|
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 |
Data entry refers to user actions involving input of data to a computer, and computer responses to such inputs. The simplest kind of data entry consists merely of pointing at something -- selecting an item or designating a position on a computer-generated display. In more complicated modes of data entry, a user may have to control the format of data inputs as well as their contents. Thus questions of format control in text entry/editing and graphic interaction may properly be considered questions of data entry.
Note, however, that user inputs which initiate or interrupt transactions -- such as command entries, or control entries selected from a displayed menu or by function keys -- pose rather different questions of design. Such control entries are discussed in Section 3 of these guidelines.
Data can be entered into a computer in a variety of different ways. Users might designate position or direction by pointing at a display. Users might enter numbers, letters, or more extended textual material by keyed inputs, or in some applications by spoken inputs. Data might be keyed into displayed forms or tables, into constrained message formats, or as free text. In graphic interaction users might draw pictures or manipulate displayed graphic elements. These different types of data entry all merit consideration here.
The computer will also play a role in the data entry process, guiding users who need help, checking data entries to detect errors, and providing other kinds of data processing aids. A designer of user interface software must be concerned about computer processing logic as well as data input by the user.
Data entry is heavily emphasized in clerical jobs, and many other jobs involve data entry to some degree. Because data entry is so common, and because inefficiencies caused by poorly designed data entry transactions are so apparent, many published recommendations for good user interface design deal with data entry questions. Human factors specialists can probably give better advice about data entry than about any other functional area of user interface design.
Data entry requires hardware, and the proper design of input devices has received considerable attention, including concern for standardization of keyboard layouts. Future advances in hardware design may well influence data entry tasks, as suggested by current advocacy of voice input.
But the major need in today's information systems is for improving the logic of data entry, and it is there that design guidance should prove most helpful. Thus the guidelines presented here deal with data entry functions, insofar as possible, without regard to their hardware implementation.
The general objectives of designing data entry functions are to establish consistency of data entry transactions, minimize input actions and memory load on the user, ensure compatibility of data entry with data display, and provide flexibility of user control of data entry. Stated in such general terms, these principles do not provide helpful guidance to designers. Somehow these general ideas must be converted into more specific guidelines.
The process of converting general principles into more detailed guidelines will lead to a considerable proliferation of ideas. With regard to minimizing input actions, one guideline might be that a user should not have to enter the same data twice. Probably every designer knows that, even if it is sometimes forgotten. A related guideline might be that a user should not have to enter data already entered by another user. That seems to make good sense, although one could imagine occasional exceptions when cross validation of data inputs is required.
How can duplicative data entry be avoided in practice? The solution lies in designing the user interface (programming the computer) to maintain context. Thus when a user identifies a data category of interest, say a squadron of aircraft, the computer should be able to access all previously entered data relevant to that squadron and not require the user to enter such data again.
In repetitive data entry transactions the user should have some means of establishing context. One method is to allow users to define default entries for selected data items, in effect telling the computer that those items will stay the same until the default value is changed or removed. If a user enters one item of data about a particular squadron, it should be possible to enter other items thereafter without having to re-identify that squadron.
Context should also be preserved to speed correction of input errors. One significant advantage of on-line data entry is the opportunity for immediate computer validation of user inputs, with timely feedback so that a user can correct errors while the data are still fresh in mind and while documented source data are still at hand. Here the computer should preserve the context of each data entry transaction, saving correct items so that the user does not have to enter those again while changing incorrect items.
Preservation of context is, of course, important in all aspects of user-system interaction, with implications for data display, sequence control and user guidance, as well as for data entry. The importance of context is emphasized again in the discussion of those other functional areas.
Another important design concept is flexibility. It is easy to say that the interface should adapt flexibly to user needs, but the specific means of achieving such flexibility must be spelled out in design guidelines. For data entry functions it is important that the pacing of inputs be controlled flexibly by the user. Tasks where the pacing of user inputs is set by a machine are stressful and error-prone.
Aside from flexibility in pacing, users will often benefit from having some flexible choice in the ordering of inputs. What is needed for interface design is some sort of suspense file to permit flexible ordering of data entries, including temporary omission of unknown items, backup to correct mistaken entries, cancellation of incomplete transactions, etc.
As noted above, users may also benefit from flexibility in defining default options to simplify data entry during a sequence of transactions. Some systems include only those defaults anticipated by the designers, which may not prove helpful to the user in a particular instance. Thus the concept of flexibility is related to maintaining context, and is related also to many other aspects of interface design.
The guidelines proposed here deal with data entry in terms of specific functions, covering different kinds of data entry and different kinds of computer processing support. Some topics, such as "abbreviation", which pertain to all data entry are covered in an initial group of guidelines dealing generally with the subject. A summary of the functional coverage in this section is presented on the next page. These guidelines recommend specific ways to accomplish the fundamental design objectives for data entry.
Objectives
Consistency of data entry transactions
Minimal entry actions by user
Minimal memory load on user
Compatibility of data entry with data display
Flexibility for user control of data entry
Data entry refers to user actions involving input of data to a computer, and computer responses to such inputs.
Ensure that a user need enter any particular data only once, and that the computer can access those data if needed thereafter for the same task or for different tasks.
Comment
In effect, this recommendation urges integrated and flexible software
design so that different programs can access previously entered data as
needed. Requiring re-entry of data would impose duplicative effort on
users and increase the possibility of entry errors.
See also
1.8/9
When data entry is a significant part of a user's task, entered data should appear on the user's primary display.
Example
As a negative example, entry via typewriter is acceptable only if the
typewriter itself, under computer control, is the primary display
medium.
Comment
When the primary display is basically formatted for other purposes, such
as a graphic display for process control, a separate window on the
display may have to be reserved for data entry.
Provide displayed feedback for all user actions during data entry; display keyed entries stroke by stroke.
Exception
For reasons of data protection, it may not be desirable to display
passwords and other secure entries.
Reference
Ensure that the computer will acknowledge data entry actions rapidly, so that users are not slowed or paced by delays in computer response; for normal operation, delays in displayed feedback should not exceed 0.2 seconds.
Example
A key press should be followed by seemingly immediate display of its
associated symbol, or by some other appropriate display change.
Comment
This recommendation is intended to ensure efficient operation in
routine, repetitive data entry tasks. Longer delays may be tolerable in
special circumstances, perhaps to reduce variability in computer
response, or perhaps in cases where data entry comprises a relatively
small portion of the user's task.
Comment
Note that this guideline refers to acknowledgment, rather than final
processing of entries which may be deferred pending an explicit ENTER
action.
Reference
Design the data entry transactions and associated displays so that a user can stay with one method of entry, and not have to shift to another.
Example
Minimize shifts from lightpen to keyboard entry and then back again.
Example
As a negative example, a user should not have to shift from one keyboard
to another, or move from one work station to another, to accomplish
different data entry tasks.
Comment
This, like other guidelines here, assumes a task-oriented user, busy or
even overloaded, who needs efficiency of data entry.
Reference
See also
1.1/14
Where data entry on an electronic display is permitted only in certain areas, as in form filling, provide clear visual definition of the entry fields.
Example
Data entry fields might be underlined, or perhaps highlighted by reverse
video.
Exception
For general text entry of variable (unrestricted) length, no field
delimiters are needed. In effect, keyed text entries can replace
nothing (null characters).
Comment
Display formats with field delimiters provide explicit user guidance as
to the location and extent of data entry fields. Where delimiters
extend throughout an entry field, as in underlining, then any keyed data
entries should replace the delimiter characters on the display.
Reference
See also
1.4/10
In keyed data entry, always allow users to change previous entries if necessary (including displayed default values) by delete and insert actions; if data change is sometimes made by direct character substitution ("typeover"), then that option should also be consistently available.
Example
Form filling may require typeover to replace displayed characters such
as underscores that act as field delimiters.
Comment
Text editing on an electronic display can be handled with or without
typeover; there seems to be no published research on the relative
efficiency of user performance under these two conditions.
Comment
Using typeover, there is some risk of user confusion in replacement of
an old value with a new one, during the transitional period when the
item being changed is seen as a composite beginning with the new value
and ending with the old. Some designers do not permit overtyping for
that reason.
Comment
In some applications it may help the user to key a new entry directly
above or below display of the prior entry it will replace, if that is
done consistently. Here the user can compare values before confirming
entry of the new data and deletion of the old.
Reference
Allow users to pace their data entry, rather than having the pace being controlled by computer processing or external events.
Comment
The timing of user-paced data entry will fluctuate depending upon a
user's momentary needs, attention span and time available. At maximum
speed, user-paced performance is more accurate than that achieved by
machine pacing.
Comment
When user pacing does not seem feasible, as in some real-time process
control applications, reconsider the general approach to task allocation
and interface design.
Reference
Always require a user to take an explicit ENTER action to initiate processing of entered data; do not initiate processing as a side effect of some other action.
Example
As a negative example, returning to a menu of control options should not
by itself result in computer processing of data just keyed onto a
display.
Exception
In routine, repetitive data entry transactions, successful completion of
one entry may automatically lead to initiation of the next, as in keying
ZIP codes at an automated post office.
Comment
Deferring processing until after an explicit ENTER action will permit a
user to review data and correct errors before computer processing,
particularly helpful when data entry is complex and/or difficult to
reverse.
Reference
See also
1.4/1
|
1.4/2
|
3.0/5
|
4.0/2
|
6.0/9
|
6.3/5
Label an ENTER key explicitly to indicate its function.
Example
As a negative example, the ENTER key should not be labeled in terms of
mechanism, such as CR or RETURN or XMIT.
Comment
For a novice computer user, the label should perhaps be even more
explicit, such as ENTER DATA. Ideally, one consistent ENTER label would
be adopted for all systems and so become familiar to all users.
Comment
Some other label might serve as well, if it were used consistently. In
some current systems the ENTER key is labeled GO or DO, implying a
generalized command to the computer, "Go off and do it."
Reference
Require a user to take an explicit action in order to cancel a data entry; data cancellation should not be accomplished as a side effect of some other action.
Example
As a negative example, casual interruptions of a data entry sequence,
such as paging through forms, or detouring to HELP displays, should not
have the effect of erasing partially completed data entries.
Comment
If a requested sequence control action implies a more definite
interruption, such as a LOG-OFF command, or a command to return to a
menu display, then the user should be asked to confirm that action and
alerted to the loss of any data entries that would result.
See also
3.3
Ensure that the computer will acknowledge completion of a data entry transaction with a confirmation message, if data entry was successful, or else with an error message.
Exception
In a sequence of routine, repetitive data entry transactions, successful
completion of one entry might result simply in regeneration of the
initial (empty) data entry display, in order to speed the next entry in
the sequence.
Comment
Successful data entry should not be signaled merely by automatic erasure
of entered data from the display, except possibly in the case of
repetitive data entries. For single data entry transactions, it may be
better to leave entered data on the display until the user takes an
explicit action to clear the display.
Reference
See also
1.0/3
|
3.0/14
|
4.2/1
For a repetitive data entry task that is accomplished as a continuing series of transactions, indicate successful entry by regenerating the data entry display, automatically removing the just-entered data in preparation for the next entry.
Comment
Automatic erasure of entered data represents an exception to the general
principle of control by explicit user action. The interface designer
may adopt this approach, in the interests of efficiency, for data entry
transactions that task analysis indicates will be performed
repetitively.
Comment
In addition to erasure of entered data, a message confirming successful
data entry might be displayed. Such a message may reassure uncertain
users, especially in system applications where computer performance is
unreliable.
Reference
See also
1.0/3
|
3.0/14
|
4.2/1
If a user requests change (or deletion) of a data item that is not currently being displayed, offer the user the option of displaying the old value before confirming the change.
Exception
Expert users may sometimes wish to implement data changes without
displayed feedback, as in "global replace" transactions, accepting the
attendant risk.
Comment
Displayed feedback will help prevent inadvertent data change, and is
particularly useful in protecting delete actions. Like other
recommendations intended to reduce error, it assumes that accuracy of
data entry is worth extra effort by the user. For some tasks, that may
not be true.
See also
6.3/16
For coded data, numbers, etc., keep data entries short, so that the length of an individual item will not exceed 5-7 characters.
Example
Coded data may include such items as badge numbers, payroll numbers,
mail stops, equipment and part numbers, etc.
Comment
For coded data, lengthy items may exceed a user's memory span, inducing
errors in both data entry and data review. The nine-digit ZIP codes
proposed by the US Postal Service will prove difficult to remember
accurately.
Comment
Proper names, meaningful words, and other textual material are not coded
data. Such items can be remembered more easily, and the length
restriction recommended here need not apply.
Reference
When a long data item must be entered, it should be partitioned into shorter symbol groups for both entry and display.
Example
A 10-digit telephone number can be entered as three groups,
NNN-NNN-NNNN.
Reference
See also
2.2/14
Allow optional abbreviation of lengthy data items to minimize data entry keying by expert users, when that can be done without ambiguity.
Comment
Novice and/or occasional users may prefer to make full-form entries,
while experienced users will learn and benefit from appropriate
abbreviations.
Reference
When defining abbreviations or other codes to shorten data entry, choose them to be distinctive in order to avoid confusing similarity with one another.
Example
BOS vs. LAS is good; but LAX vs. LAS risks confusion.
Reference
When defining abbreviations, follow some simple abbreviation rule and ensure that users understand that rule.
Example
Simple truncation is probably the best rule when that can be done
without ambiguity.
Comment
When encoding abbreviations for data entry the user must know what the
rule is. Truncation provides novice users with a straightforward and
highly successful method for generating abbreviations, and is a rule
that can be easily explained. Moreover, truncation works at least as
well, and often better than, more complicated rules, such as word
contraction with omission of vowels.
Comment
Designers of military systems may wish to consult the relevant standard
for abbreviations, MIL-STD-12D.
Reference
Use special abbreviations (i.e., those not formed by consistent rule) only when they are required for clarity.
Comment
Special abbreviations will sometimes be needed to distinguish between
words whose abbreviations by rule are identical, or when abbreviation by
rule forms another word, or when the special abbreviation is already
familiar to system users. If more than 10 percent of abbreviations are
special cases, consider changing the abbreviation rule.
Reference
When an abbreviation must deviate from the consistent rule, minimize the extent of deviation.
Example
In abbreviation by truncation, letters in the truncated form should be
changed one at a time until a unique abbreviation is achieved.
Reference
Make abbreviations the same length, the shortest possible that will ensure unique abbreviations.
Comment
Desirable length will depend upon the vocabulary size of words to be
abbreviated. For a vocabulary of 75 words, 4-letter abbreviations might
suffice. For smaller vocabularies, still shorter abbreviations might be
used.
Reference
When the computer cannot recognize an abbreviated data entry, question the user as necessary to resolve any ambiguity.
Example
This may occur when a user enters a misremembered abbreviation.
Provide prompting for the required formats and acceptable values for data entries.
Example
(Good)
| Vehicle type: __ |
| c = Car |
| t = Truck |
| b = Bus |(Bad) | Vehicle type: __ |
Exception
Prompting may not be needed by skilled users and indeed may hinder
rather than help their performance in situations where display output is
slow (as with Teletype displays); for such users prompting might be
provided as an optional aid.
Comment
Prompting is particularly needed for coded data entries. Menu selection
may be appropriate for that purpose, because menu selection does not
require the user to remember codes but merely to choose among displayed
alternatives. Other methods of prompting include labeling data fields,
such as
| Vehicle type (c/t/b): __ |
and/or providing optional guidance displays.
Reference
See also
1.4/5
|
4.4/7
|
3.1.3
Allow users to enter each character of a data item with a single stroke of an appropriately labeled key.
Example
As a negative example, when a keyboard is intended primarily for numeric
input, with several letters grouped on each key such as a telephone
keypad, do not require a user to make alphabetic entries by double
keying.
Comment
Devices that involve complex keying methods for alphabetic entry (e.g.,
pressing more than one key, simultaneously or successively) require
special user training and risk frequent data entry errors.
Comment
When hardware limitations such as those of a telephone keypad seem to
require double keying of alphabetic entries, try to limit data codes so
that only single-keyed (numeric) entries are required. Alternatively,
consider providing software to interrogate the user to resolve any
ambiguities resulting from single-keyed alphabetic entries.
Reference
Design data entry transactions to minimize the need for shift keying.
Comment
Shift keying can be considered a form of double keying, which imposes a
demand for extra user attention. Keyboard designers should put
frequently used characters where they can be easily keyed. Conversely,
software designers should avoid frequent use of characters requiring
shift keying.
Reference
For coded data entry, treat upper and lower case letters as equivalent.
Comment
For data codes, users find it difficult to remember whether upper or
lower case letters are required, and so the software design should not
try to make such a distinction. For text entry, however, conventional
use of capitalized letters should be maintained.
Allow optional entry or omission of a decimal point at the end of an integer as equivalent alternatives.
Example
An entry of "56." should be processed as equivalent to an entry of "56",
and vice versa.
Comment
If a decimal point is required for data processing, the computer should
probably be programmed to append one as needed. Most users will forget
to do it.
Reference
For general numeric data, allow optional entry or omission of leading zeros as equivalent alternatives.
Example
If a user enters "56" in a field that is four characters long, the
system should recognize that entry rather than requiring an entry of
"0056".
Exception
Special cases may represent exceptions to this rule, such as entry of
serial numbers or other numeric identifiers.
Reference
Treat single and multiple blank characters as equivalent in data entry; do not require users to count blanks.
Comment
People cannot be relied upon to pay careful attention to such details.
The computer should handle them automatically, e.g., ensuring that two
spaces follow every period in text entry (if that is the desired
convention), and spacing other data items in accord with whatever format
has been defined.
See also
3.1.5/17
If a user must enter hierarchic data, where some items will be subordinate to others, provide computer aids to help the user specify relations in the hierarchic structure.
Comment
For simple data structures, question-and-answer dialogues or form
filling may suffice to maintain necessary data relations. For more
complex data structures, such as those involved in graphic data entry,
special techniques may be needed to help users specify the relations
among data entries.
Consider spoken data input only when data entry cannot be accomplished through more reliable methods such as keyed entry or pointing.
Example
Postal workers whose hands are occupied sorting packages might speak ZIP
codes into a speech recognition device rather than keying entries.
Comment
Current speech recognition devices are not well developed and tend to be
error prone. Thus there should be some good reason for choosing speech
input over more conventional data entry methods. Speech input might be
appropriate if a user cannot use his/her hands, perhaps because of a
physical handicap or because the user's hands are needed to accomplish
other tasks. Speech input may also be appropriate if a user does not
have access to a suitable keyboard, as might be the case if data were
being entered by telephone.
Structure the vocabulary used for spoken data entry so that only a few options are needed for any transaction.
Comment
To increase the likelihood that a user's valid entries are correctly
identified by the system, the user's vocabulary should be predictable.
This does not necessarily mean that the vocabulary must be small, though
recognition systems that can only accommodate small vocabularies are
more prevalent and less expensive. A vocabulary is predictable when a
user's choice of inputs at any given time is small, so that the system
will be more likely to make a correct match in interpreting an entry.
Ensure that the spoken entries needed for any transaction are phonetically distinct from one another.
Comment
Words which are easily distinguished by one speech recognition system
may be confused by another. Thus system testing should be performed in
order to determine what sounds a particular system tends to confuse, and
what sounds it can distinguish reliably.
Provide feedback and simple error correction procedures for speech input, so that when a spoken entry has not been correctly recognized by the computer, the user can cancel that entry and speak again.
Comment
Simple error correction is particularly important with spoken data
entry, since speech recognition systems are prone to error except under
carefully controlled conditions.
When speech input is the only form of data entry available, allow alternatives for critical entries, so that if the system cannot recognize an entry after repeated attempts another entry can be substituted.
Example
"Exit" might be defined as an acceptable substitute for "Finished".
Comment
Because speech recognition systems are affected by normal variations in
a user's voice, and by changes in the acoustic environment, a spoken
entry that was accepted yesterday might not be accepted today. Thus for
important entries a user should be able to use an alternative word.
Comment
Spelling a word letter-by-letter is not an acceptable alternative, since
speech recognition systems may have trouble correctly identifying
similar sounding letters.
Provide PAUSE and CONTINUE options for speech input, so that a user can stop speaking without having to log off the system.
Example
A user may wish to stop speaking data for a time in order to answer a
telephone, or to speak with a fellow worker. Users should not have to
log off the system every time they wish to say something that is not
intended as an entry.
Position designation refers to user selection and entry of a position on a display, or of a displayed item.
For position designation on an electronic display, provide a movable cursor with distinctive visual features (shape, blink, etc.).
Exception
When position designation involves only selection among displayed
alternatives, highlighting selected items might be used instead of a
separately displayed cursor.
Comment
When choosing a cursor shape, consider the general content of the
display. For instance, an underscore cursor would be difficult to see
on a display of underscored text, or on a graphical display containing
many other lines.
Comment
If the cursor is changed to denote different functions (e.g., to signal
deletion rather than entry), then each different cursor should be
distinguishable from the others.
Comment
If multiple cursors are used on the same display (e.g., one for
alphanumeric entry and one for line drawing), then each cursor should be
distinguishable from the others.
Reference
Design the cursor so that it does not obscure any other character displayed in the position designated by the cursor.
Example
A block cursor might employ brightness inversion ("reverse video") to
show any other character that it may be marking.
When fine accuracy of positioning is required, as in some forms of graphic interaction, design the displayed cursor to include a point designation feature.
Example
A cross may suffice (like cross-hairs in a telescope), or perhaps a
notched or V-shaped symbol (like a gun sight).
Comment
Precise pointing will also require a cursor control device capable of
precise manipulation. Touch displays, for example, will not permit
precise pointing.
Reference
Require users to take a separate, explicit action, distinct from cursor positioning, for the actual entry (enabling, activation) of a designated position.
Exception
For line drawing or tracking tasks the need for rapid, continuous entry
may override the need to reduce entry errors.
Reference
Ensure that the computer will acknowledge entry of a designated position within 0.2 seconds.
Example
Almost any consistently provided display change will suffice to
acknowledge pointing actions, such as brightening or flashing a selected
character.
Comment
In some applications it may be desirable to provide an explicit message
indicating that a selection has been made.
Reference
See also
1.0/3
|
4.2/2
|
4.2/10
Ensure that the displayed cursor will be stable, i.e., that it will remain where it is placed until moved by the user (or by the computer) to another position.
Comment
Some special applications, such as aided tracking, may benefit from
computer-controlled cursor movement. The intent of the recommendation
here is to avoid unwanted "drift".
Reference
For arbitrary position designation, moving a cursor from one position to another, design the cursor control to permit both fast movement and accurate placement.
Comment
Ideally, when the user moves a pointing device the displayed cursor
should appear to move instantly. Rough positioning should take no more
than 0.5 seconds for full screen traversal. Fine positioning may
require incremental stepping of the cursor, or a control device
incorporating a large control/display ratio for small displacements, or
a selectable vernier mode of control use. For any given cursor control
action, the rate of cursor movement should be constant, i.e., should not
change with time.
Comment
Slow visual feedback of cursor movement can be particularly irritating
when a user is repeatedly pressing a cursor control key, or perhaps
holding the key down. In that case, slow feedback will cause the user
to misjudge location and move the cursor too far.
When cursor positioning is incremental by discrete steps, design the step size of cursor movement to be consistent horizontally (i.e., in both right and left directions), and consistent vertically (in both up and down directions).
Comment
Horizontal and vertical step sizes need not be the same, and in general
will not be.
When character size is variable, design the incremental cursor positioning to vary correspondingly, with a step size matching the size of currently selected characters.
If proportional spacing is used for displayed text, provide computer logic to make necessary adjustments automatically when the cursor is being positioned for data entry or data change.
Example
Automatic proportional spacing is useful for cursor control when editing
text composed for typesetting.
Exception
Manual override may help a user in special cases where automatic spacing
is not wanted.
Comment
Without automatic computer aids, a user probably will not handle
proportional spacing accurately.
For continuous position designation, such as needed for line drawing, provide a continuously operable control (e.g., joystick) rather than requiring a user to take incremental, discrete key actions.
See also
1.6.2
When position designation is the sole or primary means of data entry, as in selection among displayed alternatives, provide cursor placement by direct pointing (e.g., with a touch display or lightpen) rather than incremental stepping or slewing controls (e.g., keys, joystick, etc.).
Reference
In selection of displayed alternatives, design the acceptable area for pointing (i.e., cursor placement) to be as large as consistently possible, including at least the area of the displayed label plus a half-character distance around the label.
Comment
The larger the effective target area, the easier the pointing action
will be, and the less risk of error in selecting the wrong label by
mistake. Some researchers have recommended a target separation on the
display of no less than 6 mm.
Reference
See also
3.1.3/5
When position designation is required in a task emphasizing keyed data entry, provide cursor control by some device integral to the keyboard (function keys, joystick, "cat", etc.).
Comment
Separately manipulated devices (lightpen, "mouse", etc.) will tend to
slow the user.
Reference
See also
1.0/5
Ensure that control actions for cursor positioning are compatible with movements of the displayed cursor, in terms of control function and labeling.
Example
For cursor control by key action, a key labeled with a left-pointing
arrow should move the cursor leftward on the display; for cursor control
by joystick, leftward movement of the control (or leftward pressure)
should result in leftward movement of the cursor; etc.
See also
3.0/16
Employ multiple cursors on a single display only when they are justified by careful task analysis.
Example
Multiple cursors might be useful to mark a user's place when
manipulating data in multiple display windows.
Example
In graphic interaction, one cursor might be used for line drawing and a
different cursor for alphanumeric data entry (labels, etc.).
Comment
Multiple cursors may confuse a user, and so require special
consideration if advocated in USI design.
If multiple cursors are used, make them visually distinctive from one another.
See also
1.1/1
If multiple cursors are controlled by a single device, provide a clear signal to the user to indicate which cursor is currently under control.
If multiple cursors are controlled by different devices, ensure that their separate controls are compatible in operation.
Example
Assume that one cursor is moved upward on a display by forward motion of
a joystick. Then a second cursor should also be moved upward by forward
motion -- perhaps by forward motion of a second joystick or by forward
motion of a thumbwheel or other device.
Reference
See also
3.0/16
When there is a predefined HOME position for the cursor, which is usually the case, define that position consistently on all displays of a given type.
Example
HOME might be in the upper left corner of a text display, or at the
first field in a form-filling display, or at the center of a graphic
display.
Comment
The HOME position of the cursor should also be consistent in the
different "windows" or sections of a partitioned display.
Reference
See also
4.4/16
On the initial appearance of a data entry display, ensure that the cursor will appear automatically at some consistent and useful location.
Example
In a form-filling display, the cursor should be placed in the first
entry field.
Reference
If a cursor must be positioned sequentially in predefined areas, such as displayed data entry fields, ensure that this can be accomplished by simple user action.
Example
Programmable tab keys are customarily used for this purpose.
Comment
Automatic cursor advance is generally not desirable.
Reference
See also
1.4/26
When there are areas of a display in which data entries cannot be made (blank spaces, protected field labels, etc.), make those areas insensitive to pointing actions, i.e., prevent the cursor from entering those areas.
Exception
When a user may have to modify display formats, then this automatic
format protection can be provided as a general default option subject to
user override.
Comment
Automatic format protection will generally make cursor positioning
easier for a user, since the cursor will not have to be stepped through
blank areas, and much routine cursor control can be accomplished with
only casual reference to the display.
Reference
See also
1.4/7
|
2.0/10
|
6.2/5
Ensure that an ENTER action for multiple data items results in entry of all items, regardless of where the cursor is placed on the display.
Comment
A user may choose to move the cursor back to correct earlier data items,
and may not move the cursor forward again. The computer should ignore
cursor placement in such cases.
See also
6.3/7
Direction designation refers to user entry of directional data (azimuth, bearing, heading, etc.) on a display.
When direction designation is based on graphic representation, provide some analog means of entry, such as vector rotation on the display and/or a suitably designed rotary switch.
Example
A rotary switch might be used to indicate heading estimations for
displayed radar trails.
Exception
When approximate direction designation will suffice, for just eight
cardinal points, keyed entry can be used.
Comment
For matching the directional elements in a graphic display, an entry
device providing a visual analog will prove both faster and more
accurate.
Reference
When designation of direction is based on already quantified data, allow keyed entry.
Example
A heading entry might be made from a verbal report in which the
direction has already been expressed numerically.
Text entry refers to the initial entry and subsequent editing of textual material, including messages.
Ensure that display capacity, i.e., number of lines and line length, is adequate to support efficient performance of text entry/editing tasks.
Example
For text editing where the page format of subsequent printed output is
critical, the user's terminal should be able to display full pages of
text in final output form, which might require a display capacity of
50-60 lines or more.
Example
For general text editing where a user might need to make large changes
in text, i.e., sometimes moving paragraphs and sections, a display
capacity of at least 20 lines should be provided.
Example
Where text editing will be limited to local changes, i.e., correcting
typos and minor rewording, as few as seven lines of text might be
displayed.
Comment
A single line of displayed text should not be used for text editing.
During text editing, a user will need to see some displayed context in
order to locate and change various text entries. Displaying only a
small portion of text will make a user spend more time moving forward
and back in a displayed document to see other parts, will increase load
on the user's memory, and will cause users to make more errors.
Reference
See also
1.3/27
Allow users to do at least some simple editing during text entry without having to invoke a separate edit mode.
Example
While entering text, users will need at least some capability for text
selection (by cursor movement) and deletion.
Comment
The intent of this guideline is not to endorse modeless over moded text
editors. In fact, when experienced users perform editing tasks, a moded
editor may offer some advantages. However if a moded editor is
provided, users should be able to do some simple editing such as
correcting typographical errors and making simple word changes without
having to invoke that editor.
Comment
When users will compose text on-line, consider providing a modeless
editor rather than a moded editor. Modeless editors offer some
advantages for text composition, when users will frequently alternate
between text entry and editing.
Reference
See also
2.0/9
For text editing, allow users to move the cursor freely over a displayed page of text to specify items for change, and to make changes directly to the text.
Comment
Free cursor movement and changes made directly to the text are
characteristics usually associated with so-called screen-based editors
and not associated with line- or command-based editors. Screen-based
editors are preferred by users and are potentially more efficient.
Reference
See also
2.7.2/8
If control entries are made by keying onto the display, such as by keyed menu selections or commands, ensure that they will be distinguishable from displayed text.
Example
Keyed control entries might be made only in a reserved window in the
display.
Comment
The intent here is to help ensure that a user will not inadvertently
enter controls as text, or vice versa. If a command entry is keyed into
the body of a text display, perhaps at the end of the last sentence,
then a user cannot be certain whether the computer will interpret the
command as a text entry or as a control entry.
Comment
In applications where the screen cannot display all possible format
features (e.g., special fonts), format codes representing those features
are usually displayed within the text. It is not practical in such
cases to display format codes in a separate window, since a displayed
code must mark the text that will be affected by the code. These codes
should therefore be highlighted in some way to distinguish them from
text.
Comment
One way of avoiding the problem altogether is to use function keys
rather than command entry to control text editing. To provide a general
range of text editing functions, however, many keys will be needed. A
practical design approach might be to adopt double-keying logic for all
keys on a standard (QWERTY) keyboard, where control-F means FILE a
document, control-G means GET a document, etc., and providing
appropriate extra labels for those keys.
See also
1.3/26
Allow users to specify segments of text in whatever units are natural for entry/editing.
Example
For unformatted ("free") text, natural units will be characters, words,
phrases, sentences, paragraphs, and pages; for specially formatted text,
such as computer program listings, allow specification of other logical
units, including lines, subsections, sections, etc.
Allow users to specify units of text as modifiers for control entries.
Example
Consider two alternative control sequences to delete a four-character
word:
(Good) DELETE WORD
(Bad) DELETE DELETE DELETE DELETE
Comment
Control entries, whether accomplished by function key, menu selection,
or command entry, will be easier and more powerful when a user can
specify text in natural units, rather than having to repeat an entry for
each text character.
Comment
When units of text are modifiers for all control entries, the syntax for
those control entries will be easier to learn. Whether a control action
is to MOVE or to DELETE, the modifiers to specify text are the same.
Reference
When text has been specified to become the subject of control entries, highlight that segment of text in some way to indicate its boundaries.
Comment
Text may be specified for various purposes -- for underlining or
bolding, moving, copying, or deleting. Highlighting provides the user
with direct feedback on the extent and content of specified text,
reducing the likelihood of specification errors.
See also
4.2/10
Allow users to move the cursor by specific units of text, as well as one character at a time.
Comment
The time necessary to position a cursor is directly related to the
number of control actions required. Incremental cursor movement by
character will therefore be inefficient when moving the cursor over
large units of text.
Comment
Cursor positioning will be easier if appropriate function keys can be
provided. A SENTENCE key that allows a user to move directly to the
next displayed sentence will be more convenient than some double-keying
logic such as CONTROL-S.
See also
1.1/7
Allow users to specify a string of text and request the computer to advance (or back up) the cursor automatically to the next (or last previous) occurrence of that string.
Comment
Novice users may prefer to move through a displayed document by units of
text, such as by word or paragraph. More experienced users, however,
may sometimes wish to specify cursor placement directly. An automatic
string search capability will generally speed cursor placement in
comparison with incremental positioning, particularly when moving over
large portions of a document.
Comment
Expert users may also wish to incorporate special characters in string
search, including format control characters such as those for tabbing,
bolding, etc.
Reference
Unless otherwise specified by a user, treat upper and lower case letters as equivalent in searching text.
Example
"STRING", "String", and "string" should all be recognized/accepted by
the computer when searching for that word.
Comment
In searching for words, users will generally be indifferent to any
distinction between upper and lower case. The computer should not
compel a distinction that users do not care about and may find difficult
to make. In situations when case actually is important, allow users to
specify case as a selectable option in string search.
Comment
It may also be useful for the computer to ignore such other features as
bolding, underlining, parentheses and quotes when searching text.
When case is important, allow users to specify case as a selectable option in string search.
Example
When searching a document in which all the headings are capitalized, a
user might wish to find a string only when it appears in a heading.
Comment
Users may also wish to specify features such as bolding, underlining,
and quotes when searching text.
When systematic editing changes will be made throughout a long document, consider providing a "global search and replace" capability in which the computer will replace all occurrences of one text string with another.
Comment
Global search and replace could be designed in two different ways. One
user might want the computer to make all changes automatically. Another
user might want to review and confirm each change. Ideally, both
options should be available.
If a global search and replace capability is provided, ensure that each time a string is replaced the case of the new string matches the case of the old string, unless otherwise specified by the user.
Example
If a word is replacing the first word in a sentence, the first letter of
the new word should be capitalized; if it is replacing a word that is
entirely in lower case, then the new word should also be in lower case.
Comment
On occasion, however, a user might wish to replace an erroneous
lower-case word ("Mitre") with a correctly capitalized version
("MITRE").
Provide automatic pagination for text entry/editing, allowing users to specify the page size.
Exception
For short documents, automatic pagination may not be needed.
When automatic pagination is provided, allow users to override that pagination in order to specify page numbers at any point in a document.
Example
A user might wish to number the first page of a document "23", or
perhaps skip a page number in the middle of a document.
Comment
When producing a large document, a user may wish to split it into
several separate text files for convenience in editing, and hence need
to control the page numbering of those component sections. In general,
a user will want flexibility in assembling different computer files to
create a composite document.
When automatic pagination is provided, allow users to specify the number of lines in a paragraph that will be allowed to stand alone at the top or bottom of a page (i.e., the size of "widows" and "orphans"), and to specify any text that should not be divided between two pages, such as inserted lists or tables.
For entry/editing of unformatted text, provide an automatic line break ("carriage return") when text reaches the right margin, with provision for user override.
Comment
For specially formatted text, such as computer program listings, users
may need to control line structure themselves and hence need to override
any automatic line break. Even when entering unformatted text, a user
will sometimes wish to specify a new line at some particular point, if
only for esthetic reasons.
Unless otherwise specified by the user, ensure that entered text is left-justified to maintain constant spacing between words, leaving right margins ragged if that is the result.
See also
2.1/8
In the entry/editing of text, ensure that automatic pagination and line breaks by the computer keep words intact, and introduce hyphenation only where specified by users.
Comment
Where compound words have been hyphenated by a user, the computer might
break the compound after a hyphen, for pagination or line breaks, unless
otherwise specified by the user. Compound words formed with slashes
(e.g., "entry/ editing") might be treated in a similar manner.
See also
2.1/9
Provide easy means for users to specify required format control features during text entry/editing, e.g., to specify margin and tab settings.
Example
One convenient method of margin and tab control is to allow users to
mark settings on a displayed "ruler" that extends the width of a page
and is continuously displayed at the top of the screen.
Comment
Required format features will vary depending on the application. For
instance, font size may be quite important when composing text for
typesetting but unnecessary when editing computer programs. The intent
of this guideline is that all required format features should be easy to
control, and should take priority in interface design. Any format
features which are provided but are optional for the user's task should
not be made easy to use at the expense of required format features.
When text formats must follow predefined standards, provide the standard format automatically; do not rely on users to remember and specify proper formats.
Example
Standard formats might be required for letters, memos, or other
transmitted messages.
See also
5.1/6
When text formats cannot be predicted in advance, allow users to specify and store for future use the formats that might be needed for particular applications.
Example
A special format might be adopted for generating a particular report at
periodic intervals.
Allow users to select and move text segments from one place to another within a document.
Comment
A user should not have to re-enter (i.e., rekey) text that is already
available to the computer.
Comment
One convenient method of allowing the user to both move and copy text is
to provide a "cut and paste" facility in which the "cut" text remains in
a storage buffer and can be "pasted" more than once. For copying, the
user can cut text, paste it back into its original location, and paste
it again at a new location.
See also
1.0/1
Allow users to label and store frequently used text segments, and later to recall (copy into current text) stored segments identified by their assigned labels.
Example
Much text processing involves repetitive elements specific to different
applications, such as signature blocks, technical terms, long names,
formulas or equations.
Ensure that whatever information a user needs for text entry/ editing is available for display, as an annotation to displayed text.
Example
A user might wish to see format control characters, such as tab and
margin settings.
Comment
Required annotation will vary with the application. Some annotation may
be so commonly needed that it should be continuously displayed -- e.g.,
document name, page number, indication of control mode (if any), etc.
Other annotation might be displayed only at user request -- such as
document status (date last changed, last printed, etc.) which might be
displayed in an optional window overlay, and format control characters
which might be visible in an optional display mode.
Ensure that annotations to displayed text are distinguishable from the text itself.
Example
Continuous annotation might be displayed in the top and/or bottom lines
of a page, separated from the text by blank lines; optional annotation
might be displayed in window overlays.
Comment
This recommendation refers to text annotations added by users, such as
marginal notes on printed displays. Other annotation such as format
control characters might be shown in a special display mode where text
has been expanded to permit annotation between lines.
See also
1.3/4
Allow users to display text exactly as it will be printed.
Comment
Accurate display is particularly necessary when the format of printed
output is important, as when printing letters, tables, etc.
Comment
Ideally, text displays should be able to represent all the features that
are provided in printed output, including upper and lower case,
underlining, bolding, subscripting, superscripting, special symbols, and
different styles and sizes of type. When those features are important,
the necessary display capability should be provided.
Comment
For special formatting features that are not frequently used, it may be
sufficient to use extra symbols to note text features that cannot be
directly displayed. In that case, care should be taken that such
annotation does not disturb the spacing of displayed text. This may
require two display modes, one to show text spacing as it will be
printed and the other to show annotations to the text.
Comment
A corollary to this recommendation is that changes made to displayed
text should appear as a user makes them. Some line-based editors show
changes only after a document has been filed and later recalled for
display, which does not represent good user interface design.
Reference
See also
1.3/1
In printing text, allow users to select among available output formats (line spacing, margin size, etc.) and to specify the parts of a document to be printed; do not require that an entire document be printed.
Example
Permit a user to print just those portions of a document that have been
changed, perhaps specifying just the first page, or page 17, or the last
five pages, etc.
Comment
This is particularly important when long documents will be edited. A
user should not be required to print an entire 50-page document just
because of a change to one page.
Inform users concerning the status of requests for printouts.
Example
The computer should acknowledge print requests immediately, and might
provide a subsequent message to indicate when a printout has been
completed if the printer is remote (unobservable) from the user's work
station.
Example
If there is a queue of documents waiting for printout, a user should be
able to get an estimate as to when a particular document will be
printed.
Comment
If a user is responsible for operating a local printer, the computer
might display messages to alert the user of potential malfunctions,
e.g., if its paper supply is exhausted, if the paper is not correctly
loaded, etc.
During text entry/editing, provide an auditory signal whenever it is necessary to draw a user's attention to the display.
Comment
A touch typist entering text from written copy will often not be looking
at the display screen, and therefore may not notice visual indicators of
errors or mode changes unless they are accompanied by auditory signals.
Comment
Note that in a group environment an auditory signal may distract other
workers, and may embarrass the user whose error has been thus
advertised. In such a work setting, consider allowing users to disable
the auditory signal.
See also
2.6/39
When a user is inserting text into a document that has already been paginated, ensure that no text is lost if the user inserts more text than a page can hold.
Comment
It is difficult for a user to keep track of page size, particularly if
the size of the display screen is less than the full page specified for
printed text, which is often the case. A user will often not know when
more text has been inserted into a page than there is room for. The
computer should accommodate text insertions with automatic repagination.
If a DELETE mode is used, highlight any text specified by a user for deletion and require the user to confirm the DELETE action before the computer will process it.
Comment
Requiring a user to confirm actions in DELETE mode is particularly
important when the control entries for cursor positioning (e.g., WORD,
SENTENCE, PARAGRAPH, PAGE) are also used to specify text for deletion,
which is often the case. Users will associate the specification of text
units primarily with cursor positioning, which is the most frequent
action in text editing. In a DELETE mode, after specifying text units
for deletion, a user may press a PARAGRAPH key intending to move to the
next paragraph but accidentally delete the next paragraph. Confirmation
of DELETE actions will tend to prevent such errors.
Comment
An alternative approach to this problem is not to provide a continuing
DELETE mode, but instead require double keying to accomplish deletions.
In a DELETE mode, a user might press a DELETE key followed by unlimited
repetitions of a WORD key (or keys specifying other units of text).
With double keying, the user would have to press DELETE before each
selection of a text unit to be deleted.
See also
1.3/6
|
6.0/18
|
6.3/19
Design text editing logic so that any user action is immediately reversible.
Example
If a user centers a heading and then decides it would look better flush
against the left margin, an UNDO action should reverse the centering and
move the heading back to its original location.
Example
If a user underlines a paragraph of text and then decides it should be
in all capital letters instead, an UNDO action should reverse the
underlining. The user should not be required to delete the paragraph
and retype it just to erase the underscoring.
Comment
Reversible actions are particularly important in a text editing
environment because text formatting often involves experimentation with
features such as underscoring, bolding, and spacing. If users know that
they can reverse whatever they do, they will feel more free to delete
text and experiment with formatting features.
Comment
An UNDO capability is currently available in some interface designs. In
some applications, however, this capability is provided through the use
of an UNDO key which can only reverse the most recent control action.
For text editing, users must be able to reverse such formatting features
as centering and bolding at any time. Therefore, if control actions are
to be made reversible, an UNDO action should be able to reverse more
than the most recent command, perhaps by requiring the user to specify
which command to undo, and/or to place the cursor at the location of the
format feature that is to be reversed.
Comment
When text segments have been deleted, it should be possible to retrieve
more than the most recent deletion. Some systems do this by storing all
deletions in a special file. Deleted text which the user wishes to
retrieve can then be moved from the deletion file to the file in which
the user is presently working.
Reference
When a user signals completion of document editing, allow the user to confirm that changes should be made to the original document, or else to choose alternative options.
Comment
A user will generally wish to replace the original document with its
edited version. However, sometimes a user may decide that editing
mistakes have been made, and wish to discard the new version while
saving the original. Or a user might wish to save the new version as a
separate document, while saving the original unchanged. Such decisions
can be made best at the end of an editing session, when the user knows
what has been accomplished, rather than before a session is begun.
Comment
During text editing, the computer should always retain a copy of the
original document until the user confirms that it should be changed.
The original document should not be changed automatically as the user
enters each editing change.
Data forms permit entry of predefined items into labeled fields of specially formatted displays.
Good and Bad Examples
These sample displays represent a possible form for entry and review of
visa application data. In the good form, data entries are bolded to
help distinguish them from labels and field delimiters. Fields are
ordered consistently in relation to a (supposed) paper application form,
and formatted to facilitate both data entry and data review.
The bad display is annotated to indicate violations of several of the design guidelines proposed here for data forms. The data entries in the bad display were invented to suggest what a user might have produced, if confused by inadequate labeling and the absence of field delimiters.
Good Sample Data Form
|-----------------------------------------------------|
| VISA APPLICATION |
| |
| NAME: Jones, Andrew David_______ VISA: 356 478 |
| LAST, FIRST MIDDLE |
| |
| BIRTH COUNTRY: UK DATE: 3/22/25 |
| MM DD YY |
| |
| NATIONALITY: UK PASSPORT: Z196284__ |
| |
| ADDRESS: 5 Fairview Lane_________________ |
| Loughborough, LE11 3RG__________ |
| England_________________________ |
| |
| OTHER TRAVELERS ON THIS VISA |
| BIRTH |
| NAME: COUNTRY: DATE: |
| Jones, Sandra Jean________ UK 10/11/28 |
| Jones, Cynthia Leigh______ FR 6/12/68< |
| __________________________ __ __/__/__ |
| __________________________ __ __/__/__ |
| LAST, FIRST MIDDLE MM DD YY |
| |
| * Press ENTER when done. |
|-----------------------------------------------------|
Bad Sample Data Form
|-----------------------------------------------------|
| Name Andrew D. Jones Visa Number 356478 |
| |
| Birthplace London Nationality English |
| |
| Passport Z196284 Birthdate Mar. 22, |
| |
| Address 1925 |
| 5 Fairview Lane, Loughborough, L |
| E11 3RG, England |
| |
| Other travelers on this visa |
| Traveler's Name Date of Birth - Place |
| Sandra J. Jones Oct. 11, - 1928 |
| Birmingham |
| Cynthia L. Jones June 12, - 1968 |
| Paris, France# |
| |
| |
| |
| |
| |
| |
| |
| Press ENTER when done |
|-----------------------------------------------------|
This bad data form display violates in some degree several design guidelines in this section: 1.4/3 Minimal use of delimiters 1.4/6 Consistent labeling 1.4/10 Marking field boundaries 1.4/11 Prompting field length 1.4/15 Explicit tabbing to data fields 1.4/16 Distinctive label format 1.4/18 Label punctuation as entry cue 1.4/19 Informative labels 1.4/20 Data format cueing in labels 1.4/25 Form compatible with source documents This bad data form also violates various design guidelines pertaining to data display, as noted at the end of Section 2.2.
In a form-filling dialogue, when a user is entering logically related items, require just one explicit entry action at the end of the transaction sequence, rather than separate entry of each item.
Comment
Depending on form design, this practice might involve entering the
entire form, or entry by page or section of a longer form. Form design
should indicate to users just where explicit entry is required.
Comment
Single entry of grouped data will generally permit faster input than
item-by-item entry, and should prove more accurate as well. This
practice permits user review and possible data correction prior to
entry, and also helps the user understand at what point grouped data are
processed. It will also permit efficient cross validation of related
data items by the computer.
See also
1.0/9
|
6.3/6
|
6.3/18
When multiple data items are entered as a single transaction, as in form filling, allow the user to REVIEW, CANCEL, or BACKUP and change any item before taking a final ENTER action.
Reference
See also
1.0/9
|
3.3/3
|
3.3/4
|
3.3/5
|
3.5/2
|
6.0/10
|
6.3/8
Whenever possible, allow entry of multiple data items without keying special separator or delimiter characters, e.g., hyphens, dollar signs, etc.
Example
See sample displays in this section.
Comment
This can be accomplished either by keying into predefined entry fields
or by separating sequentially keyed items with blank spaces. In this
context, tabbing from field to field is not considered to be keying a
special delimiter character.
Comment
When data items contain internal blanks, design the entry fields with a
predefined structure so that users will not have to key any internal
delimiters.
When a field delimiter must be used for data entry, adopt a standard character to be employed consistently for that purpose.
Example
A slash (/) may be a good choice.
Comment
Choose a special delimiter character that does not require shift keying.
It will also be necessary to choose a character that does not occur as
part of any data entry (except possibly for entry of running text where
its occurrence would not be ambiguous).
For each data field, display an associated label to help users understand what entries can be made.
Example
(Good)
| NAME: __ __ __ __ __ __ __ __ __ __ __ |
| |
| ORGANIZATION: __ __/__ __ |
| |
| PHONE: __ __ __-__ __ __ __ |(Bad)
| NAME, ORGANIZATION AND PHONE |
| |
| __ __ __ __ __ __ __ __ __ __ __ __ |
| |
| __ __ __ __ |
| |
| __ __ __ __ __ __ __ |
Reference
Make field labels consistent; always employ the same label to indicate the same kind of data entry.
Example
A field labeled NAME should always require name entry, and not sometimes
require something different like elevation (cited from an actual
system).
Example
See sample displays in this section.
Protect field labels from keyed entry, by making the cursor skip over them automatically when a user is spacing or tabbing.
Exception
When a user must change a displayed form, including changes to field
labels, then that user must be able to override label protection.
Reference
See also
1.1/23
|
2.0/10
|
6.2/5
|
6.3/2
Ensure that labels are sufficiently close to be associated with their proper data fields, but are separated from data fields by at least one space.
Reference
See also
2.2/9
Choose a standard symbol for input prompting and reserve that symbol only for that use.
Example
In the examples here, and also in many printed forms, a colon serves to
prompt inputs, as
(Good) | TIME: ________ |
(Bad) | TIME ________ |
Comment
Consistent use of a symbol for input prompting in data entry forms, in
menus, in command entry lines, etc., will help to cue users that an
input is required. A standard symbol used in addition to other
formatting cues will help to alert a user to differences between labels
and displayed data, between messages requiring input and messages for
information only.
Reference
Display special characters or other consistent means of highlighting to clearly delineate each data field.
Example
An underscore might be used for this purpose, perhaps broken to indicate
the number of symbols required in an entry, as
(Good) | Enter account number: __ __ __ __ __ |
(Bad) | Enter account number: |
Example
See sample displays in this section.
Comment
Such implicit prompts help reduce data entry errors by the user.
Reference
See also
1.0/6
|
2.2/2
|
4.4/15
Provide cues in field delineation to indicate when a fixed or maximum length is specified for a data entry.
Example
(Good) | Enter ID: __ __ __ __ __ __ __ __ __ |
(Bad) | Enter ID (9 characters): |
Example
See sample displays in this section.
Comment
Prompting by delineation is more effective than simply telling the user
how long an entry should be. In the example cited here, underscoring
gives a direct visual cue as to the number of characters to be entered,
and the user does not have to count them.
Comment
Similar implicit cues should be provided when data entry is prompted by
auditory displays. Tone codes can be used to indicate the type and
length of data entries.
Reference
See also
4.4/15
In designing form displays, distinguish clearly and consistently between required and optional entry fields.
Example
Field delineation cues may be used for this purpose, perhaps a broken
underscore to indicate required entries and a dotted underscore to
indicate optional entries, as
| LICENSE NUMBER: __ __ __ __ __ __ |
| |
| MAKE: . . . . . . . . . . . . . . |
| |
| YEAR/MODEL: . . . . . . . . . . . |
Example
Alternatively, it might be preferable to distinguish required versus
optional entry fields by coding their labels, perhaps displaying in
parentheses the labels of optional fields.
Reference
See also
4.4/15
When item length is variable, so that a data entry does not completely replace the markers in a field, ignore any remaining field markers in computer processing.
Comment
A user should not be expected to erase any field markers. Extra markers
should not be processed as part of a data entry if they are not erased.
Reference
When item length is variable, provide automatic justification in computer processing; a user should not have to justify an entry either right or left.
Example
Assuming field delineation by underscore, the following entries should
all be considered equivalent
| Address: 40 Dalton Road_______ |
| Address: _______40 Dalton Road |
| Address: ___40 Dalton Road____ |
Comment
If a data entry is shorter than its field length, its position when
entered in that field should not matter. The computer can impose its
own justification rules when storing and subsequently displaying such
data for review.
Reference
Require users to take explicit keying ("tabbing") action to move from one data entry field to the next; the computer should not provide such tabbing automatically.
Example
See sample displays in this section.
Comment
Automatic tabbing may cause cascading of errors, if a skilled typist
keys a series of items without looking at the display and has
accidentally overrun one of the earlier data fields. An acceptable
solution here is to design each field to end with an extra (blank)
character space; software should be designed to prevent keying into a
blank space, and an auditory signal should be provided to alert the user
when that is attempted. This will permit consistent use of tab keying
by the user to move accurately from one field to the next, even for
touch typists.
Reference
See also
1.1/22
Make labels for data fields distinctive, so that they will not be readily confused with data entries, labeled control options, guidance messages, or other displayed material.
Example
Labels might be displayed in capital letters always followed by a colon.
Or labels might be displayed in dim characters, with data entries
brighter.
Example
See sample displays in this section.
Reference
When data fields are distributed across a display, adopt a consistent format for relating labels to delineated entry areas.
Example
The label might always be to the left of the field; or the label might
always be immediately above and left-justified with the beginning of the
field.
Comment
Such consistent practice will help the user distinguish labels from data
in distributed displays.
See also
4.0/7
The label for each entry field should end with a special symbol, signifying that an entry may be made.
Example
A colon is recommended for this purpose, as
| NAME: __ __ __ __ __ __ __ __ __ __ __ |
Example
See sample displays in this section.
Comment
Choose a symbol that can be reserved exclusively for prompting user
entries, or at least is rarely used for any other purpose.
Reference
See also
4.4/15
In labeling data fields, employ descriptive wording, or else standard, predefined terms, codes and/or abbreviations; avoid arbitrary codes.
Example
Employ descriptive labels such as STANDARD and MODIFIED, rather than
abstract codes such as SET A and SET B; MALE and FEMALE, rather than
GROUP 1 and GROUP 2.
Example
(Good)
| WEEK: __ MONTH: __ __ YEAR: __ __ |
| |
| SOCIAL SECURITY NO: __ __ __ - __ __ - __ __ __ __ |(Bad)
| DATECODE: __ __ __ __ __ |
| |
| SSAN: __ __ __ __ __ __ __ __ __ |
Example
See sample displays in this section.
Comment
Do not create new jargon. If in doubt, pretest all proposed wording
with a sample of qualified users.
Reference
Include in a field label additional cueing of data format when that seems helpful.
Example
| DATE (MM/DD/YY): __ __/__ __/__ __ |
Example
See sample displays in this section.
Reference
See also
4.0/11
When a measurement unit is consistently associated with a particular data field, include that unit as part of the field label rather than requiring a user to enter it.
Example
| COST: $ __ __ __ __ |
Example
| SPEED (MPH): __ __ __ |
Reference
Employ units of measurement that are familiar to the user.
Example
(Good)
| SPEED LIMIT: __ __ miles per hour |(Bad)
| SPEED LIMIT: __ __ feet per second |(Good)
| FUEL USE: __ __.__ miles per gallon |(Bad)
| FUEL USE: .__ __ gallons per minute |
Comment
If data must be converted to unfamiliar units, the computer should
handle that automatically.
Reference
See also
4.0/17
When alternative measurement units are acceptable, provide space in the data field so that a user can designate the units actually entered.
Example
| DISTANCE: __ __ __ __ (MI/KM) __ __ |
Reference
See also
4.0/11
When forms are used for reviewing displayed data as well as for data entry, make the form for data entry compatible with that for display output; use the same item labels and ordering for both.
Comment
When a display format optimized for data entry seems unsuited for data
display, or vice versa, some compromise format should be designed,
taking into account the relative functional importance of data entry and
data review in the user's task.
Reference
See also
2.2/12
|
2.5/1
|
4.0/6
When data entry involves transcription from source documents, ensure that form-filling displays match (or are compatible with) those documents, in terms of item ordering, data grouping, etc.
Example
See sample displays in this section.
Comment
If paper forms are not optimal for data entry, consider revising the
layout of the paper form.
Comment
If data entries must follow an arbitrary sequence of external
information (e.g., keying telephoned reservation data), employ some form
of command language dialogue instead of form filling, to identify each
item as it is entered so that the user does not have to remember and
re-order items.
Reference
See also
2.5/1
|
2.5/14
|
3.1.1/4
|
4.0/6
When designing displays for form-filling data entry, minimize user actions required for cursor movement from one field to the next.
Comment
Placing all required fields before any optional fields will sometimes
make data entry more efficient.
Reference
See also
1.1/22
If no source document or external information is involved, then design forms so that data items are ordered in the sequence in which a user will think of them.
Comment
The software designer will need to work with prospective system users to
determine what represents a logical sequence of data entries.
Reference
See also
2.5/14
When a form for data entry is displayed, the computer should place the cursor automatically at the beginning of the first entry field.
Exception
If a data form is regenerated following an entry error, the cursor
should be placed in the first field in which an error has been detected.
Reference
See also
1.1/21
|
3.1.3/29
|
4.4/16
Tables permit data entry and display in row-column format, facilitating comparison of related data sets.
When sets of data items must be entered sequentially, in a repetitive series, provide a tabular display format where data sets can be keyed row by row.
Exception
When the items in each data set exceed the capacity of a single row,
tabular entry will usually not be desirable, unless there is a simple
means for horizontal scrolling.
Comment
Row-by-row entry facilitates comparison of related data items, and
permits potential use of a DITTO key for easy duplication of repeated
entries.
Reference
See also
2.7.2/4
Design distinctive formats for column headers and row labels, so that users can distinguish them from data entries.
See also
4.0/8
Ensure that column headers and row labels are worded informatively, so that they will help guide data entry.
See also
4.0/11
During tabular data entry, allow users to tab directly from one data field to the next, so that the cursor can move freely back and forth within a row (i.e., across columns).
Reference
During tabular data entry, allow users to tab directly from one data field to the next, so that the cursor can move freely up and down a column (i.e., across rows).
Reference
Provide automatic justification of tabular data entries; a user should not have to enter blanks or other extraneous formatting characters to achieve proper justification.
Example
As a negative example, if a user enters "56" in a field four characters
long, the system should not interpret "56 __ __" as "5600".
Reference
Allow users to make numeric entries in tables without concern for justification; the computer should right-justify integers, or else justify with respect to a decimal point if present.
Example
A dollars-and-cents entry made at the beginning of a field
| 14.37 __ __ |should automatically be justified to the right
| __ __ 14.37 |when later displayed.
Reference
When a user must enter numeric values that will later be displayed, maintain all significant zeros; zeros should not be arbitrarily removed after a decimal point if they affect the meaning of the number in terms of significant digits.
Reference
See also
2.3/17
For entry of tabular data, when entries are frequently repeated, provide users with some easy means to copy duplicated data.
Example
Perhaps a DITTO key might be provided.
Comment
A DITTO capability will speed data entry, and should prove more accurate
than requiring users to rekey duplicated data.
For long tables, those with many rows, provide some extra visual cue to help a user scan a row accurately across columns.
Example
A blank line might be inserted after every fifth row; or perhaps adding
dots between columns in every fifth row might suffice.
Example
As an alternative, provide a displayed ruler which a user can move from
one row to another.
Comment
Visual aids for scanning rows are probably needed more when a user is
reviewing and changing displayed data than for initial data entry. Such
aids should be provided consistently, however, so that display formats
for both data entry and review will be compatible.
See also
2.3/14
Graphics permit entry of data specially formatted to show spatial, temporal, or other relations among data sets.
When graphic data entry involves frequent pointing on a display surface, design the user interface so that actions for display control and sequence control are also accomplished by pointing, in order to minimize shifts from one entry device to another.
Example
In drawing a flow chart, a user should be able to link predecessor and
successor elements directly by pointing at them, or by drawing lines
between them, rather than by separately keyed entries.
Exception
Alphabetic entry for titles, labels, and other annotation of graphic
displays will be accomplished more quickly by conventional keyboard
input than by pointing.
Comment
This recommendation implies extensive use of menus in the margins of a
graphic display to permit direct selection of data attributes and
control options by pointing. If screen capacity is too limited to
permit simultaneous display of both graphic data and menus, then the
designer might provide temporary superposition of menu windows on
displayed data, or might provide some separate display device to show
current options for control entry. Control entry via keyboard and/or
function keys will be less satisfactory.
Comment
If pointing is performed on some separate input device, such as a stylus
on a digitizing tablet, then associated control actions should also be
implemented via that device.
Comment
For graphics software, a pointing action by a user can accomplish
several different logical functions: specifying a displayed element
("pick" function); selecting a system-defined object, attribute or
action ("button" or "choice" function); or indicating a location in the
conceptual drawing space ("locator" function). A designer must
distinguish among these functions, although most users will not.
Reference
Indicate the current cursor position by displaying some distinctive cursor symbol at that point.
Comment
The cursor may take various forms on a graphics display. Many designers
recommend a plus-sign for this purpose, representing abbreviated
cross-hairs whose intersection can mark a position with reasonable
precision. In some applications it may help to extend those cross-hairs
the full height and width of the display. In some applications it may
help to display a cursor incorporating the current values of various
attributes (color, size, etc.) that can be selected by a user.
Reference
Provide users an easy, accurate means of positioning a displayed cursor to point at different display elements and/or display locations.
Comment
Cursor positioning is a frequent user action during graphic data entry;
an easy means for controlling cursor movement will be essential for
efficient performance.
See also
1.1/7