How the Ribbon solves some of the problems for the menubar and toolbar, but ultimately not enough of them.
The fourth in the Menu and Toolbar series.
(Click for full size)
While some disparage Microsoft for scrapping their traditional pulldown menu and toolbars for the Ribbon, I think that if anything, Microsoft hasnâ€™t gone far enough. I congratulate MS for recognizing that the traditional menu and toolbar (and task pane) has evolved into a Byzantine monster unsuitable for todayâ€™s highly sophisticated software. I commend MS for taking bold steps to come up with something new. I happen to agree that providing both separate toolbars and a menubar has become confusing, and that the toolbar and menubar must merge. I want to cheer when the Ribbon developers say “No Automatic UI”. Finally, I want to thank MS for kick-starting interest in GUIs, showing that they’re not dead, and there are still problems to solve.
The main complaint I hear about the Ribbon is that itâ€™s different, that it has moved commands around and now they are hard to find for those used to the old menubar and toolbars of Office. Some of this criticism appears to be coming from UI developers and designers, and I wonder if many have complained about their users being resistant to change. Maybe theyâ€™ll get some empathy.
The old menubar and toolbar system of Office had evolved into a train wreck, making finding commands nearly impossible for a novice user. However, for those who grew up using Office and had memorized its idiosyncratic organization, that’s not their problem. These advanced users know how to use Office for their own purposes, so for them it doesnâ€™t matter what happens to relative novices. Users who have used Office long enough may even feel the old Office organization is natural and sensible, much like alphabetical order seems sensible only because weâ€™ve practice the alphabet since age 6 or earlier; the order of letters in the alphabet of course is actually arbitrary. Like victims of a software Stockholm syndrome, proponents of the old Office cannot see the unreasonableness of its menus and toolbars. Worse, if they are software designers, they may copy it into their own menu designs perpetuating the unreasonableness to other software.
But critics of the Ribbon do have a point. Learning something new, even if it is easy to learn, is more difficult than not learning anything at all. Anytime you make a change, you need to make the app work better than the old app if you want to get your legacy experts on board. You need to make it worth the pain of re-learning. In the case of Office 2007, benefits of the Ribbon over the old menubar and toolbar are actually worth it, I think. Or maybe I donâ€™t â€“I havenâ€™t exactly rushed out to buy Office 2007 for my own use yet.
Is the Ribbon Right for You?
More important than whether the Ribbon is right for Office, is whether the Ribbon is right for the app that you are designing. Over a decade ago, MS Office introduced the toolbar, and it has since become a standard design element of GUI apps. Will history repeat itself? Should the Ribbon be the new standard for menus? Throughout this menu and toolbar series, Iâ€™ve outlined the problems with the menubar and toolbar. How does the Ribbon handle these problems?
Of course, the Ribbon was designed the make Office better, not apps in general better. While in many ways Office is a poster child for a lot that has gone wrong with the menubar and toolbar (and Iâ€™ve used many examples from it in my previous posts), the Ribbon is also the product of specific characteristics of Office, its history, the goals of the Office design team, and its implicit user interface design philosophy. Before you adopt the Ribbon, you better be sure it addresses the problems and goals in your app. You donâ€™t want to put your users through the pain of re-learning something for naught.
Is Your App as Complex as Office?
The attraction of the Ribbon is very much tied to the kind of app it was designed for. The biggest challenge for designing a menu system for Office is accomodating the the sheer number of features. Word has a staggering 1025 commands in Version 2002 and even more in 2003. In previous versions of Office using a conventional menubar and toolbars, Microsoft met this challenge by limiting the commands on the menubar. Rather than comply with the convention of having all commands on the menus while common commands are on the toolbars, Office had some commands that were only accessible through the appropriate toolbar (e.g., Accept All Changes in Word). This is because fitting a 1000 commands on pulldown menus is not easy without it being a grand labyrinth of cascading menus.
The problem with this is the users no longer have a single, well-labeled place to find commands. After searching the menus for a feature, the user next has to search the toolbars (some which may not even be visible, but more on that later). While this simplified the menus, toolbars are entirely unsuitable for searching for a command because of their lack of text labels for either the toolbar or the items on the toolbar. Users are left to “scrub” the toolbar for the tooltips.
The Ribbon substantially reduces this problem, providing one-stop shopping for any command while avoiding the problem of an overloaded menubar. One way to look at the Ribbon is that each tab comprises a set of menus and toolbars for a high-level task. Instead of trying to pour everything into one menubar, the user first selects their major task by clicking a tab, and thereby gets the menus and toolbars to go with it. Picking a tab is like switching to a different application instantly for a given document. In this way, the menus and toolbars for each “app” have a reasonable number of commands to handle. Itâ€™s a clever solution.
But that doesnâ€™t mean itâ€™s for you. If you donâ€™t have a thousand commands or more, the Ribbon is a solution to a problem you donâ€™t have. If your app has a few hundred commands or less, you can easily accommodate them all in a menubar, leaving your toolbar to have only the top 10 to 30 commands. In this instance, the menubar already provides one-stop shopping. Given Officeâ€™s precedent with the Ribbon implies forgoing text labels for many commands, searching the pulldown menus is likely to be easier than searching the tabs of a Ribbon. If users want a shortcut to the command theyâ€™ve found, theyâ€™ll see the toolbar icon or (better) accelerator in the menu item caption.
It makes little sense to spread your one or two hundred commands among multiple tabs in a Ribbon when theyâ€™ll all fit in one set of menus and toolbars. It adds a layer to the menu hierarchy that makes commands harder to finder, rather than easier. Furthermore, it can make for “modey” user interface. For the Ribbon approach to work well for an app, it is essential that you can group your commands into major self-contained tasks, in which the user remains in a given task through multiple commands. Ideally, once your users go to a tab, theyâ€™ll remain there for a while, but youâ€™d be pretty lucky if thatâ€™s the case for an app of average complexity. If it isnâ€™t, then you users will engage in “command looping,” where they have to switch back and forward between two tabs to accomplish a task. That sort of navigation overhead can get inefficient, tedious, and annoying.
Most important is to resist the temptation to give each feature its own tab, an inferior design to using pulldown menus, which allow the user the flexibility to make any command at any time. Microsoft itself resisted this temptation with the Ribbon but only after learning its lesson in a prior attempt to group commands into self-contained tasks: Task Panes. Added complexity and loss of flexibility are some of the reasons task panes are now considered a failure and not included in Office 2007.
Is Discovering Advanced Functionality Your Main Concern?
According to Microsoft, “the overriding design goal for the new UI is to deliver a user interface that enables users to be more successful finding and using the advanced features of Microsoft Office.” Itâ€™s not about making it easier for things the users already know. Itâ€™s about getting users to do things they havenâ€™t done before, the features currently done by 0.01% of Office users (to make up a number). Apparently, the Office design team gets a steady stream of requests for features that are already in Office. With the Ribbon, they hope that stream dries up.
In the case of Office, these advanced features are primarily concerned with the format and design of documents. Julie Larson-Green, a researcher with Microsoft, is quite specific about this, saying the purpose of the new UI is to help people “make better looking documents faster.” For example, she notes that most tables in Word are black and white, which seems a waste given the elaborate shading and coloring capabilities in Word.
In theory, users will make more colorful tables in Office 2007 because the Ribbon will make it easy to figure it out (another Office 2007 feature, “galleries,” is also intended to encourage more fancy formatting). Iâ€™ve little doubt that the Ribbon will improve the discoverability of advanced formatting. MSâ€™s research on users was quite heavy, presumably including usability tests that demonstrated that advanced features are more discoverable with the Ribbon.
However, improving the discoverability of advanced features may not be the main problem with your appâ€™s menus and toolbar. Iâ€™m not even so sure itâ€™s the main problem with Office. Do you care if your tables are black and white or colored? I donâ€™t. While I donâ€™t doubt the stories of users requesting features that already exist in Office, I canâ€™t help but think that maybe the Ribbon is a case of Microsoft coming up with a bright solution to the wrong problem. I mean, I can certainly sympathize with MS developers. Iâ€™d be pretty depressed if I spent my professional life developing cool powerful features that only 0.01% of my users used. I would want a new GUI control that has been shown to make it easier for ordinary users to discover my features.
But in Office as in other apps that use the menubar and toolbar, Iâ€™m seeing plenty of low-end users having trouble finding basic commands. For basic commands, the Ribbon provides the Home tab, which is unsuitable for such low-end users for two reasons:
- To find basic commands, it requires users to know which commands are basic in order to know if they might be on the Home tab or not.
- It relies extensively on icon labels for the controls, which are difficult to recognize and interpret.
When it comes to discoverability of basic commands, the Ribbon comes up short.
Do Your Problems Have the Same Cause?
Okay, but letâ€™s say your users are having trouble finding advanced functionality and you want to do something about it. Before reaching for the Ribbon, you need to know if your discoverability problem has the same cause as pre-2007 Officeâ€™s discoverability problem. If the Ribbon is addressing the wrong cause, itâ€™s not going to help you much.
To maximize discoverability, the Ribbon scrupulously groups together commands that accomplish similar tasks. This is, of course, the way a windowâ€™s menus should always be organized so that the user can follow the information scent through the hierarchy to the sought command. As you add features to an app, you add commands by either putting them in existing menus or, if none of them are appropriate, creating a new menu.
Organizing menus by related commands is hardly an innovation of Microsoft. The only reason itâ€™s different for Office 2007 is that previous versions failed to do this. If they had, Word would look like this (click for full size):
For an app with Wordâ€™s complexity, it ainâ€™t half bad. But instead, for reasons lost in the mists of history, MS got into the practice of adding toolbars instead of adding menus for new features (the new menus in the illustration above are mostly the names of Wordâ€™s advanced toolbars). Maybe Microsoft wanted to avoid having a lot of menus on the menubar. By Word 2.0, there were nine menus on the menubar, and some old usability guidelines recommend no more than eight options at any level of a hierarchy, which isnâ€™t a bad guideline if interpreted correctly, but the alternative MS chose was worse.
A toolbar is not nearly as compact as a pulldown menu (when it isnâ€™t pulled down), the former sometimes spanning the entire window, while the latter needs space for just one word. While Word, for example, could have easily fit eight of more additional pulldown menus as shown above, displaying that many toolbars full-time would have taken too much space (click for full size).
Furthermore, with toolbars being unlabeled, having that many visible at once would have been too overwhelming anyway, making it hard to find any one command. Thus, Office apps by default hide most of their toolbars.
Now they had another problem. Access to advanced functionality is thus buried under View â€“ Toolbars. Thatâ€™s where users had to look to see the list of toolbars (right-clicking the menubar works too). In addition to being physically awkward and time consuming to access (the user has to go through a cascade menu just to see the toolbar list), itâ€™s a counterintuitive organization, useless to novices and detrimental to experts who expect View to only have commands for changing the document view. Who thinks “I want to mail merge, so Iâ€™ll look under View”? Itâ€™s organization by implementation rather than related actions. View became a de facto junk drawer menu in addition to the Tools menu.
Loading advanced features on hidden toolbars has other problems. When searching for a command by displaying candidate toolbars, users have to explicitly hide any toolbars that proved to be dead ends. Many users donâ€™t bother, perhaps because they havenâ€™t entirely given up searching a particular toolbar, and the result is a window polluted with useless toolbars that makes finding other commands harder. Combined with the need to scrub toolbar items for tooltips because of the lack of text labels, this design makes searching much harder than easily accessed, well-labeled, self-clearing pulldown menus. No wonder users could never find stuff.
This is the problem the Ribbon seeks to solve, and I believe it does. The Ribbon is really about eliminating the View â€“ Toolbars menu and putting those toolbars on tabs. Now the toolbar names are seen all the time in the tab labels, not buried under View â€“ Toolbars. Selecting a “toolbar” is merely a matter of selecting a tab, not snaking a path through a cascade menu. Now making one “toolbar” appear automatically hides the previous one, preventing toolbar pollution. Now many toolbar items have text labels, cutting down on the icon deciphering. Thatâ€™s a big usability improvement.
But seen this way, Ribbon is an extension of an existing toolbar-for-task model, more an evolution, not revolution in UI design. The proto-Ribbon has been in Office for years, in the form of the View â€“ Toolbars menu and the toolbars it shows. The Ribbon provides better organization, but primarily by bringing the commands under View â€“ Toolbars to the top level (along with redistributing Tools menu items). Basic commands are still organized under the traditional categories of File, Edit, View, Insert, Format, and Help, suggesting that these categories were actually pretty good, even if some of the names are rather vague. Score one for ancient usability engineers.
However, if MS had followed the proper approach for adding functionality in the first place and added pulldown menus rather than stuff all that functionality under View (and if not there, Tools), they may never had seen a need for the Ribbon. At some point, they could have put menubars on tabs to handle the massive number of commands in Office, but that wouldnâ€™t be the Ribbon as we know it today. Iâ€™d so go so far as to say that such an alternative branch of design evolution would have made features as easy to find as the Ribbon does.
The Ribbon was a response to bizarre usage of the View menu that never should have happened. The Ribbon is a big improvement over the old Office UI, but only because the old menu system was so screwed up. Assuming youâ€™ve never done anything like hide all advanced functionality under a random menu in your apps, the lesson of the Ribbon does not apply to you.
Smack Down for the Ribbon
While clever and helpful for the Office apps, the Ribbon is not so much a re-working of the entire menubar and toolbar concept than a user-friendly progression of MSâ€™s design philosophy. It still retains many of the design characteristics of the traditional menubar and toolbar, and thus perpetuates many of the problems Iâ€™ve discussed with the menubar and toolbar. Hereâ€™s a list of the problems with the menubar and toolbar from my previous posts in this series:
A. Users canâ€™t find features in the menubar because of:
1. Vague menu names.
2. Menus organized by implementation.
3. Menubar overwhelmed by toolbars.
B. Countless cryptic toolbar items clutter windows causing confusion because:
4. There’s confusing terminology in documentation.
5. Tiny pictures are used to convey actions.
6. Toolbar item behavior is not predictable from appearance.
7. There’re just plain too many toolbar items.
C. The menubar and toolbar combination fails in its attempt to provide a satisfactory UI for novices and experts. This is because:
8. Menu labels provide weak information scent to novices.
9. Itâ€™s too onerous to match menu items to icons on a separate toolbar.
10. Novices are encouraged to start with the toolbar, so never really learn the menubar.
11. Duplication commands in the toolbar adds complexity to the app.
12. Users must correctly select the appropriate interface for themselves.
Letâ€™s see how the Ribbon fares when it goes up against each of these problems mano a mano.
1. Vague Menu Names
While the Tools menu label is thankfully gone, weâ€™ve a new label called “Home” (or “Message” in Outlook), a vague name that says nothing about what all the commands within its tab have in common. What the commands have in common is theyâ€™re all commonly-used commands. The problem with that is, even if the users know this, they arenâ€™t going to necessarily know whether a command theyâ€™re seeking is commonly used or not. The result is Home becomes the new junk drawer in place of Tools, potentially having anything, and therefore always needing to be searched when looking for a command.
Additionally, the View menu is retained as the “View” tab on the Ribbon. View may be a sensible category of commands (as implemented in Office 2007), but the label is problematic. “File” is another problematic menu name, which is missing from the Ribbon, replaced by something worse: the Office logo. Assuming users even recognize it as the Office logo, what is it supposed to mean? “Here are the Office commands”? Arenâ€™t all the commands in the Office suite Office commands?
2. Menus Organized by Implementation
The frightful abuse of the View menu is gone, with View â€“ Toolbars replaced by the tabs. Offhand, I donâ€™t see any cases of where commands are organized by implementation.
Result: Win, I think.
3. Menubar Overwhelmed by Toolbars
Well, thereâ€™s no menubar to overwhelm any more, so you might think this is a win by forfeit (which in this game is the best kind of win). However, the Ribbon includes something new: the tabs. Like the menubar, Iâ€™m concerned that the relatively muted tab labels can be lost in the clutter of the multi-sized and multi-colored command controls within each tab. However, until Iâ€™ve a chance to witness a lot of users attempting to use the tabs, that is only a suspicion.
Result: Tie so far, going into overtime.
4. Confusing Terminology in Documentation
Alas, confusing geeky terms remain in the Office 2007 user documentation. The tool metaphor is still inappropriately applied. “Toolbar” is used in reference to the Quick Access Toolbar, and sometimes “Tools” is used for menu items, although usually they are referred to with the superior term “Commands” (so I guess you could say thereâ€™re some consistency problems too).
“Ribbon” itself should not have been used in user documentation. It has even less metaphorical meaning than “toolbar,” and it doesnâ€™t look like any ribbon I know. It should simply be called “the menu,” but I imagine someone in marketing required it have a funky name to give it some branding.
5. Reliance on Tiny Pictures to Convey Actions
Overall, Iâ€™d say Office 2007 has made definite improvements here, being much more likely to provide text labels for Ribbon items than they were for toolbar items in previous versions. This can especially be seen in tabs other than the Home tabs, which have the less commonly used commands that benefit the most from text labels. However, that still leaves the Home tab with its heavy reliance on icons, which novices are expected to memorize and use. With the removal of the redundant pulldown menu items, there is no place to see the command names for these. If your users donâ€™t know the icon for Copy, theyâ€™re just out of luck. I call it a wash.
6. Toolbar Item Behavior is not Predictable from Appearance
The Ribbon largely continues the tradition of the same-looking control acting like a pointer-tool, command button, option button, and check box (although I do occassional see a conventionally rendered checkbox control here and there). The worse offender has to be using the same appearance for three very different controls:
- A pulldown menu, where the caption indicates what you get in the pulldown.
- A dropdown menu, where the caption indicates the current setting in your document.
- A sort of button-dropdown combination, in where the caption indicates the current setting of the button.
The net effect is that the user canâ€™t tell at a glance what the caption is trying to say.
7. Too Many Toolbar Items
While still cluttered-looking at first glance, the Ribbon improves greatly on this. In shear number, a single tab of the Ribbon has 30 or more controls, as many as a large toolbar. However, the raw number alone is misleading. The problem with having that many controls on a conventional toolbar is that they become an undifferentiated mass of little pictures. Combine that with multiple unlabeled toolbars blending together, and you have real problems. I mentioned earlier the old usability guideline of restricting the number of options to eight or less. Conventional toolbars is the kind situation where that guideline applies.
However, it has been found that you can have many more options if you subdivide and group them, ideally with text labels for the groups. This is what the Ribbon has done to the conventional toolbar: it has labels for each toolbar-equivalent (the tabs) and groups and labels commands within each toolbar. Making commonly needed controls bigger may also make them easier to find, as well has having efficiency advantages according to Fitts law.
8. Menu Labels Provide Weak Information Scent to Novices
Result: Lose, but we wonâ€™t count it because itâ€™s the same as 1.
9. Itâ€™s Too Onerous to Match Menu Items to Icons on a Toolbar
Thereâ€™re no menu items to match to the toolbar anymore, so that solves that problem. Of course for some commands such as those on the Home tab, the users have only the icons, completely removing anything to help novices transition to expert-hood. Itâ€™s like saying itâ€™s hard to look up things in Help, so weâ€™ll just eliminate it. Besides, at some point users will have to match the command name to its icon, whether the command name comes from Help or someone who is trying to teach the UI. However, it wouldnâ€™t be fair for me to ding the Ribbon twice for using some icons without text labels (see 5), so Iâ€™ll give it a pass.
Result: Win, by forfeit.
10. Novices are Encouraged to Start With Toolbar so Never Learn the Menubar
This is pretty much the same situation as number 9: novices have only the Ribbon to learn.
Result: Win, by forfeit.
11. Duplication of Commands
Microsoft really tried to eliminate the duplication of commands as found with conventional menubar and toolbar combinations, and in doing so, they gained decisive wins in 9 and 10. But then they kind of blew it by re-introducing redundancy in the form of the Minibar and Quick Access Toolbar. The Ribbon is example of a great design vision that had to be corrupted by reality. The vision was One-stop Shopping: get rid of those toolbars and task panes and just have the Ribbon, one thing to learn.
But for maximum efficiency, the Ribbon requires that commands fit neatly into self-contained tasks, which isnâ€™t necessarily the case, and evidently wasnâ€™t for the Office suite. Instead, there were certain commands like Undo and basic formatting that tended to be used across all major tasks. The Minibar and Quick Access Toolbar are attempts to deal with this reality and prevent command looping. These additions to the Ribbon were necessary, but they also show a weakness in the vision.
12. Users Must Correctly Select the Appropriate Interface
With the Ribbon, users no longer have to chose between the pulldown menus or the toolbars. However, they do have to choose among Home, Minibar, or Quick Access Toolbar over other portions of the Ribbon. They have to guess whether the designers of Office regarded the command they seek to be worthy of special consideration for these special locations. Itâ€™s really about the same as trying to guess if a command is on a toolbar or not.
Tallying it up, throwing out the ties, and I see the Ribbon has a 4-and-5 record. Not bad, especially compared to the competing menubar and toolbar combination and its 0-and-12 record. You can see why I consider the Ribbon to be a significant improvement for the Office suite.
But the Ribbon is also ultimately disappointing. Some call the Ribbon radical. I say itâ€™s not radical enough. There are still several menu problems it has not resolved. As a response to the specific problems found in a specific office suite, itâ€™s worth it, even if it means expert users have to do some relearning. However, given its mixed performance, for your app you could do just as well following advice from my previous posts for the menubar and toolbar. By mitigating the problems of the menubar and toolbar with better documentation and tooltip usage, more menus with better menu names and organization, a toolbar diet and use of text labels, the use of detail panes, and so on , you may achieve the equivalent of a 4-and-5 record yourself, and your experienced users wonâ€™t have to learn something entirely new.
There is an alternative to both the Ribbon and a mitigated menubar and toolbar, and thatâ€™s to make an entirely different kind of menu with a 12-and-0 record. Such a menu system would ideally be more flexible than the Ribbon, working as well with simple apps as complex ones. While on the one hand more radical than the Ribbon, it would ideally also allow a range of compatibilities with the existing menubar and toolbars so that you can tailor the amount of relearning to your specific user population. One such alternative is coming next in the last of the menubar and toolbar series.
Problem: Should your app use a Ribbon in place of conventional menubar and toolbars?
Potential Solution: The Ribbon is appropriate if several of the following are true about your app:
- Your app is highly complex with 1000 or more commands that cannot be fit into a single menubar.
- These 1000-plus commands neatly divide themselves into major self-contained tasks such that your app is better thought of as several apps that happen to use the same document or data objects rather than a single app.
- Your primary problem with the current menubar and toolbar system is that users cannot find advanced features.
- Users couldnâ€™t find features because they were put exclusively on toolbars rather than adding pulldown menus.
- Considerations of novices trying to learn your app override concerns about experts having to re-learn your app.
- Mitigating the problems with the current menubar and toolbar do not result in adequate improvement.
- Other alternatives are not suitable.