PressAndHold-Graphic.png|This contextual menu appears based on selection of a piece of text, then the user pressing and holding the OK/Enter key. A small menu appears, and the first item is in focus. Selecting an item will commit that action on the selected text.
PressAndHold-keyboard.png|Pressing and holding a character on this keyboard presents a list of optional accented characters. Dragging over the list then releasing will select and type the character on the screen. The “Sym” modifier allows entry of common symbols; this is a good way to offer even more characters without adding modes or entering the settings and switching languages.
PressAndHold-Anti1.png|This dialogue is too complex for a Press & Hold menu. If data must be entered, launch it from a location that is more robust and integral to the application.
In certain contexts, an alternative cursor-initiated function should be made available. A simple, universal method of applying this mode switch should be provided.
Mobile pointing and selection interactions are relatively simple, and generally one dimensional. Items are pointed at, and selected. In some situations, an alternative selection method can be useful. In many cases, a mode switch on the keypad or in an on-screen menu is unsuitable due to space or in order to preserve the contextual function of the pointing and selection behavior.
In other computing environments, this is performed by the "right click" on the mouse, by the use of buttons on the pen, or by using a keyboard mode switch to change the pointer effects.
In mobile, none of these are very suitable. There is insufficient space on the input area for alternative inputs, touch devices cannot provide a secondary button on user's fingers, and key combinations work poorly for several reasons.
If conventional click actions take effect on "mouse up" (on release of the button or removing the finger from the screen) then Press & Hold of the selection mechanism can be used to initiate an alternative interaction. Within this pattern the web conventions of "mouse up" and "mouse down" will be used to refer to these conditions regardless of the pointing device.
By far the most common is to present a contextual menu of options, or other contextually-relevant optional selections. For example, pressing and holding a the keys for a virtual , on screen Keyboards & Keypads can offer a list of special characters such as accented versions that cannot be easily accessed via Mode Switches.
The same behavior may be used for other functions such as a temporary zoom to aid in selection of a text insertion point, or placing a pinpoint on a map. These behaviors are generally either immediate actions (although a confirmation or undo may be provided) or they only function while the mouse is down. These behaviors are not entirely settled so the remainder of this pattern will discuss only the functionality and appearance of the contextual selection variation.
Press & Hold works equally well with any hardware interactive selection. Buttons, pens and fingers all may press and hold equally well.
The length of time needed to hold before the action occurs should be about 1/2 second. This can be varied greatly based on testing user behaviors with the interface. The menu or other function must appear immediately after this timing is reached, and with absolute consistency in all locations.
For direct entry methods especially, a certain amount of jitter must be allowed for, instead of detecting the mouse-down time as all in-motion. This should be around 10-20% of the minimum target size for touch devices.
The menu may work in one of two modes:
- The mouse is kept down while scrolling to the item to be selected. Selection is made by mouse up when the desired selection is in focus, at which point the action occurs and the menu is dismissed. Releasing the mouse without moving after the menu appears, or by mouse up outside the menu area entirely will dismiss the menu without selection.
- Once the menu appears, the mouse is released and the menu remains in place as a dialogue. The user performs conventional scroll or point and selection activities. Once a selection is made, it is committed and the dialogue is dismissed.
Both of these should be semi-modal dialogues; actions outside the menu will dismiss the dialogue, but not perform the action on the screen beyond.
The decision as to which to use should be based on the manner in which the remainder of the OS functions generally. Avoid mixing the two methods within a single interface.
Before the hold time has been reached, and the alternative action occurs, an indicator that Press & Hold is about to take place may be shown. The timing when this appears is variable, but about halfway through the time is a reasonable starting point. The indication must be visible past any on-screen indicators, so if a finger must be larger than the finger or adjacent to it, and should indicate progress to count down to the activation time. A common symbol is to draw a circle around the current in-focus item or the centroid of the contact area. This is timed so the context menu appears as the circle is completed.
This timing indicator will disappear when the context menu appears.
Menus resulting from Press & Hold behaviors must appear adjacent to the in focus item or the contact point. Ideally, the menu will emerging directly from the option selected. If there is no distinct item (such as for selecting a portion of a map or image) either an object can be created, or the menu may simply appear from under the selection point.
Menus must be clearly separate from the rest of the interface, so should use border and shadow effects to indicate they are largely associated with the pointing device, and not just the screen. Typically, these will appear to be floating above the interface.
Avoid overly complex dialogues offered via Press & Hold behaviors. Stick with individual selectable items, and about complex selectors, text entry and submit buttons. If such dialogues are needed, present them via a Revealable Menu, Fixed Menu, or link within an Annotation.
Do not absolutely rely on use of a Press & Hold behavior. As it has no affordance, the function may not be discovered or remembered by users. Attempt to instruct the users in some manner as to this functionality.
Use these behaviors consistently, and as pervasively through the device UI as possible. Once learned, if it fails irregularly, this will violate the user's mental model and may lead to general disuse of the feature.