1

I see that a lot of frameworks for form validation have "is dirty" state check which tells if the user has ever modified input value.

But I don't see options that compare the original and current value of the input to check if it's actually different and needs to be saved.

So, in this use-case:

  1. Initial value: "my text"
  2. User changes to: "your text"
  3. Then the user changes it back to "my text"

Should the save button be enabled, or not?

My assumption is that the user might not remember what the original value was and would be looking for an option to save.

But if we only enable the save button when there's something to save - the user should recognize this and understand that his changes resulted in the starting value (back to the square one)?

Any opinions on that?

5
  • The question is probably also, "Did the user save in the mean time?". I think it is unlikely that a user looks at a form, decides to change its value, changes it back and forgot what the initial value was (all in a time frame of 10 seconds or so).
    – Nash
    Sep 6 at 7:11
  • Why would you ever want to disable a save button even if nothing has changed?
    – jazZRo
    Sep 6 at 7:16
  • 1
    @jazZRo as an indication that there are no changes - hence no need to save anything Sep 6 at 7:34
  • 1
    Yes I got that, but is it really that bad that the form can be saved when nothing has changed? What if the user wants to be sure any changes are saved but forgot if anything did actually change? Let the user just save the form, just to be sure. A disabled button doesn't communicate that it isn't necessary to save and can be very confusing, even a "nothing changed" text nearby doesn't fix that.
    – jazZRo
    Sep 6 at 7:52
  • I thoutht that It can be bad. This answer highlighted that in case if the resource is shared, there might be a race condition because of this. And in my case, it is a shared resource, so race condition is possible. But this doesn't eliminate the race condition possibility completely, so we'll be implementing protection against it anyway. Long story short, now I think we can leave "save" button with no harm to the system or UX... But azure disables the save button. Here's a video of it that I recorded. Thoughts? Sep 6 at 9:39
1

A couple of points are worth mentioning here.

Firstly, the general consensus is that disabling buttons is bad for accessibility reasons https://www.smashingmagazine.com/2021/08/frustrating-design-patterns-disabled-buttons/ it can be done, but personally, I'd aim to avoid it.

Secondly, in terms of a dirty state changing from and then back to the original value should likely not result in a dirty flag being set.

You say:

But I don't see options that compare the original and current value of the input to check if it's actually different and needs to be saved.

I'm not sure I see this in practice, most solutions will compare to the initial values (and keep those in memory/state) to establish if the form or field is dirty (e.g. Formik https://formik.org/docs/api/formik). Additionally, if you were writing this from scratch you'd want to use this pattern.

1
  • Good point on accessibility, thank you. About dirty, it looks like you're right... I was pretty sure that it was working differently in libs that I've checked, but now I can see the opposite, weird. Oct 8 at 12:36
1
  1. The tracking of a dirty state and removing it if the change is nullified can certainly be done. I find it very useful myself; it saves my sanity and OCD anxiousness / mental load that otherwise arises if I see an "unsaved" indicator or dialogue box when I don't think I've made any changes.

To take VSCode as an example, you can see it does not track dirty state in the way you describe for files in the editor, but its git UI does (of course).

VSCode state tracking

  1. I'm ambivalent about disabling a save button to reflect an unchanged state. The others are certainly right that disabling buttons and menu options is bad UI in general, since it's hard to communicate why this is happening and/or provide solution routes. Even so, if it's the only way to indicate an unchanged state, I think it's worthwhile.

    But perhaps you can take a cue from the git changelist or the icon on the .py file here for your own use case. Many modern editors now do some kind of state tracking in the title bar, e.g. adding an asterisk * to indicate unsaved changes. If I don't see that asterisk, I won't unnecessarily save; but (and therefore) you also don't need to disable the save menu item. It's the best of both worlds.

P.S. One more note. VSCode (and other editors) do do a light form of dirty state tracking, but in a different way. They look at the undo/redo command stack. And they remove the dirty state indicator if I actually undo everything, rather than retype it. This is technologically easier to track and probably also psychologically more coherent in terms of thinking, "But I undid all those changes!" instead of "Oh, that's right, I happened to retype everything I previously deleted" — a less common use case among users with basic proficiency.

restate

P.P.S. lol, these online gif converter artefacts!

1
  • Interesting point about adding unsaved state indication but not disabling the save button. And about showing as unsaved even if new content equals the original. I'll have to think about this, thanks! Oct 8 at 12:31
0

As suggested in the comments to your question, there should be very few cases where an "extra" save causes trouble.

But if you absolutely want to manage a "not-dirty" state, disabling a button is often not a good way to convey this. I find leaving buttons active and giving feedback (if needed) on click instead leads to a better user experience.

In this case though, no feedback is even required. I would just manage the "dirty" mechanics silently: leave the "Save" button always active and on click, if you figure nothing's changed (better be 100% right, though!) your button does not save the data again, and just does the next step, as if a save had happened.

So if after the data is saved, the user is usually redirected to page A, then when the user clicks "Save" and nothing's change, simply do the redirect immediately. This can be done either client-side or server-side. But as I said, you'd better be sure nothing's changed otherwise some changes will not get saved to the database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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