Settings Page - Save and Cancel buttons

Question

please see an attached wireframe which roughly explains my question.

I am working on a settings page - see 'My Settings' selected in the secondary nav nested under another heading.

On this page, the user can change their photos and also some other settings. I was planning on having the 'Save' button disabled when the user lands on the page and then enabling it once the user has either changed a photo or one of the other settings - The 'Save' button will then become disabled again once the user clicks on it. The 'Save' button will keep the user on this page, the only way the user has of leaving this page is by clicking back in the browser or one of the primary / secondary headings at the top of the page.

I am a little unsure what the 'Cancel' button should do, or if it is even necessary but I am working with it there at the moment based on what was previously there before I started working on this - What would you expect the behaviour of the 'Cancel' button to be if you were a user on the page shown? (Both before and after any settings have been changed).

If you don't think the 'Cancel' button should be there, it would be great to hear your thoughts.

Answer 1

I believe the use of a Cancel button should bring the user away from the page and remove any changes made.

A cancel button is a useful "exit" from a settings page.

Without it the only way a user has to go away and not keep any changes in the settings is clicking on a page link. The user is not interested in the link he is clicking, but rather using it as a Cancel button.

Where should it redirect the user?

Probably to a main page, if this settings page is in a Dashboard or profile page, then those are probably is a good redirect page. Otherwise maybe the Home page.

Answer 2

Generally, "Cancel" is defined as:

to decide or announce that a planned event will not take place; call off:

Therefore, the [Action]|Cancel combination is appropriate for a distinctive process. A common example is the Ok|Cancel for confirmation boxes. The user has started a process and the Cancel button gives her a way to discontinue the process she's started and preserve the former state.

How the user arrives at a screen frames the expected scope and actions she can perform while on that screen. In the case of the above dialog the user is presented with this "screen" after she clicks an Approve button. So the path is:

Approve  >  Read confirm message  >  Respond with: Cancel|Ok

~~~

In your case, compare "My Settings" and "Change photo":

What do you expect to see and be able to do if you click "My Settings". What fields and buttons come to mind? How about "Change photo"?

Narrow that down a bit. If you click "My Settings", is Cancel an appropriate response? If you click "Change photo", is Cancel an appropriate response?

~~~

So, of course, the context determines the users' expectations.

Another thing to consider is Cancel vs Undo. Both return to the previous state. The difference is Cancel is for discontinuing an ongoing process and Undo is for reverting a completed process.

~~~

Back to the scenario you described: the user is presented with the "My Settings" page with the Save button is disabled. The user makes a change and the button enables. She clicks Save, remains on the page and the Save button is disabled.

Which is an appropriate counter-response: Cancel or Undo?

.

Ideally, in my opinion, when the user clicks "My Settings" she's presented with all the settings fields and the buttons Save and Undo. When clicking either button the user remains on the settings page. To navigate away from this page she uses the navbar.

However when the user clicks "Change photo" she's presented with only the change photo fields and Change photo and Cancel, possibly in a modal context. When clicking either button the user is returned to the page where she clicked "Change photo".

Answer 3

I think your approach with the save button and behavior is fine. However, when it comes to cancelling or resetting all the values or updates on a profile form such as this, scrolling down all the way to the bottom to either exit the page or to reset the values to it's original state, could be seen as an ineffective way for the user to do this.

My suggestion would be to break up the bits of information in chunks. Have one thing saved after it's completion. For instance, the mental model for most users updating a profile pic, is to upload and have it saved, then go on to the next piece of information and complete the little bits of information as apposed to completing everything and then saving everything.

Not only will this address your question for the cancel but it will also limit your chances of errors. Having the user complete everything but you get a server error and they have to complete EVERYTHING again. Guide them to have quick wins and limit the recapturing of data, should there be a problem.

Hope that is helpful