Save/Cancel/Close button behavior question

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

Cancel vs Close: Design to Distinguish the Difference

Long ago, the symbol X meant “this is where the treasure is buried.” In today’s digital interfaces, X no longer marks the spot, but rather functions as a way for users to cancel a process or to dismiss an interim screen. How can one tell for sure whether the X means cancel or close? Sometimes, unfortunately, you can’t.

The main issue lies with the common lack of a text label for the X icon. When an icon represents multiple meanings in similar contexts across different interfaces, icon usability suffers because users cannot rely on any single interpretation.

Avoid Losing Users’ Work To avoid losing users’ work, systems need to determine the user’s intent — cancel or close — and provide clear options.

This goal can be accomplished by one or more of the following:

1. Asking the user to confirm their intention
2. Using explicit text labels rather than ambiguous icons
3. Presenting two distinct buttons:X for closing the view (with the side effect of saving intermediate work) and Cancel for abandoning the process

1. Ask for Confirmation

2. Use Explicit Labels

3. Favor Close & Save

Note that saving intermediate work or maintaining an ongoing process before closing is proactive, but sometimes can be contrary to the user’s intention: If users intend to cancel their selections by clicking the X button, auto applying those selections could be confusing and frustrating. This is why it’s critical to also include a separate Cancel button, to give users an out rather than forcing them to only save and close the view.

Conclusion

While the X icon is ambiguous and can often cause usability problems, it’s unlikely that it will disappear from all interfaces any time soon. Designers should be aware of the multiple meanings of the X icon and disambiguate between close and cancel, as well as provide safeguards such as confirmation dialogs or autosaving to avoid losing any users’ work.

Remember, when in doubt, save, then out.

Refer : NN Group: Cancel vs Close: Design to Distinguish the Difference