We have a list of complicated things, which the user can click on to get a new view in which they can edit all the details stored for that thing.
The edit view already has a Cancel exit mechanism (default for all our edit forms) and it has a save button (which both saves and exits back to the list).
Should the Save button be disabled until changes are made to any of the details?
In an app I created some 10 years ago, disabling is the approach I took. Each form has a Save, Cancel and Close button. Save and Cancel are both disabled until changes have been made. Close is always available and will prompt to save or cancel when changes were made.
At the time I thought it was the right way to do things. Now, every time I open an edit form and want it to go away, it irks me that I have to use close and can't just use ok or cancel.
I think the form should figure out what to do:
The close button will be removed in the near future, but the functionality and behaviour remain as on a desktop you will always have the "X" button by which you can close a form. The inclusion of a separate close button was really to provide a bigger target...
Edit
Just for good measure, here is Joel's view on disabling/hiding menu items (which is "DON'T") http://www.joelonsoftware.com/items/2008/07/01.html
I have come to the conclusion that it applies to buttons as well.
In response to JohnGB's comment
The back button in a browser never submits a form, it always has the implicit meaning of a cancel. Any app, whether on a desktop, in a browser or on a mobile, that supports "back" navigation should really stick to that unwritten standard. And it doesn't even matter whether you follow an explicit save or an auto-save paradigm. It just means that using an explicit save paradigm you will have to provide a "save" button and in an auto-save paradigm "back" is just that "back".
The save button has become the Skinner Box button for a great deal of people thanks to terrible, terrible software that never autosaved people's work for a good 20 years of popular software. I don't like to keep training people to hit that button, but there's nothing more aggravating than finding your app didn't just save what you did.
I found Google Doc's placebo Save button an interesting solution; the save button was there, but the document autosaved. For a while you could click the useless button called "save," but now they've replaced it with a notification:
After it saves it lets you know, and on hover if you try to click the "button" it explains why you can't use it:
If you're dead set on disabling the button letting the users know why the button is disabled like that is important. As much as I hate to suggest it, the simpler solution for user and application, especially for older or less technical users is to just leave the save button there and let them click like mad. They might waste 5 seconds clicking it every 5 minutes, but they'll have peace of mind, and that's very hard to foster in an application.
You're assuming users never save changes to data they haven't changed. They do - all the time. Partly as an unconscious reflex, partly because they can't always remember what they've edited, and partly because they fear the risk of losing their work so much, they save religiously.
I exit forms via the save function all the time. It's a hard-learned habit, and a form that didn't support that workflow would seem jarring. It'd also make me distrust the application (what if the form simply hasn't detected my changes? what if the save button is missing because the application is broken?).
I wouldn't like it. But I'm not your user. Try some A/B testing some time and find out for yourself.
Definitely. An enabled button that does nothing helps no one.
Although in this particular case it sound like the label should be "apply" or "Ok".
If your detail forms are relatively simple, I would suggest just using OK/Cancel buttons that users are so familiar with (with both buttons staying active all the time). Users understand that if they click OK, any changes will be saved and the dialogue will close. If they click Cancel, changes will be discarded and the dialogue will close.
If your detail forms display a significant amount of data (where the user would be afraid to loose data if they don't save often enough); only then would I go for using Save/Undo/Cancel buttons with the Save and Undo buttons becoming active if there are unsaved changes. And like Marjan mentioned, prompt the user if they click Cancel and there are unsaved changes.
I kindof like Microsoft's approach to use the OK-Cancel-Apply combination on their input forms. The Apply button is disabled as long as nothing has changed, and the OK button will automatically Apply the changes if there are changes.
It's intuitive and clear what each button does and it's familiar to a lot of people.
