2

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:

mockup

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

3 Answers 3

5

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.

An Image showing various options to denote primary and secondary button actions

4
  • Great suggestions. However, in some other parts of the application, a cancel link is used. This is for cases where there is a logical previous or parent page to send the user back to. In those pages, the link is styled as my mockup and has the text cancel. Will having a different style for Discard cause problems due to the inconsistency?
    – F21
    Aug 21, 2012 at 23:05
  • Given that cancel and discard differ in outcome, I don't see why the styling shouldn't different. More so as there's a different styling to the save button anyway - so I would actually say that a styled save next to a discard link is less consistent than having both styled.
    – Izhaki
    Aug 21, 2012 at 23:12
  • As a side note, I wouldn't use links for actions like cancel simply because it is an action and not really a link. You are thinking in 'programmer terms' here, where your cancel could well be a <a> link to the origin page. But cancel and view 1 are not the same in the view of the user (although both might be links to a page); save and cancel are related in user minds.
    – Izhaki
    Aug 21, 2012 at 23:19
  • Also, and I'm being picky here, just notice that the underline for links is considered ugly by many designers. Just look on the links on this page (they do get an underline when you hover over - other then the top tabs, but personally I think the pointer cursor is sufficient)
    – Izhaki
    Aug 21, 2012 at 23:21
0

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?

3
  • My appologies. I have updated my mockup. Essentially the view is instantiated by a menu on the left hand side. The view can also be accessed directly via the URL. There is no parent view for these views and these views are not of the edit the item type. They are pages such as a form for editing system configuration, etc.
    – F21
    Aug 21, 2012 at 9:46
  • @F21 Ok, so the user won't be able to see the data without it being in an edit context, like with a text editor? Aug 21, 2012 at 10:32
  • Yes, that's correct :) and there is no logical "parent" or "previous" page to go back to.
    – F21
    Aug 21, 2012 at 23:03
0
  • 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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