UI Element Guidelines: Menus
Menus present lists of items—commands, attributes, or states—from which the user can choose.
Users refer to menus frequently, especially when they are seeking a function for which they know of no other interface. Ensuring that menus are correctly organized, are worded clearly, and behave correctly is crucial to the user’s ability to explore and access the functionality of your app.
Menus have a few different forms in the OS X interface:
A menu bar menu displays the current app’s commands in the single menu bar at the top of the display. An app typically displays several menus in the menu bar (for an overview of the menu bar, see “All Apps Use the Single Menu Bar”).
A Dock menu contains system-defined commands (such as Reveal in Finder and Keep in Dock) and, optionally, app-specific commands (such as New Window). To reveal a Dock menu, users Control-click or press and hold an app’s Dock icon.
A contextual menu displays commands that are directly related to an item. To reveal a contextual menu, users Control-click an onscreen area or a selection.
You can see examples of these menu types in the TextEdit Edit menu, the Mail Dock menu, and a Finder contextual menu (from left to right).
There are also a few controls that display menus, such as pop-up menus, command pop-down menus, and pop-up icon buttons and bevel buttons. Many of the guidelines in this chapter also apply to these control menus because they share several characteristics with app menus. To learn how to use the controls themselves, see the control-specific sections in “UI Element Guidelines: Controls.”
Menu Appearance and Behavior
At a minimum, a menu displays a list of menu items. Most menus also include a title that indicates the types of items that are in the list. In addition, menus can include some optional components, such as keyboard shortcut symbols, hierarchical menus (also known as submenus), toggled menu items, separators, icons, and symbols (such as the checkmark). For example, the TextEdit Edit menu includes a list of commands, a title ("Edit”), keyboard shortcuts, hierarchical menus, and separators that indicate different groups of items.
A menu bar menu might include examples of all of these components, but not all of them are suitable for every type of menu. For example, a contextual menu does not need a title because it is automatically related to the user’s current selection. For guidelines on providing a contextual menu in your app, see “Designing Contextual Menus.”
Menus are an example of the see-and-point paradigm: People identify what needs to be acted on and then specify the action by choosing a menu item.
To choose an item in a menu, the user reveals the menu and moves the pointer to the desired item. Each active menu item highlights as the pointer passes over it and opens its submenu (if it has one). No action happens until the user chooses an item. This behavior allows people to open and scan menus to find out what features are available without having to actually perform an action. When the user chooses a menu item, it blinks briefly to confirm the user’s choice and then performs the action.
After the user opens a menu, it remains open until another action forces it to close. Such actions include:
Choosing an item in the menu
Moving the pointer to another menu title in the menu bar
Clicking outside of the menu
A system-initiated alert
A system-initiated app switch or quit
In addition to the system-provided menus, such as File and Window, most apps provide a few app-specific menus to display in the menu bar so that users have access to useful commands. Users choose which menu to open based on the menu’s title, so it’s important to make your menu titles accurate and informative. Note that contextual and Dock menus don’t need titles because users open these menus after focusing on a selection or an area in a window or by choosing an app in the Dock.
Follow these guidelines as you create titles for your menus.
Use menu titles that accurately represent the items in the menu. Users should be able to use a menu’s title to predict the types of items they’ll find in the menu. For example, users would expect a Font menu to contain names of font families, such as Helvetica and Geneva, but they wouldn’t expect it to include editing commands, such as Cut and Paste.
Make menu titles as short as possible without sacrificing clarity. One-word menu titles are best because they take up very little space in the menu bar and they’re easy for users to scan.
Avoid using an icon for a menu title. You don’t want users to confuse a menu-title icon with a menu bar extra. Also, it’s not acceptable to mix text and icons in menu bar menu titles.
Ensure that a menu’s title is undimmed even when all of the menu’s commands are unavailable. Users should always be able to view a menu’s contents, whether or not they are currently available. Ensuring that your menu items are always visible (even when they are not available) helps users learn what they can do in your app.
Naming Menu Items
As with menu titles, it’s important to choose menu item names that are accurate and informative so that users can predict the result of choosing an item.
Menu item names describe actions that are performed on an object or attributes that are applied to an object. Specifically:
Actions are verbs or verb phrases that declare the action that occurs when the user chooses the item. For example, Print means print my document and Copy means copy my selection.
Attributes are adjectives or adjective phrases that describe the change the command implements. Adjectives in menus imply an action and they can often fit into the sentence “Change the selected object to …” —for example, Bold or Italic.
Follow these guidelines as you create menu items.
In general, avoid including definite or indefinite articles in the menu item name. Including an article is rarely necessary because the user has already made a selection or entered a context to which the command applies. Good examples are “Add Account” instead of “Add an Account” and “Hide Toolbar” instead of “Hide the Toolbar.” Be sure that you use this style consistently in all your menu item names.
Use an ellipsis to show users that further action is required to complete the command. The ellipsis character (…) means that a dialog or a separate window will open in which users need to make additional choices or supply additional information in order to complete the action. For details on when to use an ellipsis in menu items, see “Using the Ellipsis Character.”
Use title-style capitalization for menu item names. For more information on this style, see “Capitalizing Labels and Text.”
If appropriate, define a keyboard shortcut for a frequently used menu item. A keyboard shortcut, such as Command-C for Copy, can make common tasks easier for sophisticated users. Before you create a keyboard shortcut for a custom menu item, be sure to read the guidelines in “Creating New Keyboard Shortcuts.”
Dim unavailable menu items. When a menu item is dimmed (that is, gray), it helps users understand that the item is unavailable because, for example, it doesn’t apply to the selected object or in the current context. A dimmed menu item does not highlight when the user moves the pointer over it.
Grouping Items in Menus
Arranging menu items in logical groups makes it easy for users to quickly locate commands for related tasks. The guidelines in this section can help you list menu items in ways that make sense to users.
In general, place the most frequently used items at the top of the menu. The top of the menu tends to be the most visible part of the menu because users often see it first. At the same time, you should avoid arranging all of a menu’s items strictly by frequency of use. A better strategy is to create groups of related items and place the more frequently used groups above the less frequently used groups. For example, although the Find Next (or Find Again) command might be used infrequently, it should appear right below the Find command.
Avoid combining actions and attributes in the same group. Users tend to view choosing an action differently from choosing an attribute to apply to a selection, so it’s best to put these items in different groups.
Group interdependent attributes. Users expect to find related attributes in the same group. Attributes 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).
Group the commands that act upon a smart container. If your app 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. Doing this makes it easy for users to find the commands for creating, modifying, and destroying a smart group.
Look for opportunities to consolidate related menu items. If a menu repeats a term more than twice, consider dedicating a separate menu (or submenu) to the term. 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 Show item that includes a submenu.
As much as possible, create the “right” number of groups. The number of groups to use is partly an aesthetic decision and partly a usability decision. For example, the leftmost menu shown below depicts a good balance of grouping, contrasted with the menus in the middle and on the right, which show too much grouping and insufficient grouping, respectively. Use this picture as a visual guide when trying to decide how many groups to use in your menus.
In general, avoid creating very long menus. Long menus are difficult for users to scan and can be overwhelming. If you find that there are too many items in a single menu, try redistributing them; you might find that some of the items fit more naturally in other menus or that you need to create a new menu. You can also consider creating submenus for some related sets of items, but this isn’t appropriate in all cases; for some guidance on creating a submenu, see “Creating Hierarchical Menus.”
Note that in some menus, users might add enough items to make the menu very long. For example, the Safari History menu can grow very long, depending on how many websites users visit. In some cases, a long menu can become a scrolling menu, which displays a downward-pointing arrow at the bottom edge. Scrolling menus should exist only when users add many items to a customizable menu or when the menu’s function causes it to have items added to it (such as an app’s Window menu). You should not intentionally design a scrolling menu.
Providing Dynamic Menu Items
A dynamic menu item is a command that changes when the user presses a modifier key. For example, when the user opens the Window menu in the Finder and then presses the Option key, the Minimize and Zoom menu items change.
You can define dynamic menu items using Interface Builder. To define dynamic menu items in code, you can use the
setAlternate: method of
NSMenuItem to designate one menu item as the alternate of another.
Follow these guidelines if you decide to use dynamic menu items in your app.
Avoid making a dynamic menu item the only way to accomplish a task. Because dynamic menu items are hidden by default, they can be an appropriate way to offer a shortcut to sophisticated users. In particular, be sure that you don’t require users to discover a dynamic menu item before they can use your app effectively. For example, a user who hasn’t discovered the Minimize All dynamic menu item in the Finder Window menu (shown above) can still minimize all open Finder windows by minimizing each one individually.
Although you can enable dynamic menu items in a contextual or Dock menu, you should probably consider such items to be doubly hard for users to discover. As with app menus, make sure that the functionality of the contextual or Dock menu does not depend on the discovery of dynamic menu items.
Require only a single modifier key to reveal the dynamic menu items in a menu. Users are apt to find it physically awkward to press more than one key while simultaneously opening and choosing a menu item. Also, requiring more than one additional key press greatly decreases the user’s chances of discovering the dynamic menu items.
Providing 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 indicate opposite states or actions; for example, Grid On and Grid Off. The menu item currently in effect can be identified by a checkmark or by being inactive.
One menu item whose name changes to reflect the current state; for example, Show Ruler and Hide Ruler.
A menu item that has a checkmark next to it when it is in effect; for example, a style attribute such as Bold.
Toggled menu items can be convenient, but they are rarely necessary. If you want to use toggled menu items in your app, use the following guidelines to make sure that they provide value to users.
Display both items in a set, if you have room in your menu. When users can see both states or actions at the same time, there’s less chance of confusion about each item’s effect. For example, the Mailbox menu in Mail includes both the Take All Accounts Online and Take All Accounts Offline items. When the user’s accounts are online, only the Take All Accounts Offline menu item is available, which leaves no doubt about the effect of this action.
Use a changeable menu item name if there isn’t enough room to show both items. You might also choose to use this type of toggled menu item if you’re confident that users will reopen the menu and see the opposite item. The best way to make sure that the command names are completely unambiguous is to use two verbs that express opposite actions.
For example, the commands Turn Grid On and Turn Grid Off are unambiguous. By contrast, it’s unclear what the opposite of the command Use Grid might be. Some users might expect the opposite command to be Don’t Use Grid, because they interpret the command as an action. Other users might expect to see a checkmark next to Use Grid after choosing the command, because they interpret Use Grid as a description of the current state.
For example, Mail uses changeable toggled menu items in the View menu to allow users to show or hide features such as the mailbox list and toolbar.
Use a checkmark when the toggled items represents an attribute that is currently in effect. It’s easy for users to scan for checkmarks in a list of attributes to find the ones that are in effect. For example, in the Mail Format menu, users can see at a glance which styles have been applied to the selected text.
Don’t use a checkmark when the toggled item indicates the presence or absence of a feature. In such a case, users can’t be sure whether the checkmark means that the feature is currently in effect or that choosing the command turns the feature on.
Using Icons in Menus
Sometimes, displaying icons in menus can help users recognize menu items and relate them to other items they know about. As with all icons, you need to make sure that using them does not add confusion or ambiguity. Follow the guidelines in this section if you decide to use icons in your menus.
Don’t use an icon without any text. Even if you use an icon you think all users will recognize, it’s best to reinforce the icon’s meaning by including a textual menu item name.
Use only familiar icons. You can use icons in menu items if the icon is something the user can learn to associate with specific functionality in your app or if the icon represents something unique. For example, the Finder uses icons in the Go menu because users can associate them with the icons they see in the sidebar.
In another example, Safari uses the icons displayed by some webpages to help users make the connection between the webpage and the menu item for that webpage.
Avoid displaying an icon for every menu item. If you include icons in your menus, include them only for menu items for which they add significant value. 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 provide additional information in menus. These symbols are used consistently throughout OS X, so users are accustomed to their meaning.
Table 6-1 lists the standard symbols and what they mean.
In the Window menu, the active document; 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 (typically, when Auto Save is not available)
In the Window menu, a document that is currently minimized in the Dock
To use symbols appropriately in your menus, follow these guidelines.
Avoid using custom symbols in a menu. If you use other, arbitrary symbols in menus, users are unlikely to know what they mean. Also, additional symbols tend to add visual clutter.
Use a checkmark to indicate that something is currently active. In an app’s Window menu, a checkmark appears next to the active window’s name. In other menus, a checkmark can indicate that a setting applies to the entire selection. As described in “Providing Toggled Menu Items,” you can use checkmarks within 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 the selected text has two styles applied to it, you can put a dash next to each style name. Or, you can display a checkmark to every style currently in effect. When it’s appropriate, you can combine checkmarks and dashes in the same menu.
As much as possible, use a dot only when Auto Save is not available. When you support Auto Save, users should not have to be aware of the saved state of their documents. However, you might need to display a dot if, for example, the user’s disk is full and Auto Save can't complete. For more information about supporting Auto Save in your app, see “Auto Save and Versions.”
Allow the diamond and the checkmark to replace the dot (if it is used). A minimized document with unsaved changes should have a diamond only. If the active window has unsaved changes, the checkmark should override the dot in the Window menu.
Use actual text styles only in a Style menu. If you have a Style menu, you can display menu items in the actual styles that are available, so that users can see what effect the menu item has. Don’t use text styles in menus other than a Style menu. Also, it would not make sense to apply a list or indentation style to a menu item.
Creating Hierarchical Menus
A hierarchical menu (also called a submenu) contains a set of choices that are related to a menu item without increasing the length of the menu. A menu item that contains a submenu, such as the Find menu item in the Mail Edit menu, displays the submenu indicator to show users that there are additional choices. It’s easy for users to discover the existence of submenus because they open automatically when the pointer passes over the menu item.
Submenus can have all the features of menus, including keyboard shortcuts, status markers (such as checkmarks), and so on. If you use submenus in your app, follow these guidelines.
Ensure that a submenu’s title is undimmed even when all its commands are unavailable. As with menu titles, it’s important for users to be able to view a submenu’s contents, even if none of them are available in the current context.
Use submenus cautiously. Submenus add complexity to the interface and are physically more difficult to use, so you should take care not to overuse them. In general, it’s appropriate to use submenus when you have sets of closely related commands (or alternative ways to perform one type of command, such as Find) and when you need to save space.
As much as possible, use only one level of submenus. A submenu that contains other submenus can be very difficult for users to use. Also, if a submenu contains more than five items, consider giving it its own menu.
Title a submenu so that it accurately describes the items it contains. Make sure the a submenu’s contents have a logical relationship with the submenu title. For example, the Mark menu item in the Mail Message menu reveals a submenu that allows users to mark a message in different ways, such as junk or high priority. In general, 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.
Designing Menus for the Menu Bar
The single menu bar at the top of the main display screen provides a home for the top-level menus in your app. In addition to the system-provided and user-assigned items (described in “All Apps Use the Single Menu Bar”), you determine the menus that appear in the menu bar. For some guidance on how to arrange your app-specific menus, see “Make Your App Easy to Use.”
The following sections provide guidelines that help you choose which menus you need and which menu items you should include.
The Apple Menu
The Apple menu provides items that are available to users at all times, regardless of which app is active. The Apple menu’s contents are defined by the system and can't be modified by users or developers.
The App Menu
The app menu contains items that apply to the app as a whole rather than to a specific document or other window. To help users identify the active app, the app menu title (which is the app’s name) is displayed in a bold font in the menu bar.
If possible, use one word for the app menu title. Using a short name helps make room for the rest of your app’s menus. If your app’s name is too long, provide a short name that’s about 16 characters or fewer. If you don’t provide a short name, the system might truncate the name from the end and add an ellipsis when the name is displayed in the menu bar.
Don’t include the app version number in the name. Version information belongs in the About window.
The app menu contains the following standard menu items, listed in the order in which they should appear:
Opens the About window, which contains the app's copyright information and version number.
To learn more about About windows, see “About Windows.”
Opens a preferences window for your app.
To learn about defining preferences for your app, see “Preferences.”
Displays a submenu of services that are available in the current context.
For more information on providing and using services, see “Services.”
Hides all of the windows of the currently running app and brings the most recently used app to the foreground.
Hides the windows of all the other apps currently running.
Shows all windows of all currently running apps.
Quits the app.
Use the short app name in menu items that display it. If you supplied a short app name, use it in the About, Hide, and Quit menu items.
Put a separator between the About item and the Preferences item. These two commands are very different and should be in different groups. Note that if your app provides document-specific preferences, you should make them available in the File menu (described in “The File Menu”).
In general, place the Preferences menu item before any app-specific items. For example, Mail places its app-specific Provide Mail Feedback item after Preferences. You can add a separator between Preferences and your app-specific items if it makes sense (for advice on grouping menu items, see “Grouping Items in Menus”).
Don’t include a Help menu item with other app-specific items. All app help items belong in the Help menu (described in “The Help Menu”).
Place the Quit menu item last. Precede the Quit item with a separator and don’t combine it with any other items. For a discussion about some ways to think about the need for a Quit command in your app, see “Avoid Burdening Users with App-Management Tasks.”
The File Menu
In general, each command in the File menu applies to a single file (most commonly, a user-created document).
If your app is not document-based, you can rename the File menu to something more appropriate or eliminate it.
The File menu includes the following standard menu items, listed in the order in which they should appear:
Opens a new document.
For more information about naming new document windows, see “Naming New Windows.”
Displays a dialog for choosing an existing document to open. (Note that in the Finder, the Open command is not followed by an ellipsis character because the user performs navigation and document selection before selecting the Open command.)
For more information, see “The Open Dialog.”
Opens a submenu that displays a list of the most recently opened documents. (Note that the Apple menu provides the ability to open recent documents and apps in the Recent Items menu item.)
Closes the active window.
When the user presses the Option key, Close changes to Close All. The keyboard shortcuts Command-W and Command-Option-W should implement the Close and Close All commands, respectively.
Closes a file and all its associated windows.
Typically used in file-based apps that support multiple views of the same file.
Displays the Save dialog, in which users provide a name and location for their content.
The Save command can become the Save a Version command after users have provided a name and location for their content. (For more information about the Save dialog, see “Save Dialogs.”)
Duplicates the current document, leaving both documents open.
Legacy command. In document-based apps, this functionality is provided by the Duplicate command instead.
Displays the Save dialog, in which the user can save a copy of the active file in a format your app does not handle.
After the user completes an Export As command, the original file remains open so that the user can continue working in the current format; the exported file does not automatically open.
Saves changes to all open files.
Revert to Saved
Displays all available versions of the document in the version browser (when Auto Save is enabled). Users choose a version to restore and the current version of the document is replaced by the restored version.
Opens the standard Print dialog, which allows users to print to a printer, to send a fax, or to save as a PDF file.
For more information, see “The Print and Page Setup Dialogs.”
Opens a dialog for specifying printing parameters such as paper size and printing orientation (these parameters are saved with the document).
In the Open Recent command, display document names only. In particular, don’t display file paths. Users have their own ways of keeping track of which documents are which and file paths are inappropriate to display unless specifically requested by the user.
Use the Save command to give users the opportunity to specify a name and a location for their content. As much as possible, you want to help users separate the notion of saving their work from the task of giving it a name and location. Above all, you want users to feel comfortable with the fact that their work is safe even when they don’t choose File > Save. To learn more about how to free users from frequently using the Save command to save their work, see “Auto Save and Versions.”
Use the Duplicate command to replace the Save As and Export As commands. Many users are confused by the Save As and Export As experiences because the relationship between the two document versions isn’t always obvious. The Duplicate command shows users precisely where the document copy comes from (it emerges from the original) and indicates which version is which (the copy includes Copy in its title). In addition, the Duplicate command leaves both document versions open, giving users control over which document they want to work in.
If you provide document-specific preferences items, place them above printing commands. Also, be sure to give your document-specific preferences a unique name, such as Page Setup, rather than Preferences. Note that the Preferences and Quit commands, which apply to the app as a whole, are in the app menu.
Avoid providing multiple Save As Format commands. If necessary, you can instead use the Format pop-up menu in the Save dialog to give the user a selection of file formats. For example, the Format pop-up menu in Preview’s Save dialog allows a user to specify many different formats, such as TIFF, PNG, and JPG.
If you need to allow users to continue working on the active document, but save a copy of the document in a format your app doesn't handle, you can provide an Export As command.
Avoid providing Save a Copy or Save To commands. The functionality that users associate with these commands is provided by the Duplicate command.
The Edit Menu
The Edit menu provides commands that allow people to change (that is, edit) the contents of documents and other text containers, such as fields. It also provides commands that allow people to share data, within and between apps, via the Clipboard.
Even if your app doesn’t handle text editing within its documents, the expected Edit commands should be available for use in dialogs and wherever users can edit text.
The Edit menu includes the following standard menu items, listed in the order in which they should appear:
Reverses the effect of the user’s previous operation.
Reverses the effect of the last Undo command.
Removes the selected data and stores it on the Clipboard, replacing the previous contents of the Clipboard.
Makes a duplicate of the selected data, which is stored on the Clipboard.
Inserts the Clipboard contents at the insertion point.
The Clipboard contents remain unchanged, permitting the user to choose Paste multiple times.
Paste and Match Style
Inserts the Clipboard contents at the insertion point, matching the style of the inserted text to the surrounding text.
Removes selected data without storing the selection on the Clipboard.
Highlights every object in the document or window, or all characters in a text field.
Opens an interface for finding items.
Performs the last Find operation again.
Performs a spell-check of the selected text and opens an interface in which users can correct the spelling, view suggested spellings, and find other misspelled words.
Displays a submenu containing the Start Speaking and Stop Speaking commands.
Users choose this command to hear any app text spoken aloud by the system.
Displays the Special Characters window, which allows users to input characters from any character set supported by OS X into text entry fields. This menu item is automatically inserted at the bottom of the Edit menu.
As much as possible, support undo and redo functionality. In particular, you should support the Undo command for:
Operations that change the contents of a document
Operations that require a lot of effort to re-create
Most menu items
Most keyboard input
It might not be possible to support undo for every operation users can perform in your app. For example, selecting, scrolling, splitting a window, and changing a window’s size and location aren’t necessarily undoable.
Let the user know when Undo isn’t possible. If the last operation can’t be reversed, change the command to Can’t Undo and display it dimmed to help the user understand that the action isn’t available.
If a user attempts to perform an operation that could have a detrimental effect on data and that can’t be undone, warn the user (for more information on how to do this, see “Alerts”).
Add the name of the last undo or redo operation to the Undo and Redo commands, respectively. If the last operation was a menu command, add the command name. For example, if the user has just input some text, the Undo command could read Undo Typing. If the user chooses Undo Typing, the Redo command should then read Redo Typing and the Undo command should include the name of the operation the user performed before typing.
Don’t change the Delete menu item name. Choosing Delete is the equivalent of pressing the Delete key or the Clear key. Use Delete as the menu command, not Clear or Erase or anything else.
Determine the best placement for the Find command. For example, the Find command could be in the File menu, instead of the Edit menu, if the object of the search is files. When appropriate, your app should also contain a Find/Replace command. For more information about providing find functionality, see “Find Windows.”
Provide a Find submenu, if appropriate. You might want to include a Find submenu if find is important functionality in your app. Typically, a Find submenu contains Find (Command-F), Find Next (Command-G), Find Previous (Shift-Command-G), Use Selection for Find (Command-E), and Jump to Selection (Command-J). If you include a Find submenu, the Find menu item name should not include an ellipsis character.
Group Find Next with Find. Whether you place the Find command in the File menu or the Edit menu, this item should be grouped with the Find command because users think of them together.
Provide a Spelling submenu, if appropriate. If your app provides multiple spelling-related commands, you might want to include a Spelling submenu that contains Check Spelling (Command-;) and Check Spelling as You Type commands. If you include a Spelling submenu, the Spelling menu item name should not include an ellipsis character.
The Format Menu
If your app provides functions for formatting text, you can include a Format menu as a top-level menu or as a submenu of the Edit menu. It might be appropriate to group some items that are in the Format menu into submenus, such as Font, Text, or Style.
The Format menu includes the following standard menu items, listed in the order in which they should appear:
Displays the Fonts window.
The Show Fonts menu item should be displayed first in the Format menu.
Displays the Colors window.
Boldfaces the selected text or toggles boldfaced text on and off.
Italicizes the selected text or toggles italic text on and off.
Underlines the selected text or toggles underlined text on and off.
Causes the selected item to increase in size in defined increments.
Causes the selected item to decrease in size in defined increments.
Copies the style—font, color, and size for text—of the selected item.
Applies the style of one object to the selected object.
Left-aligns a selection.
Center-aligns a selection.
Evenly spaces a selection.
Right-aligns a selection.
Displays a formatting ruler.
Copies formatting settings such as tabs and alignment for a selection to apply to a another selection and stores them on the Clipboard.
Applies formatting settings (that have been saved to the Clipboard) to the selected object.
The View Menu
The View menu provides commands that affect how users see a window’s content; it does not provide commands to select specific document windows to view or to manage a specific document window. Commands to organize, select, and manage windows are in the Window menu (described in “The Window Menu”).
The View includes the following standard menu items, listed in the order in which they should appear:
Shows or hides a toolbar.
Opens a dialog that allows the user to customize which items are present in the toolbar.
Enter Full Screen
Opens the window at full-screen size in a new space. Available when the app supports full-screen windows.
Include the View menu if a window can go full screen or if it contains a toolbar. Create a View menu for these commands even if your app doesn’t need to have other commands in the View menu. Note that the Enter Full Screen command toggles with the Exit Full Screen command.
Avoid using the View menu to display panels (such as tool palettes). Use the Window menu to display open windows and panels instead.
Implement the Show/Hide Toolbar command as a dynamic toggled menu item. If the toolbar is currently visible, the menu item says Hide Toolbar. If the toolbar is not visible, it says Show Toolbar.
You can add your own app-specific menus as appropriate. These menus should be between the View menu and the Window menu. For example, the Safari-specific History and Bookmarks menus appear between the View and Window menus.
The Window Menu
The Window menu contains commands for organizing and managing an app’s windows.
Other than Minimize and Zoom (discussed below), the Window menu does not contain commands that affect the way a user views a window’s contents. The View menu (described in “The View Menu”) contains all commands that adjust how a user views a window’s contents.
The Window menu includes the following standard items, listed in the order in which they should appear:
Minimizes the active window to the Dock.
Minimizes all the windows of the active app to the Dock.
Toggles between a predefined size appropriate to the window’s content and the window size the user has set.
Bring All to Front
Brings forward all of an app’s open windows, maintaining their onscreen location, size, and layering order. (This should happen when the user clicks the app icon in the Dock.)
Note that this item can be an Option-enabled toggle with Arrange in Front.
Arrange in Front
Brings forward all of the app’s windows in their current layering order and changes their location and size so that they are neatly tiled.
Note that this item can be an Option-enabled toggle with Bring All to Front.
The following guidelines help you provide a Window menu that helps users organize windows in your app.
List open windows appropriately. The Window menu should list your app’s open windows (including minimized windows) in the order in which they were opened, with the most recently opened window first. If a document contains unsaved changes, a dot can appear next to its name.
Avoid listing open panels in the Window menu. You can, however, add a command to the Window menu to show or hide panels in your app. (For more information about panels, see “Panels.”)
Include a Window menu for the Minimize and Zoom commands. Even if your app consists of only one window, you should provide the Minimize and Zoom commands so that people using full keyboard access can implement these functions with the keyboard.
Use the correct order for items in the Window menu. Specifically, items should appear in this order:
App-specific window commands
Bring All to Front (optional)
A list of open windows
Note that the Close command should appear in the File menu, below the Open command (see “The File Menu”).
Avoid using Zoom to expand the window to the full screen size. Users expect Zoom to toggle the window between two useful sizes. For more information about implementing zoom, see “Resizing and Zooming Windows.”
The Help Menu
If your app provides onscreen help, the Help menu should be the rightmost menu of your app’s menus.
If you have registered your help book, the system provides the Spotlight For Help search field as the first item in the menu (for information on how to register your help book, see Apple Help Programming Guide).
The next menu item is AppName Help, which opens Help Viewer to the first page of your app’s help book. For some guidelines on creating useful help content, see “User Assistance.”
As much as possible, display only one custom item in the Help menu. That is, it’s best to display only the AppName Help item. If you do have more items, display them below this item. If you have additional items that are unrelated to help content, such as arbitrary website links, registration information, or release notes, link to these within your help book instead of listing them as separate items in the Help menu.
Avoid using the Help menu as a table of contents for your help book. When users choose the AppName Help item, they can see the sections in your help book in the Help Viewer window. If you choose to provide additional links into your help content within the Help menu, be sure they are distinct.
Menu Bar Extras
As described in “All Apps Use the Single Menu Bar,” users decide to place menu bar extras in the menu bar. Typically, users decide to hide or show a menu bar extra by changing a setting in the appropriate preferences pane.
If there is not enough room in the menu bar to display all menus, OS X automatically removes menu bar extras to make room for app menus, which take precedence. Similarly, if there are too many menu bar extras, OS X may remove some of them to avoid crowding app menus.
Don’t rely on the presence of menu bar extras. The system might change which menu bar extras are visible, and you can’t be sure which menu bar extras users have chosen to show or hide.
Avoid creating a popover that emerges from a menu bar extra. Popovers emerge from controls and specific window areas (for guidelines on how to use a popover in your app, see “Popovers”). A menu bar extra can open a menu, such as the Keyboard & Character Viewer menu.
Consider alternatives to creating a menu bar extra. For example, you can use the Dock menu functions to open a menu from your app’s icon in the Dock. For some guidelines on how to create a Dock menu, see “Designing a Dock Menu.”
Designing Contextual Menus
A contextual menu provides convenient access to often-used commands associated with an item. You can think of a contextual menu as a shortcut to a small set of commands that make sense in the context of the current task. An object or selection can display a contextual menu when the user Control-clicks the object or selection.
For example, Control-clicking a document icon displays a contextual menu that allows users to perform several file-specific Finder actions.
Control-clicking a text selection displays a different contextual menu and one that is focused on text-specific actions. For example, the contextual menu displayed when users Control-click a text selection in a TextEdit document lists commands that allow them to change the font or check the spelling of the text.
If appropriate, use an Action menu to make contextual menu functionality easier to access. You can use an Action menu to provide an app-wide contextual menu control in a toolbar. For example, the Finder provides an Action menu toolbar control that allows users to get the same commands that are displayed in a contextual menu for the selected item. For some guidelines on how to use an Action menu, see “Action Menu.”
Include only the most commonly used commands that are appropriate in the current context. For example, Edit menu commands should appear in the contextual menu for highlighted text, but a Save or a Print command should not.
Use caution when adding a submenu to a contextual menu. Although you don’t want a contextual menu to grow too long (too-long contextual menus display the scrolling indicator and scroll like standard menus), you also don’t want to make them hard to use. Sometimes, users can find it difficult to maneuver the pointer so that the submenu stays open. If you decide to add submenus to your contextual menu, be sure to keep them to one level.
Don’t set a default item in a contextual menu. If the user opens the menu and closes it without selecting anything, no action should occur.
Always ensure that contextual menu items are also available as menu commands. A contextual menu is hidden by default and a user might not know it exists, so it should never be the only way to access a command. In particular, you should not use a contextual menu as the only way to access an advanced or power-user feature.
Don’t display keyboard shortcuts in a contextual menu. A contextual menu is a shortcut to a set of task-specific commands, so it's redundant to display the keyboard shortcuts for those commands. Note that you should continue to display keyboard shortcuts in your app menus, as described in “Designing Menus for the Menu Bar.”
Designing a Dock Menu
When users Control-click a running app’s Dock icon, a customizable Dock menu appears. By default, this menu displays the same items as the minimal Dock menu that is displayed when users press and hold the Dock icon (for more information about different styles of Dock menus, see “The Dock”). In addition, this menu can contain app-specific items, such as the playback-focused commands in the customized iTunes Dock menu.
The custom items that you add appear in the Dock menu only when your app is open and the user Control-clicks the Dock icon. You might consider adding items such as:
Common commands to initiate actions in your app when it is not frontmost
Commands that are applicable when there is no open document window
Status and informational text
For example, Mail provides commands to initiate a new message or to check for new messages. To learn how to customize the Dock menu for your app, see Dock Tile Programming Guide.
Be sure that all Dock menu commands are also available in your app’s menus. Users might not know about the Dock menu, so it should not be the only way to do something.
Place your app-specific items above the standard Dock menu items. Users should always know where to look for the system-provided Dock menu commands.