User has edited text, then deleted changes. Should "save" button remain active?

Question

We are trying to figure out the conditions for enabling/disabling a button that saves text contents in the following scenario:

1. A user types "hello" in a textarea.
2. A "save" button is enabled.
3. The user clicks the "save" button.
4. The text is saved and the "save" button becomes disabled.
5. The user modifies the text to "hello world".
6. The "save" button is enabled.
7. The user changes their mind and deletes the changes by pressing delete or backspace on their keyboard.
8. Should the "save" button become disabled?

I personally think that the "save" button should become disabled because I don't want the user to do unnecessary work and because it's easier to implement in our codebase.

However, a colleague argues that because the user has touched the contents, their expectation is that the button should stay enabled.

What do you think?

Answer 1

Yes, the Save button should remain active.

The only rule for your disabled Save button is: After the user has pressed the button it becomes disabled, when the user adds/removes a character the button becomes enabled. Note that the idea is when something is added/removed in history terms, not in the end result.

Don't confuse the user with an exception.

It doesn't matter if the new step in history is the same as the previous one. The user might want to save it to keep a log that he thought about adding some extra info but regretted it, improbable but possible.

If there is any kind of confusion don't do it, even if it might look more convenient.

Answer 2

Either choice is fine as this is an edge case which will not affect real users. Go with the easiest path. I am a product owner with 15 years usability research experience at fortune 100 companies.

Answer 3

I think the rule of thumb is, after the user does what ever he does to the text area, will the resulting text be different from what is there before the edit? Yes, then enable save button, No then what are you saving?

Disclaimer: I have no research basis for this, this is entirely based on common sense.

Answer 4

Disclaimer: I am not a UX guy, I'm just giving my views as a user.

Let me explain how I felt about a real world situation similar to this.

When programming in Java I use IntelliJ and when programming in .NET I use Visual Studio.

When a change is made to a Version Controlled file in IntelliJ the name of the file changes color. If I reverse the changes, the color changes back. In Visual Studio if you change a file it add a little star next to the name of the file. If the change is undone that star doesn't go away.

Personally, I very much like the idea of knowing if I made any changes. I don't like that in Visual Studio I can basically be warned/prompted that my work has changed and not been saved even if it didn't.

I think you should disable the Save button so that the user can quickly know that they essentially reverted back to the last saved changes. I think users do like to know when they changed something, and that they like knowing when they fully undid that change.

Answer 5

Invisible logic

This type of logic, from a user perspective at least, is invisible logic - the system has a set of rules that the user can only infer.

• Why the save button is disabled?

Invisible logic is counter usability since users are left to infer why things are the way they are.

Even when the logic can be easily inferred - as in the case of a disabled login button when either the username or password fields are blank - designers will sometimes prefer to allow users make errors then tell them explicitly what they've done wrong than let users work out invisible logic.

Situational & contextual design

Designers often ignore the situation and context in which users operate.

Consider the following scenario:

A user types a new value in the field, and gets a Tinder notification on their mobile. Eagerly, the user unlocks his phone. After 10 minutes of flirting, the user is back to the system, with the save button disabled. "Have I pressed save? I don't remember I did!". Obviously the user did, but he can't remember.

Back to the user

An IO analysis of users in this case goes:

• Output: In terms of actions, users want to save what they have entered.
• Input: In terms of information, users want to know all their changes have been saved.

To satisfy the output requirement, simply have a Save button. To satisfy the input requirement, simply add a message next to it All changes are saved - that's much more reassuring than a disabled save button.

Disabling

You may still choose to disable the save button, or in some cases replace it with the All saved message.

In the case you've described, since the message reads Changes saved, any change should enable the button (even if the change ends up as the saved version). If your message reads Saved than disabling or hiding the button makes more sense.

Answer 6

Enabling / disabling of Save button should be proportional to user’s activity in textarea.

So, it must be enabled whenever the user jumps into the textarea in-spite of any modifications done. By enabling Save button (an affordance) you are serving an additional signifier for user to re-confirm/review the changes to be published.

As in the above mentioned scenario user have done modifications in the already published content, so in that case user should be in charge for confirming the changes not the system in order to maintain consistency throughout (among user’s mind and published post).