Menu Design Concepts
To use menus effectively, it helps to understand the characteristics of the various command presentations:
- Menu bars. A menu bar is best used to catalog all the available top-level commands within a program. New users of your program are likely to review all the commands in the menu bar to answer questions like:
- What can the program do?
- What commands does the program have?
- What are the shortcut keys for the common commands?
- Toolbars. A toolbar is best used for quick, convenient access to frequently used, immediate commands. They don't have to be comprehensive or even self-explanatory—just direct and efficient.
- Command buttons. Command buttons are a simple, visible, direct way to expose a small number of primary commands. However, they don't scale well, so you should use menus in primary windows for more than a few commands.
- Context menus. Context menus are simple, direct, and contextual. They are also efficient because they display only the commands and options that apply to the current context. Because they are displayed at the pointer's current location, they eliminate the need to move the mouse to display a menu. However, they normally have no visible presence on the screen. Consider context menus appropriate only for redundant contextual commands and options targeted at advanced users.
Because of these various tradeoffs, your program may need to use a combination of command presentations. For example, full-featured applications often use menu bars, taskbars, and context menus, whereas simple programs typically just use command buttons and standard context menus.
If you do only one thing...
Choose a command presentation that matches your program type, window types, command usage, and target users.
While menu bars are the most traditional menu type, they aren't suitable for all types of programs or windows. Here are some of the factors in using them effectively.
Keeping simple things simple
Menu bars aren't used in dialog boxes and should be avoided in simple programs like utilities. The commands in such windows should be kept simple, direct, and readily apparent. Menu bars are primarily a learning and discovery tool, and simple windows shouldn't require learning or discovery. For dialog boxes, use command buttons (including menu buttons and split buttons), command links, and context menus.
Using screen space efficiently
While menu bars use screen space efficiently, they are sufficiently heavy that you should consider alternatives if there aren't many commands or they aren't used frequently. For example, toolbar menus are a better choice if a program already has a toolbar and needs only a few drop-down menus.
Making menus stable
Given the need for learning and discoverability, users expect menu bars to be stable. That is, users expect to see the same menu items as they did the last time they used the menu. The menu items can be enabled or disabled based on the current context, but menu items or submenus shouldn't be added or removed. However, you may add or remove entire menu categories based on obvious changes in program state (such as a document being loaded).
That said, disabled menu items can be confusing because users have to determine why the item is disabled. If the reason isn't obvious, users have to determine the problem through experimentation and deductive logic. In such cases, it's better to leave the item enabled and give a helpful error message to explain the problem explicitly.
Menu bars organize menu items into a tree structure. However, there is a dilemma when using trees: Trees are intended to organize menu items and make them easy to find, yet it's difficult to make all menu items within a menu tree easily discoverable. Menu items that aren't well known or could belong in multiple menu categories are especially difficult to find. For example, suppose a menu has Debug and Window categories. Where should users look for a Debug window command?
Using the standard menu categories helps address this dilemma. For example, users know to look for an Exit command in the File menu because that is standard. If you know that users are having trouble finding non-standard menu items because they could belong in multiple categories, put a small number (one or two) of hard-to-find menu items in multiple categories. Anything more harms the overall menu bar usability.
The standard menu organization makes common menu items predictable and easier to find. However, these categories were designed when most applications were used to create or view document files, thus the File, Edit, View, Tools, and Help menu categories. This standard organization has little value for other types of programs, such as Windows Explorer.
Don't feel obligated to use the standard menu organization if it isn't suitable for your program. Instead, consider organizing your menu items into more useful, natural categories based on your program's purpose and the way users think about their tasks and goals.
If you choose to use non-standard menu categories, you have the burden of designing good category names. These names should use a single, specific word and they should accurately describe their contents. While the category 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.
However, if your program is primarily used to create or view documents, most likely you should use the standard menu organization. Don't interpret the fact that many built-in Windows applications no longer use standard menus to mean that standard menus have been abandoned. They have not. Rather, it means that there are more appropriate solutions for programs that aren't focused on document creation.
Many programs provide both a menu bar and a toolbar. There doesn't need to be an exact correspondence between menu bar commands and toolbar commands because the attributes of a good menu bar and a good toolbar differ.
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.
Focus on delivering the full benefit of each type of menu. Don't worry about consistency between the menu types.
For more information, see Toolbar Design Concepts.
Context menus, being contextual, differ from menu bars in the following ways:
- Context menus show items that apply only to the current context, so, in general, they don't have disabled items. Menu bars are intended to be more of a complete catalog of functionality, so they need to be comprehensive and stable.
- Context menus don't show shortcut keys (ironically) because they aren't intended to be a learning tool as menu bars are. Keep them simple and efficient.
- Context menus have a specific order: most frequently used items first (primary commands), transfer commands next, and Properties last. This order is for efficiency and predictability. By contrast, menu bar menus are ordered by the relationships among the commands, as well as frequency of use.
Menu bars lack affordance, which means their visual properties don't suggest how they are used. Rather, users understand menu bars through experience and identify them by their standard appearance and location.
The other menu patterns aren't as recognizable and don't have a standard location, so they use the drop-down arrow to indicate the presence of a pull-down menu. The need for this arrow might be a factor in your command presentation choices. If your program window is cluttered with menu arrows, consider using a menu bar.
Themed menus in Windows® give you the opportunity to provide icons for menu items. Providing icons has the following benefits:
- Icons emphasize the most commonly used menu items.
- Distinct icons help users recognize commonly used menu items quickly.
- Well designed icons help communicate the meaning of their menu items.
Deciding to use menu icons doesn't mean that you must have icons for all your menu items. In fact, icons have better effect if they are reserved for only the most important menu items.
Command icons are especially difficult to design because commands are actions (verbs), yet icons show objects (nouns). Consequently, most command icons are either standard symbols or images of objects that suggest the actions.
Menu items should be directly accessible using access keys and shortcuts. Doing so helps users who prefer the keyboard, including power users who want to work quickly.
Access keys and shortcut keys have several fundamental differences for menus:
- Are the underlined character in a menu name.
- Use the Alt key plus an alphanumeric key.
- Are primarily for accessibility.
- Are assigned to all menus.
- Are not intended to be memorized, so they are documented directly in the UI (by underlining the corresponding character).
- Aren't assigned consistently across menus (because they can't always be).
By contrast, shortcut keys:
- Use Ctrl and Function key sequences.
- Are primarily a shortcut for advanced users.
- Are assigned only to the most commonly used menu items.
- Are intended to be memorized and are documented only in menus, tooltips, and Help.
- Must be assigned consistently across programs (because they are memorized and not directly documented in the UI).
Tip: Access key underlines are usually hidden by default and shown when the Alt key is pressed. To improve awareness of the access key assignments in your program, you can display them at all times. In Control Panel, go to the Ease of Access Center, and click Make the keyboard easier to use; then select the Underline keyboard shortcuts and access keys check box.