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.
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.
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).
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 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 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.
Not to denigrate the work done here, but I find it hard to see the excitment over this new UI pattern as anything more than a fad, and anticipate that will go through a highly predictable cycle of 'why you need a progress bar' through 'progress bars considered harmful' etc. etc.
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.
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
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.
I worked, for a brief instance in time, at a roadside produce stand. At first I got really hung up on whether or not I could give a customer an accurate, precise answer to their question. With time, I realized that 19/20 customers didn't want the correct answer; they simply wanted a confident answer to allay their concerns.
To wit: a customer asked for a tomato with qualities A, B, and C (anyone who thinks that such a conceptually complex interest in tomatoes is unnecessary needs google 'heirloom tomatoes'). I recommended a Black Krim tomato which, to the best of my knowledge, I believed would meet all of her needs.
She happily purchased six Black Krim tomatoes and went along her merry way. I then asked my manager if there was a better recommendation.
He promptly told me that 1) I was diametrically incorrect in my choice for meeting her needs, and 2) it didn't matter, even in the least.
Sure enough, later that week the same customer came back and specifically thanked me for my excellent recommendation.
I've been reading the comments on various progress bar threads here and elsewhere in the past few days, and I think many of those who dismiss this UI pattern are missing the forest for the trees.
It's not about accurately representing the loading of elements in the page.
It's not about accurately predicting and displaying when the page will finish loading.
It's not about supplanting browser features for the sake of establishing a site-wide or web-wide standard.
---
It's about making the user feel like things that are out of their view and control are working properly.
---
When I look back on my childhood experiences with computers in the 80s and 90s I distinctly remember my litmus test for "is it frozen" was "can I hear those clicky noises from the hard drive".
Those noises told me nothing directly actionable nor did they accurately describe what had been done or what was left to be done. If, hypothetically, I ran an app caught in some bizarre infinite I/O hard drive loop those noises would have been misleading, and I eventually would have given up and hard-rebooted the computer
Spinning wheels generally act consistently; a loading bar such as this juts and pauses without any noticeable pattern. It gives us the impression that something is happening behind the scenes that we can't directly observe. If it acted uniformly we might just as easily believe that a dumb loop was living out its repetition.
Actual representation of reality is not the point. Perception is the point.
I'm sure that popularity could result in a harmful cliche-ification of this UI pattern, but I believe it has its place and its purpose. A browser cannot divine the amount of content that will be loaded on a dynamic site pre-execution.
At this point in time, at least, I don't mind encountering these loading bars. I can't really think of an example that irk me in any way. If I notice an in-site loading bar sticking around for a while there's probably something happening (or not happening) that would have pissed me off whether or not that loading bar were there.
> He promptly told me that 1) I was diametrically incorrect in my choice for meeting her needs, and 2) it didn't matter, even in the least.
This is why I hate talking to sales people in brick-and-mortar stores. Appearing confident rather than actually being correct is probably good for closing sales and for short-term customer happiness, but it's no good for the longer-term (ie, when you get home and realize you made the wrong choice).
> Appearing confident rather than actually being correct is probably good for closing sales and for short-term customer happiness, but it's no good for the longer-term
Well, that depends--and that's where my metaphor breaks down. The customers went home satisfied and remained satisfied (at least, that's what their consistent repeat business and smiling faces would suggest).
Tomatoes and website loading times matter to you in the here and now but don't have any lasting effect on your life. That's not the case for making a major purchase.
Yeah, it's definitely context-dependent. Buying the wrong kind of tomato may not matter if you're going to eat them for dinner that night. But if your plan is to grow tomatoes using the seeds from the ones you purchased, it suddenly becomes a bigger problem.
You can apply the same reasoning to this UI element. Sometimes - most of the time? - the user doesn't really care about the amount of progress made. They just need to know that something is happening. But at other times, they need to know how much time is actually left on the progress. If that's the case, you need to care about more than just perception.
Thank you, reading the first couple of comments really threw me off. I completly agree. Although the spinnging wheels works for me IF it say freezes when its not actually processing data or anything other than waiting for a response or something. I still personally prefer the progress bar, the best is combining the two. Showing that the computer (read: browser) hasnt frozen, and that we're progressing in time. Up until now, I was just wishing there was a better way of showing this other than a moving zebra stripe progress bar. This looks like something I'll use.
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.
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).
I find these fake progress bars a borderline-dark pattern: in general, the goal is to deceive users into waiting for progress that isn't truly happening, with the goal of holding their eyeballs.
It’s fake because even after you set the exact correct percentage of the progress bar, the progress bar still keeps moving forward on its own, even if your process hasn’t made any progress. The page says it itself: NProgress has “realistic trickle animations to convince your users that something is happening” – even if nothing is actually happening. The stuttering-forward is all about looking like something is happening, when it that is not necessarily true.
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.
If this is going to become a pattern, it probably makes more sense to allow the browser chrome to be manipulated in a way so progress bars aren't redundant (i.e. 'pjax' style loading uses the same bar as if you did a real page load, just like pushState allows for history manipulation.)
It would be cooler to see some guys get together and make a de facto standard, and then implement this type of control into extensions for FF/Chrome.
A couple weeks ago I built something similar, except that my solution is even smaller (doesn't depend on jQuery, 1 single file, 1KB gzipped and minified). Check out: http://buunguyen.github.io/rainbow.js/.
I'm more interested in the code needed to establish how much data needs to be loaded. Is it dumb file counting? Are they sending some sort of informational "header" before the data? If they're counting bytes, how are they doing that?
Thanks for pointing that out. I see it now and the full text has been since added to the repository. I was looking at the source and only saw copyright!
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.
Nice, but looking at the code I don't think really needs a jQuery dependency. Manipulating CSS classes, $extend, and the very basic DOM jiggering in this library could be accomplished easily without it. More and more people are removing jQuery in favor of frameworks like Angular and lighter weight libraries. Just my two cents.
I liked this idea but I didn't like the dependency on jQuery and I'm into AngularJS at the moment. So I've created a AngularJS Provider for basically the same thing. Check it out if you have time.
Great job, i have done some months ago something similar in a project (it's a portuguese project sorry :p ) : http://www.dizer.de/mografia/ , you can check the loading bar on the top, in form page. Start typing..
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.
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...
Very nice! Have you considered going by "Ricosta Cruz"? It sounds kind of cool that way. NProgress is perfect for something I'm just about to finish, thanks!
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()`.
Similarly, there might be a good reason YouTube is still using them? As with all things, the pattern may or may not apply to any particular app or implementation.
That said, I'm not in love with them on YouTube. They always catch my eye for just a moment after they're done loading about halfway, and makes me crazy.
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.
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.
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.
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.
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]
"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.