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

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 (31)
  1. Anas Hashmi says:

    You mentioned that auto-customization of the UI would cause it to expect in unintended ways.  That is not exactly true.  Having a deep look into Aritificial Intelligence, I believe firmly that humans think from a pattern and that this pattern can be calculated, enacted, and signal future events or actions.  

    Well thought out Artificial Intelligence can take decades to innovate and the calculations cannot be processed today even by the world’s fastest super computers in acceptable time.  However, small steps can be taken.  

    We already have the concept of recent documents.  The documents that I am currently working on is a step away.  Likewise, every user has a set of functions that he or she always uses and another set of functions that the user is using multitude of times in a particular session, such as repetitive tasks.

    These functions could come up in a "Common Use" toolbar.

    User actions could be monitored and calculated.  However, the drawback might be computer processing time, e.g. keeping track of the order of user functions and calculating movement patterns.  

  2. Bob Snyder says:

    New Topic Suggestion: As long as you’re discussing the history of the UI, I’d be interested in hearing what was learned in the usability labs with regard to What’s This help (i.e. the mechanism introduced circa Win95 where you first click a What’s This help button on the window’s title bar, and then you click on a specific control to get help on that control.)

  3. Sebhelyesfarku says:

    Confess, who "invented" that retarded Clippy!

  4. This is the fourth part in my eight-part series of entries in which I outline some of the reasons we…

  5. This is the sixth part in my eight-part series of entries in which I outline some of the reasons we decided…

  6. Angie says:

    Well done!

    [url=]My homepage[/url] | [url=]Cool site[/url]

  7. Angie says:

    Well done!

    [url=]My homepage[/url] | [url=]Cool site[/url]

  8. A topic that has come up frequently in our private beta newsgroups as well as here in blog comments from…

  9. While walking through Jensen’s museum of Office Past I came across several fun posts: Combating the perception

Comments are closed.

Skip to main content