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

211–220 of 232 posts

Re: Progress bars still lie

#211

Post by Unklejoe »

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…

This is because when I was growing up (Windows 95 era), it was normal for a computer to just completely freeze regularly. If I saw a static "processing", I'd assume the computer froze and would rip out the power after like 5 seconds.

Re: Progress bars still lie

#212

Post by Ruthalas »

TeMPOraL wrote: post #206
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…

Strongly agreed. One tricky thing, though. The few times I saw someone trying to implement the task count, it would sometimes be the case the count couldn't be determined beforehand! So I'd see progress reports like: 1/123 done.... 42/124 done... 45/2616 done... 68/98213 done... I think scandisk (or whatever the disk scanning utility that runs before Windows boots is called these days) was prone to such ever-growing…

Honestly, the example with the incrementing total, while not useful for estimating remaining time, conveys a lot of information. I'd be happy with that for processes that have an unknown number of steps.

Re: Progress bars still lie

#213

Post by dirtyid »

For short activities (less than a few minutes) I don't need the progress bar to be useful, I need it to be reassuring.

Any longer than that, reassurance comes from visual previews of what's happening, see vray preview windows for renders. Basically that feeling of shit getting done from watching laser and 3D printers do their thing.

Re: Progress bars still lie

#214

Post by jbay808 »

throwaway2245 wrote: post #192
jbay808 wrote: post #128

Earlier quoted context omitted.

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.

Will Google pick up the connection again when it's available? And could that theoretically happen at any moment? If so, it doesn't seem completely unreasonable to communicate in this way. (I agree it could be communicated better) The system is not quite hung, but it's not doing great.

I had disconnected my router, so I don't think Google was going to pick up the connection again.

At the very least, there's no sense in which the page loading (or map route finding, etc) was farther along at t=2 than it was at t=1 when the connection was removed, so for Google to be telling me it's making progress in that situation is a transparent lie.

Unless the information they're trying to convey with the progress bar is simply that "time is passing", which I'm well aware of.

Re: Progress bars still lie

#215

Post by woodrowbarlow »

quacked wrote: post #83
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…

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.

if you give numbers of any sort, users will try to mentally do the math to convert that to a percentage -- and at that point, you might as well give them a progress bar.

If you instead just show a description of the current task, users will want to know how many tasks are left. if you tell them how many are left, they will revert to thinking of it as an overall percentage.

i'm a fan of "checklists" that get ticked off as the process progresses; possibly with progress bars for specific tasks, if they have a straightforward way of measuring that (like % downloaded). but i almost never include an overall progress bar for a multi-step process. it keeps the user's focus on the current task, while still providing some information about what's to come.

Re: Progress bars still lie

#216

Post by gpvos »

jessriedel wrote: post #119
JeremyBanks wrote: post #107

Earlier quoted context omitted.

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".

First, no, as the other comments here attest, the end result of constant lying is that nobody trusts progress bars at all; if things reliably finished at 75%, progress bars would be easy, but they don't so they aren't. Second, that people soon get used to being lied to does not make lying OK.

I don't think you are in disagreement.

Re: Progress bars still lie

#217

Post by gpvos »

TeMPOraL wrote: post #206
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…

Strongly agreed. One tricky thing, though. The few times I saw someone trying to implement the task count, it would sometimes be the case the count couldn't be determined beforehand! So I'd see progress reports like: 1/123 done.... 42/124 done... 45/2616 done... 68/98213 done... I think scandisk (or whatever the disk scanning utility that runs before Windows boots is called these days) was prone to such ever-growing…

> split your process into a "planning" part and "execution" part if possible

Doing the scanning and the processing at the same time may be faster. It should be clear though when the total has been established and when it isn't yet.

Re: Progress bars still lie

#218

Post by deathanatos »

DaiPlusPlus wrote: post #139
deathanatos wrote: post #129

Earlier quoted context omitted.

UI toolkits include "indeterminate" progress bars. Back before AJAX spinners (really, a simplified form of indeterminate progress bars) took over, they were a blob that bounced back and forth, or scrolled left to right repeatedly, within the progress bar's trough. Sometimes, a barber pole. The good ones would only advance the animation so long as actual progress was occurring, so that a hung system was indicated by a…

The problem with AJAX spinners is that they’re often just GIFs or CSS animations that will keep on playing even if “the system has hung” (e.g. the AJAX request failed and there’s no client-side error handling logic, no retry, no error display, and no UI cleanup) so in that respect the situation now is worse than it was before.

Yes, I agree with that for the case of AJAX spinners. A lot of web software fails to handle errors (resulting in the AJAX spinner spinning on — I think we've all seen this all the time¹) and most don't connect progress events to the animation in any way. There's no reason web-based libraries couldn't provide utilities for that, other than they don't, the existing code is of poor quality, and the APIs that browsers provide don't really push one towards the high-quality solutions in any way (since you really have to either get this level of functionality from some sort of library, or build it yourself).

My point is that good UI is possible, there is even precedent for it, and that while we definitely need to do better perhaps with available APIs or tooling, that is not an excuse for the moral failing of lying to the user.

¹and I'd say that's even the mild case. A number of high-profile websites that encounter even edge cases — not even errors — just simply fail to render at all.

Re: Progress bars still lie

#219

Post by jessriedel »

gpvos wrote: post #216
jessriedel wrote: post #119

Earlier quoted context omitted.

First, no, as the other comments here attest, the end result of constant lying is that nobody trusts progress bars at all; if things reliably finished at 75%, progress bars would be easy, but they don't so they aren't. Second, that people soon get used to being lied to does not make lying OK.

I don't think you are in disagreement.

Neither of Jeremy Bank's sentences are relevant to my first comment if you try to contort their interpretation so they do not conflict with me.

Re: Progress bars still lie

#220

Post by quacked »

woodrowbarlow wrote: post #215
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.

if you give numbers of any sort, users will try to mentally do the math to convert that to a percentage -- and at that point, you might as well give them a progress bar. If you instead just show a description of the current task, users will want to know how many tasks are left. if you tell them how many are left, they will revert to thinking of it as an overall percentage. i'm a fan of "checklists" that get ticked of…

That works for completion status, but I don't think it works for task failure notification. Do you know of any clever way that reliably informs the user whether or not the process is frozen?
Post reply on HN