Screen-Based Controls
By "screen-based controls," the author means the array of standard elements that users encounter on the Web - such radio buttons, checkboxes, select lists, buttons, etc. - usually in the context of data-input forms.
EN; The author refers to these as "widgets," but that is contrary to the current understanding of the term, so I'll stick to the more generic phrase.
1. Distinguish between required and optional inputs (5:3)
Several methods of highlighting required fields are mentioned (asterisks, color, the word "required," icons, etc.) - none is especially preferred to the others.
2. Label buttons clearly (5:2)
For years, submit buttons were labeled "submit" - a descriptive phrase that indicates the function of the button ("search," "place my order", etc.) is preferable.
3. Label data entry fields consistently (4:3)
Be consistent in labels for form input fields across a site. If you ask for a "cell phone number" in one place, don't ask for "mobile phone" in another.
4. Accept input regardless of case (4:2)
Allow users to enter content in any case (upper/lower/mixed) rather than throwing an error if there is a case mismatch. One exception: case-sensitivity is acceptable in passwords.
5. Label date entry fields correctly (4:3)
Each field where a user is expected to enter data should have a clear and unambiguous label that indicates the type of input expected in terms that the user can understand (not jargon or business-specific).
These labels should be visually differentiated from the data entry fields. (EN: I believe they are by default, but if style sheets are used to alter the appearance of the entry field, it's important to maintain this differentiation).
6. Minimize User Data Entry (4:3)
Do not require users to enter data more than once. Example: for billing and shipping address, provide a method for using the same address for both and require the user to enter it only once.
Another example (a login that remembers the user's login name in the future) implies that it is a good practice to reference user data to pre-populate form fields or render them unnecessary.
7. Place labels close to entry fields (3:2)
Labels should be placed close to entry fields so the reader immediately recognizes that the field and label are associated. The example given shows a form in a table layout, where labels are left-aligned and fields are right-aligned, such that there is considerable white-space between them.
8. Allow users to see the data they entered (3:3)
The examples given show form fields that are too short - if a box for the user's address is only twenty characters long, some of their content will run off the screen. Also, where long inputs are necessary, use the text area input type, which provides the user easy access to data that may have scrolled off screen.
9. Use radio-buttons for mutually exclusive selections (3:4)
On the surface, this seems self-explanatory: the difference between radio buttons and check boxes is the number of items that can be selected. However, the author also states that radio buttons are "preferred" over select lists.
EN: This seems contrary to common practice - when there are a large number of options in a list, or when several lists are on the page - the use of select objects can compact the form - it would seem logical that keeping the form on a single screen is more valuable than making the user scroll, especially if they must scroll to see the various options in a single list. Additionally, drop-down lists are more accessible via keyboard (typing a few characters to jump to an item versus tabbing through radio buttons individually). My sense is that his sources, dating back to the mid-nineties, are out of date.
10. Use familiar input devices (3:3)
It is possible, by using JavaScript, to alter the behavior and function of input devices (example: making a text field behave as if it were a select object). Doing so will confuse users (slowing down performance as they must learn an unconventional behavior) and hinder accessibility.
11. Anticipate typical user errors (3:2)
The first example prompts the user to enter a date in a specific format - zero-padding a month or using a two-digit rather than four-digit year to make the format MM/DD/YY to match system requirements. (EN: later advice indicates that you should anticipate the various formats and accept anything, adjusting the format programmatically rather than making the user do so).
Another example corrects the spelling of terms entered into a search engine (EN: some debate over whether this should be done automatically, or whether the search terms should be used as entered with a separate suggestion of the correct spelling)
11. Partition long data items (3:2)
"Partitioning" refers to breaking a single field into separate components: rather than a single field for phone number, provide three fields for each segment; two fields for ZIP+4; etc.
EN: This is dead wrong. Requiring users to tab through three fields to enter a phone number is cumbersome, and it prevents the ability to copy and paste data. Don't do this.
13. Use a single data-entry method (3:4)
If possible, be consistent in the use of data-entry deceives (for example, use all text fields or all select lists).
EN: I don't think this "consistency" is entirely possible in all cases - a form that is all select lists or radio buttons seems more like an artistic statement rather than a usable form. Moreover, the choice of data-entry method is probably better made by the nature of the data (specific input types make specific types of data easier to enter)
14. Prioritize Buttons (3:3)
Where buttons are presented in sets (submit and reset), place the button the user is most likely to use on the left to facilitate use and minimize the likelihood of wrong choices.
EN: Later advice is to ditch the "reset" button, and I'm hard pressed to think of another reason a form might have multiple buttons in the same location.
15. Use checkboxes to enable multiple selections (3:3)
Using checkboxes rather than radio buttons is a matter of function rather than design, but the author suggests that the multiple select object is not as easily recognized by users as a method by which multiple items can be selected.
EN: I think space is a factor, as in the earlier item (9) regarding radio buttons: if the universe of possible options would require the user to scroll to view them all, a select object may be a better option.
16. Label units of measurement (3:3)
When a measurement of length, width, area, etc. are required, explicitly state the unit of measurement (inches, pounds, etc.) to reduce the chance of options.
It is also implied that, to accommodate users domestically (where the imperial system is preferred) and abroad (where metrics are preferred), it is more efficient to provide multiple options for a form rather than requiring the user to select the units they are using.
17. Do not limit viewable list box options (3:3)
Studies conflict on the length of list boxes (select objects that scroll). One study suggests a list of three to five is sufficient, others suggest that users may select from visible alternatives and neglect to scroll to discover better ones. The author's suggested compromise is to show "as many options as possible" given the available space.
17. Display default values (3:2)
Populate form fields with default values when a specific value is anticipated, either through the choices made by users in general, or by the user's previous responses to similar questions.
EN: I don't disagree, but the research was done before the "auto fill" feature was added to browsers, which does this without any effort on the designer's part. Accommodating auto-fill probably requires designers to use conventional input field names ("name" and "address" rather than something cryptic)
Related, do not use a form field to display a label or provide instructions (e.g., "type your comments in this space")
19.Give focus to the first data entry field (2:2)
The author relates advice to use JavaScript to place the focus on the first data entry field of a form, but concedes that this may hinter the performance of screen reader software.
EN: I would have to disagree with this advice as well - the effort saved is minimal, not worth the trade-off. However, technological advances since the most recent study cited make it possible for designers to alter the tab-order from its default setting - so making the first data field the first thing that will be featured when the user taps the tab key may be an acceptable compromise.
20. Ensure that double-clicking will not cause problems (2:2)
The author cites a study that indicates "many" users double-click links and buttons in the browser, and that there are instances in which this could cause confusing results.
EN: I disagree with the premise (the study cited is from 2000, when there were a high proportion of novice users - users in general have more experience these days) and cannot conceive of a situation where a double-click would cause a problem.
21. Use open lists to select one from many (2:2)
The implication is that a drop-down list (which saves space) is more difficult to use than an open list, where all options are immediately visible without scrolling.
EN: See the note on radio buttons (number 9) - also note the low scores in terms of relevance and research support for this guideline.
22. Use data entry fields to speed performance (2:5)
Enabling users to select items from select objects results in slower performance, but far fewer errors than requiring them to type content into an open text field. The author implies that it is a worthwhile trade-off.
EN: I would generally agree, though the trade-off should be considered carefully. Especially where a site's audience is composed of more proficient typists, the trade-off may not favor use of select objects. There may also be specific instances where even general users find a select object obstructive (typing a two-letter state code rather than selecting from a list of fifty options)
23. Use a minimum of two radio buttons (2:2)
Specifically, never use a single radio button - if it's a single option, use a checkbox if it is optional, or omit the field if it's a mandatory item (no choice is possible to the user).
EN:It first, it seems only a moron would do this - but when forms are dynamically generated from a database, there may be conditions where some users have multiple options and others only one. Handle that elegantly.
24. Provide auto-tabbing functionality (2:3)
Where possible, use JavaScript to move the focus to the proceeding entry field when the user has finished entering data.
EN: This is bad advice. Users expect to have to tab to the next data field, because that is default browser behavior. Auto-tabbing often causes frustrations because the user will click tab anyway and skip a field. Also, if a mistake is made, they will have to navigate backward to correct it.
25. Minimize use of the shift key (1:4)
In addition to the advice to accept input regardless of case (number 4), consider whether it's necessary to force the user to enter symbols, such as a "dollar sign" when entering currency or "http://" when entering a URL. Placing the symbol beside the box is a visual cue that is does not need to be entered.
EN: Even though entering a symbol is not necessary, and there are visual cues the user shouldn't bother, some people still will do so. Parse the user's input to remove it automatically rather than throwing an error.