Undo me!

Why can't operating system designers build a better "undo" feature?

Published June 1, 2000 7:03PM (EDT)

If we want computers to be easier to use -- and who doesn't? -- a good place to start would be with that all-important command, "Undo." Although many of today's computer systems have some sort of undo capability, few of them work consistently throughout the system, or even in one application. As a result, users can't depend upon it, and lots of people lose a lot of work.

The need for a better undo is one of the important ideas in designer Jef Raskin's first book, "The Humane Interface," published earlier this year by Addison-Wesley. Although Raskin is perhaps best known as the creator of the Apple Macintosh project, his book is not a rant arguing why the Mac has a better user interface than Windows. Of course the Mac is better, says Raskin, but both computer systems have fundamental problems that make using them an unpleasant experience for both novices and experts alike.

Raskin bases his arguments not on opinion but on nearly 30 years of research by people around the world who have studied how the human brain interoperates with engineered systems from aircraft to computers. Raskin suggests that we should apply this research to the design, or redesign, of today's operating systems.

One of Raskin's early observations is that people quickly become habituated to routine processes and procedures. This works to both the advantage and the detriment of the interface designer. Habituation lets an experienced person use a well-designed interface more quickly. But that same habituation can also lead to errors -- sometimes catastrophic ones. And that's when it would be great if we had a truly workable undo.

Consider the Yes/No or OK/Cancel questions that many computer systems ask. "Do you really want to empty your trash? (Y/N)" "Are you sure you want to permanently delete the selected items?" People become so accustomed to these questions and pop-up boxes, Raskin writes, that after seeing them a few times they habitually click "OK," even when they should click "Cancel." Hence, they click right through something like: "WARNING: All data on non-removable Disk Drive C: will be lost. Proceed with format? (Y/N)"

Far better than giving the user a Yes/No or OK/Cancel choice would be to create a general undo facility that worked consistently throughout the entire computer system. When, weary from slaving for hours on that paper you're writing, you mistakenly tell your word processor to shut down without saving the final version, you don't want it to ask, "Are you sure?" You want it, when you realize your mistake, to promptly undelete any work you've foolishly trashed.

Raskin's words became especially poignant to me last month, when a minor user-interface tick and an OK/Cancel alert caused me to lose the minutes of a board meeting that I had been taking on my Palm Pilot. It was an hour into the meeting, and one of the organization's board members asked me to beam my minutes into her Palm VII. Trying to be helpful, I clicked the button to display my computer's pull-down menu, selected "Beam Memo" and was prompted with a pop-up box asking: "Beam current memo? OK/Cancel." I clicked "OK" and suddenly the memo vanished.

Of course, I hadn't clicked "Beam Memo" on the Pilot's menu, but "Delete Memo." As Raskin notes, I had been so focused on the idea of beaming my memo to the board member that I had misread the confirmation box -- a box that was designed to prevent me from doing precisely what I had then proceeded to do.

Instead of a confirmation box, a far better design would be to have the computer always delete the menu, but then to allow the ability to undo the last action. The ubiquitous OK/Cancel box is a terrible user-interface design, writes Raskin, because it slows you down the majority of the times you are actually trying to do something, and the few times that you really, really need the confirmation box -- when you are habituated to a user interface and about to make a mistake that will cause you to irrevocably lose data -- you don't stop to read it. You don't stop because you have become habituated.

Of course, the Palm operating system does have an undo feature. Unfortunately, it doesn't work all the time. Undo works for undoing modification to text in the memo pad application, for example, but it can't undo the deletion of a memo. There's an undo option on the Palm's appointment book program, but it can't undo changes you might make to an appointment's date or time. These limitations aren't the result of the Palm's low-powered microprocessor or small memory; they're the result of poor design -- poor design of both the memo pad application and the underlying operating system. And they are design problems shared by many systems.

Speaking as a programmer and as a designer, creating a generalized undo feature is hard work. To do it, you must remember every change that affects the user's data so that you can undo those changes if the user asks. Few application frameworks provide an undo facility, so each programming team has to create its own. Although this shouldn't be hard to do in principle, in practice it enforces a discipline that few of today's programmers are up to. One of the reasons, I think, is that they lack good examples: Since no program currently on the market today does undo properly, there is little incentive for other programmers to do better.

Consider the undo feature in Microsoft Word. Overall it's pretty good, but it frequently behaves in an unpredictable manner. For example: Type a paragraph of text. Select the paragraph with your mouse and choose the "Copy" command. Now select the last sentence of the paragraph and choose the "Cut" command. Now click undo, click the mouse at the end of the paragraph and choose the command "Paste." What happens? You should get the entire paragraph, but, instead, you get just the last sentence. That's because Microsoft's undo doesn't really undo your last command; instead, it reverts to the last change to your document. In this example, the last command also affected the clipboard, which Word's undo command doesn't restore.

Many applications don't even have an undo facility. Last year, for instance, I received an e-mail from a reader who was furious at Intuit. The reader had lost a significant amount of time because Intuit's Quicken lacks an undo feature and he had inadvertently made a change to a transaction in his checking register. Of course, he didn't know what the change was -- it was, after all, inadvertent -- and he spent several hours trying to figure out why a reconciled transaction had disappeared but his register still balanced. The man eventually discovered that he had changed the year of a credit card charge from 1999 to 1909. An undo feature that would undo a change to the last transaction would have saved him much work and frustration.

The computer industry has technical standards that describe everything from the voltage transmitted on an Ethernet cable to procedures that companies must follow for ensuring the "quality" of their products. But few standards ensure that these products will be usable or, to use Raskin's word of choice, humane. Building an undo feature that always works would be a good place to start.

By Simson Garfinkel

"Simson Garfinkel is a frequent contributor to Salon, the Chief Technology Officer of Sandstorm Enterprises, and the Chief Scientist of Broadband2Wireless, Inc."

MORE FROM Simson Garfinkel

Related Topics ------------------------------------------