Screen-Based Controls (Widgets)

In order to interact with a Web site, users usually require the use of screen-based controls (sometimes known as 'widgets'). Besides the pervasive link, commonly used screen-based controls include pushbuttons, radio buttons, check boxes, drop-down lists and entry fields. Designers should ensure that they use familiar widgets in a conventional or commonly-used manner.

When pushbuttons are used, ensure that they look like pushbuttons and that they are clearly labeled. In some cases, the pushbuttons will need to be prioritized to facilitate their proper use.

Radio buttons are used to select from among two or more mutually-exclusive selections. Check boxes should be used to make binary choices, e.g., 'yes' or 'no.' Drop-down lists are generally used to select one item from among many. To speed user performance, show default values when appropriate, and do not limit the number of viewable list box options.

Entry fields are used when completing forms and entering text into search boxes. Designers should try to minimize the amount of information entered by users. Each entry field should be clearly and consistently labeled, with the labels placed close to the entry fields. Designers should also clearly distinguish between 'required' and 'optional' data entry fields, and attempt to minimize the use of the Shift key.

To facilitate fast entry of information, designers should automatically place the cursor in the first data entry field, provide labels for each field (e.g., pounds, miles, etc.), and provide auto-tabbing functionality. In order to increase accuracy of data entry, partition long data items into smaller units, enable the software to automatically detect errors, and do not require case-sensitive data entries. Showing users their data entries can increase accuracy. For experienced users, the fastest possible entry of information will come from allowing users to use entry fields instead of selecting from list boxes.


Distinguish Required and Optional Data Entry Fields:

• Distinguish clearly and consistently between required and optional data entry fields.
• Users should be able to easily determine which data entry fields are required and which are optional. Many Web sites are currently using an asterisk in front of the label for required fields. Other sites are adding the word 'required' near the label. One study found that bolded text is preferred when compared to the use of chevrons (>>>), checkmarks, or color to indicate required fields.

Label Pushbuttons Clearly:

• Ensure that a pushbutton’s label clearly indicates its action.
• The label of a pushbutton should clearly indicate the action that will be applied when the pushbutton is clicked. Common pushbutton labels include 'Update,' 'Go,' 'Submit,' 'Cancel,' 'Enter,' 'Home,' 'Next,' and 'Previous.'

Label Data Entry Fields Consistently:

• Ensure that data entry labels are worded consistently, so that the same data item is given the same label if it appears on different pages.
• If possible, employ consistent labeling conventions. For example, do not use single words or phrases for some labels and short sentences for others, or use verbs for some and nouns for others.

Do Not Make User-Entered Codes Case Sensitive:

• Treat upper- and lowercase letters as equivalent when users are entering codes.
• Do not make user-entered codes case sensitive unless there is a valid reason for doing so (such as increased security of passwords). If required, clearly inform users if they must enter codes in a case specific manner. When retaining data entered by users, show the data as it was entered by the user.

Label Data Entry Fields Clearly:

• Display an associated label for each data entry field to help users understand what entries are desired.
• Employ descriptive labels that clearly, concisely, and unambiguously define the required entry. Make labels distinct enough so that readers do not confuse them with the data entries themselves. This can be done by bolding the labels or providing other visual cues, such as an asterisk.
• Do not create new jargon when labeling data entry fields. Use common terms (e.g., male, female) rather than arbitrary labels (e.g., Group 1, Group 2). If the meaning of a proposed label is in doubt, conduct usability testing with an appropriate sample of qualified users.

Minimize User Data Entry:

• Do not require users to enter the same information more than once.
• Requiring re-entry of data imposes an additional task on users, and increases the possibility of entry errors. When entries made by users on one page are required on another page, the computer should retrieve the original entries, rather than requiring re-entry of the same information. In general, require users to make as few entries as possible.

Put Labels Close to Data Entry Fields:

• Ensure that labels are close enough to their associated data entry fields so that users will recognize the label as describing the data entry field.
• All labels and related information should be close to the data entry field to enable users to easily relate the label and entries required.

Allow Users to See Their Entered Data:

• Create data entry fields that are large enough to show all of the entered data without scrolling.
• Users should be able to see their entire entry at one time. There always will be some users who will enter more data than can be seen without scrolling; however, try to minimize the need to scroll or move the cursor to see all the data for that field. If there is a character limit for a particular field, state that near the entry field.
• Designers should be particularly aware of the length of data entry fields used for entering search terms. One study found that this entry field should be at least 35-40 characters long to accommodate ninety-five percent of search terms being used.

Use Radio Buttons for Mutually Exclusive Selections:

• Provide radio buttons when users need to choose one response from a list of mutually exclusive options.
• Radio buttons should be used when there is a need to select from among mutually exclusive items. Users should be able to click on the button or its text label to make their selection. Assign one of the radio button choices as the default when appropriate. One study reported that for making mutually exclusive selections, radio buttons elicit reliably better performance than drop-down lists. Radio buttons are also preferred over both open lists and drop-down lists.

Use Familiar Widgets:

• Use widgets that are familiar to your users, and employ them in their commonly used manner.
• Do not assume that all users are familiar with all available widgets. Unfamiliar widgets will slow some users, and cause others not to use the widget because they do not know how to make it work properly. For instance, one study showed that some users, particularly older users, do not know how to use a drop-down list.
• In choosing widgets, designers typically consider such issues as the amount of available screen 'real estate,' reducing the number of user clicks, and whether the user will be choosing one from among many items, or several items at once. Usability test the performance and acceptability of widgets to ensure they do not confuse or slow users.

Anticipate Typical User Errors:

• Use the computer to detect errors made by users.
• Do not expect that users always will make correct entries. Anticipate possible user errors, and when possible, allocate responsibility to the computer to identify these mistakes and suggest corrections. For example, if a date is entered as 'February 31,' the computer should generate an error message asking for a revised entry.
• Design the site's search engine (and other places where users enter data) to accommodate common misspellings and certain other errors.

Partition Long Data Items:

• Partition long data items into shorter sections for both data entry and data display.
• Partitioning long data items can aid users in detecting entry errors, and can reduce erroneous entries. For example, it is easier to enter and verify a ten digit telephone number when entered as three groups, NNN-NNN-NNNN. Similarly, ZIP+4 codes and Social Security numbers are best partitioned.

Use a Single Data Entry Method:

• Design data entry transactions so that users can stay with one entry method as long as possible.
• Do not have users shift back and forth between data entry methods. Requiring users to make numerous shifts from keyboard to mouse to keyboard can substantially slow their entry speed.

Prioritize Pushbuttons:

• Use location and highlighting to prioritize pushbuttons.
• If one pushbutton in a group of pushbuttons is used more frequently than the others, put that button in the first position. Also make the most frequently used button the default action, i.e., that which is activated when users press the Enter key.
• One study reported that designers should place the button most likely to be clicked on the left side of a two-button set of buttons. This button arrangement allows the user to read the first button label, and since it is the most likely selection, click on that button immediately. Some users look at the left and then right button before making a selection, preferring to be fully informed before submitting a response.

Use Check Boxes to Enable Multiple Selections:

• Use a check box control to allow users to select one or more items from a list of possible choices.
• Each check box should be able to be selected independently of all other check boxes. One study showed that for making multiple selections from a list of non-mutually exclusive items, check boxes elicit the fastest performance and are preferred over all other widgets. Users should be able to click on either the box or the text label.

Label Units of Measurement:

• When using data entry fields, specify the desired measurement units with the field labels rather than requiring users to enter them.
• Designers should include units such as minutes, ounces, or centimeters, etc. as part of the data entry field label. This will reduce the number of keystrokes required of users (speeding the data entry process), and reduce the chance of errors.

Do Not Limit Viewable List Box Options:

• When using open lists, show as many options as possible.
• Scrolling to find an item in a list box can take extra time. In one study, an open list that showed only three (of five) options was used. To see the hidden two items, users had to scroll. The need to scroll was not obvious to users who were not familiar with list boxes, and slowed down those that did know to scroll.

Display Default Values:

• Display default values whenever a likely default choice can be defined.
• When likely default values can be defined, offer those values to speed data entry. The initial or default item could be the most frequently selected item or the last item selected by that user. In general, do not use the default position to display a heading or label for that widget.

Place Cursor in First Data Entry Field:

• Place (automatically) a blinking cursor at the beginning of the first data entry field when a data entry form is displayed on a page.
• Users should not be required to move the mouse pointer to the first data entry field and click on the mouse button to activate the field. Designers should consider, however, that programming this automatic cursor placement might negatively impact the performance of screen reader software.

Ensure that Double-Clicking Will Not Cause Problems:

• Ensure that double-clicking on a link will not cause undesirable or confusing results.
• Many users double-click on a link when only one click is needed. Developers cannot stop users from double-clicking, but they should try to reduce the negative consequences of this behavior. Usability testing has indicated that if users start with quick double-clicks, they tend to continue to do this for most of the test. Sometimes, when both clicks are detected by the computer, the first click selects one link and the second click selects a second link, causing unexpected (i.e., puzzling) results.

Use Open Lists to Select One from Many:

• Use open lists rather than drop-down lists to select one from many.
• Generally, the more items users can see in a list (without scrolling), the faster their responses will be, and the fewer omission errors they will make. Ideally, users should be able to see all available items without scrolling.
• When compared with drop-down lists, open lists tend to elicit faster performance primarily because drop-down lists require an extra click to open. However, if a list is extremely long, a drop-down list may be better. The available research does not indicate the upper number limit of items that should be displayed in a list.

Use Data Entry Fields to Speed Performance:

• Require users to enter information using data entry fields (instead of selecting from list boxes) if you are designing to speed human performance.
• At least two studies have compared the effectiveness of text entry versus selection (list boxes) for entering dates and making airline reservations. Both studies found text entry methods were faster and preferred over all other methods. However, use of text entry fields tends to elicit more errors.

Use a Minimum of Two Radio Buttons:

• Never use one radio button alone.
• Use at least two radio buttons together. If users can choose not to activate any of the radio button choices, provide a choice labeled 'None.'

Provide Auto-Tabbing Functionality:

• Provide auto-tabbing functionality for frequent users with advanced Web interaction skills.
• Auto-tabbing can significantly reduce data entry times for frequent users by not requiring them to manually tab from field to field.

Minimize Use of the Shift Key:

• Design data entry transactions to minimize use of the Shift key.
• If possible, designers should not require users to enter characters that require the use the Shift key. Using the Shift key imposes a demand for extra user attention and time. For example, the designer can include symbols such as the dollar or percent sign near data entry fields rather than requiring users to enter those characters. Designers also can treat upper- and lowercases as equivalent when entered by users.

Source:[usability.gov]