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

141–150 of 232 posts

Re: Progress bars still lie

#141

Post by yellowapple »

paxys wrote: post #74

Progress bars are something that have been researched and iterated on for decades now, and the overall sentiment is pretty clear – users like seeing numbers go from zero to a hundred while they wait. It doesn't matter if they aren't always accurate. Replacing them with a static "processing" message would absolutely increase user confusion and dissatisfaction with loading times. A while ago we put in a lot of engineer…

> After feedback from design we hard-coded it to a steadily increasing bar regardless of actual progress, and the complaints all stopped immediately.

This seems like a surefire way to end up with a progress bar at 8675309%, or a progress bar that gets to 100% and then sits there waiting for reality to catch up. And I say this from experience, having seen both of these failure cases numerous times in the wild.

If users are frequently reporting that the application's getting stuck at a particular percent, then - to me at least - that's valuable information for whether I should consider doing some optimization to speed up whatever step in the process corresponds with that progress percentage, or to break down that step further into smaller steps to keep things moving, or both.

Re: Progress bars still lie

#142

Post by admax88q »

jbay808 wrote: post #128
generalizations wrote: post #117

Earlier quoted context omitted.

> As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung". This is an important point. "Lying" progress bars are still conveying essential information - that the installation is progressing and isn't frozen. I remember from my days working with W98 and early Ubuntu versions, one of the most important bits of information coming from progress bars was whether or n…

I've seen Google display progress bars showing that my page is loading, even when I've totally lost internet connection and I know it will never load. The progress bar goes as something like 1-e^-t, so it just asymptotically approaches 100% but never gets there. When it's that kind of lie, I don't think it's conveying any essential information.

The "system is not hung" signal is dead now due to modern platforms making sure that nothing happens on the UI thread. Now we get buttery smooth 60 fps spinners and loading bars, but if the thread doing the real work hangs, there's no indication.

Re: Progress bars still lie

#143

Post by yellowapple »

kazinator wrote: post #135
fomine3 wrote: post #116

Earlier quoted context omitted.

Or just show verbose logs like Apt GUI frontend.

Problem with just logging the progress is that the user has no idea where he "bottom" is. A log might as well be a spinning cursor or any other animation.

It's invaluable from a troubleshooting perspective, though. "Hmm, it always seems to get stuck when installing this particular package"

Re: Progress bars still lie

#144

Post by eru »

admax88q wrote: post #127
kazinator wrote: post #108

Earlier quoted context omitted.

Complex flows can be represented by a tree control full of checkboxes that tick off for things that are done, which can be hidden behind a "show details ..." button next to a regular progress bar. If the users can see the detailed tasks, maybe they will be less ticked off by a jumpy progress bar.

If you can reliably break down your complex flow into a tree of checkboxes, you could just as easily render a truthful progress bar based upon how many sub tasks are done.

Yes, but that bar would still get hung intermittently whenever a specific task took a long time.

Re: Progress bars still lie

#145

Post by generalizations »

jbay808 wrote: post #128
generalizations wrote: post #117

Earlier quoted context omitted.

> As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung". This is an important point. "Lying" progress bars are still conveying essential information - that the installation is progressing and isn't frozen. I remember from my days working with W98 and early Ubuntu versions, one of the most important bits of information coming from progress bars was whether or n…

I've seen Google display progress bars showing that my page is loading, even when I've totally lost internet connection and I know it will never load. The progress bar goes as something like 1-e^-t, so it just asymptotically approaches 100% but never gets there. When it's that kind of lie, I don't think it's conveying any essential information.

Totally agree. I was rather intentionally using examples from more than a decade ago, where I was using the progress bar to observe whether or not the whole system was hung.

This was back when my best computer had a 500 MHz CPU and 512 MB of RAM.

Re: Progress bars still lie

#146

Post by cgriswald »

yellowapple wrote: post #143
kazinator wrote: post #135

Earlier quoted context omitted.

Problem with just logging the progress is that the user has no idea where he "bottom" is. A log might as well be a spinning cursor or any other animation.

It's invaluable from a troubleshooting perspective, though. "Hmm, it always seems to get stuck when installing this particular package"

This is the most infuriating part of progress bars to me. When it hangs I don’t even have a jumping off point for Google. I can only search “foo hangs during install” which almost always results in issues that are not the problem I’m experiencing because usually the most common reason isn’t the reason the majority of the time. “Foo hangs during ‘reticulating splines’” usually has far more useful results.

Re: Progress bars still lie

#147

Post by cgriswald »

0xfeba wrote: post #109
paxys wrote: post #74

Progress bars are something that have been researched and iterated on for decades now, and the overall sentiment is pretty clear – users like seeing numbers go from zero to a hundred while they wait. It doesn't matter if they aren't always accurate. Replacing them with a static "processing" message would absolutely increase user confusion and dissatisfaction with loading times. A while ago we put in a lot of engineer…

I bet $100 Netflix does the same. From my "experiments" during outages, it seems to show you a timer based progression from 0-25% no matter what, while it waits for stuff to queue/load properly, then it takes off to 26-100% in short order. So when it Netflix is up, it slowly climbs 1-5% then rockets to 100% and plays. When it's slow, sometimes it goes to 15%, then rockets up. When it's down, it reaches 25% after 12.5…

When my internet connection is down I get 99% sometimes from Netflix. I typically use the PS4 client so maybe that’s the difference.

Re: Progress bars still lie

#148

Post by wolrah »

news_to_me wrote: post #41
fgdelcueto wrote: post #13

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.

A progress bar should not indicate progress over multiple tasks — a segmented progress bar is better, or a series of spinners, or just a single spinner for the whole set. A progress bar should measure exactly one metric, where the total is known.

Exactly! The biggest problem with most progress bars is that they tie together multiple unrelated things that aren't even measured in the same way to a single indicator.

If there are multiple independent tasks, give me multiple independent indicators of their state. Multiple instances of the same class of task can of course be grouped, you don't need to list every file copy independently, but a file copy and an external dependency installer shouldn't be two stops on the same progress bar.

Re: Progress bars still lie

#149

Post by _carbyau_ »

These progress bars lie because they don't represent what the user thinks - either intentionally or from poor UI design.

I like MS Windows 10 "file transfer over a network" progress bar (though the pause button seems iffy...). The "hopes and dreams" simple progress bar is labelled factually and can't be accused of lying. And more information is available upon request and is simply factual.

A lot of work for a simple case of transferring files though. Much easier to default to the boring progress bar and some 0% to 100% assumptions to abstract things away so the "dumb user" doesn't have to worry... (NOTE: I hate the seemingly persistent concept of "dumb user" that so many people have.)

If your users have worries about your application performance to the extent that you are required to address them, then 90% of the time a dumb progress bar isn't the full answer. It may be an answer that makes management or user testing groups happy, but perpetuates the lie the article addresses.

Edit: snipped crap and added caveat note.

Re: Progress bars still lie

#150

Post by lanternfish »

yeetman21 wrote: post #99
jrochkind1 wrote: post #79

Earlier quoted context omitted.

It's worse. They seem to be intentionally slowing things down to make it look like the software is somehow "working harder" because to some people it justifies the high price. A progress bar that takes 5s or more to complete for an operation that actually takes under a second.

People are willing to pay more for meals eaten with heavier silverware

This sounds like it would be correct, do you know where I can find a source?
Post reply on HN