How rich is the rich GUI?

Sometimes when his lieutenants are talking, I close my eyes and hear Bill Gates -- his cadence, his repetition of favorite words. One of those favorite words is "great," as in "great platform for connected apps." Another, delivered with no apparent sense of irony, is "rich," as in "rich Internet apps." We absorb these words so easily that we can lose sight of the agendas behind them.

A rich application implies a contrasting poor alternative. And that, of course, has been a problem for Microsoft. From its perspective, the balance of power between the haves and the have-nots has been out of whack for a decade. The rich (and fat) GUI interface was eclipsed by an impoverished (and thin) third-world interloper, the browser. That was a necessary trade-off, we tell ourselves, and now it's time for the pendulum to swing back. True enough. We gave up lots of good stuff when we standardized on the browser, and one way or another, we're going to get that stuff back. And yet, sometimes I can't help asking: How rich, really, is that rich GUI we nostalgically crave?

I don't want to pick on Windows, because Linux's GNOME and Apple's Aqua share similar problems, but what got me thinking about this was a long session with the various Windows 2003 Server management tools. Most of my interaction with the software was dominated by two user-interface idioms: trees and tabs. The trees are, of course, the ubiquitous tree controls that manage hierarchies of servers, users, registry keys, and every other kind of object. The tabs are dialog boxes. These are both good and useful constructs, but as a strategy for managing complexity, they haven't evolved. Meanwhile, the Windows server products have gotten much more complex. Adding more snap-ins to the MMC (Microsoft Management Console), thus multiplying the trees and tabs, can't be the only way forward.

While it's true that the browser needs an infusion of GUI richness, the reverse is also true. The GUI needs to learn a thing or two from the browser. Consider tabbed dialog boxes. When tabs appear in multiple rows, they create a problem that Jeff Johnson, author of the wonderful book GUI Bloopers, calls "dancing tabs." Clicking on a tab not in the front row disconcertingly reorders the rows. On a Web page controlled by rows of links, that doesn't happen.

Of course, the rich GUI needn't restrict itself to the merely utilitarian. Flash developer Samuel Wan has demonstrated an intriguing fisheye effect that could be used to manage sets of choices without requiring the user to scroll or tab. When we eschew the utilitarian Web-style interface in favor of something richer, let's make sure it's really valuable.

In one crucial way, the rich GUI is tragically disadvantaged with respect to its poor browser cousin. Trying to sort out a permissions problem with IIS 6, I clicked a Help button and landed on a Web page. The page could only describe the tree-navigation procedure required to find the tabbed dialog box where I could address the problem. It could not link to that dialog box. This is nuts when you stop and think about it. Documentation of GUI software needs pages of screenshots and text to describe procedures that, on the Web, are encapsulated in links that can be published, bookmarked, and e-mailed. A GUI that doesn't embrace linking can never be truly rich.