|
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 |
User guidance refers to error messages, alarms, prompts, and labels, as well as to more formal instructional material provided to help guide a user's interaction with a computer. The fundamental objectives of user guidance are to promote efficient system use (i.e., quick and accurate use of full capabilities), with minimal memory load on the user and hence minimal time required to learn system use, and with flexibility for supporting users of different skill levels.
User guidance should be regarded as a pervasive and integral part of interface design that contributes significantly to effective system operation. User guidance cannot be merely a decoration added at the end, like frosting on a cake. A study by Magers (1983) has demonstrated convincingly that good user guidance can result in faster task performance, fewer errors, greater user satisfaction, and will permit accomplishment of information handling tasks otherwise impossible for novice users.
A narrow view of user guidance deals with preventing and correcting user errors. But minimizing user errors may require improvements in broad aspects of interface design -- in techniques for data display, in procedures for data entry and sequence control -- as well as provision of user guidance. Moreover, any general consideration of user guidance functions must include provision of status information, job aids, and routine feedback, as well as feedback for error correction.
Many user interface design features contribute directly or indirectly to guide a user's interaction with an on-line computer system. The primary principle governing this aspect of interface design is to maintain consistency. With consistent interface design, users can learn to apply computer tools more quickly, more accurately, and with more confidence.
Design consistency implies predictability of system response to user inputs. A fundamental principle is that some response be received. For every action (input) by the user there should be a noticeable reaction (output) from the computer. It is this feedback linking action to reaction that defines each discrete transaction and maintains user orientation in interaction with the system.
The importance of feedback information for guiding the user has been emphasized by Engel and Granda (1975, page 13) in their recommendations for user interface design: Feedback to user action covers keeping the user informed of where he is, what he has done, and whether it was successful. . . . In an interactive computing situation, immediate feedback by the system is important in establishing the user's confidence and satisfaction with the system. One of the more frustrating aspects of any interactive system is sitting at the terminal after entering something and waiting for a response. Questions arise such as, 'Is the system still going?', 'Is the terminal still connected to the system?', 'Did the computer lose my input?', 'Is the system in a loop?'. A message that indicates that the system is still working on the problem or a signal that appears while the system is processing the user's input provides the user with the necessary assurance that everything is all right.
Predictability of computer response is related to system response time. Timely response can be critical in maintaining user orientation to the task. If a response is received only after a long delay, the user's attention may have wandered. Indeed, the user may forget just which action the machine is responding to. Frequent user actions, generally those involving simple inputs such as function key or menu selections, should be acknowledged immediately. In transactions where output must be deferred pending the results of computer search and/or calculation, the expected delay should be indicated to the user in a quick interim message.
Some experts argue that consistency of system response time may be more important in preserving user orientation than the absolute value of the delay, even suggesting that designers should delay fast responses deliberately in order to make them more consistent with occasional slow responses. Perhaps such a reduction in response time variability may be desirable. If system response time is always slow, a user can adapt to the situation and find something else useful to do while waiting. But surely a better solution is to make all responses uniformly fast, or, where that is not possible, to provide a quick interim message to warn the user that a response will be delayed, as suggested above. In that way, a slow response is made predictable even though it is not consistent with other responses.
Ensuring fast response is probably a greater problem in the design of general-purpose, multi-user, time-shared systems than for dedicated information system applications. Where an information system is designed to accomplish defined tasks in a specified manner, data processing loads can usually be anticipated sufficiently well in user interface design to provide adequately fast response for all transactions.
Consistency is important in all aspects of user interface design. Anyone who has tried to learn a foreign language knows the difficulty of learning irregular verbs, whose conjugation does not follow any consistent rule. In the same way it is difficult to learn (and remember) irregular features of user interface design.
Data entry can be guided by consistent formatting of entry fields on the display, including consistent wording of labels, consistent placement of labels with respect to entry fields, and consistent demarcation of the fields themselves. Some kind of highlighting is frequently recommended for field delineation, displaying field location and boundaries clearly to a user. Even more guidance could be provided by consistent use of different field marking to indicate different types of data entry.
For data display, formats should be consistent from one frame to another, always including a title at the top, labels to indicate page numbers in related displays, standard labeling of control options, standard positioning of guidance messages, etc. Messages indicating user errors should be carefully worded to be both concise and informative. They should also be consistently worded from one message to the next, and consistently located in the display format. Even such a subtle feature as cursor positioning should receive consistent treatment in the software logic of user interface design.
For sequence control, consistent user interface design is even more important. One design feature that can help guide the user is consistent provision of a general OPTIONS display, a "home base" to which the user can return from any point in a transaction sequence in order to select a different transaction. As a basic principle of user guidance, the interface designer should not rely on a user to remember what prior actions have been taken, or even what action is currently being taken. Users may be distracted by competing job demands. For control actions whose consequences are contingent on context, an indication of context should always be displayed, even when that context was defined initially by the user.
Although consistent interface design will provide much inherent guidance, it is often desirable to include in computer-generated displays some explicit instructions or prompts for the user. Such instructions should be consistently located in display formatting, perhaps always at the bottom where they can be ignored by experienced users. For novice users it may be desirable to provide supplementary guidance or job instruction, available in response to user requests for help. Such optional guidance will adapt the interface to different user capabilities, supporting the novice user without hindering the expert.
The concern here is with on-line user instruction, as opposed to off-line system documentation. The need for on-line instruction has been emphasized by Brown, Brown, Burkleo, Mangelsdorf, Olsen and Perkins (1983, page 6-1) in their user interface guidelines developed as an in-house design standard at Lockheed: Much of the information commonly provided in paper documentation, such as user manuals, should also be available on line. A manual may not be available when it is needed. Some users may never receive the relevant documentation. They may not know what documents are available, which ones are relevant, or how to procure them. Even users who possess the appropriate documentation will not necessarily have it with them when it is needed.
One might add that even if users have the appropriate documentation on hand, they may not be able to find answers to their questions, especially when the documentation is bulky. Effective on-line instruction and other forms of user guidance can reduce the need for off-line training courses based on system documentation.
Certainly there is a strong trend in current system design toward on-line documentation for user instruction. This trend reflects the decreasing cost of computer memory, and also the increasing use of computers by people with little understanding of computer function. The novelty of early pioneering efforts to program computers to teach their own use (Morrill, 1967; Morrill, Goodwin and Smith, 1968; Goodwin, 1974) has now become almost commonplace, as we have learned more about the techniques of on-line aiding.
One of the principal arguments for on-line documentation is economic. Limanowski (1983) estimates a potential cost saving of 70 to 80 percent if on-line documentation can be provided as an alternative to more traditional paper documentation. If that is true, we can expect to see increasing recourse to on-line documentation for that reason alone.
People who are responsible for writing instructional material may be the first to note inconsistencies in user interface design. In the documentation of user guidance, whether intended for on-line display or printed handbooks, every special feature and smart shortcut provided by software designers will add an extra paragraph, or sentence, or footnote to the instructional material. As special features proliferate, instructions to the user must expand accordingly. On-line guidance will require more display space, and printed manuals will grow fatter.
From this reasoning, we may conclude that interface design may be improved if its documentation begins early, when changes are still relatively easy to make. On-line documentation can certainly be prepared (and changed) more quickly than printed user manuals, which suggests that early on-line documentation may help interface designers as well as the eventual system users.
Preparation of user guidance material will serve to indicate the point of diminishing returns in further elaboration of user interface software. If it takes ten minutes for a user to learn a special procedure that might save ten seconds in a seldom-used transaction, then design elaboration has outpaced user needs. Considering questions of user guidance throughout interface design will ensure that a sensible balance is struck between efficiency of operation and ease of learning, between functionality and usability. This practical trade-off has been noted by others concerned with user interface design (e.g., Goodwin, 1982), but requires continuing emphasis.
There is clearly an intimate relation between user guidance and interface design. The argument presented above that preparation of user guidance might help improve interface design can also be reversed. That is to say, interface designers can often help to improve user guidance. Preparation of user guidance should not be left solely the separate responsibility of technical writers who were not involved in the design process. Interface designers should participate as well.
In the course of design, a designer must sometimes make decisions that favor one group of users at the expense of another. As an example, for a system that will be used frequently by most of its users, a designer might choose to emphasize flexibility over simplicity when those two design goals conflict, while understanding that this priority could handicap some people who will use the system only occasionally. This priority would be reflected in the designer's choice of dialogue type, in the availability of control options, in display layouts, etc. A thoughtful designer can sometimes predict that users will have difficulty with particular design features. When that is the case, the designer's insight can contribute to the development of effective user guidance material.
In considering guidelines for design of user guidance functions, we must recognize that user guidance is a pervasive concern in interface design. Many of the guidelines proposed for data entry, data display, and sequence control functions have the implicit objective of making a system easier to learn and easier to understand during its use. From general recommendations for design consistency, through more detailed guidelines to help distinguish different aspects of information handling transactions, there must be an underlying concern for guiding the user's interaction with the computer. Thus almost any guideline for user guidance could be cross-referenced to a wide range of other design recommendations. Of the many possible cross references, a number of specific interest are cited in the guidelines proposed here.
Objectives
Consistency of operational procedures
Efficient use of full system capabilities
Minimal memory load on user
Minimal learning time
Flexibility in supporting different users
User guidance refers to error messages, alarms, prompts, and labels, as well as to more formal instructional material.
Design standard procedures for accomplishing similar, logically related transactions.
Comment
Standard procedures will facilitate user learning and efficient system
operation.
Comment
A designer might argue that for one particular transaction a standard
procedure does not seem efficient. Perhaps the standard procedure
requires one or two more keystrokes than some special procedure that
might be devised. But every special feature of interface design will
put a small added burden on the user's memory, and where special
procedures are not remembered they may not be used properly. Standard
procedures will increase overall operational efficiency.
Reference
See also
3.0/6
|
3.0/7
|
6.0/7
Require users to take explicit actions to specify computer data processing; the computer should not take extra (and possibly unrecognized) actions beyond those specified by a user.
Exception
Automatic cross file updating following data change might be considered
an exception to this rule.
Comment
Explicit actions, even though they may require an extra keystroke or
two, will help a user to learn procedures and to understand better what
is happening in any transaction. In effect, requiring the user to take
action to accomplish something can be regarded as a form of guidance.
Comment
An interface designer, with expert knowledge of the system and its
internal workings, is sometimes tempted to provide the user with "smart
shortcuts", where the computer will execute automatically some action
that the user would surely need to take. Incorporating such smart
shortcuts in interface design, though done with the intention of helping
the user, will risk confusing any but the most expert users.
Reference
See also
1.0/9
|
1.7/4
|
3.0/5
|
3.1.4/9
|
3.2/1
|
6.0/9
In applications where users must log on to the system, design LOG-ON as a separate procedure that is completed before a user is required to select among any operational options.
Comment
Separate LOG-ON will focus user attention on the required input(s),
without the distraction of having to anticipate other decisions, and
will help reduce initial confusion, particularly for novice users.
Reference
In general, follow recommendations for the design of data displays when designing user guidance displays.
Comment
Some of the specific guidelines for data display are restated for
convenient reference in this section, as particularly appropriate for
display of user guidance. Many other applicable data display guidelines
are cited by cross reference.
See also
2
Tailor the display for any transaction to the current information requirements of the user, so that only relevant data are displayed.
Comment
When this can be done successfully, so that only relevant data are
displayed, the display itself provides implicit guidance, showing what
data should be considered. Conversely, display of irrelevant data will
tend to confuse the user.
Reference
See also
2.0/1
|
2.0/2
|
2.7.2/1
Create display formats with a consistent structure evident to the user, so that any particular type of data is always presented in the same place and in the same way.
Comment
Consistent display formats will help new users learn to interact
efficiently with the system.
Reference
See also
1.4/24
|
1.4/25
|
2.0/6
|
2.5/1
|
2.7.1/4
|
3.0/8
|
3.1.3/8
|
3.1.3/32
|
3.1.5/2
|
3.4/7
|
4.4/8
Format each different type of user guidance consistently across displays.
Example
Display titles might be centered at the top of the display, with display
identification codes at the upper left corner. The bottom line of the
display should be reserved for command entries, where needed, in which
case the line just above it could be used for prompts and advisory
messages.
Comment
Types of user guidance include display titles, labeling of data entry
fields, prompts for data/command entry, error messages, alarms, status
and other advisory messages, as well as on-line instructional material.
Comment
Consistent allocation of particular areas of a display for user guidance
may be sufficient. Certain types of guidance, however, such as alarms
and error messages, may require auxiliary coding to help attract user
attention.
Reference
Design display formats so that user guidance material is readily distinguishable from displayed data.
Comment
Consistent location of user guidance on the display will usually
suffice, but other formatting conventions may help distinguish
particular categories of user guidance, such as labels, prompts, etc.,
as recommended in other guidelines.
Reference
See also
1.4/16
|
1.5/2
|
2.2/8
|
2.5/2
|
3.1.3/20
|
3.1.4/17
Design cursors (in terms of shape, blink, or other means of highlighting) so that they are readily distinguished from other displayed items.
Comment
When a cursor is automatically positioned under computer control, it can
serve to direct the user's attention to a particular point on a display,
and so it should be designed to catch the eye. Even when the cursor has
been positioned by a user, if the user is momentarily distracted then a
distinctive format may help locate the cursor.
Comment
A cursor is the most immediate and continuously available form of user
guidance, since it will generally mark the current focus of user
attention. With this in mind, the interface designer may decide to use
different cursor formats to denote different operational conditions. If
that is done, each of those different cursors should be distinctive from
other displayed items, and from each other.
Label function keys and other controls clearly to indicate their function.
Reference
Label all displayed data clearly.
Comment
Labels for individual data fields can be omitted only where display
format and labeling of grouped data clearly identify subordinate items,
as in row/column labeling of tabular data.
Reference
See also
1.4/5
|
1.4/19
|
1.4/20
|
1.4/21
|
1.4/23
|
1.5/3
|
2.2/3
Whatever methods are used to highlight critical items in data display, adopt similar methods to highlight the display of critical user guidance information.
Comment
Alarms and warning messages may require output of auxiliary auditory
signals as well as display highlighting, to help assure that they
attract the user's attention.
Reference
See also
2.6/1
|
3.6/2
|
4.3/17
Ensure that symbols and other codes have consistent meanings from one display to another.
Comment
This practice will aid user learning of new codes, so that they will
gain familiarity. Where codes have special meanings, those should be
defined in the display.
Reference
See also
2.6/7
|
2.6/16
|
2.6/32
|
3.1.3/13
|
4.4/21
Ensure that codes and abbreviations for data entry/display conform to conventional usage and user expectations.
Comment
Conventional usage will aid user learning of codes, and reduce the
likelihood of user error in code generation (entry) and code
interpretation (display).
Comment
Deviation from familiar meanings, such as using an aircraft symbol to
denote artillery and vice versa, would almost certainly confuse users.
Reference
Ensure that the names for function keys, command names, etc., are consistent for similar or identical functions in different transaction sequences.
Example
As a negative example, do not call the same function EDIT in one place,
MODIFY in another, UPDATE in a third.
Comment
Consistency in interface design is the fundamental basis of effective
user guidance.
Reference
See also
3.0/10
|
3.1.3/12
|
3.1.3/14
|
3.1.3/19
|
3.1.5/7
When wording labels, prompts and user guidance messages, adopt terminology familiar to users.
Example
(Good)
| Data requires special access code; |
| call Data Base Admin, X 9999. |(Bad)
| IMS/VS DBMS private data; see DBSA, 0/99-99. |
Comment
User testing and iterative design will often be needed to eliminate
difficult words, abbreviations and acronyms that are not generally
familiar to all users.
Reference
See also
2.0/4
|
2.0/12
|
3.1.5/6
Adopt task-oriented wording for labels, prompts and user guidance messages, incorporating whatever special terms and technical jargon may be customarily employed in the users' tasks.
Comment
Jargon terms may be helpful, if they represent the jargon of the user
and not of the designer or programmer. The rule here should be to know
the users and adapt interface design to their vocabulary instead of
forcing them to learn new wording.
Reference
See also
1.4/22
|
2.0/12
|
3.1.5/6
|
3.1.5/7
|
3.2/9
Choose wording for user guidance that is consistent with the words used for control entries.
Example
(Good)
| To delete a paragraph, press DELETE and then PARAGRAPH. |(Bad)
| To erase a paragraph, press DELETE and then PARAGRAPH. |
Example
If a user must complete a control form to specify printer settings, the
words used as labels on that form should also be used in any error
messages and HELP displays which may guide that process.
Comment
When selecting or composing control entries, a user will tend to mimic
the vocabulary, format, and word order used in computer displays,
including labels, error messages, HELP displays, etc. If displayed
wording is consistent with required entries, a user will be more likely
to make a correct entry on the first try.
Comment
Consistent wording of user guidance will be particularly helpful for
dialogues based on constrained natural language. If a designer begins
by determining which words and formats users are likely to choose
naturally, and then reinforces that usage by incorporating such wording
in user guidance, much of a user's interaction with the computer will be
predictable. Therefore, the "natural language" need not accommodate the
full range of possible entries, but only those entries which users are
likely to make.
Reference
See also
2.0/7
|
3.0/13
|
3.1.7/1
Choose wording for user guidance that speaks directly to a user, rather than talking about users.
Example
(Good)
| Press ENTER to continue. |(Bad)
| The user should press ENTER to continue. |
Reference
Adopt affirmative rather than negative wording for user guidance messages.
Example
(Good)
| Clear the screen before entering data. |(Bad)
| Do not enter data before clearing the screen. |
Comment
Affirmative statements are easier to understand. Tell the user what to
do rather than what to avoid.
Reference
See also
2.1/16
Adopt active rather than passive voice in user guidance messages.
Example
(Good)
| Clear the screen by pressing RESET. |(Bad)
| The screen is cleared by pressing RESET. |
Comment
Sentences in active voice are easier to understand.
Reference
See also
2.1/17
When user guidance describes a sequence of steps, follow that same sequence in the wording of user guidance.
Example
(Good)
| Enter LOG-ON sequence before running programs. |(Bad)
| Before running programs, enter LOG-ON sequence. |
Reference
See also
2.1/18
Be consistent in grammatical construction when wording user guidance.
Example
(Good) (Bad)
| Options: | | Options: |
| s = Select data | | s = Select data |
| e = Erase display | | e = Erasure function |
| w = Write file | | w = Write file |
Comment
Even minor inconsistencies can distract a user, and delay comprehension
as the user wonders momentarily whether some apparent difference
represents a real difference.
Comment
Consistent grammatical construction may help a user resolve an ambiguous
message (e.g., | Numeric entry |) to understand whether it recommends an
action (e.g., "You should enter a number") or indicates an error
condition (e.g., "You entered a number when you shouldn't have").
Reference
See also
2.0/15
|
2.2/5
|
3.1.3/11
When techniques adopted for user guidance (display of option lists, command prompting, etc.) may slow an experienced user, provide alternative paths or modes permitting a user to by-pass standard guidance procedures.
Comment
Multiple paths, such as command entry to by-pass a menu, or use of
abbreviated rather than complete commands, can speed the performance of
an experienced user. The interface designer, however, should take care
that such shortcuts supplement rather than supplant the standard, fully
guided procedures provided for novice users.
Reference
See also
3.0/2
|
4.4/31
|
4.4/32
Allow users to switch easily between any information handling transaction and its associated guidance material.
Example
Guidance might be displayed as a temporary "window" overlay on the
working display, which a user could request or suppress at will.
Comment
If user guidance is difficult to obtain, and/or if asking for guidance
will disrupt a current transaction (e.g., erase a working display), then
users will prefer to guess at proper procedures rather than seeking
help.
Reference
Consider computer-generated speech output for user guidance messages in environments with low ambient noise, when a user's attention may not be directed toward a visual display or when providing a visual display is impractical.
Example
Computer-generated speech might be used to provide prompts or status
messages, including warnings. A familiar example of the use of
computer-generated speech for warnings is the "talking dashboard", which
tells a car driver when a door is open, or when the car requires
service.
Comment
A noisy environment, particularly noise from other voices, will make it
difficult for a user to hear computer-generated speech.
Comment
Auditory signals such as computer-generated speech are useful for
notifying a user of important information when his/her attention is
focused somewhere other than a visual display, such as when a
touch-typist transcribes data from a paper form.
Comment
Speech output might also help a user who must access a computer from a
remote location, by telephone.
Comment
When considering speech output for user guidance, remember that people
other than the user might hear those spoken messages. Speech output may
prove distracting to other people trying to work nearby. Or the user of
a system may not wish others to hear his/her messages, as might be the
case if spoken messages were provided for an automated banking
application.
Reference
Limit computer-generated speech to provide only a few messages.
Example
As negative examples, computer-generated speech would not be useful if
many messages might be given at one time, or for conveying a lengthy
list of menu options.
Comment
When messages are spoken, the user must remember each message. If many
different messages are given one after another, then a user would
probably not remember them all, and might only remember one or two.
When using computer-generated speech to provide messages, ensure that those messages are short and simple.
Comment
If a user does not understand a written message, s/he can reread it.
That is not the case with spoken messages. Though a REPEAT function
might be provided, a better solution is to restrict use of speech
outputs for short and simple messages.
Comment
If a user who may not be watching a display must be given long or
complex messages, it is probably better to provide a simple auditory
signal such as a chime, and then display the messages visually for the
user to read. In general, users will understand complex messages better
when they see them displayed than when they hear them.
Reference
If computer-generated speech is used to provide warnings as well as other forms of user guidance, ensure that spoken warnings are easily distinguishable from routine messages.
Example
Speech output used to identify dangerous conditions might use some
distinctive voice (perhaps female rather than male, or vice versa)
and/or preface each warning message with some other distinctive auditory
signal.
Comment
In some applications, computer-generated speech might be useful for
providing a few short and simple warnings. However, if speech output is
also used for other purposes, then the warning messages must be
distinctive.
Reference
See also
2.6/42
Status information on current data processing should be available at all times, automatically or by request.
Provide some indication of system status to users at all times.
Comment
In some applications, system status may be continuously displayed.
Status display can be explicit (e.g., by message), or can be implicit
(e.g., by a displayed clock whose regular time change offers assurance
that the computer link is still operating). Alternatively, system
status information might be provided only on user request, following a
general or specific query.
Comment
Status information is particularly needed, of course, when system
operation is unreliable for any reason. Under those conditions, if
status information is not provided by design, users will often devise
their own repertoire of harmless but time-wasting inputs to test system
performance.
Comment
When system status changes, it may be desirable for the computer to
generate an advisory message to draw users' attention to that change.
Reference
When users must log on to a system, display appropriate prompts for LOG-ON procedures automatically at a user's terminal; do not require users to take any special action to obtain a LOG-ON display, other than turning on the terminal.
Comment
An automatic LOG-ON display will signal the operational availability of
a terminal, as well as prompting the user to make necessary initial
inputs.
Reference
See also
4.0/3
If a user tries to log onto a system and LOG-ON is denied because of system unavailability, display an advisory message to tell the user what the system status is and when the system will become available.
Example
| System is down for maintenance until 9:30 AM. |
Comment
Avoid "as soon as possible" messages. Make an estimate of system
availability, and update the estimate later if that becomes necessary.
Reference
If at any time the keyboard is locked, or the terminal is otherwise disabled, notify the user.
Example
Control lockout might be signaled by disappearance of the cursor from
the display, or by a notable change in the shape of the cursor,
accompanied by an auditory signal.
Comment
An auditory signal will be especially helpful to touch-typists, who may
be looking at source documents for data entry rather than at the display
or keyboard.
See also
3.0/20
When the results of user action are contingent upon different operational modes, then clearly indicate the currently selected mode.
Example
A change in display caption and/or cursor shape might suffice to alert
users to changing modes.
Reference
See also
3.4/4
|
4.2/8
|
4.4/13
When task performance requires data exchange and/or interaction with other users, allow a user to obtain status information concerning other people currently using the system.
Comment
If there are many other users, it might be helpful to allow a user to
ask whether any particular individual is a current user.
See also
5.3/5
When task performance is affected by operational load (e.g., number of on-line users), allow a user to obtain status information indicating current system performance, expressed in terms of computer response time.
Comment
It may be necessary to define a "standard" function for which computer
response time is predicted on a normalized basis.
Comment
Such load information is primarily helpful, of course, when system use
is optional, i.e., when a user can choose to defer work until low-load
periods. But load status information may help in any case by
establishing realistic user expectations for system performance.
When task performance requires data exchange and/or interaction with other systems, allow a user to obtain relevant status information for external systems.
See also
5.3/5
When task performance requires or implies the need to assess currency of information, annotate displays with date-time signals.
Comment
Depending on the application date-time status might be displayed
continuously or periodically on displays that are automatically updated,
or by user request.
When alarm signals are established on the basis of logic defined by users, permit users to obtain status information concerning current alarm settings, in terms of dimensions (variables) covered and values (categories) established as critical.
Comment
Alarm status information will be particularly helpful in monitoring
situations where responsibility may be shifted from one user to another
("change of watch").
See also
3.6/1
Routine feedback should be provided by a computer to its users as transactions are processed.
Ensure that every input by a user will consistently produce some perceptible response output from the computer; when a terminal is in use, its display screen should never be blank.
Exception
A user might choose to blank a display screen temporarily, perhaps to
protect data from casual onlookers, but even then some acknowledging
message should probably appear, e.g.,
| Display temporarily suppressed. |
Comment
Keyed entries should appear immediately on the display. Function key
activation or command entries should be acknowledged either by evident
performance of the requested action, or else by an advisory message
indicating an action in process or accomplished. Inputs that are not
recognized by the computer should be acknowledged by an error message.
Comment
Absence of system response is not an effective means of signaling
acceptable entry. At best, a dialogue without feedback will be
disconcerting to the user, as when we talk to an unresponsive human
listener. At worst, the user may suspect system failure, with
consequent disruption and/or termination of the interaction sequence.
Reference
See also
1.0/3
|
1.0/12
|
1.0/13
|
3.0/14
|
3.0/16
|
3.1.3/9
|
3.1.4/10
|
6.2/6
Ensure that computer response to user entries will be rapid, with consistent timing as appropriate for different types of transactions.
Reference
See also
1.1/5
|
2.7.1/6
|
3.0/18
|
3.1/2
Provide some indication of transaction status whenever the complete response to a user entry will be delayed.
Comment
After making an entry to the computer, the user needs feedback to know
whether that entry is being processed properly. Delays in computer
response longer than a few seconds can be disturbing to the user,
especially for a transaction that is usually processed immediately. In
such a case some intermediate feedback should be provided, perhaps as an
advisory message that processing has been initiated, and ideally with an
estimate of how long it will take to complete.
Comment
Indicating the progress of computer processing is particularly important
when response time is inconsistent and may be lengthy, which is often
the case when users perform complex functions on time-shared systems.
Displaying time-to-completion or some other indication of progress will
permit users to plan their time more effectively, and perhaps to perform
other tasks while waiting.
Comment
Note that a routine advisory (e.g., | Wait for processing |) displayed
before every computer response, whether fast or slow, is not an
effective indication of transaction status. Users will come to ignore
routine messages that are sometimes true but sometimes just false
alarms.
Reference
See also
3.0/14
When computer processing of a user entry has been delayed, inform the user when processing is completed, and provide appropriate guidance for further user actions.
Comment
For long delays, interim feedback on processing status before completion
may be reassuring to a user. Such follow-up messages, however, should
not interfere with current user activities. It may be desirable to
reserve a special display window for prompts and advisory messages.
Reference
See also
3.0/15
When user requests for printed output will be handled by a remote printer, give the user an advisory message confirming that a print request is being processed.
Reference
See also
1.3/29
Provide a unique identification for each display in a consistent location at the top of the display frame.
Exception
As a possible exception, interface designers may sometimes provide
unlabeled displays as "free-form" screens for text entry and other tasks
involving display composition by users.
Comment
A displayed title may suffice, although a shorter identification code
may be helpful for some purposes. The objective is to help the user
recognize a display when it appears, to learn interactive sequences
stepping from one display to another, and (in some system applications)
to request a particular display directly. Display identification will
also help both users and interface designers to refer to individual
displays in discussion and documentation.
Comment
In applications involving menu selection, it may prove helpful to code
each display with the string of option selections (letter codes) used to
reach that display. This practice is particularly useful in situations
where a user can learn to by-pass the menu selection sequence by
entering option string codes as a single command to request a familiar
data display.
Reference
See also
2.5/10
|
2.7.1/2
|
2.7.1/3
|
2.7.1/4
When lists or data tables extend beyond the capacity of a single display frame, inform the user that the display is continued in multiple frames.
Example
Incomplete lists might be annotated at the bottom as
| Continued on next page |
Example
For extended data tables, the display title might be annotated as
| Page ____ of ____ |
Example
For scrolled data, displays might be annotated with the current and
concluding locations
| Line ____ of ____ |
Exception
In special formats such as spreadsheets the partial nature of a display
may be self-evident.
Comment
As a complementary recommendation, it may also be desirable to conclude
completed lists with the annotation
| End of list |
unless the list is so short that it obviously does not fill available
display space.
Reference
When a user (or computer) action establishes a change in operational mode that will affect subsequent user actions, display some continuing indication of current mode.
Example
Selection of a DELETE mode in text editing should produce some kind of
warning signal on the display, perhaps by a distinctive change in cursor
shape.
Comment
This practice is particularly helpful when the mode selected is one
seldom used.
Comment
Display of mode selection will help prevent unintended data loss when
the mode is potentially destructive (e.g., DELETE). For destructive
modes, it may help if the mode indication is implemented as some sort of
distinctive change in the appearance of the cursor, since the cursor is
probably the one display feature most surely seen by a user.
Reference
See also
3.4/4
|
3.4/5
|
4.1/5
|
4.4/13
|
6.0/15
|
6.0/16
When previously selected options are still operative, display those options either automatically or on user request.
Comment
Displaying a cumulative sequence of option selections may help a novice
user learn transaction sequences, and may help any user deal with
complex transactions.
Reference
When a user selects a displayed item in order to perform some operation on it, highlight that item on the display.
Comment
This practice will provide a routine natural feedback that item
selection has been accomplished, and will provide a continuing reminder
to the user of just what selection has been made.
Comment
Highlighting might be accomplished in different ways. Reverse video is
commonly employed for this purpose. For a selection among displayed
options, the selected option might be brightened.
Reference
See also
1.1/5
|
3.1.3/9
|
3.4/6
Following user interrupt of data processing, display an advisory message assuring the user that the system has returned to its previous status.
Reference
See also
3.3/6
Error feedback should be provided if an error or other unexpected event prevents routine processing.
When the computer detects an entry error, display an error message to the user stating what is wrong and what can be done about it.
Example
(Good)
| Code format not recognized; enter two letters, |
| then three digits. |(Bad)
| Invalid input. |
Comment
Users should not have to search through reference information to
translate error messages.
Comment
Error messages can be regarded as the most important form of system
documentation. Well designed error messages will give help to users
automatically, at the point where help is most needed.
Reference
Make the wording of error messages as specific as possible.
Example
(Good)
| No record for Loan 6342; check number. |(Bad)
| No record for inquiry. |
Comment
Specificity will require computer analysis of data processing
transactions in context.
Reference
Adopt wording for error messages which is appropriate to a user's task.
Example
(Good)
| Contract number not recognized; check |
| the file and enter a current number. |(Bad)
| Entry blocked. Status Flag 4. |
Comment
Error messages that can be understood only by experienced programmers
(and interface designers) will have no value for ordinary users.
Reference
If a data entry or (more often) a control entry must be made from a small set of alternatives, an error message that is displayed in response to a wrong entry should indicate the correct alternatives.
See also
3.2/5
Make error messages brief but informative.
Example
(Good)
| Entry must be a number. |(Bad)
| Alphabetic entries are not acceptable because |
| this entry will be processed automatically. |
Comment
Often a user will recognize that an error has been made, and the message
will serve merely as a confirming reminder. In such instances, short
error messages will be scanned and recognized more quickly.
Comment
For a user who is truly puzzled, and who needs more information than a
short error message can provide, auxiliary HELP can be provided either
on-line or by reference to system documentation.
Comment
If an on-line HELP explanation is not available, a user may have to
refer to system documentation for a coded listing of possible errors.
Under those circumstances, some designers display each error message
with an identifying code, to facilitate rapid reference to
documentation. That practice might help experienced users, who would
gradually come to recognize the codes.
Reference
See also
2.1/13
|
2.1/14
|
4.4/23
Adopt neutral wording for error messages; do not imply blame to the user, or personalize the computer, or attempt to make a message humorous.
Example
(Good)
| Entry must be a number. |(Bad)
| Illegal entry. |(Bad)
| I need some digits. |(Bad)
| Don't be dumber, use a number. |
Comment
Error messages should reflect a consistent view that the computer is a
tool, with certain limitations that a user must take into account in
order to make the tool work properly. If error messages reflect an
attitude that the computer (or its programmer) imposes rules, or
establishes "legality", the user may feel resentful. If error messages
reflect personalization of the computer, as if it were a friendly
colleague, a naive user may be misled to expect human abilities the
machine does not actually possess. If error messages are worded
humorously, any joke will surely wear thin with repetition, and come to
seem an intrusion on a user's concern with efficient task performance.
Comment
The same considerations apply for the wording of computer-generated
prompts and other instructional material.
Reference
Following the output of a simple error message, permit users to request a more detailed explanation of the error.
Comment
A more complete discussion of each error could be made available
on-line, perhaps at several levels of increasing detail, supplemented by
reference to off-line system documentation if necessary. Successively
deeper levels of explanation might then be provided in response to
repeated user requests for HELP.
Reference
See also
4.4/28
When multiple errors are detected in a combined user entry, notify the user, even though complete messages for all errors cannot be displayed together.
Example
| DATE should be numeric. |
| + 2 other errors |
Comment
The computer should place the cursor in the data field referred to by
the displayed error message, with other error fields highlighted in some
way, e.g., by reverse video. There should also be some means for the
user to request sequential display of the other error messages if
needed.
Reference
If a user repeats an entry error, there should be some noticeable change in the displayed error message.
Example
A simple expedient might be to display the same verbal message but with
changing annotation, perhaps marked with either one asterisk or two.
Comment
If an error message is repeated identically, so that displayed feedback
seems unchanged, the user may be uncertain whether the computer has
processed the revised entry.
The computer should display an error message only after a user has completed an entry.
Example
An error message should not be generated as wrong data are keyed, but
only after an explicit ENTER action has been taken.
Comment
In general, the display of error messages should be timed so as to
minimize disruption of the user's thought process and task performance.
Reference
Display an error message approximately 2-4 seconds after the user entry in which the error is detected.
Exception
For type-ahead systems with experienced users, error messages should be
displayed as quickly as possible.
Comment
Longer delays in error feedback may cause user uncertainty or confusion.
Longer delays may also cause frustration if the user is already aware of
the error, which is often the case.
Comment
Shorter delays in error feedback can pose problems of a different sort.
An error message following immediately upon a user entry can be
disconcerting. Immediate error feedback can also be irritating. User
expectations are conditioned by human conversation, where an immediate
contradiction is considered rude, and where a polite listener will pause
for a few moments before saying that you are wrong.
Comment
If error messages take somewhat longer to appear than the routine
computer response, then that additional delay may cue the user to expect
an error message and pay attention to it.
Reference
See also
3.0/18
As a supplement to on-line guidance, include in the system documentation a listing and explanation of all error messages.
Comment
Developing good error messages may require review by both designers and
users. Documentation of the complete set of error messages will
facilitate such review.
Comment
Documentation of error messages will permit users to reference
particular messages for fuller explanation, and to review all messages
as a means of understanding data processing requirements and
limitations.
Reference
In addition to providing an error message, mark the location of a detected error by positioning the cursor at that point on the display, i.e., at that data field or command word.
Comment
Displaying the cursor at a non-routine position will help emphasize that
an error has occurred, and direct the user's attention to the faulty
entry.
Reference
See also
4.4/16
When an entry error has been detected, continue to display the erroneous entry, as well as an error message, until corrections are made.
Comment
The error itself may provide useful information, in conjunction with the
error message, helping a user understand the specific nature of the
error.
Following error detection, require the user to re-enter only that portion of a data/command entry which is not correct.
Comment
The user should not have to rekey an entire command string or data set
just to correct one wrong item.
Reference
See also
3.1.5/23
|
3.5/3
|
6.0/10
|
6.3/10
Ensure that a displayed error message is removed after the error has been corrected; do not continue to display a message that is no longer applicable.
Comment
The immediate removal of an error message upon error correction will
serve as feedback to a user that the corrected entry is indeed correct.
Reference
When a data or command entry seems doubtful, in terms of defined validation logic, display a cautionary message asking the user to confirm that entry.
Example
| Blood pH of 6.6 is outside the normal range; |
| confirm or change entry. |
Comment
Feedback to the user can be worded to deal with a range of intermediate
categories between a seemingly correct entry and an outright error.
Reference
Require the user to take some explicit action to confirm a potentially destructive data/command entry before the computer will execute it.
Comment
A requirement to take an explicit CONFIRM action will direct user
attention to questionable entries and help the user avoid the
consequences of thoughtless errors.
Comment
What constitutes "potentially destructive" requires definition in the
context of each system application.
Reference
See also
3.5/7
|
6.0/18
|
6.0/20
|
6.3/19
For conditions requiring (or implying the need for) special user attention, code the alarms (or warning messages) distinctively.
Example
Alarm messages might be marked with a blinking symbol and/or displayed
in red, and be accompanied by an auditory signal; warnings and error
messages might be marked with a different special symbol and/or
displayed in yellow.
Comment
This practice will help ensure appropriate attention, even when a user
is busy at routine tasks.
Reference
See also
2.6/12
|
2.6/32
|
2.6/35
|
2.6/40
|
3.6/2
|
6.0/17
Job aids should provide users with specific task-oriented guidance for every transaction.
Ensure that specific user guidance information is available for display at any point in a transaction sequence.
Comment
Do not require a user to remember information not currently displayed.
The user should not have to remember what actions are available, or what
action to take next. Human memory is unreliable, and without guidance
users can be expected to make errors.
Reference
See also
2.0/3
|
2.7.2/1
|
3.1.3/17
|
3.1.3/18
|
3.2/4
|
3.2/5
Provide a general list (menu) of control options that is always available to serve as a "home base" or consistent starting point to begin a transaction sequence.
Reference
See also
3.1.5/12
|
3.2/2
|
3.2/3
Display menu options in logical groups.
Comment
Logical grouping of menu options will aid user learning and selection
among displayed alternatives. It may be necessary to test proposed
menus to determine just what structural groupings will seem logical to
their intended users.
See also
2.1/23
|
3.1.3/22
|
3.2/3
When hierarchic menus are used, organize and label them to guide users within the hierarchic structure.
Comment
Users will learn menus more quickly if a map of the menu structure is
provided as HELP.
Reference
See also
3.1.3/24
|
3.1.3/25
|
3.1.3/30
At every point in a transaction sequence, provide guidance telling the user how to continue.
Example
(Good)
| Data are current through March 1986. |
| Press STEP key to continue. |(Bad)
| Data are current through March 1986. |
Reference
See also
3.0/4
|
3.1.3/16
|
3.2/12
If there are control options that are specifically appropriate to the current transaction, indicate those options on the display.
Exception
Treat control options that are generally available at every step in a
transaction sequence (PRINT, perhaps) as implicit options that need not
be included in a display of specific current options.
Comment
Usually space can be found on a working display to remind users of
several specific control options that are appropriate to the current
transaction. A list of all available options, however, may well exceed
display capacity. A user may be expected to remember general options,
once they have been learned, without their specific inclusion in a
display of guidance information. Perhaps the best design approach is to
implement general options on appropriately labeled function keys, which
will aid user learning and provide a continuing reminder of their
availability.
Provide advisory messages and other prompts to guide users in entering required data and/or control parameters.
Comment
Prompting in advance of data/control entry will help reduce errors,
particularly for inexperienced users. Prompting might be provided as an
optional feature for skilled users.
Comment
If a default value has been defined for null entry, that value should be
included in the prompting information.
Reference
See also
1.0/24
|
1.8/4
|
3.1.5/11
|
3.2/11
|
3.5/5
Display prompts for data/command entry in a standard location, next to the command entry area at the bottom of the display.
Comment
As an alternative, prompts might be provided in a window overlay added
to a working display at user request.
Use consistent phrasing and punctuation in all prompts.
Example
(Good)
| Save as new file or Overwrite old file (S/O): |and
| Create new file or Edit old file (C/E): |(Bad)
| (S)ave as new file or (O)verwrite old file: |and
| Would you like to create a new |
| file or edit an old file (C/E): |
Reference
Choose a standard symbol for prompts indicating that an entry is required, and reserve that symbol only for that purpose.
Example
(Good)
| Enter completion code: |(Bad)
| Enter completion code |
Comment
Some standard prompting symbol in data entry forms, in menus, in command
entry lines, etc., will help to cue users that an input is required.
That standard symbol, used along with other formatting cues, will help
to alert a user to differences between advisory messages and messages
requiring an input.
Reference
Use concise wording for prompts; eliminate extraneous words.
Example
(Good)
| Delete what: |(Bad)
| What text would you like to delete: |
Reference
When users vary in experience, which is often the case, provide prompting as an optional guidance feature that can be selected by novice users but can be omitted by experienced users.
Comment
Flexibility in prompting can also be provided by multilevel HELP
options, so that additional guidance information can be obtained if the
simple prompt is not adequate.
See also
3.1.5/11
|
3.1.5/13
|
4.4/28
When the results of a user entry depend upon context established by previous entries, display some indication of that context to the user.
Example
When the effects of user entries are contingent upon different
operational modes, indicate the current mode.
Example
If the user is editing a data file, display both the file name and an
indication of EDIT mode.
Reference
See also
2.7.3/6
|
2.7.3/7
|
3.0/9
|
3.1.4/5
|
3.1.4/11
|
3.4/1
|
3.4/4
|
3.4/5
|
4.1/5
|
4.2/8
In a transaction involving extended data entry, display a cumulative record of any previous inputs that are relevant to the current input.
Example
In a multipage data entry display, do not rely on the user to remember
data accurately from one page to the next.
Provide cues for data entry by formatting data fields consistently and distinctively.
Example
A colon might be used consistently to indicate that an entry can be
made, followed by an underscored data field to indicate item size, such
as
| Enter part code: __ __ __-__ __ |or perhaps just simply
| Part code: __ __ __-__ __ |
Comment
Consistent use of prompting cues can sometimes provide sufficient
guidance to eliminate the need for more explicit advisory messages.
Reference
See also
1.4/10
|
1.4/11
|
1.4/12
|
1.4/18
As the last step in generating a display output, ensure that the computer will automatically position the cursor so that it appears in a consistent display location for each type of transaction.
Example
For data entry displays, the cursor should be placed initially at the
first data field, or else at the first wrong entry if an error has been
detected; in other displays, the cursor might be placed at a consistent
HOME position, or at the first control option for menu selection, or
else in a general command entry area, depending upon the type of
display.
Comment
Consistent cursor positioning will provide an implicit cue for user
guidance.
Reference
See also
1.1/20
|
1.1/21
|
1.4/28
|
3.2/6
|
3.2/7
|
4.3/13
Provide reference material describing system capabilities and procedures available to users for on-line display.
Comment
Many systems are not utilized effectively because users do not fully
understand system capabilities. On-line access to a description of
system structure, components and options will aid user understanding.
Comment
On-line guidance can supplement or in some instances substitute for
off-line training. An investment in designing user aids may be repaid
by reduced costs of formal training as well as by improved operational
performance.
Reference
In applications where the user can choose what stored data to display, provide an on-line data index to guide user selection.
Comment
The data index should indicate file names, objects, properties, and
other aspects of file structure that might be used to access different
categories of data. It may help to allow users to specify what they
require in this index. Some users might wish information on file size,
currency (time of latest update), etc. Other users might wish to add a
short description of each data file to remind themselves of its
contents.
Reference
See also
3.1.6/3
In applications where a user can employ command entry, provide an on-line command index to guide user selection and composition of commands.
Comment
Such a command index may help a user to phrase a particular command, and
will also be generally helpful as a reference for discovering related
commands and learning the overall command language.
Reference
Provide a complete dictionary of abbreviations used for data entry, data display, and command entry, both for on-line user reference and in design documentation.
Comment
In applications where users can create their own abbreviations, as in
the naming of command "macros", it will be helpful to provide aids for
users to create their own individual on-line dictionaries.
Reference
See also
2.0/21
When codes are assigned special meaning in a particular display, include a definition of those codes in the display.
Comment
This practice will aid user assimilation of information, especially for
display codes that are not already familiar.
Reference
See also
2.6/6
Allow users to request a displayed record of past transactions in order to review prior actions.
Reference
In addition to explicit aids (labels, prompts, advisory messages) and implicit aids (cueing), permit users to obtain further on-line guidance by requesting HELP.
Comment
It is difficult for an interface designer to anticipate the degree of
prompting that may be required to guide all users. Moreover, even when
prompting needs are known, it may be difficult to fit all needed
guidance information on a display page. One possibility would be to
provide user guidance in a window overlay added to a working display
when a user requests HELP. If more extensive user guidance is needed,
then a separate, full-screen HELP display might be provided.
Reference
See also
2.7.5
Provide a simple, standard action that is always available to request HELP.
Example
HELP might be requested by an appropriately labeled function key, or
perhaps by keying a question mark into a displayed entry area.
Comment
A user should be able to request HELP at any point in a transaction
sequence. The procedure should always be the same, whether the user
wants an explanation of a particular data entry, a displayed data item,
or a command option.
Reference
Tailor the response to a HELP request to task context and the current transaction.
Example
If a data entry error has just been made, HELP should display
information concerning entry requirements for that particular data item.
Example
If an error in command entry has just been made, HELP should display
information concerning that command, its function, its proper structure
and wording, required and optional parameters, etc.
Reference
When a request for HELP is ambiguous in context, the computer should initiate a dialogue in which the user can specify what data, message or command requires explanation.
Example
The computer might ask a user to point at a displayed item about which
HELP is requested.
When a user requests HELP on a particular topic, the computer should accept synonyms for standard system terminology.
Example
If a DELETE command exists, then an explanation of that command might be
displayed when a user requests HELP for ERASE.
Comment
Users will often attempt to get HELP for a function they know exists,
but cannot remember its correct name.
Comment
Likely synonyms can be identified by compiling a list of function names
used in other similar systems. Other synonyms can be discovered through
user testing. It might be desirable to let HELP facilities grow to meet
user needs by allowing a system administrator to add synonyms to the
system.
When an initial HELP display provides only summary information, provide more detailed explanations in response to repeated user requests for HELP.
Comment
It is necessarily a matter of judgment just what information should be
provided in response to a HELP request. Designing the HELP function to
provide different levels of increasing detail permits users to exercise
some judgment themselves as to just how much information they want.
Reference
See also
4.3/7
Permit users to browse through on-line HELP displays, just as they would through a printed manual, to gain familiarity with system functions and operating procedures.
Reference
Where appropriate, provide an on-line training capability to introduce new users to system capabilities and to permit simulated "hands on" experience in data handling tasks.
Comment
On-line simulation, using the same hardware, user interface software and
data processing logic as for the real job, can prove an efficient means
of user training. Care must be taken, however, to separate the
processing of simulated data from actual system operations.
Reference
Anticipate the needs of different users, and offer different levels of training for on-line job support.
Example
In systems supporting different user jobs, on-line instruction might
describe the procedures for each different data handling task.
Example
Instruction on keyboard use and lightpen selection of menu options might
be provided for novice users, while a tutorial on command language might
be provided for more experienced users.
See also
3.0/3
|
3.1/1
|
3.1.3/35
|
3.1.5/4
|
4.0/24
In applications where a user must learn complex tasks, design computer-mediated training to adapt automatically to current user abilities.
Comment
Adaptive training will require some means for computer assessment of
appropriate components of user performance.
User records will permit assessment of performance and improvement of user interface design.
In applications where skilled user performance is critical to system operation, provide automatic computer recording and assessment of appropriate user abilities.
Comment
Recording individual performance may be constrained by other
considerations, as noted elsewhere in this section.
See also
4.4/32
Inform users of any records kept of individual performance.
Comment
Informing users concerning the nature and purpose of performance records
is required by ethical principle, and in some situations may be required
by law.
Comment
Recording individual performance is potentially subject to abuse, and
requires careful scrutiny to ensure essential protection of user
privacy. Designers must conform to whatever legal (or otherwise agreed)
restrictions may be imposed in this regard.
Ensure that the computer can maintain records of user transactions.
Comment
Record keeping might include duration, sequencing and frequency of
different transactions. Such transaction records will aid task
analysis, particularly in developing systems where data handling
requirements are not yet fully defined.
Comment
A buffered store of current transactions may be required for user
guidance, and for other purposes such as supporting an UNDO capability.
Comment
In some applications, transaction recording might be made optional,
under control of a system administrator.
See also
4.4/22
Ensure that the computer can maintain records of data access, i.e., which data files, categories, or items have been called out for display.
Comment
Records of data use may help software designers improve file structure,
reduce data access time, and manage multiple use of shared data files.
Comment
Data access records may also be required for purposes of data
protection/security.
See also
6.2/8
Ensure that the computer can maintain records of use for different portions of application software.
Comment
In some cases "program calls" can be derived from transaction records
rather than having to be measured directly.
Comment
Records of software use may not affect user interface design directly,
but can help detect and correct programming inefficiencies and improve
system response, particularly during early stages of system development.
Provide a capability for recording user errors.
Comment
Error recording might be done continuously, or by periodic sampling
under the control of a system administrator.
Comment
Error records can be used to indicate supplemental instruction needed by
different users, if individual user errors are identified. In that
case, ethical considerations (and in some instances legal
considerations) dictate that users be informed that such records will be
kept.
Comment
Error records can be used to indicate whether particular transactions
are giving trouble to many users, in which case design improvements to
the user interface may be needed, including changes to user guidance.
Comment
For an individual user, the computer might be programmed to generate a
special on-line HELP sequence to guide the correction of repeated
errors.
Reference
Provide a capability for recording user requests for HELP.
Exception
There is probably no need to record user browsing of HELP information,
if such a capability is provided.
Comment
HELP records can be used to detect deficiencies in in early system
development, and can be used to improve user guidance in later system
operation. In effect, user requests for HELP might be regarded as a
possible symptom of poor interface design. If HELP requests are
frequent for a particular transaction, then some design improvement may
be needed, in procedures, or prompting for user guidance, or both.
Design change of software supporting user guidance functions may be needed to meet changing operational requirements.
When user guidance requirements may change, which is often the case, provide some means for users (or a system administrator) to make necessary changes to user guidance functions.
Comment
User guidance functions that may need to be changed include those
represented in these guidelines, namely, changes in status information,
routine and error feedback, job aids, and user records.
Comment
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.
Comment
In some applications, it may prove helpful to allow individual users to
reword and/or add their own notes to on-line guidance material, just as
they might annotate paper documentation.
Reference
See also
4.3/12
|
4.4/3
|
4.4/20
|
4.4/27
|
4.5/3
|
4.5/4
|
4.5/5
|
4.5/6
|
4.5/7
When changes are made to interface design, including changes to user guidance functions and on-line documentation, inform users of those changes.
Comment
An on-line "message board" appearing at LOG-ON may suffice to notify
users of current changes. But more extensive measures may be needed,
including corresponding changes to user guidance information, e.g.,
prompts, error messages, HELP displays, etc.
Reference
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents | | | Top |