Problem

Not all functions for a page can or should be presented on the screen. A method must be provided to access these optional functions.

Solution

By selecting a key, small on-screen element, or performing a gesture, an option menu is displayed with content relevant to the current state of the application.

Softkeys 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.

Variations

Three variations of this pattern exist:

The Softkey style uses one or more hardware buttons (or a portion of the touch/pen area outside the display) to reveal an option menu. They may or may not display a tab indicating the presence of this menu when closed.

Softkey-like on-screen displays always display a tab or button, usually along the bottom edge of the viewport. The closed state is always visible as this is the method used to access the function

Gestural menus generally have no on-screen visibility. When the user swipes from an edge, the menu acts as if it accompanies them. This is generally non-persistent, and when the pen or finger leaves the screen, the menu collapses. Selections must be made in the same pen/finger-down gesture as the original reveal. Releasing while an action is in focus selects that action.

Interaction Details

OPEN METHODS... button immediate, and should be nearby: appear to emerge from the button;

When the menu is revealed from an on-screen tab or button, this behavior must take place immediately, preferably accompanied by haptic feedback. The menu should appear to emerge from the tab or button, over-writing the area.

SUB-PORTIONS OPEN... Subvariant - "more" either SK style with menus to the side (scrolling does not count), or Android click-for-more, which also pulls up a different sort of display for the next set...

SKS/LIKE Are locked to viewport, do not scroll...

SCROLL AND SELECT TO GET ITEMS...

RIGHT OR OKAY TO GET SUB-ITEMS... LEFT OR BACK (when available) TO CLOSE SUB-ITEM...

PRESS AND HOLD DOES SOMETHING ELSE...

RIGHT AND LEFT SK... FOLLOW STANDARDS FOR THE OS, THE OPERATOR, ETC... NO universal standard.

*** Android has this. Action opens it. - SKs and things like Bada (visible item, with label maybe, but NOT the menu itself) are variants of this. Also think about weird pullout strips like Pre has. ***

Presentation Details

CLOSED, button only.... 1) Nothing (android), 2) Tabs (SKs) -- SKs tabs even when normally present can hide or fade to give more room...

Closed, on-screen interactions, tab and button... (BADA)

If the design has no on-screen 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.

Within the opened menu, items should be displayed as text, and use supporting iconic elements only when there is room. Most Softkey-like menus are vertical and designed for text density, and do not work well with icons.

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.

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

Drilldown indicator for multiple levels of menu...

Open menu as tree or as layer... if the latter, only one level while trees can go several.

Antipatterns

Within the menu, only allow access to options that can be used.

Examples