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.
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?
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.
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).
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?
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?
Learn
- The cranky user: Everything's automated! (Peter Seebach, developerWorks, January 2005): Read more on the drawbacks of the overcompensatory user interface.
- The cranky user: Yes Virginia, security affects usability (Peter Seebach, developerWorks, August 2003): Why must security features disrupt the use of computers?
- "How to turn
off the empty trash warning: Take control of your Mac, if you
dare.
- Bug Hall of
Fame: Learn all about the first-ever recorded computer
bug.
- developerWorks Web
architecture zone: Find the Web development solutions you need.
Discuss
- Participate in the discussion forum.
- developerWorks
blogs: Get involved in the developerWorks community!
Table of contents
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags