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?

6 Answers 6


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:

  • ok + changes => save
  • ok + no changes => close
  • cancel + changes => close
  • cancel + no changes => close
  • close + changes => prompt
  • close + no changes => close

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...


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".

  • I think that it's a good idea that you remove the close button and leave cancel enabled all the time. If the user can choose between "cancel" and "close" - there's a high probability of confusion. Oct 14, 2011 at 6:52
  • @HenrikEkblom. Yes, I (now :-) agree. But my point was not to disable anything. Added a link to Joel's view on disabling/hiding menu items. I feel it applies to buttons as well. Oct 14, 2011 at 7:13
  • +1 for a really useful answer. How would you do this differently on a mobile application where you have a back navigation button (not called back of course).
    – JohnGB
    Oct 14, 2011 at 10:12
  • @JohnGB: Thanks. And good question, have edited my answer with my thoughts. Oct 14, 2011 at 16:38

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:

enter image description here

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:

enter image description here

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.

  • 3
    This is the key! A purely disabled button feels broken. This will only frustrated users. But a button that explains why its disabled is a great form of inline validation, and is certainly a viable option.
    – DA01
    Oct 14, 2011 at 13:55
  • 2
    I love that Google's started doing this, and was very excited when I first saw it. Very very rarely do I ever see an explanation why an item is disabled, especially not when it's a normal menu item.
    – Ben Brocka
    Oct 14, 2011 at 14:07
  • 1
    it should be noted that autosaving could potentially be a security issue. If I were to create a google doc, and I pasted in some text containing secure information that I was going to remove (example, paste in db code containing username pass, delete username pass) the older version would still be saved. Users should always have the ability to disable auto-saving, in which case, the button should be re-enabled.
    – zzzzBov
    Oct 14, 2011 at 15:30
  • 2
    I wasn't entirely suggesting autosave (though I love it), I was more suggesting that if your save button is disabled because of no changes to save (whether it's because the doc auto-saved or because you just didn't touch it) it should be shown why the button is disabled.
    – Ben Brocka
    Oct 14, 2011 at 15:50
  • 2
    The Save button isn't a placebo. It is available and functional between auto-saves. And that is very useful! Try and close your browser when you have un-auto-saved changes... When my browser alerts me that I have unsaved changes, I really don't want to have to wait for the next auto-save... Oct 14, 2011 at 16:46

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.

  • I also tend to distrust applications like that. I don't care if there are no changes. let me save! :p
    – Svish
    Oct 14, 2011 at 12:57

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".

  • I think it's a good idea to disable a button that does nothing. although - If it should be called "save" or something else is imposible for us to know - we don't know anything about the software! Oct 14, 2011 at 6:55
  • 2
    Well, the button does do something .. it is an exit point from the edit view, returning them to the list view.
    – Erics
    Oct 14, 2011 at 7:20

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.

  • 4
    "It's intuitive and clear" -- I'd contest that assumption. Having two buttons that, for most people, appear to do the exact same thing isn't all that clear. I've see folks habitually hit APPLY and then OK 'just to be sure'.
    – DA01
    Oct 14, 2011 at 13:56

Your Answer

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

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