

Never Use a Warning When you Mean Undo - jayliew
http://www.alistapart.com/articles/neveruseawarning/

======
pan69
"Oh, and the next time you see a warning used instead of undo, send the
designer of the application/website a nice e-mail suggesting that they
implement an “undo” feature instead."

A typical designer point of view on the world. Has the author any idea of how
much time (therefore money) it can take to implement Undo features across the
board? I don't think so. Successfully implementing Undo functionality can be a
daunting task. The question simply comes down to; is it worth the money
investing in this feature? For most applications it simply isn't, no matter
what mister visual UX dude thinks or says.

~~~
Jach
There's a lazy solution: do what Gmail does. Rather than have an actual undo
stack, especially for those pesky things like removing information from the
database, just delay action for 5-30 seconds and offer an undo button until
the time expires.

~~~
d0mine
It is not a real undo it is a warning with timeout.

~~~
phillco
"LAUNCHING MISSILES (click here very quickly to undo)..."

~~~
d0mine
"cancel" and "undo" is not the same thing.

You can cancel the launch. But you can't undo it. It is thermodynamically
impossible.

~~~
phillco
Right. But that's how Gmail is marketing it. "Undo send" gives you the
impression that Gmail is reaching through the tubes and yanking your message
back for you, but in reality it's just cancelling a launch that didn't happen
yet.

------
acabal
In my perfect world, all software, from nuclear reactor software to Angry
Birds, would be powered by a learning neural net that dynamically reshapes the
interface as it learns my most common actions and foibles. It would interface
directly with my brain so that there would be no chance of my mouse slipping
and clicking 'OK' when I meant 'Cancel'.

Oh wait... that would be incredibly time-consuming to implement, would very
likely only marginally improve the experience for the majority of users, and
would be plagued by edge-case pitfalls.

------
trustfundbaby
I don't think he's thought through the difficulty of implementing something
like this in a non trivial situation ... or at least he doesn't dwell on it in
a way that suggests that he has.

I mean, what happens if you delete 3 things, and realize that you want to undo
the 1st one?

What happens if the action you take, changes the state of the user's data in a
way that is unrecoverable?

I like where he's going, but I'd love to see a more rigorous treatment of the
idea.

~~~
munificent
> I mean, what happens if you delete 3 things, and realize that you want to
> undo the 1st one?

Just drag the first one out of the trash and leave the other two there.

> What happens if the action you take, changes the state of the user's data in
> a way that is unrecoverable?

Store the previous state.

~~~
shaggyfrog
"Store the previous state" sounds great in theory. Doesn't always work in
practice.

Storing the state of the system may involve a non-trivial amount of both
storage and/or time. Or the backing store may not allow for reversing a
deletion.

pan69 really said it all: these ideas sound great to designers, but cause
nightmares for the programmer that actually has to implement it.

~~~
jasonlotito
> Storing the state of the system may involve a non-trivial amount of both
> storage and/or time. Or the backing store may not allow for reversing a
> deletion.

That sounds like an excuse. The problem isn't with the undo. It's with the
rest of the system, so clearly their are other problems to address first.

~~~
shaggyfrog
To put it bluntly, this is an ignorant response. Many systems have constraints
beyond the control of the developer. It isn't an _excuse_ to say, for example,
that doing save/load from a PS2 memcard is slow and non-trivial; that's just
the way it _is_.

A good designer will have a deep understanding of the capabilities and
limitations of the medium they are working with. (Think Jonathan Ive and the
countless testing they do using all sorts of different construction
materials.) A poor designer will come up with a grand idea, but no idea how to
implement it, and then blame the programmer if it's impossible to do.

~~~
jasonlotito
I said in another comment that certain cases (like games) are the exception of
the rule. But in context with the article, what I say stands. Implementing
undo for users is fairly trivial. If it's not, their are other problems that
need addressing.

~~~
shaggyfrog
You are being hopelessly dogmatic on this point. I'm not sure it's worth
belabouring.

~~~
jasonlotito
I'm coming off that way, and I apologise. I wasn't clear. I believe the
original article was mostly discussing these factors within the confines of
web based applications, which is what my comments here have assumed. Obviously
their are exceptions to the rule, and a true undo is not trivial. However, a
true undo, and an undo that meets the users needs are different things
entirely. While it's unfair for me to suggest that implementing undo is
trivial, it's also unfair to assume that implementing undo has to be
difficult.

~~~
shaggyfrog
I think we have common ground, here. If it's reasonable to put in undo
(pragmatically speaking, in terms of money, time, technology, etc.) then I
agree the user _is_ better off having it than not.

------
vietor
How exactly does he propose to undo the closing of an application, as the
application developer? It was his canonical example for the entire first half
of the post, and then he jumped to trivially undo-able actions _within_ an
application when it came time for examples.

How does he feel about the UX tradeoffs of blocking state synchronization to
non-volatile storage for every user action? Better or worse then _usually_ not
losing data on an unsaved close?

How about the UX of restoring state when you re-open the application? Should
the user see the last state every time? The last manually saved state with an
option to roll-forward? A huge obnoxious recovery dialog box like OpenOffice
when you kill it without saving?

These are the questions the first half of the article setup, not trivially
reversible actions within an application.

~~~
ubershmekel
E.g. mobile apps just save their state all the time and revert when you reopen
them. Imagine if MS Word didn't ask you before it exits, but instead it asks
you when you open it if you want to restore previous state.

~~~
vietor
Right, and both of those involve UX tradeoffs. Which was my point and why I
gave them both as options in my initial comment. Having read the first half of
the article, I was expecting the second half to address the issues which these
various options raise.

Sure you _can_ "Just save state all the time", but doing so involves
tradeoffs. Tradeoffs which were not addressed at all in the article.

Your MS Word example is exactly what OpenOffice does when it's been closed
without saving. It's really obnoxious. I was hoping to read some UX insight
into how to make those kinds of actions less obnoxious without losing their
helpful functionality when it's needed.

In general I agree with the core idea of the article. But it lacked useful
discussion about the hard UX problems involved, opting instead for some easy
in-application examples.

~~~
jasonlotito
> I was hoping to read some UX insight into how to make those kinds of actions
> less obnoxious without losing their helpful functionality when it's needed.

An initial ideas I had, fairly trivial in the context of OpenOffice and Word
asking to return to your previous state:

If a short period of time has elapsed since closing the application, simply
resume state. Short period of time would have to be determine, of course. But
it's fair to say that if I close an application and open it again within a
minute, I probably want to resume the state. Additional conditions could be
added based on testing: didn't save in the last close might be a good
indicator.

------
weixiyen
The fundamental problem with this article is that the author brings up a
problem, but does not offer a practical real-world solution. The article only
pretends to offer a solution.

A List Apart is well known for helpful and practical solutions, down to
detailed implementations. This does not introduce anything helpful or
practical.

All I got from this article was that undo is better than a confirmation modal.
Thanks for stating the obvious.

------
GeneralMaximus
(This post turned into a rant. Sorry about that.)

The OS X shortcut for quitting an application is Cmd+Q. The shortcut for
closing a window/tab is Cmd+W. Q and W are adjacent on a standard QWERTY
keyboard, which means you sometimes hit Cmd+Q when you meant to hit Cmd+W.

Now hitting Cmd+Q accidentally doesn't matter most of the time. Most
applications will ask you if you want to save your changes before you quit.
Web browsers will offer to save your session. Also, most applications save
their state anyway, so you can relaunch them and continue working. So not a
problem, right?

There is one piece of software, though, that refuses to follow this
convention. A program that has ignored every HIG and UI convention in the
history of all known universes in the name of creating a "better" user
experience: Google Chrome.

I didn't complain when they hacked the window system to put tabs on the top of
the window. I didn't complain when their shitty multi-process model brought my
aging MacBook to its arthritic knees. I didn't complain when they opened PDFs
in the browser without asking me first, or when they used filetype
associations from my OS instead of letting me redefine them. But this just
takes the cake: Google Chrome will quit without a confirmation if you
accidentally hit Cmd+Q when you meant Cmd+W. In the last month I've
accidentally quit the browser twice, and lost about 50 tabs every time.
Surprisingly enough, there is no extension that will fix this behavior. Yes, a
couple of hacks exist, but they only work half the time.

I don't expect Google to fix this, though. There are gaping holes in Android
that Google has simply ignored or outright refused to fix. I don't expect them
to treat Chrome differently.

~~~
desigooner
ever tried enabling the "Confirm to Quit" setting in the about:flags page in
chrome?!

A little search before ranting would have certainly helped.

~~~
GeneralMaximus
Thanks for the tip. I didn't know about that page. I still don't see any such
setting, though. I'm on Chrome 8.0.552.237. What version are you using?

~~~
slig
IIRC, it's 9.x and up only.

------
smosher
Generally, adding "undo" of some kind doesn't seem like a great idea. Too much
complexity to solve a simple problem which virtually never arises in my
experience.

I've always found the "«save» «discard changes» «cancel»" dialog to be
effective. The outer (easy) "save/cancel" choices are non-destructive. The
save dialog is a file selector which can be easily canceled and "cancel"
brings you right back into the program which you are free to try quitting
again. And face it, when we form habits like this (which, I agree, are natural
and to be accepted) we tend not to form them around the longer options. I
always scan the "discard..." button semi-consciously before clicking it
because the information is long, and specific to the operation (i.e. throwing
everything away) so if you do manage to form a habit around "discard changes"
it will apply only when that is what you want to do. (You probably won't form
a habit about generally clicking the largest button regardless of the
situation.)

A solution I do not like is using "clever" dialog window placement or mixing
up button orderings. These are just frustrating and do little to solve the
problem.

------
rst
"Undo" is one alternative to warning dialogs that users learn to click through
mechanically.

There's at least one other: if you're going to implement some irreversible
action, find a way to delay it --- like in email programs or file managers
where the button labeled "delete" moves things to a trash folder, and the
_real_ deletion operation is separately labeled "expunge". Implementing this
sort of thing is usually easier than keeping the "real" delete operation, and
then implementing a separate "undelete" which works in full generality.

~~~
Waywocket
That's even worse. Users habituate themselves to the two-step process in
exactly the same way, only now they're annoyed because you're forcing them to
do extra unnecessary work.

------
taylorbuley
This article spends way too much time clearing throat with an explanation of
why we need to make our interfaces usable.

~~~
metageek
I think I have to disagree. The habit he's pointing out is so deeply ingrained
that we need to pull it to the surface and examine it for a bit before we can
talk about it coherently.

~~~
taylorbuley
Agreed, but I don't think those are necessarily the kind of people in his
audience -- reading Hacker News and articles on A List Apart, I feel like one
can assume "make things usable" is a principle on which we can all agree.

------
Groxx
If your software tries to anticipate that you _might_ want to not-close when
you told it to close, you end up with the opposite complaint: it takes too
long for anything to happen.

I'd be willing to bet that there would be _far_ more complaints that your
program takes a minute longer to shut down than that they told it to quit when
they didn't want it to quit. I'm a _huge_ believer in software that people can
use, and love trying to make things totally foolproof for as many people as
possible, but I also believe that to truly be _useful_ on a computer you
_must_ learn some of the ground rules. Like anywhere else in life. The trick
then becomes teaching your users without them realizing or fighting it, not
trying to predict the inherently un-predictable (ie, the immediate whims of
anyone and everyone).

------
agentultra
Predicting user behavior is a fruitless time-consuming task.

I get the gmail example... but the quitting example?

How are you supposed to know that _this time_ they really meant to quit and
didn't just slip and click the wrong button?

This is why I hate GUIs. I'm too clumsy with a mouse to trust it. How many
times have I opened the wrong application from an applications menu and had to
wait for it to startup only to shut it down right away? How many times did I
close the application I was using by accident and have to open it again?

I get a lower error rate on a keyboard using a tiled window manager.

So... should I code a new feature, fix a broken one, or spend time trying to
predict what mistake (or intentional action) you are going to make next?

Priorities...

------
lhorie
Similar to keyboard accessibility, undo is one of those things you should only
consider if you don't have any less time consuming features that you should
implement.

The easier workaround to the "oops, I didn't mean to do that" problem is to
make it harder or awkward to do it in the first place - e.g. turn reset
buttons into smaller, less prominent links, don't put delete buttons right
next to edit buttons, don't cram unrelated next-step actions together (e.g.
"send email" and "add attachment" shouldn't be right beside each other), etc

------
joh6nn
it's surprising to me that so far, no one has pointed out that this sort of
user behaviour is A Bad Thing. while Undo is definitely important and
desirable, a user base that ignores attempts to communicate with them is not.
i don't know if the issue is that warnings are the wrong way to communicate,
or if it's that we haven't done our jobs on user education, but the fact that
we have somehow trained the average Joe to just click "ok" without reading is
indicative of a larger problem than irreversible actions.

~~~
BenSS
Dialogs like that should be reserved for important, irreversible changes but
instead are used everywhere. They're no longer read and solely seen as an
interruption to the program flow.

Always providing undo, or a delayed action without interrupting what the user
is doing eliminates the need to retrain users.

------
stoney
But when I close a program, most of the time I want it to go away and go away
quickly. If the program hangs for a few seconds while it saves data that I've
already told it I don't want on the off chance that I decide I really do want
to restore it later, then I am likely to get annoyed with it to an extent that
I'll stop using that program and never find out what a useful feature that
undo functionality was.

------
csomar
There is a technique that is used in some applications (Windows) that worked
really well, at least with my mind.

Most of the time, the "Yes" button is in the left. I have the habit to click
on the left. Some application inverse the position. When the position is
inversed, my mind stops, because something is wrong. And yes, I read the
message and select the appropriate button.

