Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

In our web application we have a number of pages to do with user settings, in different categories. For most of them we have a display page with an edit button/link, which takes them to a form which has a cancel/save exit path.

However, for one category of settings we do something different. For the alerts & notifications settings we show all the alerts they can have, and present the controls to turn them on/off individually right there, as well as change their respective options (eg. email address to use as destination). There is no save button/link, the changes take effect immediately. We did this because the typical scenario is the user will want to tweak just the one alert setting, rather than review and edit the lot as a batch. We also recognised that a "save" button would likely be below the window-fold and thus be missed, and we really didn't want to put a save button against each set of alert settings.

We're a bit worried the user might be puzzled by the lack of a save button.

What are some guidelines and arguments for and against some setting chenages having an immediate effect?

share|improve this question
    
See also my answer here. For general insight Google does a pretty good job of autosave controls and deciding what to save automatically. ux.stackexchange.com/questions/12741/… –  Ben Brocka Oct 14 '11 at 14:10
add comment

3 Answers 3

up vote 8 down vote accepted

You need to be consistent. Changing what people expect from your application confusing and not a good idea.

If you are saving automatically in one section, why not do it in all of them? If there is a good reason to have the save button(s), then why not have them on all the settings pages?

Many applications break up settings pages to logical groupings and then have a save button for each group. I haven't found it visually ugly, and it is clear what to do. Definitely a better option than only at the end of a long list.

share|improve this answer
3  
One addition I would make to that: if you're going to have groups with a save button for each, make sure either each save button saves everything, or saving one group does so without resetting other groups to the default! I've lost a load of config changes in the past due to people implementing this wrong, so I'm keen to spread the good word :) –  John Yeates Oct 4 '11 at 8:25
    
@JohnGB same here. We're confounding things further by having the different categories of settings actually being inside different panes of an accordion page. The devs might however implement this as distinct separate pages with an accordion style appearance, rather than have one monster sized page of html. –  Erics Oct 4 '11 at 8:33
    
@JohnYeates: Good point. –  JohnGB Oct 4 '11 at 8:38
    
Your answer would have been more balanced if you talked about the plus points of both auto-saving and not auto-saving. Each has its merits and its uses. –  Kris Sep 22 '12 at 6:35
add comment

Consistency is definitely a must. However, if one group of settings warrant a toggle on/off action rather than actually typing into a set of fields, it may be ok to have these save automatically on each change.

If you are using a toggle style switch it is expected that once you flick it, the action has been saved... Think about turning on or off a light. You could symbolize that it is being save by a short animation or notification after it has been toggled.

You also need to think about what type of users you have. Do they expect things to be saved automatically or do they need the psychological closure of completing the actions by clicking a save button.

It is becoming more of a common practice to use autosave within applications. Google uses autosave for most of their apps but they also use a 'save button' where needed. You could argue that 'web savvy' users would be more used to autosave but 'less web savvy' users may still expect or want to click a button to feel secure that their efforts have been saved.

share|improve this answer
add comment

In ancient times, documents would have two states: the "saved" state on disk, and the state being edited. I would suggest that's often a good model, even for on-line applications. To avoid having people lose their work if their connection goes down, it may be good to have the server keep an up-to-date copy of the state being edited, but the "saved" state should generally only be updated if someone affirmatively requests that.

When closing a window after some state has been modified, a user should be allowed to abandon changes, apply changes, or keep as draft. If the user opts for the latter, or if the connection is lost, the next time an attempt is made to edit the state the user should be explicitly formed that the system is retrieving a saved draft.

I dislike having some kinds of changes to a form auto-applied and others not; if certain changes must be auto-applied, I would suggest that rather than using [e.g. a checkbox or radio button, one have a "submit"-style buttons for "Turn XXX on" or "Set mode to YYY".

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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