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.