GUIDELINES FOR DESIGNING USER INTERFACE SOFTWARE
ESD-TR-86-278
by Sidney L. Smith and Jane N. Mosier
skip navigation Introduction | Data Entry | Data Display | Sequence Control | User Guidance | Data Transmission | Data Protection | Table of Contents

1 DATA ENTRY

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

1.0 General

Data entry refers to user actions involving input of data to a computer, and computer responses to such inputs.

1.0/1 Data Entered Only Once

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

1.0/2 Entry via Primary Display

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.

1.0/3 Feedback During 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

See also

3.0/14  |  4.2/1

1.0/4 + Fast Response

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

See also

3.0/18  |  3.0/19

1.0/5 Single Method for Entering Data

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

1.0/6 Defined Display Areas for Data Entry

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

1.0/7 Consistent Method for Data Change

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

1.0/8 User-Paced Data Entry

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

1.0/9 Explicit ENTER Action

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

1.0/10 + ENTER Key Labeling

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

See also

3.0/16  |  4.0/10

1.0/11 Explicit CANCEL Action

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

1.0/12 Feedback for Completion of Data Entry

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

1.0/13 + Feedback for Repetitive Data Entries

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

1.0/14 + Feedback when Changing Data

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

1.0/15 Keeping Data Items Short

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

1.0/16 + Partitioning Long Data Items

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

1.0/17 Optional Abbreviation

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

1.0/18 + Distinctive Abbreviation

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

1.0/19 + Simple Abbreviation Rule

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

1.0/20 + Minimal Exceptions to Abbreviation Rule

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

1.0/21 + Minimal Deviation from Abbreviation Rule

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

1.0/22 + Fixed Abbreviation Length

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

1.0/23 + Clarifying Unrecognized Abbreviations

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.

1.0/24 Prompting Data Entry

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

1.0/25 Character Entry via Single Keystroke

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

1.0/26 + Minimal Shift Keying

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

1.0/27 Upper and Lower Case Equivalent

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.

See also

1.3/10  |  3.0/12

1.0/28 Decimal Point Optional

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

1.0/29 Leading Zeros Optional

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

1.0/30 Single and Multiple Blanks Equivalent

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

1.0/31 Aids for Entering Hierarchic Data

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.

See also

1.6/18  |  1.8/12

1.0/32 Speech Input

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.

1.0/33 + Limited Vocabulary for Speech Input

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.

1.0/34 + Phonetically Distinct Vocabulary for Speech Input

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.

1.0/35 + Easy Error Correction for Speech Input

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.

1.0/36 + Alternative Entries for Speech Input

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.

1.0/37 + PAUSE and CONTINUE Options for Speech Input

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.

See also

3.3/8  |  3.3/9

1.1 Position Designation

Position designation refers to user selection and entry of a position on a display, or of a displayed item.

1.1/1 Distinctive Cursor

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

See also

1.1/17  |  4.0/9

1.1/2 + Nonobscuring Cursor

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.

1.1/3 + Precise Pointing

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

1.1/4 Explicit Activation

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

See also

1.6/4  |  3.1.3/6

1.1/5 Fast Acknowledgement of Entry

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

1.1/6 Stable Cursor

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

1.1/7 Responsive Cursor Control

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.

1.1/8 Consistent Incremental Positioning

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.

1.1/9 + Variable Step Size

When character size is variable, design the incremental cursor positioning to vary correspondingly, with a step size matching the size of currently selected characters.

1.1/10 + Proportional Spacing

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.

1.1/11 Continuous Cursor Positioning

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

1.1/12 Direct Pointing

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

1.1/13 + Large Pointing Area for Option Selection

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

1.1/14 Cursor Control at Keyboard

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

1.1/15 Compatible Control of Cursor Movement

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

1.1/16 Minimal Use of Multiple Cursors

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.

1.1/17 + Distinctive Multiple Cursors

If multiple cursors are used, make them visually distinctive from one another.

See also

1.1/1

1.1/18 + Distinctive Control of Multiple Cursors

If multiple cursors are controlled by a single device, provide a clear signal to the user to indicate which cursor is currently under control.

1.1/19 + Compatible Control of Multiple Cursors

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

1.1/20 Consistent HOME Position

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

1.1/21 Consistent Cursor Placement

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

See also

1.4/28  |  4.4/16

1.1/22 Easy Cursor Movement to Data Fields

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

1.1/23 Display Format Protection

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

1.1/24 Data Entry Independent of Cursor Placement

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

1.2 Direction Designation

Direction designation refers to user entry of directional data (azimuth, bearing, heading, etc.) on a display.

1.2/1 Analog Entry of Estimated Direction

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

1.2/2 Keyed Entry of Quantified Direction

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.

1.3 Text

Text entry refers to the initial entry and subsequent editing of textual material, including messages.

1.3/1 Adequate Display Capacity

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

1.3/2 Editing Capabilities During Text Entry

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

1.3/3 Free Cursor Movement

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

1.3/4 + Control Entries Distinct from Text

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

1.3/5 Natural Units of Text

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.

1.3/6 + Control Entry Based on Units of Text

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

See also

3.0/6  |  4.0/1

1.3/7 + Highlighting Specified Text

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

1.3/8 + Cursor Movement by Units of Text

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

1.3/9 String Search

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

1.3/10 + Upper and Lower Case Equivalent in Search

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.

See also

1.0/27  |  3.0/12

1.3/11 + Specifying Case in Search

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.

1.3/12 + Global Search and Replace

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.

1.3/13 + Case in Global Search and Replace

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").

1.3/14 Automatic Pagination Aids

Provide automatic pagination for text entry/editing, allowing users to specify the page size.

Exception

For short documents, automatic pagination may not be needed.

1.3/15 + User Control of Pagination

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.

1.3/16 + Controlling Integrity of Text Units

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.

1.3/17 Automatic Line Break

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.

1.3/18 + Consistent Word Spacing

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

1.3/19 Hyphenation by Users

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

1.3/20 Format Control by User

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.

1.3/21 Establishing Predefined Formats

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

1.3/22 + Storing User-Defined Formats

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.

1.3/23 Moving Text

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

1.3/24 Storing Frequently Used Text

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.

1.3/25 Necessary Data Displayed

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.

1.3/26 + Text Distinct from Annotation

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

1.3/27 Text Displayed as Printed

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

1.3/28 Flexible Printing Options

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.

1.3/29 Information on Printing Status

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.

See also

3.0/14  |  4.2/5

1.3/30 Auditory Signals for Alerting Users

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

1.3/31 Protecting Text During Page Overruns

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.

1.3/32 Confirming Actions in DELETE Mode

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

1.3/33 Reversible Actions

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

See also

3.5/10  |  6.0/21

1.3/34 User Confirmation of Editing Changes

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.

See also

6.0/18  |  6.3/19

1.4 Data Forms

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.

1.4/1 Combined Entry of Related Data

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

1.4/2 Flexible Interrupt

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

1.4/3 Minimal Use of Delimiters

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.

1.4/4 + Standard Delimiter Character

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).

1.4/5 Data Field Labels

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

See also

1.0/24  |  4.0/11

1.4/6 + Consistent Labeling

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.

1.4/7 + Protected Labels

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

1.4/8 + Labels Close to Data Fields

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

1.4/9 + Standard Symbol for Prompting Entry

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

See also

3.1.3/15  |  4.4/10

1.4/10 Marking Field Boundaries

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

1.4/11 + Prompting Field Length

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

1.4/12 + Marking Required and Optional Data Fields

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

1.4/13 + Field Markers Not Entered with Data

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

1.4/14 + Automatic Justification of Variable-Length Entries

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

1.4/15 Explicit Tabbing to Data Fields

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

1.4/16 Distinctive Label Format

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

See also

2.2/8  |  4.0/8

1.4/17 + Consistent Label Format

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

1.4/18 + Label Punctuation as Entry Cue

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

1.4/19 Informative Labels

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

See also

2.0/12  |  4.0/11

1.4/20 Data Format Cueing in Labels

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

1.4/21 + Labeling Units of Measurement

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

See also

2.2/10  |  4.0/11

1.4/22 + Familiar Units of Measurement

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

1.4/23 + Alternative Units of Measurement

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

1.4/24 Form Compatible for Data Entry and Display

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

1.4/25 + Form Compatible with Source Documents

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

1.4/26 Minimal Cursor Positioning

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

1.4/27 + Data Items in Logical Order

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

1.4/28 Automatic Cursor Placement

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

1.5 Tables

Tables permit data entry and display in row-column format, facilitating comparison of related data sets.

1.5/1 Tables for 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

1.5/2 Distinctive Labels

Design distinctive formats for column headers and row labels, so that users can distinguish them from data entries.

See also

4.0/8

1.5/3 + Informative Labels

Ensure that column headers and row labels are worded informatively, so that they will help guide data entry.

See also

4.0/11

1.5/4 Tabbing within Rows

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

1.5/5 + Tabbing within Columns

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

1.5/6 Automatic Justification of Entries

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

1.5/7 + Justification of Numeric Entries

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

1.5/8 + Maintaining Significant Zeros

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

1.5/9 Aiding Entry of Duplicative Data

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.

1.5/10 Row Scanning Cues

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

1.6 Graphics

Graphics permit entry of data specially formatted to show spatial, temporal, or other relations among data sets.

1.6/1 Pointing

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

See also

1.0/5  |  1.1

1.6/2 + Distinctive Cursor

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

See also

1.1/1  |  1.6/12

1.6/3 + Easy Cursor Positioning

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

1.6/4 Confirming Cursor Position

For most graphics data entry, pointing should be a dual action, first positioning a cursor at a desired position, and then confirming that position to the computer.

Exception

An exception to this recommendation would be the freehand drawing of continuous lines ("path specification"), where a computer must store and display a series of cursor positions as they are input by the user; when the user initiates such a line-drawing sequence, a new data point might be recorded automatically whenever the cursor has been moved a certain distance (e.g., 1 mm) or when a certain time has elapsed (e.g., 0.5 s).

Comment

During graphics data entry, a cursor will almost always be somewhere on the display, but not necessarily at a location intended by the user. In effect, a user needs some way to move the cursor around and some separate action to signal the computer when its position should be recorded.

Comment

An interesting case of position confirmation is "rubberbanding", which is a technique to aid line drawing. With rubberbanding, a user can designate the starting point for a line, then move the cursor to various possible end points while the computer continuously shows the line that would result if that end point were confirmed by the user.

Reference

See also

1.1/4  |  1.6.2/2

1.6/5 Zooming for Precise Positioning

When data entry requires exact placement of graphic elements, users should be allowed to request expansion of the critical display area ("zooming") to make the positioning task easier.

Reference

See also

1.6.2/11  |  2.4/15

1.6/6 Selecting Graphic Elements

Provide users some means for designating and selecting displayed graphic elements for manipulation.

Example

Designation might be by pointing, in the case of a discrete element, or might require some sort of outlining action to delineate portions of a complex figure.

See also

1.3/5

1.6/7 + Highlighting Selected Elements

When a user has selected (i.e., pointed at) a displayed graphic element, highlight that element in some way so that the user can anticipate the consequences of any proposed action involving that selection.

Example

A dotted border might be displayed around a selected element, or perhaps a selected element might be displayed with video inversion to distinguish it from other elements.

Reference

See also

1.3/7  |  2.6/1  |  4.2/10

1.6/8 Changing Position (Translation)

When editing graphic data, allow users to reposition selected elements on the display.

Comment

Repositioning displayed elements, whether done by "dragging" or "cut-and-paste", will usually prove easier than deleting an element and then recreating it from scratch in the desired location. A capability for moving elements will aid initial data entry as well as any subsequent editing of graphic data.

Comment

If an element is moved visibly by dragging across the display, it is probably not necessary to depict it in complete detail in all of its intermediate positions. It might suffice to show it in simplified outline until its new position has been confirmed by the user (or perhaps until it remains in one position for a fixed interval of time), at which point its details could be filled in again by the computer.

See also

1.3/23

1.6/9 Deleting Elements

When editing graphic data, allow users to delete selected elements from the display.

Comment

Deletion/erasure will help when mistakes are made during data entry, as well as in any subsequent editing of graphic data. Deletion should be implemented as a reversible action. A general UNDO capability might suffice to reverse deletions. A more extended reversibility might be provided by saving deleted elements in a computer scrap basket from which they can be retrieved any time during a work session in case a deletion is discovered to be a mistake.

1.6/10 Selecting from Displayed Attributes

During graphic data entry, allow users to specify attributes for displayed elements -- e.g., text font, plotting symbol, line type, color -- by selecting from displayed samples illustrating the available options.

Example

For line drawing a user might select from displayed samples of thick or thin, solid or broken, etc.

Comment

A display of available attributes will serve as a helpful reminder to the user, and will eliminate the need to assign distinctive verbal labels to the various options.

Comment

Samples of some attributes may be difficult to display. In complex graphics, for example, specification of line type might involve selection among "brushes", each of which has a "tip" defining the size and shape of the drawing area (a group of pixels) that the user can manipulate. Brushes might have squared tips to draw sharp lines, or rounded tips to draw lines with softer edges. By analogy with artistic painting, a "smear" brush might be provided to average or blend colors along its path. Selective erasure might be accomplished with a brush applying (returning to) the color of the display background.

Comment

In most applications, the current selection of data attributes should remain in effect until a new selection is made. In some cases, e.g., following selection of an "erase" attribute, it may help the user if a selected attribute reverts automatically to a default value at the completion of a transaction sequence.

1.6/11 + Selecting Colors

If users may select colors as an attribute of graphic elements, allow them to specify colors directly by pointing at displayed samples, rather than requiring them to name the colors.

Exception

If only a few colors are available, their names can probably be used reliably.

Comment

If many colors are available, users with normal vision can choose from displayed samples more reliably than from a list of color names. For color-blind users, however, it might be helpful to add names/labels to the displayed samples.

Comment

For more elaborate graphic art, it may be helpful to allow users to mix their own colors by sequential selection (i.e., cursor placement), either in a displayed palette or directly in a graphic image. Such color mixing could permit user control of saturation, brightness, and opacity/transparency, as well as hues.

1.6/12 + Displaying Current Attributes

During graphic data entry/editing, display the selected attributes that will affect current actions for ready reference by the user.

Example

When graphic attributes -- plotting symbols, character size, line type, color, etc. -- are chosen from displayed menus, it might suffice to highlight the currently selected menu options; alternatively, current selections might be shown in some sort of "reminder" window.

Example

A few attributes might be shown by the displayed cursor, i.e., by changing cursor shape, size or color depending upon current attribute selections.

Example

If rubberbanding is provided to aid line drawing, then that process itself would show the currently selected line type.

Comment

Users may forget what options have been chosen. Displayed reminders will be particularly important in situations where the consequences of a mistaken user action are difficult to reverse, e.g., where it may be hard to erase a wrongly drawn line.

Comment

In some applications, display cues may not be adequate to convey attribute information completely. There may not be sufficient room on the display. Or the attributes may derive from underlying models whose characteristics are too complex for simple display representation. In such cases, users should be able to request auxiliary display of such information to determine the operative context for current actions.

See also

1.6.2/2  |  3.0/9  |  4.0/9  |  4.4/13  |  3.4

1.6/13 Changing Attributes

When entering or editing graphic data, allow users to change display attributes -- e.g., line type, cross-hatching, color -- for selected graphic elements.

Example

If a figure was created initially with dashed lines, then a user should be able to select the figure, or portions of it, and change the dashed lines to solid lines by specifying that alternative attribute.

Comment

If it is easy to change attributes, reversing earlier data entry decisions, then the process of composing graphic displays will be generally easier.

Comment

Another approach to changing an attribute might be to rely on general editing capabilities, i.e., to delete the element in question (perhaps using an UNDO command for an element just created) and then redraw it. But a capability for specifying attribute change directly, without element deletion and reentry, will often be helpful.

See also

1.6/6

1.6/14 + Consistent Method for Attribute Selection

When editing graphic data, allow users to change display attributes by whatever means were used to select those attributes in the first place.

Example

If line type is selected initially from a menu of displayed attributes, then changing a line type should also be accomplished via menu selection.

Comment

Many editing changes will be made during data entry, rather than as separate later actions, and thus it is important that entry and editing actions be consistent.

1.6/15 Easy Storage and Retrieval

Provide easy means for saving and retrieving graphic displays or their component elements at different stages in their creation.

Comment

A user should not have to create a graphic image more than once. Once a graphic element has been created, a user should be able to save it for possible re-use.

Comment

As a protective measure, a user might wish to save different versions of a graphic display at successive stages during its creation, in order to return to an earlier state if later results seem unsatisfactory. During creation, the elements added to a graphic display can be interrelated in complex ways, and thus stepwise deletion of unwanted elements could prove a difficult process. An UNDO command might be helpful for deleting some of the most recently added elements. But storage and subsequent retrieval of interim versions of the display may be more helpful for a foresighted user.

1.6/16 + Naming Displays and Elements

Allow users to name graphic displays or designated elements, in order to aid storage and retrieval or manipulation during graphic data entry/editing; and provide means for a user to review a current "catalog" of named elements.

Comment

Standard displays and graphic components might be assigned names automatically by the computer, but users will still need a capability to assign their own names to interim versions of displays in creation, or to various elements of those displays. In either case, users may forget what names have been assigned; some "catalog" of currently named elements will serve as a helpful reminder.

Comment

For currently displayed material, pointing may be more convenient than naming for the designation of selected elements; but names will certainly aid the retrieval of stored material.

Reference

1.6/17 Automatic Data Registration

Provide automatic registration or alignment of computer-generated graphic data, so that variable data are shown properly with respect to fixed background or map data at any display scale.

Comment

When users are required to enter data via some separate device such as a graphics tablet, rather than directly on the display surface, it may be necessary for a user to participate in some computer-prompted procedure for ensuring data registration. Such a procedure may prove error-prone, however, and should be considered an undesirable expedient.

1.6/18 Aids for Entering Hierarchic Data

When graphic data must be entered in an organized hierarchic structure, in different sections and at different levels of increasing detail, provide computer aids for that purpose.

Example

For entering map data, a user might have to specify different levels of data storage for a city's name and location, its municipal boundaries, its major road patterns, its street names and house numbers, etc.; computer aids could help that process.

See also

1.0/31  |  1.8/12  |  2.4/15

1.6/19 Automatic Data Validation

When graphic data represent relations among real objects, provide appropriate computer logic based on models of physical probability to validate data entries.

Example

If data indicate that a military land unit has been reported in the middle of a lake, the computer should call that discrepancy to the user's attention.

Comment

If inconsistencies of data entry cannot be resolved immediately, the computer might keep track of unresolved questions pending receipt of further data.

See also

1.7/1

1.6.1 Graphics - Plotting Data

Plotting data to show their relations in various graphic formats can be aided greatly by appropriate software.

1.6.1/1 Automated Data Plotting

When complex graphic data must be entered quickly, provide computer aids to automate that process.

Example

Prestored geographic data and background maps, along with automated entry ("posting") of flight plan data and track data, will permit fast and accurate generation of graphic displays for air traffic control, far beyond the capabilities of manual entry by a user.

Comment

Users can create simple graphics or edit stored graphic material fairly quickly, but they can create complex graphic displays only much more slowly. A variety of computer aids can be provided to help enter graphic data. Entry of detailed drawings and/or photographic imagery can be accomplished via a video camera and high-resolution digitizer, perhaps with facilities for a user to edit that process.

1.6.1/2 Plotting Stored Data

Provide automated plotting of computer-stored data at user request, with provision for subsequent editing by a user.

Example

A computer might plot the data values from two arrays in a line graph, or three-dimensional data in XYZ coordinates.

Comment

In many applications, data intended for graphic display will already be stored in the computer. In such cases a user might specify the graphic format required and edit elements in the resulting display output, without actually having to re-enter the data. When users do have to enter data for graphic display, they might choose form filling or tabular entry for efficiency in the initial input of data and then invoke graphic capabilities for subsequent data editing. In either case, it is important that previously entered data should be accessible for graphic processing.

See also

1.8/7  |  1.8/8

1.6.1/3 Predefined Graphic Formats

When graphic data must be plotted in predefined standard formats, provide templates or skeletal displays for those formats to aid data entry.

Example

Sample displays might be stored in the computer to aid in creating standard graphs such as bar graphs, or standard diagrams such as organization charts, or page layouts for typesetting, or maps drawn to different scales or with different projections.

Comment

In many applications, it may help to provide flexibility so that general prestored formats can be modified by a user and then saved for subsequent use.

See also

1.6/15

1.6.1/4 Aids for Graph Construction

When graphs must be constructed for data plotting, provide computer aids for that purpose.

Example

Construction aids might include stored templates of different kinds of graphs, prompts to guide users in the definition of scale axes, and aids for format control such as automatic centering of axis labels if requested by a user.

Comment

Computer aids for graph construction should be designed to allow flexibility in their use. A user should be allowed to position labels and other graphic elements at will, except where operational requirements may impose fixed formats.

Reference

1.6.1/5 + Aids for Scaling

Provide computer aids to help users specify appropriate scales for graphic data entry.

Comment

The computer should handle scaling automatically, subject to review and change by a user. The computer might provide a general template for the plotting scale and prompt the user as necessary to define the scale more exactly, including specification of the origin, linear or logarithmic axes, scale intervals, minimum and maximum values, and labels for axes.

Comment

In the process of defining scales the computer might impose rules to ensure that the resulting graphic displays are designed to permit effective information assimilation by their users, e.g., displaying scales with conventional direction, so that numbers increase in value from left to right, or from bottom to top.

Reference

See also

2.4.1/1

1.6.1/6 Computer Derivation of Graphic Data

When graphic data can be derived from data already available in the computer, provide machine aids for that purpose.

Example

A computer might fit a smoothed curve through plotted data values, filter out points when drawing a densely defined curve, rescale graphs, invert graphs by exchanging X- and Y-values, convert graphs to show cumulative curves, calculate and display various statistical measures of data distribution, produce a contour plot from gridded data with linear interpolation, plot map contours from latitude-longitude coordinates, calculate bearings, distances, and areas on maps, plot perspective views of objects defined in plan views, plot specified cross-sections of displayed objects, calculate a parts list for a designed assembly, identify critical paths and float time in network scheduling charts, etc.

Comment

The machine capacity for generating graphic data by computation will far exceed a user's capabilities in both speed and accuracy.

See also

1.8/8

1.6.2 Graphics - Drawing

Drawing lines and figures to produce pictorial data of various kinds can be aided greatly by appropriate software.

1.6.2/1 Drawing Lines

When line drawing is required, provide users with aids for drawing straight line segments.

Comment

Some applications may require drawing continuous lines freehand.

Reference

1.6.2/2 Rubberbanding

When lines must be drawn at arbitrary positions, lengths and angles, provide a rubberbanding capability, in which the computer displays a tentative line extending from a designated start point to whatever is the currently proposed end point.

Comment

This technique permits users to enter or change a line segment rapidly and with confidence by designating its starting point and then simply moving the cursor to the desired end-point, thus placing the "rubberband" line in its intended position. A similar capability should be provided to aid entry/editing of specified outline figures. A rectangle might be rubberbanded by fixing one corner and moving the opposite corner. A circle might be rubberbanded to desired size by fixing its center and changing the extension of its radius.

Reference

1.6.2/3 Aiding Line Connection

When line segments must join or intersect, which is true in most drawing, provide computer logic to aid such connection.

Comment

An effective computer logic to aid line connection is to provide a so-called "gravity field" surrounding each line segment, so that if a line-drawing cursor is moved within that field the cursor's new line will be extended automatically to intersect the already-displayed line. Note that a "gravity field" need not itself be displayed; users will soon learn to infer its extent by its effect in aiding cursor placement. Because users often seek to join line segments at their ends, it may help to enlarge the zone of attraction at the end of each displayed line to facilitate such end-to-end connection.

Comment

The concept of "gravity field" can also be used to align drawn line segments with points in a reference grid, as well as with each other.

Reference

1.6.2/4 Grid Reference for Alignment

When graphic elements are created with vertical and horizontal alignment, provide a reference grid that can be requested by a user to aid that alignment.

Comment

A reference grid might be displayed merely as a visual aid. In some instances, however, where repeated graphic elements must be aligned in regular fashion, it may be helpful to use a grid to position graphic elements automatically at its intersections. An example might be the construction of organization charts with repeating rows of boxes connected by line segments. "Grid gravity" might be provided automatically during graphic entry, based on "gravity field" connection of drawn lines to grid points, or might be invoked as a separate editing command by a user.

Comment

A grid suitable for aiding data entry may not prove equally helpful for subsequent interpretation of data on the completed display. Therefore, after a graphic image has been composed, the user should decide whether or not to include the reference grid in the finished display.

Reference

See also

2.4.1/11

1.6.2/5 + Changing Grid Intervals

When a reference grid is displayed to aid graphic data entry, allow users to change the grid intervals in either or both directions.

Comment

For different applications, a user may wish to work with a fine grid or a coarse grid, depending on the quantizing interval of the data being plotted. Some designers recommend a standard grid resolution of 1/20 of graph height or width, but such a standard will not be optimum for every application.

1.6.2/6 Constraint for Vertical and Horizontal Lines

When graphic elements are created with vertical and horizontal lines, allow users to specify appropriate constraints during line drawing.

Comment

Here computer logic is invoked to interpret casual freehand gestures by a user as if they were carefully drawn -- the electronic equivalent of a draftsman's T-square. Thus a roughly vertical motion by a user could create an exactly vertical line in computer storage and display.

Comment

In applications where orthogonal lines predominate, it may be helpful to make constrained drawing the norm, while allowing users to specify free-form drawing as an exception.

Reference

1.6.2/7 Specifying Line Relations

For precise drawing, allow users to draw lines by specifying their geometric relations with other lines.

Example

In computer-aided design, a user might wish to create a new line by declaring it parallel with (or perpendicular to) an existing line.

1.6.2/8 Drawing Figures

When a user must draw figures, provide computer aids for that purpose.

Example

A user might select from a stored set of standard forms -- rectangles, circles, etc. -- and edit those to create figures or the component elements of figures, rather than having to draw each figure from scratch.

Example

Computer logic might be provided to allow a user to create a rectangle simply by designating two opposite corners, or a circle by first specifying its center and then any point on its circumference, with rubberbanding to show the result of any current selection.

Comment

Much graphic construction can either be aided in some way (by templates, tracing techniques, grid gravity, etc.), or can employ machine generation of computed or stored forms, often followed by user editing of those forms. A great many different figures can be created by combining simple elements or by specifying geometric parameters (e.g., conic sections). Computer aids that allow such shortcuts can speed figure drawing and make the process more accurate. In some applications, such as constructing organization charts, figures may repeat a number of standard elements. In such cases computer aids can be provided to make the production of figures almost routine.

Comment

Some capability for freehand drawing may be needed, particularly in the creation of graphic art, but freehand drawing will not provide sufficient precision for many applications.

Reference

See also

1.6.1/3

1.6.2/9 + Alternative Methods for Drawing Figures

In applications requiring a general capability for drawing figures, provide a choice of methods for specifying graphic elements.

Example

A straight line might usually be created by specifying two points, but sometimes it might be easier to specify one point plus a constraint that the line be parallel (perpendicular, tangent) to some other line.

Example

A circle might usually be created by specifying its center and a point on its circumference; but sometimes it might be easier to specify a circle by other means -- e.g., by two ends of its diameter, or by three points on its circumference, or by its center plus a constraint that it be tangent to some other figure, or by inscribing it within a square.

Example

An ellipse might usually be created by specifying two foci and a point on its perimeter, but sometimes it might be easier to specify its center and draw its long and short axes, or it might be inscribed within a rectangle.

Example

A regular polygon might usually be created by specifying the end points of one edge and the number of sides, but it also might be specified by its center and one vertex and the number of its sides.

Comment

These examples are from the demanding realm of computer-aided design. Simpler kinds of graphic entry may not require such capabilities.

Comment

In the use of various figure-drawing aids, it may be helpful if the computer can provide step-by-step prompts for each procedure, e.g., "Now indicate center point", "Now indicate radius", etc.

Reference

1.6.2/10 Changing Size

When editing graphic data, allow users to change the size of any selected element on the display.

Comment

Scaling displayed elements to different sizes, expanding or shrinking them, will usually prove easier than deleting an element and then recreating it from scratch in the desired size. A capability for changing the scale of a displayed element will aid initial data entry as well as any subsequent editing of graphic data.

Comment

Depending on the application, it may be helpful to provide a continuous sizing capability, or else incremental sizing to various defined scales.

1.6.2/11 + Enlargement for Symbol Drawing

In applications where users may create special symbols, provide a capability for drawing (or changing) a symbol in large scale, with automatic reduction by the computer to the needed size.

Example

Enlargement might aid in specifying shapes to be used for plotting points or for map symbols, or in designing icons or the letters in a font.

Comment

When drawing symbols in large scale, a rough sketch may suffice, requiring less dexterity from a user. The desirable degree of scale expansion will depend upon symbol complexity, and can probably be determined by testing. Some designers recommend a 20x20 grid to provide an enlarged pixel representation, on which a user can add or delete pixels to create a symbol.

See also

1.6/5

1.6.2/12 Copying Elements

Allow users to copy a selected graphic element in order to duplicate it elsewhere or create a repeating pattern.

Comment

Many graphic displays contain repeating elements; copying an element already created may prove quicker than redrawing that element from scratch.

Comment

In creating patterns, a user will often need to specify a reference point in the original element and then specify where that point should be placed for each copy of that element.

Comment

In some special applications, it might help to provide an optional kind of copying capability called "instancing", in which a user can choose to copy a graphic element from a stored template, and then all copies (or instances) will be changed automatically whenever that original template is changed.

See also

1.6/15

1.6.2/13 Rotating Elements

When editing graphic data that depict objects, allow users to rotate a selected element on the display, in order to show it in different orientations.

Comment

Rotation of a displayed element will usually prove easier than deleting an element and then recreating it from scratch in the desired orientation. A capability for rotating an element will aid initial data entry as well as any subsequent editing of graphic data.

See also

2.4.6/5

1.6.2/14 Reflection of Elements

When users must create symmetric graphic elements, provide a means for specifying a reflection (mirror image) of existing elements.

Comment

Many graphic displays contain symmetric figures where if one side has been drawn the other side might be created quickly as a reflected copy of the first, perhaps with some subsequent modification by the user.

Comment

Users will need some means for specifying the desired reflection plane, which for practical purposes should probably be constrained to a choice between left-right and up-down reflection.

Reference

1.6.2/15 Grouping Elements

Allow users to designate a group of elements to which graphic editing operations will be applied in common.

Example

A user might carefully position two elements with respect to each other, and then wish to move both of them together while preserving their relative positions.

Comment

Grouping elements might be a temporary action, intended for just a few successive editing operations, or it might be specified more permanently via some sort of "make group" command.

See also

1.6/6

1.6.2/16 Merging Elements

In the special case when a drawn object can be created by the junction or disjunction of other graphic elements, provide computer aids for merging those elements by boolean combination.

Example

In showing the junction of two objects comprising the components of some more complex object, a computer might calculate and draw their intersection, automatically dealing with overlapped data sets and concealed contours.

Comment

This technique can represent the intersection of solid objects and also the result of drilling holes in an object.

Reference

1.6.2/17 Filling Enclosed Areas

When area coding is required, provide aids to allow users to fill an enclosed area with a selected attribute (color, shading or cross-hatching) by a simple specification action, rather than by having to trace over the area involved.

Example

For many applications, it may suffice if a user can simply point at one of several displayed attributes (color patches, brightness levels, hatching patterns) and then point at the area to be filled.

Comment

A user might wish to shade the bars of a bar chart, or the wedges in a pie chart, or the various components of a drawn diagram or picture.

1.6.2/18 Automatic Figure Completion

In applications where design rules have been previously defined, provide computer aids to complete automatically any details of graphic data entry covered by those rules.

Example

The computer might automatically add dimensional annotation to drafted figures.

Example

When drawing or editing a polygon, the computer might automatically maintain closure if additional vertices are specified, rather than requiring the user to close the figure manually.

Example

In computer-aided design, if the flanges of connected components are designed with arcs of standard radius, then a user might draw those joints square and ask the computer to round them.

Example

A computer might create perspective drawings automatically from plan and elevation data, with hidden parts eliminated.

Example

In drawing flow charts, a computer might automatically add the arrow to a connecting line, depending upon the direction in which the line was drawn (or the sequence in which its points were designated).

Reference

See also

1.6.1/6

1.6.2/19 Stored Models

When drawings are variations on a common theme, consider providing a computer model that will allow users to create particular instances by entering appropriate parameters.

Example

An aerodynamic model might be invoked to help create (and evaluate) an aircraft wing design.

Example

For designing a workplace for human use, it might be helpful to store a body model from which the computer could draw automatically a sample user of any specified size percentile, and then move body parts of the displayed sample user to ensure that all controls are within reach.

Comment

Different kinds of models might be needed, including models based on geometric, surface, and solid relations, as well as even more complex logical models.

Reference

1.7 Data Validation

Data validation refers to checking entries for correct content and/or format, as defined by software logic.

1.7/1 Automatic Data Validation

Provide software for automatic data validation to check any item whose entry and/or correct format or content is required for subsequent data processing.

Example

If a date is entered as "February 31", the computer should generate an error message asking for a revised entry.

Comment

Do not rely on a user always to make correct entries. Computer aids for checking data entries will improve accuracy.

Comment

Some data entries, of course, may not need checking, or may not be susceptible to computer checking, such as free text entries in a COMMENT field.

Reference

See also

6.3/17  |  6.3/18

1.7/2 Accepting Correct Entries

Ensure that every possible correct data entry will be accepted and processed properly by the computer.

Example

As a negative example, on 1 June 1983, after several previous months of successful use, the computers controlling Massachusetts automobile emission inspections failed; it was discovered that they would not accept a "June" entry.

Comment

This guideline states the obvious, and might seem unnecessary except for occasional design lapses such as that cited in the example.

1.7/3 Non-Disruptive Error Messages

If data validation detects a probable error, display an error message to the user at the completion of data entry; do not interrupt an ongoing transaction.

See also

4.3/10

1.7/4 Deferral of Required Data Entry

If a user wishes to defer entry of a required data item, require the user to enter a special symbol in the data field to indicate that the item has been temporarily omitted rather than ignored.

Reference

See also

4.0/2

1.7/5 + Reminder of Deferred Entry

If a user has deferred entry of required data but then requests processing of entries, signal that omission to the user and allow immediate entry of missing items or perhaps further deferral.

Reference

1.7/6 Timely Validation of Sequential Transactions

In a repetitive data entry task, validate the data for one transaction and allow the user to correct errors before beginning another transaction.

Comment

This is particularly important when the task requires transcription from source documents, so that a user can detect and correct entry errors while the relevant document is still at hand.

See also

3.5/12  |  6.3/9

1.7/7 Optional Item-by-Item Validation

For novice users, consider providing optional item-by-item data validation within a multiple-entry transaction.

Comment

This capability, which might be termed an "interim ENTER", may sometimes help a novice user who is uncertain about the requirements imposed on each data item. But item-by-item processing may slow skilled users. Providing such a capability as an optional feature would help novices without hindering more experienced users.

Reference

See also

4.3/10

1.8 Other Data Processing

Other data processing aids may be provided to facilitate data entry.

1.8/1 Default Values

When likely default values can be defined for the data entries in a particular task, offer those default values to speed data entry.

1.8/2 + Defaults for Sequential Entries

If a series of default values have been defined for a data entry sequence, allow a user to default all entries or to default until the next required entry.

Comment

Where a set of default values has been defined, a user may not wish to specify that each default value should be accepted for each data field individually. It might be quicker to accept the set of defaults by a single action.

1.8/3 + User Definition of Default Values

When interface designers cannot predict what default values will be helpful, permit users (or perhaps a system administrator) to define, change or remove default values for any data entry field.

Reference

1.8/4 + Display of Default Values

On initiation of a data entry transaction, display currently defined default values in their appropriate data fields.

Comment

Do not expect users to remember them.

Comment

It may be helpful to mark default values in some way to distinguish them from new data entries.

Reference

See also

4.4/7  |  6.3/15

1.8/5 + Easy Confirmation to Enter Default Values

Provide users with some simple means to confirm acceptance of a displayed default value for entry.

Example

Simply tabbing past the default field may suffice.

Comment

Employ similar techniques when a user must review the accuracy of previously entered data.

Reference

See also

6.3/15

1.8/6 + Temporary Replacement of Default Values

Allow users to replace any data entry default value with a different entry, without thereby changing the default definition for subsequent transactions.

Reference

1.8/7 Automatic Generation of Routine Data

For routine data that can be derived from existing computer records, program the computer to access and enter such data automatically.

Example

As a negative example, do not require a user to identify a work station in order to initiate a transaction, nor to include other routine data such as current date and transaction sequence codes.

Exception

Some data entry routines may be imposed in the interest of security, but at the risk of hindering a user in achieving effective task performance. Other means of ensuring data security should be considered.

Reference

See also

6.1/1  |  6.3/14

1.8/8 Automatic Computation of Derived Data

Provide automatic computation of derived data, so that a user does not have to calculate and enter any number that can be derived from data already accessible to the computer.

Example

Statistical descriptors such as sums, means, etc., can all be derived automatically by appropriate software.

Reference

See also

6.3/14

1.8/9 User Review of Prior Entries

When data entries made in one transaction are relevant to a subsequent transaction, program the computer to retrieve and display them for user review rather than requiring re-entry of those data.

Reference

See also

1.0/1  |  6.3/13

1.8/10 Automatic Entry of Redundant Data

If data are accessible to the computer that are logically related to other entries, program the computer to retrieve and enter those redundant data items automatically.

Example

As a negative example, a user should not have to enter both an item name and identification code when either one defines the other.

Exception

Redundant entry may be needed for resolving ambiguous entries, for user training, or for security (e.g., user identification).

Comment

When verification of previously entered data is required, ask users to review and confirm data items rather than re-enter them.

Reference

See also

6.3/14

1.8/11 Automatic Cross-File Updating

Provide automatic cross-file updating whenever necessary, so that a user does not have to enter the same data twice.

Example

If an aircraft has been assigned to a mission, the computer should automatically update both aircraft status and mission assignment files to indicate that commitment.

Reference

See also

1.0/1  |  6.3/14

1.8/12 Aids for Entering Hierarchic Data

When data must be entered in an organized hierarchic structure, in different sections and at different levels of increasing detail, provide computer aids for that purpose.

Comment

At the least, the computer should provide the user a schematic summary display of any defined data structure for general orientation, with its branches and levels labeled for convenient reference. When a user specifies any portion of the structure for data entry or editing, the computer should display that section of data appropriately labeled, and perhaps show in the display margin a diagram indicating what portion of the overall data structure is currently being displayed.

Comment

When data at one level in a hierarchy are dependent on data entries at other (usually subordinate) levels, the computer should handle cross-level bookkeeping automatically, just as for cross-file updating.

Comment

For entering hierarchic data, a user must specify where in the data structure any new data should be added. If the data structure is complex, it may help if the computer automatically prompts the user to make the appropriate data entries at different levels.

Comment

If a user may need to change the data structure, then computer aids may be needed for that purpose as well as for data entry. The computer should bookkeep automatically any changing relations among the data in different sections that might result from changes to the overall data structure.

See also

1.0/31  |  1.6/18  |  2.4.8/11

1.9 Design Change

Design change of software supporting data entry functions may be needed to meet changing operational requirements.

1.9/1 Flexible Design for Data Entry

When data entry requirements may change, which is often the case, provide some means for users (or a system administrator) to make necessary changes to data entry functions.

Comment

Data entry functions that may need to be changed are those represented in these guidelines, including changes to procedures, entry formats, data validation logic, and other associated data processing.

Comment

Many of the preceding guidelines in this section imply a need for design flexibility. Much of that needed flexibility can be provided in initial interface design. Some guidelines, however, suggest a possible need for subsequent design change, and those guidelines are cited below.

See also

1.3/22  |  1.4/25  |  1.7/1  |  1.8/3  |  1.8/8  |  1.8/10  |  1.8/11


skip navigation Introduction | Data Entry | Data Display | Sequence Control | User Guidance | Data Transmission | Data Protection | Table of Contents | Top