Partager via

Combating the Perception of Bloat (Why the UI, Part 3)

  • Article

This is the third part in my eight-part series of entries in which I outline some of the reasons we decided to pursue a new user interface for Office 2007.

Last time we started a walk down memory lane by taking a look at the first five major versions of Word for Windows. I ended by showing Word 97, a major milestone release which included many useful new features and improvements. Office 97 also introduced command bars, a paradigm in which menus and toolbars were made more similar in capability and visual design. All this new functionality came at a cost, however, and part of this cost was increased complexity in the user interface, mainly through the addition of new menu items and toolbar buttons. Responding to this, the industry press started publishing articles and popularizing the idea that Office was "bloated."

In reality, the programs themselves weren't "bloated." At least, the miles-long list of feature requests from customers indicated that, if anything, people expected us to do more in this space. What had happened, however, was that the user interface had begun to feel bloated. Like a suitcase stuffed to the gills with vacation clothes, the menu and toolbar system was beginning to show signs of not being scalable enough to fit the richness of the product. It was becoming harder to get the zipper shut each release. Some people perceived the result as "bloat."

Office 2000 introduced several new UI mechanisms designed to reduce this perception of "bloat." In many ways, this release marks the beginning of the road that eventually turns towards the redesign of the UI in Office 2007.


(Click to view full picture)

The first new mechanism, called "Adaptive Menus" or, later, "Personalized Menus" were an attempt to make the top-level menus appear shorter by showing the most popular items first. After a few seconds (or after pushing a chevron at the bottom of the menu) the menu expanded to show the full contents. As you used the menus, items you used often were promoted to the "short" menu and items you never used were demoted to the "long" menu. This was the adaptive part, and the idea was that eventually you'd have a fully-tuned, auto-customized UI that would show you only what you need and use.


(Click to view full picture)

Adaptive Menus were not successful. In my opinion, they actually add complexity to the interface. Why? Several reasons:

  • There was no way to get the default "short" menu right. Although conventional wisdom holds that "everyone only uses the same few features in Office," the reality is that people use an amazingly wide range of functionality. So, one person's ideal default "short" menu was exactly the wrong thing for someone else.
  • Once the default short menu was wrong, the user was forced to scan the menu. However, scanning adaptive menus requires two passes: scan the short menu, press the chevron, then back to the top to scan the long menu. Because the secondary menu items could appear between short menu items, the appearance of the long menu caused your scan to reset. As a result, scanning menus took twice as long Even if they had designed it so that pushing the chevron revealed the bottom part of the menu (and the top part didn't change), at least you'd only have to scan the menu once. So, adaptive menus added a lot of inefficiency.
  • Auto-customization, unless it does a perfect job, is usually worse than no customization at all. Although the algorithm used to promote and demote menu items is rather complex and well thought-out, it's not perfect. Because it's not perfect, it does the wrong thing a lot of the time. (If it's even clear what a "right thing" is for a feature like this.) What people experienced is a sense randomness and unpredictability: one time, a menu item would be in a certain place, and then two days later it wasn't there anymore.

As a result, even for the Office 2007 applications that are still using old-style UI (such as Publisher, Project, and Visio), we've turned off Adaptive Menus by default.

The other new mechanism in Office 2000 designed to reduce the perception of bloat was "rafted toolbars." In this design, two or more toolbars could share a line on the screen. By default the Standard and Formatting toolbars were "rafted" together onto the same row. As there wasn't space on most monitors for both toolbars, a complex algorithm decided which toolbar buttons were least likely to be used and those were moved from the toolbar into an overflow area at the end. Just like with adaptive menus, as you used the toolbars, buttons were promoted and demoted from the toolbar and moved to/from the overflow area.


(Click to view full picture)

The rafted toolbars add complexity for the same reason as the adaptive menus do. The order of commands was no longer constant, scanning for functionality was inefficient, and predictability suffered as nothing could ever be guaranteed to be in the same place even from click to click.

The result: most customers, especially those in corporate environments, turn both of these features off.

So, if these mechanisms were so flawed, why were they introduced into the product in the first place?

First, remember that we're analyzing this with 20/20 hindsight. As computers got more powerful, there was a lot of excitement (not just at Microsoft) about "auto-customization" and using the power of the computer to present exactly the right UI for the person at hand. Now, it's easy to say that today people are generally against this idea because it seems to cause unpredictability, but we know that mainly through trying experiments such as the adaptive UI in Office 2000.

But the second, more important piece is that the people who worked on these mechanisms were working within a very narrow set of requirements. Office was known at the time for being very conservative about the user interface; as I discussed last time, until Office 2007, the top-level menu structure of Word hasn't changed since 1989. This consistency was a good thing in many customer's minds, because an unchanged UI meant virtually no retraining costs.

Whatever enhancements were designed had to be done within the confines of not changing the structure of the UI. This means that, if you want to have short and long menus, you have to make the long menu items show up in-place--otherwise you're changing the order of well-known menu items (which would have been a non-starter.)

Similarly with the rafted toolbars, there's only so much you can do to make the toolbars simpler if you can't change the core contents of the Standard and Formatting toolbars.

So, it's not as if we're somehow smarter than the people who worked on the Office 2000 UI. (In fact, some of the biggest supporters of the Office 2007 UI today are people who worked on and taught us what they learned from these earlier versions.) They had to try to reduce the perception of bloat--to combat the fullness of the menus and toolbars--without changing the actual contents of the menus and toolbars. It was kind of like when I was told to clean my room as a kid and I just hid everything under the bed. It looks good on first blush (and on the back of the box), but the facade doesn't hold up for long.

In the end analysis, we didn't end up making the suitcase any bigger or the zipper any easier to close--we just added more pockets.

Next week, we'll take a detour into one of the special exhibits at Ye Olde Museum of Office Past : the "Office Assistant" wing.

Comments