Ah, CTRL-Z. I’m sure at some point in our lives, everyone has wished they had the ability to go back in time and Undo something they did. The ability to undo, however, is rather commonplace in the computer world. It allows one to revert a document to an older state by negating the last action(s) performed and all of their consequences.
If you have used a computer before, I’m sure this feature has saved you numerous times. It’s so deeply rooted in our subconscious people sometimes use it without even thinking about it. If undo is so successful on the desktop, what is the reason for it’s almost non-existance in Web Applications?
Before we get to the bottom of this, we must first understand why undoing has become such a household feature in the first place.
According to the tenets of good Interface Design, you should allow the user the ability to discover and explore the interface. This, of course, is likely to produce more than a few outcomes where the user won’t be satisfied with the result of her exploration. So, instead of making the user deal with the consequences of her actions, designers provide the ultimate fallback mechanism: the power to travel back in time. If actions were completely irreversible, and the only way to revert to an older state of a document was to keep multiple concurrent saved files, would most users really dare to use features and commands they weren’t sure about? The answer is a clear no.
Let’s now turn to the Web side of things. As I said in the beginning of this article, most Web Applications fail to provide an undo feature. So what do they provide, as a way to prevent user error? The most common practice is to use a Javascript-powered alert box:
What are the problems with this approach? For starters, you interrupt the user’s workflow. Imagine the user doing her work, clicking something and bam! A box pops up. Annoying, at least. Secondly, Javascript Alert Boxes also disable any sort of interaction with the page itself as well as with the browser, effectively giving the user no option but to focus on the box. Lastly, users have been training their brains for all these years of putting up with confirmation boxes, and, much like advertising, they’ll pretty much ignore it’s contents and just click OK. What typically happens after clicking OK can be best described as the ohnosecond. Unfortunately for the user, the hidden meaning of the dialog box is: Hey, you, take a nice long look at me, because what I’ll do after you click ok is COMPLETELY IRREVERSIBLE.
Confirmation boxes such as this are still very much around, but ever since the rise of what I like to call the “Cool Javascript” (the proliferation of Javascript as the de-facto language for client-side scripting), designers have replaced them with the (in)famous modal dialog box:
The modal box approach solves none of the crucial problems listed above. At most, it solves the issue of not being able to interact with the browser. It still rudely interrupts the user, its contents are still ignored. But nevermind all that, it’s way prettier than a crappy alert box.
So why don’t you integrate Undo functionality into your Web Application right now? Gmail does it. Heck, they now even offer an undo feature for sent messages. The most common complaint is it’s hard to implement. That’s a myth, at best. Just last week I came up with a really cool Undo feature for a project I’m working on. It supports multiple levels of history, it’s flexible enough to be implemented in a variety of ways, and even has cookie support built-in, just in case the user is working with the application in multiple browser windows. I got the idea and the code base from this awesome post, and here is my implementation.
The time for excuses is over. Start taking care of your users and give them undo support, now!
P.S. The front image is adapted from this very cool T-Shirt concept.
latestcomments