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

171–180 of 232 posts

Re: Progress bars still lie

#171

Post by cbhl »

kazinator wrote: post #108
paxys wrote: post #87

Earlier quoted context omitted.

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.

A tree is insufficient for flows at $dayjob, you need a directed acyclic graph to handle fanout/parallelism.

For which a visualization exists internally, but every time someone decides to "fix" the progress bar problem they do a one-off analysis and only wire up the three biggest steps to the bar.

Re: Progress bars still lie

#172

Post by yyx »

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.

Had problem when GUI closed after trying to install a package. No error, no logs. (or was it defaulting to the normal state with install button and no logs, I don't remember)

Found out about package conflict only after running apt from the terminal.

Re: Progress bars still lie

#173

Post by sildur »

A long long time ago, I was testing a web site. I accidentally suspended the server. Mozilla's progress bar stopped right there while internet explorer kept going, progressively slower, until the browser threw an error around 98%. Also, let's not forget windows file download/copy estimations. Lying progress bars are at least as old as windows.

Re: Progress bars still lie

#174

Post by alkonaut »

Disagree with the gist of the post. Completing after 75% doesn't mean completing after 75%. It means the developers had to estimate the time taken for 2 subtasks (e.g. uploading and committing via an API request) and said that uploading was likely 75% and the commit step 25%. What happens is likely that the final 25% was so fast it seemed instant.

The options are: 1) don't show progress. Show a marquee, as to not lie. This is terrible. Please don't do this. 2) Show two phases. E.g. the first phase progress runs slowly from 0-100 and the second one runs instantly from 0-100. 3) Guess better. Such as do it adaptively. The expected time for phase N is estimated from data (e.g. last time for commit phase, or from a bandwidth estimate from last upload times the file size). 5) Add a minimum phase time so that instantaneous completion takes e.g. 50ms, so people get time to see the completion at 100%. 4) Do nothing. No one expects progress bars to run linearly.

There are so many good options that are better than "don't show progress, only show activity". Even the do nothing/status quo alternative is much better than no progress bar.

Re: Progress bars still lie

#175

Post by finishtime »

the second suggestion where they estimate the time to completion in a matter of comparing the time other uses had to wait. They could test it out on a specific scale and that's practically it. You don't need to do anything difficult, just log the time it takes and then show the average.

Re: Progress bars still lie

#176

Post by eru »

karottenreibe wrote: post #164
eru wrote: post #144

Earlier quoted context omitted.

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

I don't know whether it _will_ be any different, but there was some speculation about that:

> 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

#177

Post by chrismorgan »

> Every time I upload a lecture video to YouTube, it goes back-and-forth from "0% processed" and "100% processed", repeatedly, until it is actually done. I've never seen it say any other number.

I’m uploading a couple of 50–100m videos each week, and a lot of the time it stops off briefly at 95%, 99% or both before reaching 100%. (Also, “100% processed” comes before “finished processing” or “SD processed, processing HD”.) I’ve never seen it go back down, only ever upwards.

Re: Progress bars still lie

#178

Post by nextlevelwizard »

>And yet, every single photo and video that I export from Dropbox finishes at 75%, regardless of how big the file is.

What does he expect? That larger files go over 100%? Who knows how the progress bar is calculating, but the assumption that every file shouldn't finish at the same percentage just seems very odd.

Re: Progress bars still lie

#179

Post by rini17 »

generalizations wrote: post #121
hutzlibu wrote: post #120

Earlier quoted context omitted.

Well, not necessarily, if the GUI with the progress bar and the installation or whatever are on seperated threads.

That's true on the backend, but it doesn't help the end user much, since they don't know that.

Heh, I've imagined a message like:

"Your task has started and is processing in the background where it can't be observed. Please wait."

[OK]

Re: Progress bars still lie

#180

Post by tonyedgecombe »

lanternfish wrote: post #150
yeetman21 wrote: post #99

Earlier quoted context omitted.

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?

Charles Spence at Oxford University has done a lot of work on this. It turns out just changing the colour of the plate impacts peoples perception of food.
Post reply on HN