Rethinking the Progress Bar (2007) [pdf]

When a program is performing a task that is going to make me wait I want lots of communication. Imagine I ordered a sandwich in a restaurant and its taking longer than expected. I&#x27;m now faced with a decision, do I wait or do I leave? I could make a better decision about what to do if I could see how many orders are ahead of me or if I can watch the kitchen and see a stack of ingredients ready to go, but the chef paused to clean off the grill. In the case of computer it can be hard to know beforehand exactly what its going to do and how long it will take. Maybe there is some kind of issue I need to fix before the task will ever be complete. As computers and networks evolve and improve (or degrade) it can be really hard for the programmer to have a good idea of how long a task will take to complete. In light of that, I would always err on the side of giving the user <i>more</i> information about what the program is doing and how long its taking.<p>On a file transfer I&#x27;d really like to know, how much has been copied, how much is remaining and the current (5 sec average maybe) bit rate. That gives me enough information to know whether its worth waiting around for it to finish or I should find an alternative or the connection has dropped.<p>Staring at a spinner, with no idea how fast or slow things are going is the worst and I&#x27;m going to give up a lot sooner than if I knew what was happening.

As a summary;<p>- Participants preferred whatever they saw first<p>- Otherwise, accelerating or rapidly accelerating progress bars were generally preferred<p>If you&#x27;re designing progress bars with an unknown time to completion, my recommendation is to use an accelerating function for the first 95% over the predicted median time to completion. Then linear timing function for the next 4% and set the time to 3x the median time to completion. Automatically fill the bar when progress completes, no matter what.<p>e.g. if an action takes a median time of 4s to complete;<p><pre><code> f(0 &lt;= t &lt; 4) = 0.95 * ((t &#x2F; 4) ^ 2) f(4 &lt;= t &lt;= 16) = 0.95 + (0.04 * ((t - 4) &#x2F; 12)) f(t &gt; 16) = 0.99 </code></pre> You can adjust this however you see fit but I find it gives a pleasant experience.

I had a friend who implemented what he referred to as Zeno&#x27;s Progress Bar. After every unit of time passed, the progress bar would progress half the distance to completion. So 0 -&gt; 50% -&gt; 75% -&gt; 87.5% and when the task finished it would jump to 100%. It didn&#x27;t bother to measure the actual progress at all. Key factor was making users think something was happening and not give up before it was done. In hindsight, it leverages the human&#x27;s susceptibility to the sunk time fallacy.<p>They may not have been the first to invent the idea or implement it. I found this description of the same idea here: <a href="https:&#x2F;&#x2F;cerealnumber.livejournal.com&#x2F;27537.html" rel="nofollow">https:&#x2F;&#x2F;cerealnumber.livejournal.com&#x2F;27537.html</a><p>and an online implementation and demo here: <a href="https:&#x2F;&#x2F;jan-martinek.com&#x2F;etc&#x2F;zeno&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jan-martinek.com&#x2F;etc&#x2F;zeno&#x2F;</a>

I&#x27;m still waiting for a neural net progress bar as a service that pipes in all available device data, measurable progress and a task id and spits out a prediction based on previous runs across _all_ previous tasks.<p>Should eventually figure out what tasks are IO bound, what are CPU bound, what are fixed time, etc. as well as what device configurations effect that. Could also predict a service is down given enough scale...

These researchers presume that their goal is to make users think that an operation is happening quickly, even if it is slow.<p>I thought the goal of a progress bar was to report reality, not manipulate users into thinking that your slow code is faster than it actually is.<p>Since when have dark patterns infiltrated academic HCI?

Results:<p>Participants tended to prefer (i.e., perceive as faster) whichever function they saw first. Of the 990 paired com- parisons, the first function was preferred 376 times (38%), the second 262 times (26%), with no preference 352 times (36%).

Someone should make a JSFiddle that demos these different progress bar mathematical functions so you can visually compare them side-by-side.<p>Also relevant: Tom Scott&#x27;s recent video[0]<p>[0] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=iZnLZFRylbs" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=iZnLZFRylbs</a>

The best progress bars I see, are double ones, where there&#x27;s one general bar, and one with a thinner bar for each item. That way I always know that there&#x27;s progress. Perhas even some info text would be nice too, like it is in most games, for when the progress requires some CPU time.

Also: <a href="https:&#x2F;&#x2F;chrisharrison.net&#x2F;projects&#x2F;progressbars2&#x2F;ProgressBarsHarrison.pdf" rel="nofollow">https:&#x2F;&#x2F;chrisharrison.net&#x2F;projects&#x2F;progressbars2&#x2F;ProgressBar...</a>

Cool to see article by someone I know on here! Really liked this paper, something else I find tricky about them is how hard it often is to accurately measure&#x2F;report&#x2F;track progress when writing software. In my experience a lot of these bad behaviors in progress bars come from programmers not having good way to actually track the real progress and instead just have to aggregate or estimate progress from each &quot;stage&quot; or &quot;step&quot; or whatever your software abstraction for a unit or work ends up being

Good to see Chris Harrison doing good work after being fired from hosting the Bachelor.