NEED A NEW NAME. PERILOUSLY CLOSE TO SELECT LIST, WHICH IS A SELECTABLE VERTICAL LIST!

Problem

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

Solution

XXX The long-established text and textarea input fields are heavily used to accept user-generated text input in all types of computing. Mobile is no exception, and employs these elements in several methods, with variations to meet the needs of mobile devices.

The Input Areas pattern is concerned largely with differences between the typical implementations of these web or desktop computing form fields, and their most common practices within mobile OSs and applications.

For mobile web use of forms, see existing standards from organizations like the W3C for the presentation, interaction and design of these form fields.

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.

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.

Lists -- Mobile devices often present steps in a process or other selections independent of any others. A second action, such as selecting a radio button then submitting, may be redundant or difficult to perform. A single-action selection may be made instead by using a series of Buttons or a single Select List. Multiple selections may also be made by using the multiple Select List. See the Buttons and Select List patterns for additional details on employing these elements.

Interaction Details

XXX Text Input Areas may only be used while in focus. Focus may be granted by scrolling with Directional Entry keys or by direct selection with a pen or finger. Scroll and select devices may require explicit selection of the field by selecting the OK/Enter button. This allows the form to be scrolled through quickly, and only when a field needs to be entered will full focus be granted.

While a field is in focus, pressing the OK/Enter key (when available) will perform different functions depending on the context of use. Web forms will work as they usually do for the desktop web. For fields in mobile applications, OK/Enter will generally commit the field, and transfer focus to the next field in the form -- in a mode ready for entry -- or next item in the list. If no other item is available, the entire form will often be submitted instead.

Whenever content is known to the system, it should be pre-populated so the user does not have to enter it. Pre-populated content is interacted with just as user-entered text, and may be edited, added-to or removed. When large amounts are pre-populated, a Clear Entry item should be provided.

Presentation Details

XXX Focus of a field must always be very clearly delineated, with border, background or other effects. Cursors must always be used when fields are editable, to denote the state change and the position of the text insertion point. See the Focus & Cursors pattern for additional details.

*** Selection mechanisms should look like their intended function. Use web standards for and no other functions should look like them. *** Anti: Select lists should not look like anything else, and buttons (etc.) should not look like select lists. E.g. Seesmic. These tend to follow web standards.

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). Typically it will be gray, and may be italicized or a different size to make the difference more clear under all conditions. Content specifics, such as trailing ellipsis may also serve to make this distinction clearer.

Labels or hints in the field are not like pre-populated text, and will disappear when focus is granted. When all content is removed from the field (or none has been entered) and focus is removed, the label or hint text will appear again.

If hint text is required and the field is not available (due to the label being in the field, or the likelihood of pre-populated information) hint text should appear adjacent to the field, below or to the right.

Whenever possible, validate forms at the field level, as they are typed 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.

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.

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