save/cancel dialog from pressing cancel

Question

^{download bmml source – Wireframes created with Balsamiq Mockups}

I'm making a Windows desktop application. It's "too hard" to build in an Undo action.

I have a task that opens in a modal window, it's a task that may take the user a while to do, so I want to prompt them to save changes if they hit cancel by accident.

If they press cancel, the confirm dialog will say something like "Changes have been made, are you sure you want to discard these changes?"

My question is what buttons should there be (on the original task window and the confirm)? Save/Cancel? The user clicked the cancel button, then sees the confirm dialog, so they may press cancel again because that's what they want to do, but that would cancel the confirm dialog, not the original task. Also, would I prompt to save from the cancel?

[ Cancel ] > [ Don't Save ][ Save ][ Cancel ]

That doesn't seem right, because to continue with their original decision to cancel, they'll have to [ Cancel ] > [ Don't Save ].

Answer 1

Use more specific language in your CTAs

Perhaps you've got a style guide that might prohibit this, but part of the existing problem is that the microcopy is typically generic.

1. Leave the buttons in the task modal as [Save] and [Cancel].

2. Restrict so that it's only possible to save from the task modal.

3. Use more natural language instructions in the Confirm Dialog

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 2

There's a few other things you can do to help here.

1. Don't put your cancel and save buttons together, that way a user is less likely to get to the dialog without meaning to. I'd put cancel over to the left out of the way, or even remove and allow the dialog close button to take that role.

2. Autosave in the background, resulting in a 'draft' status record that they can come back to later. If you can save a completed task, then you can save a partially completed task.

3. Or, similar to 2, give them a 'save progress so far' button, leaving them the option to come back later.

4. You could choose a different paradigm altogether for cancel and discard, one that doesn't involve dialogs, perhaps more like an iPhone delete process or some other thing that makes the user have to think a little bit more than just clicking buttons.

Personally, I think in 2016, the progressive save, manual and automatic, should be the default position of any interface build that captures info more complicated than a few words. Users should not lose work these days. With this sort of thing it's less important to try and catch all mistakes with dialog buttons.

It may be that Windows paradigms are expected but just because that's how things have always been doesn't mean that's how to do them - building things in the best way to help your users complete a task regardless of expected paradigm is the best way to do things.

It seems the goal of question is to stop the user from losing work and that isn't going to be optimally achieved whatever combination or words and buttons you choose. People will struggle with button position, automatic responses to pop-ups and confusion over wording so it's better to try to catch them from ever falling into this trap.

Answer 3

If you are going to ask your user a question, you should ensure the call to actions answer that question, e.g. Treat this like a conversation:

"Are you sure you want to discard changes?"

• Yes, I want to discard changes
• No, I made a mistake and want to continue working

This can be simplified to:

• Yes
• No

Clicking Yes triggers the Discard feature and closes the Confirm dialog.

Clicking No cancels the Discard feature and returns you to the form to continue working.

Answer 4

Simplify the modal wording:

"Discard the changes you made?"

Make the buttons simpler as well "Yes, Discard" and "Cancel".