So I should never pretend that an operation that took 10 ms took 200ms so the users stop hammering the Save button over and over again because there's 'no way' it could have saved that quickly?
Our software product eventually got auto-save after having required manually saving for a while. We got rid of the save button, and got tons of complaints.
The button went back up, with no functionality, because users liked that.
Finally got rid of the button and put some text that said 'saving...' -> 'auto-saved' in its place.
It is far more pleasing to understand what is going on and be able to measure its progress then to be shown a series of arbitrary shapes and symbols that happen to push one's happy buttons.
Stop pandering to your users' mercurial, unpredictable, and manipulable feelings, and start using your software to teach their brains how it all works.
Plus, then I don't finish the interaction with, "well, what else have they deceived me on?"
No it's not. It doesn't prove anything, and there are ways you can prove it that don't deceive the user, like a status message at the end or a change of button text. The value of a progress bar is for the user to see the state of a background process, not to see whether it suceeded. Don't assume that all your users, or even a small proportion, think this.
I'm not suggesting deceiving users. I'm suggesting a spinner isn't much proof of the app not being hung. Some kind of updating status or progress is, assuming it's not complete bullshit. I can see cases where "slightly bullshit, but somewhat true" is better than just a spinner or unresponsive UI.
I disagree. There's a difference between a progress bar that could just be a spinner or no progress bar at all because it's fake. And a progress bar that attempts to communicate real progress.
For me, a spinner doesn't say much, because it could just be something like an animated gif, while the app itself is hopelessly out to lunch. Knowing that at least one thread is working in a long running task is calming.
So I should never pretend that an operation that took 10 ms took 200ms so the users stop hammering the Save button over and over again because there's 'no way' it could have saved that quickly?
Why wouldn't you instead show a timestamp of the last save, giving confirmation that the save really went through?
Or a quick tooltip that flashes "Document saved" before disappearing?
Or disable the button for a second after saved?
Or show a cute little "save complete" icon?
Or autosave on change and disregard the save button entirely?
1 reply →
Our software product eventually got auto-save after having required manually saving for a while. We got rid of the save button, and got tons of complaints.
The button went back up, with no functionality, because users liked that.
Finally got rid of the button and put some text that said 'saving...' -> 'auto-saved' in its place.
Should have put "Saving. Please do not remove the MEMORY CARD™ or turn off the power."
Why not an enable/disable edit button?
Typically, applications disable the save button when there are no changes that could be saved.
Our brains are funny things and there are lots of ways to hack them to make the world a more enjoyable place.
A related idea: https://signalvnoise.com/posts/1244-defining-the-problem-of-...
I would put these solutions into the same category: accommodating the way the brain works to create an overall more pleasant experience.
You may choose to call it deception, but you probably don't want to live in the world where no one does anything along these lines.
> overall more pleasant experience
It is far more pleasing to understand what is going on and be able to measure its progress then to be shown a series of arbitrary shapes and symbols that happen to push one's happy buttons.
Stop pandering to your users' mercurial, unpredictable, and manipulable feelings, and start using your software to teach their brains how it all works.
Plus, then I don't finish the interaction with, "well, what else have they deceived me on?"
Maybe for you but i dont think that is true for a majority of the population.
It's visual "proof" that the app itself isn't hung. I agree that you would have to be careful with the text, but progress bars do have some value.
No it's not. It doesn't prove anything, and there are ways you can prove it that don't deceive the user, like a status message at the end or a change of button text. The value of a progress bar is for the user to see the state of a background process, not to see whether it suceeded. Don't assume that all your users, or even a small proportion, think this.
I'm not suggesting deceiving users. I'm suggesting a spinner isn't much proof of the app not being hung. Some kind of updating status or progress is, assuming it's not complete bullshit. I can see cases where "slightly bullshit, but somewhat true" is better than just a spinner or unresponsive UI.
1 reply →
I disagree. There's a difference between a progress bar that could just be a spinner or no progress bar at all because it's fake. And a progress bar that attempts to communicate real progress.
For me, a spinner doesn't say much, because it could just be something like an animated gif, while the app itself is hopelessly out to lunch. Knowing that at least one thread is working in a long running task is calming.