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.

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?

share|improve this question
add comment

7 Answers

up vote 9 down vote accepted

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

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

share|improve this answer
    
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. –  Henrik Ekblom Oct 14 '11 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. –  Marjan Venema Oct 14 '11 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 '11 at 10:12
    
@JohnGB: Thanks. And good question, have edited my answer with my thoughts. –  Marjan Venema Oct 14 '11 at 16:38
add comment

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.

share|improve this answer
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 '11 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 '11 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 '11 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 '11 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... –  Marjan Venema Oct 14 '11 at 16:46
show 9 more comments

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.

share|improve this answer
    
I also tend to distrust applications like that. I don't care if there are no changes. let me save! :p –  Svish Oct 14 '11 at 12:57
add comment

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

share|improve this answer
    
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! –  Henrik Ekblom Oct 14 '11 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 '11 at 7:20
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
2  
"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 '11 at 13:56
add comment

I want to disable the Save button until the user makes a change. Two reasons:

  1. It's redundant to have two buttons side-by-side that perform identical actions. A user might logically assume these buttons with different labels must do different things. (The little X button that closes the window and the Close button are also technically redundant, but I've been conditioned to them.)
  2. The state of the Save button cues the user about whether a change was made. After browsing one of these "complicated things" in the dialog I might wonder Did I make a change or not?

Our UX team is debating almost the same problem in our own application right now. We have a modal dialog with OK and Cancel buttons that edits a complicated selection set. We can't agree either....

Modal dialog with OK and Cancel buttons

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.