Exhibit 1014 – Part 2
`
`Exhibit 1014 — Part 2
`
`

`
`2.4 Principles: Recognize the Diversity
`
`67
`
`coming these limitations is a serious challenge to the designer. Restricting
`vocabulary to a small number of familiar, consistently used terms is
`essential to begin developing the user's knowledge of the system. The
`number of possibilities should be kept small, and the novice user should
`be able to carry out a few simple tasks to build confidence, to reduce
`anxiety, and to gain positive reinforcement from success. Informative
`feedback about the accomplishment of each task is helpful, and construc-
`tive, specific error messages should be provided when errors do occur.
`Carefully designed paper manuals and step-by—step online tutorials may
`be effective. Users are attempting to relate their existing knowledge to the
`task objects and actions in the application, so distractions with computer
`concepts and the syntax are an extra burden.
`Knowledgeable intermittent users: Many people will be knowledgeable but
`intermittent users of a variety of systems. They will be able to maintain
`the semantic knowledge of the task and the computer concepts, but they
`will have difficulty maintaining the syntactic knowledge. The burden of
`memory will be lightened by simple and consistent structure in the
`command language, menus, terminology, and so on, and by use of
`recognition rather than recall. Consistent sequences of actions, meaning-
`ful messages, and frequent prompts will all help to assure knowledgeable
`intermittent users that they are performing their tasks properly. Protec-
`tion from danger is necessary to support relaxed exploration of features or
`attempts to invoke a partially forgotten command. These users will
`benefit from online help screens to fill in missing pieces of syntactic or
`computer semantic knowledge. Well-organized reference manuals will
`also be useful.
`
`Expert frequent users: The expert ”power" users are thoroughly familiar
`with the syntactic and semantic aspects of the system and seek to get their
`work done rapidly. They demand rapid response times, brief and less
`distracting feedback, and the capacity to carry out actions with just a few
`keystrokes or selections. When a sequence of three or four commands is
`performed regularly, the frequent user is eager to create a macro or other
`abbreviated form to reduce the number of steps. Strings of commands,
`shortcuts through menus, abbreviations, and other accelerators are re-
`quirements.
`
`These characteristics of these three classes of usage must be refined for each
`environment. Designing for one class is easy; designing for several is much
`more difficult.
`
`When multiple usage classes must be accommodated in one system, the
`basic strategy is to permit a level-structured (some times called layered or spiral
`approach) to learning. Novices can be taught a minimal subset of objects and
`actions with which to get started. After gaining confidence from hands—on
`
`

`
`Chapter 2
`
`Theories, Principles, and Guidelines
`
`experience, the users can progress to ever greater levels of semantic concepts
`and the accompanying syntax. The learning plan should be governed by the
`progress through the task semantics. For users with strong knowledge of the
`task and computer semantics, rapid presentation of syntactic details is
`possible.
`For example, novice users of a bibliographic-search system might be
`taught author or title searches first, followed by subject searches that require
`Boolean combinations of queries. The progress is governed by the task
`domain, not by an alphabetical list of commands that are difficult to relate to
`the tasks. The level-structured approach must be carried out in the design of
`not only the software, but also the user manuals, help screens, error
`messages, and tutorials.
`Another approach to accommodating different usage classes is to permit
`user control of the density of informative feedback that the system provides.
`Novices want more informative feedback to confirm their actions, whereas
`frequent users want less distracting feedback. Similarly,
`it seems that
`frequent users like displays to be more densely packed than do novices.
`Finally, the pace of interaction may be varied from slow for novices to fast
`for frequent users.
`
`2.4.2 Task profiles
`
`After carefully drawing the user profile, the developers must identify the
`tasks. Task analysis has a long, but mixed, history (Bailey, 1989). Every
`designer would agree that the set of tasks must be determined before design
`can proceed, but too often the task analysis is done informally or implicitly.
`If implementers find that another command can be added, the designer is
`often tempted to include the command in the hope that some users will find
`it helpful. Design or implementation convenience should not dictate system
`functionality or command features.
`High-level task actions can be decomposed into multiple middle—level
`task actions that can be further refined into atomic actions that the user
`
`executes with a single command, menu selection, and so on. Choosing the
`most appropriate set of atomic actions is a difficult task. If the atomic actions
`are too small, the users will become frustrated by the large number of actions
`necessary to accomplish a higher-level task. If the atomic actions are too
`large and elaborate, the users will need many such actions with special
`options, or they will not be able to get exactly what they want from the
`system.
`
`The relative task frequencies will be important in shaping, for example, a
`set of commands or a menu tree. Frequently performed tasks should be
`simple and quick to carry out, even at the expense of lengthening some
`
`

`
`2.4 Principles: Recognize the Diversity
`
`69
`
`infrequent tasks. Relative frequency of use is one of the bases for making
`architectural design decisions. For example, in a text editor,
`
`- Frequent actions might be performed by special keys, such as the four
`cursor arrows, INSERT, and DELETE.
`
`- lntermediately frequent actions might be performed by a single letter
`plus CTRL, or by a selection from a pull-down menu-examples
`include underscore, center, indent, subscript, or superscript.
`
`0 Less frequent actions might require going to a command mode and
`typing the command name-—for example, MOVE BLOCK or SP ELLING
`CHECK.
`
`- Infrequent actions or complex actions might require going through a
`sequence of menu selections or form fillins—for example, to change the
`printing format or to revise network protocol parameters.
`
`A matrix of users and tasks can help us to sort out these issues (Figure
`2.3). In each box, the designer can put a check mark to indicate that this user
`carries out this task. A more precise analysis would lead to inclusion of
`frequencies, instead of simple check marks.
`
`2.4.3
`
`Interaction styles
`
`When the task analysis is complete and the semantics of the task objects
`and actions can be identified, the designer can choose from these pri-
`mary interaction styles: menu selection, form fillin, command language,
`natural language, direct manipulation (Table 2.1). Chapters 3 through 5
`
`Frequency of Task by ]ob Title
`
`Query by
`patient
`0.14
`0.06
`0.01
`0.26
`0.07
`
`.
`
`Iob title
`Nurses
`Physicians
`Supervisors
`Appointments personnel
`Medical—record maintainers
`Clinical researchers
`Database programmers
`
`Figure 2.3
`
`Query
`across
`patients
`
`Add
`relations
`
`Evaluate
`system
`
`0.04
`
`004
`0.08
`0.02
`
`Hypothetical frequency—of-use data for a medical clinic information system. Queries by
`patient from appointments personnel are the highest-frequency task.
`
`

`
`Chapter 2
`
`Theories, Principles, and Guidelines
`
`Table 2.1
`
`Advantages and disadvantages of the five primary interaction styles.
`
`Interaction Style
`Disadvantages
`
`Advantages
`menu selection
`shortens learning
`reduces keystrokes
`structures decision making
`permits use of dialog-management
`tools
`allows easy support of error handling
`form fillin
`
`simplifies data entry
`requires modest training
`makes assistance convenient
`
`permits use of form-management tools
`command language
`is flexible
`
`appeals to ”power” users
`supports user initiative
`is convenient for creating user—defined
`macros
`
`natural language
`relieves burden of learning syntax
`
`direct manipulation
`presents task concepts visually
`is easy to learn
`is easy to retain
`allows errors to be avoided
`encourages exploration
`permits high subjective satisfaction
`
`imposesdanger of many menus
`may slow frequent users
`consumes screen space
`requires rapid display rate
`
`COI‘l5l.lI‘l'l€S SCFEEI1 SPEICC
`
`has poor error handling
`requires substantial training and
`memorization
`
`requires clarification dialog
`may require more keystrokes
`may not show context
`is unpredictable
`
`may be hard to program
`may require graphics display and
`pointing devices
`
`explore these styles in detail; here, we give a comparative overview to
`set the stage.
`
`Menu selection In menu-selection systems, the users read a list of items,
`select the one most appropriate to their task, apply the syntax to indicate
`their selection, confirm the choice, initiate the action, and observe the effect.
`If the terminology and meaning of the items are understandable and distinct,
`then the users can accomplish their task with little learning or memorization
`
`

`
`2.4 Principles: Recognize the Diversity
`
`and few keystrokes. The greatest benefit may be that there is a clear structure
`to decision making, since only a few choices are presented at a time. This
`interaction style is appropriate for novice and intermittent users and can be
`appealing to frequent users if the display and selection mechanisms are
`rapid.
`For designers, menu—selection systems require careful task analysis to
`ensure that all functions are supported conveniently and that terminology is
`chosen carefully and used consistently. Dialog-management tools to support
`menu selection are an enormous benefit
`in ensuring consistent screen
`design, Validating completeness, and supporting maintenance.
`
`Form fillin When data entry is required, menu selection usually becomes
`cumbersome, and form fillin (also called fiIl—inethe—blanks) is appropriate.
`Users see a display of related fields, move a cursor among the fields, and
`enter data where desired. With the form fillin interaction style, the users
`must understand the field labels, know the permissible Values and the data-
`entry method, and be capable of responding to error messages. Since
`knowledge of the keyboard, labels, and permissible fields is required, some
`training may be necessary. This interaction style is most appropriate for
`knowledgeable intermittent users or frequent users. Chapter 3 provides a
`thorough treatment of menus and form fillin.
`
`Command language For frequent users, command languages provide a
`strong feeling of locus of control and initiative. The users learn the syntax
`and can often express complex possibilities rapidly, without having to
`read distracting prompts. However, error rates are typically high, training
`is necessary, and retention may be poor. Error messages and online
`assistance are hard to provide because of the diversity of possibilities plus
`the complexity of mapping from tasks to computer concepts and syntax.
`Command languages and lengthier query or programming languages are
`the domain of
`the expert
`frequent users who often derive great
`satisfaction from mastering a complex set of semantics and syntax.
`Chapter 4 covers command languages and natural language interaction in
`depth.
`
`Natural language The hope that computers will respond properly to
`arbitrary natural-language sentences or phrases engages many researchers
`and system developers, in spite of limited success thus far. Natural-language
`interaction usually provides little context for issuing the next command,
`frequently requires clarification dialog, and may be slower and more
`cumbersome than the alternatives. Still, where users are knowledgeable
`about a task domain whose scope is limited and where intermittent use
`
`

`
`Chapter 2
`
`Theories, Principles, and Guidelines
`
`inhibits command-language training, there exist opportunities for natural-
`language interfaces (discussed at the end of Chapter 4).
`
`Direct manipulation When a clever designer can create a visual rep-
`resentation of the world of action, the users’ tasks can be greatly simplified
`because direct manipulation of the objects of interest is possible. Examples of
`such systems include display editors, LOTUS 1-2-3, air-traffic control
`systems, and video games. By pointing at visual representations of objects
`and actions, users can carry out tasks rapidly and observe the results
`immediately. Keyboard entry of commands or menu choices is replaced by
`cursor-motion devices to select from a visible set of objects and actions.
`Direct manipulation is appealing to novices,
`is easy to remember for
`intermittent users, and, with careful design, can be rapid for frequent users.
`Chapter 5 describes direct manipulation and its applications.
`Blending several interaction styles may be appropriate when the required
`tasks and users are diverse. Commands may lead the user to a form fillin
`where data entry is required or menus may be used to control a direct-
`manipulation environment when a suitable visualization of actions cannot
`be found.
`
`2.5 Eight Golden Rules of Dialog’Design
`
`Later chapters cover constructive guidance for design of menu selection,
`command languages, and so on. This section presents underlying principles
`of design that are applicable in most interactive systems. These underlying
`principles of interface design, derived heuristically from experience, should
`be validated and refined:
`
`1. Strive for consistency. This principle is the most frequently violated one,
`but the benefits of adherence are large. Consistent sequences of actions
`should be required in similar situations; identical terminology should be
`used in prompts, menus, and help screens; and consistent commands
`should be employed throughout. Exceptions, such as no echoing of
`passwords or confirmation of the DELETE command, should be compre-
`hensible and limited in number.
`
`. Enable frequent users to use shortcuts. As the frequency of use increases, so
`do the user's desires to reduce the number of interactions and to increase
`
`the pace of interaction. Abbreviations, special keys, hidden commands,
`and macro facilities are appreciated by frequent knowledgeable users.
`Shorter response times and faster display rates are other attractions for
`frequent users.
`
`

`
`2.5 Eight Golden Rules of Dialog Design
`
`73
`
`. Offer informative feedback. For every operator action, there should be some
`system feedback. For frequent and minor actions, the response can be
`modest, whereas for infrequent and major actions, the response should be
`more substantial. Visual presentation of the objects of interest provides a
`convenient environment for showing changes explicitly (see discussion of
`direct manipulation in Chapter 5).
`
`. Design dialogs to yield closure. Sequences of actions should be organized
`into groups with a beginning, middle, and end. The informative feedback
`at the completion of a group of actions gives the operators the satisfaction
`of accomplishment, a sense of relief, the signal to drop contingency plans
`and options from their minds, and an indication that the way is clear to
`prepare for the next group of actions.
`. Offer simple error handling. As much as possible, design the system so the
`user cannot make a serious error. If an error is made, the system should
`detect the error and offer simple, comprehensible mechanisms for han-
`dling the error. The user should not have to retype the entire command,
`but rather should need to repair only the faulty part. Erroneous com-
`mands should leave the system state unchanged, or the system should
`give instructions about restoring the state.
`. Permit easy reversal of actions. As much as possible, actions should be
`reversible. This feature relieves anxiety, since the user knows that errors
`can be undone; it thus encourages exploration of unfamiliar options. The
`units of reversibility may be a single action, a data entry, or a complete
`group of actions.
`. Support internal locus of control. Experienced operators strongly desire the
`sense that they are in charge of the system and that the system responds
`to their actions. Surprising system actions, tedious sequences of data
`entries, incapacity or difficulty in obtaining necessary information, and
`the inability to produce the action desired all build anxiety and dissatis-
`faction. Gaines (1981) captured part of this principle with his rule avoid
`acausality and his encouragement to make users the initiators of actions
`rather than the responders.
`. Reduce short—term memory load. The limitation of human information
`processing in short—term memory (the rule of thumb is that humans can
`remember "seven plus or minus two chunks" of information) requires
`that displays be kept simple, multiple page displays be consolidated,
`window-motion frequency be reduced, and sufficient training time be
`allotted for codes, mnemonics, and sequences of actions. Where appropri-
`ate, online access to command-syntax forms, abbreviations, codes, and
`other information should be provided.
`
`These underlying principles must be interpreted, refined, and extended
`for each environment. The principles presented in the ensuing sections focus
`
`

`
`Chapter 2
`
`Theories, Principles, and Guidelines
`
`on increasing the productivity of users by providing simplified data-entry
`procedures, comprehensible displays, and rapid informative feedback that
`increase feelings of competence, mastery, and control over the system.
`
`___:_
`
`2.6 Preventing Errors
`
`There is no medicine against death, and against error no rule has been found.
`Sigmund Freud, (Inscription he wrote on his portrait)
`
`Users of word processors, spreadsheets, database-query facilities, air-traffic
`control systems, and other interactive systems make mistakes far more
`frequently than might be expected. Card et al. (1980) reported that experi-
`enced professional users of text editors and operating systems made mis-
`takes or used inefficient strategies in 31 percent of the tasks assigned to
`them. Brown and Gould (1987) found that even experienced authors had
`some errors in almost half their spreadsheets. Other studies are beginning to
`reveal the magnitude of the problem and the loss of productivity due to user
`errors.
`
`One direction for reducing the loss in productivity due to errors is to
`improve the error messages provided by the computer system. Shneiderman
`(1982) reported on five experiments in which changes to error messages led
`to improved success at repairing the errors, lower error rates, and increased
`subjective satisfaction. Superior error messages were more specific, positive
`in tone, and constructive (telling the user what to do, rather than merely
`reporting the problem). Rather than using vague and hostile messages, such
`as SYNTAX ERROR or ILLEGAL DATA, designers were encouraged to use
`informative messages, such as UNMATCHED LEFT PARENTHESIS or MENU
`CHOICES ARE IN THE RANGE OF 1 TO 6.
`Improved error messages, however, are only helpful medicine. A more
`effective approach is to prevent the errors from occurring. This goal is more
`attainable than it may seem in many systems.
`The first step is to understand the nature of errors. One perspective is that
`people make mistakes or ”slips” (Norman, 1983) that designers can avoid by
`organizing screens and menus functionally, designing commands or menu
`choices to be distinctive, and making it difficult for users to do irreversible
`actions. Norman offers other guidelines such as do not have modes, offer
`feedback about the state of the system, and design for consistency of
`commands. Norman's analysis provides practical examples and a useful
`theory.
`
`

`
`2.6 Preventing Errors
`
`2.6.1 Techniques for ensuring correct actions
`
`The ensuing sections refine his analysis and describe three specific tech-
`niques for reducing errors by ensuring complete and correct actions: correct
`matching pairs, complete sequences, and correct commands.
`
`Correct matching pairs A common problem is the lack of correct matching
`pairs. It has many manifestations, and several simple prevention strategies.
`An example is the failure to provide the right parenthesis to close an open
`left parenthesis. If a bibliographic-search system allowed Boolean expres-
`SiOI1S such as COMPUTERS AND (PSYCHOLOGY OR SOCIOLOGY) and the
`user failed to provide the right parenthesis at the end, the system would
`produce a SYNTAX ERROR message or, even better, a more meaningful
`message, such as UNMATCHED LEFT PARENTHESES.
`Another error is failure to include the closing quotation mark (”) to close
`a string in BASIC. The command 1 0 PRINT “HELLO” is in error if the
`rightmost quotation mark is missing.
`Similarly, a @B or other marker is required to indicate the end of boldface,
`italic, or underscored text in word processors. If the text file contains
`@BThis
`i s boldface@B, then the three words between the @B markers
`appear in boldface on the printer. If the rightmost @B is missing, then the
`remainder of the file is printed in boldface.
`A final example is omitting termination of a centering command in a text
`formatter. Some text formatters have a pair of commands—such as . ON
`CENTER and . OFF CENTER—-surrounding lines of text to be centered. The
`omission of the latter command causes the entire file to be centered.
`
`In each of these cases, a matching pair of markers is necessary for
`operation to be complete and correct. The omission of the closing marker can
`be prevented by use of an editor, preferably screen-oriented, that puts both
`the beginning and ending components of the pair on the screen in one action.
`For example, typing a left parenthesis generates a left and right parenthesis
`and puts the cursor in between to allow creation of the contents. An attempt
`to delete one of the parentheses will cause the matching parenthesis (and
`possibly the contents as well) to be deleted. Thus, the text can never be in a
`syntactically incorrect form.
`Some people find this rigid approach to be too restrictive and may prefer
`a milder form of protection. When the user types a left parenthesis, the
`screen displays in the lower-left corner a message indicating the need for a
`right parenthesis, until that character is typed.
`Another approach is to replace the requirement for the ending marker.
`Many microcomputer versions of BASIC do not require an ending quotation
`mark to terminate a string; they use a carriage return to signal the closing of
`a string. Variants of this theme occur in line-oriented text editors that allow
`omission of the final / in a CHANGE/OLD STRING/NEW sTRING/ com-
`
`

`
`Chapter 2
`
`Theories, Principles, and Guidelines
`
`mand. Many versions of LISP offer a special character, usually a right square
`bracket (] ), to terminate all open parentheses.
`In each of these cases,
`the designers have recognized a frequently
`occurring error and have found a way to eliminate the error situation.
`
`Complete sequences Sometimes, an action requires several steps or
`commands to reach completion. Since people may forget to complete every
`step of an action, designers attempt to offer a sequence of steps as a single
`action. In an automobile, the driver does not have to set two switches to
`signal a left turn. A single switch causes both turn-signal lights (front and
`rear) on the left side of the car to flash. When a pilot lowers the landing gear,
`hundreds of steps and checks are invoked automatically.
`This same concept can be applied to interactive uses of computers. For
`example, the sequence of dialing up, setting communication parameters,
`logging on, and loading files is frequently executed by many users. Fortu~
`nately, most communications-software packages enable users to specify
`these processes once, and then to execute them by simply selecting the
`appropriate name.
`Programming—language loop constructs require a WHILE—DO—BE‘.GIN—
`END or FoR—NEXT structure, but sometimes users forget to put the complete
`structure in, or they delete one component but not the other components.
`One solution would be for users to indicate that they want a loop, and for the
`system to supply the complete and correct syntax, which would be filled in
`by the user. This approach reduces typing and the possibility of making a
`typographical error or a slip, such as the omission of one component.
`Conditional constructs require an IF—THEN—ELsE or CASI-:—OF—END struc-
`ture; but again, users may forget a component when creating or deleting.
`Users of a text editor should be able to indicate that section titles are to be
`
`centered, set in upper-case letters, and underlined, without having to issue a
`series of commands each time they enter a section title. Then, if a change is
`made in style-—for example, to eliminate underlining—a single command
`would guarantee that all section titles were revised consistently.
`As a final example, air traffic controllers may formulate plans to change
`the altitude of a plane from 14,000 feet to 18,000 feet in two steps; after
`raising the plane to 16,000 feet, however, the controller may get distracted
`and fail to complete the action. The controller should be able to record the
`plan and then have the computer prompt for completion.
`The notion of complete sequences of actions may be difficult to imple-
`ment, because users may need to issue atomic actions as well as complete
`sequences. In this case, users should be allowed to define sequences of their
`own—the macro or subroutine concept should be available at every level of
`usage.
`
`

`
`2.6 Preventing Errors
`
`77
`
`Designers can gather information about potential complete sequences by
`studying sequences of commands actually issued and the pattern of errors
`that people actually make.
`
`Industrial designers recognize that successful products
`Correct commands
`must be safe and must prevent the user from making incorrect use of the
`product. Airplane engines cannot be put into reverse until the landing gear
`have touched down, and cars cannot be put into reverse while traveling
`forward at faster than 5 miles per hour. Many simpler cameras prevent
`double exposures (even though the photographer may want to expose a
`frame twice), and appliances have interlocks to prevent tampering while the
`power is on (even though expert users occasionally need to perform
`diagnoses).
`The same principles can be applied to interactive systems. Consider these
`typical errors made by the users of computer systems: They invoke corn-
`mands that are not available, type menu selection choices that are not
`permitted, request files that do not exist, or enter data values that are not
`acceptable. These errors are often caused by annoying typographic errors,
`such as using an incorrect command abbreviation; pressing a pair of keys,
`rather than a desired single key; misspelling a file name; or making a minor
`error such as omitting, inserting, or transposing characters. Error messages
`range from the annoyingly brief ? or WHAT ?, to the vague UNRECOGNI ZED
`COMMAND or SYNTAX ERROR,
`to the condemning BAD FILE NAME or
`ILLEGAL COMMAND. The brief ? is suitable for expert users who have made
`a trivial error and can recognize it when they see the command line on the
`screen. But if an expert has ventured to use a new command and has
`misunderstood its operation, then the brief message is not helpful.
`Whoever made the mistake and whatever were its causes, users must
`
`interrupt their planning to deal with correcting the problem—-and with their
`frustration in not getting what they wanted. As long as a command must be
`made up of a series of keystrokes on a keyboard, there is a substantial chance
`of making an error in entering the sequence of keypresses. Some keypressing
`sequences are more error-prone than others—-especially those that require
`shifting or unfamiliar patterns. Reducing the number of keypresses can help,
`but it may place a. greater burden on learning and memory, since an entry
`with reduced keystrokes; for example, RM may be more difficult to remem-
`ber than the full command name, REMOVE (see Chapter 4).
`Some systems offer automatic command completion that allows the user
`to type just a few letters of a meaningful command. The user may request
`the computer to complete the command by pressing the space bar, or the
`computer may complete it as soon as the input is sufficient to distinguish the
`command from others. Automatic command completion can save key-
`
`

`
`Chapter 2
`
`Theories, Principles, and Guidelines
`
`strokes and is appreciated by many users, but it can also be disruptive
`because the user must consider how many characters to type for each
`command, and must verify that the computer has made the completion that
`was intended.
`Another approach is to have the computer offer the permissible com-
`mands, menu choices, or file names on the screen, and to let the user select
`with a pointing device. This approach is effective if the screen has ample
`space, the display rate is rapid, and the pointing device is fast and accurate.
`When the list grows too long to fit on the available screen space, some
`approach to hierarchical decomposition must be used.
`Imagine that the 20 commands of an operating system were constantly dis-
`played on the screen. After users select the PRINT command (or icon), the sys-
`tem automatically offers the list of 30 files for selection. Users can make two
`lightpen, touchscreen, or mouse selections in less time and with higher accu-
`racy than they could by typing the command PRINT JAN—JUNE-EXPENSE S.
`In principle, a programmer needs to type a variable name only once. After
`it has been typed, the programmer can select it, thus eliminating the chance
`of a misspelling and an UNDECLARED VARIABLE message.
`It is not always easy to convert a complex command into a small number
`of selections and thus to reduce errors. Pointing at long lists can be visually
`demanding and annoying if users are competent typists.
`
`__
`
`2.7 Guidelines: Data Display
`
`Guidelines for display of data are being developed by many organizations.
`A guidelines document can help by promoting consistency among multiple
`designers, recording practical experience, incorporating the results of em-
`pirical studies, and offering useful rules of thumb (see Chapters 8 and 13).
`The creation of a guidelines document engages the design community in a
`lively discussion of input or output formats, command sequences, terminol-
`ogy, and hardware devices (Rubinstein and Hersh, 1984; Brown, 1988;
`Galitz, 1989). Inspirations for design guidelines can also be taken from
`graphics designers (Tufte, 1983, 1990).
`
`2.7.1 Organizing the display
`Smith and Mosier (1986) offer five high—level objectives for data display:
`1. Consistency of data display: This principle is frequently violated, but
`violations are easy to repair. During the design process, the terminology,
`
`

`
`2.7 Guidelines: Data Display
`
`79
`
`abbreviations, formats, and so on should all be standardized and con-
`trolled by use of a written (or computer-managed) dictionary of these
`items.
`
`. Efficient information assimilation by the user: The format should be familiar
`to the operator, and should be related to the tasks required to be
`performed with these data. This objective is served by rules for neat
`columns of data, left justificationifor alphanumeric data, right justification
`of integers, lining up of decimal points, proper spacing, use of compre-
`hensible labels, and appropriate use of coded values.
`
`. Minimal memory load on user: Users should not be required to remember
`information from one screen for use on another screen. Tasks should be
`
`arranged such that completion occurs with few commands, minimizing
`the chance of forgetting to perform a step. Labels and common formats
`should be provided for novice or intermittent users.
`
`. Compatibility of data display with data entry: The format of displayed
`information should be linked clearly to the format of we data entry.
`
`. Flexibility for user control of data display: Users should be able to get the
`information from the display in the form most Convenient for the task on
`which they are working.
`
`This compact set of high-level objectives is a useful starting point, but
`each project needs to expand these into application—specific and hardware-
`dependent standards and practices. For example, these detailed comments
`for control—room design come from a report from the Electric Power
`Research Institute (Lockheed, 1981):
`
`- Be consistent in labeling and graphic conventions.
`- Standardize abbreviations.
`
`- Use consistent format in all displays (headers, footers, paging, menus,
`and so on).
`
`- Present a page number on each display page, and allow actions to call
`up a page via entry of a page number.
`- Present data only if they assist the operator.
`- Present information g