Differences between revisions 2 and 10 (spanning 8 versions)
Revision 2 as of 2011-03-29 20:16:54
Size: 7064
Editor: shoobe01
Comment:
Revision 10 as of 2011-03-30 03:55:04
Size: 9721
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
NEED A NEW NAME. PERILOUSLY CLOSE TO SELECT LIST, WHICH IS A SELECTABLE VERTICAL LIST! {{attachment:|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.|align="right"}}

{{attachment:|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.|align="right"}}

{{attachment:|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.|align="right"}}

{{attachment:|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.|align="right"}}

Line 4: Line 12:
A method must be provided for users to easily make selections from pre-loaded lists of options. A method must be provided for users to easily make single or multiple selections from pre-loaded lists of options.
Line 8: Line 16:
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. 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
Line 10: Line 18:
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. 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.
Line 12: Line 20:
For mobile web use of forms, see existing standards from organizations like the W3C for the presentation, interaction and design of these form fields. 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.
Line 16: Line 24:
 * Select -- Generally called a "drop-down" or "pull-down" list.
 * Radio --
 * Checkbox --
 * 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]]'''. See the '''Buttons''' and '''Select List''' patterns for additional details on employing these elements.
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.
 * Select - The "drop-down" or "pull-down" list as seen on desktop and web forms can be placed within a mobile application. When selected, it opens as an anchored layer, allowing scrolling and selection.
 * Radio - Each item in a list is preceded by a line-item selection mechanism, just like a radio button list in desktop or web forms. These work best for vertical text lists. In other cases, they may be un-recognized, or not easily associated with a particular item.
Line 21: Line 29:
because differences can be fuzzy, and some are bad implementation, e.g. J2ME/S60 default full-page input; (NOT on-page lists or simple nav: refer to Information Display chapter above) '''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.
 * Checkbox - Each item in a list is preceded by a line-item selection mechanism, just like a checkbox list in desktop or web forms. Used in-conjunction with other form elements, these work best for vertical text lists, but can be made to work in multiple columns and for other types of selections. For complexly-displayed multiple selections, try the next variation.
 * Multiple Select List - A variation of the '''[[Select List]]''' pattern, where each item displayed has an associated checkbox, allowing selection and deselection.
Line 23: Line 33:

Text - Text fields are single-line entry methods. For mobile, these should usually be restricted to only accepting as much input as can be seen in the form, though exceptions may be made, such as for URL entry.

Textarea - Textarea field are multi-line entry methods, with a fixed display heights. They are often configured to accept an arbitrary (though not infinite) amount of text, and are provided with a vertical scrolling mechanism to display text which does not fit in the field.

Convertible - In certain cases, such as the numeric entry field for the '''[[Dialer]]''', mobile devices may display an entry field that appears to be a Text field, but is in fact a Textarea. This variation is used due to the limited space on mobile devices -- the field is only as large as is needed at any one time, and expands to additional lines as more text is entered.
'''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.
 * Button List - Not radio buttons, but actual form-submission types of '''[[Buttons]]'''. A list of these can be provided to choose from. Only used for short lists, where no scrolling is required and the action is committed immediately.
 * Select List - When a longer list is needed, the setting does not take immediate effect or confirmation of the setting should take place inline (by showing the current state in the same display, refreshed) a '''[[Select List]]''', usually a simple text '''[[Vertical List]]''' will serve the purpose.
Line 32: Line 39:
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. 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.
Line 34: Line 41:
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. 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.
 * A "dropdown" list is not in focus when it appears as a single line. When the field is in focus, it will open to reveal what is functionlly a scrolling, vertical '''[[Select List]]'''. Whenever the field is in focus, for a scroll-and-select device, one item within the list will be in focus, and using the OK/Enter button will commit the field selection and close the dropdown. For touch or pen devices, no items are in focus, and pointing at an item in the opened list will select and close the list.
 * Any list used inline, in the context of a page, such as radio button list can be considered to be in focus at all times. The individual items are selected in the same manner as for dropdown lists, though the list itself does not change, just the selection mechanism.
 * Select lists are mostly used full-page, so the list is much like a dropdown, in that it scrolls as a complete list. When a multi-select list, this works like an inline list, and selection only changes the indicator. When a single-select list, it is more like the dropdown list, and closes the list or continues to the next state.
Line 36: Line 46:
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. 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.
Line 40: Line 50:
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. 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.
Line 42: Line 52:
An '''[[Input Method Indicator]]''' of some sort should be used to denote the available methods. 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.
Line 46: Line 56:
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 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."
Line 48: Line 58:
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. 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.
Line 50: Line 60:
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 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.
Line 52: Line 62:
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. 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.
Line 56: Line 66:
Do not use full-screen input panels. In several OSs or environments selection of an '''Input Area''' will display a common full-screen panel. This removes the user from any context, makes hints and other text invisible, and makes implied limits (such as the difference between a text field and textarea) invisible. Even if working in such a platform, there are workarounds, so avoid this whenever possible.
*** Discuss full-page, and large modal popups a lot; they are a fact of small devices and many OSs so make them not /just/ an anti-pattern. Plenty of how to make them good like title, make scroll clear and line by line, with a position indicator, jumping by letter, etc.***
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.
Line 59: Line 68:
*** 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. 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.
Line 61: Line 70:
Form fields, and especially text '''Input Areas''' are among the most prone to frustration and error due to free-form entry. Design carefully to avoid confusion, and use supporting patterns such as '''[[Autocomplete & Prediction]]''' and the principles of '''[[Cancel Protection]]''' to make entry more efficient and speedy. 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.

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.

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.

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.

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.

Problem

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

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.

  • Select - The "drop-down" or "pull-down" list as seen on desktop and web forms can be placed within a mobile application. When selected, it opens as an anchored layer, allowing scrolling and selection.
  • Radio - Each item in a list is preceded by a line-item selection mechanism, just like a radio button list in desktop or web forms. These work best for vertical text lists. In other cases, they may be un-recognized, or not easily associated with a particular item.

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.

  • Checkbox - Each item in a list is preceded by a line-item selection mechanism, just like a checkbox list in desktop or web forms. Used in-conjunction with other form elements, these work best for vertical text lists, but can be made to work in multiple columns and for other types of selections. For complexly-displayed multiple selections, try the next variation.
  • Multiple Select List - A variation of the Select List pattern, where each item displayed has an associated checkbox, allowing selection and deselection.

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.

  • Button List - Not radio buttons, but actual form-submission types of Buttons. A list of these can be provided to choose from. Only used for short lists, where no scrolling is required and the action is committed immediately.

  • Select List - When a longer list is needed, the setting does not take immediate effect or confirmation of the setting should take place inline (by showing the current state in the same display, refreshed) a Select List, usually a simple text Vertical List will serve the purpose.

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.

  • A "dropdown" list is not in focus when it appears as a single line. When the field is in focus, it will open to reveal what is functionlly a scrolling, vertical Select List. Whenever the field is in focus, for a scroll-and-select device, one item within the list will be in focus, and using the OK/Enter button will commit the field selection and close the dropdown. For touch or pen devices, no items are in focus, and pointing at an item in the opened list will select and close the list.

  • Any list used inline, in the context of a page, such as radio button list can be considered to be in focus at all times. The individual items are selected in the same manner as for dropdown lists, though the list itself does not change, just the selection mechanism.
  • Select lists are mostly used full-page, so the list is much like a dropdown, in that it scrolls as a complete list. When a multi-select list, this works like an inline list, and selection only changes the indicator. When a single-select list, it is more like the dropdown list, and closes the list or continues to the next state.

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.

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

Form Selections (last edited 2011-07-31 23:39:35 by shoobe01)