

Killing the Cancel Button on Forms for Good - UXMovement
http://uxmovement.com/design-articles/killing-the-cancel-button-on-forms-for-good

======
barrkel
I strongly disagree with the confirmation dialogs' Cancel button: confirmation
dialogs are generally pointless and annoying. It's far better to provide a
means of undoing.

On the other hand, Cancel buttons on configuration dialogs in non-web contexts
are great: they relieve the stress burden of playing with settings. This is
something that freaks me out every time I end up in System Preferences on OS
X: I have no way to undo what I just did. I have to hunt around and fiddle to
put things back the way they were. I much prefer the way Windows does it with
OK and Cancel: opening up a dialog is like starting a transaction, and OK and
Cancel become Commit and Rollback.

~~~
potatolicious
> _"I strongly disagree with the confirmation dialogs' Cancel button:
> confirmation dialogs are generally pointless and annoying. It's far better
> to provide a means of undoing."_

There are some places where it's appropriate - but IMHO they should _never_ be
named "OK" and "Cancel". One of the better things we've done to make our lives
easier is the trend to verb our dialog buttons, and "OK/Cancel" is in gross
violation of that.

OK to what? Cancel to what? People simply don't read dialogs (or, your dialog
text is just not as understandable as you think it is).

"Are you sure you want to foo?" should be followed by "Foo" and "Don't Foo",
not "OK" and "Cancel".

~~~
lotharbot
This point cannot be stated strongly enough. The buttons should describe what
you're doing, not merely affirm or reject what's in the text box. People are
trained to hit "cancel" or "no" whenever unexpected text boxes come up, and
"yes" if they're expecting it, without reading. This often leads to them doing
the opposite of what they intended.

Wording it as [Foo] and [Don't Foo] is a good start, but sometimes it should
be worded as [Foo] and [Bar] where Bar is opposite of Foo. For example, [Quit]
and [Continue], or [Leave] and [Stay].

EDIT: an example of the wrong way to do it: "Press OK to stay on the current
page, or Cancel to receive 50% off!" <http://failblog.org/2010/10/08/epic-
fail-photos-cancel-fail/>

~~~
nailer
Agreed. Say I quit a long running job. And a menu comes up asking me ok or
cancel. I want to quit the job, so I cancel, right? Oops, that cancels the
quitting, not the job, .

quit job or coninue job would mean more than ok or cancel.

------
teye
Yawn. Jakob Nielsen scooped you by ten years.

<http://www.useit.com/alertbox/20000416.html>

~~~
Qz
Doesn't make it less true today.

------
Vivtek
My favorites are designers who think the Clear Form button should be to the
_left_ of the Submit button. I mean, bad enough to have the opportunity to
wipe out everything I just typed, but why make it that easy?

~~~
jonasvp
Completely agree. While the cancel button might be useful, the reset button is
such an invitation to disaster, I don't know why it was even invented.

If I spend time filling out a form, why would I want to clear it? If I make an
error, I'll correct it - not start anew. When I see a "clear form" button
nowadays it's a big red flag that the owner of the site is still stuck in the
90s usabilitywise.

~~~
Vivtek
Well, for what it's worth, I thought it was stupid in the 90's, too. I never
did understand the logic of having a reset button.

------
Timothee
Personally, I'm not against Cancel buttons in some cases for the simple reason
that I'm not sure the site will work fine with the Back button on multi-page
forms that are used for almost all payment transactions.

I also tend to use a Cancel button if there's one, or a navigation link to
exit the process because I'll be sure to avoid a "resubmit POST values?" alert
if I were to click 'Back'.

------
jlesk
I use Cancel buttons for pop-up forms all the time. It usually just hides the
containing div, so re-opening the form will show the data as it was entered
previously. Making the Submit button 2-3x longer than the Cancel button helps
mitigate the risk of accidentally hitting the wrong thing.

------
rkuester
Neither "ok" nor "cancel" are appropriate answers to the yes-or-no question,
"Are you sure?"

------
evanrmurphy
_Cancel buttons...[give] users the opportunity to accidentally click on it
when it’s mistaken for the Submit button. Removing the Cancel button
completely removes the chances of this mistake happening._

This is an excellent point.

 _There are two situations where Cancel buttons are proper.... The first
situation is confirmation windows.... The second situation is progress bars._

Would this suggest that Cancel buttons are never appropriate on basic HTML /
mobile websites? This seems like an extreme rule to me, but maybe it's good
advice.

------
tav
While I agree that they're often misused in forms, I'm not a 100% convinced
that killing the cancel button is the right way to go. They're increasingly
used as a web equivalent of the "close" button and in that context, they do
function quite well.

A substantial portion of both users and AJAX apps still don't use/support the
back button effectively. And when there's a form overlaying the content, using
a cancel button to get rid of it does make a fair amount of intuitive sense...

------
systemtrigger
Completely agree. So many cancel buttons are just clutter.

------
wvenable
All my web application's forms have onbeforeunload handlers that prevent you
from accidentally navigating away from the page (including the back button)
once you've started editing a long form. It's possible to continue to navigate
away from the onbeforeunload dialog but the cancel button is a nicer way out.
Every cancel button also has a confirmation on it so you can't accidentally
cancel the form either.

~~~
lovskogen
What if the user really want back? You just broke the back button and moved
it's functionality to Cancel.

~~~
wvenable
No, they get a dialog (you can't completely prevent navigation in a web
browser). They can say, "yes I want to lose all my changes", and then it will
go back.

------
decadentcactus
Considering most progress bars are just approximations anyway, Cancel buttons
don't even work half the time.

I distinctly remember pressing Cancel while loading a TF2 server, with maybe
80% filled, but it loads anyway, because it had actually finished loading,
just didn't update the progress bar.

------
stackthat
One big question is if you need confirmation button then should you put a
"Cancel" or "No"? or both?

------
evanrmurphy
In Gmail, the "Compose mail" form has a Discard button that serves as a
Cancel. Have others found this to be a nuisance? (It's never bothered me
before, and I think I've often found it quite convenient.)

~~~
mooism2
GMail's "Discard" button is needed because GMail saves your unsent e-mail as a
draft otherwise. Whereas most forms don't upload your form while you're still
filling it in, which is what makes "Cancel" superfluous from a functional
point of view.

~~~
evanrmurphy
Gmail's basic HTML view also has a discard button, even though it doesn't
auto-save drafts.

You make a good point, though. Maybe basic HTML just has Discard to stay
consistent with standard.

------
yycom
IME users (office drones) seem completely ignorant of the back button.

------
stretchwithme
Amen. How long will the dialog box drive people's thinking?

------
gcb
forms does not have Cancel button! they have reset buttons.

big difference.

There's no input type=cancel. only input type=reset

<http://www.w3.org/TR/html401/sgml/dtd.html#InputType>

And resetting is sometimes desirable, say, for a real time map filter form.
where you can play with the controls, reset, play some more, reset... you get
the idea.

Now, for forms that are presented to the user empty, as most are, the reset
button with a 'cancel' label, is just plain dumb. yes.

