出自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 应用于已有的程序

尽管你可以仅仅简单地将一个现有程序的传统菜单栏和工具栏设计重组为 Ribbon 形式，但这么做会损失 Ribbon 能够带来的的大部分价值。Ribbon 在用于呈现即时性的、结果导向的命令时最有价值，这往往出现在 Gallery 和实时预览形式中。结果导向命令可以使得命令更容易理解，使用起来更加方便高效。因此，最好是对你的程序执行命令的方式进行完全重设计，而非简单地重组现有的命令。

不要把创建高效的 Ribbon 想得过于简单，也不要觉得只要用了 Ribbon 你的程序就会一下子变得好用。创建高效的 Ribbon 是需要大量的时间和精力的，对于这种命令重新设计来说，是否愿意投入时间和精力是是否要使用 Ribbon 的重要考虑因素。

更多关于将现有程序的命令移植至 Ribbon 的信息，参见 Ribbon 设计流程。

Ribbon 的自然特性

与传统的菜单栏和工具栏相比，Ribbon 具有以下特性：

• 用于所有命令的单一用户界面（UI）。菜单栏内容全面且易于学习，工具栏则高效直接，可为什么不能稍稍多花一点屏幕空间来创建一个能够实现全部这些目标的单一命令 UI 呢？由于 Ribbon 只有一个 UI，用户不需要研究到底他们需要的命令在哪个 UI 上。
• 可视性与自说明性。菜单栏命令是通过其标签实现自说明性的，但大部分时间是看不到的。为了节约屏幕空间，工具栏按钮主要是通过图标来呈现，没有标签（虽然有些工具栏按钮两者俱有），如果图标自身含义不明确的话就只能靠工具提示。不过，用户通常只了解那些最常用命令的图标。

通过将大多数命令用带标签的图标呈现，Ribbon 命令兼顾了可视性与自说明性，工具提示仅用于提供辅助信息。很少需要为了理解一个命令而转至别处（比如帮助）。

• 带标签的分组。尽管菜单分类是有标签的，但下拉菜单中的分组并没有标签，仅通过分隔条隔开。工具栏上的分组也只是通过不带标签的分隔条来定义的。

通过将命令用带标签的分组来组织，Ribbon 中的命令更加易于查找，其用途也更加明确。

• 模式化但非层级化。菜单栏通过命令层次结构来适应不同的命令数量规模。具有大量菜单项的菜单可以使用一级或多级子菜单来提供更多的命令。

Ribbon 命令占用的空间比工具栏命令多，它通过选项卡来适应不同的命令数量规模。这种选项卡的用法使得 Ribbon 具有模式化的特点，偶尔用户需要切换模式来寻找命令。不过，单个选项卡中的大部分命令都是直接命令，或者是一个分割按钮或菜单按钮，而非层级化的命令。

• 直接性和即时性。如果激发一个命令只需要一次单击的话（也就是说，不需要在菜单中寻找），这个命令就是直接的；而如果立即就可以生效（而不需要对话框来收集其他信息）的话，那么它就是即时的。与工具栏类似，大部分 Ribbon 命令都被设计为直接且即时的，最常使用的命令只需一次单击即可触发，也不需要对话框用于额外的输入。
• 体积较大。菜单栏和工具栏主要是为了节约空间而设计的。Ribbon 为了提供其优点，可能会占用更多的垂直屏幕空间，大约与菜单栏加上三排工具栏的大小相当。由于很少有程序需要三排以上的工具栏，Ribbon 通常比传统命令 UI 占用的屏幕空间更多。
• 具有应用程序按钮和快速访问工具栏。Ribbon 始终于应用程序按钮和快速访问工具栏一起呈现。这使得用户无须切换选项卡即能快速访问与文件相关的命令及常用命令，并且提高了不同程序间的一致性。
• 最小可定制性。虽然菜单栏的呈现是固定不变的，但许多工具栏是能够定制的，用户能够设定其位置、大小以及内容。Ribbon 本身是不可定制的，但快速访问工具栏提供了有限的定制能力。
• 改进的键盘可访问性。菜单栏具有极好的键盘可访问性，因为按下 Alt 键即可直接将焦点转移至菜单栏。但是，工具栏则不存在类似的机制，因为它们与窗口内容共享键盘导航。在此，用户必须通过 Tab 键导航至工具栏（通常 Tab 顺序是排在最后的），然后再通过箭头键移至所需的命令。

相比而言，Ribbon 则通过 Keytip 提供了增强的键盘可访问性，通常为以下三步：

1. 按下 Alt 进入 Keytip 模式。
2. 按下一个字符以选择选项卡、应用程序按钮或是快速访问工具栏中的命令。
3. 在选项卡中，按下一个或两个字母以选择一个命令。

这种方法是高度可视化的。而且也更加灵活，分配多个助记访问键使得它可以更好地适应不同的命令数量规模。

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

富命令的自然特性

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 选项卡。