Hello!
To use the forum, login or register above.
(If you are already logged in above, please click here)
Change to "Save Changes" Button
I suggest implementing two states of "Save Changes" button:
1. when no changes are made, the button is greyed (disabled).
2. when changes are made, the button looks exactly the same as it is now (blue and active, maybe even pulsating)
I can't always remember if I already saved changes, or made any changes at all. With a two-states button I won't be tempted to press the button multiple times and be greeted with annoying banner "No changes detected".
If you think this suggestion may be useful, please upvote.
1. when no changes are made, the button is greyed (disabled).
2. when changes are made, the button looks exactly the same as it is now (blue and active, maybe even pulsating)
I can't always remember if I already saved changes, or made any changes at all. With a two-states button I won't be tempted to press the button multiple times and be greeted with annoying banner "No changes detected".
If you think this suggestion may be useful, please upvote.
This discussion has been closed.
Powered by Vanilla
Comments
To implement the button color change, one needs to decide on what criteria triggers the change. Is it the insertion of the cursor into a field? Is it an edit to text in an existing field? What if you make a mistake, edit a number, then realize it was the wrong number and change it back to the original number? If that's the case, has a change been made? How is the system tracking that? What if the change is happening with a checkbox or button or something on a popup menu?
If you change something, then change it back, and the criteria is that any field receiving focus constitutes a change, the button swaps color, you go away, you come back, you submit, and you still get a notice that no changes were detected.
There are potentially lots of things to track. To put it politely, this could be a whole heck of a lot to program.
Assume some distraction/interruption in the workflow. Phone call, howling cat, whatever. Upon resuming work, the button state may be not visible (require scrolling down). To assess the current state one then may need to scroll, locate the button, and scroll back to a non-fixed point in the page. This has introduced three steps in the workflow. Is this more efficient than submitting in whatever state the page is in and dealing with a notice? I think it's at least three steps versus one.
My particular experience with the button/disappearing notice happens to be on the image upload page. I may have multiple pages open while working on multiple images. If I upload an image, the notice appears, then disappears and the page returns to it's previous state of "nothing". I become distracted. Upon returning to the page I can't remember if the image has been uploaded or not. In this instance a persistent notice would be helpful.
Having a modal button as you suggest in a fixed position on the page (it stays put while the rest of the page scrolls) would be an alternative to having to scroll around until you assess the state and then potentially return to wherever you were, but being modal requires tracking the page state.
You state: "Any further change to the page would turn the button blue (meaning it has become active) and the change has to be saved."
I wouldn't go as far as "HAS TO be saved"... I'd say that the change in button color would indicate the page has been altered in accordance with whatever rules are set up to track the page state. Your initial point was that you couldn't remember if it had been saved or not. If it had been subsequently altered after a save, and then you're interrupted, can you remember where you were on the page, how many fields were altered, which fields were altered, and so on? Did the cat step on the keyboard while you were away? Are you going to save the page at this point irregardless or is it better to reload the last saved state and start over? Do you have to scroll around to find the submit button and determine the color? I don't know the answer.
One can go into lots of specific situations, and the best solution for one page may not be the best solution for another.
This kind of thing can turn into hours or days or weeks of intense examination to find an optimal solution.
Changing the button color as you suggest is not a bad idea at all. But it addresses only part of the stated problem. It implies potentially a lot of programming.
My suggestion is relatively trivial from a programming standpoint. Note that it doesn't address the whole "current state of the page" issue which would need to be addressed with the modal button.
I'm not suggesting what you're suggesting is a bad idea at all. I am suggesting it's quite a bit of work to achieve. If the goal is simply to eliminate the popup saying that there was no change when the button is clicked...well, I think I can live with that popup notice given that it's still going to be...not necessarily required...I can't fathom all the possibilities relative to all the forms that may be affected, but...useful communication in many instances.
The real problem, as I see it, is the human one of not being able to remember. So unless the page can be constructed in such a way as to highlight all changes as they're made and have them persist until the submit button is clicked, changing the button color is indicative of a change of the page state but not indicative of where you were, what has been accomplished, what needs to be accomplished, and so on. It's indirectly addressing the problem, not directly addressing the problem. And it still wouldn't resolve my situation of having completed the task but not remembering.
At least that's how I see it.
If you know or understand something that I don't, please refute my assertions as I'm always eager to learn stuff. I would certainly be very interested in hearing how you'd implement the suggested change from the programming side.
For @mfav : yes, but have you had your cat use the keyboard as a scratching post and then leave you the message
XxxxxxftdkyhFEEeEDbgknodhhsldMEskhfkshfjlosariawry
?
We have treasured pictures of a destroyed keyboard and message posted otherwise no one would believe...
"Is it the insertion of the cursor into a field?" No, it isn't, I tried that.
"What if you make a mistake, edit a number, then realize it was the wrong number and change it back to the original number?" Tried that as well, no change has been detected.
A change of button color would just show in advance that the System detected a change and it's up to you if you want to save it. If there is no change detected, your action is not required and the button remains inactive.
Sure, it doesn't address all the problems (e.g. having completed the task but not remembering) but I think it's a step in the right direction. Maybe all the changes could be in different color until the Save button is pressed?
Now, finding the Save button is whole other issue and I like idea of a "floating" one, that doesn't require scrolling to the bottom of the page each time.
you say: "I assume the System is already programmed to recognize a change:"
I doubt it. Typically data is "copied" from the database into the editable fields on the page. When the submit button is clicked, then the data from those fields replace the corresponding field data in the database. The management of the data happens after the click of submit.
If the data in the editable fields was "live" then there would be no need to click a submit button to update.
Having the page recognize a change would require that every editable element be tagged to recognize whatever "trigger" action is appropriate for that element. That could be a mouse click down, a mouse click up, a key stroke, or many other things. Each element would need to be addressed individually. If this additional coding is done with javascript, then the functionality may be overridden on the client side by a plug-in or by manually disabling javascript...thus rendering it inoperable and pretty much at that point the programmer has to consider if the effort to reward ratio is worth it.
If I'm following your comments correctly, you appear to be "testing" my questions. As you find that the suggested actions are yielding no results, then it should be clear that the system at present is definitely not recognizing these actions relative to your desired/proposed outcome.
You say: "A change of button color would just show in advance that the System detected a change and it's up to you if you want to save it. If there is no change detected, your action is not required and the button remains inactive."
Right, but do you remember what the change is? Did you make that change? Is it one change or several changes? Have all the changes you intended to effect been made? Did the cat make the change?
It's up to you to decide to save the page whether or not the button has changed color. The appearance of the page prior to editing and subsequent to submission are identical...you have, in your scenario, a gray button...if you can't remember if you submitted the changes or not, now you have to scan the page looking for edits.
You say: "Maybe all the changes could be in different color until the Save button is pressed?" This may be possible in some manner, but now you need a whole "engine" to drive this. And to what degree are changes indicated? How is deleted text indicated? What color are changes? Is the background colored or the words colored? Is the content still legible with color changes? And on and on. You've now introduced visual design and cognitive fluency issues into the mix. Can it be done, probably. Can it be done so the comprehension of the user is immediate and unambiguous? I don't know. Can it be done cost effectively? Doubtful.
Ignoring the complexities of programming, and assuming that the button state would change when any field content is changed, I wonder if that change in button color would be a completely reliable indicator or only a partially reliable indicator. Do you need to continue to edit the page, or are the edits complete? I don't know how that could be determined by the system.
Button color change might work on a page with only one editable field. In that case there's probably no ambiguity.
@One_Click_Off: Nope. No cat here. But definitely have had things end up on top of the keyboard which destroyed work on screen.