The attached image shows a dialog with a save/cancel button bank and a "x" icon to close the dialog. The question I have is this. Should the cancel button even be on the modal if it does not clear/cancel any of the values? I have it in now as a redundant way to close the dialog. Should I just use the "Save" button and rely on the "x" to close, or is the use of the "Cancel" as a redundant close acceptable? My thought was that having a positive action "Save" without a corresponding negative action "Cancel" is a pattern breaker.

Thanks for the feedback.

Save/Cancel Button Question

  • 3
    The cancel button is a bigger target to hit than the [X]. Something which will be appreciated very much by people who are not so deft with a mouse. And not being deft with a mouse is not something reserved for the elderly. Plenty of people around with other causes for not being able to point and shoot all that accurately. – Marjan Venema Feb 17 '12 at 19:52
  • Another excellent point. I think I'm going to err on the side of redundancy and keep both metaphors. – gstern1994 Feb 17 '12 at 19:57
  • 1
    The cancel button is also likely more keyboard accessible – DA01 Feb 17 '12 at 22:24
  • Fitt's Law Demonstration – denis.efremov Feb 21 '12 at 12:43
  • Thanks everyone for all of the feedback, it has been very, very helpful. – gstern1994 Feb 21 '12 at 20:22

Even though [cancel] would not actually clear or cancel any concrete data, in the user's mind it confirms, that none of the values he changed in the dialog will be saved/applied. The [x] should generally always be there, it works as some sort of "way out" for the user, it gives the option to skip the choice and intuitively get out of the situation (for example when he entered the dialog by accident).

The main problem with only [x] and [save] would be, that the user does not know for sure what [x] does (and doesn't do), what his options are. [save] and [cancel] combined, let the user choose exactly what he wants to be done to the changes he made in the dialog; explicit choices make users feel in control of what they're doing.

An [apply] option is also often seen in dialogs, but I would only add an [apply] button, if there are multiple tabs in the dialogwindow.

  • 1
    +1. Precisely, Cancel is explicit about its functionality, while X is not. A user who changed a value and didn't press Save, has no way of knowing whether X will save and close, or just close. – Vitaly Mijiritsky Feb 17 '12 at 20:32

Redundancy isn't always a bad thing. Sometimes, having multiple ways of accomplishing the same task helps accommodate users who are used to different patterns.

In this case, the candidate for redundancy removal is [X] not Cancel because your modal dialog is an editable form, which has a Save button already so the counter-action has to be next to it (as you've mentioned). However, it wouldn't hurt to keep [X] because it doesn't break the flow or add any clutter to the layout.

I would rather focus on the micro-copy & functionality of the Save/Edit buttons: you need to find out whether your users expect Save to act as "save & close" or "save & continue editing". Depending on the results of that inquiry, you may need to either change the labels on the buttons or even add another one to make it equivalent to Apply | OK | Cancel.

  • Excellent points. Would this three button group eliminate the need for the [X] in your view? – gstern1994 Feb 17 '12 at 19:35
  • 1
    based on my experience, users rarely use the button apply changes when it behaves the way to "save & continue editing" – Alex Feb 17 '12 at 19:44
  • 1
    Not necessarily. [X] is a part of the modal dialog's header so there's empty space (top-right corner) where it can reside without disturbing anyone. In Windows, the design patter is to include [X] in every modal dialog. In OS X, it's inconsistent because some modals slide out of the title bar. – dnbrv Feb 17 '12 at 19:48

Cancel and X should do the same thing. There's no point in not closing the dialog when the user presses cancel.

There's a real Windows/Apple thing going on here. Windows typically puts cancel on the right, Apple puts it on the left. Personally, I tend to put the positive action on the right (like moving from one page of results to the next) and the negative action on the left. The 2 buttons are in my view too close together - you need to separate them out, and ideally, if the user has entered anything in this dialog, ask for confirmation, otherwise you run the risk of frustrating the user. And in answer to your main question, you should absolutely have both a cancel and an "x" - many users will not even look to close the window.

  • 1
    IMHO, proximity isn't a huge issue, but the lack of differentiation is. The buttons are visually identical. I'd suggest trying to figure out how to visually differentiate them better. – DA01 Feb 17 '12 at 22:26
  • Agreed - making the "Save" button the main call to action (maybe through size and colour) would help to resolve this). – Peter Feb 18 '12 at 8:11
  • The Visual Weight of Primary and Secondary Action Buttons – denis.efremov Feb 21 '12 at 12:44

I'll add my vote for removing the [X] entirely if you can. It should behave like a Cancel, i.e. discarding changes and closing the dialog, but it leaves users to wonder whether it really is the same thing, and if so, why there are two controls that function identically but look different.

The behavior of a button labeled Save is in some ways a more difficult question. In both Windows and Mac OS, we've gotten used to the term "Save" as meaning "save and continue working," and even though we don't see it that often anymore (we're usually hitting Command-S or Ctrl-S), I think that meaning lingers enough to create doubt when we see it as a command button's label.

My rule in a situation like this would be that the button should close the dialog; unless there's a need to preview the changes made in some other window, or what you're doing in the dialog is so lengthy a task that there's real danger in not being able to save it as you go along (in which case you might consider Preview and auto-save, respectively), there's no reason to keep it open.

So I would opt for a label that has come, for better or worse, to stand for "accept and move on": "OK". The OK/Cancel pairing is everywhere, and even though it might feel weird to end a form dialog with "OK," it's the kind of weird that happens when you stare at a word so long it turns into nonsense. Most users won't have to think about what it means, and that's just what you want.

(If for some reason you need a Save that really does mean "save and continue," you want either Save and Close or Apply and Close. "Save and Continue" doesn't pair with "Cancel" because we understand "Cancel" to discard all the changes we made, and it's not clear whether that's all the changes made since we opened the dialog or all the changes made since we last saved.)

  • I like your rationale for this. I need to come up with a consistent pattern to deal with it, we do it differently all over our app. We have an [X] built into a modal, it can't be removed, as it's part of the chrome, so would a Cancel/Close button be useful or redundant or both? Would something like this seem reasonable: Save/Close buttons that give a confirmation message that something was successively saved, and the cancel would just close the modal post haste unless there was unsaved data - this would trigger a message about unsaved data and a choice of saving or canceling the action. – gstern1994 Feb 27 '12 at 21:21

Case-1: Your "x" close is not relatively at its best position, where it can cause some Perceptual problems, since x aligns with the Title,and what if this in first place needs to get at its usual position above the header blue band, as with aligned along border line of the window. So if we had to move this What next?

Case-2: Let me tell you that Save & Cancel are good to be paired, since when the user approaches the screen, and finds not going to edit any item, its better-off he may choose to Close by using "x" (atleast most preferably 90% would do this fashion) and atleast 10% of people would use "Cancel" - saying "OK, I am not going to edit anything here, let me cancel this action" (This is what my experience helps me to bring the stats here)

Case-3: So Why do we need then the "x", coz it represents same action as in case 2? User will be not be worried to close the modal window with the button "Cancel", and will really not look at the missing piece, since the affordance to Close or Cancel is already provided inside the window. So the 10% would naturally turn 100% since they have the option to chose to close only through "Cancel"

Building on the Case 3, the best way to look at this is, user will edit some item and "Save" or user will edit some item and choose not to save and use "Cancel" or user will look at the screen and perform no action, and would still click "Save" (Here you can chose to Grey off the SAVE button, and making the user to perform the action only if there is some edit on the screen) or perform no action and would say "OK, let me close this" which is otherwise "Cancel". So the inference after the long build-up pointers, is that you may chose not to have "x" and go with pairing of buttons alone. Think about grey-off the SAVE button and make user to chose only if there is an edit linked with it.

There are some great thoughts in this thread so I won't offer my own preferences because I can see reasons for any of the choices you could take. I've also struggled with this same question, it's difficult.

The approach that might be helpful is using evidence to give you your answer. I would test:

  • Current layout - see if users use both options if both are available
  • Only the X - see if users understand what they are doing and if they can find it

  • Only the cancel button - see if users understand what they are doing (this would have to be a cancel + exit interaction or perhaps click cancel then whitespace to exit)

You might find surprising answers depending on the patterns your users are comfortable with.

This would be a relatively simple thing to test with prototyping I think. It's just a matter of changing one screen within your scenarios. I would formulate the tasks so that they don't include the word cancel or exit, and just so happen to require the user to do that action, if that makes sense.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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