Are We Nearly There Yet? – 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

1. 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!
2. 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. 
3. 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.
4. Appropriate – before using a progress bar, consider carefully whether it is appropriate, both in terms of User Experience and technical feasibility.

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.

Unusual progress indicators

This post shows a progress bar using lights. Sometimes a bit of quirky charm buys you a measure of clemency from your users. Breaking from the norm can be fun, provided it remains useful. On the web, a progress bar could be represented by something like a monkey climbing a tree, so long as it meets the 4 criteria.

 

 

Ridge Racer on the PlayStation dispensed with a loading bar altogether, instead offering the users the chance to play a few seconds of 80s shoot ‘em up Galaga. This was extremely well received and where appropriate can be a delightful little treat for users. Choice of game is paramount – it must be challenging, fun and quick.

 

 

The technical challenges

TVTropes has a page about progress bars in popular culture, which observes that “in TV and movies, all computer operations take an exact, known amount of time to perform, and all progress bars move smoothly at a constant rate”, something that doesn’t happen in real life. Some operations (like the download managers we’ve looked at) are relatively simple, but some are complex, or involve multiple systems. Let’s take a look at a couple of issues.

The Halting Problem (Turing)

Wikipedia defines the halting problems as “a decision problem which can be stated as follows: given a description of a program and a finite input, decide whether the program finishes running or will run forever, given that input.” In simple terms, in this context this means that it’s not possible, given a program, to determine programmatically when (or even whether at all) that program will finish running without running it. Therefore, estimations of computational problem time cannot be perfectly accurate. 

So, if we can’t monitor our processes progress with absolute accuracy, what can we do? One way to provide progress statistics is to use heuristics rather than programmatic calculation. To do this, run a given operation a large number of times and use the average time as an estimate. Of course, this is not perfect; sometimes operations, particularly those on the file system, take much longer than usual for one reason or another. Reddit has an interesting discussion of the topic.

Unpredictability

“Estimating progress can be difficult for complex or multi-stage processes” (Harrison et al, 2007)

On the web, we can encounter issues with latency. Consider an operation that runs like the one in this diagram. If we are trying to estimate the progress of the operation process as a whole, we have the following unknowns:

• Speed of JavaScript on the client’s machine - browsers vary in JavaScript execution speed. Processor speed, memory available, and the number of programs running can also have an effect.
• Speed of user’s internet connection
• Load on the load balancer
• Network traffic between the load balancer and the application servers
• Load on the application servers
• Network traffic between the application server and the database
• Load on the application database

With all these unknowns, a progress bar is perhaps not the best approach. Perhaps a simple animated “working” indicator would be better in this situation (see http://www.usabilitypost.com/2009/01/23/making-wait-times-feel-shorter/).

Lessons

Progress bars are best suited to long-running linear tasks and are not always the best way of providing information. What you’re trying to communicate is:

1. The application is not dead
2. The application is making progress
3. Some kind of indication of how long it’s going to take

Precision is worthless without accuracy; saying “52.24% done” is not necessarily better than saying “about half done” if it is not accurate – users can perceive precision as implied accuracy. In fact, it is often better to take Apple’s route and say “about 30 seconds remaining” – a temporal estimate is commonly preferred.

Perceived performance is more important than actual performance, as this article about perceived performance on Coding Horror describes.

Only provide a progress bar if you can provide accurate, precise estimates. If you cannot, then perhaps provide a list of tasks, such as this fragment from the Linux bootup. It shows a list of tasks being performed.  To the expert user, this is a good metric of how far through the process is, and to the rest of us, it at least shows that progress is being made.

Wrap up

Progress bars can be great, but for the sake of your users, only use them when you can meet the four criteria. If not, there are plenty of alternatives out there that might provide a better fit.

What do you think? Get in touch via the comments box below!