|
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.
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.
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.
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.
Provide automatic measures to minimize data loss from computer failure.
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.
An automatic capability is needed because users cannot be relied upon to remember to take necessary protective measures.
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.
Protect data from inadvertent loss caused by the actions of other users.
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.
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.
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.
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.
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.
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.
Provide clear and consistent procedures for different types of transactions, particularly those involving data entry, change and deletion, and error correction.
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.
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.
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.
A computer might perform cross-file updating automatically, following data change by a user.
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.
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.
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).
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.
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.
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.
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.
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.
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.
In text editing, if a user takes a DELETE action, that in itself should not establish a continuing DELETE mode.
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.
If a DELETE mode is being used to edit displayed data, some indication of that mode should be continuously displayed to the user.
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.
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.
Require users to take an explicit extra action to CONFIRM a potentially destructive control entry before it is accepted by the computer for execution.
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.
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.
| Enter next command| D__ | | | | If deleted, all data in this file will be lost. | | Enter YES to confirm deletion: ______ |
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.
Allow users to UNDO an immediately preceding control action that may have caused an unintended data loss.
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.
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.
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.
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.
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.
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.
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.
When passwords are required, allow users to choose their own passwords.
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.
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.
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.
Allow users to change their passwords whenever they choose.
A user may sometimes suspect that a password has been disclosed, and thus wish to change it.
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.
When a password must be entered by a user, ensure that password entry can be private; password entries should not be displayed.
Covert entry of passwords will prevent casual eavesdropping by onlookers. This represents an exception to the general recommendation that all entries should be displayed.
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.
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.
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.
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.
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.
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.
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.
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.
A user might reasonably be required to repeat procedures for authentication of identity when resuming work after some specified period of inactivity.
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.
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.
When displayed data are classified for security purposes, include a prominent indication of security classification in each display.
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.
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.
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.
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.
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.
When users are not authorized to change displayed data, indicate that "read-only" status on the display.
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.
Protect display formatting features, such as field labels and delimiters, from accidental change by users.
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.
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.
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.
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. |
As required for security, establish procedures to control access to printed data, rather than simply prohibiting the printing of sensitive data.
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.
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.
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.
When sensitive data may be exposed to unauthorized access, provide a capability for encrypting those data.
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.
Ensure that data encryption is reversible, i.e., that encrypted data are protected from any change that might prevent successful reversal of their encryption.
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.
When data must not be changed, maintain computer control over the data, and do not permit users to change controlled items.
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.
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.
Transaction records might be maintained for purposes of user guidance as well as for data protection, as recommended elsewhere.
Make procedures for data entry/change as simple as possible by following guidelines for the design of data entry functions.
Allow users to enter short rather than long items, do not require users to enter leading zeros or count blanks, etc.
Simple procedures will help ensure accuracy in data entry/change transactions.
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.
A user should be able to key data into a displayed form but not change stored data unless some explicit ENTER action is taken.
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.
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.
Explicit actions will help direct user attention to data entry/change, and reduce the likelihood of thoughtless errors.
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.
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.
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.
Allow users to correct keyed data entries (and control entries) before taking an explicit ENTER action.
Easy correction before entry will avoid the need for computer processing of user-detected errors.
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.
When a data entry error is detected by the computer, allow the user to make an immediate correction.
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.
Following error detection, allow users to edit entries so that they must rekey only those portions that were in error.
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.
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.
Allow users to return easily to previous steps in a transaction sequence in order to correct an error or make any other desired change.
A user might wish to BACKUP through the defined sequence of a question-and-answer dialogue in order to change a previous answer.
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.
When verification of prior data entries is required, allow users to review and confirm the data, rather than requiring re-entry of the data.
For routine verification, data review by the user will be quicker than re-entry, with less risk of introducing new errors.
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.
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.
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.
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.
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.
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.
Provide data validation software which will detect erroneous or doubtful values for data changes, as well as for initial data entries.
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.
For the entry of related data items, provide automatic cross validation to ensure that the data set is logically consistent.
Such cross checking is a significant advantage of on-line data processing, providing computer aids to help users detect logical errors.
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.
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.
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.
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.
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.
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.
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.
| Current data entries have not been filed; | | save if needed before confirming LOG-OFF. |
The user may sometimes suppose that a job is done before taking a necessary further implementing action.
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.
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.
Sometimes message release may require coordination among several reviewers in the interests of data protection.
When it is necessary to transmit sensitive data over insecure communication channels, provide automatic encryption to protect such data.
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.
Save a copy of any transmitted message automatically until correct receipt has been confirmed (and possibly longer in some applications).
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.
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.
When a user must confirm the identity of a message source, provide computer aids for that purpose.
In military message systems, received commands might be authenticated automatically by requesting computer-generated confirmation codes.
Within the constraints of data security, allow users to generate printed copies of transmitted data, including messages sent and received.
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.
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.
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.
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.
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 |