出自UXGuide.net

功能区：设计理念

Ribbons: Design Concepts

目录 1 这样的用户界面是否正确？ 2 设计理念 2.1 将 Ribbon 应用于已有的程序 2.2 Ribbon 的自然特性 2.3 富命令的自然特性 2.4 Ribbon 总是包含应用程序按钮和快速访问工具栏 2.5 但应用程序按钮可以离开 Ribbon 单独使用 2.6 组织与可发现性 2.7 选项卡 2.8 分组 2.9 预览 2.10 Ribbon 缩放 3 注释与引用

这样的用户界面是否正确？

考虑下列问题以进行判断：

程序类型

• 你在设计什么类型的程序？程序类型是 Ribbon 是否合适的好的标志。Ribbon 适合于文档创建和编辑的程序，以及文档查看器及浏览器等。对于其他类型的程序来说，Ribbon 也许可行，但其他形式的命令呈现方式可能更加适合。通常来说，轻量级的程序应当具有轻量级的命令呈现方式。（有关程序类型列表，参见程序命令模式。）

可发现性及学习问题

• 用户在寻找命令方面是否有困难？用户期望添加的功能是否已经包含在程序中？如果是，使用带自说明标签以及相关命令组合的 Ribbon 可使命令更易于查找。对于将来的扩展来说，使用 Ribbon 也比菜单栏和工具栏要好。
• 用户在理解程序的命令方面是否有困难？他们是否经常需要通过试错来选择正确的命令或是确定命令如何使用？如果是，使用基于 Gallery^[1]和实时预览的面向结果的 Ribbon 可使命令更加易于理解。

命令特征

• 这些命令是否在多处出现？如果你的程序已经存在，其命令是否出现在菜单栏、工具栏、任务窗格及工作区域内？如果是，使用 Ribbon 可将这些命令统一至单一的位置，使其更易于查找。
• 这些命令用作整个窗口还是仅限特定的面板？Ribbon 最适用于用作整个窗口或者特定对象的命令。就地命令则更适合于单独的窗口面板。
• 是否大多数命令都能直接呈现？这是指，用户是否只需一次单击即可使用？如果经常使用的命令需要从菜单或对话框中访问的话，能否将其重构为能够直接使用？虽然有些命令可以通过菜单和对话框来呈现，但是将大多数命令如此呈现会削弱 Ribbon 的使用效率，可能菜单是更好的选择。

命令规模

• 命令是否数量很少？能否将最常使用的命令直接显示在一个简单的工具栏上？如果在增加一些核心和上下文选项卡之后，Home^[2] 选项卡能够保持简单且可单独用于完成最常用的任务的话，那么使用 Ribbon 是值得的。否则，使用 Ribbon 带来的好处可能不足以弥补为少量命令增加的额外复杂度。
• 命令是否数量很多？如果使用 Ribbon 是否会需要超过七个核心选项卡？用户是否需要不停地切换选项卡以完成常规任务？如果是，使用工具栏（无须切换选项卡）和调色板窗口（可能需要切换选项卡，但可以同时打开多个）可能是更高效的选择。
• 用户在大多数时候是否倾向于只使用一小部分命令？如果是，只要将这些命令放在 Ribbon 的 Home 选项卡中，他们即可方便地使用。不停地切换选项卡会降低 Ribbon 的使用效率。
• 该程序的内容区域是否越大越好？如果是，使用菜单栏和单个工具栏比 Ribbon 更省空间。不过，如果你的程序需要三行以上的工具栏或者任务窗格的话，使用 Ribbon 则会更省空间。
• 用户是否倾向于在程序的大窗口中的特定区域进行长时间的工作？如果是，排列紧凑的微型工具栏、调色板窗口和直接命令会更加适用。把工具区域周围的命令组织到 Ribbon 中可能降低使用效率。
• 对于效率和灵活性来说，用户是否需要对命令呈现的内容、位置或尺寸进行重大改变？如果需要，可自定义可扩展的工具栏和调色板窗口则是更好的选择。注意有些类型的工具栏可以解除停靠变成调色板窗口，而调色板窗口可以移动、改变大小和自定义。

最后，考虑这个根本问题：与在可发现性、易学习性、效率及生产力方面的提升相比，使用选项卡组织命令所需的额外空间是否值得？如果值得，则使用 Ribbon 绝对是好的选择。如果你不能确定的话，可以考虑使用可用性测试来对基于 Ribbon 的设计和最佳的替换设计进行比较。

Ribbon 是一种新的迷人的命令呈现方式，也是程序现代化的重要方式。但与其绚丽的外表不同，它并非所有程序的最佳选择。

错误：

请不要这么做！

设计理念

将 Ribbon 应用于已有的程序

While you might simply refactor a traditional menu bar and toolbar design of an existing program to a Ribbon format, doing so misses most of the value of using a Ribbon. Ribbons have the most value when used to present immediate, results-oriented commands, often in the form of galleries and live previews. Results-oriented commands make commands easier to understand and users much more efficient and productive. Instead of refactoring your existing commands, it's better to redesign completely how commands are performed in your program.

Don't underestimate the challenge of creating an effective Ribbon. And don't take for granted that using a Ribbon automatically makes your program better. Creating an effective Ribbon takes a lot of time and effort. Being willing to commit the time and effort required for such a command redesign is an important factor in deciding to use a Ribbon.

For more information about migrating commands to a Ribbon in an existing program, see Ribbon Design Process.

Ribbon 的自然特性

Compared to traditional menu bars and toolbars, Ribbons have the following characteristics:

• A single user interface (UI) for all commands. Menu bars are comprehensive and easy to learn, and toolbars are efficient and direct, but why not use a bit more screen space to create a single commands UI that accomplishes all of these? With only one UI, Ribbons don't require users to figure out which UI has the command they are looking for.
• Visible and self-explanatory. Menu bar commands are self-explanatory through their labels, but are hidden from view most of the time. To save screen space, toolbar buttons are primarily represented by icons instead of labels (although some toolbar buttons use both), and depend on tooltips when the icon isn't self-explanatory. However, users generally know the icons only for the most commonly used commands.

By presenting most commands with labeled icons, Ribbon commands are both visible and self-explanatory, and use tooltips only to provide supplemental information. There's little need to go elsewhere (such as Help) to understand a command.

• Labeled grouping. While menu categories are labeled, groups within a drop-down menu are not and are indicated only with an unlabeled separator. Groups within toolbars are also indicated with unlabeled separators.

By organizing commands in labeled groups, Ribbons make it easier to find commands and determine their purpose.

• Modal but not hierarchical. Menu bars scale by creating a hierarchy of commands. Menus with many items can use one or more levels of submenus to provide more commands.

Ribbon commands require more space than toolbar commands, so they use tabs to scale. This use of tabs makes Ribbons modal, requiring users to change modes occasionally to find commands. However, within a tab most commands are either direct or use a single split button or menu button, not a hierarchy.

• Direct and immediate. A command is direct if invoked with a single click (that is, without navigating through menus) and immediate if it takes effect immediately (that is, without dialog boxes to gather additional input). Menu bar commands are always indirect and often not immediate. Like toolbars, most Ribbon commands are designed to be direct and immediate, with the most frequently used commands invoked with a single click, and without requiring a dialog to gather additional input.
• Spacious. Menu bars and toolbars are primarily designed to be space efficient. To provide their benefits, Ribbons may consume more vertical space, being roughly the equivalent of a menu bar plus three rows of toolbars. Being that few programs have three or more rows of toolbars, Ribbons usually consume more space than traditional UIs for commands.
• Has an Application button and Quick Access Toolbar. A Ribbon is always presented with an Application button and Quick Access Toolbar. Doing so allows users to access file-related and frequently used commands without changing tabs, and promotes consistency across programs.
• Minimal customization. While menu bars have a fixed presentation, many toolbars are quite customizable, allowing users to set locations, sizes, and contents. A Ribbon itself is not customizable, but the Quick Access Toolbar provides limited customization.
• Improved keyboard accessibility. Menu bars have excellent keyboard accessibility because pressing the Alt key directly gives the menu bar input focus. However, there is no such mechanism for toolbars because they share keyboard navigation with the window's content. Consequently, users must navigate to the toolbar using the Tab key (which is given the last tab stop), and then navigate to a specific command using the arrow keys.

By contrast, Ribbons provide enhanced keyboard accessibility through keytips, usually with a three-step process:

• 1. Press Alt to enter keytip mode.
  2. Press a character to choose a tab, the Application button, or a command in the Quick Access Toolbar.
  3. Within a tab, press a one or two letters to choose a command.

This approach is highly visual. It is also more flexible, allowing it to scale better and to have more mnemonic access key assignments.

不要把访问键与快捷键搞混。虽然访问键和快捷键都是为用户界面提供键盘访问，但他们具有不同的用途和设计规范。更多信息，参见键盘。

富命令的自然特性

Rich commands refer to the presentation and interaction of commands used by Ribbons, without necessarily using a Ribbon container. Rich commands have these characteristics:

• Labeling. All commands are given self-explanatory labels, with exceptions only when the icons are extremely well known and space is at a premium.

Correct:

These commands are extremely well known so they don't need labels.

Incorrect:

These unintelligible icons require labels for rich commands.

• Sizing. Instead of uniform sizing, commands are sized relative to their frequency of use and importance. In addition to making the most frequently used commands easier to find and click, it also makes them more touchable.

In this example, the most frequently used button is larger than the others.

• Dynamic sizing. Rich command controls resize themselves to take full advantage of the available space, as opposed to using a fixed size and either truncating or using overflow when the size is too small.

In this example, the command buttons resize to work well in the available space.

• Split buttons. Split buttons are a good way to consolidate a set of variations of a command when needed, while maintaining directness for the most frequently used command.

In this example, the Save As command uses a split button, where the main button performs the most common variation and the menu portion reveals a menu with variations of the command.

• Rich drop-down menus and galleries. Drop-down menus, drop-down lists, and galleries take the space they need to communicate and differentiate the effect of the choices, often using graphics and text descriptions. Categories are used to organize large sets of options.

In these examples, clicking a menu button displays a list of choices that show their effect.

• Live previews. Whenever the user hovers over a formatting option, the program shows what the results would look like with that formatting using the actual content.

Live previews show the results of applying a formatting option on hover.

• Enhanced tooltips. These concisely explain their associated commands and give the shortcut keys. They may also include graphics and references to Help (although they largely eliminate the need for command-related Help).

Enhanced tooltips concisely explain their associated commands.

While Ribbons might not be suitable for all programs, all programs can potentially benefit from rich commands.

Ribbon 总是包含应用程序按钮和快速访问工具栏

The Application button and Quick Access Toolbar provide commands that are useful in any context, thus reducing the need to change tabs. While these three components are logically independent, a Ribbon must always have an Application button and Quick Access Toolbar. Given that commands can go in either the Ribbon or the Application button, you might be wondering where to place commands. The choice is not arbitrary.

The Application button is used to present a menu of commands that involve doing something to or with a file, such as commands that traditionally go in the File menu to create, open, and save files, print, and send and publish documents.

By contrast, the Ribbon itself is for commands that affect the content of the window. Examples include commands used to read, modify, or use the content, or change the view.

If you use a Ribbon, you must also use an Application button even if your program doesn't involve documents or files. In such cases, use the Application button menu to present commands for printing, program options, and exiting the program. While arguably the Application button isn't necessary for such programs, using it provides consistency across programs. Users don't have to hunt for save and undo commands or program options because they are always in the same place.

The Quick Access Toolbar is required even if the Ribbon only uses one tab. Again, while arguably such programs don't need a Quick Access Toolbar (because all the commands are already present on the single tab), having a customizable Quick Access Toolbar provides consistency across programs. For example, if users are in the habit of clicking the Print command, they should be able to do so in any program that uses a Ribbon.

但应用程序按钮可以离开 Ribbon 单独使用

Some programs such as document viewers or browsers use files but have few commands that modify their content. Alternatively, they may have a few content-related commands that are better presented inline. In such cases, rather than use a menu bar, toolbar, or Ribbon with little or nothing in them, you can use an Application button for the file-related commands.

On the other hand, never combine an Application button with a menu bar or toolbar. Such combinations result in unnecessary inconsistency in command models.

Incorrect:

In this example, an Application button is used incorrectly to replace the File menu.

组织与可发现性

By providing tabs and groups, Ribbons allow you to organize your commands to aid discoverability. The challenge is that if the organization is done poorly, it can greatly harm discoverability instead. There should be a clear, obvious, and unique mapping between your commands and the descriptively labeled tabs and groups where they reside.

Users will form a mental model of the Ribbon after using it for a while. If that mental model doesn't make sense to users, is inefficient, or is incorrect, it will lead to confusion and frustration. Your most important goal in designing a Ribbon is to facilitate finding commands quickly and confidently. If you do not accomplish this, your Ribbon design will fail. Achieving this goal requires careful design, user testing, and iteration. Don't assume that it will be easy.

Here are some common pitfalls to avoid:

• Avoid generic tab and group names. A good tab or group name must accurately describe its specific contents, preferably using task- and goal-based language. Avoid generic tab and group names, as well as technology-based names. For example, almost any command in a document creating and authoring program could belong in tabs labeled Edit, Format, Tools, Options, Advanced, and More. Rely on specific, descriptive labels, not memorization.
• Avoid overly specific tab and group names. While we want tab and group names to be specific, they shouldn't be so specific that users are surprised by their content. Users often look for things using the process of elimination, so prevent them from overlooking your tabs or groups because the name is misleading.
• Avoid multiple paths to the same command—especially if the path is unexpected or the command requires many clicks to invoke. It may seem like a convenience to find a command through multiple paths. But keep in mind that when users find what they are looking for, they stop looking. It is all too easy for users to assume that the first path they find is the only path—which is a serious problem if that path is inefficient or unexpected. Furthermore, having duplicate commands makes it harder for users to find other commands they are scanning for.

In this example, you can change paragraph borders through the Page Borders command, even though there is a more direct path on the Home tab. If users looking for paragraph borders were to stumble across this unexpected path, they might easily assume that it's the only path.

• Avoid arbitrary command placement. Suppose that you think you have a good tab and group design, but discover that several commands just don't fit in. Chances are, your tab and group design isn't as good as you think it is, and you need to continue to refine it. Don't solve this problem by putting those commands where they don't belong. If you do, users likely will have to inspect every tab to find them—then promptly forget where they are.
• Avoid marketing-based placement. Suppose that you have a new version of your program and your marketing team really wants to promote its new features. It might be tempting to put them on the Home tab, but doing so is a costly mistake if it harms overall discoverability. Consider future versions of your product and how much frustration a constantly changing organization will cause.

选项卡

The best first step is to review the standard Ribbon tabs. If your program's commands map naturally into the standard tabs, base your tab organization on these standards. On the other hand, if you program's commands don't map naturally, don't try to force it. Determine a more natural structure, and be sure to perform a lot of user testing to make sure that you've got it right.

For non-standard tabs, consider these issues:

• Each tab name should describe its content. Choose meaningful names that are specific, but not too specific. Users should never be surprised by their content.
• Each tab name should reflect its purpose. Consider the goal or task associated with the commands.
• Each tab name should be clearly distinct from all the other tab names.

The Home tab is an exception to these considerations. While you don't have to have a Home tab, most programs should. The Home tab is the first tab, and contains the most frequently used commands. If you have frequently used commands that don't fit into the other tabs, the Home tab is the right place for them.

If you can't determine a meaningful, descriptive tab name, it is probably because the tab isn't well designed. If your Ribbon organization just isn't working, reconsider your tab design.

分组

Dividing commands into groups structures the commands into related sets. The group label explains the common purpose of its commands.

There are a variety of factors to consider when determining groups and their presentation:

• Standard grouping. While there are significant differences in commands across programs, there are standard groups that are common across many programs. Having these commands appear with the same names and similar locations greatly improves discoverability.

  Correct:		Incorrect:

  In the incorrect example, commands from two standard groups were merged into one non-standard group.
• Granularity. Some structure is good, but too much structure makes commands harder to find. If the group names are generic, you might not have enough granularity. If there are groups with only one or two commands each, you probably have too much (although having an in-Ribbon gallery without any other commands within a group is acceptable).

  Correct:		Incorrect:

  In the incorrect example, having groups with one or two commands is a sign of too much structure.
• Names. Good group names explain the purpose of their commands. If your group names don't, reconsider the name or the grouping.
  Incorrect:
  
  
  Correct:
  
  In the incorrect example, the group name is too vague to be helpful. A better approach would be to reorganize these commands into more specific groups.
• Order. People read in a left-to-right order (in Western cultures), so you might think that groups on the far left are the most noticeable. However, the highlighted tab name and the window content tend to act as focal points, so groups in the center of the tab usually receive more attention than the left-most group. Place the most commonly used groups in the most prominent locations, and make sure there is a logical flow for the groups across the tab.
  
  In this example, the Font and Paragraph groups are more noticeable than the Clipboard group, because they are what the eye sees first when moving up from the document.
  
  In this example, the Tracking group receives the most attention, in part because the highlighted Review tab acts as a focal point.
• Uniformity. It can be hard to recognize commands when the command presentation all looks the same. Using icons with different shapes and colors, groups with varying formats, and commands with different sizes makes it easier for users to recognize command groups. Commands should have uniform sizing only when the Ribbon is scaled down to its smaller sizes.

  Correct:		Incorrect:

  In the incorrect example, the commands look too similar to one another because they are all the same size.

If you can't determine a meaningful, descriptive name, it is probably because the group isn't well designed.

预览

You can use various types of previews to show what will result from a command. By using helpful previews, you can improve the efficiency of your program and reduce the need for the trial-and-error learning approach. Live previews also invite experimentation and encourage creativity.

Here are some of the different types of previews that you can use:

• Realistic static icons and graphics. Static images that give a realistic indication of a command's effect. These can be used in galleries, drop-down menus, and enhanced tooltips.
  
  In this example, the Font drop-down list shows each font name using the font itself.
  
  In this example, realistic thumbnails are used to show the different watermarks.
• Dynamic icons and graphics. Icons and graphics that are modified to reflect the current state. Such icons are especially useful for galleries, as well as split buttons that change their default effect to be the same as the last action.
  
  In this example, Microsoft Word changes the Styles gallery to reflect the current styles.
  
  In this example, Word changes the Text highlight color and Font color commands to indicate their current effect.
• Live previews. When users hover over a formatting option, live preview shows what the results would look like with that formatting. Live previews help users make selections more efficiently and confidently based on the user's actual context.
  
  In this example, the Page Color command performs a live preview by showing the effect of the color options on hover.

Live previews are a powerful feature that can really improve your users' productivity, but even simple static previews can be a big help.

Ribbon 缩放

Scaling a toolbar is simple: if a window is too narrow to display a toolbar, the toolbar displays what fits and makes everything else accessible through an overflow button.

Toolbars scale using an overflow button.

A goal of rich commands is to take full advantage of the available space, so scaling a Ribbon requires more design work. There is no default Ribbon size, so you should not design a Ribbon with a particular width in mind. You have to design layouts with a wide range of widths and realize that any one of them could be the one most of your users will see. Scaling is a fundamental part of Ribbon design, not the last step.

There is no default Ribbon size. The smallest size is a single pop-up group icon.

When designing a tab, specify the different layouts for each group (up to three) as well as the combinations that can be used together. The Ribbon will show the largest valid combination that fits the current window size.

If you do only seven things...

1. Choose a command solution that is suitable for your program type. Using a Ribbon should make a program feel simpler, more efficient, and easier to use—never the opposite. If using a Ribbon isn't appropriate, consider using rich commands instead.
2. Don't underestimate the challenge of creating an effective Ribbon. And don't take for granted that using a Ribbon automatically makes your program better. Being willing to commit the time and effort required for a command redesign is an important factor in deciding to use a Ribbon.
3. Make the commands discoverable. Choose a tab design that has a clear, obvious, unique mapping between your commands and the descriptively labeled tabs where they reside. Users should be able to determine quickly and confidently which tab has the command they are looking for, and rarely choose the wrong tab.
4. Make the commands self-explanatory. Users should understand the effect of a command from its label, icon, tooltip, and preview. They shouldn't have to experiment or read a Help topic to see how a command works.
5. Make using the commands efficient:
   • Users should spend most of their time on the Home tab.
   • Users should rarely have to change tabs during common tasks.
   • When the window is maximized and users are on the correct tab, the most frequently used commands have the most visual emphasis and users can invoke them with a single click. Users can perform all other commands on the tab with at most four clicks.
   • Users shouldn't have to open dialog boxes to give commands and change attributes in common tasks.
6. Help users choose commands and options confidently and minimize the need for trial-and-error. Use results-oriented commands whenever appropriate, often in the form of galleries and live previews.
7. Make sure the Ribbon scales well from the largest window sizes to the smallest.

注释与引用

1. ^ 根据 Microsoft Office 2007 简体中文版网站的相关说明，Gallery 被称为“库”。为避免歧义，本文将称其为 Gallery。
2. ^ 根据 Microsoft Office 2007 简体中文版的翻译，Home 选项卡被称为“开始”，为避免歧义，本文将称其为 Home 选项卡。