What I find especially frustrating, though, is how Microsoft forces me to spend so much time pampering their software. Yes, I'm talking about Internet Explorer, the iconoclastic web browser that refuses to acknowledge web standards.

How much online productivity is lost trying to get websites to look and function properly on Internet Explorer?

That would be an interesting question to explore. Talk to just about any web designer, and they will tell you that, for every 100 hours they spend on design, 50-60 hours are dedicated to actual design, and the rest is devoted to creating xhtml and CSS hacks to get it to work on Internet Explorer.

This is just as true today.

It's getting to the point where we're thinking of adding IE6 compatibility as a separate line item on our proposals and agreements. After all, when you're spending 35-50% of your theming time just trying to get a cool new design to work on one rather archaic browser, it's no small matter.

It's a ≈40% tax on web theming.

How can we get out of this? Thanks to Microsoft market share and IT departments' resistance to upgrading, I fear we're not going to be able to say a final good-bye to IE6 anytime soon.

Sophia Locero points to the IE Death March and several other like minded efforts to build a collective movement to simply drop IE6 support, and asks:

So many parties are restless about the state of web browsing, and rather than wait for Microsoft to get its act together, they take it upon themselves to do something about it. It doesn’t really stop with the viral websites. Every few months or so you’ll find a blog post that details how the author has had it with IE (IE6 usually) and that he has resolved to drop support for the browser completely.

One must ask: are any of them making a significant difference in the market share of IE? Or IE6, specifically?

I don't think so. Here at pingVision, nearly every one of our clients requires IE6 compatibility for their web projects, and I don't think that's because they're unthinking or naive about browsers. The fact is that their audience -- and, quite often, their own organizations -- are locked into IE6 by their IT departments.

Will 37 Signals' dropping of IE6 support make a dent in their market? Perhaps not, since their audience is probably already heavily skewed towards Firefox anyway. But our B2B clients would likely see a huge drop-off in traffic if their sites did not support the IE6 that still permeates corporate desktops and workstations the world over.

Still, what we have here is a tax on productivity, and if Microsoft did one thing to help the online economy, it would simply EOL IE6 altogether. Right. Now.

Meanwhile, we'll consider adding the "Microsoft Internet Explorer 6 Tax" to our estimates as a line item for all clients to see.

There probably will be a couple of betas after this, followed by a couple of release candidates before the official release of Drupal 5.0. Starting in the next couple of weeks, we'll start using Drupal 5.0 as the development foundation for new sites we develop that won't launch before December or January and don't depend heavily on the hundreds of the contributed modules in the Drupal community. For sites wanting a lot of those functions, we'll either work off of Drupal 4.7 or work module upgrades into the sites' development processes.

We'll review Drupal 5.0 in the coming days and weeks and post a run-down of some highlights. Existing clients and other Drupal users might want to consider planning for an upgrade sometime in the first half of next year.

Recently on his blog, Drupal founder Dries Buytaert wrote:

The Ockham's Razor Principle of Content Management Systems says that given two functionally equivalent content management systems, the simplest one will be chosen. It asserts that simplicity is preferred to complexity. As content management systems become more alike in terms of critical functionality, ease of use will become a key differentiator (rather then functionality).

In addition, web application frameworks like Ruby on Rails, whose goal is to develop applications with as little code as possible, are redefining the rules of how websites are built. For web application developers, ease of development will become a key differentiator.

Complexity is a disease.

Much as I hate to disagree with Dries, I truly do not believe that simplicity itself makes for "ease of use." Usability arises from many different principles, of which simplicity in the abstract hardly ranks.

Case in point: DVDs vs. Drupal-powered websites. DVDs can be aggravatingly unusable, despite their inherent architectural simplicity. On the other hand, websites powered by anything can be incredibly easy to use and understand, even without disabling rich and complex functionality.

To Dries' post, I responded, in part:

I'm not so sure that simpler is always better. Which is easier to drive: A BMW? or a prototype car that just has a joystick? The BMW, with steering wheel, pedals and gear shift, is much more complex in terms of user interface, but for most people it is also easier to use, despite the fact that the prototype vehicle with just a singular joystick is obviously a much simpler interface. Existing patterns of use always come into play.

In another example: A looping handle on a door you can only push open is bad design, no matter how simple it is. People will take a cue from the design and try to pull that door open. A push-latch bar on a door, on the other hand, is much more complex to design and manufacture, but it is infinitely easier for people to use. Very few people will try to pull open that door.

Complexity isn't a disease -- confusion is the disease. Complexity often leads to confusion, and that's a problem. But complexity in itself doesn't have to confuse. All you have to do is listen to a Beethoven symphony to hear the proof of that.

When it comes to making a website easy to use, we're always balancing principles such as affordance, accessibility, chunking, signal-to-noise ratio, forgiveness, feedback, the list goes on. The law of parsimony, which people call Ockham's Razor, is but one part of the picture -- and taken to its extreme, can lead to maddeningly unusable design.

One of the greatest appeals for me about Drupal is its inherent flexibility and capacity for very complex content management. The challenge for me, as a designer, is to make that complexity into something usable. Sometimes that means simplifying choices or function, but mostly I'm focusing on clarity and affordance. As new, more powerful functions and features are being added every day to the Drupal core and contribution repository, sometimes ease of use can slip away from us for a while. It's gratifying to read of Dries' interest in adding to the Drupal development process a real focus on ease of use -- especially since I do not believe Drupal has to lose any of its robust complexity in order to achieve this.

One of the very exciting developments to arise in last week's worldwide Drupal developers' conference call was discussion on revamping the entire theming architecture of Drupal, so that, eventually, all of the content presentation is called and handled by the theme. So far, much of our work in designing Drupal themes is in handling information that is pushed out from the CMS. Changing this paradigm into a pull mechanism can make for some exciting new ways we can develop user interfaces for Drupal-powered sites in the future.

Related and recommended: "Universal Principles of Design", by William Lidwell, Kritina Holden and Jill Butler (Rockport Publishers: 2003).