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

101–110 of 232 posts

Re: Progress bars still lie

#101

Post by eyelidlessness »

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 didn’t implement one but a former employer did, and [consults my exit agreement] the only thing I can say is they got complaints about long running processes that depended on third party data sources that were so unpredictable that having a colored bar gradually fill up a colorless bar made people stop calling so much, even if it didn’t convey much information.

Re: Progress bars still lie

#102

Post by magicalhippo »

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.

Back in Windows 3.11 days, I noticed a patter with installers. Their progress bar would go steadily up for quite a while, and then suddenly spend 3x as long on just one or two percentage points.

It didn't take me long to realize that the progress bar measured bytes written to disk, but when it was seemingly "stuck", it was creating a lot of small files.

Instead of bytes written, what I really cared about is "how done are you?" and that would have been better represented by a function of both number of files created _and_ bytes written. I don't think the weighting of those two had to be very accurate to be a big improvement.

Re: Progress bars still lie

#103

Post by laumars »

dkersten wrote: post #46
canadian_tired wrote: post #2

Progress bars are great when they convey meaningful information... sometimes it's nice to know if you have time to grab a coffee, or actually eat lunch. In my experience (when having to supply said bars) is that they serve primarily to tell the hapless user that things are still happening. In other words, the actual number is not important...what is important is real feedback that things are still happening and it's…

> the actual number is not important...what is important is real feedback that things are still happening Absolutely agree, but then, don't make it a percentage progress bar. Make it one of those "amount unknown" bars, or better yet, a spinner or game-like loading screen. Something with movement that tells me things are happening. Don't pretend to know "how done" it is if you don't know.

The web has ruined those feedback widgets for me. Now every time I see one of those spinners I think “oh look, a gif that will keep spinning even if the process I’m waiting on has failed”.

Re: Progress bars still lie

#104

Post by kortilla »

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

And slower service to boot!

Re: Progress bars still lie

#105

Post by eyelidlessness »

SulfurHexaFluri wrote: post #57
thesuitonym wrote: post #37

Earlier quoted context omitted.

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?

People love to see progress rather than start to finish speed. Its why getting stuck in traffic is frustrating while riding a bike is not even if you take longer overall. A blank page for 2 seconds is worse for the average user than a UI template instantly and 2.2 seconds of content filling.

This is why there’s an ever evolving art of progressive/lazy image rendering. There are several techniques that involve populating a blurry or even polygonal version of an image that eventually resolves to the real image. The ultimate payload is larger, and the time to render is greater, but faster UX gratification is more satisfying.

This reminds me of a counterpoint to my top-level comment of how frustrating Apple’s progress bars are: way back in the early OS X days, they did user tests that showed people respond better to longer running progress disclosure than shorter running real progress. So they literally baked a delay into the OS X boot process that would make booting take longer but show a more predictable progress bar.

Re: Progress bars still lie

#106

Post by jessriedel »

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…

Lying often reduces complaints. This doesn't mean users like being lied to, it means they don't know they are being lied to.

Re: Progress bars still lie

#107

Post by JeremyBanks »

jessriedel wrote: post #106
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…

Lying often reduces complaints. This doesn't mean users like being lied to, it means they don't know they are being lied to.

Users aren't being fooled here. People learn that progress bars aren't accurate, and things like the author mentioned, "when it gets to 75% it will really be done".

Re: Progress bars still lie

#108

Post by kazinator »

paxys wrote: post #87
quacked wrote: post #83

Earlier quoted context omitted.

As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung". I think the best option is simply X/Y bytes downloaded, like Blizzard does on WoW patches. The fraction indicates how much is left to download, and the rate of the numerator changing informs how quickly the download is going.

You're bringing up the easiest use case though. Most complex flows cannot be easily expressed by a single determinable metric.

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.

Re: Progress bars still lie

#109

Post by 0xfeba »

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.5s or whatever it is, then sits there forever/shows an error message.

Re: Progress bars still lie

#110

Post by theamk »

canadian_tired wrote: post #7
ktpsns wrote: post #3

Progress bars are way better then spinners: They communicate an time/duration estimate, at least. Even in the case it is bad, this is always better then just showing a spinner, indicating that some system is doing something. Spinners got omnipresent since the Web 2.0. Nowadays for me they are almost always a sign of lazy programmers with an "that's good enough" paradigm.

Progress bars that lie are seldom better than spinners. I suppose what is needed is an informed spinner. It would have to be visually different than a bog-standard spinner. I have seen many cases where the numbers on the bar were entirely made up...but they seem to keep people happy. The illusion of progress maybe?

sure, but even the wrong numbers can be useful because they provide some information.

like the "75% max" example from the post. Does it lie? yes. Can it be useful? very much, it is pretty easy to compensate.

Post reply on HN