|
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.
Objectives
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.
Example
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.
Comment
Necessary transactions should be defined in task analysis prior to
software design.
Reference
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.
Example
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.
Example
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.
Exception
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.
Comment
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).
Reference
See also
4.0/24
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.
Comment
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.
Reference
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.
Comment
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.
Comment
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.
Reference
See also
4.4/5
Allow users to control transaction sequencing by explicit action; defer computer processing until an explicit user action has been taken.
Example
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.
Example
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.
Exception
In automated process control applications, emergency conditions may take
precedence over current user transactions, and a computer-generated
warning might interrupt user actions.
Exception
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.
Comment
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.
Comment
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.
Comment
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.
See also
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.
Comment
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.
Comment
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.
Reference
See also
4.0/1
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.
Comment
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.
Reference
See also
4.0/1
Design all displays so that features relevant to sequence control are distinctive in position and/or format.
Comment
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.
Example
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.
Comment
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.
Example
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.
See also
4.0/15
When selecting names for sequence control functions, choose names that are semantically congruent with natural usage, especially for paired opposites.
Example
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.
Comment
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.
Reference
For interpreting user-composed control entries, treat upper and lower case letters as equivalent.
Comment
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.
Example
(Good)
| To delete a paragraph, press |
| DELETE and then PARAGRAPH. |(Bad)
| If a paragraph must be erased, |
| press DELETE and then PARAGRAPH. |
Example
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.
Example
If a user must complete a control form to specify printer settings, the
words used as labels on that form should also be used in any error
messages and HELP displays which may guide that process.
Comment
When selecting or composing control entries, a user will tend to mimic
the vocabulary, format, and word order used in computer displays,
including labels, error messages, HELP displays, etc. If displayed
wording is consistent with required entries, a user will be more likely
to make a correct entry on the first try.
Comment
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.
Reference
See also
2.0/7
|
3.1.7/1
|
4.0/18
Ensure that the computer acknowledges every control entry immediately; for every action by the user there should be some apparent reaction from the computer.
Example
Execution of a requested transaction might produce an immediately
apparent result, as when a user requests NEXT PAGE and the next page is
displayed.
Example
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. |
Example
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. |
Example
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. |
Comment
In particular, the absence of computer response is not an acceptable
means of indicating that a control entry is being processed.
Comment
"Immediately" as used in this guideline must be interpreted in relation
to the response time requirements of different dialogue types.
Reference
See also
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.
Comment
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.
Comment
If the outcome of a completed transaction may imply the need for further
user action, that should be indicated to the user.
Reference
See also
4.2/4
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.
Example
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.
Example
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.
Comment
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.
Reference
See also
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.
Comment
User pacing will let control entries be made in accord with a user's
current needs, attention span, and time available.
Comment
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.
See also
1.0/8
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.
Example
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.
Comment
Interface designers may need to consult with the intended system users
to decide upon appropriate computer response times for different
transactions.
Reference
See also
1.0/4
|
4.2/2
|
4.3/11
Allow users to make control entries as needed; a sequence of control entries should not be delayed by delays in computer response.
Comment
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.
See also
1.0/4
If control entries must be delayed pending computer processing of prior entries, then indicate that delay to the user.
Example
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.
Comment
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.
Comment
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.
Comment
Following control lockout, computer readiness to accept further entries
should be indicated to the user.
See also
4.1/4
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.
Comment
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.
Comment
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.
See also
3.3/6
When several users must interact with the system simultaneously, ensure that control entries by one user do not interfere with those of another.
Comment
This requires careful interface design for applications where joint,
coordinated actions must be made by a group of users.
Reference
See also
6.0/4
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.
Example
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.
Example
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.
Comment
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.
Comment
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.
Reference
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.
Comment
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.
Comment
If computer response time will be slow, consider choosing other dialogue
types, such as command entry.
Reference
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.
Example
In the automated collection of medical history data, a computer might
follow contingent branching logic in posing questions for patients to
answer.
Comment
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.
Comment
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.
Comment
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.
Comment
Do not rely on a user to remember prior answers.
Comment
Another way to request a related series of user entries is to use a
form-filling dialogue rather than question-and-answer.
See also
3.4/3
When questions prompt entry of data from a source document, ensure that the question sequence will match the data sequence in the source document.
See also
1.4/25
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.
Example
Form filling might be an appropriate dialogue type for a computer system
that helped users calculate income tax obligations.
Comment
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.
Reference
Consider form filling as an aid for composing complex control entries.
Example
For a complex data retrieval request, a displayed form might indicate
the various control parameters that could be specified.
Example
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.
Comment
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.
Comment
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.
Reference
See also
3.1.5/4
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.
Example Menu Display
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.
Good Sample Menu Display
|-------------------------------------------------------------|
| 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. |
| < |
|-------------------------------------------------------------|
Bad Sample Menu Display
|-------------------------------------------------------------|
| 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.
Example
Displayed menus are commonly used for function selection in text
processing, in graphic interaction, and a multitude of other
applications.
Comment
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.
Comment
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.
Comment
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.
Reference
Each menu display should permit only one selection by the user.
Comment
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.
Reference
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.
Exception
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.
Exception
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.
Comment
A single-column list format will aid scanning and assimilation of
available options, especially for novice users.
Reference
See also
2.1/20
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.).
Exception
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.
Comment
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.
Reference
See also
1.1/12
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.
Comment
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.
Reference
See also
1.1/13
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.
Example
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.
Comment
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.
Comment
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.
Reference
See also
1.0/9
|
1.1/4
|
3.0/5
|
6.0/9
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.
Comment
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.
Comment
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.
Comment
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: ___. |
Reference
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.
Comment
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.
Reference
See also
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.
Example
(Good) (Bad)
| Organizational Role | | Select: |
| r = Responsible | | r = Responsible |
| a = Assigned | | a = Assigned |
| p = Performing | | p = Performing |
Reference
The wording of menu options should consistently represent commands to the computer, rather than questions to the user.
Example
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? |
Example
For option selection by code entry, the code for each option should be
consistently indicated, as
(Good) | p = Print |
(Bad) | Print? (Y/N) |
Comment
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.
Comment
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.
Reference
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.
Comment
Where appropriate, display cumulative sequences of menu selections in a
command entry area until the user signals entry of a completely composed
command.
Comment
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.
Reference
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.
Example
(Good)
| m = Male |
| f = Female |(Bad)
| 1 = Male |
| 2 = Female |
Exception
Options might be numbered when a logical order or sequence is implied.
Exception
When menu selection is from a long list, the line numbers in the list
might be an acceptable alternative to letter codes.
Comment
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.
Comment
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.
Reference
See also
4.0/13
If letter codes are used for menu selection, use those letters consistently in designating options from one transaction to another.
Example
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 |
Example
As a negative example, the same code should not be given to different
actions
(Bad) | q = Quit | and | q = Queue |
Comment
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.
Example
(Good)
| ENTER organization type: |(Bad)
| ENTER organization type |
Comment
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.
Reference
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.
Comment
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.
Reference
Design a menu to display all options appropriate to any particular transaction.
Exception
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.
Example
Privileged users might be shown more options than regular users.
Example
Displayed file directories should contain only those files actually
available to the particular user.
Example
Offer a CHANGE option only to users who are authorized to make changes
to the particular data being displayed.
Exception
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.
Comment
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.
Reference
When menus are provided in different displays, design them so that option lists are consistent in wording and ordering.
Example
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.
Reference
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.
Example
All control options might be displayed beginning with a special symbol,
such as a plus sign
| +NEXT |, | +BACK |, etc.
Comment
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.
Reference
See also
2.3/8
|
3.1.8/5
|
4.0/8
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.
Example
(Good)
| i = Initiate track |
| m = Move track |
| d = Delete track |(Bad)
| d = Delete track |
| i = Initiate track |
| m = Move track |
Example
See sample displays in this section.
Reference
Format a menu to indicate logically related groups of options, rather than as an undifferentiated string of alternatives.
Example
In vertical listing of options, subordinate categories might be
indented.
Example
See sample displays in this section.
Comment
Logical grouping of menu options will help users learn system
capabilities.
Comment
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.
Reference
See also
4.4/3
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.
Example
See sample displays in this section.
Reference
If menu options are grouped in logical subunits, give each group a descriptive label that is distinctive in format from the option labels themselves.
Example
See sample displays in this section.
Comment
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.
Reference
See also
4.4/4
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.
Example
See sample displays in this section.
Exception
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.
Comment
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.
Reference
See also
4.4/4
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.
Comment
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.
Example
See sample displays in this section.
Comment
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.
Reference
When hierarchic menus are used, design their structure to permit immediate user access to critical or frequently selected options.
Example
See sample displays in this section.
Comment
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.
Comment
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.
Reference
See also
3.1.4/2
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.
Comment
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.
See also
1.4/28
When hierarchic menus are used, display to the user some indication of current position in the menu structure.
Example
See sample displays in this section.
Comment
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.
Reference
See also
4.4/4
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.
Example
See sample displays in this section.
Comment
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.
Reference
See also
4.0/6
When hierarchic menus are used, require users to take only one simple key action to return to the next higher level.
Comment
This action could be considered analogous to the BACKUP option proposed
as an interrupt for sequence control.
Reference
See also
3.3/4
When hierarchic menus are used, require users to take only one simple key action to return to the general menu at the top level.
Example
See sample displays in this section.
Comment
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.
Comment
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.
Comment
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.
Reference
See also
3.0/2
|
3.1.3/12
|
4.4/31
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.
Comment
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.
Reference
See also
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.
Reference
Consider function keys for frequently required control entries.
Example
Commonly used function keys include ENTER, PRINT, NEXT PAGE, PREV PAGE,
OPTIONS, etc.
Comment
When frequently used options are always available via function keys,
they need not be included in displayed menus.
Reference
Consider function keys for interim control entries, i.e., for control actions taken before the completion of a transaction.
Example
Function keys will aid such interim actions as DITTO, CONFIRM, and
requests for PRINT, or HELP, and also interrupts such as BACKUP, CANCEL,
etc.
Comment
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.
Example
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.
Example
As a negative example of confusingly similar labeling, two keys should
not be labeled ON and DN.
Reference
See also
4.0/10
If a key is used for more than one function, always indicate to the user which function is currently available.
Comment
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.
Comment
If key function is specific to a particular transaction, provide an
appropriate guidance message on the user's display to indicate the
current function.
Reference
See also
4.4/13
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.
Example
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.
Example
As a negative example, a function key that moves the cursor should not
be used when shifted to delete displayed data.
Reference
If double (control/shift) keying is used, the logical relation between shifted and unshifted functions should be consistent from one key to another.
Example
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.
Example
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.
Comment
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.
Exception
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.
Reference
See also
4.0/2
When function key activation does not result in any immediately observable natural response, provide users with some other form of computer acknowledgment.
Comment
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.
Comment
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.
Reference
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.
Comment
This practice will speed user selection of function keys.
Reference
See also
4.4/13
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.
Comment
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.
Reference
See also
3.2/10
|
3.5/1
|
6.0/11
When a function is continuously available, assign that function to a single key.
Reference
If a function is assigned to a particular key in one transaction, assign that function to the same key in other transactions.
Example
A SAVE key should perform the same function at any point in a
transaction sequence.
Comment
This becomes a design issue, of course, only in applications where the
set of needed functions does vary somewhat from one transaction to
another.
Reference
When a function key performs different functions in different operational modes, assign equivalent or similar functions to the same key.
Example
A particular key might be used to confirm data changes in one mode,
confirm message transmission in another, etc.
Example
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).
Reference
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.
Example
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.
Comment
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.
Comment
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.
Reference
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.
Reference
See also
4.0/8
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.
See also
6.0/12
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.
Comment
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.
Reference
When command language is used for sequence control, provide a command entry area in a consistent location on every display, preferably at the bottom.
Comment
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).
Reference
See also
2.5/11
|
3.1.3/8
|
4.0/6
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.
Example
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.
Comment
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.
Reference
Design a command language so that its functions are organized in groups (or "layers") for ease in learning and use.
Example
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.
Comment
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.
Comment
Control forms might be used to display default options for complicated
commands.
Reference
Choose command names that are meaningful, and that specifically describe the functions being implemented.
Comment
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.
Comment
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 |
Reference
Choose words for a command language that reflect the user's point of view, and correspond to the user's operational language.
Example
To transfer a file, the assigned command should be something like
TRANSFER, MOVE, or SEND, and not some jargon term like PIP.
Reference
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.
Example
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.
Example
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.
Reference
Design words in a command language so that they are distinctive from one another, and emphasize significant differences in function.
Comment
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.
Comment
Some researchers deal with this question by recommending the use of
specific rather than general command names.
Reference
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.
Example
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.
Comment
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.
Reference
Design a command language with flexibility to permit a user to assign personal names to files, frequently used commands, etc.
Comment
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.
Comment
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.
Comment
Before users can be allowed to adopt their own assigned command names,
the computer must check those names to prevent duplication.
Comment
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.
Reference
See also
3.2/18
|
4.4/18
|
4.4/19
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.
Example
Using a HELP function key, or perhaps simply keying a question mark in
the command entry area, would be satisfactory methods to request
prompting.
Comment
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.
Reference
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.
Comment
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").
Comment
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.
Reference
Allow users to assign a single name to a defined series of commands and then use that named "macro" for subsequent command entry.
Comment
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.
Reference
See also
3.2/18
Allow users to enter commands without any punctuation other than the spaces between words.
Comment
Command entry will be faster and more accurate when spaces are used
rather than any other kind of punctuation.
Reference
See also
3.2/16
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.
Example
A slash (/) might be a good choice.
Comment
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.
Comment
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.
Comment
People cannot readily distinguish one blank space from several, and so
the computer should not impose such a distinction.
See also
1.0/30
Allow users to abbreviate commands.
Example
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.
Comment
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.
Comment
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.
Reference
Allow users to edit erroneous commands with the same techniques that are employed to edit data entries.
Comment
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.
Comment
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.
Comment
For novice users, it may be helpful for the computer to display an
inferred command for user confirmation before execution.
Reference
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.
Example
The words "mail", "post", and "transmit" might be accepted synonyms for
the command "send".
Comment
What synonyms are frequently employed can be determined by analysis of
user error records in prototype testing.
Comment
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.
Comment
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.
Comment
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.
Reference
If a system will have many novice or infrequent users, ensure that the computer can recognize probable alternative forms of command syntax.
Example
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.
Comment
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.
Comment
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.
Comment
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 sam