USER GUIDANCE: Status Information
Automatically or by request, users must have access
to status information on current data processing.
Some indication of system status must be provided
to users at all times. Some applications are with continuously displayed
status; there are two types of status display: by message or by a displayed
clock with a time change which give assurance that the computer link is
still operating. Users might be given information by request, following
a general or specific query also.
In occasions, when the system does not execute user's
query, status information is needed. Otherwise, it takes too much time
for users to test system performance. For this reason, status information
should be provided by design and when system status changes, there must
be a message to attract users' attention to that change.
When users log on to a system, they don't have to
do special things to get a LOG-ON display - all needed prompts for LOG-ON
procedures must be displayed automatically at a user's terminal. Users
will be given information about the operational status of a terminal and
appropriate initial inputs via automatic LOG-ON display.
If a LOG-ON is denied to a user's attempt to log
on, an advisory message should be displayed with information about the
system status and when the system will be available.
Example:
System is down for maintenance until 9:30 am.
System availability should be evaluated and, if
there is a change, evaluation should be updated.
User should be notified, if by some reason the keyboard
is locked, or the terminal is disabled.
Example: If there is a problem, the
user might be notified by disappearance of the cursor from the display,
or by a notable change in the cursor's shape with an auditory signal.
In cases, when user is looking at source documents
for data entry and not at the display or keyboard, an auditory signal is
very helpful.
The currently selected mode must be indicated strongly,
because sometimes the results of user actions depend on different operational
modes.
Example: A change in cursor's shape
will attract user's attention to the change of mode.
If a user is involved in data exchange and/or in
interaction with other users, then a user should be allowed to acquire
status information about other people using the system at the same time.
If there are many other users, it's good for the
user to be allowed to ask if any particular individual is a current user.
When the number of on-line users is big, users should
be allowed to obtain status information in terms of computer responce time.
When task performance requires data exchange and/or
interaction with other systems, user has to be allowed to get status information
for external systems.
Displays with date-time signals must be annotate
because of the need to assess currency of information. Date-time status
might be displayed continuously or periodically on displays that are automatically
updated, or by user request.
Users must have also access to status information
concerning current alarm settings, in terms of dimentions and values with
critical establishment.
USER GUIDANCE: Routine Feedback
In computer systems there has to be ensurance that every
user's input will be followed by a computer's output. The screen should
not be blank when a terminal is in use. There is an exception in occasions
when a user has chose the screen to blank temporarily as a protection the
data from onlookers. But even then some message should appear - like, for
example:
Display temporarily suppressed.
All users' inputs should immediately appear on the
display. Ones, that are not recognised by the computer should be followed
by an error message. The system always should respond to the user - otherwise
the user may suspect system failure with termination of the interaction
sequence. The system response to user entries must be quick also - it
depends on types of transactions. In cases when the system response is
delayed, there must be some indication of transaction status.
After making an entry to the computer, the user
needs feedback to know whether that entry is being processed immediately.
If the system doesn't respond in few seconds to a query that usually
takes no time, it may be disturbing to the user. In cases like this some
intermediate feedback as an advisory message should be provided. This message
might inform user that his query has been accepted but it will take a little
time for it to be executed - it's ideally when the time for the query's
execution is estimated.
Indicating the progress of computer processing is important especially
in cases when response time is uncertain. Displaying time-to-completion
or some other indication of progress will allow users to plan their time
more effectively and to perform other tasks while waiting. In the
matter of fact, messages like 'Wait for processing' are not successful,
because users begin to ignore routine messages that are sometimes true
but sometimes just false alarms.
When computer processing is completed, the user
must be informed and provided guidance for further actions. For long delays,
feedback on processing status before completion may be reassuring to a
user. Such follow-up messages, however, may reserve a special display window
for prompts and advisory messages.
When user requires for printed output, he should
be given an advisory message conferming that a print request is being processed.
A unique identification for each display at the
top of the display frame should be provided. As an exception, interface
designers sometimes may provide unlabeled displays named "free-form" screens
for text entry and other tasks involving display composition by users.
Display identification - a title or an identification code sometimes (in
applications involving menu selection), helps both users and interface
designers to refer to individual displays in discussion and documentation.
There are cases when lists or data tables extend
beyond the capacity of a single display frame. Then the user should be
informed that the display is continued in multiple frames.
Example: There might be an annotation for
incomplete lists at the bottom as
Continued on the next page
Example: For extended data tables, there might
be an annotation as
Page ___ of ___
Example: For scrolled data, displays might
be annotated with the current and concluding locations
Line ___ of ___
It's possible also to conclude completed lists with the annotation
End of list
unless in the case when the list is obviously shorter than available
display space.
When a change in operational mode is established
by a user or a computer action, there should be displayed some continuing
indication of current mode.
Example: Selection of a DELETE mode in text
editing should be followed by a warning signal on the display, for example
by a notable change in cursor shape. This is helpful when the selected
mode is seldom used. In cases when the mode is potentially destructive
(e.g.,DELETE), display of mode selection will help prevent unintended data
loss. For this reason, when a distructive mode is in use, it's helpful
if the mode indication is strongly implemented as some change in cursor's
shape because the cursor is the most surely seen by a user feature on the
display.
Options which are previously selected but still
operative need to be displayed automatically or on user request. This way
a novice user will be helped in learning transaction sequences, and any
user will have no problems dealing with complex transactions. Every operation
that is in a displayed item and is chosen by a user must be highlighted.
This way a user will know that item selection has been accomplished and
will remember exactly what selection has been made. For a selection between
displayed options, the selected one might be brightened. If an error occured
while processing the data the user have to be assured that the system has
returned to its previous status.
USER GUIDANCE:Error feedback
If routine processing is prevented by an error or other
unexpected event, should be provided error feedback. In the case of an
error entry an error message should be displayed to inform user what's
wrong and what can be done about it.
Example: Error messages should be hopeful,
like
Code format not recognised; enter two letters, then three digits.
and not hopeless like
Invalid input.
Error messages should be clearly formulated - users
should not have to translate them. It's important that well designed error
messages will give help to users automatically, where help is most needed.
Error messages should have specific wording.
Example: Error messages should be like
No record for Loan 6342; check number.
and not general like
No record for inquiry.
There should be error messages for appropriate user
tasks.
Example: Error messages should consist of
appropriate wording like
Contract number not recognised; check the file and enter a current number.
and should not be coded like
Entry blocked. Status Flag 4.
Error messages have to be clear for ordinary users
also - not only for computer programmers.
If a user make a wrong choise of a small set of
alternatives that should be entried, the correct alternatives should be
given in answer. Error messages must be brief but informative.
Example: Error messages must be like
Entry must be a number.
and not like
Alphabetic entries are not acceplable because this entry will be processed
automatically.
A user usually knows that he has made a mistake
and when an error message appear it's only a conferming reminder and that's
why quick messages are better than others. If an error message is not enough
for the user, there should be provided an on-line HELP. If it's not enough
again, a user might refer to system documentation to get a coded listing
of possible errors where each message is displayed with an identifying
code for rapid reference to documentation.
Blaming the user, personalizing the computer or
humorous messages have to be avoided - neutral wording must be adopted.
Example: A good example is
Entry must be a number.
and bad examples are
Illegal entry.
I need some digits.
Don't be dumber, use a number.
Error messages should leave the feeling that the
computer is a tool, with limitations that a user must take into account.
If error messages reflect an attitude that the computer establishes legality,
the user may feel resentful; if error messages personalize the computer,
the user may expect it to possess human abilities it doesn't actually possess;
if error messages are filled with humour, any joke will sound intrusive
for a user in user's everyday work.
Users should be allowed to ask for more detailed
explanations of the error. Deeper levels of explanation might be provided
in response to repeated user requests for on-line HELP.
In case when in a combined user entry are detected
multiple errors, the user should be notified even if complete messages
for all errors cannot be displayed together.
Example:
DATE should be numeric.
+ 2 other errors
After an error is detected, the cursor should be
placed in the data field referred to by the displayed error message, with
other error fields highlighted, if needed. The user should be authorized
to ask if there are other error messages also.
If a user repeats an entry error, there should be
some noticeable change in the displayed error message.
Example: One way to do this is to change the
annotation of the message; it may be marked with one or two more asterisk.
If the same error message appears again and again,
the user may be not sure if his revised entry has been accepted or not.
Error messages should be displayed only after a user has completed an entry.
Example: Error message should not be displayed
after wrong data are keyed, but only after a wrong action has been taken.
The system should react quickly to wrong entries,
so that the user's thought process should not to be interrupted.
An error message should be displayed about 2-4 seconds
after the user entry in which the error is detected. It must be taken into
account that longer delays in error feedback may cause user uncertainty
or confusion; it may also cause frustration if the user is already aware
of the error. Shorter delays may cause problems of a different type - immediate
error feedback can be irritating and disconcerting. This is caused of the
real life where the situation is different - an immediate contradiction
is considered rude and every polite listener will pause a few minutes before
saying that you are wrong. If error feedback takes longer than the routine
computer response, then that additional delay may attract user's attention.
A listing and explanation of all error messages
should be include in the system documentation. Documentation of error messages
will permit users to refer to particular messages for fuller explanation.
After an error has occured, the location of a detected
error should be marked by positioning the cursor at that point on the display
- at that data field or command word. User's attention to the wrong entry
will be immediately attracted by displaying the cursor at a non-routine
position.
The erroneous entry should be constantly displayed
as an error message, until corrections are made. The error together with
the error message may help a user understand the specific nature of the
error.
The user should not be made to re-enter the whole
data/command - it's enough to be re-entered only this portion which is
not correct.
A displayed error message should be remove from
the screen as soon as the error is corrected. The immediate removal of
an error message upon error correction will serve as feedback to a user
that the corrected entry is indeed correct.
If , in terms of computer logic, entered data or
command seems doubtful, there should be displayed 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.
In this case the user can be given a range of intermediate
categories between a seemingly correct entry and an outright error.
Before a potentially destructive data or command
to be executed from the computer the user should be required to confirm
it.
User attention will be directed by a requirement
to CONFIRM action to questionable entries and help the user to avoid the
consequences of thoughtless errors. Every system application has a definition
for "potentially destructive".
There should be warning messages to attract special
user attention in extraordinary conditions.
Example: Alarm messages might be marked with
a blinking symbol or colored in red in accompaniment of an auditory signal;
warnings and error messages might be colored in yellow or marked with a
special symbol. This way, even if a user is bisy at routine tasks, he will
pay attention to these special messages.