macos:Designing-the-elements-of-menus
出自UXGuide.net
Designing the Elements of Menus
目录 |
Menu elements include words (and sometimes icons) to designate menu titles and menu items, and symbols to designate keyboard shortcuts, hierarchical menus, separators, and the state of some menu items. These elements are illustrated in Figure 13-3.
Figure 13-3 Menu elements
Titling Menus
Menu (and submenu) titles should appropriately represent the items in the menu. For example, a Font menu could contain names of font families, such as Helvetica and Geneva, but it shouldn’t include editing commands, such as Cut and Paste. Avoid using icons for menu titles. Make menu titles as short as possible without their losing clarity.
Naming Menu Items
Menu item names should be either actions performed on an object or attributes applied to an object:
- Actions are verbs or verb phrases that declare the action that occurs when the user chooses the item. For example, Save means save my file and Copy means copy the selected data. Your action menu commands should begin in the same way, with an action verb in its base (simplest) form.
- Attributes are adjectives or adjective phrases that describe the change the command implements. Adjectives in menus imply an action and should fit into the sentence “Change the selected object to …” —for example, Bold or Italic.
When a menu item is unavailable—because it doesn’t apply to the selected object or to the selected object in its current state, or because nothing is selected, for example—the item should appear dimmed (gray) in the menu and is not highlighted when the user moves the pointer over it.
Use title-style capitalization in your menus. See “Capitalization of Interface Element Labels and Text” for more information on this style.
In general, avoid including definite or indefinite articles in the menu item name. Good examples are “Add Account” instead of “Add an Account” and “Hide Toolbar” instead of “Hide the Toolbar.”
An ellipsis character (…) after a menu item indicates to the user that additional information is required to complete a command. For information on when to use an ellipsis in menu items, see “Using the Ellipsis Character.”
It may be appropriate in some cases to provide dynamic menu items—commands that change when the user presses a modifier key. For example, if the user opens the Window menu in the Finder and then presses the Option key, some of the menu items change, as shown in Figure 13-4. The system appropriately sizes the menu to hold the widest item, including Option-enabled commands.
Figure 13-4 Dynamic menu items
Dynamic menu items are an appropriate way to offer a shortcut to sophisticated users. However, because dynamic menu items are hidden by default, they should never be the only way to accomplish a task. Be sure that you don’t require users to discover a dynamic menu item before they can use your application effectively. To return to the example of the Minimize menu items in the Finder Window menu (shown in Figure 13-4), note that a user who hasn’t discovered the Minimize All command can still minimize all open Finder windows by minimizing each one individually.
If you decide to offer a dynamic menu item, be sure to require only a single modifier key to reveal it. Requiring more than one additional key press to reveal a dynamic menu item can make it physically awkward for the user and greatly decreases the user’s chances of discovering the key combination.
You can use Interface Builder to define dynamic menu items. You can also do so using Application Kit programming interfaces. Specifically, you can use the setAlternate: method of NSMenuItem to designate one menu item as the alternate of another.
Using Icons in Menus
You should use text, not icons, for your application menu titles. The operating system provides three application menus that use icons instead of text for their titles: the Apple menu, the Spotlight search field, and the AppleScript menu, which is displayed if the application has scripts installed. The menu bar status items also are icons. These icons (with the exception of the AppleScript menu) are always visible in the menu bar no matter what application is active, so users learn what these symbols mean. These are unique uses of symbols as menu titles.
You may use icons in menu items if the icon is something the user can learn to associate with specific functionality in your application or if the icon represents something unique. For example, as shown in Figure 13-5, the Finder uses icons in the Go menu because users can associate them with the icons they see in the Sidebar.
Figure 13-5 Icons in the Finder Go menu
Safari also makes use of the standard icons displayed with some webpages to allow users to make the connection between the webpage and the menu item for that webpage, as shown in Figure 13-6.
Figure 13-6 Icons in the Safari History menu
If you do include icons in your menus, include them only for menu items for which they add significant value; don’t include them for every menu item. A menu that includes too many icons (or poorly designed ones) can appear cluttered and be hard to read.
Using Symbols in Menus
There are a few standard symbols you can use to indicate additional information in menus. These are listed in Table 13-1 and discussed in the following text. Don’t use other, arbitrary symbols in menus, because they add visual clutter and may confuse people.
Table 13-1 Acceptable characters for use in menus
| Character | Meaning |
|---|---|
| The active document in the Window menu; in other menus, a setting that applies to the entire selection |
| A setting that applies to only part of the selection |
| A window with unsaved changes |
| In the Window menu, a document that is currently minimized in the Dock |
In the Window menu, a checkmark should appear next to the active document’s name. Checkmarks can also be used in other menus to indicate that the setting applies to the entire selection. You can use checkmarks for mutually exclusive attribute groups (the user can select only one item in the group, such as font size) or accumulating attribute groups (more than one item can be selected at once, such as Bold and Italic).
Use a dash to indicate that an attribute applies to only part of the selection. For example, if selected text has two styles applied to it, put a dash next to each style name. When it’s appropriate, you can combine checkmarks and dashes in the same menu. See “Toggled Menu Items” for more information on how to use checkmarks and dashes in menus.
Use a bullet next to a document with unsaved changes and a diamond for a document the user has minimized into the Dock. A minimized document with unsaved changes should have a diamond only. If the active window has unsaved changes, the checkmark should override the bullet in the Window menu.
Figure 13-7 and Figure 13-8 show some examples of how to use and how not to use symbols in menus.
Figure 13-7 Symbols in menus
Figure 13-8 Don’t use arbitrary symbols in menus
If you have a Style menu, you may display menu items in the actual style so users can see what effect the menu item will have. Don’t use text styles in menus other than a Style menu.
Toggled Menu Items
A toggled menu item changes between two states each time a user chooses it. There are three types of toggled menu items:
- A set of two menu items that are opposite states; for example, Grid On and Grid Off. The state currently in effect has a checkmark next to it. If you have room in your menu, it’s a good idea to display both items (rather than changing the name depending on its state) so that there’s less chance of confusion about each item’s effect.
- One menu item whose name changes to reflect the current state; for example, Show Ruler and Hide Ruler. Use this type if your menu doesn’t have room to show both states.
- Use two verbs that express opposite actions. Make sure the command name is completely unambiguous. For example, Turn Grid On and Turn Grid Off is unambiguous. Choosing the command Use Grid, however, could turn the grid on (it describes what happens as a result of choosing the command) or off (it describes the current state).
- A menu item that has a checkmark next to it when it is in effect; for example, a style attribute such as Bold. Don’t use this kind of toggled item to indicate the presence or absence of a feature such as a grid or ruler. It’s unclear whether the checkmark means that the feature is in effect or whether choosing the command turns the feature on.
Figure 13-9 shows correct and incorrect toggled menu items.
Figure 13-9 Avoid ambiguous toggled menu items
Grouping Items in Menus
Logically grouping menu items is the most important aspect of arranging your menus. Grouping items in a menu makes it easier to quickly locate commands for related tasks.
In general, place the most frequently used items at the top of the menu, but create groups of related items rather than arranging them strictly by frequency of use. For example, although the Find Next or the Find Again command may be used infrequently, it should appear right below the Find command. In a menu that contains both actions and attributes, don’t put actions and attributes in the same group.
If your application allows the creation of smart data groups or containers, such as a smart folder in the Finder, group all commands related to the smart group in the same menu. In other words, commands for creating, modifying, and destroying a smart group should all be in the same menu.
Group interdependent attributes. They can be in a mutually exclusive attribute group (the user can select only one item, such as font size) or an accumulating attribute group (the user can select multiple items, such as Bold and Italic).
If a menu repeats a term more than twice, consider dedicating a menu or hierarchical menu to the term instead. For example, if you need commands like Show Info, Show Colors, Show Layers, Show Toolbox, and so on, you could create a Show menu or a submenu off of a Show item.
How many separators to use is partly an aesthetic decision and partly a usability decision. Figure 13-10 shows a menu that depicts the right balance of grouping, contrasted with two menus showing insufficient grouping and too much grouping. Use this picture as a visual guide when trying to decide how many separators to use in your menus.
Figure 13-10 Grouping items in menus
You can use hierarchical menus to offer additional menu item choices without taking up more space in the menu bar. When the user points to a menu item with a submenu indicator, a submenu appears. Submenus have all the features of menus, including keyboard shortcuts, status markers (such as checkmarks), and so on.
Because submenus add complexity to the interface and are physically more difficult to use, you should use them only when you have more menus than fit in the menu bar or for closely related commands. Use only one level of submenus. If a submenu contains more than five items, consider giving it its own menu.
When you use submenus, include them in a menu with a logical relationship to the choices they contain; the submenu title should clearly represent the choices it contains. Hierarchical menus work best for providing submenus of attributes (rather than actions).
Always use a hierarchical menu instead of indenting menu items. Indentation does not express the interrelationships among menu items as clearly as a submenu does. You can, however, use indentation when displaying custom information (such as status information) in your application’s Dock menu. See Figure 13-25 for an example of an application Dock menu. Figure 13-11 shows an example of a hierarchical menu.
Figure 13-11 A hierarchical menu
As with menu titles, a submenu’s title is displayed unchanged even if all of the submenu’s commands are unavailable (dimmed) at the same time. Users should always be able to view a submenu’s contents, whether or not they are available in the current context.
