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

161–170 of 232 posts

Re: Progress bars still lie

#161

Post by Agentlien »

If you're making games targeting consoles there are usability requirements. Any loading screen which takes more than a few moments needs at least a spinner to indicate it's not stuck and if it may take more than a certain time (30s? 1 min?) you are specifically required to use a progress bar. But there's no requirement on how accurate it is.

While working on a popular AAA franchise at EA, we had loading screens which were sometimes really long and depended mainly on your connection speed. We estimated a worst case time for clients with slow Internet but not slow enough to time out and then made the progress bar driven by a timer from zero to this time.

Even knowing how it worked I repeatedly found myself intently staring at the loading bar.

Re: Progress bars still lie

#162

Post by rasz »

generalizations wrote: post #145
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.

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.

There was never a time when

>best computer had a 500 MHz CPU and 512 MB of RAM

500 MHz cpus started showing up in servers with 21164 in 1996 in boxes maxing out at 2GB ram, and on desktops with 1999 Pentium 3 plugged into 1998 chipset (440BX) already supporting 1GB.

Re: Progress bars still lie

#164

Post by karottenreibe »

eru wrote: post #144
admax88q wrote: post #127

Earlier quoted context omitted.

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.

How is the checkbox thing any different? If one task blocks progress, the tree also doesn't update

Re: Progress bars still lie

#165

Post by zzo38computer »

My suggestion is: Display a plain number (rather than a percentage); but only display the percentage if the total required is actually known too. For example, if you need to download a two gigabyte file, and the file size is already known, then it can calculate the percentage, but if the file size is not known, then it should only display the total number of bytes downloaded.

This is separate from time estimations, though. The progress may not run at a uniform speed, which is OK; just mention the percentage of progress if known, or a plain number if not. If there are multiple steps, display the progress for each individual step, and document what the steps are.

In a few cases (e.g. hashcash), the progress is not known, so just a "spinning" indicator (or displaying a plain (non-percentage) number which just increases while it is executing) might be used instead.

Re: Progress bars still lie

#167

Post by Agentlien »

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…

At my first job we made training simulations. One day someone decided to do make our loading bar more accurate by splitting loading into several segments and keeping a local record of the average time to load each segment. The result was a smooth progress bar from 0 to 100. We were proud of it.

Years later I worked on a popular AAA franchise and we had replace our loading screen spinner with a progress bar due to console requirements. We simply estimated a worst case scenario and made the bar driven by a timer from zero to this number, smoothly speeding towards 100 when loading was done. People kept complaining that something felt off and it didn't seem reliable.

Re: Progress bars still lie

#168

Post by sujayakar »

are there any good composable programming abstractions for expressing progress in a system?

as an analogy, I really like RAII-based cancellation for futures in rust. dropping a future means the caller is no longer interested, and the sane behavior of cancelling all of the subfutures is the default. this seems simple at first, but dropping a single future may end up cancelling operations on other threads, freeing buffers, and so on, and the programmer profitably stumbles into the correct behavior.

so, it'd be nice for having a similarly composable abstraction for reporting progress in an asynchronous system. `Control.Monad.Progress`[1] just uses a float in [0, 1] to represent progress, and `NSProgress`[2] has a bit more going on but still requires the programmer to manually partition a parent task into its subtasks.

I'm not sure this is altogether possible, but I could imagine 1) a library for expressing the ground truth of where parts of a system are and then 2) a heuristic based layer above for turning snapshots of the system into time estimates and percentages working well.

[1] https://hackage.haskell.org/package/progress-reporting-1.0.0...

[2] https://developer.apple.com/documentation/foundation/progres...

Re: Progress bars still lie

#169

Post by kburman »

So what does a perfect progress bar would look?

Will it able to predict if my internet connection going up or down in next few seconds of starting a new download.

I think the current progress bar represent the task progress not the estimated time left and the author is looking for something that shows actual time left.

Re: Progress bars still lie

#170

Post by generalizations »

rasz wrote: post #162
generalizations wrote: post #145

Earlier quoted context omitted.

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.

There was never a time when >best computer had a 500 MHz CPU and 512 MB of RAM 500 MHz cpus started showing up in servers with 21164 in 1996 in boxes maxing out at 2GB ram, and on desktops with 1999 Pentium 3 plugged into 1998 chipset (440BX) already supporting 1GB.

I didn't say I wasn't a broke kid at the time. ;)
Post reply on HN