出自UXGuide.net

功能区设计流程

Ribbon Design Process

目录 1 Surfacing commands from dialog boxes 2 Labeling commands 3 Stabilizing your user interface 4 Putting it all together

本文是用于 Microsoft® Visual C++® 2008 Microsoft Foundation Class (MFC) Ribbon 组件的设计规范初稿，将会在未来被更改。

将功能移到功能区命令用户界面不仅仅是把按钮排列在选项卡中那么简单。

如果你已经确定功能区（Ribbon）命令用户界面适合于你的程序，那么下一步就是采用有序的、逻辑性的流程来进行更改。将命令从命令栏移到功能区是对你程序界面的重大修改。你必须仔细检查每个特性，并决定如何使用功能区能够最好地传达那些特性的意义和价值。

你可能得将在之前版本中仅存在于对话框中的命令添加到功能区上。当你以选项卡和分组的方式来开始思考时，你就会发现功能之间的差距开始显现。找出用户在他们最经常访问的对话框中做了些什么，然后将这些命令移到功能区上。尽可能让用户不需要打开任何对话框就可以完成任务。

做好把大量时间花在测试和更改命令标签上的准备——是指所有标签，而不只是新增的部分。在正常的产品周期中，很少需要更改旧命令的名称，而将命令移至功能区则给了你一个难得的进行这种更改的机会。

你还需要调整原有的功能，以更好地适应功能区模式。例如，一个命令可能是动态出现在菜单或工具栏中，你在使用功能区时需要改变这种情况。否则，命令的这种外观可能会导致选项卡和分组布局发生巨大的变化。在所有情况下，不要隐藏命令，你应当将其禁用。

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.

In the above example, the work for developers turned out to be easy, because all of those features were already designed as buttons that could be added to a toolbar. Just add those buttons to the XML that describes the group of buttons on the tab.

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 a user. 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 to the Ribbon. In a typical dialog box, the user is forced to work within the dialog 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 (similar to the way toolbars work).

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. The point is that you cannot rely on these controls being adjacent. You also cannot rely on them being on the Home tab. Any individual control can be moved to any location on the Ribbon.

Labeling commands

Good labels help users tremendously. Traditionally, toolbar controls 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 you with 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 will be clearly labeled. You'll be tempted to drop labels as a way to cram a couple more commands into a tight tab. You have to realize that most users have not memorized all your icons, and unlike with toolbars, there's no separate menu-like place where a novice user can go searching 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 launches a dialog box. In the Ribbon, ellipses are only used to show truncation of text. The Ribbon will automatically strip the "?" from the end of your 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 and 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.

Disable commands, never hide them. When a command is not currently usable (for whatever reason) you must disable the command (grey out the icon and label) rather than hide it. Hiding a command will cause the layout of your groups to change, and that will likely cause the entire tab to re-evaluate its scaling, causing the tab to change, sometimes dramatically. Traditionally, hiding commands was almost always done to save space on menus and toolbars, but don't do this in a Ribbon.

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

You've got to fix the existing commands. For example, if you have an Insert Note command that only appears when non-notated text is selected, and a Delete Note command that only appears when notated text is selected, your developers should fix this issue. In this case, your current code is either showing and hiding two separate commands, or providing one command that does both actions (and has a label that changes depending on the state of the selected text). In the Ribbon, both commands must always be visible, with only one is enabled at a time.

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 few years.
   • This includes everything from every menu and toolbar, the right-click menus, and the 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.
   • Talk with your usability researcher about doing "Sort-It" tests with users.
   • What's missing? Are there features that need to be moved up from dialogs?
   • Where can you use galleries to better express the value and purpose of a feature or set of features?
   • Can a random user look at one of your tabs and know what it's for? Does the tab have an obvious purpose?
   • Think about the overall tab set. Can a random user 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.
   • 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 of record is hard. Be careful not to let your developers get ahead of your testers.