Usability: Save changes using "Apply" button or after every single change?

I am interested in hearing opinions and experiences of fellow developers on topic of designing user interface, usability AND maintainability-wise.

Common approach is to allow users to tweak options and after form gets "dirty", enable "Apply" button, and user has possibility to back out by pressing cancel. This is most commo开发者_开发知识库n approach on Windows platform (I believe MS usability guidelines say to do so as well).

Another way is to apply changes after every single change has been made to options. Example, user checks some checkbox, and change is applied. User changes value of some text box, and change is applied after box looses focus, etc. You get the point. This approach is most common on Mac OSX.

Regardless of my personal opinion (which is that Apple is better at usability, but software I usually write targets Windows users), what do you people think?

Edit: I am fully aware that this is not a real question, but rather asks for a discussion, and that it's place might not be on SO, whose policy is to have answers and questions only. But I believe it could be useful discussion, mostly because I was unable to find anything like it before asking.

Both have their places, and they're both used across many platforms (they are not really a differentiator between PCs and Macs).

The "Apply" button approach allows you to make some changes, apply them, and not have to re-open the dialog to make some more changes. This is useful for trying things out, but when you wish the user to think methodically (or feel secure) about their choices - the user is in control of precisely when their changes are applied. This is important in some cases where you may not wish to commit your changes until you have made several of them, or in cases where the user should know what setting they want, rather than needing to "experiment". These dialogs usually also have a cancel button which (hopefully) undoes any changes made since the dialog opened. THese dialogs are often modal so the user is locked into the dialog until they have made their choices.

The instant-effect dialog allows the user to experiment and see "live" updates based on their choices. This is great when the user wants to experiment with options to see what effect they will have. You have to be careful with the visual style to make it clear to the user that they are operating "live", and they must be careful because they can't back out their changes. The Microsoft approach for this type of dialog is to have a single "Close" button, which makes the instant-effect approach obvious. These dialogs often aren't modal, i.e. they are treated as "live editing panels" rather than dialogs.

Generally, UI is leaning towards the live editing side of the fence, as it allows users to be experimental and unhampered by technicalities like having to press a special button to commit changes (see the control panels in Win7 for example - hardly any modal dialogs compared to XP)

However, ultimately the choice between these two options is really down to what type of settings you wish to control. i.e. If you're setting font styles on some text, then you really want to be at the live, experimental end of the spectrum, but if you are configuring important and related groups of information (e.g. your DNS server's address and your subnet mask) you may want to use something that requires you to think/know and deliberately Apply your change (So users can enter and double-check the information, and so they can change several related pieces of information "simultaneously". Also, if you commit a DNS server address live as the user types it, they will lose their net connection until they get all the digits right - live just doesn't make sense for this).

Match platform expectations.

I too agree that Apple is superior in terms of usability, but your decisions should be based on the most common behaviour that your target platform exhibits. You should always do whatever surprises users the least, and for most Windows users I'm guessing that's to stick to the OK/Apply/Cancel behaviour.

If you have cross-platform applications, do separate GUIs that respect the match platform expectations mantra. Yes, it's extra work, but it shows that you care.

I agree that in general you need to match platform expectations.

Personally, however, I generally prefer the use of apply/save for two reasons: 1) A partially applied change can be disruptive (in delay or in actual screen artifacts) 2) Certain states or combinations may not be valid (or they might not be valid in the perception of the user). 3) If you provide some way of unrolling changes or of saving changes with meaningful names, then it makes sense to group them logically based on when the user chose to hit apply or save. As a developer I like a commit/rollback approach to things, and I like that in my UIs as well.

I can only think of two good reasons for having an apply button:

1. The changes can't be applied instantly but will lock the GUI for a noticable amount of time.
2. The changes only makes sence together (like a transaction).

None of those are very common. Historacally 1 used to be true for almost any option. But nowadays computers are faster and 1 is seldom relevant. If the effect of the changed can be seen instantly, why would anyone not want that? So the gui (but often not the code) can be simplified by skipping the apply step. I don't think it's very common that a user really needs the cancel button either, partly because it's kind of ambiguous. What should I expect if I make one change, apply, make some other change and press cancel? Will the first change be reverted (in most applications the answer is no because that's easier to implement)?

If yes, that is the point of having the apply button then everything is deceded then pressing OK/cancel anyway? Or do we need to consider yet another option, that the window is closed, in which case the first change is kept but the second reverted?

If no, then apply basically sets a bookmark which will be reverted to is cancel is pressed. But is this kind of complex behaviour really needed in any real life use case?

Is it sane to keep this kind of complexity of historical reasons because users (are believed to) expect it? I have seen users always press apply, then OK. Why? Perhaps just because the GUI is too complex. Or becuase the are not sure if "apply" means "apply and dismiss dialog" (which it does in some applications) and that OK might not apply the changes (I have seen buggy applications where OK just closes the window without applying and maybe they have too). At least I don't think users in general are awere of the exact logics of these complex choises, hence they do not need it and it doesn't need to be there. People tend to mainly distinguish between "positive" (yes, ok, go forward, apply) and "negative" (no, cancel, abort, go back) actions is dialogs, having more than one of either requires more attension from the user. Interestingly, exchanging one positiva action with another doesn't seem to affect the users perception much. If a dialog with buttons yes/no is changed to ok/cancel, many users won't even notice.

That about usability (which is far more important IMHO). Maintainability-wise instant apply can be very messy if done wrong, but also very clean and maintainable then done right. If the application is written with an apply-all-at-once approach there is generally one function. Calling such a function for every little change is of course not very efficient. What I have seen this is often solved by splitting the function to several different functions for applying different stuff, ideally one dedicated function for every kind of change that can be made. This is will make the application much more responsive, but is horrible to maintain. So don't go there. A neat solution is to use MVC (Model-View-Controller) and create a model for each configuration item and bind them to the fields in the configuration form as well as to the relevant parts of the application (and to the configuration storage back-end so every change gets saved automatically). If no MVC is available in the environment in question, it is definitely worth writing one.

+1 for Saving changes after entire form is filled rather than every field.

But should have validations whenever a field looses focus so you can give immediate feedback if anything is wrong.