Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the Progress Bar Is Lying to You

popularmechanics.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: Why the Progress Bar Is Lying to You

#11

Post by bdunbar »

ComputerGuru wrote: post #6

Very, very interesting piece. At my previous job, I spent perhaps an entire month (plus all-nighters) working on a progress bar for the restore page of a backup program. The catch was it was a multi-stage process, and we wanted one and only one bar to represent the progress as smoothly as possible. It's by far one of the most deceivingly difficult problems I've worked on. If anyone cares for more info, this is what t…

a progress bar for the restore page of a backup program

Maybe I'm unusual. Aside from tar'ing data to tape on elderly 'nix machines, years ago, nearly all of the backup / restore jobs that I've done have been for work - tape libraries, dedicated servers, etc.

I don't _care_ about progress bars, accurate or not. I'm not going to watch a nifty GUI screen for hours - kick off the job, give me an estimate, notify me when done.

People really care enough to make it an item worth that much skull sweat? Weird.

Re: Why the Progress Bar Is Lying to You

#12

Post by bdunbar »

Irrelevant Digression:

The niftiest progress bar I've ever seen wasn't a progress bar.

It was a little morality play.

As the game installed a dinosaur slowly bounced across the installer window and _ate_ a hapless user .. who didn't send in his registration card.

Still remember that, seventeen years later.

Re: Why the Progress Bar Is Lying to You

#13

Post by sukuriant »

bdunbar wrote: post #12

Irrelevant Digression: The niftiest progress bar I've ever seen wasn't a progress bar. It was a little morality play. As the game installed a dinosaur slowly bounced across the installer window and _ate_ a hapless user .. who didn't send in his registration card. Still remember that, seventeen years later.

Unfortunately, Atari owns a patent on little games loaded for someone to play while a larger bit of data is being loaded.

Re: Why the Progress Bar Is Lying to You

#14

Post by ComputerGuru »

bdunbar wrote: post #11
ComputerGuru wrote: post #6

Very, very interesting piece. At my previous job, I spent perhaps an entire month (plus all-nighters) working on a progress bar for the restore page of a backup program. The catch was it was a multi-stage process, and we wanted one and only one bar to represent the progress as smoothly as possible. It's by far one of the most deceivingly difficult problems I've worked on. If anyone cares for more info, this is what t…

a progress bar for the restore page of a backup program Maybe I'm unusual. Aside from tar'ing data to tape on elderly 'nix machines, years ago, nearly all of the backup / restore jobs that I've done have been for work - tape libraries, dedicated servers, etc. I don't _care_ about progress bars, accurate or not. I'm not going to watch a nifty GUI screen for hours - kick off the job, give me an estimate, notify me when…

People really care enough to make it an item worth that much skull sweat? Weird.

Unfortunately, yes. The B2C desktop software market is such a cutthroat environment both in terms of what users expect and how much competition there is. It's an entirely different beast and the devil really is in the details. For some reason, bloggers, software review sites, magazines, etc. will really run desktop software through the mill and pick at the nitty-gritties in a way that they don't with webapps. Perhaps because with webapps the user experience is rather ephemeral and can be easily patched or fixed whereas with desktop apps everything has a very "final" feel to it.

Re: Why the Progress Bar Is Lying to You

#15

Post by alttag »

cbr wrote: post #10

Several people [1][2] are saying they think of the progress bar as bring about how much of the work (bytes downloaded, milestones completed) is done. It doesn't matter how you interpret the bar: what matters is what your users will think, and most people see the bar as indicating time. [1] http://news.ycombinator.com/item?id=3641046 [2] http://news.ycombinator.com/item?id=3641036

I agree ... mostly.

One of the examples was bytes downloaded. The reason I, and I suspect other users, interpret that as % downloaded is that in most interfaces (e.g., iTunes, Firefox, Safari), below the download progress bar, it says "XK of YK". (There is also an estimated time remaining, but it's typically not on the left side.)

In other cases (installs), yes it makes sense that the simplest interpretation is time, because that's what we care about when installing: how long until we can use the new shiny widget.

Re: Why the Progress Bar Is Lying to You

#16

Post by InclinedPlane »

Suggestion: use a succession of checkpoints (including start and finish) to keep track of overall progress. Then create a database of checkpoints along with timestamps (either from historical runs if this is a process that normally runs often for an individual user or from a few sets of lab runs if this is a one time thing like an installation). Now, calibrate the checkpoints to the expected position on an "ideal" progress bar given the historical data and present that to the user.

Re: Why the Progress Bar Is Lying to You

#17

Post by bo1024 »

sukuriant wrote: post #13
bdunbar wrote: post #12

Irrelevant Digression: The niftiest progress bar I've ever seen wasn't a progress bar. It was a little morality play. As the game installed a dinosaur slowly bounced across the installer window and _ate_ a hapless user .. who didn't send in his registration card. Still remember that, seventeen years later.

Unfortunately, Atari owns a patent on little games loaded for someone to play while a larger bit of data is being loaded.

What, seriously?? How the hell can you patent that??

Re: Why the Progress Bar Is Lying to You

#18

Post by krambs »

bo1024 wrote: post #17
sukuriant wrote: post #13

Earlier quoted context omitted.

Unfortunately, Atari owns a patent on little games loaded for someone to play while a larger bit of data is being loaded.

What, seriously?? How the hell can you patent that??

I would love to see that patent. I have a hard time imagining it would be enforceable.

Re: Why the Progress Bar Is Lying to You

#19

Post by r00fus »

InclinedPlane wrote: post #16

Suggestion: use a succession of checkpoints (including start and finish) to keep track of overall progress. Then create a database of checkpoints along with timestamps (either from historical runs if this is a process that normally runs often for an individual user or from a few sets of lab runs if this is a one time thing like an installation). Now, calibrate the checkpoints to the expected position on an "ideal" pr…

I had a similar problem with a customer that wanted a smooth progressing progress bar for periodic sync process where I had no idea how many actual entries were being sync'd on any given run (the cost of finding out == cost to sync)... the number was almost always more than the previous time.

So what I did was simply calculate how long the previous run took, add 10%, use that as my new baseline, and show progress based on the percentage between. Often this would mean the progress bar went straight from 93% to complete - but this was preferred (better than stalling at 100% for minutes at a time).

Eventually we automated the sync process, and the customer was happier looking at the occasional exception report instead of a progress bar.

Re: Why the Progress Bar Is Lying to You

#20

Post by tzs »

Two things I've half seriously considered if I ever need to do a progress bar:

1. Make the errors amusing to the user. For instance, if the operation goes over the estimate, go ahead and fill the progress bar to 100%. Then pause a second, and act embarrassed. Change the progress text to something like "Uhm...err...well, this is a bit embarrassing...", then go one to explain it's taking a little longer then expected.

Then say something like "OH MY GOD! THAT SPIDER BEHIND YOU IS THE BIGGEST I'VE EVER SEEN!!!". While the user is presumably turned around to check out the giant spider, drop the bar back to 80% or so, and pretend nothing ever happened.

2. Report progress bar inaccuracy back to the server, which can look and see if there thing is being consistently off in one direction and make a correction factor available to subsequent users of my software.

Might also stats to the user at the end of the operation, telling them things like "This progress bar was off by 10%. The average user's progress bar was off by 20%. Congratulations! Your computer was more reliable and consistent than average!"

Post reply on HN