Mobile: Revealable Menu

Problem

Often you will not be able to fit all functions for a view on the screen. A method must be provided to access these optional functions.

Solution

Implement a revealable menu that slides into view from the bottom or side of the viewport. When the user selects a key or an icon, or performs a gesture, the revealable menu is displayed with content relevant to the current state of the application. Often the OS dictates the general style of the menu structure, mainly because the user is likely familiar with the interaction. There is leeway in this implementation if variations are called for. Soft Keys - hardware buttons tied to on-screen labels, typically on feature phones - are the standard version of this.

Variations

The soft key style uses one or more hardware buttons (or a portion of the touch/pen area outside the display) to reveal an option menu. When closed, these may or may not display a tab and label indicating their presence.

Soft key on-screen displays also present a tab or button, usually along the bottom edge of the viewport. The closed state is always visible since this is the method used to access the function.

Gesture-based revealable menus usually have no on-screen visibility. When the user swipes from the edge of the viewport, the menu accompanies the gesture and moves into the viewport at the same speed. This is generally not persistent; when the finger or pen leaves the viewport, the menu collapses. Selections must be made in the same gesture as the original reveal. Releasing while an action is in focus selects that action.

Another variation combines gesture menu reveal methods with the on-screen button. When activated, the menu appears via another action, such as sliding in from one side.

Items within the menu often reveal submenus, or lists of additional features. These may either follow the same principles as the top level of the menu and appears as an attached subset, or appear as a freestanding menu, usually as a Select List or Grid of Items.

How

Treat revealable menus as modal dialogs. For touch and pen devices, selection outside the menu area may clear the menu instead of being ignored. This is especially true if the menu does not obscure the background when open. You should not allow the user to select items in the parent window while the revealable menu remains open.

You can add the dedicated hardware "back" key. When present, this is the preferred method since the user will be accustomed to using it for similar functions.

A soft key or on-screen tab will change to "Cancel." This key must be introduced in the items available for selection, and is not locked due to the modality of the revealable menu itself.

A close function may be added to the menu either as a selectable menu option or as a desktop-like close button in the top right corner.

The function that launched the revealable menu may be used as a toggle. When it is available and not obscured by the opened menu, selection when the menu is open will close the menu.

For touch or pen devices, selecting outside the revealable menu will dismiss the menu.

The vertical opening panels are usually for display sub-menu items, while horizontal opening panels are suitable for large content areas. When implementing the accordion it is important to get the following aspects right:

• Animate the opening of panels so that users get feedback about what is happening. The animation should be subtle which means that it should last no more than 250ms
• Allow navigation using the keyboard up and down keys
• Highlight the current panel so the user can distinguish open panel headers form closed panel headers
• Make sure the total size of the accordion can grow or shrink in size. Some implementations fix the height of each panel which leads to undesirable situations when panels contain only little content.

Antipatterns

Modal design can be difficult to communicate, especially if OS standard implementations are not used, or if the user is not accustomed to the platform.

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

Soft key 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 universal for all devices using the OS. Most application frameworks allow specifying something like "primary" or "secondary" as soft key identifiers; use these instead of "left" and "right" to ensure that your application complies with the standard of the device.

Avoid too many menu levels. Due to the viewport size, only one submenu level should be provided.

Examples