3

I have a desktop application, and in this application, there is a non-modal dialog where a user can make changes to something. The dialog has a Close button and a Save button. The Save button does not close the dialog, because we expect users to be making these changes, check the result, and then possibly making more changes.

The state of the dialog will always be valid, there are no required fields or anything like that.

We have come up with two options for the save button:

  1. Leave the Save button enabled at all times. When a user clicks it, it will briefly display a checkmark or perhaps a short success message for a couple of seconds.
  2. Disable the Save button until a change has been made, then enable it. When clicked, it will go back to being disabled.

I can see pros and cons to each approach. Is there any accepted standard or a reason why one approach is better?

Improve this question
1

5 Answers 5

Reset to default
1

IMHO, choice 1 is bad. I work in IDE which does not reinstall the executable on remote server if it knows it's already there. If that file is deleted, any attempt to run/debug the executable fails even right after explicit "installing". Please don't do this.

Edit: I mean that if your saved data is somehow deleted or changed outside your program. If I don't know about it happening, it's lost.

Choice 2 is probably ok, and also allows to check if changes were made.

I suggest implementing an autosave feature which saves after some time after the last change. I'd like to see progress of this represented by small icon or busy spinner or a simple indicator of success somewhere in the corner. An example is here on StackExchange:

"draft saved" - stack exchange

If you want, you can make said icon clickable for explicit save action, but then it should save indefinitely.

Edit: If autosave is undesirable, probably choice 2 is for you. You can leave the button clickable when no changes were made, but it should show the status, and it should actually save data. If you don't want me to save what's already saved (or so you think), disable the button altogether. If the button says "Save" but does not, what sort of button it is?

Improve this answer
3
  • Could you explain what you mean in your first paragraph? I'm not sure how your IDE example relates to this. Also, unfortunately autosave is not a good option for us for a variety of reasons, one of which is that there is no option to "undo".
    – Robin
    Sep 6, 2019 at 14:25
  • @Robin answer edited.
    – trollingchar
    Sep 6, 2019 at 14:45
  • This is a good point. If it's possible for the data to be modified by another agent (possibly by a different instance of your own application!), then unless you take care to check for changes to the file (either via registering for change notifications or via polling), disallowing saving when you think there are no changes prevents someone from restoring an earlier state of the file. Note that many text editors (Notepad, Sublime Text, ...) always leave the Save command enabled.
    – jamesdlin
    Feb 6, 2020 at 17:55
0

Yes, the save button should be disabled if there have been no changes made.

It's best if the button's name emphasises the fact that it saves changes, e.g.: Save Chages and it's accompanied with a Cancel (or close) button, so the choice is obvious for the user.

Unless the changes always applied successfully (e.g. not as separate HTTP calls that can fail) and it's a common pattern in the applications, it's reasonable to show a notification for a couple of seconds, that the changes have been successfully applied.

Improve this answer
0

I don't like option two if it's running on many types of hardware that you don't completely control; sometimes applications run slow on overloaded hardware / bogged down OS/trojans - if it does, and you miss the brief time the save is active, you don't know whether you have saved or not. You need another small message that says: last saved (timestamp) / not saved.

Close should not be active until something has been saved, especially if there is no undo or revert to last save function. And I assume close does not save.

Improve this answer
0

It depends on how frequent your user will be made some changes to it. But you can enable the button at all times and once the user applied some changes on it, make sure to inform the user that it is saved successfully.

E.g

Save changes - Primary name of the button

Saved - Button name will change after triggering the save changes button and after a few secs. name will be back to the primary ones.

Hope this will help

Improve this answer
0

The most important thing is the user knows the state of the system "Can I perform an action and does the system tell me something is happened"

With the save state disabled you're actually telling the user the save state is up to date and everything is saved. This is a good thing. As long as the user knows that.

With the second option as long as you feedback the fact the system is saving there should not be a problem. The drawback is there is no state to indicated 'saved-ness'

First option carries more information.

Improve this answer

Your Answer

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

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