"2.0 General"
Data display referwith data entry Flexibility for user control of data display
s to computer output of data to a user, and assimilation of information from such outputs.
"2.0/1Necessary Data Displayed"
Ensure that whatever data a user needs for any transaction will be available for display.
"Example" As a minor example, header information should be retained or generated anew when a user is paging/scrolling data tables.
"Example" As a negative example, even temporary loss of needed data, as might be caused by display blanking during automatic data update, is not acceptable in many design applications.
"Comment" The designer of user interface software must employ some method of task analysis (e.g., operational sequence diagrams) in order to determine a user's detailed information requirements for any transaction.
"Comment" If data requirements exceed a user's ability to assimilate information from the display, break the task into smaller steps. Prototype testing may be required to determine optimum data displays for critical tasks.
"Comment" A user should not have to remember data from one display to the next.
"Reference" BB 4.3.6 EG 2.3.15 Stewart 1980 Tullis 1983
"See also" 4.0/5
"2.0/2 + Only Necessary Data Displayed"
Tailor displayed data to user needs, providing only necessary and immediately usable data for any transaction; do not overload displays with extraneous data.
"Example"
(Good)
| CODE DATA TYPE |
| su = Summary |
| d = Detailed list |
| se = Sequences |

"Comment" Display of extraneous data may confuse a user and hinder assimilation of needed information.
"Comment" When user information requirements cannot be exactly anticipated by the designer, allow users to tailor displays on line by controlling data selection (Section 2.7.1), data coverage within a display frame (Section 2.7.2), suppression of displayed data (Section 2.7.4), and data window overlay (Section 2.7.5).
"Reference" BB 1.7 1.8.10 EG 3.1.4 3.3.1 MS 5.15.3.1.2 5.15.4.6.2 Stewart 1980 Tullis 1981
"See also" 2.0/8 2.7/1 2.8/1 4.0/5
[Back to the top]

"2.0/3 Data Displayed in Usable Form"
Display data to users in directly usable form; do not make users convert displayed data.
"Example" If altitude might be required in either meters or feet, then display both values.
"Example" This recommendation applies to error messages and other forms of user guidance as well as to data displays.
(Probably adequate)
| Character in NAME entry cannot be recognized. |

(Too cryptic)
| Error 459 in column 64. |

"Comment" Do not require a user to transpose, compute, interpolate, or translate displayed data into other units, or refer to documentation to determine the meaning of displayed data.
"Reference" BB 3.3 EG 3.3.4 MS 5.15.3.1.3
"See also" 4.4/1
[Back to the top]

"2.0/4 Data Display Consistent with User Conventions"
Display data consistently with standards and conventions familiar to users.
"Example" As a negative example, if users work with metric units of measurement, do not display data in English units.
"Example" Computer time records that are not in directly usable format should be converted for display, to a conventional 12-hour (AM/PM) clock or a 24-hour clock, in local time or whatever other time standard is appropriate to user needs.
"Example" Calendar formats should follow user customs.
(American calendar)      (European calendar)
S M T W T F S              S 1 8 15 22 29
2 3 4 5 6 7 8 9             M 2 9 16 23 30
10 11 12 13 14               T 3 10 17 24 31
15 16 17 18 19 20 21    W 4 11 18 25
22 23 24 25 26 27 28      T 5 12 19 26
29 30 31                          F 6 13 20 27
                                        S 7 14 21 28
"Reference" BB 3.4 EG 2.2.4
"See also" 4.0/16
"2.0/5 + Establishing Display Standards"
When no specific user conventions have been established, adopt some consistent interface design standards for data display.
[Back to the top]

"2.0/6 Consistent Display Format"
For any particular type of data display, maintain consistent format from one display to another.
"Comment" When an item is missing from a standard format, display that item as a labeled blank rather than omitting it altogether.
"Reference" BB 1.1.1 MS 5.15.3.2.1 Stewart 1980
"See also" 4.0/6
[Back to the top]

"2.0/7 Display Consistent with Entry Requirements"
Ensure that data display is consistent in word choice, format, and basic style with requirements for data and control entry.
"Example" When the computer displays a list of current files, the names in that list should be in a format which would be recognized by the computer if they were part of a control entry; thus a user could mimic the displayed list if specifying a file for editing or mailing.
"Comment" When composing data and control entries, users will tend to mimic the vocabulary, formats, and word order used in computer displays, including displayed data, labels, error messages, and other forms of user guidance. When entry formats are consistent with display formats, users are more likely to compose an acceptable entry on their first try.
"Reference" Good Whiteside Wixon Jones 1984 Mooers 1983 Zoltan-Ford 1984
"See also" 3.0/13 4.0/18
[Back to the top]

"2.0/8 User Control of Data Display"
Allow users to control the amount, format, and complexity of displayed data as necessary to meet task requirements.
"Comment" An experienced user may be able to deal with more complex displays than a novice. But a user experienced in one task may be a novice in another. Thus a range of display tailoring capabilities may be desirable for any particular task.
"Comment" Increasing the options for user control of data displays will complicate what a new user must learn about a system, and so will involve a trade-off against simplicity of user interface design.
"Reference" EG 3.4.2
"See also" 2.0/2 2.8/1 2.7
"2.0/9 + User Changes to Displayed Data"
Allow users to change displayed data or enter new data when that is required by a task.
"Comment" For some displays, of course, it is not desirable for users to change data, such as in operations monitoring (process control) displays, or displays permitting access to a protected data base.
"Comment" Some consistent formatting cue, perhaps different cursor shape or different initial cursor placement, should be provided to inform users when displayed data can or cannot be changed.
"Reference" PR 4.4
"See also" 1.0/6 1.3/2 6.2/4
"2.0/10 + Protection of Displayed Data"
When protection of displayed data is essential, maintain computer control over the display and do not permit a user to change controlled items.
"Comment" Never assume compliance with instructions by the user, who may attempt unwanted changes by mistake, or for curiosity, or to subvert the system.
"Reference" EG 3.4.8
"See also" 1.1/23 1.4/7 6.2/3 6.3/2
[Back to the top]

"2.0/11 Context for Displayed Data"
Ensure that each data display will provide needed context, recapitulating prior data as necessary so that a user does not have to rely on memory to interpret new data.
"Comment" When user information requirements cannot be determined in advance, it may be desirable to provide a separate display window as a "notepad" in which a user can preserve needed items by marking those to be saved.
"Comment" If data must be remembered from one display to another, display no more than four to six i
[Back to the top]

"2.0/12 Familiar Wording"
The wording of displayed data and labetems.
"Reference" BB 4.3.6 EG 2.3.15
ls should incorporate familiar terms and the task-oriented jargon of the users, and avoid the unfamiliar jargon of designers and programmers.
"Comment" When in doubt, pretest the meaning of words for prospective users to ensure that there is no ambiguity.
"Reference" BB 3.7.1 3.7.4 EG 3.4.5 4.2.13 PR 4.5.6
"See also" 1.4/19 4.0/16 4.0/17 4.3/3
"2.0/13 + Consistent Wording"
For displayed data and labels, choose words carefully and then use them consistently.
"Example"
(Good)
| Record A Change |
| Record B Change |
| Record C Change |
(Bad)
| Update of Record A |
| Record B Maintenance |
| Change in Record C |
"Example" As a negative example, the word "screen" should not be used to mean "display frame" in one place, and "menu selection option" in another.
"Comment" Consistent word usage is particularly important for technical terms. Standard terminology should be defined and documented in a glossary for reference by interface designers as well as by users.
"Reference" BB 1.2.2 3.7.2 EG 3.4.5 4.2.13 Pakin Wray 1982
"2.0/14 + Consistent Wording Across Displays"
Ensure that wording is consistent from one display to another.
"Example" The title of a display should be identical to the menu option used to request that display.
"Reference" BB 3.7.4
"2.0/15 + Consistent Grammatical Structure"
Use consistent grammatical structure for data and labels within and across displays.
"Example"
(Good)
| Starting date: |
| Leaving date: |
| Home phone: |
| Work phone: |

"Comment" Even minor inconsistencies can distract a user and delay comprehension as the user wonders momentarily whether some apparent difference represents a real difference.
"Reference" Pakin Wray 1982
"See also" 4.0/23
[Back to the top]

"2.0/16 Minimal Use of Abbreviation"
Display complete words in preference to abbreviations.
"Exception" Abbreviations may be displayed if they are significantly shorter, save needed space, and will be understood by the prospective users.
"Exception" When abbreviations are used for data entry, then corresponding use of those abbreviations in data display may help a user learn them for data entry.
"Reference" BB 3.1 3.1.1 3.1.5 EG 4.1.3 MS 5.15.3.2.3
"2.0/17 + Common Abbreviations"
When abbreviations are used, choose those abbreviations that are commonly recognized, and do not abbreviate words that produce uncommon or ambiguous abbreviations.
"Example" In a process control application where system components are commonly abbreviated, messages to users could include those common abbreviations, while displaying in full form those words that are not commonly abbreviated, as
(Acceptable)
| CST pressure low |

(Poor)
| Condensate Storage Tank prssr lw |

(Acceptable)
| Restricted Acct |

(Poor)
| Rstr Account |

"Comment" The point here is that when abbreviation is necessary due to space constraints, often a designer can still choose which words will be abbreviated. The words chosen for abbreviation should be those that are commonly known in their abbreviated form, and/or those words whose abbreviations can be unambiguously interpreted.
"Reference" BB 3.1.6
"2.0/18 + Simple Abbreviation Rule"
When defining abbreviations, follow some simple rule and ensure that users understand that rule.
"Comment" Abbreviation by truncation is the best choice, except when word endings convey important information. When a truncation rule is used, abbreviations are easy for a designer to derive and easy for a user to decode.
"Comment" If an abbreviation deviates from the consistent rule, it may be helpful to give it some special mark whenever it is displayed.
"Reference" BB 3.1.2 MS 5.15.3.2.3 PR 4.5.6 Moses Ehrenreich 1981 Rogers Moeller 1984
"See also" 1.0/17 1.0/18 1.0/19 1.0/20 1.0/21 1.0/22 1.0/23
"2.0/19 + Distinctive Abbreviations"
Ensure that abbreviations are distinctive, so that abbreviations for different words are distinguishable.
"Reference" BB 3.1 MS 5.15.3.2.3 Moses Ehrenreich 1981
"2.0/20 + Minimal Punctuation of Abbreviations"
Minimize punctuation of abbreviations and acronyms.
"Example"
(Good)
| USAF |

(Bad)
| U.S.A.F. |

"Exception" Punctuation should be retained when needed for clarity, e.g., "4-in. front dimension" rather than "4 in front dimension".
"Exception" Punctuation of abbreviations might be justified when an abbreviation represents more than one word, and more than the first letter of each word is included in the abbreviation, e.g., "common services" abbreviated as "COM.SER" rather than "COMSER".
"Reference" BB 1.3.5 EG 2.2.14 MS 5.15.3.2.3
"2.0/21 + Dictionary of Abbreviations"
If abbreviations are used, provide a dictionary of abbreviations available for on-line user reference.
"Reference" BB 3.1.3 MS 5.15.3.2.3
"See also" 4.4/20
[Back to the top]