Linked by Thom Holwerda on Wed 5th Mar 2008 21:02 UTC, submitted by irbis
"Most software packages employ progress bars to visualize the status of an ongoing process. Users rely on progress bars to verify that an operation is proceeding successfully and to estimate its completion time. Typically, a linear function is applied such that the advancement of a progress bar is directly proportional to the amount of work that has been completed. However, estimating progress can be difficult for complex or multi-stage processes. Varying disk, memory, processor, bandwidth and other factors complicate this further. Consequently, progress bars often exhibit non-linear behaviors, such as acceleration, deceleration, and pauses. Furthermore, humans do not perceive the passage of time in a linear way. This, coupled with the irregular behavior of progress bars, produces a highly variable perception of how long it takes progress bars to complete. An understanding of which behaviors perceptually shorten or lengthen process duration can be used to engineer a progress bar that appears faster, even though the actual duration remains unchanged. This paper describes an experiment that sought to identify patterns in user perception of progress bar behavior."
Thread beginning with comment 303621
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:
2007-09-06
The best setup I've seen used is a two bar combination for current step and total progress. The current process bar can restart over and over as long as the total progress bar ticks along slowly with an accurate estimate of remaining time.
Someone could even do it as a pair of circles with total progress wrapped around process if they wanted to be different.
I agree fully on a single progress bar that starts over for each process step though; it's usless screen clutter that does nothing but tease the user.