|
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 |
Sequence control refers to user actions and computer logic that initiate, interrupt, or terminate transactions. Sequence control governs the transition from one transaction to the next. General design objectives include consistency of control actions, minimized need for control actions, minimized memory load on the user, with flexibility of sequence control to adapt to different user needs. Methods of sequence control require explicit attention in interface design, and many published guidelines deal with this topic.
The importance of good design for controlling user interaction with a computer system has been emphasized by Brown, Brown, Burkleo, Mangelsdorf, Olsen and Perkins (1983, page 4-1): One of the critical determinants of user satisfaction and acceptance of a computer system is the extent to which the user feels in control of an interactive session. If users cannot control the direction and pace of the interaction sequence, they are likely to feel frustrated, intimidated, or threatened by the computer system. Their productivity may suffer, or they may avoid using the system at all.
Complete user control of the interaction sequence and its pacing is not always possible, of course, particularly in applications where computer aids are used for monitoring and process control. The actions of an air traffic controller, for example, are necessarily paced in some degree by the job to be done. As a general principle, however, it is the user who should decide what needs doing and when to do it.
A fundamental decision in user interface design is selection of the dialogue type(s) that will be used to implement sequence control. Here "dialogue" refers to the sequence of transactions that mediate user-system interaction. Interface design will often involve a mixture of two or more dialogue types, since different dialogues are appropriate to different jobs and different kinds of users. Recognition of appropriate dialogue types at the outset of system development will facilitate the design of user interface software and help ensure the effectiveness of system operation.
The selection of dialogue types based on anticipated task requirements and user skills seems straightforward, at least for simple cases. Computer-initiated question-and-answer dialogues are suited to routine data entry tasks, where data items are known and their ordering can be constrained; this type of dialogue provides explicit prompting for unskilled, occasional users. Form-filling dialogues permit somewhat greater flexibility in data entry, but may require user training. When data entries must be made in arbitrary order, perhaps mixed with queries as in making airline reservations, then some mixture of function keys and coded command language will be required for effective operation, implying a moderate to high level of user training.
One important aspect of dialogue choice is that different types of dialogue imply differences in system response time for effective operation. In a repetitive form-filling dialogue, for example, users may accept relatively slow computer processing of a completed form. If the computer should take several seconds to respond, a user probably can take that time to set one data sheet aside and prepare another. But several seconds delay in a menu selection dialogue may prove intolerable, especially when a user must make an extended sequence of selections in order to complete an action.
To categorize these differences, the estimated requirement for user training and for system response time is given below for eight dialogue types.
|------------------------------------------------------------| | Required Tolerable Speed of| |Dialogue Type User Training System Response | |------------------------------------------------------------| |Question and Answer Little/None Moderate | |Form Filling Moderate/Little Slow | |Menu Selection Little/None Very Fast | |Function Keys Moderate/Little Very Fast | |Command Language High Moderate/Slow | |Query Language High/Moderate Moderate | |Natural Language Moderate/Little Fast | |Graphic Interaction High Very Fast | |------------------------------------------------------------|
The general requirements estimated in this table may vary, of course, with any specific system design application. As an example, graphic interaction is judged here to require a high degree of user training. That would surely be true of systems providing a full range of graphic functions. But in other applications some simple forms of graphic interaction, such as iconic representation of menu options, might actually serve to reduce the need for user training.
This categorization of dialogue types has been adopted from that proposed by Ramsey and Atwood (1979). Each of these dialogue types is considered in the guidelines presented here. But much pertinent material will be found elsewhere in these guidelines. Thus form filling is considered here as a dialogue type for sequence control, but is treated elsewhere as a means of data entry (Section 1.4) and of data display (Section 2.2). Graphic interaction, considered here as a dialogue type for sequence control, is also treated extensively as a means of data entry (Section 1.6) and data display (Section 2.4).
One might speculate whether some other type of sequence control dialogue, beyond those listed here, could become commonplace in the future. Imagine an application where a user interacts with a so-called "expert" computer system, with the locus of control in query and reply shifting back and forth. Would that represent merely a combination of the various dialogue types considered here? Or should we define some new type of interaction called "mutual consultation" to deal more effectively with that situation? This remains an open question.
Regardless of the dialogue type(s) chosen, providing context, consistency and flexibility will be important for sequence control as it is for other aspects of user interface design. Several guidelines proposed here deal explicitly with the need to define and maintain context for users.
With regard to consistency of sequence control, it should be emphasized that users of information systems regard their computer as a tool necessary to perform a job. As a tool, they expect the computer to perform efficiently, reliably, and predictably. They will not regard the computer as an intriguingly unpredictable toy with which to play games. Elements of surprise that might be entertaining in a game will be frustrating in a tool.
Neither will users want to regard their computer as a puzzle to be solved, a challenging device whose intricacies promise pleasure in mastery. Where a programmer might be intrigued by the problems of instructing a computer to perform a difficult task, an ordinary user of the system may merely be irritated by the complexity of a computer tool. Where smart shortcuts are provided to perform particular tasks in particular ways, the ordinary system user may resent the extra learning involved, and the extra memory load, rather than appreciate the elegance of saving keystrokes.
This argument for consistent control rather than smart shortcuts has been made elsewhere (e.g., Reisner, 1981) but merits continual repetition. Perhaps the most frequent mistake made by designers of user interface software is to provide smart shortcuts instead of consistent control procedures. In every instance, the designer's intent is to help users -- by shortening a particular command, by saving a logically redundant keystroke, or by making sequence control more efficient for a knowledgeable user with perfect memory. But no real users fit that description. Real users depend upon consistent interface design to set practical limits on what they must learn and remember about their computer tools.
In accord with this argument, many of the guidelines proposed here deal in some way with the need to provide consistent logic for sequence control. A consistent interface design -- where actions are all taken in the same way, where displayed control options are all formatted in the same way, where error messages are all worded in the same way, and so on -- may seem dull to its designers. It may even seem dull to some of its users. But it should prove easy to learn. Smart shortcuts, i.e., the special design features that can make particular control actions more efficient, should be provided only as optional extras, not needed by novice users but offering some flexibility for experienced users.
Ideal flexibility would permit experienced users to undertake whatever task or transaction is needed, at any time. Although this may not always prove feasible, the interface designer should try to provide the maximum possible user control of the on-line transaction sequence. As a simple example, a user who is scanning a multipage data display should be able to go either forward or back at will. If interface software only permits stepping forward, so that users must cycle through the entire display set to reach a previous page, that design is inefficient. Users should also be able to interrupt display scanning at any point to initiate some other transaction. Such simple flexibility is relatively easy for the designer to achieve, and indeed is commonly provided.
More difficult are transactions that involve potential change to stored data. Here again users will need flexibility in sequence control, perhaps wishing to back up in a data entry sequence to change previous items, or to cancel and restart the sequence, or to end the sequence altogether and escape to some other task. The interface designer can provide such flexibility through use of suspense files and other special programmed features. That flexibility may require extra effort from the software programmer. But that extra effort is made only once, and is a worthwhile investment on behalf of future users who may interact with their computer system for months or even years.
Of course, flexibility of sequence control has pitfalls. Just as users can make mistakes in data entry, so also will users make mistakes in sequence control. The interface designer must try to anticipate user errors and ensure that potentially damaging actions are difficult to take. In most data entry tasks, for example, simple keying of data items should not in itself initiate computer processing. The user should have to take some further, explicit action to ENTER the data. The interface logic should be designed to protect the user from the consequences of inadvertently destructive actions. Any large-scale erasure or deletion of data, for example, should require some sort of explicit user confirmation, being accomplished as a two-step process rather than by a single keystroke. (This provides a software analogy to the physical barriers sometimes used to protect critical hardware controls from accidental activation.) Some well-designed systems go a step further and permit the user to reverse (UNDO) a mistaken action already taken.
One form of flexibility frequently recommended is the provision of alternate modes of sequence control for experienced and inexperienced users. In a command-language dialogue, optional guidance might be provided to prompt a beginner step by step in the composition of commands, whereas an experienced user might enter a complete command as a single complex input. Some such flexibility in the user interface is surely desirable -- so that the computer can interpret halting, stepwise control inputs, as well as fluent, coherent commands.
More generally, however, it may be desirable to include redundant modes of sequence control in user interface design, perhaps involving combinations of different dialogue types. As an example, menu selection might be incorporated to provide easy sequence control for beginners, but every display frame might also be formatted to include a standard field where an experienced user could enter complete commands more efficiently. Examples of that approach have been provided by Palme (1979).
Another way to provide flexibility in sequence control is through specific tailoring of display formats. Consider, for example, a menu selection dialogue in which sequence control is exercised through lightpen selection among displayed control options. For any particular display frame it might be possible to display just three or four options most likely to be selected by a user at that point in the task sequence, plus a general purpose OPTIONS selection that could be used to call out a display of other (less likely) commands. Thus, on the first page of a two-page display set, one of the likely commands would be NEXT PAGE; but on the second page that command would be replaced by its more likely complement, PREV PAGE.
This approach illustrates two design ideas. The first comes close to being a general principle for sequence control: make the user's most frequent transactions the easiest to accomplish. The second idea is the reliance on context to improve flexibility. These general ideas concerning sequence control are reflected in the specific design guidelines proposed in the following pages.
Consistency of control actions Minimal control actions by user Minimal memory load on user Compatibility with task requirements Flexibility of sequence control
Sequence control refers to user actions and computer logic that initiate, interrupt, or terminate transactions.
Provide flexible means of sequence control so that users can accomplish necessary transactions involving data entry, display, and transmission, or can obtain guidance as needed in connection with any transaction.
In scanning a multipage display the user should be able to go forward or back at will. If user interface design permits only forward steps, so that the user must cycle through an entire display series to reach a previous page, that design is deficient.
Necessary transactions should be defined in task analysis prior to software design.
Ensure that control actions are simple, particularly for real-time tasks requiring fast user response; control logic should permit completion of a transaction sequence with the minimum number of actions consistent with user abilities.
A user should be able to print a display by simple request, without having to take a series of other actions first, such as calling for the display to be filed, specifying a file name, then calling for a print of that named file.
For long, multipage displays, it should be possible to request a particular page directly, without having to take repetitive NEXT PAGE or PREV PAGE actions.
A destructive action will be less likely to be taken by mistake, if it is designed to be different or distinctive, requiring extra user actions.
Shortcuts via direct commands should allow experienced users to by-pass intervening steps that may help beginners. The computer should be programmed to handle automatically any intervening processing that may be required, informing the user what has been done if that becomes necessary (as in the case of a detected error).
Ensure that the means of sequence control are compatible with user skills, permitting simple step-by-step actions by beginners, but permitting more complex command entry by experienced users.
Most systems will have users with varying levels of experience. Any particular user may become more expert with increasing experience, or perhaps less expert after a long period of disuse. Accommodating users of varying expertise will usually require a mixture of different dialogue types, with some means for smooth transition from one mode of dialogue to another. For instance, as a user comes to learn menu codes, s/he might be allowed to enter those codes without necessarily displaying a menu, i.e., those codes might also serve as commands.
Allow users to take initiative and control their interaction with the computer; try to anticipate user requirements and provide appropriate user control options and computer responses in all cases.
In most applications, a user should be able to interrupt or terminate any transaction once it has been initiated (see Section 3.3). Users will sometimes change their minds and decide that an initiated transaction is not what was wanted after all.
Software logic should be "bulletproofed" to anticipate every possible action by a user, no matter how improbable, providing an appropriate computer response for random (or even malicious) inputs as well as for correct entries and likely errors. In particular, a dialogue should never reach a dead end with no further action available to the user. If a user makes an entry inappropriate to current processing logic, the computer should simply display an advisory message that the input cannot be recognized and indicate the available options as to what can be done next.
Allow users to control transaction sequencing by explicit action; defer computer processing until an explicit user action has been taken.
When a user is keying an extended data entry, the computer should not interrupt the user to require immediate correction of any entry error, but instead should wait for the user's ENTER action.
When a user is composing a command to accomplish some transaction, the computer should not interrupt the user by responding as soon as it recognizes a partial entry, but instead should wait for the user's ENTER action.
In automated process control applications, emergency conditions may take precedence over current user transactions, and a computer-generated warning might interrupt user actions.
In routine, repetitive data entry transactions, successful completion of one entry may lead automatically to initiation of the next, as in keying ZIP codes at an automated post office.
If the computer interrupts a user, it pre-empts the initiative in sequence control, in effect forcing the user into an error correction (or some other) sequence conceived by the interface designer, and not necessarily a sequence that would be chosen by the user.
Some interface designers devise computer interruptions that they suppose will help a user, as when they program a computer to complete a partial command automatically as soon as it recognizes the user's intended entry. Many users, however, will find unexpected computer interruptions more disconcerting than helpful, and may become confused at least momentarily as to just what they had intended.
In general, computer detection of problems with current user entries can be negotiated at the conclusion of a transaction, before it is implemented. Nondisruptive alarms or advisory messages can be displayed to report computer monitoring of external events so that the user can choose when to deal with them.
1.0/9 | 1.1/4 | 1.4/1 | 4.0/2 | 6.0/9 | 6.3/5
Ensure that sequence control actions are consistent in form and consequences; employ similar means to accomplish ends that are similar, from one transaction to the next, from one task to another, throughout the user interface.
In particular, there should be some standard, consistent routine for a user to initiate and terminate the transaction sequences that comprise different tasks. Do not require users to learn different command names to terminate different tasks, or remember to terminate one task by command and another by function key.
Interface designers may sometimes be tempted to deviate from consistent control syntax in order to minimize keystrokes in a particular transaction. Or designers may wish to add a new, improved syntax for functions added later in system development. Though such inconsistencies may in each case be intended to help users, they will make all functions more difficult for users to learn.
When designing a sequence of related transactions for some information handling task, employ task analysis to ensure that those transactions will constitute a logical unit or subtask from a user's viewpoint, and to determine what control options users will need at any point.
A logical unit to the user is not necessarily the same as a logical unit of the computer software that mediates the transaction sequence. It might be, for example, that a user should enter ten items of data in a single transaction, because those data all come from one particular paper form, even though the computer will use five of those items for one purpose and five items for another in its subsequent internal processing.
Design all displays so that features relevant to sequence control are distinctive in position and/or format.
Relevant features include displayed options, command entry areas, prompts, advisory messages, and other displayed items (titles, time signals, etc.) whose changes signal the results of control entries.
If the consequences of a control entry will differ depending upon context established by a prior action, then display some continuous indication of current context for reference by the user.
If activating a DELETE key establishes a mode, so that subsequent selection of a PAGE key will erase a page of data rather than simply advancing to display the next page, then some indication of that established DELETE mode should be displayed to the user.
Do not rely on the user always to remember prior actions, nor to understand their current implications.
For instructional material, such as display labeling, on-line guidance and other messages to users, adopt consistent terminology to refer to sequence control.
Various words and phrases might be used, such as "control input", "command entry", "instruction", "request", "function call", etc. The practice adopted in these guidelines is to call general sequence control actions "control entry". More specific terminology is sometimes used here, such as "command entry" for keyed control entries composed by the user, "code entry" for keyed selections from displayed menus, etc.
When selecting names for sequence control functions, choose names that are semantically congruent with natural usage, especially for paired opposites.
If one function name is UP, then DOWN (rather than LOWER, say) should accomplish an opposite function; PULL should be reversed by PUSH; FORWARD by BACKWARD; RIGHT by LEFT; IN by OUT; etc.
A user who learns one function name will assume that s/he can accomplish an opposite function by using a semantically opposite name. One implication is that names for sequence control functions should not be chosen independently. Another implication is that understanding a user's natural vocabulary is important for selecting good function names.
For interpreting user-composed control entries, treat upper and lower case letters as equivalent.
Users find it difficult to remember whether upper or lower case letters are required, and so the interface design should not try to make such a distinction.
Ensure that the wording and required format of control functions is reflected consistently in the wording of user guidance, including all labels, messages, and instructional material.
(Good)
| To delete a paragraph, press | | DELETE and then PARAGRAPH. |
(Bad)
| If a paragraph must be erased, | | press DELETE and then PARAGRAPH. |
When the computer displays a file name, that name should be shown in a format that would be acceptable if the name were included in a command entry; do not display a capitalized name if the computer will not accept a capitalized entry.
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.
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.
Consistency in wording 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.
Ensure that the computer acknowledges every control entry immediately; for every action by the user there should be some apparent reaction from the computer.
Execution of a requested transaction might produce an immediately apparent result, as when a user requests NEXT PAGE and the next page is displayed.
A message might indicate completion of a transaction, as when a user requests printout at a remote facility and the computer displays a confirming message
| AIRFIELD file has been sent to printer. |
A message might indicate that execution is in progress or deferred, as when a user enters data and the computer displays an interim message
| AIRFIELD file is being updated. |
A message might indicate that the control entry requires correction or confirmation, as when a user requests file display and the computer displays an error message
| "AIRFELD" file not recognized. |
In particular, the absence of computer response is not an acceptable means of indicating that a control entry is being processed.
"Immediately" as used in this guideline must be interpreted in relation to the response time requirements of different dialogue types.
1.0/3 | 1.0/12 | 1.0/13 | 4.2/1 | 4.2/3 | 3.1
When processing in response to a control entry is lengthy, give the user some positive indication of subsequent completion, and appropriate related information.
If a user is currently involved in some new transaction, then completion of processing for a prior transaction should be indicated by nondisruptive display of an appropriate advisory message.
If the outcome of a completed transaction may imply the need for further user action, that should be indicated to the user.
Ensure that the results of any control entry are compatible with user expectations, so that a change in the state or value of a controlled element is displayed in an expected or natural form.
A control entry of NEXT PAGE should show the next frame of a current display, and should not jump off to some other internally defined "page" in the computer's data base.
When the completion of a control entry is indicated by a special function key, that key should be labeled ENTER (or some functionally equivalent word) and should result in computer acknowledgment of the entry.
Compatibility between user action and system response is an important concept in human engineering design. Interface designers should not assume that user expectations will match their own. User expectations can be discovered by interview, questionnaire, and/or prototype testing. Where no strong user expectations exist with respect to a particular design feature, then designers can help establish valid user expectations by careful consistency in interface design.
1.0/10 | 1.1/15 | 1.1/19 | 3.0/6 | 4.2/1
Allow users to pace control entries, rather than requiring users to keep pace with computer processing or external events.
User pacing will let control entries be made in accord with a user's current needs, attention span, and time available.
When user-paced control does not seem feasible, as in critical process control applications, reconsider the general approach to task allocation and user interface design, perhaps providing greater system automation to ensure timely response.
Ensure that the speed of computer response to user control entries is appropriate to the transaction involved; in general, the response should be faster for those transactions perceived by a user to be simple.
Computer response to a likely control entry, such as NEXT PAGE, should be within 0.5-1.0 second; response to other simple entries should be within 2.0 seconds; error messages should be displayed within 2-4 seconds.
Interface designers may need to consult with the intended system users to decide upon appropriate computer response times for different transactions.
Allow users to make control entries as needed; a sequence of control entries should not be delayed by delays in computer response.
It is recommended that control delays or lockouts not exceed 0.2 seconds. In some applications, however, longer delay may be tolerable, particularly if that has the effect of reducing variability in computer response time.
If control entries must be delayed pending computer processing of prior entries, then indicate that delay to the user.
If processing delay results in control lockout, that could be signaled by disappearance of the cursor from the display, or perhaps by a notable change in the shape of the cursor, accompanied by an auditory signal.
In some applications it may be desirable to ensure that the keyboard and other control devices are automatically locked until the user can begin a new transaction. This would be true when processing the current transaction will affect the results of subsequent user actions. In other applications, it may be possible to permit users to continue work while previous transactions are still being processed.
Deletion or change of a displayed cursor in itself may not be a sufficient indicator of keyboard lockout. Auditory signals will be particularly helpful to a skilled touch-typist, who may not look at the display when transcribing data entries.
Following control lockout, computer readiness to accept further entries should be indicated to the user.
In situations where control lockout does occur, provide the user with an auxiliary means of control entry, such as a special function key, to abort a transaction causing extended lockout.
Such an interrupt capability will be especially helpful if a user recognizes that an error has been made and wants to stop an unneeded transaction, acting like an UNDO command.
Alternatively, for some transactions it may be helpful to design this interrupt as an END command that stops ongoing processing without canceling it. For example, if a user has asked the computer to scroll ahead in a long file display, that user may simply wish to stop at a certain point rather than returning to the beginning.
When several users must interact with the system simultaneously, ensure that control entries by one user do not interfere with those of another.
This requires careful interface design for applications where joint, coordinated actions must be made by a group of users.
Dialogue types for sequence control must be designed to match the needs of different tasks and different users
Consider task requirements and associated user characteristics when choosing dialogue type(s) and designing sequence control logic.
When untrained users must choose among a fixed set of options (as in the case of automated bank teller machines) labeled function keys might suffice for sequence control; when options may be chosen from a larger set (as in public information systems) menu selection will prove a more efficient dialogue type.
When users must make data and control entries in an arbitrary order, perhaps mixed with queries (as in making flight reservations when talking with a customer), then some mixture of function keys and command entries will be required for effective operation.
A simple dictum is, "Know the user." However, if user characteristics are variable, which is usually the case, then provide a variety of dialogue types based on analysis of task requirements.
Choice of dialogue type(s) is a fundamental decision in interface design. Designers should consider that decision carefully. A poor choice can detract seriously from system usability and will be difficult to change later.
Ensure that the speed of computer response to user entries is appropriate to the type of dialogue; the response to menu selections, function keys, and most entries during graphic interaction should be immediate.
It is generally thought that maximum acceptable delay for computer response to menu selection by lightpen is 1.0 second; for key activation is 0.1 second; for cursor positioning by lightpen (as in graphic line drawing) 0.1 second.
If computer response time will be slow, consider choosing other dialogue types, such as command entry.
Question-and-answer dialogues, where the computer poses questions for a user to answer, are suited to novice users.
Consider question-and-answer dialogues for routine data entry tasks, where data items are known and their ordering can be constrained, where users will have little or no training, and where computer response is expected to be moderately fast.
In the automated collection of medical history data, a computer might follow contingent branching logic in posing questions for patients to answer.
Brief question-and-answer sequences can be used to supplement other dialogue types for special purposes, such as for LOG-ON sequences, or for resolving ambiguous control or data entries.
Where computer response to any single user entry may be slow, then the aggregate time required to process a series of questions and answers may be very slow. In such a case, consider form filling as an alternative dialogue type, where the user can enter a set of related "answers" as a single transaction.
In question-and-answer dialogues, display each question separately; do not require users to answer several questions at once.
A user may become confused in trying to deal with several questions at once, particularly if the number of questions is variable from one transaction to another.
When a series of computer-posed questions are interrelated, display answers to previous questions when those will provide context to help a user answer the current question.
Do not rely on a user to remember prior answers.
Another way to request a related series of user entries is to use a form-filling dialogue rather than question-and-answer.
When questions prompt entry of data from a source document, ensure that the question sequence will match the data sequence in the source document.
Form filling permits a user to enter a series of related data items or control options as a single transaction.
Consider form filling for tasks where some flexibility in data entry is needed, such as the inclusion of optional as well as required items, where users will have moderate training, and/or where computer response may be slow.
Form filling might be an appropriate dialogue type for a computer system that helped users calculate income tax obligations.
Specific recommendations for the design of form-filling dialogues are presented in Section 1.4 for data entry and in Section 2.2 for data display.
Consider form filling as an aid for composing complex control entries.
For a complex data retrieval request, a displayed form might indicate the various control parameters that could be specified.
For a print request, a displayed form might help a user invoke the various format controls that are available.
Consider form filling as a means of displaying default values for the parameters in complex control entries.
Default parameters permit users to compose potentially complicated control entries by relatively simple actions. If defaults have been defined, they should be indicated to users. A displayed form permits a user to review (and confirm or change) default control values, just as a user might review displayed defaults for data entry.
When only a few control parameters are involved, it may be feasible simply to prompt users with guidance messages rather than by displaying a control form.
Ensure that forms for control entry are consistent in format; their design should generally conform to guidelines for the design of data entry forms.
Menu selection permits a user to specify control entries by pointing at displayed options or keying associated codes.
These sample displays represent portions of a large menu of word processing functions. The good menu indicates the current position in a hierarchic menu structure. Different levels in the hierarchic structure are indicated by indentation. This menu offers (bolded) control actions for the most frequently used branch ("document management"), along with options to select other branches in the menu hierarchy. Selection of another branch would show a similar menu display, offering control actions within the selected branch, but without offering the control actions shown here for document management.
The bad menu shows an alternative design for the same functions. The bad menu lacks hierarchic structure, and does not distinguish between control actions and options that merely select further menus. The bad menu would require several successive menu selections in order to take frequent actions.
|-------------------------------------------------------------| | W : WORD PROCESSING MENU GO= General Options | | | | D : DOCUMENT MANAGEMENT | | C = Create | | CF= Free format | | CL= Letter | | CM= Memo | | CW= Wide format | | E = Edit | | P = Print | | CO= COpy | | RE= REname | | DE= DElete | | SP= SPelling check | | I = Index | | | | T = Transferring documents | | L = List processing | | S = Status information | | U = User profile | | | | | | ENTER letter code to select action or another menu. | | < | |-------------------------------------------------------------|
|-------------------------------------------------------------| | C = Create a new document | | | | CW = Create a new wide document | | | | D = Delete a document | | | | E = Edit an existing document | | | | F = Finished -- Exit | | | | I = Index of documents | | | | L = List Processing | | | | M = More Menu selections | | | | P = Print a document | | | | S = Spelling Error Detection | | | | | | | | Type the letters followed by a RETURN | | < | |-------------------------------------------------------------|
This bad menu display violates in some degree several design guidelines in this section: 3.1.3/21 Logical ordering of menu options 3.1.3/22 Logical grouping of menu options 3.1.3/23 Logical ordering of grouped options 3.1.3/24 Labeling grouped options 3.1.3/25 Hierarchic menus for sequential selection 3.1.3/27 Minimal steps in sequential menu selection 3.1.3/28 Easy selection of important options 3.1.3/30 Indicating current position in menu structure 3.1.3/31 Control options distinct from menu branching 3.1.3/34 Return to general menu
Consider menu selection for tasks that involve choice among a constrained set of alternative actions, that require little entry of arbitrary data, where users may have little training, and where computer response is relatively fast.
Displayed menus are commonly used for function selection in text processing, in graphic interaction, and a multitude of other applications.
Lengthy menus are often formatted as separate displays. Task-specific menus, however, can sometimes be incorporated effectively along with data displays, to provide a short list of appropriate control options.
Menu selection is, of course, a generally good means for control entry by untrained users. Menus can be used in conjunction with other dialogue types, depending upon task requirements. Sometimes a menu selection might be clarified by a supplementary question-and-answer dialogue.
If display output is slow, as on a printing terminal or on an electronic display constrained by a low-bandwidth channel, it may be tiresome for a user to wait for display of menu options, especially when selections must be made from several sequentially displayed menus. Under those conditions, experienced users may wish to by-pass menu selections in favor of direct command entry.
Each menu display should permit only one selection by the user.
Novice users will be confused by any more complicated procedure, such as a "Chinese menu" requiring one choice from Column A, one from Column B, etc.
When multiple menu options are displayed in a list, display each option on a new line, i.e., format the list as a single column.
Displaying options in several columns may be considered where shortage of display space dictates a compact format; if there are only a few options, those might be displayed in a single row.
An interesting exception could be made for hierarchic menus, where a high-level menu might be shown in the left column of a display, accompanied by a lower-level menu in the right column whose options change to reflect whatever selection is currently made from the high-level menu.
A single-column list format will aid scanning and assimilation of available options, especially for novice users.
When menu selection is the primary means of sequence control, and especially if choices must be made from extensive lists of displayed control options, permit option selection by direct pointing (e.g., by touch display, lightpen, etc.).
If a capability for direct pointing is not provided (e.g., if pointing involves separate manipulation of a mouse, or cursor positioning by key action), then for long menus it may prove faster to permit menu selection by keying associated option codes.
Pointing directly at a displayed option guarantees good display-control compatibility. Users do not have to note associated option codes and enter them by key actions.
If menu selection is accomplished by pointing, as on touch displays, design the acceptable area for pointing to be as large as consistently possible, including at least the area of the displayed option label plus a half-character distance around that label.
The larger the effective target area, the easier the pointing action will be, and the less risk of error in selecting a wrong option by mistake.
If menu selection is accomplished by pointing, provide for dual activation, in which the first action designates (positions a cursor at) the selected option, followed by a separate second action that makes an explicit control entry.
On a touch display, the computer might display a separate ENTER box that can be touched by a user to indicate that the cursor has been properly positioned.
The two actions of cursor placement and entering should be compatible in their design implementation. If the cursor is positioned by keying, then an ENTER key should be used to signal control entry. If the cursor is positioned by lightpen, provide a dual-action "trigger" on the lightpen for cursor positioning and control entry.
This recommendation for dual activation of pointing assumes that accuracy in selection of control entries is more important than speed. In some applications that may not be true. Interface design will involve a trade-off considering the criticality of wrong entries, ease of recovery from wrong entries, and user convenience in making selections.
When menu selection is a secondary (occasional) means of control entry, and/or only short option lists are needed, then consider accomplishing selection by keyed entry.
An option might be selected by keying an associated code which is included in the displayed menu listing. Alternatively, if menu labels can be displayed near a screen margin, then an option might be selected by pressing an adjacent multifunction key.
When menu selection is accomplished by code entry, provide a standard command entry area (window) where users enter the selected code; place that entry area in a fixed location on all displays.
In a customary terminal configuration, where the display is located above the keyboard, command entry should be at the bottom of the display, in order to minimize user head/eye movement between the display and the keyboard.
Experienced users might key coded menu selections in a standard area identified only by its consistent location and use. If the system is designed primarily for novice users, however, that entry area should be given an appropriate label, such as
| ENTER choice here: ___. |
When a user has selected and entered a control option from a menu, if there is no immediately observable natural response then the computer should display some other acknowledgment of that entry.
An explicit message might be provided. In some applications, however, it may suffice simply to highlight the selected option label (e.g., by brightening or inverse video) when that would provide an unambiguous acknowledgment.
1.1/5 | 3.0/14 | 4.2/1 | 4.2/10
Display an explanatory title for each menu, reflecting the nature of the choice to be made.
(Good) (Bad) | Organizational Role | | Select: | | r = Responsible | | r = Responsible | | a = Assigned | | a = Assigned | | p = Performing | | p = Performing |
The wording of menu options should consistently represent commands to the computer, rather than questions to the user.
For option selection by pointing, a "+" (or some other special symbol) might be used consistently to distinguish a selectable control option from other displayed items, as
(Good) | +PRINT |
(Bad) | PRINT? |
For option selection by code entry, the code for each option should be consistently indicated, as
(Good) | p = Print |
(Bad) | Print? (Y/N) |
Wording options as commands will permit logical selection by pointing, will facilitate the design of mnemonic codes for keyed entry, and will help users learn commands in systems where commands can be used to by-pass menus.
Wording options as commands implies properly that the initiative in sequence control lies with the user. Wording options as questions implies initiative by the computer.
If menu selection is used in conjunction with or as an alternative to command language, design the wording and syntactic organization of displayed menu options to correspond consistently to defined elements and structure of the command language.
Where appropriate, display cumulative sequences of menu selections in a command entry area until the user signals entry of a completely composed command.
This practice will speed the transition for a novice user, relying initially on sequential menu selection, to become an experienced user composing coherent commands without such aid.
If menu selections are made by keyed codes, design each code to be the initial letter or letters of the displayed option label, rather than assigning arbitrary letter or number codes.
(Good)
| m = Male | | f = Female |
(Bad)
| 1 = Male | | 2 = Female |
Options might be numbered when a logical order or sequence is implied.
When menu selection is from a long list, the line numbers in the list might be an acceptable alternative to letter codes.
Several significant advantages can be cited for mnemonic letter codes. Letters are easier than numbers for touch-typists to key. It is easier to memorize meaningful names than numbers, and thus letter codes can facilitate a potential transition from menu selection to command language when those two dialogue types are used together. When menus have to be redesigned, which sometimes happens, lettered options can be reordered without changing codes, whereas numbered options might have to be changed and so confuse users who have already learned the previous numbering.
Interface designers should not create unnatural option labels just to ensure that the initial letter of each will be different. There must be some natural differences among option names, and special two- or three-letter codes can probably be devised as needed to emphasize those differences. In this regard, there is probably no harm in mixing single-letter codes with special multiletter codes in one menu.
If letter codes are used for menu selection, use those letters consistently in designating options from one transaction to another.
As a negative example, the same action should not be given different names (and hence different codes) at different places in a transaction sequence, such as (Bad) | f = Forward | and | n = Next |
As a negative example, the same code should not be given to different actions (Bad) | q = Quit | and | q = Queue |
Different codes for the same action will tend to confuse users and impede learning. The same code for different actions will tend to induce user errors, especially if those actions are frequently taken. However, this practice may be tolerable when selections are seldom taken, and then always taken from labeled alternatives.
Choose a standard symbol for indicating that an entry is required, and reserve that symbol only for that purpose.
(Good)
| ENTER organization type: |
(Bad)
| ENTER organization type |
Some standard prompting symbol, such as the colon shown in the example here, will help to cue users that an input is required. The same symbol should be used to prompt data entries, code entries for menu selections, command entries, etc.
When control entries for any particular transaction will be selected from a small set of options, show those options in a menu added to the working display, rather than requiring a user to remember them or to access a separate menu display.
A complete display of control options will sometimes leave little room for display of data. If an extensive menu must be added to a working data display, provide that menu as a separate window that can temporarily overlay displayed data at user request, but can then be omitted again by further user action.
Design a menu to display all options appropriate to any particular transaction.
A familiar set of general control options (i.e., options that are always implicitly available) may be omitted from individual displays; such general options might be selected by requesting a general menu, or perhaps by function key or command entry.
Design a menu to display only those options that are actually available in the current context for a particular user.
Privileged users might be shown more options than regular users.
Displayed file directories should contain only those files actually available to the particular user.
Offer a CHANGE option only to users who are authorized to make changes to the particular data being displayed.
Menu displays for a system under development might display future options not yet implemented, but such options should be specially marked in some way so that users will understand that they are not available.
If a user selects a displayed option, and is then told that option is not actually available, an undesirable element of unpredictability has been introduced into the interface design. Users may become uncertain and confused about sequence control. Also irritated.
When menus are provided in different displays, design them so that option lists are consistent in wording and ordering.
As a negative example, if | +PRINT | is the last option in one menu, the same print option should not be worded | +COPY | at the beginning of another menu.
If menu options are included in a display that is intended also for data review and/or data entry, which is often a practical design approach, ensure that they are distinct from other displayed information; locate menu options consistently in the display and incorporate some consistent distinguishing feature to indicate their special function.
All control options might be displayed beginning with a special symbol, such as a plus sign
| +NEXT |, | +BACK |, etc.
An interesting variation in menu design is the use of "embedded menus" in which various items within a working display are highlighted in some way to indicate that they can be selected to obtain further information. Thus a text display of encyclopedia information might highlight certain words as cross references to related material, words which can be selected in context rather than from some separate menu listing. Here the selectable items are made visually distinct without being segregated spatially.
List displayed menu options in a logical order; if no logical structure is apparent, then display the options in order of their expected frequency of use, with the most frequent listed first.
(Good)
| i = Initiate track | | m = Move track | | d = Delete track |
(Bad)
| d = Delete track | | i = Initiate track | | m = Move track |
See sample displays in this section.
Format a menu to indicate logically related groups of options, rather than as an undifferentiated string of alternatives.
In vertical listing of options, subordinate categories might be indented.
See sample displays in this section.
Logical grouping of menu options will help users learn system capabilities.
When logical grouping requires a trade-off against expected frequency of use, interface designers should resolve that trade-off consistently for those functions throughout the menu structure.
If menu options are grouped in logical subunits, display those groups in a logical order; if no logical structure is apparent, then display the groups in the order of their expected frequency of use.
See sample displays in this section.
If menu options are grouped in logical subunits, give each group a descriptive label that is distinctive in format from the option labels themselves.
See sample displays in this section.
Although this practice might sometimes seem to waste display space, it will help provide user guidance. Moreover, careful selection of group labels may serve to reduce the number of words needed for individual option labels.
When menu selection must be made from a long list, and not all options can be displayed at once, provide a hierarchic sequence of menu selections rather than one long multipage menu.
See sample displays in this section.
Where a long list is already structured for other purposes, such as a list of customers, a parts inventory, a file directory, etc., it might be reasonable to require the user to scan multiple display pages to find a particular item. Even in such cases, however, an imposed structure for sequential access may prove more efficient, as when a user can make preliminary letter choices to access a long alphabetic list.
Beginning users may learn faster and understand better a menu permitting a single choice from all available options, when those can be displayed on one page. However, a single long menu that extends for more than one page will hinder learning and use. The interface designer can usually devise some means of logical segmentation to permit several sequential selections among few alternatives instead of a single difficult selection among many.
Provide a general menu of basic options as the top level in a hierarchic menu structure, a "home base" to which a user can always return as a consistent starting point for control entries.
Return to the general menu might be accomplished by an OPTIONS function key, or by an explicitly labeled option on every display, or by a generally available implicit option.
When users must step through a sequence of menus to make a selection, design the hierarchic menu structure to minimize the number of steps required.
See sample displays in this section.
This represents a trade-off against the need for logical grouping in hierarchic menus. Minimize the number of hierarchic levels, but not at the expense of display crowding.
When hierarchic menus are used, design their structure to permit immediate user access to critical or frequently selected options.
See sample displays in this section.
It may be desirable in general purpose systems whose use is varied and unpredictable, to permit users to tailor menu design (particularly the general menu) to their individual needs, so that the options used most frequently will appear first for each user.
In designing fixed hierarchic menus, if frequent or critical options do appear logically at lower levels, and so will be less accessible, some design alternatives should be considered. For a critical action, some sort of "panic" option might be included in every menu display, or might be implemented by function key. For frequent actions, some special menu display might be provided as a supplementary shortcut to the designed menu hierarchy.
On separate menu displays (i.e., for menus not included with data displays), when menu selection is by pointing the computer should place the cursor automatically at the first listed option; when menu selection is by code entry, place the cursor in the command entry area.
When menu selection is by code entry, for some applications it may increase the efficiency of sequence control if a null entry is recognized as a default to the first displayed option (assuming that the first option is the most likely choice). If that is done, it should be done consistently.
When hierarchic menus are used, display to the user some indication of current position in the menu structure.
See sample displays in this section.
One possible approach would be to recapitulate prior (higher) menu selections on the display. If routine display of path information seems to clutter menu formats, then a map of the menu structure might be provided at user request as a HELP display.
Format the display of hierarchic menus so that options which actually accomplish control entries can be distinguished from options which merely branch to other menu frames.
See sample displays in this section.
In some applications, it may prove efficient to design "hybrid" menus which display one branch of the menu hierarchy elaborated to include all of its control options while other branches are simply indicated by summary labels. In such a hybrid menu, it will help orient users if options that accomplish control actions are highlighted in some way to distinguish them from options which will result in display of other frames of the hierarchic menu.
When hierarchic menus are used, ensure that display format and selection logic are consistent at every level.
When hierarchic menus are used, require users to take only one simple key action to return to the next higher level.
This action could be considered analogous to the BACKUP option proposed as an interrupt for sequence control.
When hierarchic menus are used, require users to take only one simple key action to return to the general menu at the top level.
See sample displays in this section.
This action could be considered analogous to the REVIEW option proposed as an interrupt for sequence control.
Allow experienced users to by-pass a series of menu selections and make an equivalent command entry directly.
In effect, a command entry might specify an option anywhere in a hierarchic menu structure, permitting a user to jump down several levels, or to move directly from one branch to another.
If a command by-passes only a portion of the complete menu sequence, and so does not yet specify a complete control entry, then display the appropriate next menu to guide completion of the control entry.
For menu selection by code entry, when a series of selections can be anticipated before the menus are displayed, permit a user to combine those selections into a single "stacked" entry.
If necessary, stacked sequential entries might be separated by some character, such as a space, slash, comma or semicolon. It would be preferable, however, if they were simply strung together without special punctuation. Computer interpretation of an unpunctuated string will require letter codes (by preference) or fixed-digit number codes for option selection.
3.1.3/13 | 3.2/13 | 3.2/14 | 3.2/15 | 3.2/16 | 3.2/17 | 3.5/4 | 3.5/5
Function keys permit control entries by direct selection of labeled keys, rather than from displayed menus.
Consider function keys for tasks requiring only a limited number of control entries, or for use in conjunction with other dialogue types as a ready means of accomplishing critical entries that must be made quickly without syntax error.
Consider function keys for frequently required control entries.
Commonly used function keys include ENTER, PRINT, NEXT PAGE, PREV PAGE, OPTIONS, etc.
When frequently used options are always available via function keys, they need not be included in displayed menus.
Consider function keys for interim control entries, i.e., for control actions taken before the completion of a transaction.
Function keys will aid such interim actions as DITTO, CONFIRM, and requests for PRINT, or HELP, and also interrupts such as BACKUP, CANCEL, etc.
Interim control refers to an action taken by a user while working with displayed data, e.g., while still keying data entries or changes, etc. Function keys will aid interim control entries partly because those entries may be frequent. More importantly, however, function keys permit those control entries to be made without special cursor positioning, so that they do not interfere with data entry.
Label each function key informatively to designate the function it performs; make labels sufficiently different from one another to prevent user confusion.
As a negative example of uninformative labeling, cited from an actual design, logging onto a system should not be initiated by a key labeled PANIC.
As a negative example of confusingly similar labeling, two keys should not be labeled ON and DN.
If a key is used for more than one function, always indicate to the user which function is currently available.
If a key is used for just two functions, depending upon defined operational mode, then alternate illuminated labels might be provided on the key to indicate which function is current. In those circumstances, it is preferable that only the currently available function is visible, so that the labels on a group of keys will show what can be done at any point.
If key function is specific to a particular transaction, provide an appropriate guidance message on the user's display to indicate the current function.
Keys controlling frequently used functions should permit single key action and should not require double (control/shift) keying.
If double (control/shift) keying is used, the functions paired on one key should be logically related.
If a particular function key moves the cursor to the upper left corner of a display screen, then that same key when shifted might be used to move the cursor to the bottom right corner of the screen.
As a negative example, a function key that moves the cursor should not be used when shifted to delete displayed data.
If double (control/shift) keying is used, the logical relation between shifted and unshifted functions should be consistent from one key to another.
One consistent logic might be that shifted and unshifted functions are opposite, so that if a particular key moves the cursor forward then that key when shifted would move the cursor backward.
Another possible logic might be that shifted and unshifted functions are related by degree, so that if a particular key deletes a single displayed character then that key when shifted would delete a word.
Consistency in the underlying logic for double keying will help a user to learn the functions associated with different keys.
Ensure that any key will perform its labeled function with a single activation, and will not change its function with repeated activation.
On a very compact keypad, where separate keys are not available to accommodate the range of needed functions, it might be acceptable to group logically related functions on a single key, where repeated key activation would extend the range of control action in a consistent way, e.g., to DELETE character, word, sentence, or paragraph with repeated keystrokes.
When function key activation does not result in any immediately observable natural response, provide users with some other form of computer acknowledgment.
Temporary illumination of the function key will suffice, if key illumination is not used for other purposes such as indicating available options. Otherwise an advisory message should be displayed.
As an interesting variation, user guidance prior to key activation might be provided, where partial depression of a double-contact function key would explain its use, either by voice output ("talking keyboard") or by visual display of a HELP message.
If some function keys are active and some are not, indicate the current subset of active keys in some noticeable way, perhaps by brighter illumination.
This practice will speed user selection of function keys.
When function keys are not needed for any current transaction, temporarily disable those keys under computer control; do not require users to apply mechanical overlays for this purpose.
If a user selects a function key that is invalid for the current transaction, no action should result except display of an advisory message indicating what functions are available at that point.
When a function is continuously available, assign that function to a single key.
If a function is assigned to a particular key in one transaction, assign that function to the same key in other transactions.
A SAVE key should perform the same function at any point in a transaction sequence.
This becomes a design issue, of course, only in applications where the set of needed functions does vary somewhat from one transaction to another.
When a function key performs different functions in different operational modes, assign equivalent or similar functions to the same key.
A particular key might be used to confirm data changes in one mode, confirm message transmission in another, etc.
As a negative example, a key labeled RESET should not be used to save data in one mode, dump data in another, and signal task completion in a third (cited from an actual design).
If the functions assigned to a set of keys change as a result of user selection, give the user an easy means to return to the initial, base-level functions.
In cockpit design, where multifunction keys may be used for various purposes such as navigation or weapons control, the pilot should be able to take a single action to restore those keys quickly to their basic flight control functions.
In effect, multifunction keys can provide hierarchic levels of options much like menu selection dialogues, with the same need for rapid return to the highest-level menu.
For some applications, it may be desirable to automate the return to base-level assignment of multifunction keys, to occur immediately on completion of a transaction and/or by time-out following a period of user inaction. The optimum period for any automatic time-out would have to be determined empirically for each application.
Group function keys in distinctive locations on the keyboard to facilitate their learning and use; place frequently used function keys in the most convenient locations.
The layout of function keys should be compatible with their importance; give keys for emergency functions a prominent position and distinctive coding (e.g., size and/or color); provide physical protection for keys with potentially disruptive consequences.
Command language permits a user to specify desired control actions by composing messages to a computer.
Consider command-language dialogues for tasks involving a wide range of control entries, where users may be highly trained and will use the system frequently.
Command language should also be considered for tasks where control entries may be mixed with data entries in arbitrary sequence, such as when making flight reservations. Such applications will generally require extensive user training.
When command language is used for sequence control, provide a command entry area in a consistent location on every display, preferably at the bottom.
Adjacent to the command entry area there should be a display window reserved for prompting entries, for recapitulation of command sequences (with scrolling to permit extended review), and to mediate question-and-answer dialogue sequences (i.e., prompts and responses to prompts).
Design a command language so that a user can enter commands in terms of functions desired, without concern for internal computer data processing, storage and retrieval mechanisms.
Users should be able to request display of a data file by name alone, without any further specification such as that file's location in computer storage.
Where file names are not unique identifiers, the computer should be programmed to determine whatever further context is necessary for identification. Or perhaps the computer should ask the user to designate a "directory" defining the subset of files of current interest.
Design a command language so that its functions are organized in groups (or "layers") for ease in learning and use.
A user should be able to display the next of a set of received messages with some simple command such as READ NEXT, although a complete command to retrieve any message might include potential specification of which message, from which message list, in which format, to which output device.
The fundamental layer of the language should be the easiest, allowing use of the system by people with little training and/or limited needs. Successive layers of the command language can then increase in complexity for users with greater skills. In effect, simple versions of commands can be recognized by defaulting all of the optional parameters.
Control forms might be used to display default options for complicated commands.
Choose command names that are meaningful, and that specifically describe the functions being implemented.
In some systems, functions are arbitrarily assigned letters as command names, e.g., the letter D preceded by a special key such as CONTROL might be a LOG-OFF command. In such cases, when command names are not real words that describe system functions, users will have difficulty learning to use the system.
If users are permitted to enter abbreviations rather than complete command names, ensure that users are told the command name represented by the abbreviation. Otherwise, a short abbreviation may seem an arbitrary code. For instance, a prompt might read
| To DELETE a record, enter D |
rather than
| To erase a record, enter D |
Choose words for a command language that reflect the user's point of view, and correspond to the user's operational language.
To transfer a file, the assigned command should be something like TRANSFER, MOVE, or SEND, and not some jargon term like PIP.
Design all words in a command language, and their abbreviations, to be consistent in meaning from one transaction to another, and from one task to another.
As a negative example, do not use EDIT in one place, MODIFY in another, UPDATE in a third, all referring to the same kind of action.
Choose wording so that commands will be congruent with one another, following natural language patterns; if one command is UP, its complement should be DOWN; other natural complements include RIGHT-LEFT, FORWARD-BACK, IN-OUT, PUSH-PULL, RAISE-LOWER, etc.
Design words in a command language so that they are distinctive from one another, and emphasize significant differences in function.
In general, do not give different commands semantically similar names, such as SUM and COUNT, or ERASE and DELETE, or QUIT and EXIT. System design abounds with negative examples of similarly named commands which confuse their users: DISPLAY and VIEW (where one command permits editing displayed material and one does not), COMPOSE and CREATE (where one command sends a composed message to an outbox and one leaves a message on the desk), etc. Even experienced users will make errors with such commands.
Some researchers deal with this question by recommending the use of specific rather than general command names.
Design words and abbreviations in a command language with distinctive spelling, so that simple spelling errors will be recognized as such rather than invoking a different command.
As a negative example, if one command name is DELETE, abbreviated DEL, then another command should not be named DELIVER, with an abbreviation of DELR. Instead, ERASE could be substituted for DELETE, or SEND for DELIVER.
When a system has only a few commands, all of those commands should be distinctive. When a system has many commands, it may not be possible to ensure that each is distinctive. In that case, it is important to ensure that any commands which are destructive or time-consuming are made distinctive.
Design a command language with flexibility to permit a user to assign personal names to files, frequently used commands, etc.
Frequently used commands should be easy for a user to enter. Where users differ in the frequency of the commands they use, perhaps the designer should provide for flexibility in command naming. On the other hand, users will not be perfectly consistent in specifying command names, and a carefully designed set of commands might well prove better for some applications.
For users who must move back and forth between different systems with differently defined command languages, some flexibility in command naming might permit those users to establish their own consistent terminology.
Before users can be allowed to adopt their own assigned command names, the computer must check those names to prevent duplication.
A potential risk of increased flexibility is increased confusion, if users forget what names they have specified for commands and data files. The computer should maintain a current index of command and file names for on-line user reference.
Allow users to request computer-generated prompts as necessary to determine required parameters in a command entry, or to determine available options for an appropriate next command.
Using a HELP function key, or perhaps simply keying a question mark in the command entry area, would be satisfactory methods to request prompting.
In some applications it may be desirable to let an inexperienced user simply choose a general "prompted mode" of operation, where any command entry produces automatic prompting of (required or optional) parameters and/or succeeding entry options.
Provide a general list of basic commands, with appropriate command format guidance, that will always be available to serve as a "home base" or consistent starting point for composing command entries.
Such a general list of commands might provide more comprehensive user guidance than is possible when prompting command entry from a working display.
Allow users to key a series of commands at one time ("command stacking").
This practice will allow experienced users to by-pass prompting sequences. Command stacking will reduce the extended memory load on users. Command stacking may also be much faster than separate entry of commands, in systems where input/output processing is overloaded by multiple users.
Allow users to assign a single name to a defined series of commands and then use that named "macro" for subsequent command entry.
In this way users can make a frequent but complicated task easier to accomplish, when the interface designer has failed to anticipate that particular need.
Allow users to enter commands without any punctuation other than the spaces between words.
Command entry will be faster and more accurate when spaces are used rather than any other kind of punctuation.
If command punctuation other than spaces is required, perhaps as a delimiter to distinguish optional parameters or to separate entries in a stacked command, adopt a single standard delimiter symbol for that purpose.
A slash (/) might be a good choice.
Whatever symbol is adopted as a delimiter for command entries should preferably be the same as any delimiter that might be used when making data entries.
Note, however, that even if some single delimiter is specified for consistent use in command punctuation, command entry will be slower and less accurate than if no delimiter at all were required. People do not punctuate reliably.
Treat single and multiple blanks between words as equivalent when processing command entries.
People cannot readily distinguish one blank space from several, and so the computer should not impose such a distinction.
Allow users to abbreviate commands.
If a "P" uniquely identifies a print command (i.e., no other commands start with "P") then a user should be able to enter PRINT, or PR, or P, or any other truncation to initiate printing.
As a corollary, misspelled command entries should also be tolerated, within the limits of computer recognition. The computer can interrogate a user as necessary to resolve ambiguous entries.
If a command language is still changing, as during system development, do not permit variable abbreviation. For the user, an abbreviation that works one day may not work the next. For the software designer, the addition of any new command might require revision of recognition logic for other commands.
Allow users to edit erroneous commands with the same techniques that are employed to edit data entries.
Consistent editing techniques will speed learning and reduce errors.
Where the set of potential command entries is well defined, program the computer to recognize and execute common misspellings of commands, rather than requiring re-entry.
This practice should permit a sizable reduction in wasted keying without serious risk of misinterpretation. The necessary software logic is akin to that for recognizing command abbreviations.
For novice users, it may be helpful for the computer to display an inferred command for user confirmation before execution.
If a system will have many novice or infrequent users, ensure that the computer can recognize a variety of synonyms for each word defined in the command language.
The words "mail", "post", and "transmit" might be accepted synonyms for the command "send".
What synonyms are frequently employed can be determined by analysis of user error records in prototype testing.
Infrequent users may need to relearn command names each time they use the system. For those users, time spent learning commands is not worthwhile considering that they will seldom use those commands.
Command synonyms will be helpful for users who are experienced with different systems. For instance, if users of different editors must occasionally use the same mail system, that mail system might permit synonyms for such common functions as creating and storing documents. If user experience with other systems is known, as when all users of a mail system use one of two editors, designers should include appropriate synonyms. Otherwise, the users themselves might be permitted to tailor command names to employ familiar terminology.
If most system users will gain expertise through frequent use, then documentation and error messages should be provided to help new users learn accepted commands, rather than permitting them to enter command synonyms. When a command language has been carefully designed, with easily distinguishable command names and rule-based abbreviations, frequent users will benefit from time spent learning that command language rather than designing their own language.
If a system will have many novice or infrequent users, ensure that the computer can recognize probable alternative forms of command syntax.
The computer might accept alternative methods of specifying a document, such as "memo 3", "memo #3", "#3", or simply "3"; users might be allowed to use different punctuation and/or to list command modifiers in different orders.
What alternative syntax should be recognized can be determined by analysis of user error records in prototype testing. Recognition of alternative syntax will require more complex parsing of commands, perhaps enlarging by several times that segment of interface software. But that effort will be justified by increased recognition of user entries.
Infrequent users may need to relearn syntax rules each time they use the system. For those users, time spent learning syntax is not worthwhile considering that they will seldom use that syntax.
Recognizing alternative syntax will be helpful for users who are experienced with different systems. For instance, if users of different editors must occasionally use the same mail system, that mail system might permit alternative syntax corresponding to the syntax of those different editors. If user experience with other systems is known, as when all users of a mail system use one of two editors, designers should provide for those different syntax forms. Otherwise, the users themselves might be permitted to tailor command syntax to employ familiar forms.
If most system users will gain expertise through frequent use, then documentation and error messages should be provided to help new users learn accepted syntax, rather than permitting them to use alternative syntax forms. When a command language has been carefully designed to minimize keystrokes and errors, and ensure that similar commands require the same syntax, frequent users will benefit from time spent learning acceptable syntax rather than designing their own language.
If a command entry is not recognized, allow the user to revise the command rather than rejecting the command outright.
Misstated commands should not simply be rejected. Instead, software logic should guide users toward proper command formulation. Preserve the faulty command for reference and modification, and do not require a user to rekey the entire command just to change one part.
If a user makes a command entry error, after the error message has been displayed allow the user to enter a new command; a user should not be forced to correct and complete an erroneous command.
In considering a command entry error message, a user may decide that the wrong command was chosen in the first place, and wish to substitute another command instead.
If a command entry may have disruptive consequences, require the user to review and confirm a displayed interpretation of the command before it is executed.
Query language is a special form of command language that can be used to request information from a computer.
Consider query language dialogue for tasks emphasizing unpredictable information retrieval (as in many analysis and planning tasks), with moderately trained users.
Guidelines for command language design would apply equally to query languages.
Design a query language so that it reflects a data structure or organization perceived by users to be natural.
If a user supposes that all data about a particular person are stored in one place, then the query language should probably permit such data to be retrieved by a single query, even though actual computer storage might carry the various data in different files.
The users' natural perception of data organization can be discovered by survey or experimentation. When users' perceptions do not match the actual structure of computer-stored data, then special care will be needed to preserve the users' viewpoint in query language design.
Establish one single representation of the data organization for use in query formulation, rather than multiple representations.
If different queries will access different data bases over different routes, a user should not necessarily need to know this.
Beginners or infrequent users may be confused by different representational models.
Design a query language so that the wording of a query simply specifies what data are requested; a user should not have to tell the computer how to find the data.
This objective has been called "nonprocedurality", meaning that a user should not have to understand computer procedures for finding data.
Allow users to employ alternative forms when composing queries, corresponding to common alternatives in natural language.
When quantifying a query, a user should be able to employ equivalent forms, such as "over 50," "more than 50," "51 or more."
Design a query language to minimize the need for quantifiers in query formulation.
Negative quantifiers ("no", "none", "zero", etc.) are particularly difficult for users to deal with; other potentially confusing quantifiers include indefinite ("some", "any") and interrogative ("how many") forms.
People have difficulty in using quantifiers. If a query language does require quantifiers, it may be helpful to allow a user to select the desired quantifier from a set of sample queries worded to maximize their distinctiveness.
Design a query language to include logic elements that permit users to link sequential queries as a single entry.
Common links for query formulation include "and", "or", etc.
However a query language should be designed so that it does not require logical links. Some logical quantifiers ("greater than", "less than", etc.) may confuse users. As an alternative to logical linking, it may prove helpful to allow a user to formulate a series of simple queries to narrow the set of retrieved data.
It may help a user to specify logical links accurately if the computer can display a graphical depiction of relations among data sets as those relations are specified during query composition. One researcher recommends Venn diagrams for this purpose.
Design a query language to allow the logical linking of sequential queries.
Logical linking of queries might be accomplished with referential pronouns ("of them", "of those") that will be recognized by the computer in terms of current context.
If a query will result in a large-scale data retrieval, require the user to confirm the transaction or else take further action to narrow the query before processing.
In this regard, it may be helpful to permit a user to set some upper bound for data output, in effect to define what constitutes a "large-scale" retrieval.
It may help a user to decide whether to confirm or modify a pending query, if the user can request a partial display of the currently specified data output.
Natural language recognition might permit a novice user to compose commands without any special training.
Consider using some constrained form of natural language dialogue in applications where task requirements are broad ranging and poorly defined, and where little user training can be provided.
Computer processing of natural language is now being developed on an experimental basis. Current capabilities permit computer recognition of constrained forms of "natural" language, with some limits on vocabulary and syntax. Such constrained natural languages might be considered akin to command languages, with the drawback that they are probably not as carefully designed.
For untrained users, the seemingly familiar form of a (constrained) natural language dialogue may help introduce them to computer capabilities. Such users may manage to do something right from scratch, without having to surmount an initial hurdle of learning more specialized command languages and control procedures. As users gain experience, they may eventually learn more efficient methods of interacting with the system. On the other hand, infrequent computer users may forget whatever training they receive, and so remain novices indefinitely.
Do not consider using unconstrained natural language dialogues for current interface design. Even if a computer can be programmed to recognize unconstrained natural language, it is not clear whether that would help in any defined information handling task. A natural language will often cause confusion in communication among its human users. Something better may be needed to mediate human communication with computers. For applications where task requirements are well defined, other types of dialogue will probably prove more efficient.
Graphic interaction permits a user to select displayed control elements by pointing and other direct manipulation.
For users who must work with graphic data, provide control capabilities as recommended in guidelines for graphic data entry.
Methods of user interaction with graphic data may be so complex that they can be exploited fully only by skilled users. Design recommendations for that specialized kind of graphic interaction are discussed in guidelines pertaining to graphic data entry (Section 1.6).
For casual users, consider providing graphic aids to supplement other types of sequence control.
Advocates recommend simple graphic interaction techniques as an aid for casual users, so that they will not have to learn more complicated methods of sequence control such as command entry. It is that potential use of graphic interaction to simplify control dialogue that is discussed in this section of the guidelines.
When system users have different linguistic backgrounds, consider providing graphic menus which display icons to represent the control options.
A computer-based information system at an international airport might display graphic menus with icons to indicate simple control options.
Here "icon" is intended to mean a small graphic figure which represents a control operation or object.
Some advocates recommend the use of icons whenever possible in place of verbal labels or explanations. They argue that icons can have universal meaning for users with different linguistic backgrounds. Whereas verbal labels may require translation into other languages for different user groups.
Some critics, however, are concerned that the meaning of icons may not be clear. Careful testing may be required to develop a satisfactory set of icons in terms of both legibility and interpretability. And even then it may prove a wise precaution to supplement icons by displaying redundant verbal labels.
One serious drawback of iconic menus is that they will not permit the sequential concatenation of coded menu selections that can ease the transition to command entry as novice users become more experienced. Thus iconic menus are more appropriate for casual rather than continuing use.
If icons are used to represent control actions in menus, display a verbal label with each icon to help assure that its intended meaning will be understood.
Some of the objects and processes dealt with in sequence control are necessarily abstract, and so may be difficult to depict by iconic representation. A redundant verbal label might help make the meaning clear to a user who is uncertain just what a displayed icon means.
One skeptic of iconic representation has cited the problems of early logographic languages, such as Egyptian hieroglyphs, and reminds us, "It took about 2500 years to get rid of the iconic shapes that we are now reviving for computer workstations."
For casual system users, consider providing a capability for direct manipulation of displayed objects as a means of sequence control.
Rather than compose a command or select a function key to file a document, a user might move a displayed icon representing the document to superimpose it on another icon representing a file.
In sequence control by direct manipulation, the techniques for selecting and moving displayed objects would be similar to those described in guidelines for graphic data entry.
An extension of this idea is the use of "embedded menus" in which various items within a working display are highlighted in some way to indicate that they can be selected to obtain further information. Thus a text display of encyclopedia information might highlight certain words as cross references to related material, words which can be selected in context rather than from some separate menu listing.
Advocates recommend direct manipulation as a means of enhancing a user's understanding of control actions, arguing that such manipulation can help clarify the relations among abstract objects and processes. Others recommend manipulation as a simple alternative to learning a command language, arguing that it is easier for a user to see and point than to remember and type.
Critics argue that for experienced users direct manipulation will generally not be as efficient as other methods of sequence control. If direct manipulation is provided, some other more efficient alternative such as command language should also be available for those users who can learn it. Unfortunately, direct manipulation suffers the same drawback as that cited for iconic menus, namely, this mode of graphic interaction does not aid transition to the use of command language as novice users gain experience.
Consider graphic means for displaying to users the context of current control actions.
A graphic representation of the currently selected values of functions, elements and attributes affecting control actions might help reduce user errors in sequence control.
Graphic techniques might be used to display the scope of a proposed control action, such as outlining a passage of text (or other group of display elements) currently selected for deletion.
1.3/7 | 1.6/7 | 1.6/12 | 4.4/13 | 3.4
Consider graphic means for displaying to users prompting aids and other guidance pertaining to current control actions.
A guidance display providing a graphic representation of keypad layout with notes explaining the various key functions might help a novice user to learn the control options available via function keys.
A graphic representation of command syntax might aid language learning by novice users who could be confused by other forms of symbolic notation.
A graphic representation of logical combinations specified in query formulation might help reduce errors in the use of query language.
Transaction selection refers to the control actions and computer logic that initiate transactions.
Allow users to select transactions; computer processing constraints should not dictate sequence control.
A user who wants to interrupt a current activity should not be required by the computer to complete some long sequence of useless transactions.
When a logical sequence of transactions can be determined in advance, interface design might encourage and help a user to follow that sequence. Guidance may be desirable though constraint is not.
Provide a general list of basic control options that will always be available to serve as a "home base" or consistent starting point for control entries.
Return to this starting point can be accomplished by an OPTIONS function key, or by an explicit control option on every display, or by a generally available implicit option.
Such a capability may be helpful even when all dialogue is user-initiated. It might be the general menu for a menu selection dialogue, or might be a standard starting point for composing command entries.
However a user should not be required to return to a display of general options in order to make a control entry. If a user remembers option codes or commands, ideally those control entries could be made from any point in a transaction sequence.
Design the general options list to show control entry options grouped, labeled and ordered in terms of their logical function, frequency and criticality of use, following the general guidelines for menu design.
Make available to users a list of the control options that are specifically appropriate for any transaction.
Transaction-specific options might be listed in the working display if there is space for them. Otherwise, they might be displayed in an overlay window at user request.
Treat control options that are available for almost any transaction as implicit options, which need not be included in a list of transaction-specific options unless they are particularly appropriate to the current transaction. One convenient way to offer implicit options is via function keys, although some experienced users may prefer to select implicit options by command entry.
Provide users with whatever information may be needed to guide control entries at any point in a transaction sequence, by incorporating prompts in a display and/or by providing prompts in response to requests for HELP.
When users will select among displayed options by pointing, place the cursor on the first (most likely) option at display generation.
When users must select options by keyed entry of a corresponding code, place the cursor in the control entry area at display generation.
When users must select options by code entry, display the code associated with each option in a consistent distinctive manner.
In many applications an equal sign can be used to designate option codes, such as
| N = Next page |, | P = Prev page |, etc.
Employ task-oriented wording for control options to reflect the user's view of the current transaction.
When assigning aircraft to a mission, the relevant control option should be ASSIGN rather than ENTER.
Offer users only control options that are actually available for the current transaction.
If certain options are not yet implemented, as during system development, or are not available for any other reason, those should be annotated on the display.
When control is accomplished by keyed command or option code entries, if a default is defined for a null control entry then indicate that default to the user.
| Press ENTER to see more options. |
If a consistent default is adopted throughout interface design, that default need not be explicitly indicated for each individual transaction.
Here the phrase "null control entry" refers to pressing an ENTER key without first keying a command or option code (and without any accompanying data). It does not refer to defaults for optional parameters that might accompany a valid control entry, whose values might be displayed only at user request.
It is not necessary that any defaults be defined for null control entries. In such cases, the computer might simply respond
| ENTER alone is not recognized here. |
The point here is that when defaults are defined, and when they vary from one transaction to another, then users should be informed of the current default logic.
At any step in a defined transaction sequence, if there is only a single appropriate next step then provide a consistent control option to continue to the next transaction.
CONTINUE or NEXT or STEP might be suitable names for this option.
If data entry is involved, then require a user to take an explicit ENTER action to signal data entry, rather than simply selecting CONTINUE.
Allow users to key a sequence of commands or option codes as a single "stacked" control entry.
In particular, allow users to enter stacked entries from any menu so that an experienced user can make any specific control entry without having to view subsequent menus.
Control entry stacking may be helpful when a user is being prompted to enter a series of parameter values, and knows what several succeeding prompts will request and what values to enter.
Control entry stacking will permit a transition from simple step-by-step control entry by novice users, as in menu selection and question-and-answer dialogues, to the entry of extended command-language statements by experienced users; entry stacking is especially helpful in time-shared systems where computer response to any user entry may be slow.
3.1.3/36 | 3.1.5/13 | 3.5/4 | 3.5/5
For control entry stacking, require entries to be in the same order as they would normally be made in a succession of separate control entry actions.
For control entry stacking, accept command names or their abbreviations or option codes just as if those control entries had been made separately.
In some applications, it might prove helpful if the computer were to display its interpretation of a stacked entry for user review and confirmation.
Allow users to stack control entries without any punctuation other than spaces between words or option codes.
Sometimes stacked entries may require specific symbols as delimiters for their interpretation. Careful design of command languages and/or option codes can minimize the need for delimiters to interpret correct entries. Delimiters may still be needed, however, to protect against possible user errors, i.e., stacked commands that have been improperly composed.
Entry will be faster and more accurate when spaces are used rather than any other kind of punctuation.
If punctuation other than spaces is needed to separate entries in a stacked control entry, adopt a single standard symbol for that purpose.
A slash (/) may be a good choice.
Whatever symbol is adopted as a delimiter for control entries should preferably be the same as any delimiter that might be used when making data entries.
Note that even when a standard symbol is consistently used to punctuate stacked entries, entry will be slower and less accurate than if only spaces are used for punctuation.
Provide flexibility in transaction selection by allowing users to assign a single name to a defined series of control entries, and then use that named "macro" for subsequent command entry.
In this way users can make frequently required but complicated tasks easier to accomplish, when the interface designer has failed to anticipate a particular need.
When appropriate to task requirements, allow users to specify transaction timing, i.e., when a requested transaction should start or should be completed, or the periodic scheduling of repeated transactions.
A user might wish to specify that a requested data analysis routine be deferred until some later hour, to ensure that interim updates to the data will be taken into account.
A user might prepare a number of messages for transmittal, but specify that actual transmission be deferred until a later time.
A user might wish to specify that a request for a large printout be deferred to take advantage of reduced overnight rates, but specify a printout deadline to ensure delivery by 0800 the next morning.
A user might wish to specify that summarized briefing material be prepared automatically at 0600 every morning until further notice.
In many applications, of course, users will wish specified transactions performed as quickly as possible. In some applications, however, users may have good reasons to delay initiation (or completion) of transactions.
In some instances, it may be possible to provide appropriate software logic to aid user decisions on transaction timing. For example, if a user requested a bulky printout, the computer might propose overnight printing as an economical alternative, subject to user confirmation.
Allowing users to specify periodic scheduling for routine transactions will tend to reduce the memory load on users, and may help ensure more reliable system performance. If such routine transactions require further user inputs, as when preparing periodic activity reports, computer logic can be devised to prompt users on a timely basis to make the necessary entries.
Interrupt capabilities that permit a user to change ongoing transactions allow flexibility in sequence control.
Provide flexibility in sequence control by allowing a user to interrupt or cancel a current transaction, in ways appropriate to task requirements.
Provision of flexible interrupt capabilities will generally require some sort of suspense file or other buffering in software design. Some such capability, however, will be needed for other reasons, e.g., to allow users to correct mistaken entries, and to permit the computer to require user confirmation of potentially destructive entries.
If different kinds of user interrupt are provided, design each interrupt function as a separate control option with a distinct name.
As a negative example, it would not be good design practice to provide a single INTERRUPT key which has different effects depending upon whether it is pushed once or twice; users would be confused by such an expedient and uncertain about what action has been taken and its consequences.
If appropriate to sequence control, provide a CANCEL option which will have the effect of erasing any changes just made by the user and restoring the current display to its previous version.
In a sequence of related data entries, on several display frames, CANCEL might erase ("clear") data in the current frame as a convenient way to begin keying corrected data, rather than having to erase each data item individually.
The easiest way to implement CANCEL may be simply to regenerate the current display.
If appropriate to sequence control, provide a nondestructive BACKUP option which will have the effect of returning to the display for the last previous transaction.
In a sequence of related data entries, on several display frames, BACKUP might return to the previous frame, where data items could then be erased by CANCEL or could be edited individually.
Such a BACKUP capability will prove feasible only in the software design of well-defined transaction sequences, but will prove helpful when it can be provided.
In some applications, BACKUP might be designed to include cancellation of any interim entries made in a pending transaction. More often, however, it will be better to preserve pending entries without processing. Interface design should be consistent in that regard.
If appropriate to sequence control, provide a nondestructive REVIEW option which will have the effect of returning to the first display in a defined transaction sequence, permitting the user to review a sequence of entries and make necessary changes.
In a sequence of related data entries, on several display frames, REVIEW might return to the first frame, from which data could be reviewed and edited as needed throughout the sequence of frames.
REVIEW is an extension of the BACKUP capability, and is useful only in well-defined transaction sequences such as step-by-step data entry in a question-and-answer dialogue.
In some applications, REVIEW might be designed to include cancellation of any interim entries made in a pending transaction. More often, however, it will be better to preserve pending entries without processing. Interface design should be consistent in that regard.
If appropriate to sequence control, provide a RESTART option which will have the effect of canceling any entries that may have been made in a defined transaction sequence and returning to the beginning of the sequence; when data entries or changes will be nullified by a RESTART action, require users to CONFIRM the RESTART.
In a sequence of related data entries, on several display frames, RESTART might erase all data entries in the sequence and return to the first frame.
A RESTART action combines the functions of REVIEW and CANCEL, and is relevant only to well-defined transaction sequences.
If appropriate to sequence control, provide an END option which will have the effect of concluding a repetitive transaction sequence.
In a repetitive sequence of data entries, where completing one transaction cycles automatically to begin the next, END might break the cycle and permit the user to select other transactions.
END can be implemented by whatever means are appropriate to the dialogue design, i.e., by menu selection, command entry, or function key.
If appropriate to sequence control, provide PAUSE and CONTINUE options which will have the effect of interrupting and later resuming a transaction sequence without any change to data entries or control logic for the interrupted transaction.
A user might wish to interrupt a current task to read an incoming message.
In the interests of data protection, as a "security pause", a user might wish to blank a current display to prevent its being read by some casual visitor.
A "security pause" may have to be implemented quickly and easily, which suggests that this option should be offered via function key.
If a PAUSE option is provided, display some indication of the PAUSE status whenever that option is selected by a user, and prompt the CONTINUE action that will permit resumption of the interrupted transaction.
If appropriate to sequence control, provide a SUSPEND option which will have the effect of preserving current transaction status when a user leaves the system, and permitting resumption of work at that point when the user later logs back onto the system.
In the interests of data protection, a SUSPEND option might require special user identification procedures at subsequent log-on, to prevent unauthorized access to suspended transactions.
If a SUSPEND option is provided, display some indication of the SUSPEND status whenever that option is selected by a user, and at subsequent log-on prompt the user in those procedures that will permit resumption of the suspended transaction.
Context definition by the computer will help ensure that control actions are related to a user's current task.
Design the sequence control software to maintain context for the user throughout the series of transactions comprising a task; where appropriate, display the results of previous entries affecting present actions, and indicate currently available options.
Design the sequence control software to interpret current control actions in the context of previous entries; do not require users to re-enter data.
If data have just been stored in a named file, permit users to request a printout of that file without having to re-enter its name.
If transactions involving contextual interpretation would have destructive effects (e.g., data deletion), then display the interpreted command first for user confirmation.
The software logic supporting contextual interpretation of control entries need not be perfect in order to be helpful. The computer may occasionally have to present an interpreted command for user review and approval. That is still easier for the user than having to specify every command completely in the first place.
Permit users to request a summary of the results of prior entries to help determine present status.
In an aircraft assignment task, there might be a status display showing current commitments of aircraft to missions.
In a text processing application, there might be a status display listing documents already edited and printed in the current work session.
Summarizing prior entries will be particularly helpful in tasks where transaction sequences are variable, where a user must know what was done in order to decide what to do next. Summarizing prior entries may not be needed for routine transactions if each step identifies its predecessors explicitly, although even in those circumstances a user may be distracted and at least momentarily become confused.
When context for sequence control is established in terms of a defined operational mode, remind users of the current mode and other pertinent information.
If text is displayed in an editing mode, then a caption might indicate EDIT as well as the name of the displayed text; if a DELETE mode is selected for text editing, then some further displayed signal should be provided.
Allow users to review any control parameter(s) that are currently operative.
A text processing system might display a variety of parameters to control document printing, including margin widths, line spacing, number of copies, etc., which would represent current default values that a user could review and change when desired.
A system might display a "user profile" that specifies for a particular user which editor will be used, which message system, which general menu, what level of prompting, etc.
A capability for parameter review is helpful even when a user selects all parameters personally. Users will sometimes be forgetful, or may become confused, particularly if their activities are interrupted for any reason.
When a user is performing an operation on some selected display item, highlight that item.
This practice will help avoid error, if a user has misunderstood or perhaps forgotten which item was selected.
Ensure that information displayed to provide context for sequence control is distinctive in location and format, and consistently displayed from one transaction to the next.
Error management by the computer will help prevent user errors and correct those errors that do occur.
Design the interface software to deal appropriately with all possible control entries, correct and incorrect.
If a user selects a function key that is invalid for a particular transaction, no action should result except display of an advisory message indicating what functions are appropriate at that point.
For certain routine and easily recognized errors, such as trying to tab beyond the end of a line, a simple auditory signal ("beep") may be sufficient computer response.
Allow users to edit an extended command during its composition, by backspacing and rekeying, before taking an explicit action to ENTER the command.
Users can often recognize errors in keyed entries prior to final entry.
1.4/2 | 3.1.5/23 | 6.0/10 | 6.3/8
If an element of a command entry is not recognized, or logically inappropriate, prompt users to correct that element rather than requiring re-entry of the entire command.
A faulty command can be retained in the command entry area of the display, with the cursor automatically positioned at the incorrect item, plus an advisory message describing the problem.
If an error is detected in a stacked series of command entries, either consistently execute to the point of error, or else consistently require users to correct errors before executing any command.
It may help the user if the commands are executed to the point of error, or it may not. In most applications, partial execution will probably prove desirable. The point here is that a considered interface design decision should be made and then followed consistently.
If only a portion of a stacked command can be executed, notify the user and provide appropriate guidance to permit correction, completion, or cancellation of the stacked command.
Note that stacked commands can fail because of error in their composition, or for other reasons such as unavailability of required data.
When a user completes correction of an error, whether of a command entry or data entry, require the user to take an explicit action to re-enter the corrected material; use the same ENTER action for re-entry that was used for the original entry.
1.0/9 | 3.0/5 | 6.0/9 | 6.3/11
When a control entry will cause any extensive change in stored data, procedures and/or system operation, and particularly if that change cannot be easily reversed, notify the user and require confirmation of the action before implementing it.
Word the prompt for a CONFIRM action to warn users explicitly of any possible data loss.
(Good)
| CONFIRM deletion of entire AIRFIELD file?? |
(Bad)
| CONFIRM DELETE |
Provide an explicitly labeled CONFIRM function key, different from the ENTER key, for user confirmation of questionable control and data entries.
Confirmation should not be accomplished by pushing some other key twice.
Some interface designers recommend that in special cases confirmation should be made more difficult still, e.g., by keying the separate letters C-O-N-F-I-R-M. Even such extreme measures, however, cannot guarantee that users will not make errors.
3.1.4/3 | 3.1.4/4 | 3.1.4/9 | 3.1.4/14 | 6.0/19
Ensure that any user action can be immediately reversed by an UNDO command.
If a user is overhasty in confirming a destructive action, and realizes the mistake right away (i.e., before taking another action), then an UNDO action might be taken to reverse the damage.
UNDO itself should be reversible, so that a second UNDO action will do again whatever was just undone.
Such an UNDO capability is currently available in many interface designs, and should be provided more generally. Even with an UNDO capability, however, a user may make an irretrievable mistake, if succeeding actions intervene before a prior destructive action is noticed.
When a user requests LOG-OFF, check pending transactions and if any pending transaction will not be completed, or if data will be lost, display an advisory message requesting user confirmation.
| Current data entries have not been filed; | | SAVE if needed, before confirming LOG-OFF. |
A user may sometimes suppose that a job is done before taking necessary implementing actions.
If a data entry transaction has been completed and errors detected, permit users to make corrections directly and immediately.
It is helpful to correct data entry errors at the source, i.e., while a user still has the entry in mind and/or source documents at hand. When a user cannot correct an entry, as when transcribing from a source document that itself contains an error, it may help to allow the user to defer entry of the wrong item. Alternatively, the user might wish to cancel the transaction.
For transactions involving extended entry of multiple items, computer checking might be invoked as each page or section of data is entered.
Allow users to BACKUP easily to previous steps in a transaction sequence in order to correct an error or make any other desired change.
Alarms and alerting signals generated by the computer might be controlled by users in terms of logic and operation.
In monitoring and process control applications, allow users to define the conditions (in terms of variables and values) that will result in computer generation of alarm messages.
The nurse in charge of an intensive care monitoring station might need to specify for each patient that a warning be signaled when blood pressure (a "variable") exceeds or falls below defined levels ("values").
There are some situations where alarm conditions must be predefined by functional, procedural, or perhaps even legal requirements, such as violation of aircraft separation in air traffic control.
Ensure that alarm signals and messages are distinctive for each class of events.
Users should participate in the classification of alarming events, and might help in specifying the desired nature of different alarm signals.
Provide users with a simple means of acknowledging and turning off non-critical alarm signals.
A function key labeled ALARM OFF would suffice for this purpose.
Provide users with a simple means of turning off an auditory alarm, without erasing any displayed message that accompanies the auditory signal.
A function key labeled ALARM RESET would suffice for this purpose.
Turning off an auditory alarm will ensure that any succeeding alarm condition will be able to generate a new auditory signal to attract the user's attention.
If users are required to acknowledge a special or critical alarm in some special way, ensure that such acknowledgment will not inhibit or slow remedial user response to the critical initiating condition.
Do not make acknowledgment of critical alarms too complicated. Help users deal with the cause of an alarm rather than the symptom.
Design change of software supporting control functions may be needed to meet changing operational requirements.
When sequence control requirements may change, which is often the case, provide some means for the user (or a system administrator) to make necessary changes to control functions.
Sequence control functions that may need to be changed include those represented in these guidelines, namely, the types of dialogue that are provided, procedures for transaction selection and interrupt, methods for context definition and error management, and alarm control.
3.0/1 | 3.1.3/28 | 3.1.5/10 | 3.1.5/14 | 3.2/18 | 3.2/19 | 3.6/1
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents | | | Top |