Ribbon Design Process

Moving your features to a ribbon involves more than just sorting your buttons into tabs.

Ribbons

If you've decided the ribbon command user interface is appropriate for your program, the next step is to adopt an orderly and logical process for making the change. Shifting from menu bars and toolbars to the ribbon is a major overhaul of your program's interface. You must scrutinize every feature and decide how to best use the ribbon to convey the feature's meaning and value.

When you start thinking in terms of tabs and groups, you'll find that gaps in functionality start to appear. You'll have to add commands to the ribbon that may have existed only in dialog boxes in previous versions. Find out what users are doing in the dialog boxes they most frequently access, and move those commands to the ribbon. Whenever possible, allow users to complete tasks without having to open any dialog boxes.

Expect to spend a lot of time testing and changing command labels—all of them, not just the new ones. In a normal product cycle, it's hard to justify changing the name of an old command. Moving commands to the ribbon gives you a rare opportunity to make this type of change.

You'll also be tweaking legacy functionality to better fit the ribbon model. For example, one of your commands may have appeared dynamically in your menus or toolbars. You'll need to change this functionality when using the ribbon. Otherwise, the appearance of the command can cause drastic changes to the layout of your tabs and groups. Applying the ribbon guidelines, rather than hide a command, you should disable it.

Surfacing commands from dialog boxes

Once you have a rough draft of what you think your program's tabs and groups will contain, take a look at the organization and think about what's missing.

For example, in Microsoft® Word, usage data indicates that the font dialog box is one of the most used in the program. Additional data shows that superscript, subscript, and strikethrough features are often manually added to the formatting toolbar. The Grow font and Shrink font buttons are frequently used in Microsoft PowerPoint®, where these commands appeared on the default toolbars.

As a result, in the Font group of the Word Ribbon, eight new commands could be imported, in addition to the original commands from the default Formatting toolbar in Word. Doing so made it much less necessary to open the font dialog box. It also meant that a huge percentage of user customization from previous versions was no longer necessary. The work in this case turned out to be easy for developers because all of the features were already designed as buttons that could be added to a toolbar.

In many cases, you'll find that a "toolbar-friendly" version of a feature doesn't already exist. For example, in Microsoft Excel 2003, to select all cells affected by conditional formatting, users had to open the Go to... dialog box, click the Special... button, then choose Conditional formats, and finally click OK to see the results. This dialog box was the only place the feature existed. There was no equivalent command that could be added to a menu or toolbar by users. To add a command like that to the ribbon in Office 2007, a toolbar-button-like version had to be built.

Often it is not immediately clear how to move a feature from a dialog box to the ribbon. In a typical dialog box, the user is forced to work within the dialog box until clicking OK. At that point, all the choices are committed and the user is returned to the program window. When the user interacts with a control on the ribbon, the changes are committed immediately.

This means that all of your controls have to work independently, and they can never rely on additional controls. For example, you'll never choose a font face, and then a font size, and then click OK to apply both at once. There can never be an OK or Cancel button in the ribbon. This does not mean that controls can't affect one another. For example, in the Paragraph group, choosing Right justify causes Left justify to become unselected.

Labeling commands

Good labels help users understand commands tremendously, but most toolbar commands are unlabeled. There isn't much room on a 640 (or even 800) pixel wide screen, and the desire to fit as many commands on the toolbar as possible means that labels are usually sacrificed. Additionally, an especially wide translation of a label might unintentionally force some other command off the screen.

One of the main benefits of the ribbon is that it provides enough room to label everything. As you lay out your tabs and groups, remember the goal that, at the most common resolution, most commands in the ribbon should be clearly labeled. You'll be tempted to drop labels as a way to cram a few more commands into a tab. You have to realize that most users won't memorize all your icons, and unlike with toolbars, there's no separate menu bar where users can search for labels.

Only a few extremely well known commands can be unlabeled by default. They'll be commands like Bold and Cut, and they'll almost certainly be on your Home tab.

Don't use an ellipsis (...) to indicate that a command requires more input. Directly on the ribbon, ellipses are used only to show truncation of text. (However, ellipses still have their traditional meaning in drop-down menus.) The ribbon strips ellipses automatically from the end of labels. When you're trying to fit a few more buttons on your tab, you'll be glad to have all that space back.

For more guidelines, see Labels.

Stabilizing your user interface

One of the main benefits of the ribbon is that it provides a single, stable location for all the commands in the program. This stability gives users more of a sense of mastery over the program, whereas a dynamically changing UI causes a lot of confusion. Be sure to find these issues early in your planning.

To maintain stability, disable commands that don't apply instead of hiding them. Hiding commands cause the layout of your groups to change, and that will likely cause the entire tab to change, sometimes dramatically.

Never change labels dynamically. Again, changing a command's label on the fly causes major repercussions to the overall tab layout. You'll likely have to tweak existing functionality and labels to make a command ribbon-friendly.

You may have to redesign existing commands. For example, suppose you have an Insert note command that appears only when non-notated text is selected, and a Delete note command that appears when only notated text is selected. In the ribbon, both commands must always be visible, with only one enabled at a time.

Make users love the ribbon

Most users don't like change, especially if that change requires more effort or relearning. Users will get frustrated if tasks that were easy in your old program become difficult or hard to find with your new one.

To make users love your ribbon:

• Make sure commands are as easy to find as before. Given the consolidation and explicit labeling in ribbons, most commands should be easier to find than before.
• Make sure tasks are as easy to perform as before. By using results-oriented commands and other types of preview in ribbons, many tasks should be easier to use than before.
• Make an extra effort to ensure that the most frequently used keyboard shortcuts and access keys from your old program still work as expected. Definitely avoid assigning new meanings to access keys from legacy menu categories. For example, if the legacy menu bar version of a program had an Edit menu, strive to use an E access key to the equivalent tab. Power users are passionate about their efficient keyboard use and will especially appreciate this consistency. And they will also especially notice when it's missing.

Don't assume that you've got it right. Rather, perform user testing throughout the design process to make sure users not only can perform their tasks, but do so significantly better than before.

Putting it all together

These are roughly the steps you'll go through as you move commands for features into the ribbon. In actuality, you'll go through all of these steps dozens of times during the many iterations you'll be doing over the course of the product cycle.

1. Make a spreadsheet of all the commands in your program. Take the time to get this list right, as you'll be depending on it for a while.
   • This list includes every command from menu bars, toolbars, context menus, and any customization UI.
   • For each command, you'll want:
     • Toolbar Control ID (TCID) information
     • Label
     • Usage data
2. Filter out commands that belong on standardized program tabs:
   • Home
   • Insert
   • Page layout
   • Review
   • View
   • Developer
   • Standardized contextual tabs
3. Filter out commands that belong on contextual tabs.
4. Filter out commands that belong in standardized groups:
   • Clipboard
   • Font
   • Paragraph
   • Editing
   • Tables
   • Illustrations
   • Themes
   • Page setup
   • Arrange
   • Proofing
   • Comments
   • Document views
   • Show/hide
   • Zoom
   • Window
   • Macros
5. Organize the remaining commands into small groups of related functionality.
   • Group program-specific clusters of commands.
   • Talk with your usability researcher about doing "Sort-It" tests with users.
6. Organize the groups into a total of 5-10 task-based tabs.
   • Begin prototyping tabs. Try out your prototyped UI.
   • Work with your user researcher to do command card sort tests with users.
   • What's missing? Are there features that need to be moved up from dialog boxes?
   • Where can you use galleries to better express the value and purpose of a feature or set of features?
   • Can users look at your tabs and know what they are for? Does each tab have an obvious purpose?
   • Think about the overall tab set. Can users read across the tab row and understand what your program does?
   • Think about the future of your program. Will the tabs you've picked make sense for the next several versions? Do they fit the overall direction of your program?
7. Build any new features and add them to your tabs.
   • Until the new features are built, you'll be dealing with gaping holes in your tab designs.
   • And even worse, when something gets cut, you've got to deal with that hole becoming permanent. Think about this up-front. Features get cut all the time, and you'll have to deal with it fast.
8. Test the organization of your features.
   • Do this throughout the development cycle, not just at major beta release dates.
   • Try using your prototypes yourself.
   • Have others use your prototypes and give you feedback.
   • To the best extent possible, design keyboard access keys and shortcuts to be compatible with previous program versions.
   • Try to get feedback about extended use, not just initial reactions.
9. Iterate, iterate, iterate.
   • Make sure all roles (including developers, testers, and relevant managers) are planning for constant iteration on the organization of commands.
   • It's very easy to make changes since all the layout is simple XML.
   • But, documenting the current plan is hard. Be careful not to let your developers get ahead of your testers.