A toolbar (which is often combined with a title bar) gives users convenient access to the most frequently used commands and features in an app. For example, the default Mail toolbar includes the commands people use most often as they view, compose, and manage their email.
A toolbar can blur the scrolling content that appears behind it, giving users a greater sense of depth and context. (You automatically get this blurring behavior when you place a scroll view adjacent to a toolbar or a title bar; to get this behavior in other scenarios, you can use
NSFullSizeContentViewWindowMask.) To learn about the style of controls that are appropriate for a toolbar, see Some Controls Can Be Used in the Window Frame.
Users often rely on the presence of a toolbar, but you can hide it in a full-screen window if users don’t need it to accomplish the focused task. For example, Preview hides the toolbar in a full-screen window because users are more likely to be focused on reading content than on annotating it. If you hide the toolbar in a full-screen window, users should be able to reveal it (along with the menu bar) when they move the pointer to the top of the screen.
Create toolbar items that represent the functionality users need most often. To help you decide which items to include in your toolbar, consider the user’s mental model of the task they perform in your app (to learn more about the mental model, see Mental Model).
Arrange toolbar items so that they support the main task that users accomplish in your app. In general, use the leading end of the toolbar for commands that should have the highest visibility. (In a localized version of your app, the leading end of the toolbar might be on the right or the left.) “High visibility” can mean different things in different apps. In some apps, for example, frequency of use should determine visibility; in other apps, it makes more sense to rank items according to importance, significance, or their place in an object hierarchy. The figure below illustrates three possible ways to arrange toolbar items.
If appropriate, separate toolbar items into subsets and then arrange the subsets according to importance. Sometimes, you can define logical subsets of your app’s features and objects, such as one subset of document manipulation commands and another subset of commands for manipulating page-level objects such as paragraphs, lists, and tables. When you define subsets, you can arrange the items in each subset according to importance or frequency of use, and then use the same criteria to position each subset in the toolbar.
The default Keynote toolbar is an example of this type of arrangement. Keynote groups items according to functionality and then positions the groups so that the items that handle slide decks and slides are to the left of items that provide inspection and selection of object attributes. You can see about half of these groups in this toolbar.
Use window-frame controls in a toolbar. Standard controls look bad on the toolbar background, whether it’s translucent or opaque. Instead, use the controls that have been specifically designed for use in toolbars, such as the round textured button (shown here used for the Quick Look button in the Finder toolbar). To learn more about the controls you can use in a toolbar, see Some Controls Can Be Used in the Window Frame.
Avoid mixing icon buttons with toolbar controls in a toolbar. Toolbars look best, and are easiest for users to understand, when they contain controls of the same type. If you want to use freestanding icons instead of controls in a toolbar, use
Ensure that your toolbar controls clearly communicate their meaning to users. It’s best when users can tell what a toolbar control does without experimentation (or waiting to see a help tag). You can use system-provided images in your toolbar controls to represent a wide range of common commands and features, such as the Action menu and Quick Look. Users are familiar with the meanings of these items, and using them frees you from having to design custom images. (For more information about the system-provided images you can use, see System-Provided Images.)
Avoid displaying a persistent selected appearance for a toolbar item. An immediate action occurs when the user clicks a toolbar item—such as opening a new window, switching to a different view, displaying a menu, or inserting (or removing) an object—so it doesn’t make sense to imply that there is also a change in state. The exception to this is a segmented control that shows a persistent selected appearance within the context of the control, such as the view controls in the Finder toolbar.
Make every toolbar item available as a menu command. Because users can customize the toolbar (and it can be hidden under some circumstances), the toolbar should not be the only place to find a command.
It’s important to emphasize that the converse of this guideline is not true. That is, you don’t create a toolbar item for every menu command, because not all commands are important enough (or used frequently enough) to warrant inclusion in a toolbar.
In general, allow users to show or hide the toolbar. Users might want to hide the toolbar to minimize distractions or reveal more of their content. (Note that you can cause the toolbar to hide automatically in a full-screen window.) The commands for showing and hiding the toolbar belong in the View menu. For more information about this menu, see The View Menu.
In general, let users customize the toolbar. Although the default toolbar should include the commands that most users want, you should let users customize this set of commands to support their individual working styles. In addition, users should be able to specify whether toolbar items are displayed as controls only, text only, or controls with text (by default, display both controls and text). Place the Customize Toolbar command in the View menu (for more information about this menu, see The View Menu). Although you can also allow users to adjust the size of toolbar items, most users don’t expect this capability (if you decide to do this, you must supply different sizes of toolbar icons).
You can also enable a contextual menu that’s revealed when users Control-click the toolbar itself. In this menu, users can choose to customize the appearance and contents of the toolbar in various ways.
Avoid putting an app-specific contextual menu in your toolbar. Users reveal the contextual toolbar customization menu by Control-clicking in the toolbar. Additionally, in document windows, users can reveal the document path menu by Control-clicking the window title. The presence of these two menus doesn’t leave any areas in the toolbar that users could Control-click to reveal a third contextual menu. If you need to offer a set of commands that act upon an object the user selects, use an Action menu control instead. This item is described in Action Menu.
Enable click-through for toolbar items when appropriate. Click-through enables the user to activate the item when the containing window is inactive. You can support click-through for any subset of toolbar items. In general, you want to allow click-through for nondestructive actions that users might want to perform when they’re focused on a task in a different window.
Avoid combining text and images within a toolbar control. A toolbar button can contain either text or an image. And, although each segment in a segmented toolbar control can contain either text or an image, it’s best to avoid combining text segments with image segments in the same segmented control.
Interface Builder makes it easy to add one of the system-provided images to a toolbar control, such as the plus sign, the accounts symbol, or the locked symbol. Some of these symbols are shown here in the controls in the Finder toolbar. For more information about the system-provided images, see System-Provided Images. If you need to design your own image to place in a toolbar control, see Toolbar Items for some metrics and guidelines.
If you want to display text inside a toolbar control, be sure it’s either a noun (or noun phrase) that describes an object, setting, or state, or that it’s a verb (or verb phrase) that describes an action. Text inside toolbar controls should have title-style capitalization. For more on this style, see Use the Right Capitalization Style in Labels and Text.
Accurately indicate the current state of a two-state control in a toolbar. If you use a toolbar control that behaves like a checkbox or a toggle button, you may be able to benefit from the automatic highlighting that signifies the On state of the control. If you do this, be very sure that the control clearly indicates the correct state in the correct situation.
If you put a two-state control in a toolbar, also provide two descriptive labels that can be displayed below the control. One label should describe the On (or pressed) state, and one should describe the Off (or unpressed) state. Finally, be sure to describe both of the states in the control’s help tag, whether the control appears in a toolbar or a bottom bar.
For example, Mail includes a toggled toolbar button that users can use to take their accounts online or offline (shown here in its pressed state). The Go Offline label that accompanies the pressed state changes to Go Online when the control is in its unpressed state.