Grouping Menu Items
Arranging menu items in logical groups helps users locate commands quickly. As you figure out how to group menu items, it often works well to refer to the user’s mental model of your app’s task. To learn more about this concept, see Mental Model.
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. The TextEdit Edit menu (shown here) is a good example of using task-specific concepts to group menu items.
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, avoid arranging all of a menu’s items strictly by frequency of use. A better tactic 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.
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 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 a large number of 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.