Michael Champion's Blog

Simplistic subsets

Ray Ozzie [IMHO but IANAL] effectively demonstrates that 1993-vintage Lotus Notes had "prior art" that -- in a rational world -- would invalidate the Eolas patent on embedded hypermedia. This patent has resulted in a large judgment against Microsoft and raised the very real possibility that the Web browser as we know it must change drastically or infringe on the patent. Jon Udell suggests that this may be the most influential weblog entry of all time. We shall see about that, but it does have one of the most intriguing tidbits I've come across in awhile:

In 1993 or thereabouts, we saw the emergence of TCP/IP, HTML, HTTP, Mosaic and the Web. From our perspective, all of these were simplistic emulations of a tiny subset of what we'd been doing in Notes for years. TCP/IP instead of Netbeui or IPX/SPX, HTML instead of CD [Lotus Notes "compound document" ] records, HTTP instead of the Notes client/server protocols, httpd instead of a Notes server. And we were many years ahead in other ways: embedded compound objects, security, composition of documents as opposed to just "browsing" them, and a sophisticated development environment. I am quite embarassed to say that we frankly didn?t "get" what was so innovative about this newfangled "Web" thing, given the capabilities of what had already been built.

So why did the "simplistic subset" succeed so much more dramatically than Notes? Uhh, probably mainly because it is a simplistic subset! Consider the argument of Clay Shirky

The very weaknesses that make the Web so infuriating to serious practitioners also make it possible in the first place. In fact, had the Web been a strong and well-designed entity from its inception, it would have gone nowhere... Only solutions that produce partial results when partially implemented can succeed. The network is littered with ideas that would have worked had everybody adopted them. Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen.

Put differently, the Web succeeded because it hit the famous "80/20 point" -- it gave most of what other solutions offered, but at a much lower cost and complexity.

Joel Spolsky has a rather different take on this.

A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it's never the same 20%. Everybody uses a different set of features.

So, the 80/20 rule rules sometimes, but not always. Obviously, it doesn't rule when different groups need a different subset of the features. More generally, it doesn't appear to rule at the application level -- the masses seem willing to keep pour money into Microsoft's jaws to get the latest version of Office, when far fewer than 20% use features that weren't in Office 97. OpenOffice, which appears to be at about the Office 97 level of functionality and is free, has a miniscule market share. (I'm part of it, so don't flame me!). A few hypotheses:

• Minimalism ( fundamental simplicity) matters more at the infrastructure level, where it really really matters how universally something is adopted, how reliable it is, and how well it performs.
• Minimalism ( fundamental simplicity) matters more when standards are involved.
• Ease of use (simplicity of operation) is obviously critical when you are dealing with a large, relatively unsophisticated audience. The early Web didn't have to worry about this, and by the time it took off it had a "cool factor" that overcame a lot of resistance. One can't count on that happening again anytime soon!
• "Good" software, at both the infrastructure and UI levels, manages to maintain the "illusion of simplicity" by hiding the ugly details while still providing most of the functionality that one immersed in the details can employ. That's hard. Office 2003 is just starting to approach this.
• Beware of the argument that complexity isn't a problem so long as it is hidden. True enough, in the abstract, but only if it is the detail being hidden and not the complex concepts that an API or GUI is simply ignoring. For example, XSLT is a powerful tool in expert hands, but AFAIK none of the GUI stylesheet generators go much beyond the basics. The same is often said of IDEs.

Comments

• 80/20 Rule
  As far as implementation goes, IMO, the 80/20 rule is effective only when you solve the 80% case in a way that allows users to figure out a way to solve the other 20% on their own. So long as the 80% solution can be employed 80% of the time without losing effectiveness, you'll be OK.

  "The network is littered with ideas that would have worked had everybody adopted them. Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen."

  In many cases, the 20% didn't fit the author's world view, and was actively disallowed. In many other cases, the 20% was accidently (but just as effectively) broken. In my experience, it is often a case of oversimplifying, overgeneralizing, or premature design decisions -- the author can't imagine that someone would _want_ to work any other way, so they don't allow for any other way to work.

  Posted by: david_hall on October 21, 2003 at 08:08 AM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling3 on December 13, 2007 at 05:56 PM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  网络营销软件
  网站推广软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版

  Posted by: uuok999 on December 20, 2007 at 12:17 AM

This work is licensed under a Creative Commons License.