Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Progress bars still lie

web.eecs.utk.edu

Post reply on HN
Print view View original

31–40 of 232 posts

Re: Progress bars still lie

#31

Post by SulfurHexaFluri »

leesalminen wrote: post #9
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…

1.) User submits ticket stating "action X is slow" 2.) Project Manager creates dev task "make action X fast" 3.) Too much work to actually make action X fast. Decides to make the user feel like it's going faster. 4.) Deploys fake progress bar to prod. No new tickets.

Its incredible how much faster you can make an app feel by just making the UI respond faster and filling in the data later. As long as something happens instantly its satisfying.

Re: Progress bars still lie

#32

Post by nix0n »

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've implemented quite a few lying progress bars.

It's impossible to estimate total completion percentage when one part of the operation is CPU-bound, and another part is disk-bound.

(I haven't had to deal with network-bound operations, but I feel for those who do.)

Truth is probably possible, but more work than it's worth, when one part of the operation is O(n) and another part is O(m^2).

If the feature is a week late, it doesn't crash, the answers are right, and the operation completes in a reasonable amount of time, I'm moving on with my life.

Re: Progress bars still lie

#33

Post by qayxc »

The problem with progress bars is that they're ambiguous on many levels.

What does the progress mean? Is it the fraction of work done or an indication of time left?

Progress bars don't necessarily lie - they simply omit useful information. Estimating progress is hard if there's variables involved that are outside the application's control, e.g. network speed or task switches initiated by the OS.

Task-based progress bars suffer from being "jumpy" and terribly inconsistent, because some tasks take longer than others and the progress indication doesn't allow to estimate the remaining the time.

Time-based progress bars are bad, because they are dynamic by nature of factors mentioned earlier, so ETA might suddenly jump from 1:23 min to 58:07 min or just as bad from 15 minutes to 3 seconds.

This is also the reason why "this is how long it took for other users" is not a great solution either: if your particular circumstances (network speed, server load, ...) are vastly different at the time, this would solve nothing and result in the same complaints.

Progress bars are just an estimation and a mixture of tasks left, ETA and a generic activity indicator ("the app didn't crash and still makes progress") might be more informative.

EDIT: for short tasks (e.g. 20 seconds or less), a simple progression of messages like "working on it", "just a moment", "almost there", "finished" might be the best option.

Re: Progress bars still lie

#34

Post by dwohnitmok »

Proposal 1 is the thing I want.

Please just list out a total number of steps and log when each of those steps is completed (with a short message describing what the step is so that we don't end up back on square one with fractional progress bars). If possible make the steps granular enough so that a step can be completed in under a second (so this may be hundreds or thousands of steps depending on the task length). In the case of say "bytes currently downloaded" this becomes essentially a continuous stream of steps (which is a good thing!).

First and foremost what this communicates to users is that the system is doing something useful. This is what frustrates me about spinners. They are functionally indistinguishable from a frozen system, to the point now that users synonymously identify an indefinitely spinning spinner with a frozen system. And progress bars that asymptotically approach completion even when the program is frozen have trained users to be similarly suspicious of progress bars.

Secondarily it offers the same vague assurances as a progress bar about approximately how much time is left. If you see 250 GB out of 500 GB downloaded you'll assume that you're half-way there, similarly if you see 250 steps out of 500 completed. Especially in the case of the latter, there's no guarantee that the total elapsed time is already 50% over, but that's true of progress bars as well.

Finally, if something goes wrong, there's usually a useful error message that can be shown since there's the context of all the previous steps that led up to this error.

Re: Progress bars still lie

#35

Post by grenoire »

azhenley wrote: post #23

Author here. Anyone have thoughts on my data-driven approach described as Solution #2? Basically: tell me how long it took other people.

That would work quite well for low-volatility tasks. iOS upgrades is a pretty good example, for one. In PC-land it gets a bit more difficult due to variations in hardware; see video games.

Re: Progress bars still lie

#37

Post by thesuitonym »

SulfurHexaFluri wrote: post #31
leesalminen wrote: post #9

Earlier quoted context omitted.

1.) User submits ticket stating "action X is slow" 2.) Project Manager creates dev task "make action X fast" 3.) Too much work to actually make action X fast. Decides to make the user feel like it's going faster. 4.) Deploys fake progress bar to prod. No new tickets.

Its incredible how much faster you can make an app feel by just making the UI respond faster and filling in the data later. As long as something happens instantly its satisfying.

Is this the idea behind that? I can't think of anything I hate more than a web page that loads with absolutely nothing useful, then waits for all the JS to load, then loads content.

I suppose I understand wanting SOMETHING to show up, but could we PLEASE make it be the raw text first?

Re: Progress bars still lie

#38

Post by news_to_me »

qayxc wrote: post #33

The problem with progress bars is that they're ambiguous on many levels. What does the progress mean? Is it the fraction of work done or an indication of time left? Progress bars don't necessarily lie - they simply omit useful information. Estimating progress is hard if there's variables involved that are outside the application's control, e.g. network speed or task switches initiated by the OS. Task-based progress b…

A progress bar is a chart, nothing more, nothing less. And as any data scientist will tell you, charts without labels are bad charts.

A progress bar should measure exactly one dimension, where a total is known, and a label should show what the dimension is. Usually progress bars implicitly measure "time left", but the total isn't known in that case, so progress bars are inapproprate.

For most "loading" scenarios, a spinner is a more appropriate element.

Re: Progress bars still lie

#39

Post by vsareto »

I'm going to be a radical and say it really doesn't matter any more. We've just gotten used to them not being accurate.

If your progress bar implementation is getting things wrong, you can probably just replace it with a loading spinner and call it a day. That's a vastly easier solution than making the progress bar accurate.

Re: Progress bars still lie

#40

Post by azhenley »

nix0n wrote: post #36
azhenley wrote: post #23

Author here. Anyone have thoughts on my data-driven approach described as Solution #2? Basically: tell me how long it took other people.

In my opinion, it's not worth the telemetry.

Aren't they tracking every app launch? Data on update times would be a drop in the bucket.
Post reply on HN