6 ms·

It's nice looking, but I'd like to see some actual user testing on whether this kind of progress bar performs its most important task. "What?" I hear you askin

It's nice looking, but I'd like to see some actual user testing on whether this kind of progress bar performs its most important task. "What?" I hear you asking, "Of course it does! It shows how much longer you'll have to wait." In which case I must inform you that giving the user information is not the most important function of a progress bar. The most important function of a progress bar is Time Travel. That is to say, subjective time travel. Try this fiddle: http://jsfiddle.net/gUkgX/1/embedded/result/ http://jsfiddle.net/gUkgX/1/embedded/result/ First, click "No feedback". Wait for it. Feel how long it takes to run. Try not to count the seconds (you wouldn't usually do that on a real website) - just see how it feels. Next, click "Spinner", and then finally try "Progress bar". Which one felt shortest? Of course, they are all the same ten seconds. Yet the spinner feels faster than no feedback, and the progress bar feels faster still. Watching that bar fill up makes the time seem to pass faster. And the progress bar is totally fake. In fact, it doesn't even take 10 seconds to fill. It fills in 9.2 seconds, starts out fast and slows down, and none of this has anything to do with what is really happening, which is that you're waiting for a 10 second timeout to fire. My point with all of this is that in order for a progress bar to fulfill its duties as a time condenser, I suspect that it needs to be prominent. I get the idea of keeping the indicator out of the way and minimal, but I think this is misguided in this case.

terabytest 13y ago
One point I'd raise about this is that I think it's fine to be able to indicate progress, be it just to keep the user looking at something while the page is loading, but I don't like how it seems to duplicate the function of the other progress indicators the browser has. Seeing the rise of client-side web apps, a browser API to show progress directly through the browser's chrome rather than custom UI patters would probably be great and prevent a lot of the fragmentation that things like this might cause. Plus, the less-savvy users might come to expect to see this bar everywhere just because they see it on YouTube, which I think is not a healthy thing for the web in general.
electic 13y ago
I think for me, it creates a unified experience for the user. Instead of coding up a slew of different spots for loading animations for different parts of the app, I can now have a loader on the top to indicate progress. It creates less code bloat for me and the user knows something is loading regardless of what action they took in the site. My two cents.
jjcm 13y ago
I work for Microsoft as a UX prototyper. One of the research studies we did was something similar to this a while back. One of the findings we had was that if there was any motion at all on the screen, the user felt something was happening. It didn't have to be prominent, just noticeable. If you're doing voice input on windows phone, the vu meter is just a series of very small dancing dots. To let the users know that they could speak, we'd blip one or two of those dots up - hardly anything at all, and indistinguishable from noise, but it let users know stuff was happening. Motion means that something hasn't gone wrong. It means that gears are still spinning. That's also why windows phone has so many 3D transitions between screens. We use longer transitions for heavier load times, because it makes those load times seem faster. The transitions don't have to be prominent though, at least from the studies we did. They just need to be there.
- wfunction 13y ago
  Is this also why Explorer's progress bar approaches the end asymptically, with no regards to the actual number of files processed? It drives me NUTS, to say the least.
  - mafro 13y ago
    I always knew there must be some solid UX reasoning behind those file copy dialogs.
    - wfunction 13y ago
      It's not a file copy dialog, it's a file search dialog. The file copy dialog was never like this. In fact, the Windows 8 file copy dialog is not only good, but fantastic.
  - andyhmltn 13y ago
    Apple's 'sending message' bar (at least on iOS7) speeds right to the end and then waits about 50px before it for a few seconds before sending. It's so annoying!
adventured 13y ago
Reminds me of this: http://www.nytimes.com/2012/08/19/opinion/sunday/why-waiting-in-line-is-torture.html http://www.nytimes.com/2012/08/19/opinion/sunday/why-waiting... In which an airport discovered it was dramatically better to have people walk longer distances to get their luggage, rather than walk a shorter distance to baggage claim and stand around waiting (all things being equal on the actual time for the luggage to be available to pick up). The walking kept them busy / distracted. The very popular game Skyrim uses a beautiful looking object / model from the game for interstitial loading screens; you can spin the object, zoom in etc, and it makes the load times a lot more tolerable.
lelandbatey 13y ago
This is 100% true. I shared this story in another comment yesterday, but I'll share it again here: On one of my one-off side projects(http://gifmachine.xwl.me/ http://gifmachine.xwl.me/), there's a rather silly example of the importance of loading bars. In the first version, the design was quite bare. There were a couple of textinputs and a "make gif" button. The way the code happens to work, when you press the "make gif" button the web page would just sit there till you where re-directed to your finished gif. The first bit of advice I got from anyone was "this is sooo slow, what's happening?" The problem was, I didn't actually have any way to understand how long/what was going on in the backend. So I decided to take the next best approach: I fake it. As soon as you click the "make a gif" button, the bar starts loading. However, that bar has no basis in reality. It takes exactly 40 seconds to fill up, no matter what's going on. However, everyone loves it! All the comments I got said how much better it seemed to make the experience. Even though it's a fake loading bar.
- guynamedloren 13y ago
  This is a fantastic hack: it's fake, but everyone still loves it. It makes the user experience better. Nice work.
- jabr 13y ago
  I like to use an asymptotic function for fake progress like this: t/(t+n) With n set to a bit under half the average load time, if generally looks about right, too.
- mistercow 13y ago
  Yep, I use them pretty often now. What I would like to do is create a library for this. Features would include: 1. Choosing arbitrary time estimate to use as a target. 2. Providing distractions for if the estimate is much too low (show a secondary progress bar or spinner, maybe even misdirect so the primary bar can backtrack without the user noticing) 3. Calibration based on real results. A simple way would be to use linear regression to map the input guesses to real world results. Then the resulting equation should be easily available to plug into a persistence library or LocalStorage, so that you continue to get accurate results moving forward.
- 13y ago
gaelian 13y ago
I personally think it's a nice looking solution and - as has already been said - I like the idea of a unified loading animation across an application. But I'd like to see some actual user testing on whether this kind of progress bar does in fact show a typical user how long they have to wait or allows them to 'Time Travel'. In my own (anecdotal) experience, non-technical users are amazingly blind to small details on screen, sometimes even when they are changing/moving.
mseebach 13y ago
Sometime around the turn of the century, I worked on an enterprise webapp (of the kind I fear may have kept IE4 in production for a long time). We'd show a popup-window with a gif of spinning gears for operations that took more than a few seconds. At one point, we had a call from a user that had been waiting for one of these operations to finish for a long time. We looked into it and realised that some backend process had crashed, so we restarted it and told him he'd have to reload the app. The user wouldn't hear it - it was still working, he could see the gears turning!
- stephanos2k 13y ago
  That's funny, true and sad at the same time.

terabytest 13y ago

One point I'd raise about this is that I think it's fine to be able to indicate progress, be it just to keep the user looking at something while the page is loading, but I don't like how it seems to duplicate the function of the other progress indicators the browser has. Seeing the rise of client-side web apps, a browser API to show progress directly through the browser's chrome rather than custom UI patters would probably be great and prevent a lot of the fragmentation that things like this might cause. Plus, the less-savvy users might come to expect to see this bar everywhere just because they see it on YouTube, which I think is not a healthy thing for the web in general.

electic 13y ago

I think for me, it creates a unified experience for the user. Instead of coding up a slew of different spots for loading animations for different parts of the app, I can now have a loader on the top to indicate progress. It creates less code bloat for me and the user knows something is loading regardless of what action they took in the site. My two cents.

jjcm 13y ago

I work for Microsoft as a UX prototyper. One of the research studies we did was something similar to this a while back. One of the findings we had was that if there was any motion at all on the screen, the user felt something was happening. It didn't have to be prominent, just noticeable. If you're doing voice input on windows phone, the vu meter is just a series of very small dancing dots. To let the users know that they could speak, we'd blip one or two of those dots up - hardly anything at all, and indistinguishable from noise, but it let users know stuff was happening. Motion means that something hasn't gone wrong. It means that gears are still spinning. That's also why windows phone has so many 3D transitions between screens. We use longer transitions for heavier load times, because it makes those load times seem faster. The transitions don't have to be prominent though, at least from the studies we did. They just need to be there.

wfunction 13y ago
Is this also why Explorer's progress bar approaches the end asymptically, with no regards to the actual number of files processed? It drives me NUTS, to say the least.
- mafro 13y ago
  I always knew there must be some solid UX reasoning behind those file copy dialogs.
  - wfunction 13y ago
    It's not a file copy dialog, it's a file search dialog. The file copy dialog was never like this. In fact, the Windows 8 file copy dialog is not only good, but fantastic.
- andyhmltn 13y ago
  Apple's 'sending message' bar (at least on iOS7) speeds right to the end and then waits about 50px before it for a few seconds before sending. It's so annoying!

adventured 13y ago

Reminds me of this: http://www.nytimes.com/2012/08/19/opinion/sunday/why-waiting-in-line-is-torture.html http://www.nytimes.com/2012/08/19/opinion/sunday/why-waiting... In which an airport discovered it was dramatically better to have people walk longer distances to get their luggage, rather than walk a shorter distance to baggage claim and stand around waiting (all things being equal on the actual time for the luggage to be available to pick up). The walking kept them busy / distracted. The very popular game Skyrim uses a beautiful looking object / model from the game for interstitial loading screens; you can spin the object, zoom in etc, and it makes the load times a lot more tolerable.

lelandbatey 13y ago

This is 100% true. I shared this story in another comment yesterday, but I'll share it again here: On one of my one-off side projects(http://gifmachine.xwl.me/ http://gifmachine.xwl.me/), there's a rather silly example of the importance of loading bars. In the first version, the design was quite bare. There were a couple of textinputs and a "make gif" button. The way the code happens to work, when you press the "make gif" button the web page would just sit there till you where re-directed to your finished gif. The first bit of advice I got from anyone was "this is sooo slow, what's happening?" The problem was, I didn't actually have any way to understand how long/what was going on in the backend. So I decided to take the next best approach: I fake it. As soon as you click the "make a gif" button, the bar starts loading. However, that bar has no basis in reality. It takes exactly 40 seconds to fill up, no matter what's going on. However, everyone loves it! All the comments I got said how much better it seemed to make the experience. Even though it's a fake loading bar.

guynamedloren 13y ago
This is a fantastic hack: it's fake, but everyone still loves it. It makes the user experience better. Nice work.
jabr 13y ago
I like to use an asymptotic function for fake progress like this: t/(t+n) With n set to a bit under half the average load time, if generally looks about right, too.
mistercow 13y ago
Yep, I use them pretty often now. What I would like to do is create a library for this. Features would include: 1. Choosing arbitrary time estimate to use as a target. 2. Providing distractions for if the estimate is much too low (show a secondary progress bar or spinner, maybe even misdirect so the primary bar can backtrack without the user noticing) 3. Calibration based on real results. A simple way would be to use linear regression to map the input guesses to real world results. Then the resulting equation should be easily available to plug into a persistence library or LocalStorage, so that you continue to get accurate results moving forward.
13y ago

gaelian 13y ago

I personally think it's a nice looking solution and - as has already been said - I like the idea of a unified loading animation across an application. But I'd like to see some actual user testing on whether this kind of progress bar does in fact show a typical user how long they have to wait or allows them to 'Time Travel'. In my own (anecdotal) experience, non-technical users are amazingly blind to small details on screen, sometimes even when they are changing/moving.

mseebach 13y ago

Sometime around the turn of the century, I worked on an enterprise webapp (of the kind I fear may have kept IE4 in production for a long time). We'd show a popup-window with a gif of spinning gears for operations that took more than a few seconds. At one point, we had a call from a user that had been waiting for one of these operations to finish for a long time. We looked into it and realised that some backend process had crashed, so we restarted it and told him he'd have to reload the app. The user wouldn't hear it - it was still working, he could see the gears turning!

stephanos2k 13y ago
That's funny, true and sad at the same time.