Undo Made Easy with Ajax (Part 2): Time-Sensitive Actions

Commentary Software Development

This is the second part of the Undo Made Easy with Ajax series. If you are jumping in late, make sure to check out part 1.

Last time we covered the event queue method, an entirely client-side way of implementing a light-weight, multi-level undo. I mentioned a couple of caveats, including that it does not work in multi-user collaborations, and that it doesn’t work for time-sensitive actions like sending emails. I missed a significant caveat that one of my readers, Alexander Botero-Lowry, pointed out: That two tabs, pointed to the same page, could get out of sync. I wrote about how to solve that issue with cookies.

This time, let’s take a look at solving Undo for time-sensitive actions. In the event queue method, we could wait until the “onunload” event to sync the user’s actions from client-side to server-side. For time-sensitive actions like sending emails, we don’t have that luxury. Worse, email is a push technology. Once an email has been released into the wild tubes of the Internet, it cannot be unsent.* For the unfortunate who hits “send” only to realize that they’ve CC’ed their boss on a steamy love letter, the only things left to hope for are power outages and spam filters. Given how often spam slips past my filters, the outlook is not so good.

The email needs to get sent soon after the user clicks “send,” and “send” can’t really be undone. What can we do?

We must turn to the interface designer’s old nemesis, the time-based interface, for the solution. Normally, time-based interfaces fail to be truly usable because the timing is never quite right. For some people it is too fast, for others it is too slow. Even your own perception of time changes based on your mental load. When you are thinking hard, you don’t notice the passage of time: What was too slow before will now be too fast. The old saying, “Time flies when you’re having fun,” actually has user-interface implications. A great example of the failure of timing-based interfaces can be seen in text entry on a cellphone, but that’s a topic that will have to wait for another post.

When sending an email, typically it’s during that “‘oh-no’ second“— the split second after hitting send — that you realize that you’ve sent the email to the wrong address. Wanting to unsend an email you sent an hour ago occurs, but with much less frequency. Thus, a time-based solution where the user can unsend an email for only a short period of time makes sense: The back-end can just delay sending the email by 30 seconds to a minute, and if the user wishes to “undo” sending during the grace period, the back-end dequeues the email so that the email never gets sent.

Now, I’m not particularly happy with championing a time-based interface, but I am sandwiched by constraints. On one side, sending an email is a real-world action that is not undoable. On the other side, emails need to be sent in a snappy manner. Undo for time-sensitive actions is a canonical problem, and the only solution I see is a compromise (if anyone can figure out another solution, I’m all ears!). In general, many situations arise in which we as designers are trapped by immutable constraints. The best we can do is to design systems that take care of the most likely use-cases, and allow users to gracefully back out of their most common mistakes. Time-based Undo won’t solve every case of wanting to unsend an email (it won’t help with late-night emails you discover you sent the next morning), but it will catch the majority of mistakenly-sent emails (both the “‘oh-no’ second” variety and the “I-clicked-the-button-accidentally” variety). And it will catch many more emails than a warning ever could. It turns out that Paul Buchheit, the creator of Gmail, has the same thought. Too bad it hasn’t been implemented — it’s a low hanging fruit that could give Gmail an even greater edge over its competition.

There’s really not much to this method. To implement it in the Ajax style, you just need a mutex and a timer. When the time runs out (or the user navigates away from the page), the message is sent. A more robust way involves setting a flag on the server along with a server-side countdown. The tricky part of this whole thing is how to indicate the time remaining in a way that does not scare the user. For instance, a count-down timer evokes an visceral reaction of panic:

Not very good feeling, is it? Instead, a slow fadeout works better:

A count-down that doesn’t begin counting down until the last 10 seconds might work too. It’s an excellent challenge to design mechanisms for nicely displaying a time-limited Undo. Share your thoughts in the comments section. Bonus points for mock-ups of any kind.

Next time, I’ll talk about some of the neater, more robust methods of doing Undo in an Ajaxy way.

* There are some solutions — albeit not very good solutions — to this problem. For instance, an email can contain only an embedded image of the text. If the image is stored on your server, then to unsend an email, you just remove or change the image. This effectively unsends the contents of the email (if not the actual sending). Thus someone will know only that you sent an email (and its subject line), but not the content.

That’s pretty cool. I wasn’t liking the idea in the beginning, but I bought into it by the seventh paragraph (the one that starts with “Now, I’m not particularly happy …”).

A message like,

Your message will be sent in X seconds or when you leave this page. Undo send. Learn more…”

would earn gmail a fantastical amount of brownie points, although I’m not sure if the length is adecuate.

I showed your 2nd solution to my girlfriend and she likes it, so i guess thats a good sign :).

An interesting, tenuously related point. With PMing systems (think sending someone a message on Facebook) it’s perfectly possible to undo sending a message before they have read it. Yet so far the only big player I know to implement it is AOL.

enabling user irresponsibility is stupid. This unsend idea is anti-darwin.
I do see and appreciate that it is intelligently designed however.
If you do continue be sure to add a dialogue box that says “Are you really sure you want to send the message now?”. Doing so will continue the trend of user frustration at supposedly helpful technology. That way Microsoft will at least review a possible purchase of the technology.

Wow, I wish I had had this feature a few times. On the other hand, I don’t find either of the two mock ups terribly compelling. I agree the countdown is a bit.. scary, and the slow fade out is a better solution, but the slow fade out doesn’t give me that same ability to know that I need to do this RIGHT now. A reverse progress bar might be something to toy with, maybe go crazy a little and let people adjust the time if they know they need to send a message right NOW, or know they need a bit more time to realize what a stupid idea it was. Though I’m afraid that might cause more problems than it solves. I love the idea though. I think I will toy with it in an app I’m writing to see how that goes.

I agree with the second mockup, but have comments on details not shown there.

In this scenario, undo is the 1% case. Most messages with not be unsent. Therefore, you do not need a dire or invasive message. In the style of Gmail-delete-message, put a benign message on the screen; a message that is visible, but does not grab the user’s attention:

“The message has been sent. [Undo] (time sensitive)”

The message disappears when no longer relevant. And there is no need for the follow-up “Too late now!” message box.

Since the use case is undoing very recent actions, the user will give the button attention in the 1% case and easily ignore it the rest of the time. Bothering the user with backend details like how long the undo is active or making the message in-your-face does not add value to solving the user’s problem.

Another solution is to wrap messages in DRM so the sender can later send a delete to the receiver which the receiver’s client will honor. That’s not 100% and it brings with it a whole host of problems.

Interesting idea, and since you mention that time delays can be too long for some, and too short for others, why not go one stage further and make it adaptable. In other words, learn from the users behaviour. If a particular user regularly has to hit the undo button, then modify the timing to be slightly longer, or change behaviour so that they have to hit a confirm button as well (but exclude this from users who rarely or never hit the undo button). The overall timings and usage could then be used to modifiy site defaults. Could be confusing for end-users but us humans are quite adaptable too.

Paul has stated “All actions should have ‘undo’”. How can this be done, because some actions are time-sensitive and non-idempotent. Time sensitive actions can’t have a undo simply because we haven’t figured out have to travel back in time!!

But I agree that in the computer world, things are different. We can make that “compromise”. But is it worth it?? When the user sends a mail, he usually is careful enough to check the addresses he mentions. Also, for people who are in some kind of urgency wouldn’t want to wait for some 20 damn seconds to send that petty little mail (addition to the mockup shown above - the user could cancel the countdown and say “send it now”). Thunderbird has this feature of “Send Now” and “Send Later”. I rarely use the “Send Later” option.

Also, the mockup shown above could display the addresses to which this mail would be sent. The user has no way to verify.

Anyway, it makes good sense to have undo for those deletes (deletion of mail, deletion of some blog entry, etc).

Also, isn’t the above mockup a “Cancel” rather than a “Undo”!!!!!

Although I don’t agree with everything in karuna’s post (particularly with respect to his presumptions of what users “usually” do), he touches an interesting subject when he states that it’s really a “Cancel” and not an “Undo.”

It helps to differentiate between how the system works and how the user thinks it works.
From a technical standpoint, Aza’s Undo is a timeout that can be cancelled. But that doesn’t necessarily mean that it’s best to present it to the user as a cancel. This is a pretty difficult design decision. Sometimes presenting a system differently from how it really works is the only thing that can make a complex system useable (and I mean bare usability, not humaneness). But sometimes, when the system image misleads the user, it spells disaster.

As of now, I’m still undecided whether a Cancel with a progress indicator or Aza’s Undo would be the better idea.

Cancel & progress indicator:
[+] Commonly used with time-stretching processes (a concept that fits the timeout).
[-] (Here,) Sending a mail is not a progress. A progress is only completed when the progress bar went all the way to the right, right? So users may sit and wait for the progress bar to finish before daring to continue their work or closing the browser window.

Undo:
[+] The user thinks the action has been executed, so he won’t hesitate to close the window or do something else.
[-] Timeout-based undo is a new concept the user has to learn.
[-] This concept can be misunderstood. What if the user thinks that this undo, like all other undos, doesn’t have a timeout, and he acts accordingly? “Ah right, I’m not quite sure the recipient was correct/I attached the file. I’ll double check this in a minute, but first I have to answer this call.” When the fadeout is not in the locus of attention, the user burns himself badly. When this has happened, he may not ever trust any undo again.

Sure, the Undo message says that you can undo for 20 seconds. But that means that the user has to learn a new concept in only 20 seconds: [1] grasp that they should read the text in the first place (I usually ignore everything but the first two words of success messages), [2] read the text, [3] understand the new concept presented, and its difference to what they know as “undo”, [4] make a decision, [5] act out the decision (hopefully in time).
First I thought that a symbolic presentation (Undo + progress bar) would be the solution, but the same steps apply.

This case is a great demonstration of the problems that arise with timeouts in user interfaces, even in an otherwise well-thought-out concept.

So both attempts have their flaws. They can both be misunderstood, causing unnecessary delay in the case of “Cancel” and stress or unintended consequences in the case of “Undo”.

Weighing the two against each other, I think that the Cancel approach is safer. But then it slows down the user. *Sigh* nothing is ever easy.

What do the other commenters think about Cancel vs. Undo?

Perhaps a long click could be used to send the message immediately?

If I press and hold the mouse button for a second before releasing, I’m indicating that yes, I’m really sure, so the message is sent immediately.

I like Varsoil’s solution, but I would change “[Undo] (time sensitive)” to “[Stop].”

Just as you can’t un-print a document, you can’t un-send a message. But you can stop a message before it reaches a certain point. We don’t have to tell the user that certain point is an artificial timed delay.

I prefer “stop” over “cancel,” because to me, “cancel” is something that happens before the message is sent. A cancel button would go next to the send button, to dismiss the dialog and save the email in the drafts folder.

@patrick:
“Perhaps a long click could be used to send the message immediately?”

I don’t think this is a good idea. When we were testing web forms, many testers were clicking and holding down the submit button. They looked at the form fields again and, when satisfied with what they filled in, let go of the mouse button.

So a long click may as well signify “I’m not too sure.”

Its interesting to note Andreas’s comment - “Sometimes presenting a system differently from how it really works is the only thing that can make a complex system useable (and I mean bare usability, not humaneness)”.

I support this only when it is totally impossible for the designers/developers to find a way out to present the system in a transparent way to the users.

Keeping the system transparent is best, because the user understands whats going on. Otherwise, the designers/developers and users would be in different worlds of understanding!

Sending out a mail in many cases, could probably be represented as a point on the time-line (I mean a small duration of time). Most of the solutions that we have above, elaborates this time (delays) and gives the user an option to either - undo/unsend, stop or cancel.

Now, to weigh which one is better; undo/unsend - implies that the action has been done (mail is sent), and the user is given an option to undo (unsend) it. This is makes the system complex to the user and the user believes the miracle mail. Stop - says that the action can be stopped. And the user would probably expect a play and pause buttons! Cancel - implies the action can be canceled and the expects the system to get back to its previous stable state (mail composer).

Also, to send a mail immediately (for those who can’t wait) we could use a key combination along with a mouse click - like Ctrl+Left click or Ctrl+Shift+Left click. Or we could have a “send now” option on the countdown splash.

Also, when we follow any of the above methods and have the countdown displayed as a big splash in the center of the screen, the users should be able to review their mail without taking the undo, stop or cancel action. Probably the countdown could be displayed in transparent and the user should be able to scroll on the mail and check out the mailing addresses, attachments, etc.

Any other different thoughts on this??