Buttons

How to Make Progress Bars Feel Faster to Users

Making users wait too long for your app to load can make users impatient. If users get impatient, they’ll abandon your slow site for a faster site.

While there are technical tweaks you can make to speed up your site, some apps have no choice but to make users wait. But there’s a way you can speed up your user’s sense of time to make them feel like your app loads faster than it does.

When an app is loading, users see a progress bar on their screen as a visual cue of when the app will finish loading. The way your progress bar moves and animates affects how they perceive the load time.

Backwards Moving Ribbings

A research study found that progress bars with backwards moving ribbings seem faster to users than forwards moving ribbings [1]. These findings show that “induced motion effects, which state that motion perception is not absolute, but rather relative to the surrounding visual context” creates an illusion of increased velocity, which alters our perception of progress bar time [1].

Higher Number of Pulsations or Revolutions

Another way you can make your progress bar feel faster to users is to increase the number of pulsations it has. The same research study found that “the progress bar with increasing pulsation was more likely to be perceived as having a shorter duration” [1].

Increasing pulsations are much like the beats per measure of a song. The more beats per measure, the greater the tempo and the faster the song is played. When a progress bar pulsates, it acts like a metronome counting the “tempo” of the progress time.

This finding also has implications for indeterminate activity indicators. Indeterminate activity indicators are like progress bars except they’re radial rather than linear. And they don’t show when the loading process will complete.

You can make load times feel faster to users by increasing the number of revolutions an indicator has. The more times your indicator spins in a duration, the faster your app will feel.

Accelerating the Progress at the End

A separate study found that progress bars with accelerating progress was strongly favored over decelerating progress [2]. This means that progress bars “with the fastest progress occurring near the end of the process” were perceived faster than progress bars “with pauses near the process conclusion” [2].

If your progress bar has to have pauses, you can downplay the progress in the beginning of the process. Then accelerate it towards the end to give users a rapid sense of completion time. Users are more tolerable with pauses at the beginning than at the end.

Progress Time is Relative

Tweaking the user’s perception of time can make your app seem faster than it really is. This comes in handy when you’ve done all you can to optimize your site.

Many feature-rich apps that have long load times can make use of this technique. But there are a couple other techniques you can use to give users a speedy perception. Perception is everything in user experience. If your load times feel fast, maybe it actually is.

References

[1] http://www.chrisharrison.net/projects/progressbars2/ProgressBarsHarrison.pdf

[2] http://www.scribd.com/lmjabreu/d/2226848-Rethinking-The-Progress-Bar


Toolkits

Affiliates

elegant wordpress themes

This Post Has 20 Comments

  1. Hugo Reply

    Hey, nice article !

    It’s fun (and useful of course) to see that kind of observations. I should remember that when I have to design a progress bar / loader.

    Thanks for sharing anyway. 🙂

  2. Chris LaChance Reply

    I was just talking about this with our dept about a month ago, trying to push a faster spinner (i had no evidence then however).

  3. Jeroen van der Tuin Reply

    Can’t wait to whip such a fast looking progress bar out on a client. Great observation and might just mean the difference between cancelling a download and waiting just a little bit more.

  4. Paul Reply

    great read! I loved the last part that said users tolerate slower acceleration at the start, but not towards the end of the process.

    great great great!

  5. Alex Coady Reply

    Interesting article. Might have a play with some CSS3 effects for use in a web application.

  6. Pierre Reply

    It’s nice post, thanks you very much.

    I’m change my progress bar ASAP.

    See you,
    Pierre

  7. Paul d'Aoust Reply

    Ha, that’s hilarious! The psychology of the human eye, eh? Thanks for the clever advice.

  8. GameZone Reply

    Great Article. I should remember that when I have to design a progress bar / loader.

  9. Christopher Roberts Reply

    Very clever stuff, the psychology of time perception!

    “Accelerate the Progress and Avoid Pauses at the End” – totally true I think, I would much rather the first half took 40 seconds to load and the second 20, rather than the other way around.

    Thanks for bringing this to my attention, it has very interesting implications 🙂

    Christopher

  10. Alistair Lattimore Reply

    I’ve never seen research to support whether this is good or bad but in cases where you don’t know how long something is going to take and a radial progress indicator is used, a lot of web sites use helpful/interesting messaging to keep the user engaged while they wait.

  11. Mark Cowtan Reply

    Excellent information, many thanks. Makes a lot of sense. On sites with lots of big images in sliders, load time is a big concern. If you can fool the user into thinking “its almost loaded” it could make a big difference in bounce rate for first time visitors. People dont mind slightly slow sites if they know the content is good, but first time visitors, the first experience must not be off-putting.

  12. Stefan Reply

    Good article, especially the backwards ribbing makes a lot of sense!

    There are two things I’m missing though:
    1. Don’t add time estimates when you can’t reliably make them (I’m looking at you, file copy dialog!). Inaccurate time estimates only increase annoyance levels.
    2. Use sub bars for sub processes – it makes the different stages of an operation more visible, and distracts from the varying speeds of the main progress bar which may seem to be stuck at times. (Note this also increases the apparent ‘pulse rate’ that is mentioned in this article)

  13. Steven St. John Reply

    The tip about speeding up the progress bar towards the end is consistent with the peak-end rule from psychology. (See: http://en.wikipedia.org/wiki/Peak%E2%80%93end_rule)

  14. Mick Reply

    One of the things about pauses at the start, we’ve all come to expect “some” delays there – like “Are you sure?” and other confirmation screen as well as queries as to where you want the file saved, or to “Open file when download finished”, etc. IOW, we expect there to be some “overhead” at first, and we tolerate watching a stumbling progress bar.

    However, at the end of a long (especially a so-far smooth) download, it might appear as if it crashed or got hung-up – a condition we’ve all experienced and don’t tolerate.

  15. Alastair McDermott Reply

    Very interesting. Any example GIFs that use these techniques?

  16. ChadF Reply

    Maybe someone should implement the seeming opposite style “progress bar” to mock the human psychology effect.. A cup/pan side view with a slooooow drip filling it up as it goes. Here comes another drop.. almost.. getting there.. any minute now.. and.. and.. DRIP! There we go. Now repeat 1000 times till full. =)

  17. Daniele Reply

    Nice article, but what if we quit progress bar at all ? And what if we apply something as used in the Chrome browser ? A circle filling up based on the size downloaded plus some ticks rotating with a speed proportional to the download speed ? I actually put up this solution for one of my clients… you can see a video explaining the solution here: http://youtu.be/7wjdwOyqjZg

  18. Cristian Rojas Reply

    Amazing article, thanks for posting, the studies pdfs are very useful

  19. Brandan Reply

    On website games with long load time have a mini game with it.

  20. Rohan Reply

    Trying to control the speed at which the bar fills doesn’t seem like anything you could do with any accuracy. If you’re copying a heap of files, it’s often a lot slower to copy a bunch of little files than a few big ones, and if you’ve got a million files of varying sizes in a thousand sub-directories with ten or more levels in use, there’s no way you can predict how fast any part of the operation will be.

    For copying files, it might be a good idea to do a three-part solution.

    1. A progress bar for the entire job. If copying 1000 files, each file fills up 1/1000 of the bar.
    2. A thinner progress bar for the current file, filled based on just data copied so far.
    3. A spinning icon thing that will only move so long as data is being written to the destination. If something goes wrong and it stops getting data or it suddenly can’t write any more (maybe because it’s run out of space or the network connection went down), it should freeze.

    Also, show the name of the current file. Don’t just say “File 387/15384”. Being able to glance at the file names and paths helps give you an idea of where it’s up to.

Leave a Reply to Alastair McDermott Cancel reply

Your email address will not be published. Required fields are marked *