Name: The Placebo

Context:

Some long-running processing is occurring in your program. You really have no idea how long this event is going to take, but you want to keep the user as happy as possible while it is running.

Forces:

• Users are happier if they can see that something is happening
• A progress-meter spinning in its 'indeterminate' state will placate the user for at most fifteen seconds, after which they will begin to mistrust it
• Users do not expect progress-bars to progress evenly
• Telling a user exactly what is happening to cause a delay is rarely helpful

Therefore:

Estimate how long your long-running process should take. Add a fudge-factor, just in case. Have a progress-bar that runs more-or-less on that time-table until it reaches around 90%. Unavoidably, if it takes longer than this you will have to stick at 90%, but by then the user probably won't cancel the action until at least twice the time you initially budgeted for the action to take.

Educate your help-desk as to the real meaning of "Well, it goes OK for a few minutes and then freezes when it's almost finished..." but ensure they don't tell the user what's really going on, on pain of death.

If there are identifiable milestones along the way, you can incorporate these milestones into your placebo to make it look more accurate.

Note: Users are used to progress-bars that accelerate and decelerate seemingly at random. It could be that a progress-bar displaying this behaviour is more likely to be believed than one that progresses smoothly.

Examples of Use:

Internet Explorer applies a variant of this pattern during DNS lookup and initial TCP/IP connection (the progress-bar creeps forward from time to time, even though no progress is actually being made). This is in direct (and I believe very deliberate) contrast to Netscape Navigator, which would spin its progress-bar in indeterminate mode until the connection was established.

Most GUI installers seem to implement this pattern as a matter of course.