
Faster Progress Bars: Manipulating Perceived Duration with Augmentations (2010) - robin_reala
http://www.chrisharrison.net/index.php/Research/ProgressBars2
======
Talyen42
It's also obvious to many users when a progress bar is "faking" progress,
stalled, or clearly not representing the actual progress being made.

This makes me mad at your app, and very slightly less likely to use your
software.

Good luck measuring my slight disdain.

~~~
emodendroket
Is it actually obvious though?

~~~
dsr_
Often, yes. A progress bar that hangs at 99% for 50+% of the elapsed time
teaches the user not to trust the bar.

~~~
gadders
It sometimes depends on what progress the bar is tracking. I think some
developers (incorrectly) track the % of the actions they are completing EG I
have 100 files of different sizes to load and I have loaded 45 of them whereas
I think users always expect the progress bar to be a timer and progress
smoothly from 0 to "done".

~~~
euyyn
Like in many cases in which a programmer codes a user-facing piece of software
(be it this, an error message, etc.), the programmer tells what he's doing
instead of what the user cares about.

------
philipodonnell
The problem with progress bars as the coder is that it's often difficult to
tell how far you are into a process if it's not a repetitive sequence of
similar steps.

Transferring a file byte-by-byte is easier that a list of arbitrarily sized
files. Fixing that would require reading all the file sizes first, or some
complex logic to determine when to pre-plan the updates.

What about some kind of "learning progress bar"? It keeps track of the updates
that have been made and predicts how long a new user will take based on
previous users experience with the bar.

The classic case is installation progress bars, repeated uses of same/similar
sequences of steps with indeterminate length of time. But if you aggregated
the real-time data from all those progress bars, each new bar becomes a kind
of dynamically-updated prediction of how much time is left on the bar.

~~~
WorldMaker
That's an interesting idea. You'd still have an issue if the process has a
very high standard deviation or a lot of outliers. You almost need some sort
of useful UX for the error bars of the progress (+/\- 3%, +/\- 15 minutes),
but if polling statistics seems to prove anything, error bar UX is something
that we have never been able to build in a way that a person with no to little
statistical background can appreciate.

Tangentially, I've experimented with a different sort of "learning progress
bar", in that I think one UX problem we face is that we've learned the hard
way that linear progress bars aren't allowed to go backwards/shrink. It
confuses/angers too many users to watch a progress shrink and gives the wrong
impression that something has gone wrong or is being rolled back (that
progress is somehow "lost").

This is a problem because a lot of our problem solutions are recursive and we
don't have a full estimate of the problem scope until we've recursed the full
depth to the leaves of the problem tree.

My experiment [1] was with the idea that with a radial progress bar you can
"shrink" it, but still give an indication of "forward" progress (clockwise
movement in this case). You get to take advantage of the fact that
perceptually people can tell the difference between small increments linearly,
but not small increments radially (the reason why pie charts are actually not
particularly great UX if you need someone to perceive subtle differences). It
seems like a "best of both worlds" approach in that in the task discovery
phase it acts like a "spinner" and as discovery completes it becomes more of a
progress bar, and if for some reason a bunch of new tasks are discovered mid-
flight you get a hybrid of the two.

[1] GitHub:
[https://github.com/WorldMaker/compradprog](https://github.com/WorldMaker/compradprog)
; Blog post:
[http://blog.worldmaker.net/2015/03/17/compradprog/](http://blog.worldmaker.net/2015/03/17/compradprog/)
; Demo site is currently broken (hello tech debt from 2015), sorry

------
tomalpha
This feels similar in nature to the reason that lifts (elevators) have mirrors
in them, whilst waiting for them, or both: [http://platformliftco.co.uk/news-
pr/why-do-lifts-have-mirror...](http://platformliftco.co.uk/news-pr/why-do-
lifts-have-mirrors)

~~~
styfle
I like mirrors in an elevator if I’m the only one in there.

Otherwise it makes the ride more awkward because I try to avoid locking eyes
with someone else through the mirror.

------
taneq
I think it's important to measure the annoyance factor of these
'augmentations' along with the perception of speed. The pulse that travels
along the new Windows progress bars bugs the hell out of me and I wish I could
turn it off.

~~~
smichel17
For me, the annoyance comes from not being able to tell if the operation has
stalled ("Did it just inch forward, or was that just a pulse?"), which
decreases the amount of useful information available to me.

I would guess this is done intentionally, to keep impatient people from
canceling the operation when they should really just let it run. If that's the
case, however, I would argue that the real problem is not providing enough
feedback to indicate whether the operation is still proceeding as planned. Ie,
whether a long wait is expected at this step or not. I wonder if a progress
bar is really the best indicator for this purpose.

------
j_s
My pet peeve is progress bars that increment based on the units of work,
rather than extrapolating to an estimated time remaining. When there is no
real correlation between how long different segments of the progress bar will
take to complete, it basically becomes useless to me.

My general perception is that most commercial software is putting in the
effort to calculate time remaining these days. Are there any open-source tools
that help with this? It would be awesome to collect analytics during
development (opt-in in production) and apply it to calculate more and more
accurate time estimates.

------
makecheck
How about: _make your product faster so you don’t need progress indicators_?

I see these _way_ too often, and most operations really should feel instant to
the user. Little things should not be taking multiple seconds to complete.

And for the occasional actually-time-consuming task, calculate the end point
so you can display a proper bar. An indeterminate spinner is laziness, forcing
the user to wait an unknown amount of time when you can probably figure it
out.

~~~
arbie
Any operations that rely on server-side compute/data must margin for
nondeterminism. I would put in a loading indicator _just_ to cover the
outliers.

Local (client-side) operations are a different matter entirely. Either
precompute the result for common operations or optimize for speed!

~~~
makecheck
Unless the device is physically out of space for storing things, there is no
excuse for putting up a modal loading indicator because of a server-only
problem.

As a general rule, every single edit should be able to return control to the
user _immediately_. If the network can’t be reached, save _locally_ and
attempt an update in the background (showing a small, unobtrusive annotation
that an update is pending, as opposed to a screen-erasing obnoxious progress
popover). And definitely don’t _erase everything the user did_ if the network
ends up being unreachable.

~~~
styfle
What about if two users are editing the same object? How do you reconcile or
merge the changes?

------
Vinnl
For those as impatient as I am (how ironic):

> Progress bars with animated ribbing that move backwards in a decelerating
> manner proved to have the strongest effect.

So I guess that'd be the second, third and fourth from the bottom at the start
of the video, but I'm listening without sound so perhaps someone can confirm.

------
chickenfries
I think this research shows that you can influence perception of time without
resorting to outright "making up" the progress bar. You can imagine using this
technique not to lie about progress but just to make short progress bars
appear to move faster.

I spent several hours in Google Analytics yesterday. It's been a few months
since I've used it, and I remember thinking that it seemed a lot faster.
They've recently refactored their UI, and possibly done some system
improvements, who knows. But after looking at this research, I can see that
they've also taken advantage of similar techniques to make their loading bars
seem faster. It's a free improvement of 11% in perceived speed, just for
changing an animation, without misrepresenting the underlying information.

~~~
euyyn
I laughed a bit when the video said it made the perceived speed 11% faster.
Two significant figures shouldn't be used to measure a perception that is
subjective and probably not even linear.

Unless they have a scale of "perceived speed to actual speed" for regular
progress bars, that they're using to gauge the enhanced ones?

~~~
chickenfries
You made me curious so I dug into the paper.

> For our final study, we selected a progress bar that featured Backwards
> Decelerating ribbing, as this was slightly preferred over the pulsating
> behavior in study three. This was compared against a standard, solid color
> progress bar. The test interface, instead of simply recording participant’s
> preferences, used the responses to warp the duration of the ribbed progress
> bar (the solid color progress bar had a fixed duration to act as a control).
> Specifically, if a user felt the ribbed progress bar was faster, its
> duration was extended (to slow it down). Conversely, if the user felt the
> ribbing was slower, the duration was reduced (to speed it up). Equal
> responses left the duration unchanged. The goal was to allow participants to
> converge to a duration where they believed the two progress bars “felt”
> equal. (For an extended discussion on method of adjustment
> experiments,please refer to [3], “Difference Thresholds”).

So I want to guess they were given some kind of interface that would let them
decrease the speed in increments of 1%, perhaps.

------
tritium
No thanks. I'm not interested in the manipulation of perception.

I'd like a progress bar to actually report on progress. If you can't do that,
don't feed me bullshit blinking lights, and pat yourself on the back. Just
tell which part is hanging up, so I can either clear the bottleneck, route
around it or throw everything in the trash.

I'm torn at this point, about which non-progress bars I hate more these days,
Apple's or Microsoft's. Windows used to have the most useless progress bars:

[https://www.xkcd.com/612/](https://www.xkcd.com/612/)

But Apple system updates for OS X are possibly much, much worse. Reporting 20
minutes and taking 90, opaque, inching along pixel by pixel, and not telling
you anything about what's slow, or whether there are parts to the process.
Just one stupid line, and if it fails in the middle, start over. Is it
unzipping, checking the integrity of file hashes, connecting to the internet,
not connecting and waiting for a time-out, compiling open-source packages for
this particular chip set?

One thing's for sure, I've been promised so many minutes, and instead lost
hours.

~~~
emodendroket
Alright, fine, but is there any reason to think you're anything like a typical
user?

~~~
tritium
Is there any reason you’d advocate writing “ _typical_ ” software?

~~~
emodendroket
Unless you're writing a programming tool it's very unlikely that most of your
users are highly technical users who think like a programmer.

~~~
emodendroket
As an addendum, I was once in a position where I'd have to provide essentially
all the support for software I developed. That's no longer the case but the
mindset of avoiding designs that are likely to confuse the user (and thus lead
to people bothering you to ask about them) stays with me even a few years
later.

------
eurticket
The best progress bar is in Gary's Mod when connecting to servers. It lists
exactly what files are being downloaded to you underneath the bar so nothing
is a mystery.

------
ben_jones
The other day my home wifi was cutting out, I was amused when the netflix
loading bar kepting chugging on before deadlocking at 97/99%

