It looks great, but why should we start promoting this as a UI pattern? This seems like a step in the wrong direction, and just because Youtube does it doesn't mean that others should too.
If you need a visual cue that something is loading on your page, throw up some kind of spinner or other animation that doesn't have a fixed beginning and end. Unless you think you know how to accurately measure the time that http request/response cycle is going to take (you don't).
Notice how much longer you seem to wait with the spinner? Watching a progress bar fill up with a definite end feels way faster. I have often used progress bars that have no connection whatsoever with the process they're "measuring".
Here's the technique I've found works well:
1. Estimate the time the operation will usually take. Call that W (it can be a constant, or you can use a heuristic to guess it specifically for the user).
2. Pick a function that asymptotically approaches 1, e.g. the error function. Transform it it so that f(0.75*W) = 0.75.
3. Now for elapsed time t, fill your progress bar to f(t).
The upshot is that the bar will start fast, and never completely fill. And for the first 75% of the estimated time, it will be accurate (as long as your estimate is). After that, it matters less, since it will take a while for the user's brain to adjust to the slower speed.
> Compare the subjective wait for the spinner and progress ar in this demo: http://jsfiddle.net/gUkgX/1/embedded/result/
> Notice how much longer you seem to wait with the spinner? Watching a progress bar fill up with a definite end feels way faster.
No it doesn't. I agree they "feel" faster than the no feedback scenario, but I perceive no difference between the spinner and the progress bar in this case.
Sorry, that could have used more explanation, especially since I'm really hypothesizing after the fact about why it works better to start fast and end slow, and that hypothesis involves a few steps of inference.
It's pretty clear that the human brain is good at simple integration over time to predict where an object will be in the future, or how long it will take to reach a destination. What it doesn't seem to be as adept at is estimating those things when something is changing speed. I would guess that the reason for this is a combination of the math being harder, the results being more noise-sensitive, and it being less crucial in our evolution to anticipate rapidly accelerating or decelerating targets.
So my first premise is that we estimate time-to-destination based on speed, and that we are slow to update the estimate when the object changes speed.
My second premise is that time perception is heavily influenced by expectation. If click something and then nothing happens for a moment, our wait-time expectation is essentially unbounded, since we aren't even reasonably sure that anything is happening.
If you add a spinner, we become more confident that the wait will end, but the time expectation is still high. If the spinner lingers for too long, our only way to update the expectation is something like "I will be waiting for some significant proportion of the amount of time I've been waiting so far". That's not good, because it actually causes your expectations to invert with respect to reality; as time goes on, you feel further from the end, not closer.
So the idea is that a progress bar feels faster because it gives a decreasing expectation of time left. If the progress bar is accurate, then once it has moved half way, you will expect to wait exactly as long as you have already waited.
Now, the trick with the decelerating progress bar is that it lets you beat accurate expectations by causing the user to underestimate how long they will be waiting.
For example, suppose you accurately estimate that it will take 6 seconds. In the first two seconds, the progress bar will fill, about linearly, to 40%. The user will therefore expect the bar to be full after 5 seconds. After 4.5 seconds, it will be 75% full. If the user were to estimate based on there entire time so far, they'd correctly expect to wait another 1.5 seconds. But that doesn't seem to be what happens. Instead, the user continues to expect less. And so on. In the final moments before the progress bar disappears, the user simply doesn't have time to adjust their expectations.
What seems to lend additional credence to this hypothesis is that you can get even better results by adding random slowdowns and speed ups (while maintaining an average fill curve of erf(erf^-1(estimate)*t/estimate)). When the bar passes the 75% mark where it slows down for good, the user still expects another jump. You can even confirm this expectation by filling the bar at the end it disappears, since at expected completion it will only be 87% full.
There are at least some cases in modern client-side programming that you have access to progress information, and would therefore want a progress meter rather than a progress indicator. "Use spinners for everything" strikes me as short-sighted and reactionary advice.
You get a progress meter when you're pushing data, like uploading a file. And that makes perfect sense. Use a progress meter here, it makes sense.
This is totally different. It's explicitly saying that it might be used with pjax or turbolinks. I don't think there's a way to accurately determine progress information for one of these, the best you can do is use historical data and guess. In this case I think using a progress meter is a bad pattern.
For instance, there's no way to monitor the progress of sending an SMS message, yet the iPhone UI displays a progress bar for it. It assumes that SMS's take an average of 4 seconds to send, so the progress bar moves at that rate.
NProgress follows the same idea, and its default behavior operates similarly. Ideally, you should tweak the progress to be more in tune with your average load times (which is what I've done for our 2 apps that use it).
If you need a visual cue that something is loading on your page, throw up some kind of spinner or other animation that doesn't have a fixed beginning and end. Unless you think you know how to accurately measure the time that http request/response cycle is going to take (you don't).