Last updated: 9th February 1998
# Think Twice *
. . . . a user may accidentally carry out an action which has serious consequences,
such as deleting a file, erasing a disc and so on. The consequences
of this may be mitigated by ALLOW UNDO (#) where
this is possible. However, in some circumstances an erroneous action
may be unrecoverable.
A user will, in general, expect some protection from disastrous errors,
but at the same time will wish to have fluidity in their operation of the
system.
A system that does not allow the user to make any errors is likely to
be highly constraining and clunky to operate. Dangerous actions may
need to be taken by the user. For most office applications the occurrence
of truly irreversible actions should not be great — but in some systems,
particularly those controlling equipment (e.g., process control, autopilots,
etc.), they are inevitable.
There are three categories of action depending on their reversibility;
-
easily reversible
-
reversible at a cost (time and/or effort): there are significant
consequences of selecting this action in error, but a disaster would not
immediately ensue.
-
irreversible: if selected in error, serious damage to assets or potentially,
injury or loss of life (a disaster) may ensue.
There are also categories of systems, based on the occurrence of each type
of action;
-
all actions are reversible
-
most actions are reversible
-
many actions are reversible
-
few actions are reversible
-
no actions are reversible
The amount of care taken by the user will be influenced by the category
of system (above) and the potential for problems or disaster that the system
has: so users of a system in which all actions are easily reversible many
not be particularly careful, whilst the user of a system in which no actions
are reversible will know that they have to exercise care at every step.
The real problems lie between these extremes. Where most actions
are reversible, a false sense of security may build up. These categories
of actions and systems make for 12 possible specific considerations for
error prevention at the level of selecting an action.
Overlaid on this schema is the need to consider the consequences of
the action being taken erroneously. This may vary between minor inconvenience
while the action is undone, to damage to capital assets, to loss of life.
Additionally, the frequency with which the action is carried out should
be taken into account.
There are a number of levels of protection that may be applied to actions;
-
Unprotected.
-
Warning: an indication of potential problems — which does not interrupt
the flow of execution.
-
Confirmation: an indication of potential problems — which requires completion
of a simple dialogue (typically a single key press) in order to proceed.
-
Authorization: an indication of potential problems — which requires
a more complex dialogue (perhaps entry of a password) in order to proceed.
-
Automatic override: here the system checks that execution of the
command will not cause damage, and if it might, either modifies the action
to be within safe parameters, or rejects the action.
The table below suggests the types of protection that should be considered
for each combination of action and system.
|
Easily Reversible |
Reversible at Cost |
Irreversible |
| All Reversible |
Unprotected |
|
Inconvenience |
Damage |
| Frequent |
Warn |
Confirm |
| Infrequent |
Confirm |
Authorize |
|
|
| Most Reversible |
Unprotected |
|
Inconvenience |
Damage |
| Frequent |
Warn |
Confirm |
| Infrequent |
Confirm |
Authorize |
|
|
Inconvenience |
Damage |
| Frequent |
Confirm |
Authorize |
| Infrequent |
Authorize |
Authorize |
|
| Many Reversible |
Unprotected |
|
Inconvenience |
Damage |
| Frequent |
Warn |
Confirm |
| Infrequent |
Confirm |
Authorize |
|
|
Inconvenience |
Damage |
| Frequent |
Confirm |
Authorize |
| Infrequent |
Authorize |
Authorize |
|
| Few Reversible |
Unprotected |
|
Inconvenience |
Damage |
| Frequent |
Unprotected |
Warn |
| Infrequent |
Confirm |
Confirm |
|
|
Inconvenience |
Damage |
| Frequent |
Unprotected |
Confirm |
| Infrequent |
Confirm |
Authorize |
|
| None Reversible |
|
|
|
Inconvenience |
Damage |
| Frequent |
Unprotected |
Automatic override |
| Infrequent |
Unprotected |
Automatic override |
|
The immediacy of perception that an erroneous action has been taken
should influence error protection. I.e., sequentially - how many
subsequent actions may be taken before the error of an earlier action becomes
apparent, or temporally - how long before the error becomes apparent.
Therefore:
For each action that a user may take, having regard for; the reversibility
of the action, the proportion of reversible actions that the system supports,
the frequency with which the action is taken, the degree of damage that
may be caused, and the immediacy of feedback, consider whether a warning,
confirmation, authorization or automatic override may be appropriate.
Users must be able to see what effect their actions are having on the
system, so give INTERACTION FEEDBACK (#).
Where error protection at the action level is required, the following patterns
specify the different types of protection; GIVE A WARNING (#),
GET CONFIRMATION (#), GET AUTHORIZATION (#),
AUTOMATIC OVERRIDE(#) . . . .
Part of a Usability Pattern Collection maintained by The
Usability Group at the University
of Brighton, UK.
