Bad UI of the Week: Ask Forgiveness, Not Permission
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Safari 3 came out not too long ago and half-fixed my pet peeve with the UI—that it was far too easy to close tabs by mistake. I generally close a tab by hitting Command-W. On a QWERTY keyboard, W is next to Q, and accidentally hitting Command-Q would quit the application, closing all tabs (and windows).
To me, this seemed like an obvious violation of Raskin’s First Law: A computer shall not harm your work or, through inaction, allow your work to come to harm.
In most cases, the contents of the pages weren’t destroyed, but I regard all parts of user-visible state as important. I rely heavily on spatial memory while working. Even if I open the same tabs again, I’ve lost their positions onscreen, so it takes longer for me to switch to them again.
In other cases, it’s much worse. If I’d been using a web app or filling in a web form when I accidentally closed the program, I could have lost a lot of state information. While it probably doesn’t count as work, I’ve lost a few long Slashdot posts as a result of that slip of the finger.
Some older browsers I’ve used make this last action even easier. If you accidentally click a link while filling in a form, when you hit Back the form contents will have gone. This is something that Safari does right: Form contents are cached with a page, so the Back button restores the previous page.
The first browser I used that correctly handled accidental quitting was Opera. In Opera, if you quit the application and then re-launch it, all of your tabs will be exactly where you left them. Firefox does something similar if the browser crashes, which protects users somewhat from developers’ errors, but not from their own.
This isn’t what the new version of Safari and current versions of Firefox do, however. These versions ask you to confirm that you want to close the browser. Now, it might be argued that closing a browser is something that happens infrequently enough in a modern computing environment that it should be confirmed. The problem comes when closing is something that happens more frequently.
To prevent you from losing form data through closing a tab, Safari now asks you to confirm that you want to close any tab containing form data. Very quickly, you get into the habit of closing tabs with Command-W immediately followed by Enter. For the first couple of times you accidentally close a tab, this habit might help you. Beyond that, you’re so used to automatically hitting Enter to dismiss the warning dialog that you don’t even do it consciously.
What would be a better way of getting the user to confirm the loss of form data? For some inspiration, let’s look at how browsers get around the problem of losing form data when you click a link. To recover the data, all you do is hit the Back button. Of course, the Back button in a web browser is just a specialized form of an undo feature; it undoes a single kind of action, namely navigation.
Since most browsers have some kind of undo feature already, why not generalize this capability to allow reopening tabs or windows that have been closed? Don’t ask me to confirm that I want to close a window—just close it. If I made a mistake, let me use undo to bring it back. Safari 3 almost gets this right; you can un-close a window (but not a tab), and you can restore all windows and tabs from the last session, but these options are hidden in the Bookmarks menu, far away from where undo options usually live.
Sometimes implementing undo isn’t even possible. Once an email message has left the user’s machine, for example, it’s beyond the mail client’s control. Nothing the client does can change this situation (much to the distress of a great many email users in the early hours of the morning, after some heavy drinking). Anything that sends data to a remote system that’s not under the user’s control can make an undo feature impossible. In some circumstances, it might be worth asking for confirmation first. Sending email isn’t one of those instances, though, because the user will get used to confirming automatically. All the dialog box will do is waste time.
In most other cases, a confirmation dialog could easily be replaced by an undo feature. If the user actually meant what he told the computer to do (which sometimes happens—users aren’t always wrong), avoiding the confirmation process means less time spent being distracted by pointless controls. If the instruction was accidental, an undo feature gives the user longer to catch the error.
Unfortunately for users, most development environments make it much more difficult to implement a global undo feature than to create a proceed/abort dialog box. In most cases, the dialog box takes only a single line of code, whereas setting up a global undo can require a lot of data structures and other housekeeping tasks. Of course, a good application will keep an undo buffer anyway, but making sure that everything is added to it can be non-trivial.
As the saying goes, it’s better to ask forgiveness than permission. This is completely true in the context of user interface design. If it’s possible to allow the user to undo an action, then it’s always preferable to do that, rather than asking for confirmation first.