Is It Time To Replace Your User Interface?

As Office 12 and Windows Vista revamp their look, you'll be doing the same with your projects.

• By Mike Gunderloy
• 01/16/2006

Fashion is something barbarous, for it produces innovation without reason and imitation without benefit.
— George Santayana

Office 12 breaks all the rules for Windows user interface design — or does it? If you're Microsoft, you get to make the rules, and the rest of us get to follow them. Like it or not, if you're building your own Windows applications the early Office 12 test releases are a clear sign that it's time to start thinking about some radical user interface redesign work. If you haven’t yet looked at what the Office team is doing, it’s time to peek in that direction. Fortunately, with the release of Office 12 beta 1 public information has become pretty easy to find.

Just Say No to Everything
Perhaps the best place to start is with a recounting of what isn’t in the redesigned Office 12 user interface:

• No menus
• No toolbars
• No task panes

Are you feeling lost yet? Welcome to the club. That’s a pretty common reaction among those new to the Office 12 user interface, at least in my admittedly limited experience. Instead of the mix of widgets you’ve grown used to, there’s a single band of controls across the top of the screen, occupying roughly the same area that the menus and toolbars used to take up. The top of this area (informally called the Ribbon, though the name will probably change by the time the product ships) is home to a set of Command Tabs. Click a tab — they have names like Insert or Page Layout — and controls for that task show up in the Ribbon.

Controls in the Ribbon don’t have a fixed size. Things that get used a lot (like Paste) might have a huge icon and text label. Lesser-used controls (like Align Center) might have just a smaller icon with no text. Everything is grouped into some sort of logical order. There are giant tooltips to help you figure out what some things are, and flyout “galleries” that show additional choices. But the basic idea is that everything is in one place, and there’s no more need to hunt through layers of menus and toolbars and task panes and dialog boxes to find functionality.

For some pictures, try the Office 12 Preview Site and the Office User Interface Blog by Jensen Harris. Even if you don’t have a chance to play with the software, those will give you a pretty good idea what’s going on.

Check Out Those Tailfins!
Of course the user interface changes aren’t limited to the replacement of menus and toolbars by the Ribbon. That’s just the most obvious, jarring difference between Office 12 and every other piece of Windows software that you’ve ever seen in your life. As you should expect if you’ve followed the development of Office over the years, the look of buttons and tabs and so on changes as well. Things are softer and more rounded than ever before. The fonts are new and optimized for higher-resolution screens. Subtle (and not so subtle) shading and transparency effects are everywhere, and the whole user interface is (to use an overused word) “clickable.”

This sort of change is easy to predict by anyone who knows the history of Office, or who’s seen any of the early versions of Windows Vista. New versions of Office always have a fresh coat of paint and different user interface widgets than the old versions. Otherwise, how would we know they were new and improved? As far as I’m concerned, most of this stuff is just as significant as the ever-changing size of the tailfins on 1950s automobiles. Yes, your application will want to mimic the latest fashions when Office 12 and Windows Vista ship, so you can look just like the other cool kids. But it’s really too soon to worry about what that precise look will be right now, because the Office 12 look and feel will likely change a couple of times during the beta cycle. Wait and pick it up when the folks in Redmond finalize the new style, around the time that release candidate versions start appearing.

Doing the Real Work
The switch from menus and toolbars to the Ribbon, though, can’t be dismissed as blithely as the new coat of paint. This is a massive and significant change, and it’s going to require substantial development resources to move your own application in this direction. Oh, just getting the required controls shouldn’t be too difficult; I already know of several component vendors who are working on Ribbon implementations for their own control suites, and you’ll probably be able to buy Ribbon controls before Office 12 hits the suite. But that’s the least of your worries.

Here’s the problem: With menus and toolbars, all of the commands in an application were available at all times. Oh, you might have to hunt through a few levels of hierarchy, but they were there someplace. With a Ribbon-based interface, you need to figure out what the logical groupings are. When your users are doing data analysis (and so have selected the Data Analysis Command Tab) which commands do they really need? And which ones do they need the most? Which commands group together? Which ones should occupy the most important real estate (near the Command Tab name)? Which ones should have the largest icons? Which ones should have fly-out galleries? Which ones should get squished down to small icons first as the application’s window is reduced in size?

This is an area in which Microsoft has a huge advantage, because they’ve been collecting information on user interface usage for years. All those people who’ve taken Microsoft up on the offer to improve Office by submitting usage information have contributed to an enormous pile of statistics on just which commands get clicked on in which situations. Add to this the fact that Microsoft can afford to run usability studies as often as they want, with fancy eye-tracking cameras if need be, and the folks in Redmond have all the information they need to construct a new user interface that puts the majority of commands in the right place for the majority of users without guesswork.

You probably don’t have that sort of information.

Instead, you’ll likely have to fall back on the primary tool of user interface designers everywhere in grouping commands: your own intuition as to what will work best for users. Fortunately, you probably don’t have the overwhelming number of commands to manage that the Office teams does. Even so, if you do decide to switch to a Ribbon-based interface, I’d suggest that you leave time for at least one, and probably more, extra betas in your next product cycle. User feedback on which commands are hard to find is probably going to cause you to rethink your ideas on just which groupings are intuitive and correct.

What About Standards?
It’s easy for experienced Windows developers to look at the new Office user interface and get irate. After all, it doesn’t even remotely conform to the Windows user interface standards that Microsoft has been promoting for a decade now. Many of us have invested substantial time and energy in learning how Windows is “supposed” to work, and in how to build applications that are good Windows citizens — and now here comes the Office group with this new, innovative interface that breaks all the rules. It’s very tempting to just dismiss the innovation and stick with menus and toolbars. After all, standards are important, right?

There’s just one flaw in this theory: Microsoft gets to define the standards. Windows is still their playground, not an environment defined by the ECMA or OASIS or some other standards body. If Microsoft decides to ship out a few hundred million copies of Office with a Ribbon, then guess what? Users are going to see the Ribbon as the standard, not whatever antiquated interface the rest of us are used to. Real-world users don’t read the published user interface standards; they look to see what comes from Microsoft. And if you want to build applications that fit in, you’ll do the same.