|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents |
|
GUIDELINES FOR DESIGNING USER INTERFACE SOFTWARE
ESD-TR-86-278
|
| by Sidney L. Smith and Jane N. Mosier |
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents |
Data display refers to computer output of data to a user, and assimilation of information from such outputs. Some kind of display output is needed for all information handling tasks. Data display is particularly critical in monitoring and control tasks. Data may be output on electronic displays, or hardcopy printouts, or other auxiliary displays and signaling devices including voice output, which may alert users to unusual conditions.
In this discussion, data are considered to be display elements related to a user's information handling task. Displayed data might consist of stock market quotations, or the current position of monitored aircraft, or a page of text, or a message from another user. Displayed data might provide guidance to a user in performing a maintenance task, or might provide instruction to a user who is trying to learn mathematics or history.
There might be some display elements that themselves do not constitute task-related data. Those elements include labels, prompts, computer-generated advisory messages and other guidance that helps a user interact with a computer system. Although such user guidance display features are sometimes mentioned here in connection with data display, they are discussed more extensively in Section 4 of these guidelines.
In general, somewhat less is known about data display, and information assimilation by the user, than about data entry. In current information system design, display formatting is an art. Guidelines are surely needed. But these guidelines may simply serve to help a designer become more proficient in the art.
It must be recognized that guidelines cannot tell a designer what the specific contents of a display should be, but only how those contents should be presented. The specific data that must be displayed can only be determined through a careful task analysis to define the user's information requirements.
For effective task performance, displayed data must be relevant to a user's needs. An early statement (Smith, 1963b, pages 296-297) of the need for relevance in data display, although written before common adoption of gender-free wording, otherwise seems valid still: When we examine the process of man-computer communication from the human point of view, it is useful to make explicit a distinction which might be described as contrasting "information" with "data." Used in this sense, information can be regarded as the answer to a question, whereas data are the raw materials from which information is extracted. A man's questions may be vague, such as, "What's going on here?" or "What should I do now?" Or they may be much more specific. But if the data presented to him are not relevant to some explicit or implicit question, they will be meaningless. . . . What the computer can actually provide the man are displays of data. What information he is able to extract from those displays is indicated by his responses. How effectively the data are processed, organized, and arranged prior to presentation will determine how effectively he can and will extract the information he requires from his display. Too frequently these two terms data and information are confused, and the statement, "I need more information," is assumed to mean, "I want more symbols." The reason for the statement, usually, is that the required information is not being extracted from the data. Unless the confusion between data and information is removed, attempts to increase information in a display are directed at obtaining more data, and the trouble is exaggerated rather than relieved.
Certainly this distinction between data and information should be familiar to psychologists, who must customarily distinguish between a physical stimulus (e.g., "intensity" of a light) and its perceived effect ("brightness"). The distinction is not familiar to system designers, however, although the issue itself is often addressed. In the following description of what has been called the "information explosion", notice how the terms data and information are used interchangeably, confounding an otherwise incisive and lively analysis by Martin (1973, page 6): The sum total of human knowledge changed very slowly prior to the relatively recent beginnings of scientific thought. But it has been estimated that by 1800 it was doubling every 50 years; by 1950, doubling every 10 years; and by 1970, doubling every 5 years. . . . This is a much greater growth rate than an exponential increase. In many fields, even one as old as medicine, more reports have been written in the last 20 years than in all prior human history. And now the use of the computer vastly multiplies the rate at which information can be generated. The weight of the drawings of a jet plane is greater than the weight of the plane. The computer files of current IBM customer orders contain more than 100 billion bits of information -- more than the information in a library of 50,000 books. For man, this is a hostile environment. His mind could no more cope with this deluge of data, than his body could cope with outer space. He needs protection. The computer -- in part the cause of the problem -- is also the solution to the problem. The computer will insulate man from the raging torrents of information that are descending upon him. The information of the computerized society will be gathered, indexed, and stored in vast data banks by the computers. When man needs a small item of information he will request it from the computers. The machines, to satisfy his need, will sometimes carry on a simple dialogue with him until he obtains the data he wants. With the early computers, a manager would often have dumped on his desk an indigestible printout -- sometimes several hundred pages long. Now the manager is more likely to request information when he needs it, and receive data about a single item or situation on a screen or small printer. It is as though man were surviving in the depths of this sea of information in a bathyscaphe. Life in the bathyscaphe is simple, protected as it is from the pressure of the vast quantities of data. Every now and then man peers through the windows of the bathyscaphe to obtain facts that are necessary for some purpose or other. The facts that he obtains at any one time are no more than his animal brain can handle. The information windows must be designed so that man, with his limited capabilities, can locate the data he wants and obtain simple answers to questions that may need complex processing.
Some experts understand this distinction clearly, such as Hannemyr and Innocent (1985) who write about "transforming . . . data into information". But many system designers and users still fail to recognize the difference.
Once a designer has determined what data must be displayed, through analysis of user information requirements, the next step is to decide how those data might best be formatted. Data might be displayed as text, or in data forms, tables and/or various graphic formats. Each of those types of data display is considered separately in the guidelines presented here.
In some applications, the nature of the data will dictate the necessary format, as in the graphic situation displays used for air traffic control. In some applications, equipment limitations may constrain display formatting, as in systems without graphic capability. In many applications, however, a designer will have considerable latitude in choosing how to display data. Good judgment may be needed to decide when pictures or diagrams should be displayed rather than narrative text, or vice versa.
In the subsections of guidelines dealing with text, or data forms, or tables, or the various types of graphic displays, the initial guidelines describe generally the circumstances in which that particular type of data display may be appropriate. The design decision will require careful analysis of the users' information handling tasks to determine just what circumstances will actually prevail.
For data display, as in other areas of user interface design, some general concepts deserve emphasis, including the importance of context, consistency, and flexibility. Somehow a means must be found to provide and maintain context in data displays so that a user can find needed information. Task analysis may point the way here, indicating what data are relevant to each step in task performance. Design guidelines must emphasize the value of displaying no more data than the user needs, and the importance of maintaining consistent display formats so that the user always knows where to look for different kinds of information, on any one display and from one display to another.
Detailed user information requirements will vary, however, and may not be completely predictable in advance, even with careful task analysis. Thus flexibility is needed so that a user can tailor data displays on line to meet current needs. Such flexibility is sometimes provided through optional data category selection and display offset and expansion features. If options for tailoring display coverage are provided, a user can adjust the assimilation of displayed data in a way analogous to the self pacing of data entry.
When a user must both enter and retrieve data, which is usually the case, the formatting of data displays should be consistent with the methods used for data entry. As an example, if data entry is accomplished via form filling, with specially formatted data fields, subsequent retrieval of that data set should produce an output display with the same format, especially if the user is expected to make changes to the displayed data or additional entries. Where compaction of data output is required for greater efficiency, perhaps to review multiple data sets in a single display frame, the displayed items should retain at least the same ordering and labeling as when those fields were used for data entry.
Display design must also take into account the type of dialogue used for sequence control, and with hardware capabilities. Where user inputs are made via menu selection, using a pointing device like a lightpen, then display formats should give prominence (and adequate separation) to the labeled, lightpennable options. Location of multifunction keys at the display margin, to be labeled on the adjacent portion of the display itself, may provide flexibility for both data entry and sequence control, but will necessarily constrain display formatting.
These general concepts underlie many of the guidelines for data display proposed in the following pages. As for the other areas of user interface design, an attempt has been made to write guidelines for data display in functional terms, insofar as possible without reference to specific display devices and questions of hardware implementation. As a practical matter, however, available display technology will inevitably influence the wording of guidelines.
A discerning reader will note that the guidelines presented here deal almost exclusively with visual displays; there are only a few references to other possible display modes. Moreover, most of these guidelines implicitly assume a fairly large visual display, with room to show different kinds of data at one time -- in effect, a display with about 24 lines of 80 characters, much like the devices we now use. Consequently, many of these guidelines will not apply in applications where displays are constrained to a smaller size, such as "briefcase" terminals or handheld display devices.
As display technology develops further, it seems inevitable that some of the guidelines proposed here must be reconsidered, and other guidelines added. As an example, we may anticipate increased use of graphics in future information display design, with moving (and talking) pictures such as those we now enjoy in displays designed for entertainment.
The guidelines proposed here are intended for display designers. If we regard displays as contrived arrangements of data, then the guidelines refer to that contrivance. What happens in applications where the computer provides a flexible capability allowing users to contrive many of their own displays? If a user composes a poor page of text, with long sentences, flawed grammar, inconsistent spacing, etc., can a software designer be held responsible? Presumably not, or at least not today.
One might imagine future systems, however, where some form of expertise is stored in the computer, including expertise on user interface design. In applications where users design their own displays, a computer might someday suggest pertinent guidelines, or perhaps even enforce design rules where warranted. For example, if a user entered irregularly spaced text, a smart computer might regularize the spacing in subsequent output of that text.
The guidelines presented here can themselves be regarded as a long multipage data display. Problems of display organization arise in presenting the guidelines material, in terms of content, wording, and format. As in other sections, the topical organization of these guidelines is based on function, dealing with different types of displayed data and display manipulation. As in other sections, the guidelines here recommend specific ways to accomplish some very general objectives.
Consistency of data display Efficient information assimilation by the user Minimal memory load on user Compatibility of data display with data entry Flexibility for user control of data display
Data display refers to computer output of data to a user, and assimilation of information from such outputs.
Ensure that whatever data a user needs for any transaction will be available for display.
As a minor example, header information should be retained or generated anew when a user is paging/scrolling data tables.
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.
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.
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.
A user should not have to remember data from one display to the next.
Tailor displayed data to user needs, providing only necessary and immediately usable data for any transaction; do not overload displays with extraneous data.
(Good)
| CODE DATA TYPE | | su = Summary | | d = Detailed list | | se = Sequences |
(Bad)
| CODE DATA TYPE DATE IMPLEMENTED | | su = Summary 5-17-82 | | d = Detailed list 7-14-82 | | se = Sequences 9-25-82 |
Display of extraneous data may confuse a user and hinder assimilation of needed information.
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).
Display data to users in directly usable form; do not make users convert displayed data.
If altitude might be required in either meters or feet, then display both values.
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. |
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.
Display data consistently with standards and conventions familiar to users.
As a negative example, if users work with metric units of measurement, do not display data in English units.
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.
Calendar formats should follow user customs.
(American calendar) (European calendar)
S M T W T F S S 1 8 15 22 29
1 2 3 4 5 6 7 M 2 9 16 23 30
8 9 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
When no specific user conventions have been established, adopt some consistent interface design standards for data display.
For any particular type of data display, maintain consistent format from one display to another.
When an item is missing from a standard format, display that item as a labeled blank rather than omitting it altogether.
Ensure that data display is consistent in word choice, format, and basic style with requirements for data and control entry.
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.
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.
Allow users to control the amount, format, and complexity of displayed data as necessary to meet task requirements.
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.
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.
Allow users to change displayed data or enter new data when that is required by a task.
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.
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.
When protection of displayed data is essential, maintain computer control over the display and do not permit a user to change controlled items.
Never assume compliance with instructions by the user, who may attempt unwanted changes by mistake, or for curiosity, or to subvert the system.
1.1/23 | 1.4/7 | 6.2/3 | 6.3/2
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.
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.
If data must be remembered from one display to another, display no more than four to six items.
The wording of displayed data and labels should incorporate familiar terms and the task-oriented jargon of the users, and avoid the unfamiliar jargon of designers and programmers.
When in doubt, pretest the meaning of words for prospective users to ensure that there is no ambiguity.
1.4/19 | 4.0/16 | 4.0/17 | 4.3/3
For displayed data and labels, choose words carefully and then use them consistently.
(Good)
| Record A Change | | Record B Change | | Record C Change |
(Bad)
| Update of Record A | | Record B Maintenance | | Change in Record C |
As a negative example, the word "screen" should not be used to mean "display frame" in one place, and "menu selection option" in another.
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.
Ensure that wording is consistent from one display to another.
The title of a display should be identical to the menu option used to request that display.
Use consistent grammatical structure for data and labels within and across displays.
(Good)
| Starting date: | | Leaving date: | | Home phone: | | Work phone: |
(Bad)
| Starting date: | | When did you quit: | | Home phone: | | Phone number at work: |
Even minor inconsistencies can distract a user and delay comprehension as the user wonders momentarily whether some apparent difference represents a real difference.
Display complete words in preference to abbreviations.
Abbreviations may be displayed if they are significantly shorter, save needed space, and will be understood by the prospective users.
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.
When abbreviations are used, choose those abbreviations that are commonly recognized, and do not abbreviate words that produce uncommon or ambiguous abbreviations.
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 |
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.
When defining abbreviations, follow some simple rule and ensure that users understand that rule.
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.
If an abbreviation deviates from the consistent rule, it may be helpful to give it some special mark whenever it is displayed.
1.0/17 | 1.0/18 | 1.0/19 | 1.0/20 | 1.0/21 | 1.0/22 | 1.0/23
Ensure that abbreviations are distinctive, so that abbreviations for different words are distinguishable.
Minimize punctuation of abbreviations and acronyms.
(Good)
| USAF |
(Bad)
| U.S.A.F. |
Punctuation should be retained when needed for clarity, e.g., "4-in. front dimension" rather than "4 in front dimension".
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".
If abbreviations are used, provide a dictionary of abbreviations available for on-line user reference.
Text displays provide output of stored textual data, along with messages and other text intended for user guidance.
These sample displays represent a broadcast message received by all users logging onto an on-line office support system. The wording of the bad display is taken from an actual instance. The good display clarifies wording of the text and improves display formatting.
The bad display is annotated to indicate violations of several of the design guidelines proposed here for text display. Although most of its noted deficiencies are minor, in sum they create a display that is potentially confusing to its users.
|----------------------------------------------------------| | SYSTEM BROADCAST MESSAGES | | | | 27 March 1984 | | | | Word Processing Users: | | | | Please do NOT print multiple copies of large | | documents (more than 100 printed pages) during normal | | working hours. Large print requests will delay | | printing service for all users. | | | | If you do need bulk printing, submit your request | | before leaving at 4:30 pm. Your printouts will be | | ready by the next morning. | | | | Network Users: | | | | Please report any net-related problems to the | | User Support Center, x2222. | | | | | | | | * Press CONTINUE to display the Office Systems Menu. | | < | |----------------------------------------------------------|
|----------------------------------------------------------| | -- System Broadcast Messages -- | | SYSTEM #22 - WPS 27 March 1984 | | | | **** NOTICE **** | | | | WPS USERS ARE REMINDED NOT TO PRINT MULTIPLE | | COPIES OF LARGE SIZE DOCUMENTS (100 PAGES OR | | MORE) TO THE 6670 PRINTER OR LINEPRINTER SINCE IT | | CAUSES LONG DELAYS ON THOSE PRINTERS. | | IF YOU NEED MULTIPLE COPIES, PLEASE SUBMIT | | YOUR REQUEST BEFORE LEAVING AT 4:30 P.M. THANK | | YOU. | | ****** | | | | NETWORK USERS -- Please report any network | | related problems to the User Support Center, | | X2222. | | | | Questions or problems should be referred to the | | USC, X2222. | | | | Press the RETURN key to enter the Office Systems | | Menu | | < | |----------------------------------------------------------|
This bad text display violates in some degree several design guidelines in this section: 2.1/1 Conventional text display 2.1/3 Consistent text format 2.1/6 Conventional use of mixed case 2.1/7 Separation of paragraphs 2.1/8 Consistent word spacing 2.1/10 Conventional punctuation 2.1/11 Clarity of wording 2.1/13 Simple sentence structure
Ensure that computer-generated displays of textual data, messages, or instructions, will generally follow design conventions for printed text.
See sample displays in this section.
Adoption of familiar design conventions for text display will permit users to rely on prior reading skills.
When a user must read lengthy textual material, consider providing that text in printed form rather than requiring the user to read it on-line.
Reading lengthy text on an electronic display may be 20-30 percent slower than reading it from a printed copy.
There are many good reasons for displaying lengthy textual material on line. Lengthy text may be displayed for editing, mailing, or search tasks. Or a lengthy text might be updated frequently, and so on-line display would be the best way to ensure that all users are reading the most recent version. The intent of this guideline is not to discourage such on-line display of text when that is needed, but rather to discourage on-line display when the text would be more useful in paper form. For instance, if HELP displays consist merely of screen after screen of text which is not tailored to a user's current task, than that text might be better displayed in a printed users' manual.
When textual material is formatted, as in structured messages, adopt a consistent format from one display to another.
See sample displays in this section.
When a user must read continuous text on line, display at least four lines of text at one time.
Four lines of text is the minimum which should be displayed when the reading material is simple in content. If the content is more complex, or if a reader will need to refer frequently to previous material, then display more lines of text.
When space for text display is limited, display a few long lines of text rather than many short lines of text.
Display continuous text in wide columns, containing at least 50 characters per line.
Text displayed in wide columns will be read significantly faster than text displayed in narrow columns.
When space for text display is limited, display a few long lines of text rather than many short lines of text.
Display continuous text conventionally in mixed upper and lower case.
See sample displays in this section.
An item intended to attract the user's attention, such as a label or title, might be displayed in upper case.
Upper case should be used when lower case letters will have decreased legibility, e.g., on a display terminal that cannot show true descenders for lower case letters.
Reading text is easier when capitalization is used conventionally to start sentences and to indicate proper nouns and acronyms.
Ensure that displayed paragraphs of text are separated by at least one blank line.
See sample displays in this section.
Maintain consistent spacing between the words of displayed text, with left justification of lines and ragged right margins if that is the result.
See sample displays in this section.
Right justification should be employed if it can be achieved by variable spacing, maintaining constant proportional differences in spacing between and within words, and consistent spacing between words in a line.
Reading is easier with constant spacing, which outweighs the advantage of an even right margin achieved at the cost of uneven spacing. Uneven spacing is a greater problem with narrow column formats than with wide columns. Uneven spacing handicaps poor readers more than good readers.
In display of textual material, keep words intact, with minimal breaking by hyphenation between lines.
Text is more readable if each word is entirely on one line, even if that makes the right margin more ragged.
Use conventional punctuation in textual display; sentences should end with a period or other special punctuation.
See sample displays in this section.
In designing text displays, especially text composed for user guidance, strive for simplicity and clarity of wording.
See sample displays in this section.
Put the main topic of each sentence near the beginning of the sentence.
Use short simple sentences.
See sample displays in this section.
Long sentences with multiple clauses may confuse the user. Consider breaking long sentences into two or more shorter statements.
When speed of display output for textual material is slower than the user's normal reading speed, make an extra effort to word the text concisely.
Assume a normal average reading speed of 250 words per minute.
The goal here is to make wording concise but not cryptic. Omitting articles ("the", "a"), prepositions ("of", "by") and relative pronouns ("that", "which", "who") may save some space, but may also reduce comprehension.
Use distinct words rather than contractions or combined forms, especially in phrases involving negation.
(Good) "will not", "not complete" (Bad) "won't", "incomplete"
This practice will help users understand the sense of a message.
Use affirmative statements rather than negative statements.
(Good)
| Clear the screen before entering data. |
(Bad)
| Do not enter data before clearing the screen. |
Tell the user what to do rather than what to avoid.
Compose sentences in the active rather than passive voice.
(Good)
| Clear the screen by pressing RESET. |
(Bad)
| The screen is cleared by pressing RESET. |
Sentences in the active voice will generally be easier to understand.
When a sentence describes a sequence of events, phrase it with a corresponding word order.
(Good)
| Enter LOGON before running programs. |
(Bad)
| Before running programs enter LOGON. |
Temporal order is clearer. Reverse order may confuse a user.
For a series of related items (words, phrases, instructions, etc.), display those items in a list rather than as continuous text.
A list format will facilitate rapid, accurate scanning.
Format lists so that each item starts on a new line; i.e., a list should be displayed as a single column.
(Good)
| Major USI functional areas include | | | | Data Entry | | Data Display | | Sequence Control | | User Guidance | | Data Transmission | | Data Protection |
(Bad)
| Major USI functional areas include | | | | Data Entry Data Display | | Sequence Control User Guidance | | Data Transmission Data Protection |
Listing in multiple columns may be considered where shortage of display space dictates a compact format.
Multiple columns of data should be used where that facilitates comparison of corresponding data sets, as in tabular displays (Section 2.3).
When a single item in a list continues for more than one line, mark items in some way so that the continuation of an item is obvious, i.e., so that a continued portion does not appear to be a separate item.
Items might be separated by a blank space, or continuing lines within an item might be indented, or each item might be numbered or marked by a special symbol such as an arrow or bullet.
Some demarcation is particularly needed when a list is comprised of a mixture of long and short items.
When listed items will be numbered, use Arabic rather than Roman numerals.
Arabic numbers are more familiar to most users, and therefore require less interpretation than Roman numerals do. The advantage of Arabic numbers becomes greater when large numbers are used. For instance, contrast XXVIII with 28.
Adopt some logical principle by which to order lists; where no other principle applies, order lists alphabetically.
It is the user's logic which should prevail rather than the designer's logic, where those are different.
2.3/2 | 2.5/14 | 2.5/15 | 2.5/16 | 2.5/17 | 2.5/18
If a list is displayed in multiple columns, order the items vertically within each column.
(Good)
| S.R. Abbott B.M. Drake | | C.N. Abernethy S.M. Dray | | C.A. Adams M.G. Dumoff | | H.L. Ammerman R.C. Eakins | | C.J. Arbak S.L. Ehrenreich | | etc. |
(Bad)
| S.R. Abbott C.N. Abernethy | | C.A. Adams H.L. Ammerman | | C.J. Arbak A.J. Aretz | | A.F. Aucella J.A. Ballas | | M.C. Bardales S.H. Barry | | etc. |
For a long list, extending more than one displayed page, consider adopting a hierarchic structure to permit its logical partitioning into related shorter lists.
When words in text displays are abbreviated, define each abbreviation in parentheses following its first appearance.
This practice will help only those users who read displayed text from front to back and remember what they have read. For forgetful users, and for users who sample later sections of a multipage text display, abbreviations may still seem undefined. For such users, it might be helpful to provide an on-line dictionary of abbreviations for convenient reference.
When a critical passage merits emphasis to set it apart from other text, highlight that passage by bolding/brightening or color coding or by some auxiliary annotation, rather than by capitalization.
A single word might be capitalized for emphasis, but capitalizing an extended passage will reduce its readability.
When text is combined with graphics or other data in a single display, thus limiting the space available for text, format the text in a few wide lines rather than in narrow columns of many short lines.
(Good)
| Text is easier to read when displayed in wide | | lines than when displayed in thin columns. |
(Bad)
| Text is harder | | to read when | | displayed in | | thin columns | | than when | | displayed in | | wide lines. |
Listed items might be displayed in a narrow column format.
When tables and/or graphics are combined with text, place each figure near its first citation in the text, preferably in the same display frame.
If a figure is cited at several points in the text, then it might be desirable to allow optional display of the figure at user request, perhaps as a temporary window overlay at each point of citation.
If a figure is cited at several points in printed text, and particularly if that text may be accessed at different places by its readers (as in the case of printed reference material), then it might be desirable to group figures consistently at a particular location, such as at the end of each section.
Readers may not bother to find and look at a figure is it is displayed separately from its citation in the text.
Data forms can display sets of related data items in labeled fields formatted to aid data entry and review.
These sample displays represent a possible form for review (and possible revision) of visa application data. In the good display, 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 data review.
The bad display is annotated to indicate violations of several of the design guidelines proposed here for data form displays. The data entries in the bad display were invented to suggest what a user might have entered, if confused by inadequate labeling and the absence of field delimiters.
|----------------------------------------------------------| | VISA APPLICATION | | | | NAME: Jones, Andrew David VISA: 356 478 | | LAST, FIRST MIDDLE | | | | BIRTH COUNTRY: UK DATE: 3/22/25 | | M D Y | | | | 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 M D Y | | | | * Review and ENTER changes if needed. | |----------------------------------------------------------|
|----------------------------------------------------------| | 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 | | | | | | | | | | | | | | | | Review and ENTER changes if needed | |----------------------------------------------------------|
This bad data form display violates in some degree several design guidelines in this section: 2.2/2 Visually distinctive data fields 2.2/4 Descriptive wording of labels 2.2/5 Consistent wording of labels 2.2/8 Distinctive label format 2.2/14 Partitioning long data items 2.2/15 Distinguishing blanks from nulls This bad data form also violates various design guidelines pertaining to data entry, as noted at the end of Section 1.4.
Use forms to display related sets of data items in separately labeled fields.
Forms can aid review of related data items by displaying explanatory labels to caption each data field.
Provide clear visual definition of data fields, so that the data are distinct from labels and other display features.
See sample displays in this section.
Identify each data field with a displayed label.
Do not assume that the user can identify individual data fields because of past familiarity. Context may play a significant role: 617-271-7768 might be recognized as a telephone number if seen in a telephone directory, but might not be recognized as such in an unlabeled display.
1.4/5 | 1.4/6 | 1.4/7 | 1.4/8 | 4.0/11
Choose a word or phrase to label each field that will describe the data content of that field.
See sample displays in this section.
Labels should be worded carefully so that they assist users in scanning the display and assimilating information quickly.
Ensure that labels are worded consistently, so that the same data item is given the same label if it appears in different displayed forms.
See sample displays in this section.
It may also help to employ consistent grammatical format for different labels; i.e., do not use single words or phrases for some labels and short sentences for others, or use verbs for some and nouns for others.
Ensure that field labels are worded distinctively from one another.
Place each label in a consistent location above or to the left of its associated data field(s).
In a numbered list, vertically formatted, the numeric labels should be aligned so that the data items start in a fixed column position on the display.
Consistent alignment of labels and data will aid display scanning by a user.
Ensure that labels are distinctive in format/positioning to help users distinguish them from data and other display features.
Labels might be capitalized when data are displayed in mixed case, or might be dim when data are bright, or might perhaps be displayed in a different font where that capability exists.
See sample displays in this section.
Ensure that each label is sufficiently close to be associated with its data field, but is separated from its data field by at least one space.
Include the units of measurement for displayed data either in the label or as part of each data item.
| DISTANCE (KM): __ __ __ | or | DISTANCE: __ __ __ KM |
Ensure that the ordering and layout of corresponding data fields is consistent from one display to another.
When forms are used for data entry as well as for data display, ensure that the format for data display is compatible with whatever format is used for data entry; use the same item labels and ordering for both.
Ensure that the internal format of frequently used data fields is consistent from one display to another.
Telephone numbers should be consistently punctuated, perhaps as 213-394-1811.
Time records might be consistently punctuated with colons, as HH:MM:SS or HH:MM or MM:SS.S, whatever is appropriate.
Date records might be consistently formatted with slashes, as MM/DD/YY.
The convention chosen should be familiar to the prospective users. For European users, the customary format for telephone numbers and dates is different than suggested in the examples above. For military users, date-time data are frequently combined in an accepted special format. For many user groups, time records are kept on a 24-hour clock, which should be acknowledged in display formatting.
Divide long data items of mixed alphanumeric characters into subgroups of three or four characters separated by a blank or by some special symbol.
See sample displays in this section.
Words should be displayed intact, whatever their length.
Hyphens may be used instead of blanks where that is customary. Slashes are less preferred for separating groups, since they are more easily confused with alphanumerics.
Where a common usage has been established, as in the NNN-NN-NNNN of US social security numbers, grouping should follow that usage.
Distinguish blanks (keyed spaces) from nulls (no entry at all) in the display of data forms, where that can aid task performance.
See sample displays in this section.
Some special symbol might be adopted to denote null entry. If field delimiters are displayed to guide data entry, then it will often be sufficient simply to leave those delimiters unchanged when no entry has been made.
Tables can display data in row-column format to aid detailed comparison of ordered sets of items.
These sample displays represent a table for finding the owner of a car with a particular license plate. (Perhaps it is an employee who has parked in the wrong place, or who has left headlights burning.) In the good display, data entries are ordered by license number to aid the search.
The bad display is ordered alphabetically by employees' last name, which will not prove helpful for this task. The bad display is annotated to indicate several other violations of the design guidelines proposed here for tabular displays.
|----------------------------------------------------------| | AUTOMOBILE OWNERS Page 1 of 4 | | | | LICENSE EMPLOYEE EXT DEPT | | | | MA 127 355 Michaels, Allison 7715 91 | | MA 135 449 Duvet, William 3898 81 | | MA 227 379 Smithson, Jill 2491 63 | | MA 227 GBH Zadrowski, Susan 2687 53 | | MA 253 198 Jenskin, Erik 3687 31 | | | | MA 286 PAM Hilsmith, Joseph 2443 100 | | MA 291 302 Leonard, John 7410 92 | | MA 297 210 Toth, Kelley 7538 45 | | MA 328 647 Cooksey, Roger 2144 64 | | MA 342 NCG Hesen, Christopher 7544 21 | | | | MA 367 923 Maddox, Patrick 7070 66 | | MA 375 NRC Ashley, Maria 3397 34 | | MA 376 386 Wheetley, Katherine 2638 58 | | MA 385 248 Malone, Frank 2144 64 | | MA 391 293 Lowman, Edward 8263 77 | | | | n = Next page | | < | |----------------------------------------------------------|
This bad tabular display violates in some degree several design guidelines in this section: 2.3/2 Logical organization 2.3/4 Tables referenced by first column 2.3/6 Row and column labels 2.3/12 Consistent column spacing 2.3/13 Column scanning cues 2.3/14 Row scanning cues 2.3/16 Justification of numeric data Various other guidelines are also violated in this bad table, including those pertaining to identification of multipage displays and display of control options.
|----------------------------------------------------------| | Automobile Owners | | Sara Alwine 2438 MA 929 448 103 | | Christopher Aranyi 2716 MA 797 AND 97 | | Maria Ashley 3397 MA 375 NRC 34 | | Arlene Atchison 7672 NH 60731 28 | | Steven Bahr 3272 MA 635 203 35 | | David Baldwin 3295 NH 63577 75 | | David Benkley 3581 MA 589 ADE 58 | | Marlin Boudreau 3413 MA 816 HER 93 | | Roger Cooksey 2144 MA 328 647 64 | | Joseph Curran 3167 RI 4693 83 | | Kent Delacy 3619 MA 749 827 29 | | Susan Doucette 2797 MA 525 115 41 | | Joseph Drury 7604 NH 42265 27 | | William Duvet 3898 MA 135 449 81 | | Samuel Everett 3619 MA 635 ASK 29 | | Jeanne Fiske 7642 MA 614 CSU 10 | | Nancy Graham 2358 MA 745 CKJ 10 | | Paul Greenbaum 3979 MA 846 BLN 103 | | Christopher Hesen 7544 MA 342 NCG 21 | | Joseph Hilsmith 2443 MA 286 PAM 100 | | | | | | < | |----------------------------------------------------------|
When information handling requires detailed comparison of ordered sets of data, adopt a tabular format for data display.
Organize tabular data in some recognizable order to facilitate scanning and assimilation.
Dates might be ordered chronologically, names alphabetically.
See sample displays in this section.
Construct a table so that row and column labels represent the information a user has prior to consulting the table, i.e., the information that can be used to access table entries for a particular task.
If a user's task were to determine characteristics of various raw materials, then a table might be organized as
| Raw Transport Processing Consumer | | Material Costs Time Acceptance | | A High Slow Good | | B High Fast Good | | C Low Slow Good | | D High Slow Poor | | E High Fast Poor | | F Low Fast Poor |
whereas if the user's task were to identify what raw material meets certain criteria, then the table might be organized as
| Consumer | | Acceptance | | Good Poor | | | | High Fast Processing B E | | Transport | | Costs Slow Processing A D | | | | Low Fast Processing F | | Transport | | Costs Slow Processing C |
When tables are used for reference, display the reference items, i.e., those by which the table will be accessed, in the left column; display the material most relevant for user response in the next adjacent column; and display associated but less significant material in columns further to the right.
See sample displays in this section.
As a corollary, when a list of people is ordered alphabetically by their last name, then their last names should be displayed first, i.e., as the leftmost element in each row.
If data items must be compared on a character-by-character basis, display one directly above the other.
But remember that users will not be entirely accurate in making such comparisons; automated comparison by computer analysis would be more reliable.
Label the rows and columns of tabular displays following the guidelines proposed for labeling the fields of data forms.
See sample displays in this section.
Adopt a consistent format for labeling the rows and columns of displayed tables.
Each column label might be left-justified with the leftmost character of the column entries beneath it.
Consistent left justification of column labels will prove especially helpful when columns vary in width.
Ensure that row and column labels are distinguishable from the data displayed within tables, and from the labels of displayed lists such as menu options or instructions to users.
There are many ways to distinguish different types of labeled material, including consistent differences in display format/placement as well as special fonts and markers.
When rows or columns are labeled by number, start the numbering with "1", rather than "0".
In counting, people start with "one"; in measuring, they start with "zero".
For hierarchic lists with compound numbers, display the complete numbers; do not omit repeated elements.
(Good)
| 2.1 Position Designation | | 2.1.1 arbitrary positions | | 2.1.1.1 discrete | | 2.1.1.2 continuous | | 2.1.2 predefined positions | | 2.1.2.1 HOME | | 2.1.2.2 other |
(Bad)
| 2.1. Position Designation | | 1. arbitrary positions | | 1 discrete | | 2 continuous | | 2. predefined positions | | 1 HOME | | 2 other |
Implicit numbering, as in the "bad" example, may be acceptable for tasks involving perception of list structure. Complete numbering is better, however, for tasks requiring search and identification of individual items in the list.
In tabular displays, either consistently include the units of displayed data in the column labels, or else place them after the first row entry.
(Good)
| Time Velocity Temperature | | (s)_ (m/s)___ (0C)_______ | | 5 8 25 | | 21 49 29 | | 43 87 35 |
(Also acceptable)
| Time Velocity Temperature | | 5 s 8 m/s 25 0C | | 21 49 29 | | 43 87 35 |
Maintain consistent column spacing within a table, and from one table to another.
See sample displays in this section.
When columns are grouped under superheadings, it may help to add extra space between superheadings, in order to emphasize that the columns under any single superheading are related.
Separate the columns in a table by enough blank spaces, or by some other distinctive feature, to ensure separation of entries within a row.
See sample displays in this section.
For most tables, a column separation of at least three spaces should be maintained. Certainly the spacing between columns should be greater than any internal spaces that might be displayed within a tabulated data item.
In dense tables with many rows, insert a blank line (or some other distinctive feature to aid horizontal scanning) after a group of rows at regular intervals.
For many applications it will suffice to insert a blank line after every five rows.
See sample displays in this section.
Show columns of alphabetic data with left justification to permit rapid scanning.
(Good)
| APL | (Bad) | APL | | COBOL | | COBOL | | FORTRAN | | FORTRAN | | PL1 | | PL1 |
Indentation can be used to indicate subordinate elements in hierarchic lists.
A short list, of just four or five items could be displayed horizontally on a single line, in the interests of compact display format, if that is done consistently.
Justify columns of numeric data with respect to a fixed decimal point; if there is no decimal point, then numbers should be right-justified.
See sample displays in this section.
When a user must enter numeric values that will later be displayed, maintain all significant zeros; zeros should not be arbitrarily removed after a decimal point if they affect the meaning of the number in terms of significant digits.
Graphics show spatial, temporal, or other relations among data by special formatting of displayed elements.
Consider graphics rather than text description or tabulation, for display of data showing relations in space or time.
People cannot readily assimilate detailed textual or tabular data, although sometimes such data are necessary. Therefore, a graphic display might be designed where graphic elements showing trends and differences are combined with text annotation and tabular presentation of detailed data. In some applications, it might prove helpful to supplement a primary graphic display with alternative displays of detailed data available as a user-selected option.
When users must quickly scan and compare related sets of data, consider graphic format to display the data.
Graphic display might help users discern errors in a data base, since deviant "outliers" will appear visually distinct from the body of correct data.
When users must monitor changing data, consider graphic format to display the data.
Whenever possible, the computer should handle data monitoring and should call abnormalities to the user's attention. When that is not possible, and a user must monitor data changes, graphic display will make it easier for the user to detect critical changes and/or values outside the normal range.
The current lore of graphic design derives chiefly from static, printed displays. Computer processing, however, offers a potential for continuous dynamic display of changing data that should be considered in all methods of graphic presentation.
Use consistent logic in the design of graphic displays, and maintain standard format, labeling, etc., for each method of graphic presentation.
Consistency in graphic design will allow users to focus on changes in displayed data without being distracted by changes in display format.
The standardization advocated here has to do with the logic of user interface design, not with internal processing by graphics software. Recent efforts to establish international standards for graphics software have been focused on the internal encoding, processing, storage and transmission of graphics displays in digital form. Such data processing standards do not in themselves specify or significantly constrain user interface design.
Tailor graphic displays to user needs and provide only those data necessary for user tasks.
Current advances in the technology (and theory) of graphic display permit realistic depiction of complex natural scenes. Such technology has been successfully applied to generate displays for arts and entertainment, and may also find increasing application to information displays. For many information displays, however, less may be more: an abstracted schematic diagram, omitting much detail, may convey more effective information than a photographic image. For any particular application, the amount of detail needed should be determined based on a task analysis.
When a user's attention must be directed to a portion of a graphic display showing critical or abnormal data, highlight that feature with some distinctive means of data coding.
On a bar chart, one bar representing an out-of-tolerance condition might be textured or shaded differently to call attention to it and to contrast it with other bars.
More specific recommendations for highlighting different kinds of graphic displays are provided elsewhere in this section.
When a user must compare graphic data to some significant level or critical value, include a reference index or baseline in the display.
A horizontal line might be displayed on a profit-and-loss graph to indicate where displayed curves exceed the break-even point.
Most data plots include a displayed baseline of some sort. An additional reference index may be displayed as well. The baseline should be chosen with care to provide an appropriate reference for displayed data. A graph without a baseline, or with a poorly chosen baseline, may distort the interpretation of displayed data.
More specific recommendations for indexing different kinds of graphic displays are provided elsewhere in this section.
When a graph contains some outstanding or discrepant feature that merits attention by a user, consider displaying supplementary text to emphasize that feature.
A flow diagram for process control might include a current advisory message, POSSIBLE PRESSURE VALVE FAILURE, as well as appropriate graphic indications of the problem.
This recommendation derives from the lore of audiovisual aids, where speakers are exhorted to "get the message across" with words as well as pictures. In some information system applications, a graphic display may convey many messages at once. It might then prove difficult to determine which message(s) should be stated in words. As in other aspects of display design, some priorities must be established in relation to the user's information requirements.
When precise reading of a graphic display is required, annotate the display with actual data values to supplement their graphic representation.
Adjacent numeric annotation might be added to the ends of displayed bars on a bar graph; numeric data might be displayed to mark the points of a plotted curve.
Some displays may require complete data annotation, but many displays will require annotation only for selected data elements.
Format any displayed annotation consistently in relation to the graphic elements.
Labels might always be placed over the displayed points with which they are associated.
Sometimes it might be necessary to displace a label from its "standard" position to avoid overlap or crowding on the display; such exceptions should themselves be handled consistently.
Display the annotation of graphic displays, including labels for the axes of graphs, in a normal orientation for reading text.
For users reading English, labels should be displayed horizontally, even for the vertical axis of a graph.
A conventional text orientation of labels will permit faster, more accurate reading. With a printed graph, it may be possible to tilt the page to read a disoriented label. With an electronic display, a user usually cannot tilt the display screen but instead must tilt his/her head.
More specific recommendations for labeling different kinds of graphic displays are provided elsewhere in this section.
Establish standard meanings for graphic symbols and use them consistently within a system and among systems with the same users.
As a negative example, if an aircraft symbol is used to denote an aircraft on one display, that symbol should not be used to mark airfields on another display.
If users may be unfamiliar with the graphic symbology used, consider incorporating a legend to define displayed symbols. Alternatively, users might be allowed to request a supplementary display of symbol definitions or to request the definition of a particular displayed symbol by pointing at it.
Design pictorial symbols (e.g., icons, pictograms) to look like the objects or processes they represent, and test the resulting symbol set with a representative group of users to ensure that the intended meanings will be understood.
Some pictorial symbols have conventional meanings within a user population, which must be followed to ensure their correct interpretation. Novel symbol design must always be tested. It can happen that a symbol whose meaning seems perfectly clear to its designer may not be understood by system users.
In selecting textures to code displayed areas, choose simple hatching rather than elaborate patterns.
Compared with manual drafting methods, it is temptingly easy to have a computer generate texture codes of considerable complexity. A designer should resist that temptation. When in doubt, create some sample displays and check them to ensure that texture codes do not produce distracting visual effects such as moire patterns.
Texture coding is a technique specifically related to graphics. Other kinds of display coding -- size, shape, brightness, color, etc. -- can be applied more generally in display design. Display coding is considered in Section 2.6 of these guidelines.
When a user may need to perceive graphic relations more accurately, or to view pictures, diagrams, maps, etc. in greater detail, provide a zooming capability that allows the user to expand the display of any selected area.
Zooming can increase display spacing among crowded data items so that they can be perceived better. Thus an air traffic controller might expand a portion of a situation display to see more clearly the spacing of converging tracks that threaten a collision.
Zooming can increase the degree of detail, i.e., can add data to a display. Thus a user might expand a city map to see detailed road structures that are not shown in a small-scale map. When used this way, a zooming capability implies that graphic data be "layered" hierarchically at different levels of aggregation, which may require complex data files and data management techniques.
Zooming might be implemented as a continuous function, by which a display can be expanded to any degree, analogous to a continuous panning capability. Or zooming might be implemented in discrete increments, as in increasing the magnification of an optical instrument to x2, x4, etc. Incremental zooming, with abrupt changes in display scale, may tend to disorient a user, but might prove acceptable in some applications.
When a map or other graphic display has been expanded from its normal coverage, provide some scale indicator of the expansion factor.
A linear indicator of current map scale might be shown in the margin, or perhaps simply a numeric indication of the display expansion factor (e.g., | x4 |).
In many applications it may be helpful to show the scale even for a display with normal, unexpanded coverage.
When a display has been expanded from its normal coverage, provide some graphic indicator of the position in the overall display of the visible section.
In a corner of any frame of an expanded display, the computer might show a rectangle representing the overall display, in which a smaller rectangle is placed to indicate the position and extent of the currently visible portion of that display.
A graphic indication of the current coverage of an expanded display will provide some visual context to help a user maintain a conceptual orientation between the visible part and the whole display from which that part has been expanded.
Consider animation, the movement of data elements under computer control, for displaying a temporal sequence of changing events, or for the pictorial display of complex objects.
For air traffic control, sequential frames of radar data might be displayed (with time compression) to aid perception of the tracks from moving aircraft.
A complex molecular structure might be perceived more effectively if a viewer is shown sequential displays depicting a computer-stored model from different angles.
An architect might demonstrate a proposed building design with a sequential "walk through" displayed from a computer-stored model.
Animation can be used to enhance a variety of graphic displays, including scatterplots, curves, bar graphs, flow charts, etc. Computer tools to support display animation are growing more powerful, and should find increased use in information displays. Prototype testing may be required to determine optimal timing for sequential display, which will vary with different applications.
When sequential relations or other connectivity between display elements requires highlighting, consider animation for that purpose.
Connectivity might be emphasized by an arrow moving repeatedly between two displayed elements.
Sequential relations might be emphasized by an animated "sprite", i.e., a moving pointer under computer control.
There was a time when viewers of "sing-along" motion pictures were exhorted to "follow the bouncing ball" which marked their place. A moving marker of that kind is now often called a "sprite", or sometimes a "movable object block" (MOB). Sprites can simplify the process of animating computer-generated displays. Once a graphic element has been defined to a computer as a sprite, that element can be moved about a display independently of a fixed background or of other sprites.
If only one element is shown moving on an otherwise stable display, that moving element will be seen as distinctive. Such animated highlighting is probably subject to diminishing returns. If one sprite is good for directing a user's attention, two may not be. The simultaneous display of multiple sprites may confuse a user.
When on-line graphic displays must be printed, allow users to display the material exactly as it will appear in the printed output.
On-line displays can offer some advantages over printed graphics, in terms of animation and highlighting. When a user is preparing a display for printed output, however, it is important that limitations of the print medium can be taken realistically into account. If the printed version does not appear satisfactory, it may be necessary to reformat the display in some way. Alternatively, it may be possible to find a printer with greater capabilities.
Scaling refers to the positioning of displayed data elements with respect to a defined measurement standard.
Follow conventional scaling practice, so that values on an axis increase as they move away from the origin, and the horizontal X-axis is used to plot time or the postulated cause of an event (the independent variable) and the vertical Y-axis is used to plot a caused effect (the dependent variable).
In a graph showing plant growth, the X-axis might show successive days, or it might show increasing amounts of water or fertilizer applied.
Scaling conventions also apply to the placement of the origin of a graph. When graphed data represent positive numbers, which is usually the case, the graph should be displayed with the origin at the lower left. When the data include negative values and the axes must extend in both directions from a zero point, that origin should be displayed in the center of the graph.
When the X-axis represents time intervals, the labeled scale points should represent the end of each time interval. This consistent usage will aid interpretation of all data plots, including scatterplots, line graphs, and bar charts.
If users must compare graphic data across a series of charts, use the same scale for each chart.
Users will find it difficult to compare data sets that are scaled differently. Moreover, users may overlook differences in labeling, and assume that the same scale has been used even when displayed scales are actually different from one another.
Note that in many applications it may prove more effective to display data for comparison in a single combined chart, rather than requiring users to compare data across a series of charts.
Label each scale axis clearly with its description and measurement units, if any.
Labels might include "Population in Thousands", "Price in $1000", "Percent", "Fiscal Year", etc.
Labels should be displayed in conventional text orientation on both the X- and Y-axis for ease of reading.
Employ a linear scale for displayed data, in preference to logarithmic or other non-linear methods of scaling.
A logarithmic scale shows percentage change rather than arithmetic change; it may be appropriate for some special applications.
Most users are more familiar with linear scales and will interpret linear scales more accurately than other methods of scaling.
Construct scales with tick marks at a standard interval of 1, 2, 5, or 10 (or their multiples by 10) for labeled divisions; intervening tick marks to aid visual interpolation should be consistent with the labeled scale interval.
As a negative example, it is not acceptable to let the computer divide available scale space automatically if that results in a scale labeled in unfamiliar intervals such as 6 or 13.
In special instances, the X-axis might be scaled in odd intervals to show customary divisions, such as the seven days in a week or the 12 months in a year.
Users will find it difficult to interpret scales based on odd intervals, even if computers do not.
When users must compare aggregate quantities within a display, or within a series of displays, scaling of numeric data should begin with zero.
If for any reason the zero point is omitted, the display should include a clear indication of that omission.
When data comparisons of interest fall within a limited range, consider constructing the scaled axis to emphasize that range, with a break in the displayed axis to indicate discontinuity with the scale origin.
Note, however, that a broken axis distorts the displayed amount in relation to a base value and so risks confusing users. In effect, a user will expect that a scale marked in regular intervals will continue in a consistent fashion. If an axis must be broken, label that break clearly, perhaps with some indicator that extends across the displayed graph.
When scaled data will contain extreme values, display duplicate axes, so that the X-axis appears at both the top and bottom, and the Y-axis at both the left and right sides of the graph.
Extreme data values may be located far from conventionally placed axes. When duplicate axes are displayed at the top and right side, users will find it easier to read the extreme values.
Design graphs so that only a single scale is shown on each axis, rather than including different scales for different curves in the graph.
For users experienced in data analysis, multiple-scale charts may prove an effective tool for comparing relative values of different variables.
Single-scale graphs will generally permit more accurate reading than graphs displaying several scales. Many users will be confused by multiple-scale graphs and make errors when interpreting them. Moreover, by changing the relative scale factors of multiple-scale graphs it is possible to change radically their apparent meaning and bias interpretation by users.
If multiple-scale graphs are used, an interactive display capability might aid interpretation, e.g., permitting a user to select any curve and have the computer highlight the corresponding scale for that curve.
If different variables on a single graph seem to require different scales, consider scaling them against a common baseline index, rather than showing multiple scales.
Rather than showing sales in units and profits in dollars, both might be graphed in terms of percent change from a baseline period.
An indexed chart can permit comparisons among different variables when multiple scales would otherwise be needed. However, care should be taken in selecting an appropriate base period against which to index, in order to ensure that comparisons will not be biased.
Index scaling may also be appropriate for showing the effect of a single variable (such as money) whose units of measurement change in real value with time.
Where accuracy of reading graphic data is required, provide computer aids for exact interpolation.
It might suffice to allow users to request a fine grid as an optional display feature; or it might be better to display vertical and horizontal rules that a user could move to intersect the axes of a chart; or it might prove best simply to let a user point at any data item and have the computer label that item with a readout of its exact value(s).
When grid lines are displayed, ensure that they do not look like data and do not obscure data elements -- curves, bars, plotted points, etc.
Grid lines should be thinner than data curves, and should be invisible behind depicted objects and areas such as the bars on a bar chart. Note in particular that heavy vertical grid lines may conceal the height of plotted peaks.
In this respect, electronic displays offer more flexibility than printed graphs. Grids can be displayed or suppressed by user selection. For reading the value of a particular data point, perhaps no grid is needed at all. A user might simply ask the computer to display the value of any selected point.
Consider three-dimensional scaling, where a Z-axis is added to the display, only in special applications for experienced users.
Showing a Z-axis on a display that is limited to two actual dimensions will confuse many users. If three-dimensional scaling is employed, adopt a consistent method of representation, e.g., isometric or orthographic projection, perspective drawing, or triangular coordinate grid.
It is often possible in graphic display to show a third dimension through use of auxiliary coding -- e.g., color or shape coding, or supplementary annotation -- which may prove more effective than trying to represent a third spatial dimension pictorially.
Scatterplots show relations among the individual data points in a two-dimensional array.
Consider scatterplots, in which data are plotted as points in a two-dimensional graph, to display how two variables are correlated or to show the distribution of points in space.
A changing display of points representing radar data, such as those used for monitoring aircraft tracks, might be regarded as a dynamic scatterplot.
Curves can be superimposed on scatterplots to indicate computed data trends, correlations, or other derived statistical measures, thus combining two types of graphic display.
Scatterplots, as the name implies, are sometimes used to show a dispersal intended to indicate non-correlation of variables. But scatterplots may not be convincing for that purpose, because users will often perceive or imagine patterns in scattered data points where none actually exist.
Note that scatterplots cannot be shown effectively in most forms of three-dimensional spatial representation because of inherent display ambiguities. (Here the triangular grid might be considered an exception.) A third dimension might be represented by coding the symbols used to plot different data categories. If that is done, however, the visual correlation between any two variables in the scatterplot will be obscured.
If some plotted points represent data of particular significance, highlight those points to make them visually distinctive from others.
Significant data points might be highlighted by bolding, color, blinking, shape coding, or other means, or might be designated by supplementary display annotation.
When relations among several variables must be examined, consider displaying an ordered group (matrix) of scatterplots, each showing the relation between just two variables.
The ordering of several scatterplots in a single display might help a user discern relations among interacting variables.
When scatterplots are grouped in a single display to show relations among several variables, provide some interactive aid for analysis so that if a user selects a set of data in one plot then the corresponding data points in other plots will be highlighted.
Data selection might be accomplished by "brushing" a scatterplot with a superimposed box of controllable size to define the data set of interest. That technique can exploit the capabilities of interactive graphics to permit a range of data analysis not possible when using printed graphs.
Curves and line graphs show relations among sets of data defined by two continuous variables.
Consider curves (in which data relations are summarized by a smoothed line) or line graphs (in which plotted data points are connected by straight line segments) for displaying relations between two continuous variables, particularly for showing data changes over time.
Line graphs are regarded here merely as a special form of plotted curves, hence recommendations for displaying curves are intended to apply also to line graphs.
Curves are generally superior to other graphic methods for speed and accuracy in interpreting data trends. Unlike printed graphs, computer-generated curves can show dynamic data change, as in oscilloscope displays.
A curve implies a continuous function. Where that could be misleading, a better choice might be a bar graph composed of discrete display elements from one data point to the next.
Sometimes curves may be combined with other graph types. For example, annual sales for the past several years might be displayed as a bar chart, followed by curves to indicate monthly sales during the current year.
When several curves must each be compared with the others, display them in one combined graph.
The objective here is an integrated display that will provide a user with all needed information. On the other hand, as more curves are added to a graph the user's task of comparison will become more difficult. Some designers recommend that no more than four curves be displayed in a single graph. Certainly it is clear that some reasonable limit should be adopted.
If one particular curve must be compared with each of several others, some designers recommend multiple charts in which each pairing is shown separately, rather than displaying all the curves in one single chart. When multiple charts are used for such a purpose, the same scale should be used in each of the charts.
When multiple curves are included in a single graph, each curve should be identified directly by an adjacent label, rather than by a separate legend.
Where displayed curves are too close for direct labeling, an acceptable alternative might be to distinguish the various curves in some way, perhaps by color coding or line coding, and identify their codes in a separate legend.
Direct labeling will permit users to assimilate information more rapidly than displaying a separate legend.
If a legend must be displayed, order the codes in the legend to match the spatial order of their corresponding curves in the graph itself.
If legends are shown for a series of related graphs, then adopt some logical order consistently for all of those legends.
In charts displaying multiple curves, if one curve represents data of particular significance, highlight that curve.
If one curve represents critical/discrepant data, that curve might be displayed with a noticeably thicker line stroke or in a different color.
If line coding is already used to distinguish among multiple curves, then the means of highlighting any particular curve should be selected so that it will not be confused with coding for visual separation. For example, if displayed curves are distinguished by line codes (solid, dashed, dotted, etc.), then one curve might be highlighted by displaying it in a different color.
When multiple curves are displayed in a single graph, and particularly if those curves approach and/or intersect one another, provide line coding to distinguish one curve from another.
Curves might be distinguished by different colors or different line types; commonly recommended line types include solid, dashed, dotted, and dot-dashed.
When one curve must be compared with a set of other curves, which need not themselves be distinguished, then it might help to display all the curves with the same line type and highlight the one curve that is intended to be distinctive.
Lines might also be coded by stroke width, including at least wide (bold) and narrow (light), but it is probably better to reserve that distinction for use in distinguishing data curves (bold) from background display of reference grids (light). In particular, do not use bold or heavy dots for coding, but reserve those for plotting data points.
Aside from conventional means of display coding, it may be possible to provide aids that are more interactive. For example, the computer might highlight any particular curve selected by a user.
When coding by line type in a series of displayed charts, use line codes consistently to represent corresponding data.
When curves represent planned or projected or extrapolated data, show them consistently as broken (dashed or dotted) lines to distinguish them from solid curves representing actual data.
A consistent convention in this regard will make charts easier to interpret.
When curves must be compared with some critical value, include a reference index in the chart to aid that comparison.
In such cases, the index might be displayed as a horizontal or vertical line, or perhaps as a reference curve of some kind.
Where curves represent cyclic data, consider extending the graph to repeat uncompleted portions of the displayed cycle.
A plot showing train arrival times at different stations should be extended beyond a 24-hour cycle as necessary to show the complete schedules of any trains en route at midnight.
The intent here is to allow users to scan any critical portion of the displayed cycle without having to return visually to the beginning of the plot. How much extension is desirable will depend on the particular application. In short, data that are used together should be displayed together.
Where users must evaluate the difference between two sets of data, plot that difference directly as a curve in its own right, rather than requiring users to compare visually the curves that represent the original data sets.
If two curves represent income and expenses, then it might help to plot the difference between those curves to show profit (or loss).
Some designers recommend band charts, where two curves are plotted and the area between them is textured or shaded, for applications where the difference between curves is of interest, but where that difference must be interpreted in terms of the absolute values of the two variables.
When curves represent all of the portions of a whole, consider using a surface chart in which curves are stacked above one another to display aggregated amounts, and the areas defined below the curves are textured or shaded.
Surface charts might be appropriate to display sales volume over time in different market areas, or for different products.
The area texture or shading between curves has an implication of volume that is appropriate for many purposes. However, for curves that do not represent parts of a whole (e.g., a set of price indices), surface charts might have misleading implications and should not be used.
Surface charts permit smooth, continuous display of data categories that might be represented in more discrete form by a set of segmented bars. Thus, recommendations for surface charts may be applied also to segmented bar charts.
Order the data categories in a surface chart so that the least variable curves are displayed at the bottom and the most variable at the top.
In a surface chart, any irregularity in the bottom curve will "propagate" throughout the curves above it, which will make it difficult for a user to distinguish whether apparent irregularity in upper curves is real or merely a consequence of this method of presentation.
Sometimes there are independent logical grounds for the ordering of data categories. If a surface chart constructed on a logical basis produces confusing irregularity of curves, then it might be better to display the data in some other graphic format.
Where space permits, label the different areas of surface charts directly within the textured or shaded bands.
Consider cumulative curves to show the current total at any point; but do not rely on cumulative curves to show effectively the amount of change at any point.
Cumulative curves tend to "wash out" local variations in the displayed data. The rate of change in incremental data can be estimated by judging the slope of a cumulative curve at any point, but that is hard to do.
Bar graphs show a comparative measure for separate entities or for a variable sampled at discrete intervals.
Consider bar graphs, where numeric quantities are represented by the linear extent of parallel bars, for comparing a single measure across a set of several entities or for a variable sampled at discrete intervals.
Displayed bars are usually shown extending from a common origin. For some applications, however, the bars might extend between separately plotted high- and low-points. Bars might be displayed, for example, to indicate the range of observed measures.
The displayed linear extent of adjacent bars permits direct visual comparison of quantity, and thus effective assimilation of comparative data by users.
The value of the bar graph format, as with other graphic displays, is to speed information assimilation by a user. In some applications, however, a user can scan displays in a leisurely way, as when reviewing printed output. In such cases, the data shown in a bar graph could often be presented more economically (i.e., more compactly) by a textual description or in a small table.
For experienced users, the overall pattern of a bar graph may serve a diagnostic function beyond the comparison of individual bars. For example, if multiple bars show data from different components of a complex system, then users may learn characteristic "profiles" of the bars which indicate system status.
Consider histograms (step charts), bar graphs without spaces between the bars, when there are a great many entities or intervals to be plotted.
Histograms are often used to plot frequency data, i.e., the frequency of observations for each of many intervals scaled along the X-axis. For such applications, a histogram will avoid the "picket fence" appearance which might result from spaces between bars.
In a related series of bar graphs, adopt a consistent orientation for bars displaying similar information, either vertical or horizontal.
Vertical bars can be used to display frequency counts, size, cost, or a large variety of other measured attributes.
If bar length is used to represent time duration, then it might be more appropriate to orient the bars horizontally, in accord with the general convention of plotting time on the horizontal axis of a graph.
Consistent orientation will aid users in assimilating information from a series of bar graphs.
Here the phrase "bar graph" is used to denote graphic displays in which bars extend either horizontally or vertically. Some designers distinguish between these two alternatives, calling displays with vertical bars "column charts".
Space adjacent bars closely enough that a direct visual comparison can be made without eye movement.
In this regard, some designers recommend that the spacing between bars be less than the bar width.
If there are a great many bars to be displayed, then spacing will produce an alternating pattern of bright and dark bands that could prove visually disturbing, particularly for viewers with epileptic vulnerability. In such a case it might be better to display a histogram with no spacing between bars.
When the extent of displayed bars must be compared with some critical value, include a reference index in the chart to aid that comparison.
A horizontal line might be an adequate reference index for a vertical bar graph.
If bars are shown to monitor the pulse rates of patients under intensive care, then two reference lines might be displayed to define an acceptable zone.
Indexing may be complicated in situations where the displayed bars do not represent a common measure. In such a case, it might help to choose (or devise) an index scheme so that bar lengths will fall in the same zone under normal conditions, so that deviations in bar length will be readily noticed by users who must monitor changing data.
In a simple bar graph, if one bar represents data of particular significance, highlight that bar.
If one bar represents critical/discrepant data, that bar might be displayed with different tonal coding, such as solid black rather than cross-hatched (or vice versa).
If bar coding is already used for other purposes, such as to distinguish among different sets of grouped bars, then no additional highlighting code should be superimposed on the bars themselves; perhaps some other means of highlighting (e.g., an arrow) might be adopted.
When paired measures from two data sets must be compared, consider displaying each pair as contiguous or (partially) overlapped bars.
A common application of paired data is the display of planned versus actual quantities.
Paired bars will permit a direct visual comparison by the user. When more than two data sets must be compared, a display of grouped bars will be less effective. As the number of matched items becomes larger, it might be better to display the data sets in separate bar graphs, or to allow users to select different sets of data for simultaneous display.
In some applications, a good alternative might be to display directly the difference between paired measures. That is to say, a pair of bars showing income and expenses might be converted to a single bar showing the net difference: a "profit" bar might be displayed extending above a "break-even" index line, and a "loss" might be displayed descending below that line.
In a dynamic display where bar length may change while being displayed, it will probably not be a good design choice to overlap the bars.
When bars are displayed in pairs, label the bars in one pair directly to distinguish the two entities being compared, rather than displaying a separate legend.
Direct labeling of bars will permit efficient information assimilation by a user. If the user has to refer to a separately displayed legend, interpretation of the chart will be slower and more subject to error.
It will probably be sufficient to label just one pair of bars rather than all of them. Labels should have a conventional orientation for reading text. In a dynamic display where bar length may change while being displayed, label position may have to change accordingly.
Consider stacked bars, in which differently coded segments are shown cumulatively within a bar, when both the total measures and the portions represented by the segments are of interest.
In stacked bars, order the data categories within each bar in the same sequence, with the least variable categories displayed at the bottom and the most variable at the top.
In effect, a series of stacked bars is analogous to the stacked curves of a surface chart, and the same design considerations should apply.
Some designers recommend displaying the largest values as the bottom segment. Whatever logic is chosen should be maintained consistently from one display to another.
Consider using iconic symbols of varying size (rather than simple bars) to represent quantitative values in bar graphs only in special cases when unambiguous icons can be provided and when no interpolation will be necessary.
In general, use of icons to represent quantitative information, such as when a silhouette of a person represents 1000 people in a graph, should be avoided. Icons are often ambiguous, and so must be explained somewhere on the figure. In addition, users will find it difficult to interpolate using icons. If a silhouetted person represents 1000 people, then how many people are represented by a silhouette showing just two legs?
Pie charts show apportionment of a total into its component parts.
Consider a pie chart only in special cases to show the relative distribution of data among categories, i.e., for displaying data that represent proportional parts of a whole; but note that a bar graph will permit more accurate interpretation for such applications.
There are several significant limitations to a pie chart -- in itself it provides no means of absolute measurement, it cannot represent totals greater than 100 percent, and it can only represent a fixed point in time.
Estimation of angular relations, as required in pie charts, is less accurate than estimation of linear extent. Pie charts may have artistic merit in some applications, but will not support accurate assimilation of data.
If pie charts are used, some designers recommend that partitioning be limited to five segments or less.
Multiple pie charts will not permit accurate comparison of different totals, although different-sized pies can be used to indicate gross differences. Stacked bar graphs will prove more effective for this purpose and should be used when it is necessary to show proportions of different totals.
If pie charts are used, label the segments directly rather than by a separate legend, in a normal orientation for reading text.
If pie charts are used, add numbers to their segment labels to indicate the percentage and/or absolute values represented in the display.
Because pie charts include no explicit reference scale or index, the only way they can convey numeric values accurately is through their labeling.
If a particular segment of a pie chart requires emphasis, highlight it by special hatching or shading and/or by "exploding" it, i.e., displacing it slightly from the remainder of the pie.
Pictures and diagrams show relations among the various elements of objects or processes.
Use pictorial displays in applications where it is necessary to show accurately detailed representations of real or imaginary objects or processes.
Pictorial displays aid in the analysis of objects and events, as in the case of photo interpretation.
Pictorial displays support a variety of computer-aided design applications, including the design of aircraft, artificial hearts, automobiles, etc.
In some applications it may be possible for a computer to synthesize pictorial displays from stored data. This is true in computer-aided design, where the computer must display a designed object that does not yet exist. For a map-reading task, a computer might synthesize perspective views of terrain from topographic data, where real images are not available.
For some information-handling tasks the display of detailed images (photographs) will help users. In other instances, simplified line drawings may be more readily comprehended.
Dynamic display of "moving pictures" can exploit various animation techniques to improve the pictorial representation of complex objects and processes.
Use diagrams to show spatial relations, with selective focus on the data specifically required by a user's task, in applications where a full pictorial rendering might be unnecessarily complicated.
Diagrams are used to support many applications, ranging from mechanical assembly/maintenance instruction to the representation of electronic circuitry, or floor plans, or organizational hierarchies.
Diagrams are here considered a special form of picture. Diagrams should be kept as simple as possible, omitting unnecessary data. A system diagram for a subway engineer would have to be quite complex, showing accurate distances and directions, and perhaps the relation between subway sections and surface streets, utility lines, etc. But a subway diagram intended for a tourist might display simply the connecting links between one station and another.
When diagrammed data exceed the capacity of a single display frame and must be shown in separate sections, provide an overview for the diagram, a consistent notation to indicate the logical linking of its various sections, and an easy means for users to move from one section to another.
The sections of a diagram might be assigned letter codes, which could be shown in the overview and at any internal branch points, and which could be entered by a user to request the display of various sections.
General guidelines for linking sectional displays by paging/scrolling are considered elsewhere under the topic of display framing. The concern here is to establish a coherent structure to show logical relations among the separately displayed parts of a diagram. The solution may require internal notation and perhaps replication of some portions of the diagram from one section to another.
An alternative approach might be to construct a hierarchic diagram with a zooming capability to show greater detail. That capability represents a potential advantage of computer-generated electronic displays over printed diagrams.
If a picture or diagram contains data of particular significance, implying a special need for user attention, highlight those data.
Selected portions of pictures might be highlighted by adding a box outline to the display, or perhaps a blinking arrow; diagram elements might be highlighted by bolding or video reversal, or perhaps by color coding.
Highlighting might be used to indicate a computer analysis of design deficiencies in a depicted object, or an assessment of damage when monitoring a system that has been degraded in some way.
In an application where a user must examine a depicted object from different viewpoints, allow the user to rotate its displayed image.
The axis of rotation will generally be the center of the depicted object. Where that is not the case, some indication of the rotation axis should be displayed. In some applications it might also help the user to display some explicit separate indication ("gnomon") of the degree of rotation and the current orientation of the depicted object.
In applications where a user must make a detailed comparison of two (or more) displayed objects, it may be necessary to allow independent rotation, translation and superposition of their images.
When users must analyze pictorial images in detail, provide appropriate computer aids for that purpose.
For examining displayed surfaces, it might be helpful to allow a user to specify/control the light source adopted for computer-generated images.
For photo interpretation, computer processing can sometimes improve the visual quality of stored images, as by edge enhancement.
For examining the component structure of a complex object, as for an assembly or maintenance task, it might be helpful to allow a user to "explode" an aggregate display into its several elements.
For examining the internal structure of a depicted object, it might be helpful to allow a user to request auxiliary displays of specified cross-sections or transect diagrams.
For more detailed structural analysis of depicted objects, it might be necessary to provide computer aids for calculating area, volume, center of gravity, modes of vibration, stresses, heat transfer, etc.
Flowcharts are diagrams that illustrate sequential relations among elements or events.
Consider flowcharts for schematic representation of sequence information, i.e., to display data that are logically related in terms of sequential processes.
Flow charts are frequently used for process control, project scheduling, and other similar applications.
Consider providing a flowchart to aid problem solving when a solution can be reached by answering a series of questions, and when no tradeoffs will be required.
In process control, a flowchart might aid problem diagnosis when a user must determine the cause of abnormal conditions and take appropriate action.
A flowchart can add structure to complex problem solving by illustrating a set of discrete decision points. With such a flowchart, a user is given specific steps to follow in solving a problem, helping to ensure that all relevant factors are considered. For simple problems, however, a tabular or text format may be read more quickly than a flowchart.
Flowcharts are not useful when a user must make tradeoffs. For example, if a user must evaluate alternative outcomes if s/he could invest more money or could accept lower quality, then using a flowchart would be cumbersome and time consuming. When a user must evaluate alternatives, a tabular format may be more efficient.
Design flowcharts so that their displayed steps follow some logical order.
When a flowchart displays some sequential process, then display the steps in the order of that sequence.
When a flowchart is provided as a problem solving aid, then steps might be ordered by importance, where those decisions which will have the largest impact on the final problem solution are made first, or ordered by certainty, where decisions which can be made with the most certainty are made first.
When there is no inherently logical order to the steps in a flowchart, order them to minimize flowchart size, i.e., to minimize average path length.
Flowchart size can sometimes be reduced by placing first those steps that represent binary decisions.
When all decision options are not equally probable, consider minimizing the length of the most likely path, i.e., that most frequently followed, rather than minimizing the overall size of the flowchart.
Design flowcharts so that the path of the logical sequence is consistent with familiar orientation conventions, i.e., from left to right (for users accustomed to reading English) and from top to bottom, or perhaps clockwise.
When it is necessary to distinguish different types of flowchart elements, adopt a consistent coding scheme for that purpose.
Shape coding of "boxes" in a flowchart is commonly used to indicate the different user actions in an operational sequence diagram that displays the results of task analysis.
Flowchart coding within any system should conform to established conventions and user expectations, with some flexibility to meet changing user requirements. For some applications, such as the operational sequence diagrams noted in the example above, flowcharts may have to meet normative standards established across systems.
In flow charts and other graphics displays, use arrows in a conventional fashion to indicate directional relations in the sequential links between various elements.
If one element in a flowchart represents data of particular significance, implying a special need for user attention, highlight that element.
Line coding by color or bolding might be used to highlight displayed paths, and/or the boxes or other graphic elements representing displayed states.
Highlighting might be used to distinguish scheduled vs. actual accomplishment, emphasizing critical time delays, cost overruns, or other discrepant conditions.
As a cautionary example, the flowchart instructions for cleaning an electric lawnmower might highlight a box which says "unplug it before touching the blade".
Color coding may be particularly appropriate in flowcharts, because of the effective primacy of color for guiding the visual scanning required to trace paths.
When a flowchart is designed so that a user must make decisions at various steps, require only a single decision at each step, rather than combining decisions to reduce flowchart size.
Combining decisions in a single step, such as asking
| Does the temperature exceed 500 0C and the pressure | | exceed 2250 psi? |
may save space. But such a choice might confuse a user who will be uncertain what path to follow if a situation meets only one of the combined criteria, i.e., in this example, if the temperature is above 500 but the pressure is below 2250.
When a flowchart is designed so that a user must make decisions at various steps, display the available options in some logical order.
(Good)
| Temperature at inlet valve (0F): | | h = more than 400 | | a = 300-400 | | l = less than 300 |
(Bad)
| Temperature at inlet valve (0F): | | a = 300-400 | | h = more than 400 | | l = less than 300 |
If options represent stages of a process, those stages should be listed in the order in which they would actually occur.
The ordering of options should not be determined merely by the amount of space that is conveniently available to display them.
When a flowchart is designed so that a user must make decisions at various steps, display the available options in some consistent order from step to step.
"Yes" might always be on the left and "no" on the right.
The point here is that for options which have no inherently logical order, some order should be consistently imposed. Consistent ordering will permit a user to review a flowchart more quickly.
Choose some consistent format for wording the options displayed at the decision points in a flowchart.
Decision options might be worded as questions, such as
| Will this car be driven more than 100 miles a week? |
or worded as statements listing options, such as
| Car will be driven: | | h = more than 50 miles per week | | a = 25 to 50 miles per week | | l = less than 25 miles per week |
Sometimes it may not be possible to use a consistent format for displaying options. However, the more consistent a flowchart can be made in format and wording, the easier it will be to understand and use.
Maps and situation displays are a form of diagram showing geographic relations among objects or events.
Provide maps to display geographic data, i.e., direction and distance relations among physical locations.
Here the term "map" refers to the display of relatively stable geographic data, or the display of slowly changing data such as weather. When mapped data change more quickly, as in the display of aircraft tracks for air traffic control, those diagrams are called "situation displays". Design recommendations for maps will generally pertain also to situation displays.
When several different maps will be displayed, adopt a consistent orientation so that the top of each map will always represent the same direction.
In common use, most maps are oriented so that North is upward.
When maps represent large geographic areas, adopt a consistent method of projecting the earth's curvature on the flat display surface.
For large areas, any method of projection will introduce some distortion of apparent distances in the display. The projection used should be one which minimizes the practical effects of that distortion for the application at hand. If a selected method of map projection is used consistently, viewers can learn to compensate in some degree for the distortion it introduces.
Label significant features of a map directly in the display, when that can be done without cluttering the display.
When labeling and other desired annotation are too extensive to incorporate in the map itself, that material might be shown in some separate, peripheral area of the display. In that case, auxiliary coding might be used to link annotation with associated map features, e.g., by matching symbol codes.
An alternative to fixed labeling would be to permit user interaction with computer-generated graphic displays. If a user selected a mapped point, a label might be temporarily displayed. If a user selected a marginal label, its associated map location might be highlighted.
With interactive graphics, it may be possible to design maps with hierarchic levels of portrayed detail and labeling, so that a user can "zoom in" to examine an area in greater detail or "zoom out" for an aggregated overview.
Position labels on a map consistently in relation to the displayed features they designate.
The names of cities and towns might always be placed immediately above the corresponding symbols showing their locations.
As a practical matter, map displays can get very crowded. It may not always prove feasible to maintain a consistent placement for labels, with the result that designers will be tempted to put labels wherever they will fit. In such a crowded display, labels may obscure map features, and vice versa. Locating and reading labels will be slowed, particularly when map features are displayed closely adjacent to the beginning of labels. Under these circumstances, some other approach to map labeling should be considered to avoid crowding.
When different areas of a map must be defined, or when the geographic distribution of a particular variable must be indicated, consider the use of texture patterns or color or tonal codes for that purpose.
Coding might help define different areas of interest, such as the Eastern, Central, Mountain and Pacific time zones on a map of the United States, or perhaps areas of current rainfall on a weather map.
Area coding might be used to indicate a geographic variable such as elevation or a demographic variable such as population.
In many applications it may be desirable to limit area coding to one variable in order to assure effective information assimilation, in which case a designer should select that variable which is most significant. Another approach might be to allow a user to specify which variable will be coded on a map and to change that selection at will depending upon current task requirements. In some special applications, however, it may be feasible to superimpose several kinds of area coding to permit multivariate data analysis by skilled users.
Where users must make relative judgments for different colored areas of a display, consider employing tonal codes (different shades of one color) rather than spectral codes (different colors).
For reading topographic maps, tonal variation might be used to show the relative height of displayed areas, perhaps with darker hues used to code greater heights.
This recommendation represents an exception to other guidelines advocating distinctive code values. Coding by tonal variation should be considered only for applications where perception of relative differences along a single dimension is more important than perception of absolute values.
People can order categories along a continuous dimension to match tonal variations in one color, whereas people do not have a natural means of ordering different colors.
This recommendation is based on research with layer tints on printed displays. Some testing may be required to determine whether a particular electronic display permits effective variation in color tones.
Where different areas of a map are coded by texture patterns or tonal variation, order the assigned code values so that the darkest and lightest shades correspond to the extreme values of the coded variable.
For indicating the height of mapped terrain, dark shades might be used for high elevations and light shades for low.
Orderly assignment of code values will help users perceive and remember the categories represented by the code.
If one area in a map represents data of particular significance, implying a special need for user attention, highlight that area.
On a weather map, special area coding might be used to indicate severe storm conditions.
When a map exceeds the capacity of a single display frame, in terms of the required extent and detail of coverage, consider providing users a capability to pan the display frame over the mapped data in order to examine different areas of current interest.
General guidelines for viewing different parts of an extended display by paging or panning/scrolling are considered elsewhere under the topic of display framing. Panning will permit users to move continuously over a map in any desired direction, without encountering any internal boundaries imposed by predefined display framing.
An alternative approach might be to define various sections of a large map and link those sections by the same techniques used for linking sections of a large diagram. One risk in that approach is that an area of interest might be at a boundary where none of the sectional maps provide adequate coverage. Thus some degree of overlapped coverage is probably needed at the boundaries of displayed map sections.
When a user pans over an extended display in order to view different sections, provide some graphic indicator of the position in the overall display of the visible section.
In a corner of a panned display, the computer might show a rectangle representing the overall display, in which a smaller rectangle is placed to indicate the position and extent of the currently visible portion of that display.
While panning across a map, moving from one section to another, a user may lose track of what is being displayed, and be uncertain how to move in order to see some other area of interest. An indicator of current position will help maintain user orientation.
When a user must judge distances accurately on a map or other graphic display, provide computer aids for that judgment.
Some designers display for this purpose a movable grid whose scale is controlled automatically by the computer depending upon current map expansion. Some designers have suggested that the grid might consist of a vertical and a horizontal line displayed across a series of concentric range rings. It might be more helpful to display a scaled line (ruler) that a user could move to intercept any two displayed points directly.
For exact measurement, it might be better to allow a user to select (point at) any two points and have the computer "read-out" their separation distance directly. The same technique might be used to determine the direction (bearing) between two points.
When the use of mapped data may be complex, provide computer aids for data analysis.
In topographic analysis, computers might analyze contour data at different sites to calculate slopes and sun exposure for land use planning, or might calculate sight angles to determine radar coverage from different locations, etc.
In applications where the geographic distribution of nongeographic data must be displayed, consider adding other graphic elements to a map for that purpose.
A symbol might be displayed in different sizes to indicate a particular measure in different localities, such as average population age, or average annual rainfall, or incidence of a particular disease.
Small stacked bars might be superimposed on the different areas of a map to indicate the local distribution of some data measure, such as population distribution by age, education, or income.
Alphanumeric characters might be added to a map to show data, but those will not aid a direct visual comparison across areas in the same way that graphic symbols can do. Moreover alphanumeric data may be confused with labels and other kinds of annotation.
When it is necessary to show the geographic location of changing events, which is often the case for monitoring real situations, combine event data with a map background.
A display for air traffic control might superimpose aircraft tracks on a background of geographic coordinates, with supplementary annotation and/or coding to indicate track identification, speed, heading, altitude, etc.
When changes in mapped data are significant for a user's task, include auxiliary graphic elements to indicate those changes.
Auxiliary coding might be needed to indicate the movement of storm fronts on a weather map.
In dynamic maps, i.e., situation displays, data changes involving movement can be shown directly. On static displays, arrows can be added to indicate the direction of movement of mapped elements. Where movement over an extended area must be represented, as in showing weather fronts, directional "pips" can be added to displayed contour lines. Some designers recommend that such pips should be displayed one to two times as large as alphanumeric characters, and that pip spacing should be five to ten times the pip width.
If the particular data categories required at different stages in a user's job cannot be exactly predicted, allow the user to select the categories needed for any information handling task.
In monitoring aircraft separation for collision avoidance, a user might choose to display selectively the aircraft tracks within a particular altitude zone.
To help identify an unrecognized aircraft track, a user might choose to add flight plan data temporarily to an air traffic display.
This recommendation does not lessen the designer's responsibility for determining user needs. Where user information requirements can be defined, displays should be designed to provide necessary data. User selection from available data categories may represent desirable flexibility to meet changing task requirements. However, there is a risk of "data indigestion" if a user selects the wrong categories or too many categories.
Categories of selectable data might include relatively stable elements (e.g., defined flight paths, zones of radar coverage, etc.) as well as the variable elements that represent changing data (e.g., aircraft tracks).
If auxiliary coding is adopted for different data categories, such as shape coding of symbols, code values should be chosen to be distinctive for any likely combination of displayed categories.
Users should be provided a ready reminder of what data categories are available, and an easy means of selecting (or suppressing) displayed categories. This implies category selection by menu or function keys.
When graphic data are changing and displays are automatically updated, provide some stable display elements, e.g., coordinates, geographic boundaries, etc.
For vehicular control, a common display convention is to depict a moving element (aircraft) against a fixed background (horizon).
Stable display elements provide a frame of reference to help users assimilate and interpret data changes.
Moving data may overlay and temporarily obscure other display elements, such as fixed background data. When that happens, the display update logic must determine which data categories have priority on the display and which may be obscured by others, and should restore the obscured elements when the overlaid data moves away, and should further ensure that no data are erased from the display in the process of obscuring and restoring data.
Format refers to the organization of different types of data in a display to aid assimilation of information.
Adopt a consistent organization for the location of various display features from one display to another.
One location might be used consistently for a display title, another area might be reserved for data output by the computer, and other areas dedicated to display of control options, instructions, error messages, and user command entry.
It might be desirable to change display formats in some distinctive way to help a user distinguish one task or activity from another, but the displays of any particular type should still be formatted consistently among themselves.
The objective is to develop display formats that are consistent with accepted usage and existing user habits. Consistent display formats will help establish and preserve user orientation. There is no fixed display format that is optimum for all data handling applications, since applications will vary in their requirements. However, once a suitable format has been devised, it should be maintained as a pattern to ensure consistent design of other displays.
Make the different elements of a display format distinctive from one another.
Different display areas ("windows") can be separated by spacing (where space permits); outlining can also be used to separate different areas, so that displayed data, control options, instructions, etc., are distinct from each other.
Use blank space to structure a display.
Closely packed data are difficult to locate and difficult to read. Thus blank space can be used to advantage to separate different groups of data. Related data items within a group, however, should be displayed close enough to minimize eye movement time in scanning those data.
When a display contains too much data for presentation in a single frame, partition the data into separately displayable pages.
And provide convenient control procedures to allow users to move easily from one page to another.
When partitioning displays into multiple pages, take into account the type of data, and display functionally related data items together on one page.
This recommendation is easily followed for text displays, involving primarily the elimination of "widows", considerate placement of illustrations, etc. For displayed data forms and tables, data grouping and continuation of headers must be considered. The partitioning of graphics displays may require radical redesign.
In a multipage display label each page to show its relation to the others.
When coherent display is required to aid user perception of relations among data sets, provide those data in an integrated display rather than partitioning them into separate windows.
When the need to view several different kinds of data jointly cannot be determined in advance, allow a user to define and select separate data windows that will share a single display frame.
Depending upon user needs (and system capability), data windows might appear simultaneously as segments of a joint display, might be overlaid in varying degrees so as to obscure one another, or might be displayed sequentially at the user's option. In the latter condition, multiple display windows will differ little from multiple display pages, except perhaps in speed of sequential access.
When a display window must be used for data scanning, ensure that the window can display more than one line of data.
Begin every display at the top with a title or header, describing briefly the contents or purpose of the display; leave at least one blank line between the title and the body of the display.
Reserve the last several lines at the bottom of every display for status and error messages, prompts, and command entry.
Assuming that the display is mounted physically above the keyboard, which is the customary placement, a user can look back and forth from keyboard to display more easily when prompts and command entry area are at the bottom of the display.
As a corollary to this recommendation, when separate command sets are associated with different display windows, such as options for display control (size of the window, positioning, etc.), those should be shown at the bottom of each window.
Ensure that displays are formatted to group data items on the basis of some logical principle, considering trade-offs derived from task analysis.
If users must analyze sets of data to discern similarities, differences, trends, and relationships, structure the display format so that the data are consistently grouped.
(Good)
| Cost Output | | Actual Predicted Actual Predicted | | | | 947 901 83 82 | | 721 777 57 54 | | 475 471 91 95 |
(Bad)
| Cost Output | | Actual Predicted Predicted Actual | | | | 947 901 82 83 | | 721 777 54 57 | | 475 471 95 91 |
Where displayed data are used in some spatial or temporal order, consider grouping those data by sequence of use to preserve that order.
Data in an electronic display should match the order of items in an associated paper data form.
Where sets of data are associated with particular questions or related to particular functions, consider grouping each set together to help illustrate those functional relationships.
Where some displayed data items are particularly important, i.e., provide significant information and/or require immediate user response, consider grouping those items at the top of the display.
Where some data items are used more frequently than others, consider grouping those items at the top of the display.
Principles of data grouping also apply to the display/listing of control options.
These recommendations for data grouping in display formatting follow familiar human engineering principles for display/control layout in equipment design.
When there is no appropriate logic for grouping data by sequence, function, frequency or importance, adopt some other principle such as alphabetical or chronological grouping.
Coding refers to distinctive means for highlighting different categories of displayed data for user attention.
Provide distinctive coding to highlight important display items requiring user attention, particularly when those items are displayed infrequently.
Such items might include recently changed data, or discrepant data exceeding acceptable limits, or data failing to meet some other defined criteria.
"Highlight" is used here in its general sense, meaning to emphasize or make prominent, and is not restricted to any particular method of display coding such as brightening or inverse video.
Highlighting is most effective when used sparingly, adding emphasis to a display which is relatively uniform in appearance except for just a few highlighted items.
For some purposes position coding, i.e., displaying important items consistently in a particular location, might be a sufficient means of highlighting, as when an error message appears in a space otherwise left blank. But auxiliary codes may still be needed to highlight important items, even if they are positioned consistently.
If highlighting is used to emphasize important display items, remove such highlighting when it no longer has meaning.
If highlighting identifies an error, remove that highlighting when the error is corrected.
Provide display coding in applications where a user must distinguish rapidly among different categories of displayed data, particularly when those data are distributed in an irregular way on the display.
Adopt meaningful or familiar codes, rather than arbitrary codes.
A three-letter mnemonic code (DIR = directory) is easier to remember than a three-digit numeric code.
An arbitrary code, such as a Social Security Number, may eventually become familiar through frequent use.
Adopt codes for display (and entry) that conform with accepted abbreviations and general user expectations.
Use M for "male", F for "female", rather than arbitrary digits 1 and 2. In color coding, use red for danger.
If in doubt, an interface designer can survey prospective users to determine just what their expectations may be.
When codes are assigned special meaning in a display, provide a definition at the bottom of the display that replicates the code being defined.
The legend on a map is a common example.
For a color code each definition should be displayed in its appropriate color, as | RED = hostile | displayed in red.
Assign consistent meanings to symbols and other codes, from one display to another.
When coding is not consistent, the user's task of display interpretation may be made more difficult than if no auxiliary coding were used at all.
Consider alphanumeric characters for auxiliary coding in display applications such as graphics where the basic data presentation is not already alphanumeric.
Select alphanumeric codes that are visually distinct for visual displays, and phonetically distinct for auditory displays (or in any application where displayed codes must be spoken).
For alphabetic codes display all letters consistently either in upper case or in lower case.
For data display, upper case labels may be somewhat more legible. For data entry, computer logic should not distinguish between upper and lower case codes, because users find it hard to remember any such distinction.
When codes combine both letters and numbers, group letters together and numbers together rather than interspersing letters with numbers.
Letter-letter-number ("HW5") will be read and remembered somewhat more accurately than letter-number-letter ("H5W").
Unfortunately, there are common instances in which this practice has not been followed, such as the coding of British and Canadian postal zones.
When arbitrary codes must be remembered by the user, ensure that they are no longer than four or five characters.
When a code is meaningful, such as a mnemonic abbreviation or a word, it can be longer.
Consider using special symbols, such as asterisks, arrows, etc., to draw attention to selected items in alphanumeric displays.
When using special symbols to signal critical conditions, use them only for that purpose.
When a special symbol is used to mark a word, separate the symbol from the beginning of the word by a space.
A symbol immediately adjacent to the beginning of a word will impair legibility.
Consider coding with geometric shapes to help users discriminate different categories of data on graphic displays.
Approximately 15 different shapes can be distinguished readily. If that "alphabet" is too small, it may be possible to use component shapes in combination, as in some military symbol codes.
When shape coding is used, assign codes based on established standards or conventional meanings.
A number of international, national, and organizational standards for shape coding exist, and those should be followed where they apply.
Although shape codes can often be mnemonic in form, their interpretation will generally rely on learned association as well as immediate perception. Existing user standards must be taken into account by the display designer.
For graphic displays, consider using auxiliary methods of line coding, including variation in line type (e.g., solid, dashed, dotted) and line width ("boldness").
Perhaps three or four line types might be readily distinguished, and two or three line widths.
When a line is added simply to mark or emphasize a displayed item, place it under the designated item.
A consistent convention is needed to prevent ambiguity in the coding of vertically arrayed items.
For words composed from the Roman alphabet, underlining probably detracts from legibility less than would "overlining".
Consider using codes with lines of varying length for applications involving spatial categorization in a single dimension.
The length of a displayed vector might be used to indicate speed.
Perhaps four lengths can be reliably distinguished in practical use. Long lines will add clutter to a display, but may be useful in special applications.
Consider using codes with lines of varying direction for applications involving spatial categorization in two dimensions.
The angle of a displayed vector might be used to indicate direction, i.e., heading or bearing.
Users can make fairly accurate estimates of angles for lines displayed at ten-degree intervals.
Consider size coding, i.e., varying the size of displayed alphanumerics and other symbols, only for applications where displays are not crowded.
Perhaps as many as five sizes might be used for data categorization, but two or three will probably prove the practical limit.
For size coding, a larger symbol should be at least 1.5 times the height of the next smaller symbol.
An increase in symbol height must usually be accompanied by a proportional increase in width to preserve a constant aspect ratio and so facilitate symbol recognition.
Consider coding by differences in brightness for applications that only require discrimination between two categories of displayed items; i.e., treat brightness as a two-valued code, bright and dim.
A data form might display dim labels and bright data items, in order to facilitate data scanning.
Perhaps as many as four brightness levels might be used, but at some risk of reduced legibility for the dimmer items. It will be safer to reserve brightness as a two-valued code, particularly for displays whose overall intensity can be adjusted at the terminal by a user.
When a capability for brightness inversion is available (so-called "reverse video"), where dark characters on a bright background can be changed under computer control to bright on dark, or vice versa, consider brightness inversion for highlighting critical items that require user attention.
Brightness inversion is obviously limited to use as a two-valued code, i.e., a displayed item is either shown with standard or inverted brightness. If brightness inversion is used for alerting purposes, as recommended here, it should be reserved consistently for that purpose, and not be used for general highlighting.
When the relative rather than the absolute values of a variable are important, consider displaying gradual color changes as a tonal code to show the relative values of a single variable.
In displaying ocean depth, a saturated blue might be used to show the deepest point, with gradually desaturated blues to show decreasing depth.
A gradual change in color might be achieved by varying saturation, starting with a saturated hue and gradually adding white. Or the change might be in intensity, starting with an intense hue and gradually adding black. Or the change might be in hue, moving gradually from red through orange, yellow, green, etc.
People can easily make relative color comparisons when colors are displayed simultaneously. However, people find it more difficult to make absolute color judgments. Part of the problem is color naming. A particular blue-green hue might be named "green" by one person but "blue" by another. In the example above, a user could not be expected to associate any particular shade of blue with a specific ocean depth.
Gradual color changes should not be used when absolute values are important, or to code data into discrete categories. As an example, in displaying revenues to determine the point at which a company becomes profitable, it would be more appropriate to use two distinctly different colors, such as black and red, with the color changing at the point of profitability.
When a user must distinguish rapidly among several discrete categories of data, particularly when data items are dispersed on a display, consider using a unique color to display the data in each category.
Different colors might be used effectively in a situation display to distinguish friendly, unknown, and hostile aircraft tracks, or alternatively to distinguish among aircraft in different altitude zones.
Color is a good auxiliary code, where a multicolor display capability is available. A color code can be overlaid directly on alphanumerics and other symbols without significantly obscuring them. Color coding permits rapid scanning and perception of patterns and relationships among dispersed data items.
Perhaps as many as 11 different colors might be reliably distinguished, or even more for trained observers. As a practical matter, however, it will prove safer to use no more than five different colors for category coding.
With some display equipment now providing millions of different colors, designers may be tempted to exploit that capability by using many different colors for coding. The capability to display many colors may be useful for depicting complex objects, and for providing tonal codes to show the relative values of a single variable. However, such a capability is not useful for coding discrete categories, except that it may allow a designer to select more carefully the particular colors to be used as codes.
When selecting colors for coding discrete categories of data, ensure that those colors are easily discriminable.
On a light background, a good choice of colors might be red, dark yellow, green, blue and black; on a dark background, good colors might be a somewhat desaturated red, green and blue, plus yellow and white.
The harder it is for a user to identify a displayed color, the less useful will be the color code. If many colors are used, colors will be closer in hue and harder to discriminate. If color coding is applied to symbols that subtend small visual angles, which makes color perception difficult, there will be a special need to limit the number of colors used.
Varying saturation and intensity in addition to hue may increase the discriminability of colors. For instance, on a dark background a designer might select a saturated yellow but a desaturated red.
Colors selected for coding should be tested with users to ensure that they are easily discriminable. Testing should be conducted under realistic conditions, since such factors as display type and ambient room lighting will affect color perception. If colors will be used for displaying text, care should be taken to ensure that colored letters are legible as well as discriminable.
Employ color coding conservatively, using relatively few colors and only to designate critical categories of displayed data.
Casual, arbitrary use of colors on every display may cause displays to appear "busy" or cluttered. Casual use of color will also reduce the likelihood that significant color coding on particular displays will be interpreted appropriately and quickly by a user.
Add color coding after displays have already been designed as effectively as possible in a monochrome format.
Do not use color coding in an attempt to compensate for poor display format. Redesign the display instead.
Make color coding redundant with some other display feature such as symbology; do not code only by color.
Displayed data should provide necessary information even when viewed on a monochromatic display terminal or hard-copy printout, or when viewed by a user with defective color vision.
When color coding is used, ensure that each color represents only one category of displayed data.
Color will prove the dominant coding dimension on a display. If several different categories of data are displayed in red, say, they will have an unwanted visual coherence which may hinder proper assimilation of information by a user.
Choose colors for coding based on conventional associations with particular colors.
In a display of accounting data, negative numbers might be shown as red, corresponding to past use of red ink for that purpose.
Red is associated with danger in our society, and is an appropriate color for alarm conditions. Yellow is associated with caution, and might be used for alerting messages or to denote changed data. Green is associated with normal "go ahead" conditions, and might be used for routine data display. White is a color with neutral association, which might be used for general data display purposes.
Other associations can be learned by a user if color coding is applied consistently.
2.6/5 | 4.0/13 | 4.0/14 | 4.3/19
Use brighter and/or more saturated colors when it is necessary to draw a user's attention to critical data.
On some display equipment, designers can vary the intensity as well as the saturation for individual hues. On those displays, both intensity and saturation can be used to draw a user's attention to critical data.
Although saturated and/or intense hues are useful for drawing a user's attention, their overuse will result in a display which is garish and difficult to view for long periods.
When deciding the desired saturation of any given display color, consider the ambient lighting under which the display will be viewed. Colors that appear highly saturated in a darkened room will appear less saturated when viewed under high ambient illumination.
Use saturated blue only for background features in a display, and not for critical data.
Saturated blue might be used for shading background areas in graphic displays, where its lower apparent brightness could possibly be of benefit. Or saturated blue might be used to display a background grid or familiar scale on a graphic display.
The human eye is not equally sensitive to all colors, nor are its optics color-corrected. Blue symbols appear dimmer than others, and are more difficult to focus.
If blue must be used for displayed data, use a desaturated blue or cyan in order to make the data more legible.
Consider blink coding when a displayed item implies an urgent need for user attention.
If used sparingly, blinking symbols are effective in calling a user's attention to displayed items of unusual significance. Blinking characters may have somewhat reduced legibility, and may cause visual fatigue if used too much.
Perhaps three or four blink rates might be reliably distinguished, but it will probably prove safer to use blinking as a two-level code, blinking versus nonblinking.
When a user must read a displayed item that is blink coded, consider adding an extra symbol such as an asterisk to mark the item, and then blinking that marker symbol rather than blinking the item itself.
This practice will draw attention to an item without detracting from its legibility.
When blink coding is used, select a blink rate in the range from 2 to 5 Hz, with a minimum duty cycle (ON interval) of 50 percent.
Although equal ON and OFF intervals are often specified, an effective code can probably be provided even when the OFF interval is considerably shorter than the ON (a "wink" rather than a blink), as in occulting lights used for Navy signaling.
Consider other visual coding dimensions for special display applications, including variation in texture, focus, and motion.
Texture can be useful for area coding in graphic displays. Only two levels of focus are feasible, clear and blurred, with the risk that blurred items will be illegible. Perhaps 2 to 10 degrees of motion might be distinguished, in applications where motion is an appropriate and feasible means of display coding.
Consider auditory displays as a means of supplementing visual display, or as an alternative means of data output in applications where visual displays are not feasible.
Auditory signals may be helpful in alerting users to critical changes in a visual display.
Auditory output might be used to permit telephone access to computer-stored data.
Auditory display may be impractical in situations where high ambient noise prevents accurate listening.
As compared with visual displays, an auditory display offers a potential advantage in attracting a user's attention; a user does not have to "listen at" an auditory display in order to hear it. On the other hand, auditory displays suffer from a number of comparative disadvantages. Auditory displays generally do not offer as great a range of coding options. Auditory displays do not permit easy scanning to discern critical data items, or items that may have been missed at first listening. For human listeners with normal vision, auditory displays do not provide a natural representation of spatial relations.
1.3/30 | 4.0/26 | 4.0/27 | 4.0/28 | 4.0/29
For auditory displays, employ distinctive sounds to code items requiring special user attention.
A variety of signals may be available, including sirens, bells, chimes, buzzers, and tones of different frequency.
Tones may be presented in sequence to enlarge the signal repertoire.
For auditory displays with voice output, consider using different voices to distinguish different categories of data.
At least two voices, male and female, could be readily distinguished, and perhaps more depending upon fidelity of auditory output, and listening conditions.
If computer-generated speech output is used for auditory display, add a special alerting signal to introduce voice alarms and warning messages in order to distinguish them from routine advisory messages.
4.0/26 | 4.0/27 | 4.0/28 | 4.0/29
Display control refers to procedures by which a user can specify what data are shown, and how.
When user information requirements cannot be exactly defined by the designer, allow users to tailor displays flexibly on line by controlling data selection, data coverage within a display frame, data updating and suppression.
Here user control of data display is distinguished from the broader control of transaction sequences covered in Section 3 of these guidelines.
Display control by users is certainly a necessary capability in general-purpose data processing systems. In a designed information system, i.e., a system created to perform specific tasks, the need for display control by users will depend on the degree to which users' information requirements can be anticipated by designers. In effect, if you know what data the system users will need, then design the displays to provide those data. If you are uncertain about user requirements, then provide users with some flexibility to control display configuration themselves.
Some more specialized methods of display control (e.g., rotation) are discussed elsewhere in guidelines pertaining to graphic data entry.
Selection refers to the means for specification of data outputs, either by a user or automatically.
For general data processing systems, allow users to specify the data for displayed output; for specific information handling applications, allow users to select data for display as needed to meet task requirements.
Flexibility of data selection by users can be exercised, of course, only within the limits of what data are available within a computer system, and what means for data selection have been provided by the designer.
When a user will select data displays, assign to each display an identifying label, i.e., an alphanumeric code or abbreviation that can facilitate display requests by the user.
An identifying label will help users remember different displays and provide a convenient means for requesting them. Even in systems where users exercise little initiative in data selection, where displays are largely configured in advance by designers, some kind of display identification will help users understand the displayed consequences of sequence control actions.
It may also the helpful to include an identifying label in any separately selected "window" that might be overlaid on another display, as noted in Section 2.7.5.
The display identification label should be unique, short, but meaningful enough to be remembered easily.
As conceived here, the display label serves as a shorthand identification. The label does not take the place of a full, descriptive title. The full title would be displayed separately.
Where flexibility is desired, it may be good practice to let a user assign names to the particular sets of data that constitute commonly used displays, either as formal names or else as nicknames associated by the computer with the formal names.
Place the identifying label used for display selection in a prominent and consistent location on each display.
The top left corner of the display might be used for this purpose.
If the particular data categories required at different stages in a user's job cannot be exactly predicted, allow the user to select the categories needed for any information handling task.
In monitoring aircraft separation for collision avoidance, a user might choose to display selectively the aircraft tracks within a particular altitude zone.
To help identify an unrecognized aircraft track, a user might choose to add flight plan data temporarily to an air traffic display.
This recommendation does not lessen the designer's responsibility for determining user needs. Where user information requirements can be defined, displays should be designed to provide necessary data. User selection from available data categories may represent desirable flexibility to meet changing task requirements. However, there is a risk of "data indigestion" if a user selects the wrong categories or too many categories.
Categories of selectable data might include relatively stable elements (e.g., defined flight paths, zones of radar coverage, etc.) as well as the variable elements that represent changing data (e.g., aircraft tracks).
If auxiliary coding is adopted for different data categories, such as shape coding of symbols, code values should be chosen to be distinctive for any likely combination of displayed categories.
Users should be provided a ready reminder of what data categories are available, and an easy means of selecting (or suppressing) displayed categories. This implies category selection by menu or function keys.
Ensure that system response to simple requests for data display take no more than 0.5 to 1.0 second.
When display output is paced in segments (blocks, paragraphs, etc.), response time refers to output of the first segment. The recommended response time of 0.5 to 1.0 second should apply when a user makes a request (usually perceived as "simple") for the next page of a multipage display, or when a display begins to move in response to a scrolling command. The response to a request for a new display may take somewhat longer, perhaps 2 to 10 seconds, particularly if the user perceives such a request to involve more complicated operations, such as accessing different files, transforming data, etc.
The desirability of rapid display generation is often discounted in practice, particularly for general purpose, time-shared systems where other practical design considerations may dictate slower computer response. For dedicated systems, however, those designed to help perform defined information handling tasks, rapid response should be an explicit design goal, with computer output capabilities designed accordingly.
If display generation is slow, notify the user when display output is complete.
A nonobtrusive auditory signal such as a chime should suffice for this purpose.
Where the computer must regenerate a display to update changed data items, consider regenerating only those changed items if that will speed display output.
The critical design issue here is speed of display. It may be easier for the computer to regenerate an entire display than to change just one item. But if that results in slower computer response to the user, then the added work of selective display regeneration may be worth-while.
Partial display regeneration to show data changes should only be used, of course, when that can be accomplished without erasing unchanged data.
When the computer must regenerate a display to update changed data, erase old data items before adding new data items to the display.
The aim here is to avoid any momentary user confusion that might result from watching portions of old data being overwritten and partially overlapped by portions of new data.
If changing data elements temporarily overlay and obscure other display data, ensure that the obscured data are not permanently erased but will reappear if the overlaid data are later removed.
In a situation display moving track data may temporarily obscure stable background data.
To govern the appearance of data overlay, it may be necessary to establish a hierarchy of data categories to determine which will be shown when displayed in combination. Actively changing data will generally take priority over more stable background/reference data.
When displayed data are of potential long-term interest, give users some easy means to print paper copies locally, within security restraints.
Users should not have to remember displayed data. Optional printout allows a user to record data from one display to compare with another, and so deal with situations where a designer has not anticipated the need for such comparison.
A user should not have to take notes or transcribe displayed data manually. That practice underutilizes the data handling potential of the computer, and risks transcription errors by the user.
Framing refers to user control of data coverage by display movement, including paging, scrolling, offset, etc.
In designing displays, include all data relevant to a user's current transaction in one display frame or page.
This recommendation is particularly important when critical data items must be compared by a user. Do not rely on a user to remember data accurately from one display frame to another.
If a user requests a display output that exceeds the capacity of a single frame, than it is obviously not possible for any designer to ensure an integrated display. However a designer can mitigate the problems associated with use of extended displays, by providing effective means for identifying and controlling sequential access to different portions of the display.
2.0/1 | 2.5/5 | 2.5/7 | 4.0/5 | 4.4/1
When requested data exceed the capacity of a single display frame, give users some easy means to move back and forth over displayed material by paging or panning/scrolling.
Dedicated function keys might be provided for paging forward and back.
Note that critical data requiring integrated display for effective assimilation should be included in a single frame, and not dispersed over several pages. Paging is acceptable when the user is looking for a specific data item, but not when the user must discern some relationship in a set of data.
When a list of numbered items exceeds one display page, number the items continuously in relation to the first item on the first page.
For a large table that exceeds the capacity of one display frame, ensure that users can see column headings and row labels in all displayed sections of the table.
When lists or tables are of variable length, and may extend beyond the limits of one display frame, inform a user when data are continued on another page and when data are concluded on the present page.
Incomplete lists might be marked
| continued on next page| or
| continued | or
| more |
while concluding lists might display a note
| end of list | or
| end |
Short lists whose conclusion is evident from the display format need not be annotated in this way.
When display output is more than one page, annotate each page to indicate display continuation.
The phrase | page x of y | is commonly used for this purpose.
When a display extends over just a few pages, and when a user is not expected to care about any particular page, then it may be sufficient to identify the pages
| first |
| continued |
| last |
rather than assigning them numbers.
A recommended format is to identify pages by a note immediately to the right of the display title. With such a consistent location, the page note might be displayed in dimmer characters. Leading zeros should not be used in the display of page numbers.
If a large display output is viewed by continuous panning/scrolling rather than by discrete paging, then some other means must be found to label that portion of the display which is currently visible. Some sort of graphic indicator might be inset at the margin of the display frame to suggest current location.
Adopt a consistent orientation for display framing throughout interface design, so that users can either 1) conceive the display frame as a window moving over a fixed array of data, here called "panning", or 2) conceive data as moving behind a fixed display frame, commonly called "scrolling".
Ideally a consistent orientation for display framing would be maintained across all systems. Certainly that orientation should be consistent within any one system.
A user can adapt to either concept, if it is maintained consistently. Both concepts have some precedent in experience. Moving a camera across a fixed scene illustrates panning. Moving a specimen beneath the fixed eyepiece of a microscope illustrates scrolling. Tests seem to indicate that panning is the more natural concept for inexperienced users, causing fewer errors, and hence is the preferred option when other considerations are equal.
In applications where a user can move a cursor freely about a page of displayed data, adopt panning rather than scrolling as the conceptual basis of display framing.
Full-screen editing is a common application involving free cursor movement.
Since displayed data will be perceived as fixed during free cursor movement, considerations of joint compatibility suggest that displayed data remain conceptually fixed during movement of a display frame or window. Indeed, it might be possible to use the same arrow-labeled function keys to control both cursor movement and panning.
When a user will access different systems with different conventions for panning or scrolling, in user instructions, key labels, etc., always refer to display framing in functional terms (e.g., "forward" and "back", or "next" and "previous") and avoid wording that implies spatial orientation (e.g., "up" and "down").
Control of display framing functions might be implemented by keys marked with arrows, to avoid verbal labels altogether.
Note that "forward" and "back" are potentially ambiguous because of the contradictory use of those words in referring to movement within books.
When a panning orientation is maintained consistently, choose names for display framing functions that refer to movement of the display frame (or window) and not to movement of the displayed data.
In this case, the command "Up 10" should mean that the display frame will move up ten lines, with the effect that ten lines of previous data will appear at the top of the display, and ten lines of subsequent data will disappear at the bottom.
When a scrolling orientation is maintained consistently, choose names for display framing functions that refer to movement of the data being displayed, and not to movement of the display frame (or window).
In this case, the command "Up 10" should mean that displayed data will move up ten lines behind the (conceptually fixed) display frame, with the effect that ten lines of previous data will disappear from the top of the display, and ten lines of subsequent data will appear at the bottom.
When a display exceeds the capacity of a single frame, in terms of the required extent and detail of coverage, consider providing users a capability to pan the display frame over the data in order to examine different areas of current interest.
A panning capability, sometimes called display "offset", can allow a user to move continuously over an extended display in any desired direction, without encountering any internal boundaries imposed by predefined display framing. Panning control might be accomplished by some continuous-action device such as a joystick, perhaps "dragging" a displayed framing element and then requesting display regeneration. There is some risk that a user might become disoriented in this process.
An alternative approach is to define discrete pages or sections of a large display, assign those sections identifying labels, and allow a user to specify directly which section should be displayed. This approach requires the user to pay specific attention to the labeling of different sections, which extra effort may help maintain orientation to the display as a whole. One risk in this approach, for a continuous display such as a map, is that an area of interest might be at a boundary where none of the sections provide adequate coverage. Thus some degree of overlapped coverage might be needed at the boundaries of displayed sections.
For some applications, it might prove helpful to allow a user to specify a particular location (such as a point on a map) and then automatically offset the display frame to be centered around that location.
When a user may need to perceive displayed data relations more accurately, or to view data in pictures, diagrams, maps, etc. in greater detail, provide a zooming capability that allows the user to expand the display of any selected area.
Zooming can increase display spacing among crowded data items so that they can be perceived better. Thus an air traffic controller might expand a portion of a situation display to see more clearly the spacing of converging tracks that threaten a collision.
Zooming can increase the degree of detail, i.e., can add data to a display. Thus a user might expand a city map to see detailed road structures that are not shown in a small-scale map. When used this way, a zooming capability implies that data can be "layered" hierarchically at different levels of aggregation, which may require complex data files and data management techniques.
Zooming might be implemented as a continuous function, by which a display can be expanded to any degree, analogous to a continuous panning capability. Or zooming might be implemented in discrete increments, as in increasing the magnification of an optical instrument to x2, x4, etc. Incremental zooming, with abrupt changes in display scale, may tend to disorient a user, but might prove acceptable in some applications.
When a display has been expanded from its normal coverage, provide some scale indicator of the expansion factor.
A linear indicator of current map scale might be shown in the margin, or perhaps simply a numeric indication of the display expansion factor (e.g., | x4 |).
In many applications it may be helpful to show the scale even for a display with normal, unexpanded coverage.
When a display has been panned and/or expanded from its normal coverage, provide some graphic indicator of the position in the overall display of the currently visible section.
In a corner of the display frame the computer might show a rectangle representing the overall display, in which a smaller rectangle is placed to indicate the position and extent of the currently visible portion of that display.
A graphic indication of the current coverage of a panned or expanded display will provide some visual context to help a user maintain a conceptual orientation between the visible part and the whole display from which that part has been excerpted.
In some special applications it may be possible to provide a user with two separate display screens, one to show an overview for general reference, and the other to show an expanded portion of that overview display.
Ensure that framing functions perform integrally so that panning and/or zooming will affect all displayed data in the same way.
On a situation display, zooming should expand background data such as geographic boundaries to the same scale as the expansion of overlaid "active" data.
If a user is allowed to pan over an extended display, or zoom for display expansion, provide some easy means for the user to return to normal display coverage.
Return to normal display coverage might be accomplished by a function key labeled RETURN, or perhaps RESET.
A user who has panned to some special area in an extended display, or who has expanded a display to examine some particular section in detail, may suddenly need to return quickly to normal display coverage. Perhaps the user has received an alerting message requiring attention to another portion of the display. Quick return to normal coverage will allow the user to re-establish a familiar orientation to the display as a whole.
Here normal coverage might always be defined as that data coverage shown when a display was initially generated. Or it might be desirable in some instances to allow a user to specify what is to be considered normal coverage for any particular display.
Update refers to the regeneration of displayed data, by user request or automatically, to show current changes.
When displayed data are changing as a result of external events, a user should be able to request automatic update (computer regeneration) of changed data, and be able to control the update rate.
In an operations monitoring task, requirements may dictate the circumstances and rate of display updating.
When data have changed following automatic display update, consider highlighting those data changes temporarily.
A change in a critical data item might be highlighted with reverse video, or might be marked with a blinking symbol.
The desirable interval for highlighting changed data will depend on the importance of those data. If data changes imply a need for special user attention, then highlighting might continue until the user takes some specific acknowledgement action. Otherwise, highlighting might be removed after several seconds, or might continue until a user takes some other control action.
If users must accurately read changing data values, ensure that those data are displayed long enough to be read.
A current design standard specifies that for accurate reading, data should be displayed in a fixed position and updated no more than once per second. In some applications, however, a slower update rate may be required. When in doubt, test user performance with prototype displays to determine appropriate update rates.
If users need only to monitor general trends in changing data values, and do not need to take exact readings, somewhat faster update rates may be acceptable. Again, prototype testing will sometimes be needed to determine appropriate update rates.
If a user must visually integrate changing patterns on a graphic display, update the data at a rate appropriate to human perceptual abilities for that kind of data change.
Effective display of changing radar data for track detection and monitoring requires repeated, sequential output of stored data frames, and the timing of successive frames is critical for optimizing pattern perception.
Slowly developing patterns may be seen more easily with time compression, i.e., with rapid display of sequentially stored data frames. Fast changing data may require time expansion, i.e., slowed output, to aid pattern perception. For critical applications, experiment with prototype displays to determine proper timing.
In some applications it may help to allow a user to control the speed for update of displayed data.
In applications where the timing of display update is variable, it may help to indicate the currently selected time scale on the display.
Similar considerations apply to auditory displays, where speeding or slowing sound signals may aid pattern recognition.
When displayed data are automatically updated, allow users to stop the process (by "freeze" or "stop action") at any point, in order to examine changed data more deliberately.
For an operations monitoring task, requirements may dictate that current data changes be continuously viewed; in such a case, display freeze might be useful during some subsequent playback of recorded data for purposes of operational analysis.
For some applications, it might also prove helpful if a user could step incrementally forward or back in a time sequence, in order to examine data changes frame by frame.
When a display has been frozen, annotate that display with some appropriate label to remind users of its frozen status.
When a display being updated in real time has been frozen, warn users if some significant (but not displayed) change is detected in the computer processing of new data.
When a display being updated in real time has been frozen, and then a user elects to resume update, resume display update at the current real-time point unless otherwise specified by the user.
In some applications, a user might wish to resume display update at the point of stoppage, and so display change would thenceforth lag real-time data change. Or perhaps a user might choose to see a speeded "replay" of interim changes to regain current display status. In practice, however, such options might risk confusion.
To help a user understand and respond effectively to complex data changes, consider displaying a prediction of future data states based on computer analysis of an appropriate model of the data dynamics.
Prediction display might be used to aid the control of any rapidly changing process involving complex dynamics, such as depth control for a high-performance submarine.
The concept of prediction display extends the practice of dynamic display update, from simply showing recent and current data states, to anticipate future changes in data. In effect, a computer can iterate in "fast time" changes in a dynamic data model, and then display its current prediction of future real-time changes. The usefulness of such prediction will depend upon the accuracy of the underlying data model. As it happens, where prediction display can help users, as in complex vehicular control or process control applications, the dynamics of process change are often defined sufficiently well to permit valid computer modeling.
A consistent logic should be adopted for computer modeling and prediction in relation to possible user action. For dynamic control applications, one feasible logic is for a computer to predict and display the future consequences if the user persists in the current control action. As an alternative, a computer might predict and display the consequences if the user were to cease any control action. Either logic could prove helpful. But whichever is adopted should be used consistently.
Prediction displays should be formatted to distinguish clearly between actual current data and extrapolated future data.
Suppression refers to user control of display coverage by temporary deletion of specified data categories.
When standard data displays are used for special purposes, allow users to temporarily suppress the display of data not needed for the current task.
Data selections made originally for one purpose may not be appropriate for another. When task requirements shift rapidly, it may be more efficient to suppress temporarily the display of unneeded data categories, rather than to regenerate a display with different selection criteria.
When data have been suppressed from a display, annotate the display with some appropriate label to remind users that data have been suppressed.
When data have been suppressed from a display, warn users if some significant (but not displayed) change is detected in the computer processing of new data.
When data have been suppressed from a display, provide users with some means to quickly restore the display to its complete, originally generated form.
If a function key is used to restore suppressed data, that key action should have no other consequences. For instance, if a user must press RETURN to restore suppressed data, that key should only restore data and should not also move a displayed cursor to some other position.
In some applications, it may be desirable to restore suppressed data automatically, after expiration of a predetermined time-out, rather than relying on a user to remember to do it.
Window overlays can be temporarily added to a display to show requested data, menus, user guidance, etc.
When it is necessary to add requested data or other features temporarily to a current display, consider providing window overlays for that purpose.
On a map display, if a user requests detailed data about a particular location, the computer might display an overlaid window with tabular or textual description, which could later be removed by user action.
Here temporary window overlays should be distinguished from the more stable "windows" consistently provided in display formatting, such as the various defined display areas that might be dedicated to showing the display title, a date-time group, user prompting, a composed control entry, an error message, etc.
Window overlays can be used to show data of temporary or extraneous interest. By contrast, if a set of data must be viewed continuously or in an integrated display with other data, then that data set should be available as a selectable data category.
When the value of particular window overlays can be determined during interface design, those overlays should be predefined and offered to users under computer control.
A menu of currently appropriate control options might be superimposed on a current display by user selection of the displayed menu title.
The aim here is to allow a user to select window overlays that have already been designed, rather than having to specify a desired window from scratch. User display control should be kept as simple as possible, so that a user can spend time assimilating data instead of manipulating the display of data.
When the need to view several different kinds of data jointly cannot be determined in advance, allow a user to specify and select separate data windows that will share a single display frame.
Users may abuse such a capability for arbitrary window definition, adding so many windows to a display that the resulting hodgepodge defies interpretation. A designer can do little to prevent that. However, the designer can try to ensure that the means for window creation and control are made as efficient as possible.
Depending upon user needs (and system capability), data windows might appear simultaneously as segments of a joint display, might be overlaid in varying degrees so as to obscure one another, or might be displayed sequentially at the user's option. In the latter condition, multiple display windows will differ little from multiple display pages, except perhaps in speed of sequential access.
This recommendation assumes that it is mostly data overlays which a user will want to create. Other kinds of window overlays would usually be offered under computer control, such as those providing error messages and other forms of user guidance. It is possible, however, that a user might wish to define certain kinds of non-data windows, such as an overlay of "favorite" menu options, or an overlaid guidance "memo" composed for the user's own purposes. Perhaps a user should be allowed to create those kinds of window overlays as well.
Ensure that the means provided users to control window overlays operate consistently from one display to another for each type of overlay.
Control of predefined windows may simply involve "opening" and "closing" them, by selection of displayed option labels or function keys. Control of user-defined windows may require user specification of window contents, window size and positioning on the display. Such window control must be learned by a user, and consistent design of control logic will aid that learning.
Some advocates of window overlays predict that standard methods of window control will become part of the basic support software for user interface design.
Provide an easy means for a user to suppress the display of window overlays.
A requested guidance overlay might be removed by user selection of a RETURN function key; a menu overlay displayed under computer control might disappear automatically following user selection of an option from that menu.
When a user can select predefined window overlays, assign to each overlay an identifying label.
Labeling window overlays may help users request and recognize them, in the same way that display labeling can aid display selection.
If several window overlays are displayed at once, indicate to the user in which window (if any) an action can currently be taken.
A prominent cursor might be displayed in the currently active window, or perhaps the displayed border of an active window might be highlighted in some way.
Adding window overlays to a display can increase the conceptual complexity of control actions as well as the difficulty of data assimilation. Consider a case in which several windows are shown, including some menu overlays and some data windows. There it is important to indicate to a user which window is currently "active", i.e., whether the next action will result in a menu selection or a data change.
If several window overlays are displayed at once, provide some easy means for a user to shift among them to select which window shall be currently active.
The most direct method might be to allow a user to select a window by pointing anywhere within its displayed borders, but that action might be confused with the selection of a particular item within the window. Some designers provide a special symbol for window selection in the border itself.
When control actions such as command entry may be taken by a user working within a window overlay, ensure that those control actions will be consistent from one window to another.
Cursor positioning controls and data editing capabilities should operate consistently within all windows.
If controls in one window operate differently than in another, user confusion will be unavoidable.
When a window overlay temporarily obscures other displayed data, ensure that the obscured data are not permanently erased but will reappear if the overlay is later removed.
Design change of software supporting data display functions may be needed to meet changing operational requirements.
When data display requirements may change, which is often the case, provide some means for users (or a system administrator) to make necessary changes to display functions.
Display characteristics that may need to be changed include those represented in these guidelines, namely, the types of data that can be displayed, formatting and coding logic, and the capabilities offered for display control.
Many of the preceding guidelines in this section imply a need for design flexibility. Much of that needed flexibility can be provided in initial interface design. Some guidelines, however, suggest a possible need for subsequent design change, and those guidelines are cited below.
2.0/2 | 2.0/8 | 2.0/11 | 2.5/8 | 2.7.1/1 | 2.7.1/3
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents | | | Top |