1. Organization and Layout
- Design and organize the form to support the task
- Organize groups of items related semantically by:
- sequence of use,
- frequency of use, and/or
- relative importance.
- Keep the number of groups to a minimum, while limiting the size of groups to 12-14 chars wide and 6-7 lines high (within 5 degree visual angle).
- Use white space to:
- create balance and symmetry,
- lead the eye in the appropriate direction.
- Separate logical groups by spaces, lines, color, or other visual cues.
- Screens:
- High-frequency users + slow system RT --> Minimize the number of screens.
- Low-frequency users + fast system RT --> Maximize screen clarity.
- Keep related and interdependent items on the same screen.
2. Caption and Field Design
- In western cultures:
- for single fields, place caption to left.
- for list fields, place caption above.
- left justified above alpha lists.
- right justified above numeric lists.
- Justify captions and fields according to user, task, and data type.
- Separate the (longest) caption (in a left-justified group) from its field by no more than 1-2 spaces (following the delimiter, for example, a colon). Separate one caption field group from another by three or more spaces horizontally, or by one or more lines vertically.
- Break up columnar fields or long columns of single field items into groups of 5 separated by a blank line.
- Provide distinctive field group and section headings in complex forms.
- Distinguish fields (i.e., contents) from captions (i.e., labels).
- Captions should be brief, familiar and descriptive.
- Indicate the number of character spaces available in a field.
- Indicate when fields are optional.
3. Input Formats
- Consider providing system completion of unambiguous partial input.
- Consider providing pop-up or pull-down menus for fill-in forms with many but well-defined entry options.
- Avoid complex rules for entering data in the various fields of a form.
- Provide meaningful (in field) groupings to break up long input formats (chunking).
- Provide defaults whenever possible. Allow simple (single key) acceptance of defaults.
3.1. Designing input data
- Make high-frequency inputs easy to express (e.g., y/n)
- Let the user specify the unit of measurement. Do not require transformations or calculations.
- Design meaningful input data whenever possible.
- Allow abbreviated input when it can be unambiguously interpreted (e.g., "y" for "yes")
- A system should be "case blind" when it really does not matter (e.g., "yes", "Yes" or "YES")
- Keep input fields short if possible.
- Do not combine letters and numbers in a single field.
- Avoid frequent shifts between upper- and lower-case characters.
- Avoid uncommon letter sequences.
- Do not require leading zeros.
4. Prompts and Instructions
- Provide prompts when use will be relatively infrequent, inputs must be formatted, and users are not working from a source document.
- i.e., help user with syntax
- e.g., (Last, First Middle)
- Prompts should be brief and unambiguous.
- Place prompts to the right of fields, or in a MicroHelp line at the bottom of the screen/window.
- Provide instructions for navigation and completion on the screen or through on-line help.
- Place instructions in a consistent location across screens and make them visually distinctive.
- Use consistent terminology and consistent grammatical form and style in instructions.
5. Navigation
- When a form is first entered, position the cursor in the most likely default position.
- Arrange field groups consistently with default cursor movement. Vertical groups are preferable to horizontal if cursor movement can be vertical.
- Allow forward and backward movement by field and within fields.
- Make protected areas on the screen completely inaccessible. Allow the cursor to rest only on user-editable areas.
- Do not use auto tab unless fields have fixed lengths and users are high frequency and experienced.
- Provide titles and page numbers or place markers on screens in a multiscreen form.
- Direct manipulation increases flexibility, speed, and ease of learning for navigation through fields.
6. Error Handling
- Allow character edits in fields.
- Place the cursor in the error field after error detection. Highlight the error field if possible.
- For independent fields, withhold error reporting until user request.
- Provide semantic and syntactic information in error msgs depending on user knowledge.
dcb at cs wpi edu / Thu Mar 30 21:23:38 EST 2006