User Interface

I have a new hero.

The MSDN Channel 9 video behind that link is forty minutes long, but well worth the time. A very terse summary of the same topic is available here. Watch the video when you have the time, though; you'll be glad you did.

In case you're not feeling like clicking right now, the items at the other ends of those links concern the new Microsoft Office 2007 (formerly "Office 12") user interface. The Redmondians intend to premier a radically redesigned UI in the next version of the suite, replacing the menus and toolbars with a set of modal "tabs" across the top and a "ribbon" underneath containing rich controls representing available commands and other features. The contents of these entities will change automatically based on user-driven context such as the current selection and focus. Many of the controls in the ribbon will pack far more information than the Spartan toolbar icons in today's product; kind of like the "insert table" or "insert column" drop-downs on steroids. Formatting changes implied by these controls will be previewed in the document as you select choices in them, snapping back to normal if you dismiss the drop-down. Finally, aside from affecting the contents of the tab and ribbon bars, the user's manipulation of the mouse also provides contextual features in place, materializing out of the ether whenever you float the mouse near something interesting (again, consider the current smart tags feature on steroids).

These aren't the only UI changes coming in Office (the new PowerPoint UI for diagram formatting is nothing short of spectacular), but they're the big, thematic ones, and their implications for some of the traditions that have driven user interface design until fairly recently are worth noting.

Old Testaments

Few remember the Common User Access specification, what with its ignominious origins in the IBM/Microsoft OS/2 collaboration. But it was once the unsung Bible that described the requirements for application user interfaces under Microsoft Windows (before this responsibility, such as it was, fell to the Windows logo program). Though less sweeping and more mechanical in focus, the CUA draws its ancestry directly from the original GUI Bible, the Macintosh Human Interface Guidelines. The guidelines promulgated eleven principles guiding the design of any and all aspects of graphical user interfaces, and these principles have persisted, more or less intact, ever since. One of them was consistency. Consistency is a broad requirement, but its most common interpretation is that the elements of your design conform with one another and with similar elements in other applications.

Creative Destruction

There's a wee problem with consistency, though. It doesn't scale very well. The Office team's risk-taking this cycle is driven, at least in part, by the sheer numerical explosion of features available in each of the suite's premier applications. Traditional menus and toolbars have become too crowded to really provide the benefit they were originally designed for, namely making it quick and easy for the user to find the feature he or she is seeking. How can you possibly draw all of the little pictures distinctly and intuitively enough to enable users to find the one command they're looking for on all those toolbars?

So instead of shoveling everything into two parallel, shallow hierarchies, one textual and one pictographic, they're abandoning the "consistent" devices of yesteryear and investing in a single, three-level hierarchy (tab, ribbon, drop-down/dialog), the contents of which change on-the-fly based on the user's actions, supplemented by the most common operations being directly available from the mouse cursor itself as you float over distinct entities in the workspace.

Of course, the Office 12 innovations aren't the beginning of this departure from tradition, and they won't be the end. The smart tag and task pane features in today's Office were already moving in these directions, and the Windows group took some major steps, in XP, toward a long-term rethinking of the overall user interface; echoes of BillG's "information at your fingertips" vision. And really, all of this is nothing compared to the upheaval that will occur as developers take full advantage of the new UI layer in Windows Vista. Early efforts in this direction promise to dwarf the aesthetic obscenities resulting from early Macintosh adopters' font and graphics jubilation ("Look at all the things I can do!"), but once things settle down, the new "normal" will surely look and feel quite different from most of the two-dimensional, steam-powered interfaces that currently dominate the landscape.

And consistency also isn't the only founding GUI principle on the chopping block. Modelessness is arguably compromised by both the tabs and the context-driven chicanery, and WYSIWIG may also be turned inside-out by the live preview fireworks, as Jakob Nielsen argues. He argues, though, that this is a good thing...and he should know.

All in all, I tend to think this kind of creative destruction will ultimately be as healthy for user interface design as the other kind has generally been for American capitalism. Sure, it introduces some potentially scary new facts for the casual user, but these approaches to feature richness and complexity will likely settle into new, widely-adopted patterns, encouraged as usual by Windows API enhancements and development tools.

More importantly, it's about time these orthodoxies be challenged. The Macintosh team's principles were brilliantly insightful, of course. They wouldn't have stood the test of time as they have, otherwise. But decades have passed, and software is doing more kinds of things for more kinds of people, and yada, yada, yada.

Was This Really Necessary?

Some would argue that there's been an alternative to all of these Herculean efforts in service of complexity management: simpler applications. The vast majority of features in Office originated in user requests, but there are millions of users in thousands of business categories, so the effort to build an application that satisfies all of them necessarily produces a dauntingly complex result. Traditional, one-off development practices, along with the constraints imposed by physical economies of scale (Microsoft still sells quite a few truckloads of CDs-in-boxes every year) seem to leave little room for alternative approaches to delivering product. Then again, Microsoft themselves are assembling a development methodology that may, one day, enable them to offer people genuinely customizable families of applications, giving customers the option of choosing features based on their needs of the moment, obtaining software that is custom-built for them in minutes from the Microsoft Web site just as they obtain custom-built computers in days from the Dell Web site. Each application could be only as complicated as the user's needs require it to be, and no more.

Say it with me, ladies and gentlemen . . . software factories.