|
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 protection attempts to ensure the security of computer-processed data from unauthorized access, from destructive user actions, and from computer failure. With increasing use of computer-based information systems, there has been increasing concern for the protection of computer-processed data. Data protection is closely allied with other functional areas. The design of data entry, data display, sequence control, user guidance, and data transmission functions can potentially affect the security of the data being processed. In many applications, however, questions of data protection require explicit consideration in their own right.
Data protection must deal with two general problems. First, data must be protected from unauthorized access and tampering. This is the problem of data security. Second, data must be protected from errors by authorized system users, in effect to protect users from their own mistakes. This is the problem of error prevention.
Design techniques to achieve data security and to prevent user errors are necessarily different, but for both purposes the designer must resolve a fundamental dilemma. How can the user interface be designed to make correct, legitimate transactions easy to accomplish, while making mistaken or unauthorized transactions difficult? In each system application, a balance must be struck between these fundamentally conflicting design objectives.
Concern for data security will take different forms in different system applications. Individual users may be concerned with personal privacy, and wish to limit access to private data files. Corporate organizations may seek to protect data related to proprietary interests. Military agencies may be responsible for safeguarding data critical to national security.
The mechanisms for achieving security will vary accordingly. Special passwords might be required to access private files. Special log-on procedures might be required to assure positive identification of authorized users, with records kept of file access and data changes. Special confirmation codes might be required to validate critical commands.
At the extreme, measures instituted to protect data security may be so stringent that they handicap normal system operations. Imagine a system in which security measures are designed so that every command must be accompanied by a continuously changing validation code which a user has to remember. Imagine further that when the user makes a code error, which can easily happen under stress, the command sequence is interrupted to re-initiate a user identification procedure. In such a system, there seems little doubt that security measures will reduce operational effectiveness.
In recent years, computer security measures have concentrated increasingly on automatic means for data protection, implemented by physical protection of computing equipment and by tamper-proof software. Automation of security makes good sense. If data security can be assured by such means, there will be less need to rely on fallible human procedures. And, of course, user interface design will be that much easier.
It seems probable, however, that absolute data security can never be attained in any operational information system. There will always be some reliance on human judgment, as for example in the review and release of data transmissions, which will leave systems in some degree vulnerable to human error. Thus a continuing concern in user interface design must be to reduce the likelihood of errors, and to mitigate the consequences of those errors that do occur.
Like data security, error prevention is a relative matter. An interface designer cannot reasonably expect to prevent all errors, but frequent user errors may indicate a need for design improvement. Data protection functions must be designed 1) to minimize the entry of wrong data into a system; 2) to minimize mistakes that make wrong changes to stored data; and 3) to minimize the loss of stored data. In considering these objectives, prevention of catastrophic data loss is vital for effective system operation, but all three aspects of data protection are important.
Data entry and change transactions are, of course, frequently performed by system users. Careful interface design can help prevent many errors in those transactions, by providing automatic data validation and reversible control actions, as described in previous sections of these design guidelines. But the designer needs a good deal of ingenuity in applying guidelines within the context of each data handling job.
The use of job context for computer validation of user inputs is best illustrated by example. As one such example (Bertoni, 1982), a local newspaper published the following discussion of data entry error prevention, suggesting ways to reduce billing errors: . . . designers of applications systems have resorted to a number of strategies to minimize ill effects and keep the errors from escaping into the world at large. The commonest of these is the process known as 'verification,' which in its simplest form, means instructing the system to respond to input with the figurative question, 'Do you really mean that?' That is, when a data[-entry] operator enters an amount, or name, or serial number -- the system draws attention to the just-typed item (by causing it to flash on-screen, for example). The operator then is supposed to take a good hard look at the item and press a verification key if the data is correct. Better yet, what you need is for the system to do some checking on its own . . . to a certain extent, it can use internal evidence (and the percentages) to perform its own verification. Here's a simple strategy that, though currently used to some extent, will some day become universal, one hopes. It's good because it relies on an understanding of human habits. Let's take billing again. Most times, when you pay a bill, you pay either the minimum amount due or the full balance. Suppose we instruct the machine to compare the operators entry of 'amount paid' with the minimum due and with the full balance for that particular account. If the entry is equal to one or the other, pass it on through. It's very likely correct. If there's a discrepancy, discontinue entry and signal the operator to check the amount. And it does so optimally: the right ones pass through with minimum slow down, the potential wrong ones get the attention.
Similar reasoning might be applied in other data entry jobs. Once data are correctly entered into a computer, the emphasis shifts to prevention of unwanted changes to the data, including the extreme form of change represented by data loss. Stored data must be protected from unreliable computer operation and also from system users. Advances in computer technology, with less volatile memory, automatic archiving to back-up data stores, and redundant processing facilities, have significantly reduced the hazard of data loss resulting from machine failure. What remains is to reduce the hazard of human failure.
In the interface design guidelines presented here, the primary concern is for the general users of computer systems. But data protection from human error requires consideration in other aspects of system design and operation. In particular, the expert operators who maintain and run the computer system must assume a large responsibility for data protection.
Consider the following example. In one computer center, an operator must enter a command "$U" to update an archive tape by writing a new file at the end of the current record, while the command "$O" will overwrite the new file at the beginning of the tape so that all previous records are lost. A difference of one keystroke could obliterate the records of years of previous work. Has that ever happened? Yes, it has. If an error can happen, then it probably will happen.
In that respect, expert computer operators are just like the rest of us. When tired, hurried, or distracted, they can make mistakes. And not all computer operators are experts. Some are still learning their jobs, and so may be even more error-prone. Careful design and supervision of operating procedures is needed to minimize data processing errors.
If data loss from machine failure and data loss from faulty system operation are minimized through careful design, then the most serious threat to data protection is the system user. This is especially true in applications where the user must participate directly in establishing and maintaining stored data files. Means must be found to protect files from inadvertent erasure.
Some difficult design trade-offs may be required. As an example, consider a possible design guideline that might say that a user should not be allowed to change or delete data without first displaying the data. In a file deletion transaction it would usually be impractical to force a user to review the entire file. One might imagine displaying just the first page of a file nominated for deletion, and requiring the user to CONFIRM the DELETE action. But even that would be disruptive in many circumstances.
As a fall-back position, we might recommend that when a file has been nominated for deletion enough descriptive information should be displayed about that file so that a reasonably attentive user can determine whether that file should be deleted. The issue is how to ensure that the user intends to do what s/he is actually doing.
When a user selects a file for deletion, at least as much information should be provided as when a user selects a file for display and editing. Thus, if an on-line index of displayable files contains a line of information about each one, perhaps including name, description, size, and currency (date last changed), then such information would also be appropriate in prompting the CONFIRM action for file deletion:
| CONFIRM DELETION of the following file: |
| USIplan, 5-year plan for USI effort, 3 pages, 11-25-83 |
Any required confirmation procedure, of course, will tend to slow file deletion, in accord with the general guideline that destructive actions should be made difficult. Where is the trade-off when destructive actions are also frequent? What about the user who wishes to scan a file index and delete a series of files? Must each separate DELETE action be confirmed? Unless DELETE actions are easily reversible, the answer for most users is that an explicit confirmation probably should be required for each file deletion. When a user must undertake a series of file deletions, the repetitive nature of the task may increase the risk of inadvertent deletion, and so increase the need for CONFIRM protection.
Explicit DELETE commands are not the only actions that can result in accidental file erasure. In some systems, it is possible to overwrite a stored file with whatever data are currently on-line, in "working" storage. Used properly, this capability permits desired editing and replacement of files. A user might call out a file, make changes to it, and then store it again under its own name.
Used improperly, this capability risks file deletion. A user might call out and edit a file, but then absent-mindedly store it with the name of another file, thus overwriting whatever data had been previously stored in that other file. Such a hazard requires just as much protection as an outright DELETE action, or perhaps even more since the danger is more subtle. In effect, an explicit CONFIRM action should be required whenever a user attempts to store a data file under the name of any other file already stored in the system. The prompt for confirmation might read something like this:
| CONFIRM OVERWRITING the current file of this name: |
| SCG, sequence control guidelines, 45 pages, 10-08-83 |
It is interesting that many systems do not require this kind of selective confirmation. One well-known system requires user confirmation of every overwrite action, even in the common case where an edited file is being stored by the same name to replace its previous version. Thus the CONFIRM action itself becomes routine, and no longer provides any significant protection to a forgetful user. Another system avoids the problem by the rigid expedient of allowing a user to store an edited file only under its last previous name, which is safe but sometimes inconvenient.
To some extent a wary user can protect her/himself by careful selection of file names, trying to ensure that any file name is descriptive of file content, and also distinctive in comparison with the names of other files. In practice, that goal is hard to achieve. Users often work with groups of files dealing with different aspects of a common topic. For such files, if names are descriptive they will tend to be similar rather than distinctive. If file names are made longer in order to become more distinctive, then those longer names may reduce efficiency when using file names for storage and retrieval.
In systems where there is no effective on-line protection against inadvertent file deletion or replacement, either a user must be exceedingly careful, or else the system must provide effective off-line procedures to recover from archived records an earlier version of an accidentally erased file. Neither alternative is entirely satisfactory. Even a careful user will make mistakes. And archives will not protect a user from loss of current work.
A better solution can be provided by on-line computer aids to make user actions reversible. In effect, user interface software should be designed to permit users who notice unintended deletions to retrieve lost files by taking an UNDO action. Some current systems provide such an UNDO capability, permitting users to change their minds and to correct their more serious mistakes.
There must be, of course, some practical time limit to the reversibility of data processing. A user might be able to UNDO the last previous deletion, or perhaps even all deletions made during the current working session, but there seems no feasible way to make it easy to undo a particular deletion made days ago and now regretted. Moreover, reversibility will not help a user who does not notice that a mistake has been made. So even where an UNDO capability is available, other aspects of the user interface must still be carefully designed.
The guidelines proposed in the following pages illustrate the range of topics to be considered in this area, and the general need for many kinds of data protection. These guidelines draw heavily from recommendations already made in previous sections, as indicated by extensive cross referencing. In this new context of data protection, some previous guidelines have been slightly reworded, others preserved intact. They are repeated here for the convenience of a designer who must review all material pertinent to data protection functions.
These guidelines do not resolve the fundamental design dilemma discussed above, namely, how to make a system easy to use but hard to misuse. The guidelines do, however, indicate where design decisions must be made.
Objectives
Effective data security
Minimal entry of wrong data
Minimal loss of needed data
Minimal interference with information handling tasks
Data protection concerns security from unauthorized use, and potential loss from equipment failure and user errors.
Whenever possible provide automated measures to protect data security, relying on computer capabilities rather than on more fallible human procedures.
Comment
For protection against unauthorized users, who may be intruders in a
system, the need for automated security measures is clear. For
legitimate users, the need for data protection is to minimize data loss
resulting from potentially destructive equipment failures and user
errors. Even careful, conscientious users will sometimes make mistakes,
and user interface logic should be designed to help mitigate the
consequences of those mistakes.
Provide computer logic that will generate messages and/or alarm signals in order to warn users (and system administrators) of potential threats to data security, i.e., of attempted intrusion by unauthorized users.
Comment
For protecting data from unauthorized use, it may not be enough merely
to resist intrusion. It may also be helpful if the computer can detect
and report any intrusion attempts. In the face of persistent intrusion
attempts, it may be desirable to institute countermeasures of some sort,
such as changing user passwords or establishing other more stringent
user authentication procedures.
Reference
See also
6.1/6
Provide automatic measures to minimize data loss from computer failure.
Example
Depending upon the criticality of the application, different protective
measures may be justified, including periodic automatic archiving of
data files, maintenance of transaction logs for reconstruction of recent
data changes, or even provision of parallel "backup" computing
facilities.
Comment
An automatic capability is needed because users cannot be relied upon to
remember to take necessary protective measures.
Comment
Though not strictly a feature of user interface design, reliable data
handling by the computer will do much to maintain user confidence in the
system. Conversely, data loss resulting from computer failure will
weaken user confidence, and reduce user acceptance where system use is
optional.
Reference
Protect data from inadvertent loss caused by the actions of other users.
Comment
In systems where information handling requires the coordinated action of
multiple users, it may be appropriate that one user can change data that
will be used by others. But when multiple users will act independently,
then care should be taken to ensure that they will not interfere with
one another. Extensive system testing under conditions of multiple use
may be needed to determine that unwanted interactions do not occur.
Comment
When one user's actions can be interrupted by another user, as in
defined emergency situations, that interruption should be temporary and
nondestructive. The interrupted user should subsequently be able to
resume operation at the point of interruption without data loss.
Reference
See also
3.0/22
When a proposed user action will interrupt a current transaction sequence, provide automatic means to prevent data loss; if potential data loss cannot be prevented, warn the user and do not interrupt without user confirmation.
Example
If a user should interrupt a series of changes to a data file, then the
computer might automatically save both the original and the changed
versions of that file for subsequent user review and disposition.
Comment
Some interrupt actions such as BACKUP, CANCEL, or REVIEW, will by their
definition cause only limited data change, and so need no special
protection. However, if an interrupt action may cause extensive data
change (e.g., RESTART, LOG-OFF), then require the user to confirm that
action before processing.
Reference
See also
3.3/6
When simulated data and system functions are provided (perhaps for user training), ensure that real data are protected and real system use is clearly distinguished from simulated operations.
Reference
Provide clear and consistent procedures for different types of transactions, particularly those involving data entry, change and deletion, and error correction.
Comment
Consistent procedures will help users develop consistent habits of
operation, reduce the likelihood of user confusion and error, and are
especially important for any transaction that risks data loss.
Reference
See also
4.0/1
Ensure that the ease of user actions will match desired ends; make frequent or urgent actions easy to take, but make potentially destructive actions sufficiently difficult that they will require extra user attention.
Ensure that the computer changes data only as a result of explicit actions by a user, and does not initiate changes automatically.
Exception
In an operations monitoring situation, a computer might accept data
changes automatically from external sources (sensors), if appropriate
software is incorporated to ensure validation and protection of the
input data.
Exception
A computer might perform cross-file updating automatically, following
data change by a user.
Comment
The aim here is to preserve clarity of system operation for the user.
In effect, a computer should not initiate data changes unless requested
(and possibly confirmed) by a user. Well-intentioned interface
designers are sometimes tempted to contrive "smart shortcuts" in which
one user action might automatically produce several other associated
data changes, perhaps saving the user a few keystrokes in special cases.
If such shortcuts cannot be made standard procedures, they will tend to
confuse users and thus pose a potential threat to data protection.
See also
1.0/9
|
1.1/4
|
3.0/5
|
3.1.3/6
|
3.5/6
|
4.0/2
|
5.0/6
For all inputs, whether data entries or commands, allow users to edit composed material before requesting computer processing.
Comment
Input editing will allow users to correct many errors before computer
processing. When an error is detected, a user will be able to fix it by
editing, i.e., without having to retype any correct items (which might
introduce further errors).
Reference
See also
1.4/2
|
3.5/2
|
4.3/15
When function keys and other devices are not needed for current control entry, and especially when they may have destructive effects, disable them temporarily under software control so that they cannot be activated by a user.
Comment
Some means should also be provided to help users distinguish currently
active from disabled controls, such as brightening (active) or dimming
(disabled) their associated labels. If labeling is adequate, then user
selection of a disabled control need produce no response. If adequate
labeling cannot be provided, then user selection of a disabled control
should produce an advisory message that the control is not currently
active.
If activation of function keys (and other control devices) may result in data loss, locate them separately and/or physically protect them to reduce the likelihood of accidental activation.
Reference
See also
3.1.4/18
If automatic defaults are provided for control entries, ensure that those defaults will protect against data loss, or at least not contribute to the risk of data loss.
Example
When requesting a printout of filed data, one control option might be to
delete that file after printing; the default value for such a
destructive option should automatically be set to NO whenever the
printing options are presented to a user for selection.
Ensure that user interface software will deal appropriately with all possible user errors and random inputs, without introducing unwanted data change.
Comment
The interface designer must try to anticipate every possible user
action, including random keying and perhaps even malicious
experimentation. The user interface should be "bullet-proofed" so that
an unrecognized entry at any point will produce only an error message
and will not change stored data.
Reference
See also
3.5/1
Require users to take explicit action to select any operational mode that might result in data loss; the computer should not establish destructive modes automatically.
Example
In text editing, if a user takes a DELETE action, that in itself should
not establish a continuing DELETE mode.
Comment
In many applications, it may be better not to provide any destructive
mode. Instead of providing a DELETE mode, for example, require that
DELETE be a discrete action subject to confirmation by the user when the
requested data deletion is extensive. User interface design must
determine the proper balance here between data protection and
operational efficiency.
When the result of user actions will be contingent upon prior selection among differently defined operational modes, provide a continuous indication of the current mode, particularly when user inputs in that mode might result in data loss.
Example
If a DELETE mode is being used to edit displayed data, some indication
of that mode should be continuously displayed to the user.
Comment
A user cannot be relied upon to remember prior actions. Thus any action
whose results are contingent upon previous actions can represent a
potential threat to data protection.
Reference
See also
4.2/8
For conditions which may require special user attention to protect against data loss, provide an explicit alarm and/or warning message to prompt appropriate user action.
See also
3.5/8
|
4.3/14
|
4.3/19
Require users to take an explicit extra action to CONFIRM a potentially destructive control entry before it is accepted by the computer for execution.
Reference
See also
1.3/32
|
1.3/34
|
3.1.5/25
|
3.5/7
|
4.3/18
Provide a distinctively labeled CONFIRM function key for user confirmation of potentially destructive actions.
See also
3.5/9
Require users to wait for computer prompting in order to CONFIRM a potentially destructive action, so that the confirmation will constitute a second, separate action.
Example
| Enter next command| D__ |
| |
| If deleted, all data in this file will be lost. |
| Enter YES to confirm deletion: ______ |
Comment
No single user action should cause significant change or loss of stored
data, such as deleting an entire data file. Requiring users to strike
two keys, such as DELETE followed immediately by CONFIRM, is not
sufficient protection; such double keying may become habitual. The
DELETE and CONFIRM actions must be separated by some computer response
to help ensure user attention.
Reference
Allow users to UNDO an immediately preceding control action that may have caused an unintended data loss.
Comment
Some sort of an UNDO capability is now commonly provided in interface
design. UNDO represents one more level of data protection, when warning
messages and confirmation procedures fail to prevent error, but can only
help the user who notices that an error has been made.
Comment
In order to implement an UNDO capability, the computer must maintain a
record of data changes resulting from current transactions. How long
should that record be, i.e., how many transactions should be reversible?
Should a user be able to reverse all transactions back to the beginning
of a work session? Or all transactions within some defined sequence?
Or just the most recent transaction, as recommended here? Whatever UNDO
capability is provided, its limitations should be made clear to users.
Comment
Some designers recommend that UNDO itself should be reversible, so that
a second UNDO action will do again whatever was just undone. Such a
capability implies that UNDO will affect only the last previous
transaction, whatever that was. An alternative would be to offer two
different UNDO options, one to reverse mistaken actions and one to
reverse mistaken UNDO's, risking considerable user confusion.
Reference
User identification procedures should be as simple as possible, consistent with adequate data protection.
Design the LOG-ON process and procedures for user identification to be as simple as possible consistent with protecting data from unauthorized use.
Comment
Some security experts recommend that LOG-ON be made deliberately
difficult in order to discourage intruders to a system, and even that
the system not indicate the successful completion of a LOG-ON sequence.
Such measures will confound legitimate users more often than they will
impede intruders, and are not recommended here. A better approach would
be to keep the initial LOG-ON simple, and then impose some auxiliary
procedure to authenticate user identity.
Comment
Authentication of user identity is generally not enhanced by requiring a
user to enter routine data such as terminal, telephone, office or
project numbers. In most organizations, those data can readily be
obtained by other people. If verification of those data is needed, the
user should be asked to review and confirm currently stored values in a
supplementary procedure following LOG-ON.
Reference
See also
1.8/7
Design the LOG-ON process to provide prompts for all user entries, including passwords and/or whatever other data are required to confirm user identity and to authorize appropriate data access/change privileges.
Reference
When passwords are required, allow users to choose their own passwords.
Comment
A password chosen by a user will generally be easier for that individual
to remember. User choice is especially helpful when passwords must be
periodically changed, with changing demands on memory.
Comment
In the interests of security, users should be given some guidelines in
password selection, so that they will not choose easily guessable
nicknames or initials, and will choose passwords of sufficient length to
resist random guessing.
Comment
Some security experts recommend that passwords of nonsense material be
composed by a computer and arbitrarily assigned to users, in order to
make it more difficult for intruders to guess a password. Such measures
will confound legitimate users more often than they will impede
intruders, and are not recommended here. A better approach would be to
keep passwords memorable, for initial system access, and then impose
some auxiliary procedure to authenticate user identity in applications
where passwords are considered insufficient protection.
Reference
Allow users to change their passwords whenever they choose.
Comment
A user may sometimes suspect that a password has been disclosed, and
thus wish to change it.
Comment
In addition to optional changes by users, it may also be good security
practice for a system to enforce password changes for all users at
periodic intervals.
Reference
When a password must be entered by a user, ensure that password entry can be private; password entries should not be displayed.
Comment
Covert entry of passwords will prevent casual eavesdropping by
onlookers. This represents an exception to the general recommendation
that all entries should be displayed.
Comment
In the interests of security, it might be noted that passwords should
also not be retained in readable form in computer memory, although this
is not an issue of user interface design.
Reference
See also
1.0/3
Impose a maximum limit on the number and rate of unsuccessful LOG-ON attempts that will provide a margin for user error while protecting the system from persistent attempts at illegitimate access.
Comment
Legitimate users will sometimes have difficulty completing a successful
LOG-ON, perhaps due to inattention, or a faulty terminal, or faulty
communications. Occasional LOG-ON failures of that kind should be
tolerable to the system, with the user simply invited to try again.
Comment
A record of continuing failure by any particular user to complete
successful LOG-ON procedures, including password entry and other tests
of claimed user identity, may indicate persistent intrusion attempts.
Repeated LOG-ON failures might thus be grounds for denying access to
that user. Access might be denied temporarily for some computer-imposed
time interval, or indefinitely pending review by a system administrator.
The occasional inconvenience to a legitimate user may be tolerable in
the interests of increased system security. Analysis of this tradeoff
between convenience and security can determine the number and rate of
LOG-ON failures that will be tolerated in any particular system
application.
Reference
See also
6.0/2
When system security requires more stringent user identification than is provided by password entry, devise auxiliary tests that can authenticate user identity without imposing impractical demands on users' memory.
Comment
Various means have been proposed for authenticating user identity,
including the use of secret algorithms known only to each individual
user. If computer-generated cues and user responses can be protected
cryptographically from eavesdropping, a practical scheme might be to
require a user to respond to a word association test individually
devised by that user for this purpose.
Reference
Once a user's identity has been authenticated, ensure that whatever data access/change privileges are authorized for that user will continue throughout a work session.
Exception
In special instances a user's data access/change privileges might
reasonably change as a result of succeeding transactions, e.g., if
computer analysis indicated suspicious or otherwise abnormal behavior.
Exception
A user might reasonably be required to repeat procedures for
authentication of identity when resuming work after some specified
period of inactivity.
Comment
If an identified user is required to take separate actions to
authenticate data handling transactions, such as accessing particularly
sensitive files or issuing particular commands, the efficiency of system
operations may be degraded. Where continuous verification of user
identity seems required for data protection, perhaps some automatic
means of identification might be devised for that purpose.
Reference
See also
3.3/10
|
6.2/1
|
6.2/6
|
6.3/1
Data access constraints established to exclude unauthorized users should not hinder legitimate use of data.
Establish user authorization for data access at initial LOG-ON; do not require further authentication when a user requests display of particular data.
See also
6.1/8
When displayed data are classified for security purposes, include a prominent indication of security classification in each display.
Comment
This practice will serve to remind users of the need to protect
classified data, both in access to the display itself and in any further
dissemination of displayed data.
Comment
In applications where either real or simulated data can be displayed, a
clear indication of simulated data should be included as part of the
classification label.
Comment
Where a display includes partitioned "windows" of data from different
sources, it may be necessary to label security classification separately
for each window. Under those conditions, some form of auxiliary coding
(e.g., color coding) might help users distinguish a window which
contains data at a high security level.
See also
6.0/6
When protection of displayed data is essential, maintain computer control over the display and do not permit a user to change such "read-only" data.
Comment
It is not enough simply to instruct users not to make changes in
displayed data. Users may attempt unwanted changes by mistake, or for
curiosity, or perhaps even to subvert the system.
Reference
When users are not authorized to change displayed data, indicate that "read-only" status on the display.
Comment
In applications where the use of read-only displays is common, then some
simple cue in the display header may suffice to indicate that status.
In applications where users can usually make additions and/or
corrections to displayed data, then any exception to that practice may
confuse a user and so should be noted more prominently on the display.
See also
2.0/9
Protect display formatting features, such as field labels and delimiters, from accidental change by users.
Comment
In many data entry tasks users will be allowed to change data fields but
should be prevented from making any structural changes to the display.
In applications where a user may have to create or modify display
formats, special control actions should be provided for that purpose.
Reference
When confidential information is displayed at a work station that might be viewed by casual onlookers, provide the user with some rapid means of temporarily suppressing a current display if its privacy is threatened, and then resuming work later.
Comment
Such a capability is sometimes called a "security pause". For quick
display suppression a function key might be provided. To retrieve a
suppressed display and resume work, a user might be required to make a
code entry such as a password, in the interests of data protection.
Comment
A suppressed display should not be entirely blank, but should contain an
appropriate message indicating its current status, e.g.,
| Display is temporarily suppressed; |
| enter password to resume work. |
See also
3.3/8
|
4.2/1
|
6.1/8
As required for security, establish procedures to control access to printed data, rather than simply prohibiting the printing of sensitive data.
Comment
User requirements for printed data are often unpredictable, and printing
restrictions may handicap task performance. Rather than restrict
printing, establish appropriate procedures for restricting further
distribution of data printouts.
Reference
See also
2.7.1/11
|
5.3/13
|
6.4/7
When records of data access are necessary, the computer should keep those records automatically; do not rely on users to take critical record keeping actions.
Comment
Even cooperative, well-intentioned users can forget to keep manual logs
of data access, and will resent the time and effort required to keep
such logs. Subversive users, of course, cannot be expected to provide
accurate records.
See also
4.5/4
When sensitive data may be exposed to unauthorized access, provide a capability for encrypting those data.
Comment
Potential exposure may be assumed during any external data transmission,
with encryption imposed routinely by the computer. For protection of
data within a shared system, a user might choose to encrypt private
files to prevent their reading by other people. In such a case, the
user must specify a private encryption "key", which will then serve as
the basis for automatic encryption by the computer.
See also
6.4/3
Ensure that data encryption is reversible, i.e., that encrypted data are protected from any change that might prevent successful reversal of their encryption.
See also
6.3/2
Data entry constraints may be needed to prevent unauthorized data change as well as data loss from user errors.
Establish user authorization for data entry/change at initial LOG-ON; do not require further authorization when a user attempts particular data entry/change transactions.
See also
6.1/8
When data must not be changed, maintain computer control over the data, and do not permit users to change controlled items.
Comment
It is not enough simply to instruct users not to make changes in
displayed data. Users may attempt unwanted changes by mistake, or for
curiosity, or perhaps even to subvert the system.
Reference
See also
1.1/23
|
1.4/7
|
2.0/10
|
6.2/3
In situations where unauthorized data changes may be possible, allow users (or a system administrator) to request a record of data entry/change transactions.
Comment
Transaction records might be maintained for purposes of user guidance as
well as for data protection, as recommended elsewhere.
See also
3.4/3
|
4.4/22
|
4.5/3
Make procedures for data entry/change as simple as possible by following guidelines for the design of data entry functions.
Example
Allow users to enter short rather than long items, do not require users
to enter leading zeros or count blanks, etc.
Comment
Simple procedures will help ensure accuracy in data entry/change
transactions.
See also
1
Require users to take some explicit ENTER action to accomplish data entry/change transactions; data change should not occur as a possibly unrecognized side effect of other actions.
Example
A user should be able to key data into a displayed form but not change
stored data unless some explicit ENTER action is taken.
Example
A user should be able to point with a lightpen at a displayed item but
not change that item unless some further action is taken.
Exception
In some applications it will be desirable to provide automatic
cross-file updating of changed data, or generation of routine, redundant
or derived data, without requiring explicit action by a user.
Comment
Explicit actions will help direct user attention to data entry/change,
and reduce the likelihood of thoughtless errors.
Reference
See also
1.0/9
|
1.1/4
|
3.0/5
|
3.1.3/6
|
4.0/2
|
6.0/9
Allow users to enter logically related items, as in a form-filling dialogue, with a single, explicit action at the end of the sequence, rather than entering each item separately.
Comment
This practice permits user review and possible data correction prior to
entry. It will also permit efficient cross validation of related data
items by the computer.
Ensure that an ENTER action for multiple data items will result in entry of all items, regardless of where the cursor is placed on the display.
Comment
A user may choose to move the cursor back in order to correct earlier
data items, and cannot be relied upon to move the cursor forward again.
The computer should ignore cursor placement in such cases.
See also
1.1/24
Allow users to correct keyed data entries (and control entries) before taking an explicit ENTER action.
Comment
Easy correction before entry will avoid the need for computer processing
of user-detected errors.
Comment
A user should be able to backspace with a nondestructive cursor to the
point of error, correct the erroneous item, and ENTER all items without
any further cursor positioning.
Reference
See also
1.4/2
|
3.5/2
|
6.0/10
When a data entry error is detected by the computer, allow the user to make an immediate correction.
Comment
Immediate corrections will be made more easily and accurately. Intended
entries will still be fresh in the user's mind, and any source data
(e.g., documents) will still be available to the user.
Reference
Following error detection, allow users to edit entries so that they must rekey only those portions that were in error.
Comment
If a user must re-enter an entire data set to correct one wrong item,
s/he may make new errors in previously correct items.
Reference
Require users to take an explicit ENTER action for computer processing of error corrections; this should be the same action that was taken to enter the data originally.
Reference
Allow users to return easily to previous steps in a transaction sequence in order to correct an error or make any other desired change.
Example
A user might wish to BACKUP through the defined sequence of a
question-and-answer dialogue in order to change a previous answer.
Comment
The effective implementation of such a BACKUP capability depends upon
whether sequences of related transactions can in fact be defined. Any
attempt to BACKUP through an arbitrary series of unrelated transactions
will pose logical problems both for designers and users.
Reference
See also
3.5/13
When verification of prior data entries is required, allow users to review and confirm the data, rather than requiring re-entry of the data.
Comment
For routine verification, data review by the user will be quicker than
re-entry, with less risk of introducing new errors.
Comment
For special verification, as when computer processing has detected
doubtful and/or discrepant data entries, the user should be alerted with
an appropriate advisory message.
When routine or redundant data can be derived by the computer, display those data automatically for user review, rather than requiring entry by the user.
Comment
This represents an exception, in the interests of improved data
accuracy, to the general recommendation that data entry/change should
occur only as a result of explicit user actions. Automatic data
generation by the computer, where it can be based on derived values or
cross-file updating, will be faster and more accurate than user entry.
In effect, having a computer do automatically what the user may do
poorly is here regarded as a form of data protection.
Reference
See also
1.8/7
|
1.8/8
|
1.8/10
|
1.8/11
Display currently operative default values for data entry, so that users can review and confirm them for computer processing.
Reference
If a user requests change (or deletion) of a stored data item that is not currently being displayed, offer to display both the old and new values so that the user can confirm or nullify the change before the transaction is completed.
Comment
This practice will tend to prevent inadvertent change, including changes
resulting in loss of needed data. User attempts at selective data
change without displayed feedback will be prone to error.
Comment
For proposed deletion of significant amounts of data, such as entire
files, it will probably not be feasible to display all of the data. In
such instances, sufficient information should be provided so that the
user can identify those files s/he has selected for deletion. The user
should be clearly warned of the potential data loss and required to
confirm the destructive action before it will be executed.
See also
1.0/14
Provide data validation software which will detect erroneous or doubtful values for data changes, as well as for initial data entries.
Comment
Do not rely on users always to be correct when entering or changing
data. When validity of data entries can be checked automatically, such
computer validation will improve the accuracy of data entry.
Reference
See also
1.7/1
For the entry of related data items, provide automatic cross validation to ensure that the data set is logically consistent.
Comment
Such cross checking is a significant advantage of on-line data
processing, providing computer aids to help users detect logical errors.
Reference
See also
1.4/1
|
1.7/1
|
6.3/6
Require users to take explicit action to confirm doubtful and/or potentially destructive data change actions before they are accepted by the computer for execution.
Comment
A requirement to take an explicit CONFIRM action will direct user
attention to questionable data changes, and help the user avoid the
consequences of thoughtless errors.
Reference
See also
1.3/32
|
1.3/34
|
4.3/18
|
6.0/18
When data files may be deleted (or overwritten) by name, ensure that the names of different files are distinctive.
Comment
If file names are similar, it is easy for users to make an error in file
storage, by specifying an unintended overwriting of one file with data
from a similarly named other file.
Comment
If two or more files are assigned similar names, the distinctive feature
should be near the beginning of those names rather than at the end; in
particular, no file name should simply be a truncated version of
another.
Comment
In many applications, file naming is a user option, and distinctive
naming will depend on user judgment. In such circumstances, users
should be offered guidance on good naming procedures. In addition,
perhaps the computer might provide an advisory message if a proposed new
file name is similar (e.g., identical in the first 5 letters) to the
name of an existing file.
When simulated data are stored and processed in a system (perhaps for user training), ensure that changes to simulated data are processed separately and do not affect real data.
Reference
When a user requests LOG-OFF, check any pending transactions involving data entry/change and, if data loss seems probable, display an appropriate advisory message to the user.
Example
| Current data entries have not been filed; |
| save if needed before confirming LOG-OFF. |
Comment
The user may sometimes suppose that a job is done before taking a
necessary further implementing action.
Reference
See also
3.5/11
Data transmission procedures should ensure data protection when sending and receiving messages.
Ensure that whatever measures are adopted to protect data during transmission -- e.g., encryption, parity checks, buffering until acknowledgment of receipt -- will be applied automatically, without the need for user action.
Comment
Users are fallible, and cannot be relied upon to participate quickly and
accurately in the mechanisms of data transmission, whereas that is what
computers can do well. The computer should check transmitted data to
determine whether an error has occurred; correct errors automatically,
if necessary by requesting retransmission; and call to the user's
attention any case in which a detected error cannot be automatically
corrected.
When human judgment may be required to determine whether data are appropriate for transmission, provide users (or a system administrator) some means to review outgoing messages and confirm their release before transmission.
Comment
Sometimes message release may require coordination among several
reviewers in the interests of data protection.
See also
5.3/2
When it is necessary to transmit sensitive data over insecure communication channels, provide automatic encryption to protect such data.
Comment
Do not rely on users to remember to request message encryption. A user
might be asked to supply an encryption key, but the computer should
handle any actual encryption process.
Reference
Save a copy of any transmitted message automatically until correct receipt has been confirmed (and possibly longer in some applications).
Comment
The primary objective is to prevent irretrievable data loss during
transmission. For many system applications, however, the originator of
a message will probably want to retain a copy in any case. Any
subsequent deletion of that copy should probably be handled as a
separate transaction, distinct from data transmission.
Provide automatic queuing of incoming messages as necessary to ensure that they will not disrupt current user information handling tasks.
Comment
In general, incoming data should not replace currently stored data
directly, but should be queued for review and disposition by a user. An
exception must be made, however, in applications where automatic
updating of current situation data is required for operations
monitoring, as in air traffic control systems. In such cases data
updating is the primary purpose of the system, and that updating should
not require continuous actions by a user.
See also
5.5/5
When a user must confirm the identity of a message source, provide computer aids for that purpose.
Example
In military message systems, received commands might be authenticated
automatically by requesting computer-generated confirmation codes.
Reference
See also
5.3/6
Within the constraints of data security, allow users to generate printed copies of transmitted data, including messages sent and received.
Comment
User requirements for printed data are often unpredictable, and printing
restrictions may handicap task performance. Rather than restrict
printing, establish appropriate procedures for restricting further
distribution of printed messages.
See also
2.7.1/11
|
5.3/13
|
6.2/7
Design change of software supporting data protection may be needed to meet changing operational requirements.
When data protection requirements may change, which is often the case, provide some means for a system administrator to make necessary changes to data protection functions.
Comment
Data protection functions that may need to be changed include those
represented in these guidelines, namely, changes in protective measures
regulating user identification, data access, data entry/change, and data
transmission.
Protect user interface design from any changes that might impair functions supporting data entry, data display, sequence control, user guidance, data transmission, and data protection.
Comment
A trade-off is required between design flexibility, to permit needed
improvements to the user interface, and design control, to protect
current functions from undesirable changes. Some form of continuing
configuration management should be instituted to evaluate changes to
user interface design, just as for any other critical system interface.
See also
1.9/1
|
2.8/1
|
3.7/1
|
4.6/1
|
5.6/1
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents | | | Top |