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

61–70 of 232 posts

Re: Progress bars still lie

#61

Post by news_to_me »

dwohnitmok wrote: post #34

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). I…

I think there's two issues here that are often wrapped up together: 1. what is the status of my task, and 2. did the computer get stuck

If we could be sure the computer wouldn't get stuck (which is just a bug), then progress bars and spinners would be fine. If the task is as granular as you suggest, progress bars would be a great visual indicator, much better than text.

But since computers do get stuck, additional indicators should help with that. A spinner is supposed to show that a process isn't stuck, but those are fallible too. A textual representation ("bytes currently downloaded") sounds like a great addition to a progress bar. I've seen this a lot on linux distro installers, where you can click "details" below the progress bar to see the console output.

Re: Progress bars still lie

#62

Post by fairity »

dkersten wrote: post #58
canadian_tired wrote: post #14

Earlier quoted context omitted.

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. An…

What's wrong with using something like a spinner in that case though? The big issue with a lying progress bar is that it not only lies when things are happening, it also lies when things are broken, possibly wasting a lot of your users' time.

The goal isn't to save the user time. It's to maximize user conversion rate.

Re: Progress bars still lie

#64

Post by allenu »

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…

Conveying progress in a lot of cases is difficult. Sometimes you have two sets of tasks where the first set determines how much is done in the second. That means you can't accurately predict the overall length of time required to finish everything.

You could split up the overall progress into two parts, 50% of the bar each. The first part might take a while to finish and when you get to 50% you determine how much is left in the second half, and if it's quick, you immediately jump to 100%. On the other hand, if the second half takes really long, now you're sitting there waiting what seems like an eternity to do the second half.

With some clever design, you could have a smarter progress bar system where each task is weighted and adding it to the overall progress re-computes how long everything is, but now you have a scenario where the progress bar could shrink as you get more accurate about the work ahead.

If the time to complete a task is short enough, a lot of these tricks for more accuracy just aren't worth it, and often require fundamentally changing the architecture of your underlying processes, making it more work than it's worth. Hence, you end up with funny things like finishing at 75%. Though, to be fair, they should at least jump to 100% before finishing. I think that's a common bug that comes up, not letting the full bar show first before dismissing.

Re: Progress bars still lie

#65

Post by recursive »

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 made one of these.

We needed a progress bar, but there was no way to estimate progress.

Re: Progress bars still lie

#66

Post by Finnucane »

tunesmith wrote: post #63

I think duty #1 of a progress bar is just to reliably communicate whether it is frozen or not. In many cases, slow progress is fine as long as it isn't stuck.

Yeah, the main thing I want to know is that the process is still working as expected and not crashed or interrupted. In many cases that's more important than the time value.

Re: Progress bars still lie

#67

Post by atq2119 »

leesalminen wrote: post #20
tyingq wrote: post #17

Earlier quoted context omitted.

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.

> Our p95 DOM render was 400ms so it wasn't "slow" to begin with.

Not sure why exactly you put quotation marks there, but 400ms is incredibly slow, at least relative to human perception and what computers should be able to do. Consider what AAA games can render in 16ms.

Re: Progress bars still lie

#68

Post by bryanrasmussen »

news_to_me wrote: post #43
Frost1x wrote: post #30

Earlier quoted context omitted.

I often see the suggestion to display spin animations instead since estimation is often incredibly difficult if not impossible. I prefer progress bars because even if they aren't accurate, the relative directional growth shows me that something is actually executing. With a spin animation, for all I know, somethings caught in a loop.

This seems a little funny to me, since the purpose of the spinner is so that you know the computer isn't caught in a loop — it's "busy". It's true, though, that the computer could still be stuck even though it updates the spinner. This is a hard problem to solve. Abusing progress bars are not a good response to this, though. I would rather trust progress bars for what they are meant to show rather than as an indicati…

>This seems a little funny to me, since the purpose of the spinner is so that you know the computer isn't caught in a loop — it's "busy". It's true, though, that the computer could still be stuck even though it updates the spinner. This is a hard problem to solve.

The problem that people might assume the computer is stuck in a loop or at any rate that the animation is not going to stop is related to spinner animations on websites. Since the spinner is not a function of the browser, but is instead something implemented in the individual site's code, then stopping the spinner needs to be also coded for and many sites neglect to write the code for "when error happens stop spinner and tell them that things went wrong".

So over time people exposed to negligent website spinners start to suspect any spinner that takes too long.

Re: Progress bars still lie

#69

Post by allenu »

I actually don't mind the occasional lying progress bar. I think TurboTax is famous for this, where they just toss in fake progress bars to indicate that they are crunching some numbers, which really just take milliseconds, if that. The goal is just to convey that "heavy work is happening".

I ended up using this strategy recently because I wanted to convey that my app was "doing work on your behalf", so I tossed in a super quick progress bar like TurboTax does and then did a slick transition animation to show the results. It's "unnecessary" in that I could've just showed you the results, but I really wanted to convey that there was a sort of cause-and-effect in the system. Without that little bit of animation, it felt like that would've been lost.

Re: Progress bars still lie

#70

Post by amelius »

wyattpeak wrote: post #49

You know what I like for progress bars? The mess that is your average build script. Tell me how many tasks there are to complete, how many you've done, and some rough details of what you're doing (e.g. is it a network request). Don't be shy about commentary ("This may take a while", "If this fails multiple times do X"). These generally contain all of the information that the developer has access to, and rarely am I l…

CMake has a progress indicator.
Post reply on HN