I’ve seen code with progress bars that didn’t hold up under maintenance (basically lying over time). As features were added, explicit progress percentages might not be updated so last month’s “30% complete” point might have 3 more steps in between this month.
Why some apps use fake progress bars (2017)
61–70 of 200 posts
Re: Why some apps use fake progress bars (2017)
#62Deception is NEVER benevolent. Don't lie to your users, people.
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.
Re: Why some apps use fake progress bars (2017)
#63Earlier quoted context omitted.
Connecting Fetching data Processing query Preparing for display
Most of those steps will go immediately, and one of them has the same problem the original issue had: it’ll sit on it for ages...
Can it not say "$X items processed..." or have a spinner that updates it's frame at certain intervals? It doesn't have to be a percent, just proof of progress. I had no trouble adding an accurate "$X rows of csv processed" in a laravel (PHP) + VueJS app.
Re: Why some apps use fake progress bars (2017)
#64By the title and "some" does it not mean, "all" apps use fake progress bars? The only apps that use legit progress bars were made in '94, the ones that have not had a superiour product come along because they were done right the first time.
Re: Why some apps use fake progress bars (2017)
#65This is a horribly researched article. Progress bars are not benevolent deception, they are deception by incorrect choice of UI elements.
>Mask system hiccups to smooth out a user’s experience (like when a progress bar grows at a consistent rate, even if the process it’s visualizing is stuttering
This is malicious deception. The only one being benefited is the developer when the users incorrectly think your software is smooth but is in fact not. If the software hiccups, the users need to know this to better understand the system they are working with. Your users are left ignorant, which is malicious.
>The word “deception” has a negative connotation
That is because it is negative. A user exploring the UI of your software is much like a physicist researching the unknown laws of the universe. A physicist never benefits from ignorance, so don't find ways to make your users more ignorant about your system.
>Despite its complexity, this step was nearly instantaneous in the game’s first iteration. But the speed confused people. “Their reaction was, ‘Wow, was that it?’” Adar said. “That was sort of a bummer for us.”
That's why you should rarely listen to user feedback if you don't fully understand their experience. In this case the explanation is simple: users expect your system to be worse/slower than what it is, so when it exceeds their expectations, they are surprised and report this to you, but you've just set a new expectation that your software is faster than others out there, and then destroying it with an update.
>The security theater appeared to work
Already mentioned in this HN thread, but wrong term here.
>The needle only wandered within the margin of error of the forecast at any given moment, Aisch explained
Then put an error bar around the needle for crying out loud. Designers need to stop assuming their users are stupid---this is an annoying trend. If you're over the voting age, you can understand the concept of error bars. If the "needle jittered less and less", then the error bars are already known, so the designers actively chose the "lying" method to the truthful and more informative method.
>artificial static that Skype plays during quiet moments in a conversation to convince users the call hasn’t been dropped
This one is fine and can be grouped in the "skeuomorphism enhancements" category.
Re: Why some apps use fake progress bars (2017)
#66Reminds me of the old IE bar (not sure if it still does this), but it would crawl towards 100%, getting slower and slower as it approached the end, when waiting for a page to respond. In reality IE had no idea how much "progress" had been made by the server, if any.
They also had those progress bars when you stopped or restarted some services in an old version of Windows. They had no idea how long it would take, so they just made a logarithmic progress bar that became slower and slower, but never finished. That trick only works once. As soon as you see that progress bar pattern a couple of times, you realise that it is fake, and it is infuriating. Progress bars need to be honest…
I'd rather just see output of something tied to the actual process.
Basically an answer to the question, "Is this thing taking a long time because it's doing work - or because it's busted"
In software it's busted at least 20% of the time and I think that's being generous.
Re: Why some apps use fake progress bars (2017)
#67Earlier quoted context omitted.
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.
Re: Why some apps use fake progress bars (2017)
#68Earlier quoted context omitted.
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.
Why not an enable/disable edit button?
Re: Why some apps use fake progress bars (2017)
#69A physical analog of this would be when an Houston airport reduced complaints by moving it's baggage claim to be farther away from gates. Would you call this deception? Also: A friend runs a service that analyzes web page design based on tens of thousands of hours of human eye tracking studies. An analysis only takes a matter of milliseconds, but they found that their conversion rate went up if they artificially put…
artificially put in a delay Makes me wonder if online retailers for luxury/fashion items could increase sales by doing something similar. Announce the latest fashion item via social media, but make the page take forever to load... maybe throw in a few fake 404s to a percentage of users saying the store's website is overloaded and encourage the user to refresh. Then when the page finally loads there's a limited supply…
As far as I know a lot of travel and hotel websites actually work kind of like that.
Re: Why some apps use fake progress bars (2017)
#70Earlier quoted context omitted.
Connecting Fetching data Processing query Preparing for display
Most of those steps will go immediately, and one of them has the same problem the original issue had: it’ll sit on it for ages...
I know this won't work everywhere, but if you know how much time the task generally takes, your progress bar can just be a timer for that duration. Still more informative than fake messages.