Discard Changes/Cancel behaviour in a web app

Question

I have a web app that allows multi-tasking. If the user is on a page and has made changes, on navigating to a different page, the previous page is added to a list of tasks, which he can then revisit and continue making changes and saving.

Therefore, in cases where the user has made some changes and does not want them anymore, he would need to utilize the "Discard changes" function to get rid of the changes he has made.

In my case, these are the characteristics of such pages:

• Clicking the Discard changes button merely resets the page to its initial state it behaves like Reset button in forms form older websites.
• Clicking the Discard changes button does not navigate the user to a different page at all. There is no logical page we can navigate the user to.
• Clicking discard changes displays a modal to confirm that the user is about to throw away all of his changes.
• I am essentially following Luke Wroblewski's guidelines for the actions:

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

Concerns:

• When clicking discard changes on a page where which has not been modified, it does nothing. Should I hide the Discard changes action and only show it when the page's interaction elements has been modified? If not, we can disable the link, but what are ways to communicate that the link will not work until they have modified the page?

• The discard changes is styled as a link as per Luke Wroblewski's article. Is this going to confuse users who might expect to be navigated to a different page (keeping in mind that a modal is displayed when they click it)?

Answer 1

To answer your questions directly:

• Users expect something to happen if allowed an action, or they may conclude that the system malfunctions ("I press this button, but nothing happens"). If an action results in no change, either its trigger should be disabled, or a message should show, something along the lines of 'nothing to discard' (probably fade div below the button).

• I highly advise against showing a link style for something that isn't a link - it is very, very confusing from a user point of view. Visual distinction can be achieved in different ways. While none of this is presented in Luke's article, you may want to consider:

  • Icon on the primary action button. Icons tend to draw the eye.
  • Bolder text colour on the primary button. Two different button colours (green/gray; green/blue) can be confusing for users - if it's an action the button colours are better be consistant. Text colour isn't that confusing yet is effective. You can also just have the primary button text in bold.
  • Larger button length for the primary button.

Answer 2

I'm guessing from your mockup and its phrasing that the user at some point must have selected an item from somewhere and made an active choice to "Edit the item". Is that how this view is initiated?

If so, the conventional way to handle the flow when a user clicks save or confirms a discard would be to link them back to the initial view where they initiated the edit.

If this context sounds similar to how this part of your application is laid out then I would change "Discard changes" to "Cancel", that way the application is not implying that the user has made any changes and hence there is no confusion if the control is ubiquitously enabled.

This approach will also solve issues with whether it's confusing to the user to have a link that doesn't really link anywhere.

You say that there is no logical page to link the user back to when cancelling, but I can't see how that can be. Linking the user back to where the edit was initiated must be possible. No?

Answer 3

• If the control resets the values without navigating, then perhaps Reset is the best label. Generally Reset is understood to not navigate.

• Even so, I’d use a button rather than a link for Reset/Discard. Find some way to emphasize the button less, such as the suggestions by Izhaki.

• The Reset/Discard control should be disabled if there’s nothing to reset. Unlike hiding, disabling tells the user the action can be made available. This may encourage users to edit when otherwise they wouldn’t because they’re afraid of irrevocably messing things up. The ability to disable is another reason to use a button appearance rather than a link since there is no standard “disabled link” look. For more on disabling versus hiding, see Controlling Your Controls.

• After the user performs a reset/discard, consider changing the control to recover the changes the user just discarded (i.e., undo the discard). This will eliminate the need for the confirmation message. User may also find it useful for dynamically comparing old and new settings. If you save previous settings between sessions, you won’t need to disable the Reset button (you may want to include the timestamp for the values it resets to).

• Consider an Undo/Redo functionality rather than Reset, so users can back out a selected sequence of edits. That users don’t navigate away with Discard implies you expect users to make extensive and protracted edits to the page (e.g., after discarding, they continue editing rather than just give up and go away). Undo is preferred when it’s likely that users want to revert the last three changes, but not the previous 12 changes.

• Make sure your graphic design correctly communicates the scope of Save and Reset. From your wireframe, I can’t tell if Save saves just the visible fields or also changes to the other views. Put Save/Reset in the box of fields if it’s limited to just those fields; otherwise, maybe put it under the links to the left.

• What happens if the user navigates away from this page without saving or discarding? Do you put up a message forcing the user to choose between saving or discarding first? What if the user needs to check something on another page in order to decide whether to save or discard first? If this app involves extensive editing like you imply, you may want to go with a desktop-style multiple window UI, rather than web-style multiple page UI. See Turn the Page. Another option is to automatically save each field change. Now you don’t need a Save button, and Undo/Reset is more like a rollback function.