Data Forms
 

Data forms permit entry of predefined items into labeled fields of specially formatted displays.
"Good and Bad Examples These sample displays represent a possible form for entry and review of visa application data. In the good form, data entries are bolded to help distinguish them from labels and field delimiters. Fields are ordered consistently in relation to a (supposed) paper application form, and formatted to facilitate both data entry and data review.
The bad display is annotated to indicate violations of several of the design guidelines proposed here for data forms. The data entries in the bad display were invented to suggest what a user might have produced, if confused by inadequate labeling and the absence of field delimiters.

"Good Sample Data Form"

|-----------------------------------------------------|
| VISA APPLICATION |
| |
| NAME: Jones, Andrew David_______ VISA: 356 478 |
| LAST, FIRST MIDDLE |
| |
| BIRTH COUNTRY: UK DATE: 3/22/25 |
| MM DD YY |
| |
| NATIONALITY: UK PASSPORT: Z196284__ |
| |
| ADDRESS: 5 Fairview Lane_________________ |
| Loughborough, LE11 3RG__________ |
| England_________________________ |
| |
| OTHER TRAVELERS ON THIS VISA |
| BIRTH |
| NAME: COUNTRY: DATE: |
| Jones, Sandra Jean________ UK 10/11/28 |
| Jones, Cynthia Leigh______ FR 6/12/68< |
| __________________________ __ __/__/__ |
| __________________________ __ __/__/__ |
| LAST, FIRST MIDDLE MM DD YY |
| |
| * Press ENTER when done. |
|-----------------------------------------------------|
 

"Bad Sample Data Form"

|-----------------------------------------------------|
| Name Andrew D. Jones Visa Number 356478 |
| |
| Birthplace London Nationality English |
| |
| Passport Z196284 Birthdate Mar. 22, |
| |
| Address 1925 |
| 5 Fairview Lane, Loughborough, L |
| E11 3RG, England |
| |
| Other travelers on this visa |
| Traveler's Name Date of Birth - Place |
| Sandra J. Jones Oct. 11, - 1928 |
| Birmingham |
| Cynthia L. Jones June 12, - 1968 |
| Paris, France# |
| |
| |
| |
| |
| |
| |
| |
| Press ENTER when done |
|-----------------------------------------------------|

In a form-filling dialogue, when a user is entering logically related items, require just one explicit entry action at the end of the transaction sequence, rather than separate entry of each item.
"Comment" Depending on form design, this practice might involve entering the entire form, or entry by page or section of a longer form. Form design should indicate to users just where explicit entry is required.
"Comment" Single entry of grouped data will generally permit faster input than item-by-item entry, and should prove more accurate as well. This practice permits user review and possible data correction prior to entry, and also helps the user understand at what point grouped data are processed. It will also permit efficient cross validation of related data items by the computer.

"1.4/2 Flexible Interrupt"

When multiple data items are entered as a single transaction, as in form filling, allow the user to REVIEW, CANCEL, or BACKUP and change any item before taking a final ENTER action.
 
 

"1.4/3 Minimal Use of Delimiters"

Whenever possible, allow entry of multiple data items without keying special separator or delimiter characters, e.g., hyphens, dollar signs, etc.
"Example" See sample displays in this section.
"Comment" This can be accomplished either by keying into predefined entry fields or by separating sequentially keyed items with blank spaces. In this context, tabbing from field to field is not considered to be keying a special delimiter character.
"Comment" When data items contain internal blanks, design the entry fields with a predefined structure so that users will not have to key any internal delimiters.

"1.4/4 + Standard Delimiter Character"

When a field delimiter must be used for data entry, adopt a standard character to be employed consistently for that purpose.
"Example" A slash (/) may be a good choice.
"Comment" Choose a special delimiter character that does not require shift keying. It will also be necessary to choose a character that does not occur as part of any data entry (except possibly for entry of running text where its occurrence would not be ambiguous).

"1.4/5 Data Field Labels"

For each data field, display an associated label to help users understand what entries can be made.
"Example"
(Good)
| NAME: __ __ __ __ __ __ __ __ __ __ __ |
| |
| ORGANIZATION: __ __/__ __ |
| |
| PHONE: __ __ __-__ __ __ __ |

(Bad)
| NAME, ORGANIZATION AND PHONE |
| |
| __ __ __ __ __ __ __ __ __ __ __ __ |
| |
| __ __ __ __ |
| |
| __ __ __ __ __ __ __ |
"Reference" BB 2.1.7

"1.4/6 + Consistent Labeling"

Make field labels consistent; always employ the same label to indicate the same kind of data entry.
"Example" A field labeled NAME should always require name entry, and not sometimes require something different like elevation (cited from an actual system).
"Example" See sample displays in this section.

"1.4/7 + Protected Labels"

Protect field labels from keyed entry, by making the cursor skip over them automatically when a user is spacing or tabbing.
"Exception" When a user must change a displayed form, including changes to field labels, then that user must be able to override label protection.

 
"1.4/8 + Labels Close to Data Fields"

Ensure that labels are sufficiently close to be associated with their proper data fields, but are separated from data fields by at least one space.
 

"1.4/9 + Standard Symbol for Prompting Entry"

Choose a standard symbol for input prompting and reserve that symbol only for that use.
"Example" In the examples here, and also in many printed forms, a colon serves to prompt inputs, as
(Good)
| TIME: ________ |

(Bad)
| TIME ________ |
"Comment" Consistent use of a symbol for input prompting in data entry forms, in menus, in command entry lines, etc., will help to cue users that an input is required. A standard symbol used in addition to other formatting cues will help to alert a user to differences between labels and displayed data, between messages requiring input and messages for information only.

 
"1.4/10 Marking Field Boundaries"

Display special characters or other consistent means of highlighting to clearly delineate each data field.
"Example" An underscore might be used for this purpose, perhaps broken to indicate the number of symbols required in an entry, as
(Good)
| Enter account number: __ __ __ __ __ |

(Bad)
| Enter account number: |
 

"1.4/11 + Prompting Field Length"

Provide cues in field delineation to indicate when a fixed or maximum length is specified for a data entry.
"Example"
(Good)
| Enter ID: __ __ __ __ __ __ __ __ __ |

(Bad)
| Enter ID (9 characters): |

"Example" See sample displays in this section.
"Comment" Prompting by delineation is more effective than simply telling the user how long an entry should be. In the example cited here, underscoring gives a direct visual cue as to the number of characters to be entered, and the user does not have to count them.
"Comment" Similar implicit cues should be provided when data entry is prompted by auditory displays. Tone codes can be used to indicate the type and length of data entries.

 
"1.4/12 + Marking Required and Optional Data Fields"

In designing form displays, distinguish clearly and consistently between required and optional entry fields.
"Example" Field delineation cues may be used for this purpose, perhaps a broken underscore to indicate required entries and a dotted underscore to indicate optional entries, as
| LICENSE NUMBER: __ __ __ __ __ __ |
| |
| MAKE: . . . . . . . . . . . . . . |
| |
| YEAR/MODEL: . . . . . . . . . . . |
"Example" Alternatively, it might be preferable to distinguish required versus optional entry fields by coding their labels, perhaps displaying in parentheses the labels of optional fields.

"1.4/13 + Field Markers Not Entered with Data"

When item length is variable, so that a data entry does not completely replace the markers in a field, ignore any remaining field markers in computer processing.
"Comment" A user should not be expected to erase any field markers. Extra markers should not be processed as part of a data entry if they are not erased.

"1.4/14 + Automatic Justification of Variable-Length Entries"

When item length is variable, provide automatic justification in computer processing; a user should not have to justify an entry either right or left.
"Example" Assuming field delineation by underscore, the following entries should all be considered equivalent
| Address: 40 Dalton Road_______ |
| Address: _______40 Dalton Road |
| Address: ___40 Dalton Road____ |
"Comment" If a data entry is shorter than its field length, its position when entered in that field should not matter. The computer can impose its own justification rules when storing and subsequently displaying such data for review.

"1.4/15 Explicit Tabbing to Data Fields"

Require users to take explicit keying ("tabbing") action to move from one data entry field to the next; the computer should not provide such tabbing automatically.
"Example" See sample displays in this section.
"Comment" Automatic tabbing may cause cascading of errors, if a skilled typist keys a series of items without looking at the display and has accidentally overrun one of the earlier data fields. An acceptable solution here is to design each field to end with an extra (blank) character space; software should be designed to prevent keying into a blank space, and an auditory signal should be provided to alert the user when that is attempted. This will permit consistent use of tab keying by the user to move accurately from one field to the next, even for touch typists.
 

"1.4/16 Distinctive Label Format"

Make labels for data fields distinctive, so that they will not be readily confused with data entries, labeled control options, guidance messages, or other displayed material.
"Example" Labels might be displayed in capital letters always followed by a colon. Or labels might be displayed in dim characters, with data entries brighter.
"Example" See sample displays in this section.
 

"1.4/17 + Consistent Label Format"

When data fields are distributed across a display, adopt a consistent format for relating labels to delineated entry areas.
"Example" The label might always be to the left of the field; or the label might always be immediately above and left-justified with the beginning of the field.
"Comment" Such consistent practice will help the user distinguish labels from data in distributed displays.
 

"1.4/18 + Label Punctuation as Entry Cue"

The label for each entry field should end with a special symbol, signifying that an entry may be made.
"Example" A colon is recommended for this purpose, as
| NAME: __ __ __ __ __ __ __ __ __ __ __ |
"Example" See sample displays in this section.
"Comment" Choose a symbol that can be reserved exclusively for prompting user entries, or at least is rarely used for any other purpose.
 

"1.4/19 Informative Labels"

In labeling data fields, employ descriptive wording, or else standard, predefined terms, codes and/or abbreviations; avoid arbitrary codes.
"Example" Employ descriptive labels such as STANDARD and MODIFIED, rather than abstract codes such as SET A and SET B; MALE and FEMALE, rather than GROUP 1 and GROUP 2.
"Example"
(Good) |
WEEK: __ MONTH: __ __ YEAR: __ __ |
| |
| SOCIAL SECURITY NO: __ __ __ - __ __ - __ __ __ __ |

(Bad)
| DATECODE: __ __ __ __ __ |
| |
| SSAN: __ __ __ __ __ __ __ __ __ |

"Example" See sample displays in this section.
"Comment" Do not create new jargon. If in doubt, pretest all proposed wording with a sample of qualified users.

 
"1.4/20 Data Format Cueing in Labels"

Include in a field label additional cueing of data format when that seems helpful.
"Example"
| DATE (MM/DD/YY): __ __/__ __/__ __ |
"Example" See sample displays in this section.

"1.4/21 + Labeling Units of Measurement"

When a measurement unit is consistently associated with a particular data field, include that unit as part of the field label rather than requiring a user to enter it.
"Example"
| COST: $ __ __ __ __ |
"Example"
| SPEED (MPH): __ __ __ |
"Reference" BB 2.2.6 MS 5.15.4.3.10 PR 4.8.11

"1.4/22 + Familiar Units of Measurement"

Employ units of measurement that are familiar to the user.
"Example"
(Good)
| SPEED LIMIT: __ __ miles per hour |

(Bad)
| SPEED LIMIT: __ __ feet per second |

(Good)
| FUEL USE: __ __.__ miles per gallon |

(Bad)
| FUEL USE: .__ __ gallons per minute |

"Comment" If data must be converted to unfamiliar units, the computer should handle that automatically.

 
"1.4/23 + Alternative Units of Measurement"

When alternative measurement units are acceptable, provide space in the data field so that a user can designate the units actually entered.
"Example"
| DISTANCE: __ __ __ __ (MI/KM) __ __ |
 
 

"1.4/24 Form Compatible for Data Entry and Display"

When forms are used for reviewing displayed data as well as for data entry, make the form for data entry compatible with that for display output; use the same item labels and ordering for both.
"Comment" When a display format optimized for data entry seems unsuited for data display, or vice versa, some compromise format should be designed, taking into account the relative functional importance of data entry and data review in the user's task.

 
"1.4/25 + Form Compatible with Source Documents"

When data entry involves transcription from source documents, ensure that form-filling displays match (or are compatible with) those documents, in terms of item ordering, data grouping, etc.

                            "1.4/26 Minimal Cursor Positioning"
When designing displays for form-filling data entry, minimize user actions required for cursor movement from one field to the next.
"Comment" Placing all required fields before any optional fields will sometimes make data entry more efficient.
 

"1.4/27 + Data Items in Logical Order"

If no source document or external information is involved, then design forms so that data items are ordered in the sequence in which a user will think of them.
"Comment" The software designer will need to work with prospective system users to determine what represents a logical sequence of data entries.
 
 

"1.4/28 Automatic Cursor Placement"

When a form for data entry is displayed, the computer should place the cursor automatically at the beginning of the first entry field.
"Exception" If a data form is regenerated following an entry error, the cursor should be placed in the first field in which an error has been detected.