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.
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.
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.
Please could you talk to the IE team about their progress bars explicitly lying to the user? I understand that giving immediate feedback is important as it can greatly increase perceived responsiveness, but that damn thing (on both desktop and Windows Phone 8) can climb to ~80% before even the first byte is received (it might even manage ~80% before the DNS lookup has returned though I've not tested to prove that). Have you every tried explaining to a non-technical user that their phone didn't "get nearly all the way then stopped" when loading a page? They simply don't believe "your web browsing software is lying to you, it didn't actually receive anything" and look at me as if I'm making things up to try hide that I simply don't understand the hinterwebs.
Of course the lie works: people think IE is more efficient than other browsers simply because on slow site and/or with slow connectivity the progress bar seems to initially push up faster than the one in FF/Chrome/other even though the actual page load time is the same.
I'm fine with little white lies to make the user feel more cared for (which is what fast "apparent response times" is all about: people personify technology so if you don't give the impression of immediate response they feel like some concious entity is actively ignoring them) but the IE progress bar takes that to an irritating extreme, to the point where it is detrimental to UX (I sometimes can't tell if the page is just loading slowly or nothing is transferring at all and I'm just going to get the "page not available" error in 20 seconds time).
It irritates me enough that it will be a factor in deciding what I buy when my current smartphone needs to be replaced (much as I like the Lumia 920; this, other Windows Phone annoyances, and comparative inexpensiveness, will make it difficult to justify not switching to Android next time).
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!
Please make the bars predict accurately. For a hack its ok to cut corners, but the bars have been bad predictors since windows 95. You guys could have figured it out by now, surely? It has probably caused irritation 10^9 times by now.
It should be the first feature of windows 9. I would upgrade!
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/), 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.
I have an app that does some prediction based on values that a user enters. The prediction works pretty fast – unnoticably fast, like 50ms or so.
However, I had the idea to use a progress bar to achieve the opposite effect: To introduce an artifical waiting time together with a sense of progress (hence, progress bar). This should convey the feeling that the app is working hard to make Your Personal Prediction and since the app appears to be calculating a lot of stuff, the prediction Must Be Totally Accurate.
Surely, the target users are not necessarily sophisticated technical people.
I haven't implemented it but I definitely want to try it out.
We had this issue on our website - our "Browse" is essentially an SPA that fetches results from an API upon any action being taken; such as sorting, pagination, adding filters etc. We had the fetching and rendering happening in an average of 30-50ms, which meant most users didn't even realise the page had refreshed apart from what appeared to be a faint blink on the whole page.
We actually had to put in a setTimeout() for 500ms with a loading gif, followed by an scrollTo() to the top of the results just so users would know something actually happened.
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.
Online tax software like TurboTax does this as well. It says crap like, "Loading your profile from last year..." or "Verifying your data is correct..." with a bar that takes 5 or 10 seconds to fill up before highlighting the Next Page button. But you can just click the Next button anyway and it'll go instantly.
I like your app, it's very cool. One thing though, make sure you add some validation on the fields. Right now when I click on "Make a gif" without anything populated, it loads to some point and throws an error.
Haha, yes it is a very unsafe/not well validated project. There are many things like that. For example, there is no limit to either the length of the gif, or it's size in pixels. As a result, some people have generated huge gifs, on the order of hundreds of mb in size.
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.
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!
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.
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.
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.
"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/
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.