Is this the right user interface?
Controls and commands
Organization and order
Hiding menu bars
Standard menu and split buttons
Recommended sizing and spacing
A toolbar is a graphical presentation of commands optimized for efficient access.
Some typical toolbars.
Use toolbars in addition to or in place of menu bars. Toolbars can be more efficient than menu bars because they are direct (always displayed instead of being displayed on mouse click), immediate (instead of requiring additional input) and contain the most frequently used commands (instead of a comprehensive list). In contrast to menu bars, toolbars don't have to be comprehensive or self-explanatoryâ€”just quick, convenient, and efficient.
Some toolbars are customizable, allowing users to add or remove toolbars, change their size and location, and even change their contents. Some types of toolbars can be undocked, resulting in a palette window. For more information about toolbar varieties, see Usage patterns in this article.
Note: Guidelines related to
command buttons, and
icons are presented in separate articles.
Is this the right user interface?
To decide, consider these questions:
- Is the window a primary window? Toolbars work well for
primary windows, but are usually overwhelming for
secondary windows. For secondary windows, use
menu buttons, and
- Are there a small number of frequently used commands? Toolbars can't handle as many commands as menu bars, so they work best as a way to efficiently access a small number of frequently used commands.
- Are most of the commands immediate? That is, are they mostly commands that don't require additional input? To be efficient, toolbars need to have a direct and immediate feel. If not, menu bars are better suited for commands that require additional input.
- Can most of the commands be presented directly? That is, users interact with them using a single click? While some commands can be presented using menu buttons, presenting most commands this way undermines the efficiency of the toolbar, making a menu bar a better choice.
- Are the commands well represented by icons? Toolbar buttons are usually represented by icons instead of text labels (although some toolbar buttons use both), whereas menu commands are represented by their text. If the command icons aren't high quality and aren't self-explanatory, a menu bar may be a better choice.
If your program has a toolbar without a menu bar, and most of the commands are accessible indirectly through menu buttons and
split buttons, this toolbar is essentially a menu bar. Apply the
toolbar menus pattern in the Menus guidelines instead.
A good menu bar is a comprehensive catalog of all the available top-level commands, whereas a good toolbar gives quick, convenient access to frequently used commands. A toolbar doesn't attempt to train usersâ€”just make them productive. Once users learn how to access a command on a toolbar, they rarely continue to access the command from the menu bar. For these reasons, a program's menu bar and its toolbar don't need to correspond directly.
Toolbars vs. menu bars
Traditionally, toolbars are different from menu bars in the following ways:
- Frequency. Toolbars present only the most frequently used commands, whereas menu bars catalog all the available top-level commands within a program.
- Immediacy. Clicking a toolbar command takes effect immediately, whereas a menu command might require additional input. For example, a Print command in a menu bar first displays the Print dialog, whereas a Print toolbar button immediately prints a single copy of a document to the default printer.
In this example, clicking the Print toolbar button immediately prints a single copy of a document to the default printer.
- Directness. Toolbar commands are invoked with a single click, whereas menu bar commands require navigating through the menu.
- Number and density. The screen space required by a toolbar is proportional to the number of its commands and that space is always used, even if the commands are not. Consequently, toolbars must use their space efficiently. By contrast, menu bar commands are normally hidden from view and their hierarchical structure allows for any number of commands.
- Size and presentation. To pack many commands in a small space, toolbars usually use icon-based commands (with tooltip-based labels), whereas menu bars use text-based commands (with optional icons). While toolbar buttons can have standard text labels, these do use significantly more space.
Labeled toolbar buttons take at least three times as much space as unlabeled ones.
- Self-explanatory. Well-designed toolbars need icons that are mostly self-explanatory because users can't find commands efficiently just using tooltips. However, toolbars still work well if a few less frequently used commands aren't self-explanatory.
In this example, the most frequently used icons are self-explanatory.
- Recognizable and distinguishable. For frequently used commands, users remember toolbar button attributes like location, shape, and color. With well-designed toolbars, users can find the commands quickly even if they don't remember the exact icon symbol. By contrast, users remember frequently used menu bar command locations, but rely on the command labels for making selections.
For toolbar commands, distinctive location, shape, and color help make icons recognizable and distinguishable.
For menu bar commands, users ultimately depend upon their labels.
Given their characteristics, toolbars must be designed primarily for efficiency. An inefficient toolbar just doesn't make any sense.
If you do only one thing...
Make sure your toolbars are designed primarily for efficiency. Focus toolbars on commands that are frequently used, immediate, direct, and quickly recognizable.
Hiding menu bars
Generally, toolbars work great together with menu bars: good toolbars provide efficiency and good menu bars provide comprehensiveness. Having both menu bars and toolbars allows each to focus on its strengths without compromise.
Surprisingly, this model breaks down with simple programs. For programs with only a few commands, having both a menu bar and a toolbar doesn't make sense because the menu bar ends up being a redundant, inefficient version of the toolbar.
To eliminate this redundancy, many simple programs in Windows Vista® focus on providing commands solely through the toolbar, and hiding the menu bar by default. Such programs include Windows Explorer, Windows® Internet Explorer®, Windows Media® Player, and Windows Photo Gallery.
This is no small change. Removing the menu bar fundamentally changes the nature of toolbars because such toolbars need to be comprehensive and change in the following ways:
Toolbars used to supplement a menu bar are designed differently than toolbars designed for use with a removed or hidden menu bar. And because you can't assume that users will display a hidden menu bar to perform a single command, hiding a menu bar should be treated the same as removing it completely when making design decisions. (If you hide the menu bar by default, don't assume that users will think of displaying the menu bar to find a command or even figure out how to display it.)
Designing a toolbar to work without a menu bar often involves some compromises. But for efficiency, don't compromise too much. If hiding the menu bar results in an inefficient toolbar, don't hide the menu bar!
From the keyboard, accessing toolbars is quite different from accessing menu bars. Menu bars receive input focus when users press the Alt key and they lose input focus with the Esc key. Once a menu bar has input focus, it is navigated independently of the remainder of the window, handling all arrow keys, Home, End, and Tab keys. By contrast, toolbars receive input focus when users press the Tab key through the entire contents of the window. Because toolbars are last in tab order, they might take some significant effort to activate on a busy page (unless users know to use Shift+Tab to move backwards).
Accessibility presents a dilemma here: while toolbars are easier for mouse users, they are less accessible for keyboard users. This isn't a problem if there is both a menu bar and a toolbar, but it is if the menu bar is removed or hidden.
For accessibility reasons, then, prefer to retain the menu bar rather than remove it completely in favor of a toolbar. If you must choose between removing the menu bar and simply hiding it, prefer to hide it.
Toolbars have several usage patterns:
A toolbar designed to work without a menu bar, either hidden or removed.
Primary toolbars must balance the need for efficiency with comprehensiveness, so they work best for simple programs.
A primary toolbar from Windows Explorer.
A toolbar designed to work with a menu bar.
Supplemental toolbars can focus on efficiency without compromise.
A supplemental toolbar from Windows Movie Maker.
A menu bar implemented as a toolbar.
Toolbar menus are toolbars consisting primarily of commands in
menu buttons and
split buttons, with only a few direct commands, if any.
A toolbar menu in Windows Photo Gallery.
A toolbar that can be customized by users.
Customizable toolbars allow users to add or remove toolbars, change their size and location, and even change their contents.
A customizable toolbar from Microsoft Visual Studio®.
A modeless dialog box that presents an array of commands.
Palette windows are undocked toolbars.
Palette windows from Windows Paint.
Toolbars have these styles:
One or more rows of small unlabeled icon buttons.
Use this style if there are too many buttons to label or the program is frequently used. With this style, programs with complex functionality can have multiple rows, and therefore, this is the only style that needs to be customizable. With this style, some command buttons can be labeled if they are frequently used.
An unlabeled icons toolbar from WordPad.
|Large unlabeled icons|
A single row of large unlabeled icon buttons.
Use this style for simple utilities that have easily recognizable icons and are usually run in small windows.
Large unlabeled icons toolbars from Windows Live Messenger and the Windows Snipping Tool.
A single row of small labeled icons.
Use this style if there are few commands or the program isn't frequently used. This style always has a single row.
A labeled icons toolbar from Windows Explorer.
A partial row of small icons used to save space when a full toolbar isn't necessary.
Use this style for windows with navigation buttons, a search box, or tabs to eliminate unnecessary weight at the top of the window.
Partial toolbars can be combined with navigation buttons, a search box, or tabs.
|Large partial toolbars|
A partial row of large icons used to save space when a full toolbar isn't necessary.
Use this style for simple utilities that have navigation buttons or a search box to eliminate unnecessary weight at the top of the window.
A large partial toolbar from Windows Defender.
Finally, toolbar controls have several usage patterns:
|Command icon buttons|
Clicking a command button initiates an immediate action.
Examples of icon command buttons from Windows Fax and Scan.
|Mode icon buttons|
Clicking a mode button enters the selected mode.
Examples of mode buttons from Windows Paint.
|Property icon buttons|
A property button's state reflects the state of the currently selected objects, if any. Clicking the button applies the change to the selected objects.
Examples of property buttons from Microsoft Word.
|Labeled icon buttons|
A command button or property button labeled with an icon and a text label.
These buttons are used for frequently used toolbar buttons whose icon isn't sufficiently self-explanatory. They are also used in toolbars that have so few buttons that each button can have a text label.
A toolbar with its most frequently used buttons labeled.
A command button used to present a small set of related commands.
A single downward-pointing triangle indicates that clicking the button shows a menu.
A menu button with a small set of related commands.
A command button used to consolidate variations of a command, especially when one of the commands is used most of the time.
A split button in its normal state.
Like a menu button, a single downward-pointing triangle indicates that clicking the rightmost portion of the button shows a menu.
A dropped down split button.
In this example, a split button is used to consolidate all the print-related commands. The immediate Print command is used most of the time, so users normally don't need to see the other commands.
Unlike a menu button, clicking the left portion of the button performs the action on the label directly. Split buttons are effective in situations where the next command is likely to be the same as the last command. In this case, the label is changed to the last command, as with a color picker:
In this example, the label is changed to the last command.
A drop-down list (editable or read-only) used to view or change a property.
In this example, drop-down lists are used to view and set font attributes.
A drop-down list in a toolbar reflects the state of the currently selected object, if any. Changing the list changes the selected object's state.
- Choose a suitable toolbar style based on the number of commands and their usage. See the previous toolbar style table for guidance on how to choose. Avoid using a toolbar configuration that takes too much space from the program work area.
- Place toolbars just above the content area, below the menu bar and address bar, if present.
- If space is at a premium, save space by:
- Omitting the labels of well-known icons and less frequently used commands.
- Using only a partial toolbar instead of the entire window width.
- Consolidating related commands with a menu button or split button.
- Using an
overflow chevron to reveal less frequently used commands.
- Displaying commands only when they apply to the current context.
The Windows Internet Explorer toolbar saves space by omitting labels of well-known icons, using a partial toolbar, and using an overflow chevron for less frequently used commands.
- For the unlabeled icons toolbar pattern, use a default configuration with no more than two rows of toolbars. If more than two rows might be useful, make the toolbars customizable. Starting with more than two rows can overwhelm users and take too much space from the program work area.
A default configuration with more than two rows of toolbars results in too much visual clutter.
- Disable individual toolbar buttons that don't apply to the current context, instead of removing them. Doing so makes toolbar contents stable and easier to find.
- Disable individual toolbar buttons if clicking on them would directly result in an error. Doing so is necessary to maintain a direct feel.
- For the unlabeled icons toolbar pattern, remove entire toolbars if they don't apply to the current context. Display them only in the applicable modes.
In this example, the Debug toolbar is shown only when the program is being run.
- Display toolbar buttons left aligned. The Help icon, if present, is right aligned.
All toolbar buttons are left aligned except for Help.
Exception: Windows 7-style toolbars left align program specific commands, but right align standard, well-known commands such as Options, View, and Help.
- Don't change toolbar button labels dynamically. Doing so is confusing and unexpected. However, you can change the icon to reflect the current state.
In this example, the icon is changed to indicate the default command.
Controls and commands
- Prefer the most frequently used commands.
- For primary toolbars, provide comprehensive commands. Primary toolbars don't have to be as comprehensive as menu bars, but they have to provide all the commands that aren't readily discoverable elsewhere. Primary toolbars don't need to have commands for:
- Commands that are directly on the UI itself.
- Commands typically accessed through context menus.
- Standard, well-known commands like Cut, Copy, and Paste.
- For supplemental toolbars, provide commands that are used the most frequently.
Menu bar commands are a superset of the toolbar commands, so you don't have to provide everything. Focus on quick, convenient command access and skip the rest.
- Prefer direct controls. Use toolbar buttons in the following order of preference:
- Icon button. Direct and takes minimal space.
- Labeled icon button. Direct, but takes more space.
- Split button. Direct for the most common command, but handles command variations.
- Menu button. Indirect, but presents many commands.
- Prefer immediate commands. For commands that can either be immediate or have additional input for flexibility:
- For primary toolbars, use the flexible versions of commands, (such as Print...).
- For supplemental toolbars, use the immediate versions in the toolbar (such as Print) and use flexible versions in the menu bar (such as Print...).
- Provide labels for frequently used commands, especially if their icons aren't well-known icons.
The Windows Fax and Scan toolbar has few commands, so the better version labels the most important ones.
- Don't put commands in toolbar menus that are also directly on the toolbar.
In this example, Print is directly on the toolbar, so it doesn't need to be in the menu.
Organization and order
- Organize the commands within a toolbar into related groups.
- Place the most frequently used groups first. Within a group, put the commands in their logical order. Overall, the commands should have a logical flow to make them easy to find, while still having the most frequently used commands appear first. Doing so is most efficient, especially if there is overflow.
- Use group dividers only if the commands across groups are weakly coupled. Doing so makes the groupings obvious and the commands easier to find.
Examples of grouped toolbars from Windows Mail.
- Avoid placing destructive commands next to frequently used commands. Use either order or grouping to get separation. Also, consider not placing destructive commands in the toolbar, but only in the menu bar or context menus instead.
In the better example, the Delete command is physically separated from Print.
- Use the overflow chevron to indicate that not all commands can be displayed. But use overflow only if there isn't sufficient room to display all the commands.
The overflow chevron indicates that not all commands are displayed, but more of them could be with a better layout.
- Make sure that the most frequently used commands are directly accessible from the toolbar (that is, not in overflow) in small window sizes. If necessary, reorder the commands, move less frequently used commands to menu buttons or split buttons, or even remove them completely from the toolbar. If this remains a problem, reconsider your choice of toolbar style.
Hiding menu bars
Generally, toolbars work great together with menu bars because having both allows each to focus on their strengths without compromise.
- Hide the menu bar by default if your toolbar design makes having a menu bar redundant.
- Hide the menu bar instead of removing it completely, because menu bars are more accessible for keyboard users.
- To restore the menu bar, provide a Menu bar checkmark option in the View (for primary toolbars) or Tools (for secondary toolbars) menu category. For more information, see
Standard menu and split buttons.
- Display the menu bar when users press the Alt key, and set input focus on the first menu category.
For more information and examples, see
Standard menu and split buttons
If you are using menu buttons and split buttons in a toolbar, try to use the following standard menu structures and their relevant commands whenever possible. Unlike menu bars, toolbar commands don't take access keys.
These commands mirror the commands found in standard menu bars, so they should be used only for primary toolbars. This list shows the button labels (and type) with their order and separators, shortcut keys, and ellipses. Note that the command for displaying and hiding the menu bar is in the View menu.
Exit Alt+F4 (shortcut usually not given)
Edit (menu button)
Select all Ctrl+A
Delete Del (shortcut usually not given)
Find next F3 (command usually not given)
Go to... Ctrl+G
Print (split button)
View (menu button)
Menu bar (check if visible)
Details pane (check if visible)
Preview pane (check if visible)
Status bar (check if visible)
Zoom in Ctrl++
Zoom out Ctrl+-
Text size (selected setting has bullet)
Full screen F11
Tools (menu button)
Help (split button, use the Help icon)
<program name> help F1
About <program name>
These commands supplement standard menu bars. This list shows the button labels (and type) with their order and separators, shortcut keys, and ellipses. Note that the command for displaying and hiding the menu bar is in the Tools menu.
The supplemental toolbar category names differ from the standard menu category names because they need to be more encompassing. For example, the Organize category is used instead of Edit because it contains commands that aren't related to editing. To maintain consistency between menu bars and toolbars, use the standard menu category names if doing so wouldn't be misleading.
In this example, the toolbar should use Edit instead of Organize for consistency because it has the standard Edit menu commands.
While toolbar commands are used for immediate actions, sometimes more information is needed to perform the action. Use an ellipsis to indicate that a command requires more information before it can take effect. Put the ellipsis at the end of the tooltip and label, if there is one.
In this example, the Print... command displays a Print dialog box to gather more information.
If a command cannot take effect immediately, however, no ellipsis is required. So, for example, sharing settings doesn't have an ellipsis even though it needs additional information, because the command can't possibly take effect immediately.
The Sharing Settings command doesn't have an ellipsis because it can't take effect immediately.
Because toolbars are constantly displayed, and space is at a premium, ellipses should be used infrequently.
Note: For menus displayed by a toolbar, apply the
menu ellipses guidelines.
Recommended sizing and spacing
Recommended sizing and spacing for standard toolbars.
Unlabeled icon buttons
Labeled icon buttons
- If the list always has a value, use the current value as the label.
In this example, the currently selected font name acts as the label.
- If an editable drop-down list doesn't have a value, use a
In this example, a prompt is used for the drop-down list's label.
Menu buttons and split buttons
- Prefer verb-based menu button names. However, omit the verb if it is Create, Show, View, or Manage. For example, Tools and Page menu buttons don't have verbs.
- Use a single, specific word that clearly and accurately describes the menu contents. While the names don't have to be so general that they describe everything in the menu, they should be predictable enough so that users aren't surprised by what they find in the menu.
- While not required, provide infotip descriptions if they are helpful.
- Use menu item names that start with a verb, noun, or noun phrase.
- Prefer verb-based menu names. However, omit the verb if it is Create, Show, View, or Manage. For example, the following commands don't use verbs:
- Full screen
- Use specific verbs. Avoid generic, unhelpful verbs, such as Change and Manage.
- Use singular nouns for commands that apply to a single object, otherwise use plural nouns.
- For pairs of complementary commands, choose clearly complementary names. Examples: Add, Remove; Show, Hide; Insert, Delete.
- Choose menu item names based on user goals and tasks, not on technology.
- Use the following menu item names for the stated purpose:
- Options: To display program options.
- Customize: To display the program options specifically related to mechanical UI configuration.
- Personalize: To display a summary of commonly used
- Preferences: Don't use. Use Options instead.
- Properties: To display an object's property window.
- Settings: Don't use as a menu label. Use Options instead.
- Menu items that display submenus never have an ellipsis on their label. The submenu arrow indicates that another selection is required.
When referring to toolbars:
- If there is only one toolbar, refer to it as the toolbar.
- If there are multiple toolbars, refer to them by name, followed by the word toolbar. Refer to the main toolbar that is on by default and contains buttons for basic tasks, such as opening and printing a file, as the standard toolbar.
- Toolbar is a single, uncapitalized word. (By contrast, menu bar is two words.)
- Refer to toolbar buttons by their tooltip labels. Use the exact label text, including its capitalization, but don't include any ellipsis.
- Refer to toolbar menu buttons by their labels and the word menu. Use the exact label text, including its capitalization.
- Refer to toolbar controls generally as toolbar buttons.
- To describe user interaction, use click for toolbar buttons and read-only drop-down lists, and enter for editable drop-down lists. Don't use choose, select, or pick.
- Don't use cascading, pull-down, drop-down, or pop-up to describe menu buttons, except in programming documentation.
- Refer to unavailable items as unavailable, not as dimmed, disabled, or grayed. Use disabled in programming documentation.
- When possible, format the labels using bold text. Otherwise, put the labels in quotation marks only if required to prevent confusion.
- On the Page menu on the toolbar, click Send page by e-mail.
- In the Fonts box on the toolbar, enter "Segoe UI."
- On the Formatting toolbar, point to Show, and then click Comments.