# Estimating Remaining Time for a Progress Bar

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?

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 (...)

• Links can rot. Care to summarize the article here in SE? – Jon of All Trades Mar 31 '14 at 23:09
• Interesting article. @Jon: the idea is that a pulsating or animated progress bar can affect perception of time taken by about 10% vs a static progress bar. – Eric Grange Apr 1 '14 at 6:50

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.

• As a dev, I prefer indeterminate activity, but as a user, I'm really annoyed by indeterminate activity for anything lasting more than handful of seconds. – Eric Grange Apr 1 '14 at 15:31
• @EricGrange Yes, but I guess that for activity where the user has to wait longer than that would fall into the ux-feedback category (Interfaces should provide feedback about their current status. Users should never wonder what state the system is in. [Source: Nielsen]) – Franchesca Apr 2 '14 at 9:43