An app should never show the user a progress bar, fill it up, only to reset it and make them watch it fill up again.
Two-thirds done—or is it?
An app with a progress bar that resets will fail to deliver on the promise it has made. The app is saying, "Almost done! Almost done! Just a second more!", then saying, "Just kidding! There's still more." The user loses faith the process is anywhere near completion. For all they know, the progress bar is going to reset again, and again, and again. If a progress bar can start all over, there’s practically no value in having a progress bar in the first place. It's more honest in such a case to use a progress animation instead of a progress bar; at least that doesn't make any promises about when an operation will finish.
When an app has back-to-back operations that can take a long time, incorporate the progress for those operations into a combined progress bar. This can be done, for example, by assigning arbitrary percentages based on expected results. If the first operation usually takes about three times as long as the second, then the first operation can be defined to fill up 75% of the progress bar and the second operation to fill up the remaining 25%. This can result in a change in progress bar speed, but this still allows the user to derive more value from the progress bar, and maintains a sense a progress.
The point of having a progress bar is twofold:
1) to know something is still happening and that the machine hasn't hung.
2) to have an idea when a lengthy operation will finish, so I know when I can continue the task which requires the operation to finish.
An "estimated time to completion" countdown serves these purposes much better than a progress bar offering an uncalibrated "percentage complete" number.
Just for fun, it could include variable length suggestions like wait a minute, make a cup of coffee, take a nap, go to bed...
Posted by: Mark Bramley | July 12, 2005 at 10:04 AM
First off, let me say that I love this blog. These are all good solid suggestions, and very clearly written. Thank you!
On this particular point, I've always felt that the best progress bar I've ever seen was the spinning globe in Internet Explorer. It doesn't communicate any idea of length, because it doesn't know any. But it never lies to you! And it's actually quite easy to duplicate with a more thematically appropriate animation.
I like the other suggestions, though! "Go get lunch, this one's gonna take a while!"
Posted by: Chaz Haws | September 05, 2005 at 08:42 AM
Thank you for this blog! Nice work and I'm hoping for others to pop up in the near future.
Progress bars definitely have their limitations. There are times, however, when an operation could take a very long time. For example, if the user is requesting tons of data from a database. Currently, there is no progress information given back from the database (it could take forever if it wanted to). How do you recommend communicating this to the user, without completely freezing the UI?
Posted by: Scott Saad | October 03, 2005 at 09:59 PM
With my interfaces I either show one progress bar per operation (rather than start the progress again for each operation), or say "Step 1 of 3" or whatever above the bar. For really fast operations I prefer the second, because 1 progress bar refilling 3 times in under 5 seconds makes the whole operation feel really fast.
Posted by: Max Howell | December 07, 2005 at 01:50 PM