Combating the Perception of Bloat (Why the UI, Part 3)
This is the third part in my weekly series of entries in which I outline some
of the reasons we decided to pursue a new user interface for Office 12. You can
read the last installments here:
Part 1
Part 2.
Last week
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 12.
(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.
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 12, 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 12
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.