I like a good UI as much as the next guy, but its not a layer I naturally strive to spend time on. I like simple, functional interfaces that work; if you want something with rounded corners and slick animations I might not be your man. But there was something that caught my eye about the paper Rethinking the Progress Bar, and it turned out to be some pretty interesting research.
We strive, as developers, to produce accurate and linear progress bars, and are constantly annoyed by inconsistencies and hiccups in that little blue meter. But since humans don't perceive time in a linear or consistent fashion, perhaps there is a way to hack a progress bar so that it appears faster to the human observer without actually being any faster. Turns out there is and it has to do with two phenomena called peak effect and end effect.
Peak effect means humans judge time based on peaks, or extremes, in the passage of time. Progress bars that pause seem to take longer to complete. End effect means humans judge time based on their most recent observations. Progress bars that slow down near the end seem to take longer. Naturally, a progress bar that speeds up near the end and never pauses will appear faster than a linear progress bar, despite the fact that both it and a linear progress bar might take the same time to complete.
The research was pretty cool and involved 8 different algorithms to drive a progress bar. They found the fastest appearing bar was a rapidly, but smoothly, accelerating one, starting slow and gradually ending quickly. Specifically, the function was called Fast Power:
f(x) = (x+(1-x)/2)8
So now we should all hack our progress bar class to do this, right? Well, maybe not. The researchers conclude that stable, linear progress bars aren't good candidates for 'optimizing'. I'm not sure why, and I'm tempted to go ahead and do it. There are also other alternatives to hacking the progress bar... if you want to avoid stutters in progress (peak effect) you could have the progress bar cache and under-report progress during normal operation, and then replay the progress reserve during pauses. If you want to avoid slowing down the bar near the end (end effect) then you could arrange your processes so that slower, more inconsistent operations are performed at the beginning. This is attractive because humans are more likely to tolerate negative behavior at the beginning of the operation than the end. If a pause occurs, best to get it over with early.
Well I, for one, don't buy any of the 'alternative' garbage. It's time to go subclass JProgressBar and get me some faster applications!
(By the way, the paper is only 4 pages long and contains fancy color graphs. It's an easy read, go check it out!)
Thursday, April 10, 2008
Rethinking the Progress Bar
Subscribe to:
Post Comments (Atom)
6 comments:
While I think you have some good ideas, I disagree with the comment in the end of your article that people are more likely to tolerate delays early in the downloading process.
I think the opposite is true. People are more likely to accept late delays because: (a) people may see early delays as errors and try to refresh, restarting the process; and (b) however slight it is, some visual "progress" invests people more heavily in the eventual outcome.
Interesting idea to under-report progress. I think Apple has found an interesting solution, too: their progress bars have animated stripes that make it look like it's moving forward even when it's completely still.
What drives me crazy is that many progress bars don't show progress: they reset themselves to zero every so often, so as a user I have no idea where I am in the process.
I wish we could get the message out to all developers to make meaningful progress bars. .
-alain
The key to this article you refer us to read is that the study/experiment was based on 5.5 second progress bars. As the authors corrected identified, this experiment needs to be evaluated on longer times, that reflect more real world conditions. Activity/Work sampling techniques could be used to do a mutiple regression analysis in order to better fit the type of progress bar to used based on your assumed time to complete the process being tracked by the progress bar.
I'm not a programmer, but I also would ask one question - doesn't the hardware have an impact which would have a large effect on the progress of software installation?
Has anyone ever observed the progress bars on minclip.com? They've always seemed logarithmic to me. When the text says 50%, the bar's well past the half-way mark; but when it says 80%, it's only marginally past 80%. It's like their growth rate decreases with progress so that even a small initial change throws it a large distance, but this is compensated by comparatively smaller changes towards the end.
Post a Comment