Estimating Remaining Time for a Progress Bar

Question

What is the best way to estimate remaining time for a progress bar?

In my case, it's a computing time, but I suppose this is a general issue of estimating the remaining time of a task in a user-friendly fashion.

Currently I'm using an estimated time based on percentage accomplished and using it to linearly estimate the time that remains. However estimation or load variation change will result in the time not decreasing anymore, or worse, going up rather than down.

I've been experimenting with "cheats" based on over-estimating the time initially, so the time tends to trend down in a more "friendly" way, under the assumption that people are happy if it ends earlier than planned, and unhappy if it ends later than planned.

Are there studies/experiments on the "good" ways to tackle that issue?

Answer 1

Maybe this paper, would be helpful: http://www.chrisharrison.net/projects/progressbars2/ProgressBarsHarrison.pdf

(...) backwards-moving behaviors were significantly preferred over both still and forward ones (p<0.001 for both). When grouped by change in velocity, accelerating behaviors (both forward and backwards) were significantly preferred over still ribbing (i.e., no velocity, p<0.05), while decelerating behaviors are significantly preferred over both still and constant velocity ribbing (...)

Answer 2

There are 2 nice studies on this, as referenced in this article.

For progress bars that display % actual progress:

• Use backward moving ribbings.
• Make sure that you downplay progress at the start and make it appear to accelerate it at the end.
• Avoid pauses at the end.

For indeterminate activity indicators:

• Faster pulsing or rotation generates the illusion of faster progress.

I generally prefer to keep progress bars as indeterminite activity indicators for simplicity, unless there is a specific use case where the user must be aware of the specific progress.