When undo is evil

This comes up time and time again. I'm not, by any stretch of the imagination, an expert on computer interface design, however, I do spend a lot of time using computers, writing software for them, and helping other users with problems.

A recent topic at work is the implementation of undo on our web application. I'll skip discussing the challenge of making undo work accurately on a multi-user application, and go right for the throat as to why I think it's bad form to consider undo the correct option in this case.

From discussions with the people making the decisions, I gather that the biggest reason is addressed in this article: http://www.alistapart.com/articles/neveruseawarning/

That article is fundamentally wrong. It presents the case that users have fallen into habits, and software developers ignore those habits at their peril. The author is correct in saying that. It further asserts that users have gotten into the (admittedly bad) habit of clicking the "OK" button without reading first, and that only a foolish developer would ignore that habit. The author is again, very correct.

Where the author fails utterly to understand his topic, is when he arrives at the completely incorrect conclusion that warning messages are bad and should be replaced with undo.

I'll skip the part where I point out that Aza has a lousy sense of cause and effect, but I suspect that if his car wouldn't start, he'd try to put air in the tires to fix the problem.

Creating an undo button is fraught with its own perils. Assuming that an undo button in lieu of a warning dialog is always the right solution is so extreme in it's stupidity, that it rivals the stupidity that made warning dialogs so useless in the first place.

To understand the correct solution, we have to understand what Aza got wrong. First off, his "these solutions don't work" section is so silly as to be childish. The reason is that the people are confusing the symptom with the problem, and trying to solve the symptom without addressing the actual problem rarely, if ever, works.

The symptom is that people click OK on warning boxes with out reading them.

The problem is that warning boxes are usually incomprehensible, or are a needless intrusion.

For example, how many times have you been presented with a warning box that reads, "Are you sure you want to exit this program?" How pointless is that? The frightening thing is that if you use most any programming tool to help you write your application, the programming tool adds this warning for you and you have to do extra work to make it go away!

Undo itself is fraught with peril. Not all operations can be undone, especially in the case of a multi-user application. Training the user to blindly work on their application in the hope that they'll always be able to undo any mistakes is setting the user up for disappointment. I can't count the number of times I've responded to a support request where the user had made a mistake that couldn't be undone and was hoping I could magically re-enable the undo option somehow.

The obvious counter-argument is to ensure that everything is always undoable. If you've never implemented an undo system, then you may not understand how difficult that is, and how it's probably impossible in some cases. The best example I can think of is most modern operating systems have a "shred" option that allows you to not only delete files, but destroy them such as to guarantee that nobody can recover the data -- this is an obvious option where adding an undo option is not only impossible, but complete defeats the point of the software.

Since Aza's "failed solutions" obviously won't help (he is correct that those solutions don't solve anything) and since Bill says that undo doesn't solve the problem either, what can we do?

Simply solve the problem instead of the symptom.

The problem with warning boxes is that they're incomprehensible, and needlessly intrusive. Unfortunately, they've been this way for so long that they've created another problem ... people ignore them out of habit.

So we need to solve three problems. If interface designers had solved the first two a long time ago, the third wouldn't exist, but this is the bed that was made for us, we have to figure out how to get some sleep.

First off, make warnings comprehensible. Too many programmers are lousy communicators, and thus write warnings that only make sense to other programmers. As an extreme example, if your warning box contains hexadecimal data, you're doing it wrong. It's more subtle than that, however. Try to understand just how stupid you sound when you talk about computers and this will start getting easier. And important guideline: warnings should never describe a code condition, they should describe a condition in the user's life.

Bad warning: "Continuing may result in memory corruption" Like what? Will I forget my name?

Good warning: "Continuing may cause the program to crash or damage your data" Holy shit! Something I care about!

Now we're getting somewhere. Next, get rid of the useless warnings. If performing an action doesn't have any negative side effects and you pop up a warning, lynching is too good for you. If it means you have to do extra work to only warn the user when exiting the application might cause data loss, then do your job and write those extra 5 lines of code! For crying out loud, when I turn off the powersave feature on my Mac (I do this on occasion when I don't want the Mac to go to sleep, because I've got a process running) it pops up a warning that says, "These settings may cause your computer to use more power." Really? No kidding? For crying out loud, Steve Jobs, I thought you were smarter than this!

The final problem is that no matter how carefully we write our warnings, users have been trained to click OK without reading them. It is the only valid point that Aza has in his article, but it's one that must be addressed or all our other solutions fail.

Luckily, the solution is simple: Don't give the user an OK button

I'm surprised at how many people don't understand how to use this simple solution. It's not my idea, the first time I was exposed to it was from some folks in the GNOME project.

Take the earlier example, we've made the warning comprehensible by having it read: "Continuing may cause the program to crash or damage your data". That's good, but the user is still liable see a CANCEL and OK button and click OK without reading our useful message. Well, just relabel the OK button to read "Risk my data" and the CANCEL button to read "Abort the operation". Honestly, with a button named "Risk my data", we could write War and Peace in the rest of the warning and the user is going to read it (that does not give you an excuse to be pointlessly verbose!)

This even helps Apple's lousy example: The warning about my computer using more power would have felt less intrusive if instead of OK and CANCEL the buttons said, "Allow the computer to use more power" and "Reset to power saving settings"

Some will argue that long messages on buttons are a bad idea. I argue that users not knowing what's going on is a worse idea, but yes, it can be overdone. It takes a certain amount of effort to create good warnings, but the problem with warnings is not that they're inherently evil, it's just that they've been done sloppily for so long that everyone has given up on them.