|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents |
|
GUIDELINES FOR DESIGNING USER INTERFACE SOFTWARE
ESD-TR-86-278
|
| by Sidney L. Smith and Jane N. Mosier |
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents |
Data entry refers to user actions involving input of data to a computer, and computer responses to such inputs. The simplest kind of data entry consists merely of pointing at something -- selecting an item or designating a position on a computer-generated display. In more complicated modes of data entry, a user may have to control the format of data inputs as well as their contents. Thus questions of format control in text entry/editing and graphic interaction may properly be considered questions of data entry.
Note, however, that user inputs which initiate or interrupt transactions -- such as command entries, or control entries selected from a displayed menu or by function keys -- pose rather different questions of design. Such control entries are discussed in Section 3 of these guidelines.
Data can be entered into a computer in a variety of different ways. Users might designate position or direction by pointing at a display. Users might enter numbers, letters, or more extended textual material by keyed inputs, or in some applications by spoken inputs. Data might be keyed into displayed forms or tables, into constrained message formats, or as free text. In graphic interaction users might draw pictures or manipulate displayed graphic elements. These different types of data entry all merit consideration here.
The computer will also play a role in the data entry process, guiding users who need help, checking data entries to detect errors, and providing other kinds of data processing aids. A designer of user interface software must be concerned about computer processing logic as well as data input by the user.
Data entry is heavily emphasized in clerical jobs, and many other jobs involve data entry to some degree. Because data entry is so common, and because inefficiencies caused by poorly designed data entry transactions are so apparent, many published recommendations for good user interface design deal with data entry questions. Human factors specialists can probably give better advice about data entry than about any other functional area of user interface design.
Data entry requires hardware, and the proper design of input devices has received considerable attention, including concern for standardization of keyboard layouts. Future advances in hardware design may well influence data entry tasks, as suggested by current advocacy of voice input.
But the major need in today's information systems is for improving the logic of data entry, and it is there that design guidance should prove most helpful. Thus the guidelines presented here deal with data entry functions, insofar as possible, without regard to their hardware implementation.
The general objectives of designing data entry functions are to establish consistency of data entry transactions, minimize input actions and memory load on the user, ensure compatibility of data entry with data display, and provide flexibility of user control of data entry. Stated in such general terms, these principles do not provide helpful guidance to designers. Somehow these general ideas must be converted into more specific guidelines.
The process of converting general principles into more detailed guidelines will lead to a considerable proliferation of ideas. With regard to minimizing input actions, one guideline might be that a user should not have to enter the same data twice. Probably every designer knows that, even if it is sometimes forgotten. A related guideline might be that a user should not have to enter data already entered by another user. That seems to make good sense, although one could imagine occasional exceptions when cross validation of data inputs is required.
How can duplicative data entry be avoided in practice? The solution lies in designing the user interface (programming the computer) to maintain context. Thus when a user identifies a data category of interest, say a squadron of aircraft, the computer should be able to access all previously entered data relevant to that squadron and not require the user to enter such data again.
In repetitive data entry transactions the user should have some means of establishing context. One method is to allow users to define default entries for selected data items, in effect telling the computer that those items will stay the same until the default value is changed or removed. If a user enters one item of data about a particular squadron, it should be possible to enter other items thereafter without having to re-identify that squadron.
Context should also be preserved to speed correction of input errors. One significant advantage of on-line data entry is the opportunity for immediate computer validation of user inputs, with timely feedback so that a user can correct errors while the data are still fresh in mind and while documented source data are still at hand. Here the computer should preserve the context of each data entry transaction, saving correct items so that the user does not have to enter those again while changing incorrect items.
Preservation of context is, of course, important in all aspects of user-system interaction, with implications for data display, sequence control and user guidance, as well as for data entry. The importance of context is emphasized again in the discussion of those other functional areas.
Another important design concept is flexibility. It is easy to say that the interface should adapt flexibly to user needs, but the specific means of achieving such flexibility must be spelled out in design guidelines. For data entry functions it is important that the pacing of inputs be controlled flexibly by the user. Tasks where the pacing of user inputs is set by a machine are stressful and error-prone.
Aside from flexibility in pacing, users will often benefit from having some flexible choice in the ordering of inputs. What is needed for interface design is some sort of suspense file to permit flexible ordering of data entries, including temporary omission of unknown items, backup to correct mistaken entries, cancellation of incomplete transactions, etc.
As noted above, users may also benefit from flexibility in defining default options to simplify data entry during a sequence of transactions. Some systems include only those defaults anticipated by the designers, which may not prove helpful to the user in a particular instance. Thus the concept of flexibility is related to maintaining context, and is related also to many other aspects of interface design.
The guidelines proposed here deal with data entry in terms of specific functions, covering different kinds of data entry and different kinds of computer processing support. Some topics, such as "abbreviation", which pertain to all data entry are covered in an initial group of guidelines dealing generally with the subject. A summary of the functional coverage in this section is presented on the next page. These guidelines recommend specific ways to accomplish the fundamental design objectives for data entry.
Consistency of data entry transactions Minimal entry actions by user Minimal memory load on user Compatibility of data entry with data display Flexibility for user control of data entry
Data entry refers to user actions involving input of data to a computer, and computer responses to such inputs.
Ensure that a user need enter any particular data only once, and that the computer can access those data if needed thereafter for the same task or for different tasks.
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.
When data entry is a significant part of a user's task, entered data should appear on the user's primary display.
As a negative example, entry via typewriter is acceptable only if the typewriter itself, under computer control, is the primary display medium.
When the primary display is basically formatted for other purposes, such as a graphic display for process control, a separate window on the display may have to be reserved for data entry.
Provide displayed feedback for all user actions during data entry; display keyed entries stroke by stroke.
For reasons of data protection, it may not be desirable to display passwords and other secure entries.
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.
A key press should be followed by seemingly immediate display of its associated symbol, or by some other appropriate display change.
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.
Note that this guideline refers to acknowledgment, rather than final processing of entries which may be deferred pending an explicit ENTER action.
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.
Minimize shifts from lightpen to keyboard entry and then back again.
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.
This, like other guidelines here, assumes a task-oriented user, busy or even overloaded, who needs efficiency of 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.
Data entry fields might be underlined, or perhaps highlighted by reverse video.
For general text entry of variable (unrestricted) length, no field delimiters are needed. In effect, keyed text entries can replace nothing (null characters).
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.
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.
Form filling may require typeover to replace displayed characters such as underscores that act as field delimiters.
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.
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.
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.
Allow users to pace their data entry, rather than having the pace being controlled by computer processing or external events.
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.
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.
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.
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.
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.
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.
1.4/1 | 1.4/2 | 3.0/5 | 4.0/2 | 6.0/9 | 6.3/5
Label an ENTER key explicitly to indicate its function.
As a negative example, the ENTER key should not be labeled in terms of mechanism, such as CR or RETURN or XMIT.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Expert users may sometimes wish to implement data changes without displayed feedback, as in "global replace" transactions, accepting the attendant risk.
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.
For coded data, numbers, etc., keep data entries short, so that the length of an individual item will not exceed 5-7 characters.
Coded data may include such items as badge numbers, payroll numbers, mail stops, equipment and part numbers, etc.
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.
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.
When a long data item must be entered, it should be partitioned into shorter symbol groups for both entry and display.
A 10-digit telephone number can be entered as three groups, NNN-NNN-NNNN.
Allow optional abbreviation of lengthy data items to minimize data entry keying by expert users, when that can be done without ambiguity.
Novice and/or occasional users may prefer to make full-form entries, while experienced users will learn and benefit from appropriate abbreviations.
When defining abbreviations or other codes to shorten data entry, choose them to be distinctive in order to avoid confusing similarity with one another.
BOS vs. LAS is good; but LAX vs. LAS risks confusion.
When defining abbreviations, follow some simple abbreviation rule and ensure that users understand that rule.
Simple truncation is probably the best rule when that can be done without ambiguity.
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.
Designers of military systems may wish to consult the relevant standard for abbreviations, MIL-STD-12D.
Use special abbreviations (i.e., those not formed by consistent rule) only when they are required for clarity.
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.
When an abbreviation must deviate from the consistent rule, minimize the extent of deviation.
In abbreviation by truncation, letters in the truncated form should be changed one at a time until a unique abbreviation is achieved.
Make abbreviations the same length, the shortest possible that will ensure unique abbreviations.
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.
When the computer cannot recognize an abbreviated data entry, question the user as necessary to resolve any ambiguity.
This may occur when a user enters a misremembered abbreviation.
Provide prompting for the required formats and acceptable values for data entries.
(Good)
| Vehicle type: __ | | c = Car | | t = Truck | | b = Bus |
(Bad)
| Vehicle type: __ |
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.
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.
Allow users to enter each character of a data item with a single stroke of an appropriately labeled key.
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.
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.
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.
Design data entry transactions to minimize the need for shift keying.
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.
For coded data entry, treat upper and lower case letters as equivalent.
For data codes, users find it difficult to remember whether upper or lower case letters are required, and so the software design should not try to make such a distinction. For text entry, however, conventional use of capitalized letters should be maintained.
Allow optional entry or omission of a decimal point at the end of an integer as equivalent alternatives.
An entry of "56." should be processed as equivalent to an entry of "56", and vice versa.
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.
For general numeric data, allow optional entry or omission of leading zeros as equivalent alternatives.
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".
Special cases may represent exceptions to this rule, such as entry of serial numbers or other numeric identifiers.
Treat single and multiple blank characters as equivalent in data entry; do not require users to count blanks.
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.
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.
For simple data structures, question-and-answer dialogues or form filling may suffice to maintain necessary data relations. For more complex data structures, such as those involved in graphic data entry, special techniques may be needed to help users specify the relations among data entries.
Consider spoken data input only when data entry cannot be accomplished through more reliable methods such as keyed entry or pointing.
Postal workers whose hands are occupied sorting packages might speak ZIP codes into a speech recognition device rather than keying entries.
Current speech recognition devices are not well developed and tend to be error prone. Thus there should be some good reason for choosing speech input over more conventional data entry methods. Speech input might be appropriate if a user cannot use his/her hands, perhaps because of a physical handicap or because the user's hands are needed to accomplish other tasks. Speech input may also be appropriate if a user does not have access to a suitable keyboard, as might be the case if data were being entered by telephone.
Structure the vocabulary used for spoken data entry so that only a few options are needed for any transaction.
To increase the likelihood that a user's valid entries are correctly identified by the system, the user's vocabulary should be predictable. This does not necessarily mean that the vocabulary must be small, though recognition systems that can only accommodate small vocabularies are more prevalent and less expensive. A vocabulary is predictable when a user's choice of inputs at any given time is small, so that the system will be more likely to make a correct match in interpreting an entry.
Ensure that the spoken entries needed for any transaction are phonetically distinct from one another.
Words which are easily distinguished by one speech recognition system may be confused by another. Thus system testing should be performed in order to determine what sounds a particular system tends to confuse, and what sounds it can distinguish reliably.
Provide feedback and simple error correction procedures for speech input, so that when a spoken entry has not been correctly recognized by the computer, the user can cancel that entry and speak again.
Simple error correction is particularly important with spoken data entry, since speech recognition systems are prone to error except under carefully controlled conditions.
When speech input is the only form of data entry available, allow alternatives for critical entries, so that if the system cannot recognize an entry after repeated attempts another entry can be substituted.
"Exit" might be defined as an acceptable substitute for "Finished".
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.
Spelling a word letter-by-letter is not an acceptable alternative, since speech recognition systems may have trouble correctly identifying similar sounding letters.
Provide PAUSE and CONTINUE options for speech input, so that a user can stop speaking without having to log off the system.
A user may wish to stop speaking data for a time in order to answer a telephone, or to speak with a fellow worker. Users should not have to log off the system every time they wish to say something that is not intended as an entry.
Position designation refers to user selection and entry of a position on a display, or of a displayed item.
For position designation on an electronic display, provide a movable cursor with distinctive visual features (shape, blink, etc.).
When position designation involves only selection among displayed alternatives, highlighting selected items might be used instead of a separately displayed cursor.
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.
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.
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.
Design the cursor so that it does not obscure any other character displayed in the position designated by the cursor.
A block cursor might employ brightness inversion ("reverse video") to show any other character that it may be marking.
When fine accuracy of positioning is required, as in some forms of graphic interaction, design the displayed cursor to include a point designation feature.
A cross may suffice (like cross-hairs in a telescope), or perhaps a notched or V-shaped symbol (like a gun sight).
Precise pointing will also require a cursor control device capable of precise manipulation. Touch displays, for example, will not permit precise pointing.
Require users to take a separate, explicit action, distinct from cursor positioning, for the actual entry (enabling, activation) of a designated position.
For line drawing or tracking tasks the need for rapid, continuous entry may override the need to reduce entry errors.
Ensure that the computer will acknowledge entry of a designated position within 0.2 seconds.
Almost any consistently provided display change will suffice to acknowledge pointing actions, such as brightening or flashing a selected character.
In some applications it may be desirable to provide an explicit message indicating that a selection has been made.
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.
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".
For arbitrary position designation, moving a cursor from one position to another, design the cursor control to permit both fast movement and accurate placement.
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.
Slow visual feedback of cursor movement can be particularly irritating when a user is repeatedly pressing a cursor control key, or perhaps holding the key down. In that case, slow feedback will cause the user to misjudge location and move the cursor too far.
When cursor positioning is incremental by discrete steps, design the step size of cursor movement to be consistent horizontally (i.e., in both right and left directions), and consistent vertically (in both up and down directions).
Horizontal and vertical step sizes need not be the same, and in general will not be.
When character size is variable, design the incremental cursor positioning to vary correspondingly, with a step size matching the size of currently selected characters.
If proportional spacing is used for displayed text, provide computer logic to make necessary adjustments automatically when the cursor is being positioned for data entry or data change.
Automatic proportional spacing is useful for cursor control when editing text composed for typesetting.
Manual override may help a user in special cases where automatic spacing is not wanted.
Without automatic computer aids, a user probably will not handle proportional spacing accurately.
For continuous position designation, such as needed for line drawing, provide a continuously operable control (e.g., joystick) rather than requiring a user to take incremental, discrete key actions.
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.).
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.
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.
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.).
Separately manipulated devices (lightpen, "mouse", etc.) will tend to slow the user.
Ensure that control actions for cursor positioning are compatible with movements of the displayed cursor, in terms of control function and labeling.
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.
Employ multiple cursors on a single display only when they are justified by careful task analysis.
Multiple cursors might be useful to mark a user's place when manipulating data in multiple display windows.
In graphic interaction, one cursor might be used for line drawing and a different cursor for alphanumeric data entry (labels, etc.).
Multiple cursors may confuse a user, and so require special consideration if advocated in USI design.
If multiple cursors are used, make them visually distinctive from one another.
If multiple cursors are controlled by a single device, provide a clear signal to the user to indicate which cursor is currently under control.
If multiple cursors are controlled by different devices, ensure that their separate controls are compatible in operation.
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.
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.
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.
The HOME position of the cursor should also be consistent in the different "windows" or sections of a partitioned display.
On the initial appearance of a data entry display, ensure that the cursor will appear automatically at some consistent and useful location.
In a form-filling display, the cursor should be placed in the first entry field.
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.
Programmable tab keys are customarily used for this purpose.
Automatic cursor advance is generally not desirable.
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.
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.
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.
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.
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.
Direction designation refers to user entry of directional data (azimuth, bearing, heading, etc.) on a display.
When direction designation is based on graphic representation, provide some analog means of entry, such as vector rotation on the display and/or a suitably designed rotary switch.
A rotary switch might be used to indicate heading estimations for displayed radar trails.
When approximate direction designation will suffice, for just eight cardinal points, keyed entry can be used.
For matching the directional elements in a graphic display, an entry device providing a visual analog will prove both faster and more accurate.
When designation of direction is based on already quantified data, allow keyed entry.
A heading entry might be made from a verbal report in which the direction has already been expressed numerically.
Text entry refers to the initial entry and subsequent editing of textual material, including messages.
Ensure that display capacity, i.e., number of lines and line length, is adequate to support efficient performance of text entry/editing tasks.
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.
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.
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.
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.
Allow users to do at least some simple editing during text entry without having to invoke a separate edit mode.
While entering text, users will need at least some capability for text selection (by cursor movement) and deletion.
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.
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.
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.
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.
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.
Keyed control entries might be made only in a reserved window in the display.
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.
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.
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.
Allow users to specify segments of text in whatever units are natural for entry/editing.
For unformatted ("free") text, natural units will be characters, words, phrases, sentences, paragraphs, and pages; for specially formatted text, such as computer program listings, allow specification of other logical units, including lines, subsections, sections, etc.
Allow users to specify units of text as modifiers for control entries.
Consider two alternative control sequences to delete a four-character word:
(Good) DELETE WORD
(Bad) DELETE DELETE DELETE DELETE
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.
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.
When text has been specified to become the subject of control entries, highlight that segment of text in some way to indicate its boundaries.
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.
Allow users to move the cursor by specific units of text, as well as one character at a time.
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.
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.
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.
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.
Expert users may also wish to incorporate special characters in string search, including format control characters such as those for tabbing, bolding, etc.
Unless otherwise specified by a user, treat upper and lower case letters as equivalent in searching text.
"STRING", "String", and "string" should all be recognized/accepted by the computer when searching for that word.
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.
It may also be useful for the computer to ignore such other features as bolding, underlining, parentheses and quotes when searching text.
When case is important, allow users to specify case as a selectable option in string search.
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.
Users may also wish to specify features such as bolding, underlining, and quotes when searching text.
When systematic editing changes will be made throughout a long document, consider providing a "global search and replace" capability in which the computer will replace all occurrences of one text string with another.
Global search and replace could be designed in two different ways. One user might want the computer to make all changes automatically. Another user might want to review and confirm each change. Ideally, both options should be available.
If a global search and replace capability is provided, ensure that each time a string is replaced the case of the new string matches the case of the old string, unless otherwise specified by the user.
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.
On occasion, however, a user might wish to replace an erroneous lower-case word ("Mitre") with a correctly capitalized version ("MITRE").
Provide automatic pagination for text entry/editing, allowing users to specify the page size.
For short documents, automatic pagination may not be needed.
When automatic pagination is provided, allow users to override that pagination in order to specify page numbers at any point in a document.
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.
When producing a large document, a user may wish to split it into several separate text files for convenience in editing, and hence need to control the page numbering of those component sections. In general, a user will want flexibility in assembling different computer files to create a composite document.
When automatic pagination is provided, allow users to specify the number of lines in a paragraph that will be allowed to stand alone at the top or bottom of a page (i.e., the size of "widows" and "orphans"), and to specify any text that should not be divided between two pages, such as inserted lists or tables.
For entry/editing of unformatted text, provide an automatic line break ("carriage return") when text reaches the right margin, with provision for user override.
For specially formatted text, such as computer program listings, users may need to control line structure themselves and hence need to override any automatic line break. Even when entering unformatted text, a user will sometimes wish to specify a new line at some particular point, if only for esthetic reasons.
Unless otherwise specified by the user, ensure that entered text is left-justified to maintain constant spacing between words, leaving right margins ragged if that is the result.
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.
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.
Provide easy means for users to specify required format control features during text entry/editing, e.g., to specify margin and tab settings.
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.
Required format features will vary depending on the application. For instance, font size may be quite important when composing text for typesetting but unnecessary when editing computer programs. The intent of this guideline is that all required format features should be easy to control, and should take priority in interface design. Any format features which are provided but are optional for the user's task should not be made easy to use at the expense of required format features.
When text formats must follow predefined standards, provide the standard format automatically; do not rely on users to remember and specify proper formats.
Standard formats might be required for letters, memos, or other transmitted messages.
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.
A special format might be adopted for generating a particular report at periodic intervals.
Allow users to select and move text segments from one place to another within a document.
A user should not have to re-enter (i.e., rekey) text that is already available to the computer.
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.
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.
Much text processing involves repetitive elements specific to different applications, such as signature blocks, technical terms, long names, formulas or equations.
Ensure that whatever information a user needs for text entry/ editing is available for display, as an annotation to displayed text.
A user might wish to see format control characters, such as tab and margin settings.
Required annotation will vary with the application. Some annotation may be so commonly needed that it should be continuously displayed -- e.g., document name, page number, indication of control mode (if any), etc. Other annotation might be displayed only at user request -- such as document status (date last changed, last printed, etc.) which might be displayed in an optional window overlay, and format control characters which might be visible in an optional display mode.
Ensure that annotations to displayed text are distinguishable from the text itself.
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.
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.
Allow users to display text exactly as it will be printed.
Accurate display is particularly necessary when the format of printed output is important, as when printing letters, tables, etc.
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.
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.
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.
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.
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.
This is particularly important when long documents will be edited. A user should not be required to print an entire 50-page document just because of a change to one page.
Inform users concerning the status of requests for printouts.
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.
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.
If a user is responsible for operating a local printer, the computer might display messages to alert the user of potential malfunctions, e.g., if its paper supply is exhausted, if the paper is not correctly loaded, etc.
During text entry/editing, provide an auditory signal whenever it is necessary to draw a user's attention to the display.
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.
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.
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.
It is difficult for a user to keep track of page size, particularly if the size of the display screen is less than the full page specified for printed text, which is often the case. A user will often not know when more text has been inserted into a page than there is room for. The computer should accommodate text insertions with automatic repagination.
If a DELETE mode is used, highlight any text specified by a user for deletion and require the user to confirm the DELETE action before the computer will process it.
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.
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.
Design text editing logic so that any user action is immediately reversible.
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.
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.
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.
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.
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.
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.
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.
During text editing, the computer should always retain a copy of the original document until the user confirms that it should be changed. The original document should not be changed automatically as the user enters each editing change.
Data forms permit entry of predefined items into labeled fields of specially formatted displays.
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.
|-----------------------------------------------------| | 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. | |-----------------------------------------------------|
|-----------------------------------------------------| | Name Andrew D. Jones Visa Number 356478 | | | | Birthplace London Nationality English | | | | Passport Z196284 Birthdate Mar. 22, | | | | Address 1925 | | 5 Fairview Lane, Loughborough, L | | E11 3RG, England | | | | Other travelers on this visa | | Traveler's Name Date of Birth - Place | | Sandra J. Jones Oct. 11, - 1928 | | Birmingham | | Cynthia L. Jones June 12, - 1968 | | Paris, France# | | | | | | | | | | | | | | | | Press ENTER when done | |-----------------------------------------------------|
This bad data form display violates in some degree several design guidelines in this section: 1.4/3 Minimal use of delimiters 1.4/6 Consistent labeling 1.4/10 Marking field boundaries 1.4/11 Prompting field length 1.4/15 Explicit tabbing to data fields 1.4/16 Distinctive label format 1.4/18 Label punctuation as entry cue 1.4/19 Informative labels 1.4/20 Data format cueing in labels 1.4/25 Form compatible with source documents This bad data form also violates various design guidelines pertaining to data display, as noted at the end of Section 2.2.
In a form-filling dialogue, when a user is entering logically related items, require just one explicit entry action at the end of the transaction sequence, rather than separate entry of each item.
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.
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.
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.
1.0/9 | 3.3/3 | 3.3/4 | 3.3/5 | 3.5/2 | 6.0/10 | 6.3/8
Whenever possible, allow entry of multiple data items without keying special separator or delimiter characters, e.g., hyphens, dollar signs, etc.
See sample displays in this section.
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.
When data items contain internal blanks, design the entry fields with a predefined structure so that users will not have to key any internal delimiters.
When a field delimiter must be used for data entry, adopt a standard character to be employed consistently for that purpose.
A slash (/) may be a good choice.
Choose a special delimiter character that does not require shift keying. It will also be necessary to choose a character that does not occur as part of any data entry (except possibly for entry of running text where its occurrence would not be ambiguous).
For each data field, display an associated label to help users understand what entries can be made.
(Good)
| NAME: __ __ __ __ __ __ __ __ __ __ __ | | | | ORGANIZATION: __ __/__ __ | | | | PHONE: __ __ __-__ __ __ __ |
(Bad)
| NAME, ORGANIZATION AND PHONE | | | | __ __ __ __ __ __ __ __ __ __ __ __ | | | | __ __ __ __ | | | | __ __ __ __ __ __ __ |
Make field labels consistent; always employ the same label to indicate the same kind of data entry.
A field labeled NAME should always require name entry, and not sometimes require something different like elevation (cited from an actual system).
See sample displays in this section.
Protect field labels from keyed entry, by making the cursor skip over them automatically when a user is spacing or tabbing.
When a user must change a displayed form, including changes to field labels, then that user must be able to override label protection.
1.1/23 | 2.0/10 | 6.2/5 | 6.3/2
Ensure that labels are sufficiently close to be associated with their proper data fields, but are separated from data fields by at least one space.
Choose a standard symbol for input prompting and reserve that symbol only for that use.
In the examples here, and also in many printed forms, a colon serves to prompt inputs, as
(Good) | TIME: ________ |
(Bad) | TIME ________ |
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.
Display special characters or other consistent means of highlighting to clearly delineate each data field.
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: |
See sample displays in this section.
Such implicit prompts help reduce data entry errors by the user.
Provide cues in field delineation to indicate when a fixed or maximum length is specified for a data entry.
(Good) | Enter ID: __ __ __ __ __ __ __ __ __ |
(Bad) | Enter ID (9 characters): |
See sample displays in this section.
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.
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.
In designing form displays, distinguish clearly and consistently between required and optional entry fields.
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: . . . . . . . . . . . |
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.
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.
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.
When item length is variable, provide automatic justification in computer processing; a user should not have to justify an entry either right or left.
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____ |
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.
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.
See sample displays in this section.
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.
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.
Labels might be displayed in capital letters always followed by a colon. Or labels might be displayed in dim characters, with data entries brighter.
See sample displays in this section.
When data fields are distributed across a display, adopt a consistent format for relating labels to delineated entry areas.
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.
Such consistent practice will help the user distinguish labels from data in distributed displays.
The label for each entry field should end with a special symbol, signifying that an entry may be made.
A colon is recommended for this purpose, as
| NAME: __ __ __ __ __ __ __ __ __ __ __ |
See sample displays in this section.
Choose a symbol that can be reserved exclusively for prompting user entries, or at least is rarely used for any other purpose.
In labeling data fields, employ descriptive wording, or else standard, predefined terms, codes and/or abbreviations; avoid arbitrary codes.
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.
(Good)
| WEEK: __ MONTH: __ __ YEAR: __ __ | | | | SOCIAL SECURITY NO: __ __ __ - __ __ - __ __ __ __ |
(Bad)
| DATECODE: __ __ __ __ __ | | | | SSAN: __ __ __ __ __ __ __ __ __ |
See sample displays in this section.
Do not create new jargon. If in doubt, pretest all proposed wording with a sample of qualified users.
Include in a field label additional cueing of data format when that seems helpful.
| DATE (MM/DD/YY): __ __/__ __/__ __ |
See sample displays in this section.
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.
| COST: $ __ __ __ __ |
| SPEED (MPH): __ __ __ |
Employ units of measurement that are familiar to the user.
(Good)
| SPEED LIMIT: __ __ miles per hour |
(Bad)
| SPEED LIMIT: __ __ feet per second |
(Good)
| FUEL USE: __ __.__ miles per gallon |
(Bad)
| FUEL USE: .__ __ gallons per minute |
If data must be converted to unfamiliar units, the computer should handle that automatically.
When alternative measurement units are acceptable, provide space in the data field so that a user can designate the units actually entered.
| DISTANCE: __ __ __ __ (MI/KM) __ __ |
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.
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.
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.
See sample displays in this section.
If paper forms are not optimal for data entry, consider revising the layout of the paper form.
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.
2.5/1 | 2.5/14 | 3.1.1/4 | 4.0/6
When designing displays for form-filling data entry, minimize user actions required for cursor movement from one field to the next.
Placing all required fields before any optional fields will sometimes make data entry more efficient.
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.
The software designer will need to work with prospective system users to determine what represents a logical sequence of data entries.
When a form for data entry is displayed, the computer should place the cursor automatically at the beginning of the first entry field.
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.
Tables permit data entry and display in row-column format, facilitating comparison of related data sets.
When sets of data items must be entered sequentially, in a repetitive series, provide a tabular display format where data sets can be keyed row by row.
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.
Row-by-row entry facilitates comparison of related data items, and permits potential use of a DITTO key for easy duplication of repeated entries.
Design distinctive formats for column headers and row labels, so that users can distinguish them from data entries.
Ensure that column headers and row labels are worded informatively, so that they will help guide data entry.
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).
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).
Provide automatic justification of tabular data entries; a user should not have to enter blanks or other extraneous formatting characters to achieve proper justification.
As a negative example, if a user enters "56" in a field four characters long, the system should not interpret "56 __ __" as "5600".
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.
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.
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.
For entry of tabular data, when entries are frequently repeated, provide users with some easy means to copy duplicated data.
Perhaps a DITTO key might be provided.
A DITTO capability will speed data entry, and should prove more accurate than requiring users to rekey duplicated data.
For long tables, those with many rows, provide some extra visual cue to help a user scan a row accurately across columns.
A blank line might be inserted after every fifth row; or perhaps adding dots between columns in every fifth row might suffice.
As an alternative, provide a displayed ruler which a user can move from one row to another.
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.
Graphics permit entry of data specially formatted to show spatial, temporal, or other relations among data sets.
When graphic data entry involves frequent pointing on a display surface, design the user interface so that actions for display control and sequence control are also accomplished by pointing, in order to minimize shifts from one entry device to another.
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.
Alphabetic entry for titles, labels, and other annotation of graphic displays will be accomplished more quickly by conventional keyboard input than by pointing.
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.
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.
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.
Indicate the current cursor position by displaying some distinctive cursor symbol at that point.
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.
Provide users an easy, accurate means of positioning a displayed cursor to point at different display elements and/or display locations.
Cursor positioning is a frequent user action during graphic data entry; an easy means for controlling cursor movement will be essential for efficient performance.
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.
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).
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.
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.
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.
Provide users some means for designating and selecting displayed graphic elements for manipulation.
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.
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.
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.
When editing graphic data, allow users to reposition selected elements on the display.
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.
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.
When editing graphic data, allow users to delete selected elements from the display.
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.
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.
For line drawing a user might select from displayed samples of thick or thin, solid or broken, etc.
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.
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.
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.
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.
If only a few colors are available, their names can probably be used reliably.
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.
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.
During graphic data entry/editing, display the selected attributes that will affect current actions for ready reference by the user.
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.
A few attributes might be shown by the displayed cursor, i.e., by changing cursor shape, size or color depending upon current attribute selections.
If rubberbanding is provided to aid line drawing, then that process itself would show the currently selected line type.
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.
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.
1.6.2/2 | 3.0/9 | 4.0/9 | 4.4/13 | 3.4
When entering or editing graphic data, allow users to change display attributes -- e.g., line type, cross-hatching, color -- for selected graphic elements.
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.
If it is easy to change attributes, reversing earlier data entry decisions, then the process of composing graphic displays will be generally easier.
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.
When editing graphic data, allow users to change display attributes by whatever means were used to select those attributes in the first place.
If line type is selected initially from a menu of displayed attributes, then changing a line type should also be accomplished via menu selection.
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.
Provide easy means for saving and retrieving graphic displays or their component elements at different stages in their creation.
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.
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.
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.
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.
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.
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.
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.
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.
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.
When graphic data represent relations among real objects, provide appropriate computer logic based on models of physical probability to validate data entries.
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.
If inconsistencies of data entry cannot be resolved immediately, the computer might keep track of unresolved questions pending receipt of further data.
Plotting data to show their relations in various graphic formats can be aided greatly by appropriate software.
When complex graphic data must be entered quickly, provide computer aids to automate that process.
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.
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.
Provide automated plotting of computer-stored data at user request, with provision for subsequent editing by a user.
A computer might plot the data values from two arrays in a line graph, or three-dimensional data in XYZ coordinates.
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.
When graphic data must be plotted in predefined standard formats, provide templates or skeletal displays for those formats to aid data entry.
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.
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.
When graphs must be constructed for data plotting, provide computer aids for that purpose.
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.
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.
Provide computer aids to help users specify appropriate scales for graphic data entry.
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.
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.
When graphic data can be derived from data already available in the computer, provide machine aids for that purpose.
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.
The machine capacity for generating graphic data by computation will far exceed a user's capabilities in both speed and accuracy.
Drawing lines and figures to produce pictorial data of various kinds can be aided greatly by appropriate software.
When line drawing is required, provide users with aids for drawing straight line segments.
Some applications may require drawing continuous lines freehand.
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.
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.
When line segments must join or intersect, which is true in most drawing, provide computer logic to aid such connection.
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.
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.
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.
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.
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.
When a reference grid is displayed to aid graphic data entry, allow users to change the grid intervals in either or both directions.
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.
When graphic elements are created with vertical and horizontal lines, allow users to specify appropriate constraints during line drawing.
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.
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.
For precise drawing, allow users to draw lines by specifying their geometric relations with other lines.
In computer-aided design, a user might wish to create a new line by declaring it parallel with (or perpendicular to) an existing line.
When a user must draw figures, provide computer aids for that purpose.
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.
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.
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.
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.
In applications requiring a general capability for drawing figures, provide a choice of methods for specifying graphic elements.
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.
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.
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.
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.
These examples are from the demanding realm of computer-aided design. Simpler kinds of graphic entry may not require such capabilities.
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.
When editing graphic data, allow users to change the size of any selected element on the display.
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.
Depending on the application, it may be helpful to provide a continuous sizing capability, or else incremental sizing to various defined scales.
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.
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.
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.
Allow users to copy a selected graphic element in order to duplicate it elsewhere or create a repeating pattern.
Many graphic displays contain repeating elements; copying an element already created may prove quicker than redrawing that element from scratch.
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.
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.
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.
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.
When users must create symmetric graphic elements, provide a means for specifying a reflection (mirror image) of existing elements.
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.
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.
Allow users to designate a group of elements to which graphic editing operations will be applied in common.
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.
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.
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.
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.
This technique can represent the intersection of solid objects and also the result of drilling holes in an object.
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.
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.
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.
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.
The computer might automatically add dimensional annotation to drafted figures.
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.
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.
A computer might create perspective drawings automatically from plan and elevation data, with hidden parts eliminated.
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).
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.
An aerodynamic model might be invoked to help create (and evaluate) an aircraft wing design.
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.
Different kinds of models might be needed, including models based on geometric, surface, and solid relations, as well as even more complex logical models.
Data validation refers to checking entries for correct content and/or format, as defined by software logic.
Provide software for automatic data validation to check any item whose entry and/or correct format or content is required for subsequent data processing.
If a date is entered as "February 31", the computer should generate an error message asking for a revised entry.
Do not rely on a user always to make correct entries. Computer aids for checking data entries will improve accuracy.
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.
Ensure that every possible correct data entry will be accepted and processed properly by the computer.
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.
This guideline states the obvious, and might seem unnecessary except for occasional design lapses such as that cited in the example.
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.
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.
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.
In a repetitive data entry task, validate the data for one transaction and allow the user to correct errors before beginning another transaction.
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.
For novice users, consider providing optional item-by-item data validation within a multiple-entry transaction.
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.
Other data processing aids may be provided to facilitate data entry.
When likely default values can be defined for the data entries in a particular task, offer those default values to speed data entry.
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.
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.
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.
On initiation of a data entry transaction, display currently defined default values in their appropriate data fields.
Do not expect users to remember them.
It may be helpful to mark default values in some way to distinguish them from new data entries.
Provide users with some simple means to confirm acceptance of a displayed default value for entry.
Simply tabbing past the default field may suffice.
Employ similar techniques when a user must review the accuracy of previously entered data.
Allow users to replace any data entry default value with a different entry, without thereby changing the default definition for subsequent transactions.
For routine data that can be derived from existing computer records, program the computer to access and enter such data automatically.
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.
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.
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.
Statistical descriptors such as sums, means, etc., can all be derived automatically by appropriate software.
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.
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.
As a negative example, a user should not have to enter both an item name and identification code when either one defines the other.
Redundant entry may be needed for resolving ambiguous entries, for user training, or for security (e.g., user identification).
When verification of previously entered data is required, ask users to review and confirm data items rather than re-enter them.
Provide automatic cross-file updating whenever necessary, so that a user does not have to enter the same data twice.
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.
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.
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.
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.
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.
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.
Design change of software supporting data entry functions may be needed to meet changing operational requirements.
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.
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.
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.
1.3/22 | 1.4/25 | 1.7/1 | 1.8/3 | 1.8/8 | 1.8/10 | 1.8/11
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents | | | Top |