Progress bars still lie • Hacker News Board

Re: Progress bars still lie

#11

Post by ASalazarMX » Tue, Nov 24, 2020, 10:09 PM UTC

I also have seen Apple progress bars rigged to 75%, for some unknown reason, but my biggest offender is my DVR phone app.

On connection it shows the last image sent by the camera, and a progress percent. The progress is really a connection timeout, and you can't be sure it connected or not until it reaches 98% and fails.

Re: Progress bars still lie

#12

Post by dragosmocrii » Tue, Nov 24, 2020, 10:09 PM UTC

Imagine if you used the example with YouTube uploads in the context of giving project progress updates to your boss: " day 1: We're at 10% completion; day 2: we're at 20% completion; ... day 10: we're 100% done, deploying tomorrow; day 11: actually we have to start over from scratch..."

Re: Progress bars still lie

#13

Post by fgdelcueto » Tue, Nov 24, 2020, 10:10 PM UTC

When progress bars are not useful it is because the underlying problem is hard to extrapolate faithfully. If you are doing just a few tasks where each one takes a significant different time to execute, it will be hard to estimate. More often than not, they work fine, IMO. When they don't, it is because for that particular problem it is genuinely hard to do. It isn't programmer's laziness, I think, in most cases.

Re: Progress bars still lie

#14

Post by canadian_tired » Tue, Nov 24, 2020, 10:10 PM UTC

pmoriarty wrote: post #6

Lying progress bars are one of those ubiquitous anti-features which make me suspect the people who write the apps that have it or who decide what features they are to have never actually use their own software, or they'd realize in a heartbeat how incredibly annoying and frustrating lying progress bars are. I'd love to hear an HN reader who is brave enough to own up to implementing one of these explain the rationale…

Well... story time. I had to implement a lying progress bar at the behest of my client. We could not reliably predict much...network speed, file size, moon phases, sock colour, etc would change things all the time. The client wanted to show the customer that "things were happening"... so we made the bar always move. The logic was that once it hit 90% or more, customers seemed to be invested and would wait forever. And yes, we tracked the abandonment percentage against progress bar percentage.

Re: Progress bars still lie

#15

Post by lpellis » Tue, Nov 24, 2020, 10:10 PM UTC

Reminds me of this xkcd: https://xkcd.com/612/

Progress bars are much better than spinners in many cases though, even if they lie, at least I get a rough estimation how long something is expected to take, and if it gets stuck.

Re: Progress bars still lie

#16

Post by keithnz » Tue, Nov 24, 2020, 10:10 PM UTC

I've found in apple world progress bars seem to lie more ( not that others don't). Worst of all are the progress bars that take forever to get to the end, then, start a new progress bar. Multiple phases with multiple progress bars is pure evil!

Re: Progress bars still lie

#17

Post by tyingq » Tue, Nov 24, 2020, 10:11 PM UTC

pmoriarty wrote: post #6

Lying progress bars are one of those ubiquitous anti-features which make me suspect the people who write the apps that have it or who decide what features they are to have never actually use their own software, or they'd realize in a heartbeat how incredibly annoying and frustrating lying progress bars are. I'd love to hear an HN reader who is brave enough to own up to implementing one of these explain the rationale…

I suspect fake progress bars do pretty well in a/b testing for page abandons, versus nothing at all. Especially if they show more "done" than not. I don't like it myself, but perhaps it's comforting to those that don't know better.

Re: Progress bars still lie

#18

Post by sto_hristo » Tue, Nov 24, 2020, 10:12 PM UTC

Progress bars are just a tool that needs the right material to work on. I realized that when i tried to progress bar-ify a recursive task.

I think it's more sensible to find a UI language that can seamlessly incorporate a progress bar and a dumb spinner with some note on what's going on. Which one is shown/used will depend on the task that is being loaded. Different words for different things.

Re: Progress bars still lie

#19

Post by axaxs » Tue, Nov 24, 2020, 10:13 PM UTC

I think I'd rather just have predetermined steps/milestones. Think about it...what does 71 percent really mean? Would you get excited when it goes it 72? It's just an opaque, useless metric.

If instead I can see something like...step 1/5, downloading package... that's far more meaningful, at least to me.

Re: Progress bars still lie

#20

Post by leesalminen » Tue, Nov 24, 2020, 10:13 PM UTC

tyingq wrote: post #17

pmoriarty wrote: post #6

Lying progress bars are one of those ubiquitous anti-features which make me suspect the people who write the apps that have it or who decide what features they are to have never actually use their own software, or they'd realize in a heartbeat how incredibly annoying and frustrating lying progress bars are. I'd love to hear an HN reader who is brave enough to own up to implementing one of these explain the rationale…

I suspect fake progress bars do pretty well in a/b testing for page abandons, versus nothing at all. Especially if they show more "done" than not. I don't like it myself, but perhaps it's comforting to those that don't know better.

Can confirm, they work great for users. We had a system where some old things were traditional POST+redirect and the rest was all React with progress bars, disabling buttons when submitting, etc. Users demanded we make everything use progress bars because it's "faster". Our p95 DOM render was 400ms so it wasn't "slow" to begin with. I'm confident it really was the progress bar.