Problem

You often will not be able to fit all functions for a page on the screen. A method must be provided to access these optional functions.

The general style of the menu structure should often be dictated by the OS, if only because users will become familiar with the style of interaction. However, there is generally much leeway in implementation, if variation from this is desired or called for.

Softkeys are very common still, revealing menus from tab labels based on pressing adjacent hardware keys. When one is open, the other provides a method to exit. The same paradigm can be used without the hardware keys on touch and pen devices by directly selecting the tab labels.

Solution

When the user selects a key, a small on-screen element, or performs a gesture, an option menu is displayed with content relevant to the current state of the application.

Softkeys (hardware buttons tied to on-screen labels, typically on featurephones) are the archetypical version of this. Single actions that take place from a softkey (such as "Cancel") are not a Revealable Menu since they are visible, and might be considered a Fixed Menu. There are many cases where the two menu access systems overlap, or switch back and forth depending on context.

Note that some devices use more than one menu scheme, for different purposes. For example, one may present options for the current application, and another may provide access to the running-applications list for the entire device.

Do not confuse display of this menu with the display of a Notifications list, and be sure the two do not conflict with each other.

Variations

Several variations of this pattern exist:

Menus can be of different types, here displaying fewer items, but also being more touch friendly, and leaving more of the original context visible.

Items within the menu often reveal submenus, or lists of additional features. These may either follow the same principles as the top level of menu, and appear as an attached subset, or may appear as a free-standing menu, usually as a Select List or Grid of items in a Pop-Up dialogue.

Interaction Details

Treat opened menus as modal dialogues. For touch and pen devices, selection outside the menu area may, if desired, clear the menu instead of being ignored. This is especially true if the menu when open does not obscure the background. However, you should not allow selection of items in the parent window while the option menu remains open.

Menus can be made to appear with a drag action, relying on no buttons or on-screen indicators. However, users will have to be taught this action somehow, so it is often unsuitable unless used across the OS, and there is supporting marketing or training can be tolerated. All opened menus must have a method to be exited. The typical methods are:

For devices with 5-way pads, opened menus should be able to be scrolled through. Regardless of the input mechanism, selection of a single item will close the menu and initiate the action, which may change states, cause a different modal dialogue to appear, load an entirely new page or even exit the application. For vertical menus, see the Vertical List pattern for additional details on interaction and presentation.

If the selected item itself has options, a subsidiary menu will be opened. For vertically-scrolling menus, this is usually presented as a visible child, adjacent to the primary menu, and is itself a modal dialogue; the previous menu cannot be directly selected. For scroll-and-select devices, sub-menus can also be entered by scrolling right. For horizontally-arranged icon menus, typically there is only one "More..." type of option which opens a Pop-Up dialogue with a Vertical List, usually a Thumbnail List where the thumbnails are also icons.

To exit a sub-menu, scroll left or press the "back" button or "Cancel" tab, whichever is available. This key will only close the submenu, returning focus to the parent selection item, and not the entire option menu.

For any hardware menu keys or Softkeys, pressing and holding the key can perform a different action. This action is usually a different kind of reveal menu, and may be associated with a Softkey which normally does not open a Revealable Menu, and should have a relationship to the original key label to aid in discovery and recall. For example, within a browser, a softkey labeled "Back" could open a history menu when held down a few seconds.

Sub-menus or additional options can be displayed from any menu scheme. Icon menus, such as gesture menus or the icon bar menu on the left, usually should open a separate vertical dialogue. Softkey type menus, on the right, usually display them adjacent to or overlapping the main menu.

Presentation Details

In almost all cases, you should make the closed menu initiators or indicators, such as Softkey tabs, locked to the viewport. Do not allow them to scroll off the page. Visible tabs should always be visible, but may be hidden temporarily for media playback or otherwise to give more room to the primary content.

If your design has no on-screen menu visibility, and no dedicated button is provided, consider adding a visible component at page load, or during a training period when the device is first accessed, to train the user that the feature exists.

Options menus, however they are initiated, must immediately appear. If animation is used to open the menu (e.g. it slides in) the beginning of the animation must start immediately. Since the menu may be partly obscured by the user, especially for touch and pen devices, Haptic Output (vibration feedback) of the action should also be considered. The menu should appear to emerge from the tab or button, over-writing the area.

Within the opened menu, displayed items as text, and use supporting iconic elements only when there is room. See the Indicator pattern for more details on using icons along with text in lists.. Most Softkey-like menus are vertical and designed for text density, so do not work well displaying an Icon for each item, but this is very suitable for other menu types.

Options that cannot be used should be "grayed out" to make them appear inaccessible. Leaving them in the list is helpful as it teaches the user what sort of actions are available in the list, and preserves the position for additional consistency.

Display Accesskey (keyboard shortcut) indicators for each item with an associated Accesskey. Do not display these for devices that do not have hardware keyboards or keypads.

You should place indicators of some sort next to items which can reveal additional menu items. Sub-menus may occlude the main menu if space is limited, or may hang off to the side. They should usually obscure the main menu in some manner to make the focus item more clear. Sub-menus should contain a Title, or the selected parent element must be highlighted and point to the sub-menu to serve as a label for the menu.

Antipatterns

Modal design, such as the entire principle of a Revealable Menu can be difficult to communicate, especially if OS standard implementations are not used, or the user is not accustomed to the platform. Carefully consider the whole concept, how to assure the menu can be launched, and how many controls can be modeless instead.

Within the menu, only allow access to options that can be used. If all options are selectable, then error messages will be displayed which could otherwise be avoided.

Softkey orientation, or which side gets which key, should follow the standards of the OS or the operator. These are usually not set at the device level, but are univeral for all devices using the OS, or all devices the operator overlays. Most application frameworks allow specifying something like "primary" and "secondary" as softkey identifiers; use these instead of left and right, to assure your application complies with the standards of the device on which it resides.

Avoid too many levels of menu. Generally, due to size of screen and complexity, only one sub-menu level should be provided.


Next: Fixed Menu


Discuss & Add

Please do not change content above this like, as it's a perfect match with the printed book. Everything else you want to add goes down here.

Examples

If you want to add examples (and we occasionally do also) add them here.

Make a new section

Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.