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

131–140 of 232 posts

Re: Progress bars still lie

#131

Post by voodootrucker »

Not only do they lie, but they are often poorly implemented. I was pairing with a coworker, and a download was taking forever despite his fast speed tests. (I think this was chocolatey) and we tried again after 15 minutes of waiting with `--no-progress` and the download finished in seconds.

We joked that it must take a lot of work computing those VT-100 characters and went back about our business, and I swear to god, an hour later the exact same thing happened in a completely different piece of software.

I can't believe the art of software development has regressed so much in my lifetime.

Re: Progress bars still lie

#132

Post by ploxiln »

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.

IE6 also did this back in the day, it was infuriating.

Re: Progress bars still lie

#133

Post by tsjq »

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…

yes. i think this is done by the Ubuntu software updater app.

Re: Progress bars still lie

#134

Post by cgrealy »

So, the problem with progress bars is that they are rarely accurate, and the problem with static "processing..." messages is that it's imposible to tell if the app is frozen.

How about an indeterminate progress bar, but it has a button you can click that tells you the app hasn't died? :)

Re: Progress bars still lie

#135

Post by kazinator »

fomine3 wrote: post #116
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.

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.

Re: Progress bars still lie

#136

Post by denkmoon »

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.

Even worse than not conveying information, it diminishes your user's trust in your product if they realise the progress bar is bullshit.

Re: Progress bars still lie

#137

Post by srgpqt »

xwdv wrote: post #123
hutzlibu wrote: post #122

Earlier quoted context omitted.

"After feedback from design we hard-coded it to a steadily increasing bar regardless of actual progress, and the complaints all stopped immediately. " Are you talking about progress bars, that go steadily up to 99 or 100% and then stay there, until the actual progress is done? They can cause big frustration, too ...

The approach for this is to simply restart the bar from 0% and display some bogus message implying it is now doing another task. Always keep moving.

Reticulating Splines

Re: Progress bars still lie

#138

Post by Inityx »

news_to_me wrote: post #61
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 in…

I'm so sick and tired of seeing spinners that keep spinning, even after the process failed; this is an epidemic in web apps, where failures are often a bit too graceful and application state is silently corrupted.

Re: Progress bars still lie

#139

Post by DaiPlusPlus »

deathanatos wrote: post #129
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…

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.

Re: Progress bars still lie

#140

Post by DaiPlusPlus »

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

I prefer cutlery that doesn’t easily fall out of my hands when eating though.
Post reply on HN