Problem

A method must be provided for users to easily make single or multiple selections from pre-loaded lists of options.

A typical select, or “pulldown” element, along side other form elements. When selected, a Pop-up scrolling list appears, from which one item can be selected.

Solution

Mobile devices, even more than other computing devices, can use forms to good effect for selection from already-provided information. This can save greatly on user input and

Extending the ease of entry, mobiles have several regularized variations and sub-types of single and multiple selections. Consider the entire range of variants within this pattern before completing the design of any selection mechanism.

For mobile web use of standard forms, see existing standards from organizations like the W3C for the presentation, interaction and design of these form fields. When making mobile specific websites, feel free to also consider use of the other variations outlined below.

Variations

Several variations exist, including some which do not appear to be form elements based on conventional webform understanding. These can be categorized into three basic types: Single-select: Used in-conjunction with other form elements, a single item may be selected from a provided list. When all form selections are made a Button or other submission element (such as a Softkey) is used to submit the form.

Lists are heavily used in mobile devices, either as single select, where only one click selects and submits, or for multiple selections. Long lists should usually appear as scrolling lists, using the Vertical List patterns, but shorter ones like the Power key options at the right, should more clearly express the actions, by using lists of buttons instead.

Multiple-select: Used either in-conjunction with other form elements, or as a list on it's own. One, several or all items from a provided list may be selected. Items already selected (or pre-selected by the system) may be de-selected. When all form selections are made a Button or other submission element (such as a Softkey) is used to submit the form.

Single click: Used when there is no form, or this is the only element, a single item may be selected from a provided list. This does not mean it may be the only interactive item on the page. No button is required to submit the form, as the single selection is committed immediately.

Radio buttons and checkboxes are most valuable in conventional forms, such as this mixed form, with conventional submit buttons. Some handsets use the Softkeys as their default buttons.

Interaction Details

Any of the types of Form Selections may be viewed in their passive state at any time, or while not in focus. They may be scrolled through and selected (or deselected, if permissible) while the selection mechanism is in focus.

The definition of focus here may not be entirely clear, but generally does not concern the end user. For the sake of better understanding, the following (somewhat circular) definition will suffice: any time the list can be scrolled through, it is in focus. Examples may help.

Whenever content is known to the system, or it has been entered by the user previously, it should be pre-selected in the field. Pre-populated content is interacted with just as a user-entered selection, and may be deselected or another selection made.

Presentation Details

Focus of a field and selection item must always be very clearly delineated, with border, background or other effects. See the Focus & Cursors pattern for additional details.

Selection mechanisms should always appear as their intended function. Use current web standards as a heuristic evaluation for the design of such mechanisms; even if OS standard form widgets are used, assure they are understandable to the typical user. Do not mix functions with appearances, such as allowing multiple selections with radio buttons.

Labels should accompany the field whenever space provides, and may be abbreviated or iconic to save space. Labels adjacent to the field should be to the left or above the field, and must be close enough to make the relationship clear. Use regular alignment and designed grids to assure clarity.

Labels may be placed inside the form field itself. This same method may be used, when labels outside the field are provided, for "hint text" to give information on the type or limits of information to be entered in the field. Label or hint text in the field must be clearly differentiated from actual content (whether user-entered or pre-populated). This is usually by language or formatting; "Select a state..." is clearly different at a glance from "Kansas."

Labels in the field are generally selection text, but invalid and should not be submitted (or not have an assigned value, just a label). If hint text is required, such as reasons for entering the information, or clarification about what the information means, it should appear adjacent to the field, below or to the right.

Whenever possible, validate forms at the field level, as they are selected, or when the field looses focus (indicating the user has completed entry). Successful validation can be indicated adjacent to the field, near any hint text. Errors in validation, indicating improper entry, should appear in the same location. The relevant hint text, such as field constraints, can be highlighted if space allows.

Validation may also allow automatic selection of items. For example, on an address form if the user enters a ZIP code (postal code) the corresponding region information may be filled in as well.

Full screen entry methods are the default for J2ME and some entire OSs. Especially for selection lists list this, they are just confusing, as the user is removed from the context entirely. In this case, the state is a part of a larger address, and the context (shipping) may not be the default case the user considers. Staying in context can prevent errors, mistakes and confusion.

Antipatterns

Do not use full-screen input panels as the selection mechanism for small components such as pull-downs. In several OSs or environments selection of any input or select field will display the choices as a full-screen panel. This removes the user from any context, and makes hints and other text invisible. Even if working in such a platform, there are workarounds, so avoid this whenever possible.

Never over-use input methods. If a single Select List or button list is used, do not also have a submit button to commit the action.

Use the right type of selector for the information to be entered. Do not attempt to provide hints on how to multi-select from a pull-down, but use a multi-select mechanism (a checkbox or Select List) instead.

Examples