Killing the Cancel Button on Forms for Good | Hacker News Reader

Killing the Cancel Button on Forms for Good

uxmovement.com

55 pointsUXMovement42 comments

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.

> "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".

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/

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.

Preference dialogs that have a dozen tabs each with a dozen settings need cancel buttons. Make a better and simpler preference window and the need for those buttons goes away.

I don't need to confirm every command I issue. That is just madness. I like zsh confirming when I type `rm foo/*`. I don't like a preference dialog confirming that I really meant to change some colour (OK and Apply don't pop up but they are confirmations nonetheless).

The problem with "Preference dialogs that have a dozen tabs each with a dozen settings" is that users will not remember what they changed. Therefore, they won't know which of cancel or apply is the worst of the two evils they have to choose from.

The better thing to do is to do away with modality and to provide live updates of any setting users make. That way, users can see the effects of each preference change as they make it (as with Mac OS X inspectors and the Office ribbon). 'commit' buttons have their role, but they should be the exception, for actions that the user cannot easily revert. Also, they never should be labeled with generic phrases such as 'OK'.

I agree. Perhaps I should have phrased my first paragraph differently.

With OS X, every change is immediately visible so you immediately know what to undo. With Windows, nothing you change takes effect unless you click OK or Apply, at which point the Cancel button has no effect and there is no Rollback. How is this better than OS X? It just adds three superfluous buttons.

It's simply not true that every change is immediately visible; only for appearance preferences is that the case. It isn't the same case for behaviour configuration.

It's hard to understand how uncomfortable it feels when you're used to having this safety net, and it's taken away. It makes changing the preferences (for most applications, not just System Preferences) a much more cautious affair, in my experience. Even something as simple as changing the default font used in an application - once changed, it can take a lot of hunting to get it back the way it was.

If a change is not immediately visible, how would a Cancel button help? Preferences dialogs on Windows are modal, if a change is not visible you can't see the difference until you have committed the change. Especially so if a change requires a restart of the application or reboot of the OS, both of which would remove the Rollback button and the dialog it was attached to.

Also, the default font for an application is an appearance preference.

My point about the font is that even when it's an appearance preference, and you have a nice preview, it's still a pain in the neck to get it back to the way it was before.

There's also another aspect to settings. Many settings are logically tree-shaped: certain settings only apply if a dependent setting is in effect. A very simple example: Firefox's popup blocker has some settings - the Exceptions. But the Exceptions only apply if the popup blocker is actually enabled. You can't fully explore the configuration space of an application most of the time without running into these things. But you don't want to have committed to changing these settings just to explore the configuration space. The Cancel option on the dialog lets you explore without commitment.

Now, you won't get an argument from me that the Apply button is useful. I think preference dialogs shouldn't be modal where reasonable, and that changes should be previewed across the application. That's not always the case in Windows, and it should be better. But on topic here is the Cancel button, and that's what's missing on OS X, and where I believe Windows has it trumped.

Why would you be exploring the options of the popup blocker if you didn't have it enabled, let alone changing them?

Chris, I brought up the popup blocker specifically because it was a very simple demonstration of the conditional / predicate nature of exploring the configuration space, not because of its intrinsic configuration worth. Your response makes me think you're not responding in good faith, and have little interest in honest discussion.

The reason for exploring the configuration space? Are you serious? In order to discover what is possible to be configured, of course! Take another example. I'm interested in protecting my privacy, but not at the cost of too much convenience. So I'm interested in clearing some history when my browser shuts down; but not things like cookies or saved passwords. In order to discover what options are available here, in Firefox I need to enable the "Clear history when Firefox closes" option in order to discover how configurable it is. But I don't know how complicated things are going to get when I click on that Settings... button, and I certainly don't want my cookies etc. cleared prematurely, but I can comfortably stride forth into it, because I know I can hit cancel at any time and back out.

I do admit it was wrong of me to suggest that you would not explore the options of the popup blocker if you did not have it configured. Maybe this is because the predicate nature of exploring the configuration space is less common on OS X. For example, when configuring Secondary Click for my Trackpad there is a dropdown that is enabled whether or not the checkbox is checked, allowing me to explore the options without checking the checkbox. Why disable these options? This seems like a better solution than having a Cancel button.

I also suspect that the Cancel button is just masking another problem, that settings dialogs get nested so much that you forget what you changed.

This is definitely a problem. If you apply/ok a submodal but then cancel the parent modal, I believe the original apply/ok sticks. This tree-like UX is bad and should be avoided.

Could you give examples of options that should need a second confirmation? I think the instantness and not having to Apply is great - but maybe I'm not setting the same options as you.

On a Windows 7 system, right-click the desktop and select Personalize. Here, you can change the desktop background and window colour theme; changes are previewed instantaneously. But there are two buttons at the bottom: "Save changes" and "Cancel". So you can muck about with full screen preview, but still cancel at any time.

It's not a second confirmation: it's an ability to undo what you just did.

That's true, it's better usability. But not all options are so visual that it's easy to muck around and then cancel.

E.g turning on Bluetooth – either the user wants to turn in on, or not. Sure, the Apply / Cancel removes the possibility of someone clicking around hitting the "On" checkbox. But I think it's better to optimize for regular use, and not have a Apply button when you just checked to apply.

I don't think the Apply button is a good idea, as I said in a cousin posting. Ideally changes would be previewed in a modeless dialog, even to the point of temporarily enabling Bluetooth, but still with a cancel option.

But wouldn't the checkbox serve as a cancel option too?

Yawn. Jakob Nielsen scooped you by ten years.

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

Doesn't make it less true today.

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?

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.

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.

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'.

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.

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

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.

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...

Completely agree. So many cancel buttons are just clutter.

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.

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

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.

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.

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

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.)

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.

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.

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

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

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.

Reply on news.ycombinator.com