Progress Indicator

• Countdown timer on a microwave oven
• Progress bars in desktop GUI software
• The percent-complete message in a Web browser during a download

Problem:  How can the artifact show its current state to the user, so that the user can best understand what is going on and act on that knowledge?

Forces:

• The user wants to know how long they have to wait for the process to end.
• The user wants to know that progress is actually being made, and that the process hasn't just "hung."
• The user wants to know how fast the progress is being made, especially if the speed varies.
• Sometimes it's impossible for the artifact to tell how long the process is going to take.

Animation is often used to good effect in this pattern; motion draws the user's attention, and its cessation implies a new relaxed, stable state of being ("the process is done, so you can relax now").  Sound can also be used this way, for the same reason.  Be subtle, though, and be aware of the importance of the process relative to the other things demanding the user's attention.  For example, Background Posture artifacts sometimes shouldn't have attention-demanding Progress Indicators at all.  Helper Posture artifacts probably should, and so should Sovereign Posture artifacts if waiting on the process is suspending all other activity.

Resulting Context:  A user may expect to find a way to stop the process somewhere spatially near the Progress Indicator.  It's almost as though the Progress Indicator acts as a proxy for the process itself, in the user's mind.  Go with it, and put a "stop" action near or on the Progress Indicator if you can.

Notes:  A story about the use of sound as a Progress Indicator:  I once had a workstation that had a uniquely noisy disk drive, which worked wonderfully (if unexpectedly) as a Progress Indicator for a lot of my software development activities.  It wasn't too loud, fortunately, but it did have distinctive sounds for different classes of activities -- one for copying a large file, one for compiling, and so on.  If I was waiting for a long compile to finish, I could work on other things without having to watch my monitor; the sudden cessation of the sound told me it was done, in a nice subtle way.

(Also, if my workstation hung or started behaving abnormally, the sound it was making often gave me a clue what was wrong.  I got very familiar with the sound and timing of an 8-meg core dump.  But that has little to do with Progress Indicators...)

Here's another story, from Brad Appleton:

"Back in 1989 when I worked on a commercial version control tool for the PC, a common customer complaint was that the system took too long to start up (almost a full minute - keep in mind this was still in the days of 640K ;-).

We decided it would take some time to profile the system and ferret out the bottlenecks. While we were doing that, we threw in a quick "appeaser": instead of showing nothing while starting up, we decided to show a display window with the product name/logo above a small status area that printed out each major initialization action that was taking place (e.g. "loading xxxxx" and "verifying yyyy"), much in the same way that Emacs does when it starts up.

Well - after we did the above, the complaints about long start-up times stopped.  We hadn't made anything faster at all (we were still trying to work on that), but we had satisfied their need to have some clue as to what's happening and when it might be finished." (From personal correspondence, dated August 16, 1998.)

Copyright (c) 1999 by Jenifer Tidwell.  All rights reserved.