Ribbons - Win32 apps, Hacker News

(/ /

minutes to read

(Direct and immediate.) 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. 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:

Press Alt to enter keytip mode.

Press a character to choose a tab, the Application button, or a command in the Quick Access Toolbar.

Within a tab, press a one or two letters to choose a command.

Don’t confuse access keys with shortcut keys. While both access keys and shortcut keys provide keyboard access to UI, they have different purposes and guidelines. For more information, see Keyboard .

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. 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.

Ribbons always have an Application button and Quick Access Toolbar

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.

Organization and discoverability

Users will form a mental model of the ribbon after using it for a while. If that mental model does 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. 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 overal l discoverability. Consider future versions of your product and how much frustration a constantly changing organization will cause.

Tabs

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.

Groups

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.

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).

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

screen shot of format group with several commands

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.

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

Add a new tab if:

Its commands are mostly unrelated to tasks on other tabs. Adding the tab shouldn’t require more tab switching during commonly performed tasks.
The tab has enough commands to justify having an extra place to look. Don’t have tabs with only a few commands. Exception:

Consider adding a tab with a few commands if they are strongly related to a specific task and adding the tab greatly simplifies an overly complex Home tab.

Generally, having fewer tabs is better, so remove tabs that don’t help achieve these goals.
For the remaining tabs, place the most frequently used tabs first, while maintaining a logical order across the tabs.
Optimize the tab design so that users find commands quickly and confidently. All other considerations are secondary.
(Don’t provide a Help tab.) Instead, provide assistance using program-wide Help and enhanced tooltips.
(Use a maximum of seven core tabs.) If there are more than seven, it becomes difficult to determine which tab has a command. While seven core tabs is acceptable for applications with many commands, most programs should aim for four or fewer tabs.

for tab labeling guidelines, see (Tab labels) . Contextual tabs

Use a contextual tab to display a collection of commands that are relevant only when users select a particular object type. If there are only a few, frequently used commands, it may be more convenient and more stable to use a regular tab, and simply disable commands when they don’t apply.

It’s better to disable common commands like Cut and Copy than to use a contextual tab.

(Include only the commands that are specific to a particular object type.) Don’t put commands only on a contextual tab if users might need them without first selecting an object.

Include the commands frequently used when working with a particular object type. Put frequently used general contextual commands on context menus and mini-toolbars to avoid tab switching during commonly performed tasks. Alternatively, consider putting general commands redundantly on a contextual tab if doing so avoids frequent tab switching. But don’t overdo this – don’t try to include every command that a user might need while working with the object.

)

In this example, the Borders command is included on the Design tab to avoid frequent tab switching during commonly performed tasks.

Choose a contextual tab color that is different from the currently displayed contextual tabs.

The same tab set can appear at a later time using a different color in order to achieve this, but try to use consistent color assignments across invocations whenever possible.

Select a contextual tab automatically when:
The user selected a contextual tab, clicked off the object, then immediately clicked an object of the same type. In this case, return to the previously selected contextual tab.