The role of the progress bar on the web
As software migrates from the desktop to the web, we are dealing with more complex applications all the time. It is important that users constantly experience a sense of progression and efficiency as they use our products. One way to keep the user feeling engaged while waiting for a process to complete is the progress bar.
In this blog post, we define four criteria of a good progress bar, examine the difficulties in implementing one, and look at when we should and should not use them.
The four criteria of a good progress bar
- Accurate – watching a bar fill up gradually only to chug to a halt at around 90% can infuriate all but the most Zen. Worse still on the hair ripping scale are bars that fill up, only to empty and begin anew!
- Responsive and smooth – the bar should be updated regularly to show that things are still working. This means that, on the web, we should update progress bars via Ajax rather than hefty page reloads. Research shows that a linear, consistent progress increase is better than the bar jerking around like a malfunctioning robot dancer.
- Precise – the bar should show an estimate of time remaining, and perhaps other data such as percent or file size remaining so the user knows if he or she should start any long books in the interim.
Examples of good progress bars
Let’s take a look at some progress bars that satisfy our criteria.
Download managers have a pretty simple job – essentially, bytes downloaded divided by total bytes. Firefox’s download manager, as pictured here, is accurate and provides precise metrics (speed, amount downloaded, estimated time remaining, percentage).
Plain old WGet may be a command line dinosaur to some, but it can teach the whippersnappers a thing or two – it shows similar information to Firefox’s download manager.
Because most Flash movies and games are a single file, it is possible to have a loading bar indicating how much of the movie has been downloaded embedded in the first frame. This provides a reasonable indication of how long the user has to wait.
Examples of bad progress bars
There are plenty of great examples in fiction, for example in the film Office Space when Peter’s progress bar keeps resetting as he is trying to leave before his boss collars him. There are plenty of real ones that can be just as infuriating; here is an example of an old Mac progress bar from OS8. Note how the speed is inconsistent – there are jumps and pauses:
A progress bar is not appropriate for OS start-up (see The technical challenges to find out why); OSX simply shows a screen with the Apple logo and a spinner.
Static progress bars are sometimes employed on multipage forms. If the pages of such a non-linear form can be revisited, a progress bar gives a misleading indication: if you jump back to an earlier page and the progress meter goes down, this is discouraging.