Do you ever create fake progress bars?

Question

Do you (and would you) ever create progress bars that are just there to keep the client happy and moves without reflecting the true progress of the program? I remember reading about this somewhere, and am wondering if there are other developers that do it too...

Answer 1

This is quite common in certain applications, especially when you're querying a server whose response time may vary by a few seconds. The game EVE Online does this, for example, when logging in.

However, there are only limited instances when this is a good idea. Try to think about why you want to put the progress bar there. Why do you need to deceive the user? Are you abstracting away some piece of technical detail that they don't care about (e.g. variable server response times) or are you actually hiding important information?

Always take care when providing an inherently incorrect mental model.

Answer 2

It's like in Internet Explorer, when you are stopped on a break point, yet the browser magically knows my progress in debugging, and continues to progress further. Magic...Magic...Magic...

Answer 3

Yes I do, though I wouldn't call them fake - they've been present on applications for as long as I can remember. I've often set them to rotate (fill then empty, rather than progress from one side to the other).

If you really don't know how long a task is going to take, consider just a wait indicator or spinner (see recent Microsoft VS or MSSQL installers for examples), an elapsed time indicator, or some description of what's actually happening. An installer might list files as they're being copied, for instance (NSIS installers do this).

Usually, users will be happy with an indication that something's happening, and your program isn't hung.

Answer 4

Both Microsoft and Apple define “indeterminate” progress bars to be used when progress cannot be estimated. If you’re making a web app, copy that convention or use some other cyclic animation (e.g., a throbber). Please don’t use completely fake determinate progress bars. Users will eventually catch on that determinate progress bars don’t mean anything, which ruins using them for the rest of us.

How accurate does your estimated progress have to be to use a determinate progress bar? Microsoft suggests using a determinate bar even if progress can only be roughly predicted (something which we as users probably can tell). Apple in contrast suggests using determinate progress bars only if you can predict progress “accurately.” My take is this: reserve determinate progress bars for when you can accurately estimate completion time to within about 30%. Use some other means of showing progress (e.g., identity of the current step in the process) if accuracy is worse. Progress indicators serve two purposes:

• Assure the user that the app isn’t stuck or crashed.

• Let users estimate when they can return to work.

Thirty-percent accuracy is sufficient for the second purpose. A user can look at a determinate progress bar and say, “It’s taken about minute to go a little bit; I’ll check back in half an hour,” or “I have a meeting in 15 minutes -no way will this be done in time.”

For the first purpose, any kind of real indication of a change is sufficient. A user may not know what “Aligning warp coils” means, but they know that before the program was “Charging flux capacitor,” so they know the program is making some progress.