Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Personally I have never used it. I don't put information in a form and then decide everything needs to be cleared. I would edit one field.

Plus cancel in a UI suggests canceling an action which is in progress. Filling a form is not something in progress.

Would a "Clear All" button be more appropriate?


EDIT: (from merged question)

If "reset" buttons are not redundant, then why so? Give me a case where they are completey accepted, useful and maybe even encouraged/required?

If you feel obliged to put one in; does that imply that your form could be more usable?

share|improve this question

10 Answers 10

The only time I would use a 'cancel' button would be in situations where a customer has been able to save an incomplete form and come back to it later either in the same session or in a later session.

I would also attach a noun to the label of the button to give clearer meaning of what was being cancelled.

'Cancel order' 'Cancel quote'

You may also find a 'Delete' button is more appropriate.... eg 'Delete card details' 'Delete item' etc

share|improve this answer
    
Elaborate on this more. What does cancel do? Unsave previously saved data? Cancel and then what happens? If you have no intentions in the future with the form, do you actually come back and do anything? –  Tony_Henrich Aug 29 '10 at 17:49

No.

If you mean something that cancels the current form and takes you back to where you were, the browser's back button is already there.

If you mean a "reset"/"clear all" button that clears everything you typed in, then NO, NO, NO! It's way too easy to accidentally click, and adds no value.

Either way, here's a must-read article on the subject: Reset/Cancel Buttons Considered Harmful.

share|improve this answer
2  
Interesting take (Note that there is no "escape path" when ADDing a COMMENT on this site! Yikes. –  Kevin M Aug 30 '10 at 1:26
1  
I find it considerably painful and time consuming to move my mouse to browser's back button and then back to working area. I'd prefer Cancel button or (even better) a link to get away from the current form. –  parxier Aug 30 '10 at 2:13
1  
Alt+tab will get you back to where you need on most machines. –  Chris Aug 30 '10 at 22:05
1  
I would make an exception to the second part if you have a complex dynamic form that adds / changes new elements based on previous input. –  peterchen May 27 '11 at 15:55
    
@KevinM I know it's been 3 years, but... When you posted that comment, was there no delete link? –  Izkata Jul 26 '13 at 17:07

The only case where a cancel button is needed would be if a user clicked to update a setting (personal information, account setting, etc.).

share|improve this answer

Definitely unnecessary!

The reasons given here are correct, plus you can look at this question on the same topic:

"Clear all" button history

share|improve this answer

The article Robert Fraser cites is a good one, but it's a decade old. The web has changed somewhat since then. Do you honestly agree with the sentences highlighted in the image below?

alt text

We must be careful to distinguish between a browser-based experience that is "documenty" (where the BACK button works just fine) and "applicationy" (where the user may need a means to abort some task or unit-of-work sequence.

Example: adding a comment on this site appears to be unrecoverable. Once you click "add comment" (in lower case" you are not allowed to bail out. (I'm using Chrome 5.x...) Hitting the BACK button would take me off the page, away from the question, etc. Not the desired result when all I wanted to do was bail out of a wring-headed comment.

share|improve this answer
2  
GREAT answer! I'm glad someone posted a dissenting opinion. The Nielsen article was written before Gmail, Facebook, and FourSquare. This is very anecdotal, but many times I've had users ask "Now how do I go back to the list?" even though the back button would have worked and breadcrumbs were provided. –  Patrick McElhaney Aug 30 '10 at 13:32
    
Back at you, dude! Thanks... –  Kevin M Aug 30 '10 at 16:04
    
Thanks for posting! Yup, my answer was too polarized and the article is way out of date. There are definitely good uses for a cancel button (and now that you mention it, this website is probably one), but, IMO, it should be used sparingly. –  OverMachoGrande Aug 31 '10 at 11:52

I think this really depends on the context:

  • If form values are saved (e.g. advanced search) it always makes sense to have a reset button.

  • If it's a one-use form (e.g. contact form) it's not necessary because the user can just navigate away from the page if he doesn't want to submit the form for whatever reason.

If there is a reset button make sure there is no way it's mistaken for the send button. I usually don't make buttons but links to be sure it's not clicked accidentally when a user tries to submit the form and didn't read the buttons (this is probably the most frustrating thing that can happen when submitting a form...)

share|improve this answer
    
Yes, reset is intended for when a user submits a form, doesn't like the result, and returns to the page to revert things back to the way they were. Preferences, profile edit, and advanced search are possible applications. Not too useful for initial registration or purchasing forms. Since reset is something users do when they return to a form, the button should be at the top of the form, not the bottom. This makes it easier to find and reduces the chance of it being selected accidentally when the user meant to hit Submit. –  Michael Zuschlag May 27 '11 at 12:22
    
Thanks for the welcome! :). You'd made me think about a form with a few <select>s; in that case it would be a lot of hassle to go and reset the <select>. But say if it was an advanced search, you may only want to reset the "location" <select> without losing the rest of your choices, so in that case **should there be a reset/revert button next to each <select> –  Adam Lynch May 27 '11 at 12:27

If it is clear how the user can navigate away from the form, without submitting it, when the reset button isn't as useful. Including it can only raise the possibility that the user will click it by accident and clear away all of their hard work.

What you do sometimes need is a cancel button to navigate away from the form, but only when other navigation isn't obvious.

I think resetting the form to how it was when the page was loaded is rarely an action that the user wishes to perform.

share|improve this answer

A cancel button makes sense in a web application where editing a form establishes some sort of lock on a resource, such as preventing data from being edited by other users. The 'Cancel' button can be used to allow the user to release the resource lock immediately, instead of having the system wait for a timeout or for the session to end.

share|improve this answer

Cancel buttons don't belong on forms. They are meant for progress bars and confirmation windows where system processes are involved. This article explains how cancel buttons can confuse users.

Killing the Cancel Button on Forms for Good

share|improve this answer

I know this question's 3 years old but I want to modernize this and add that for accessibility reasons, having an explicit cancel button is absolutely necessary to avoid the "No Keyboard Trap".

Here's the source from WCAG 2.0: http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-trapping.html

A modal dialog box A Web application brings up a dialog box. At the bottom of the dialog are two buttons, Cancel and OK. When the dialog has been opened, focus is trapped within the dialog; tabbing from the last control in the dialog takes focus to the first control in the dialog. The dialog is dismissed by activating the Cancel button or the OK button.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.