This looks really nice. I think I've saw one of the browsers using that space at the top for it's loading bar which looks very similar (I'm not positive on this - it could have been a mobile browser).
Firefox 3.6 with the theme named Strata and the plugin named Fission had progress bars that looked almost identical to this, including the glow effect.
I think this is something slightly different in that it's non-blocking.
The progress bar provides users with feedback as to the current status of the page they have requested to load, but it doesn't get in users' way and the page loads and renders as assets become available (unlike in SWF where all interaction is halted until the entire site has been downloaded up front).
Is HTML5 audio available on all browsers yet? I remember for Cut the Rope that they claimed that HTML5 audio for games only worked in IE, and that for whatever reason Firefox/Chrome/Safari didn't work quite right and needed a Flash stub.
I think the worst was Windows movie maker, which used to seem to just randomly choose a time it might take and do a bad job of self correcting on the way. Oh, and of course there's a relevant xkcd, http://xkcd.com/612/
I think the problem was that SWFs so frequently needed load indicators. Sure, progress bars make the time seem to go by quicker, but what's better is actually being quicker. Progress bars were a crutch, but the pages were still dramatically slower, that's why we all hated Flash sites so much.
the cycle, article about some thing -> post implementing it on HN is pretty damn awesome. I remember reading articles about this a few days back and here we have this. I remember reading articles about Await in JS and a link to a framework doing exactly that was posted a few days later.
Those that are predisposed to build slow sites despite all the evidence about how detrimental it is don't really need any excuses for some reason.
In all seriousness, given that there are a lot of use cases where an app might be fetching external resources without clearly informing the user as to (i) what's going on and (ii) the current progress, I'd wager the benefits of providing some sort of indication would be measurable even if it's rather fast. I don't really see the presence of an indicator, in any case, enabling an app to get away with slow/slower results.
This looks similar to the one on Youtube, I was wondering though, why is youtube progress bar only compatible with Chrome ? does it rely on a new HTML5 feature that doesn't exist in firefox ?
I've looked into this a bit. I don't think it's just Chrome but rather YouTube has some sort of beta flag for enabling the pjax style page loads. Try Incognito in Chrome and see if you still get the bar.
Question for people using these progress bars: Are you actually doing the computation to accurately estimate the time it takes to complete the action indicated by the progress bar, or are you simply showing a progress bar as a visual cue to any loading in the same way people have been using spinning AJAX loaders?
compu-what-tion? You mean accurately predict how long it'll take an ajax request to load? Pfft, an exercise in futility, easier to just fake it, and probably just as accurate :)
That's what confuses me. AJAX loaders are ubiquitous on the web. They're small, easy to use, and a great visual cue. I'm not sure why you would want a percent-based loading bar unless you actually knew how long something would take to load. (e.g. see loading bars for downloads)
Using these super thin bars as a "dumb" loader seems like it would only confuse your users. It's like using an icon other than the floppy disk to convey saving.
There are step functions that allow you to approximate it or increment it gradually. I might not know how long an individual step in a process will take, but if I know how many steps there are, I can know approximately how much to increment on the completion of each.
This doesn't suit all usage patterns (like file downloading where you don't know the file size), but I can think of at least a dozen scenarios in which this is perfectly suitable (even if I don't personally love the effect).
It's not that hard. If you're already using a module loader (which in all likelihood, you are if you're loading something async these days), then just count modules being loaded in your controller(s), and use that as your basis.
A harder approach would be to be super accurate with actual size of response. Content-length on the header won't work because it only refers to that one file. Also, the server won't have any clue which files belong to which web page response. A way around this is to check every request against a session ID. You'll also have to pass back some sort of "request hash" -- GUID for the request so you can match different files from the same request (static files, content, etc).
It diverts my attention and somehow I think that some activity goes on at the top of the screen. It actually makes me think a new tab was opened. I don't understand why we need this.
I think the concept itself is ridiculous. It's 2013 guys, UI response should be instant. If it's not, you need to rethink what you're doing and ponder your life in general.
But it is not instant. This is used when you are making an external HTTP request over the Internet, to a server that may or may not respond instantly (if at all), over a link that may be saturated at any point in time.
Are you implying that the author would have better spent his time redesigning HTTP rather than making this library? Because to me, that is even more ridiculous.
You're right that we should all strive to build UI that responds instantly. Unfortunately sometimes, for reasons out of a designers control there might be a legitimate reason for a site to reach that level - for that, adding a subtle progress bar does help.
Think of it as a local optimisation before you reach a global one of instant UI.
When I read site-wide I thought it would be progress bars reporting on time-demanding process initiated somewhere else on the site. Silly me - it is site wide as in across your screen...
Honestly, I'd consider nixing it altogether by default. Even though it's in the CSS spec, :wait effectively duplicates an action that has a rather particular meaning at the level of the OS. Confusion over it is probably more common than one might expect.
This is a nice implementation of something that we had an exciting discussion about on HN recently: UI pattern observation from UsabilityPost: Website loading bar [1]
As far as I can tell, yes. Except that the bar stops incrementing at random right before it reaches the end, and doesn’t move forward even if you call `.inc()`. This is so the bar can still move forward when you call `.done()`.
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).
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).
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.
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.
> 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.
Well, a wide adoption of this pattern would be quite a big change. And all the big changes are met with negativity/criticism, usually.
While negativity might be discouraging and sometimes might cross the line of a constructive discussion, at the same time it gives some food for thoughts. In this particular case, it gave me more to think about rather than 'looks nice'. So did this post https://news.ycombinator.com/item?id=6143604
Is this a part of a (very slowly) building trend towards a chrome-less browser?
Long ago we used to "login" to a site using BasicAuth and the browser defined login box.... it wasn't flexible/pretty enough so we started using <form>s and integrated them into the page.
We had a path-like URL structure that we used to get to our documents, but our documents became more complex and the path-like structure became less human friendly and more like a unique id that should be under the hood.
We had back (and forward) buttons to navigate through our mainly hierarchical sites, but our sites became less linear so we used javascript to jump around.
Our complex non-linear documents became so complex that we didn't want to reload them all at once, so we started fetching parts of the page and needed to build our own progress indicators within the page.
Soon: Very little of the browser chrome will be relevant to the way we use the web.
Very interesting idea. I can definitely see the progression towards a more minimal browser that offloads functionality which used to be part of the browser into the page. However, I think we have reached a minimal point where browsers have already stripped down as far as they can.
Looking at a browser like Google Chrome basically all that is left is tabs, forward and back buttons, refresh button, search/url bar, HTTPS indicator, and right hand menu button.
We couldn't get rid of the back and forward buttons because while JavaScript navigation works inside the page, it doesn't work very well to go back from your site to the site that the user came from, because security is designed to prevent you from easily reading history.
Additionally the refresh button couldn't be replaced by an in page control because if the JavaScript in the page has an error and stops working the refresh also stops working, which would make people unable to refresh the page.
I wouldn't trust an HTTPS icon that was powered by JavaScript inside the page so that also has to be part of the chrome.
The only item on that list that could be removed is the right hand menu button. And since that does stuff like print, bookmark, and settings that also doesn't work as part of the webpage itself.
But who knows? Maybe I'm wrong and we'll find a way to strip the browser down even more, but I don't think that will happen until we develop voice, gesture, or thought controlled interface devices that are faster and more efficient than typing into a search bar or clicking a button. Then we can get rid of all the buttons and controls completely. But at that point the entire experience of browsing would be extremely different, not just the browser chrome.
I think this direction can better be described as reaching toward a "native" experience, such as on mobile devices. You see this in Windows 8's full screen apps, they tend to be isolated containers, even though some are written using web technologies.
142 comments
[ 5.1 ms ] story [ 208 ms ] threadEdit:
Readme says it was inspired by Medium and YouTube - http://www.usabilitypost.com/2013/08/19/new-ui-pattern-websi...
It gave me a feeling of nostalgia seeing this.
The progress bar provides users with feedback as to the current status of the page they have requested to load, but it doesn't get in users' way and the page loads and renders as assets become available (unlike in SWF where all interaction is halted until the entire site has been downloaded up front).
Brings lots of memories, I used to make flash games in school when I was 15. I always liked those little games. /nostalgia
The Microsoft installation progress bars are the ones I remember as being ridiculous. Often going backwards, showing ridiculous install times, etc.
Sadly down now. :(
I suppose that says good things about the bars, though; they really do signal "loading"...
In all seriousness, given that there are a lot of use cases where an app might be fetching external resources without clearly informing the user as to (i) what's going on and (ii) the current progress, I'd wager the benefits of providing some sort of indication would be measurable even if it's rather fast. I don't really see the presence of an indicator, in any case, enabling an app to get away with slow/slower results.
Using these super thin bars as a "dumb" loader seems like it would only confuse your users. It's like using an icon other than the floppy disk to convey saving.
This doesn't suit all usage patterns (like file downloading where you don't know the file size), but I can think of at least a dozen scenarios in which this is perfectly suitable (even if I don't personally love the effect).
A harder approach would be to be super accurate with actual size of response. Content-length on the header won't work because it only refers to that one file. Also, the server won't have any clue which files belong to which web page response. A way around this is to check every request against a session ID. You'll also have to pass back some sort of "request hash" -- GUID for the request so you can match different files from the same request (static files, content, etc).
Think of it as a local optimisation before you reach a global one of instant UI.
b) Awesomely devious! I love the fake loading animations. Dude you are a fucking genius!
c) Did I mention awesome?
You can disable this by removing the `cursor: wait` rule in the CSS file.
This is a nice implementation of something that we had an exciting discussion about on HN recently: UI pattern observation from UsabilityPost: Website loading bar [1]
[1] https://news.ycombinator.com/item?id=6238482
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).
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).
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.
Wait, what?
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.
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.
While negativity might be discouraging and sometimes might cross the line of a constructive discussion, at the same time it gives some food for thoughts. In this particular case, it gave me more to think about rather than 'looks nice'. So did this post https://news.ycombinator.com/item?id=6143604
Also, I'll be documenting the process here: http://developingandstuff.blogspot.fr/2013/08/nprogress-no-j...
As preparation for a talk: https://twitter.com/mparramon/status/369945214494191616
Long ago we used to "login" to a site using BasicAuth and the browser defined login box.... it wasn't flexible/pretty enough so we started using <form>s and integrated them into the page.
We had a path-like URL structure that we used to get to our documents, but our documents became more complex and the path-like structure became less human friendly and more like a unique id that should be under the hood.
We had back (and forward) buttons to navigate through our mainly hierarchical sites, but our sites became less linear so we used javascript to jump around.
Our complex non-linear documents became so complex that we didn't want to reload them all at once, so we started fetching parts of the page and needed to build our own progress indicators within the page.
Soon: Very little of the browser chrome will be relevant to the way we use the web.
Looking at a browser like Google Chrome basically all that is left is tabs, forward and back buttons, refresh button, search/url bar, HTTPS indicator, and right hand menu button.
We couldn't get rid of the back and forward buttons because while JavaScript navigation works inside the page, it doesn't work very well to go back from your site to the site that the user came from, because security is designed to prevent you from easily reading history.
Additionally the refresh button couldn't be replaced by an in page control because if the JavaScript in the page has an error and stops working the refresh also stops working, which would make people unable to refresh the page.
I wouldn't trust an HTTPS icon that was powered by JavaScript inside the page so that also has to be part of the chrome.
The only item on that list that could be removed is the right hand menu button. And since that does stuff like print, bookmark, and settings that also doesn't work as part of the webpage itself.
But who knows? Maybe I'm wrong and we'll find a way to strip the browser down even more, but I don't think that will happen until we develop voice, gesture, or thought controlled interface devices that are faster and more efficient than typing into a search bar or clicking a button. Then we can get rid of all the buttons and controls completely. But at that point the entire experience of browsing would be extremely different, not just the browser chrome.