Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
01 Nov 2005 Like dull knives in the kitchen and training wheels on bicycles, many so-called safety features just lead to trouble. The cranky user suggests an alternative approach.
A friend once needed to run a process where, for reasons unknown, the
program required him to confirm each task in a series of hundreds. He
balanced a pocket knife on the Return key and went to lunch. In
his particular case there were no horrific surprises; it was just a huge
waste of time and he worked around it. For many users faced with this
type of "safety" feature, however, the workaround isn't so simple.
Confirming, clarifying, and checking every operation, as most
applications these days do, is intended to protect users from accidents.
The result is similar to what many people find after putting training
wheels on a child's bicycle: the vehicle is more cumbersome and the
child never learns to ride it properly. This month I'll count the ways
excessive protections make computers harder to use and more
accident prone.
Double your trouble
The first problem with excessive confirmation is that it prevents the
computer from doing what it's good at -- working quickly without human
intervention. This is especially frustrating when you remember that the
original idea of the computer was that it should take whole processes
and automate them. Of course, computer programs started out with simple
processes like "add three columns of numbers," but even at greater
levels of complexity the idea remains the same: it's important to be
able to kick something off and be done with it.
The second problem is that it eventually weakens a user's ability to do
what they're good at -- making decisions about what the computer
should do next. If my computer constantly checks in to say "Hey, when
you said to do this, did you really mean to do this?" I quickly learn to
respond with an impatient "yes" to every prompt. The unfortunate result
is that when there's a real question I'm unlikely to read it; why bother
when the last thousand or so were all pointless?
Use your noggins, people!
A Linux system I recently loaded has the rm command
aliased to rm -i by default for the root user. When you're
removing one file, that's inconvenient. When you're trying to do what
UNIX is really good at, like write a brief command-line script to
batch-process some files, it's utterly awful. There's a workaround using
the -f flag, but like many safety features it actually
makes the problem worse. The -f flag overrides not only the
totally spurious inquiries but legitimate warnings, such as trying to
remove files flagged as write-protected to avoid mishaps.
Ideally, I would like to be able to see queries about protected files
without seeing queries about all the other ones, too. The easiest way to do
this is, of course, is to remove the alias.
The obliteration of 'yes'
It's perfectly reasonable to ask a user for confirmation the first
time a problem comes up. But in any automated task, right next to the
Yes option should be a Yes to all option. The argument
against this proposal is that users could end up authorizing
actions they didn't realize were part of the package, but what's the
alternative?
Very few users read dialog boxes past the first couple of lines. If
I've requested a five-hundred step process and some lunatic (who
shouldn't have been allowed near a compiler in the first place) has
inflicted 500 clicks of the Yes button to authorize it,
then I'll be reading a book while clicking periodically on the
spot where the Yes button last occurred. I'm not going to read
500 identical messages, and that means I'm not going to read 492
identical messages, or even the eight I would have actually cared about.
In many cases, the way to get around the obliteration of 'yes' is to refine the
question. If I'm extracting an archive, I would like to be able to overwrite all my older files with newer versions by clicking a single Yes to all button. But I might also want to be asked some other questions, such as whether to overwrite newer files with older versions.
The law of unintended consequences
I've written before in this column about the law of unintended
consequences. The law states simply that the consequences of an action,
especially a policy, are not always directly related to its intent. For
instance, the policy of aliasing rm to rm -i
has the consequence that users quickly learn to type rm -f
by habit, which has the consequence that any file a user is able to
remove will be removed, even if the user wouldn't have wanted to remove
that particular file.
Some UNIX users have the habit of marking files read-only to prevent accidental deletion. Normally, rm will query the user before deleting such a file, but not before deleting a file with regular write permissions. Such files are thus protected from accidental deletion. The inconvenient alias leads to an actual decrease in the safety of user data!
In a more subtle example, user interface (UI) researchers have claimed that the
Macintosh trash icon should not graphically show its contents. Users
respond to a full trash bin by emptying it, they say, which defeats the
purpose of allowing recovery of accidentally-deleted files. I can report
with some confidence at least several instances of this mishap having occurred
between 1990 and 2005 (Seebach 1990-2005, personal and very emphatic
communications with various persons; unpublished).
Wait -- can't I undo that?
The safety net that only works part of the time is a particularly common source of interface disappointment, and often data loss. For instance, if you're accustomed to using applications (such as Microsoft Word or Photoshop) that incorporate an Undo feature for key processes, you may develop the habit of trying things out just to see if they work, because you can always undo them later. If you try something that doesn't work on a process that can't be undone, however, the results could be catastrophic.
The common solution is to notify the user every time, which is annoying. A
more subtle solution is to notify the user the first time he or she tries a certain operation, and then provide a checkbox for "Don't remind me again." Of course, the real solution is to make every essential operation undoable.
I was absolutely flabbergasted to discover that the $800 publishing
program I recently used wouldn't allow me to undo a global search
and replace! I know of free text editors a decade old that do that. In
fact, I did a global search and replace in this article and sure
enough, Undo works. If Keith Bostic can make this stuff up in his spare time, why can't Adobe do it with a team of engineers?
Just talk to me
Like public policy, user interfaces are often designed to overcome
particular failings. In the rush to resolve the problem, the solution is
often ill-thought-out and heavy-handed. The response of online commerce
sites to double-submission bugs (where a user could submit the same
order twice, resulting in two orders and two credit-card charges) is a
good example. In the rush to assuage users, many sites have adopted
elaborate JavaScript hacks to prevent order resubmission. Unfortunately,
the hacks are typically far more error-prone than simply warning users
not to click the button twice.
The fact is, users are responsible for their actions. In many cases
I'd prefer to be warned -- once -- about the danger of proceeding than
to be coddled and protected to the point of never learning better. Given
both information and choice, I can decide for myself how I want to
proceed. For instance, while I have disabled all my browser's security
warnings about submitting unencrypted data and entering and leaving
secure sites, I still like the warning about unencrypted forms on
encrypted pages. That's a very useful warning that I don't plan to turn
off.
This week's action item: Try to find instructions that refer to a
confirmation message without needing you to click OK. (I've never seen
this happen.) If you're just supposed to click OK, what's the message for?
Resources Learn
Discuss
About the author  | 
| | Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though. |
Rate this page
| 
