NProgress: slim, site-wide progress bars

by ianstormtaylor • 13 years ago

597 140 13 years ago

k-mcgrady2• 13 years ago

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).

Edit:

Readme says it was inspired by Medium and YouTube - http://www.usabilitypost.com/2013/08/19/new-ui-pattern-websi...

mef• 13 years ago

youtube.com does it as well.

grey-area• 13 years ago

The iOS7 browser has an identical progress bar. I saw it in a leaked screenshot somewhere, I'm sure :)

k-mcgrady2• 13 years ago

That's where I've seen it! Thanks.

Kequc• 13 years ago

So what's the story here would one just look a little different from the other depending on colour choice?

waxjar• 13 years ago

Chrome for iOS has/had it.

Bluestrike23• 13 years ago

Chrome + Safari in iOS 7.

NoodleIncident• 13 years ago

Dolphin browser for android does it too.

bhauer• 13 years ago

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.

It gave me a feeling of nostalgia seeing this.

speeq• 13 years ago

I think the Android stock browser has the same blue progress bar - or at least my phone running CyanogenMod has.

benburleson• 13 years ago

Am I the only one that remembers SWF load-progress indicators and how retarded they were?

robmclarty• 13 years ago

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).

infinita740• 13 years ago

This guy make fun of it in his flash games (progress bars go forward then backward) http://www.ferryhalim.com/orisinal/

Brings lots of memories, I used to make flash games in school when I was 15. I always liked those little games. /nostalgia

mmcclure• 13 years ago

What have you done...now I'm going to play Winterbells for the rest of the afternoon.

ianhawes• 13 years ago

Anddddd there goes my day. Winterbells.

swah2• 13 years ago

There aren't JS games close to this yet, right?

borlak• 13 years ago

What do you mean? The SWF progress bars are one of the few that can actually be relied upon. A good example: http://armorgames.com/play/12141/kingdom-rush

The Microsoft installation progress bars are the ones I remember as being ridiculous. Often going backwards, showing ridiculous install times, etc.

mcintyre1994• 13 years ago

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/

fsckin• 13 years ago

Reminds me of this: http://www.schneier.com/blog/archives/2013/03/security_theat...

Sadly down now. :(

chavesn• 13 years ago

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.

civild• 13 years ago

I noticed YouTube had started using this (or at least the same idea), very subtle and sleek.

krstck• 13 years ago

I was just going to say that I thought I'd seen that concept before recently, but couldn't remember where. Must have been Youtube.

aeon10• 13 years ago

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.

tuananh• 13 years ago

More on website loading bar: http://www.usabilitypost.com/2013/08/19/new-ui-pattern-websi...

lmartel• 13 years ago

I hit one of the buttons in the demo and sat waiting for a doc page to load. After 5 seconds or so I realized that I'm an idiot.

I suppose that says good things about the bars, though; they really do signal "loading"...

justinpombrio• 13 years ago

You're not the only one.

jasdeepsingh• 13 years ago

looks really slick.. looking forward to build this as an AngularJS directive or such. :)

rxaxm• 13 years ago

i'll be watching your comments 'til you post this!

LadyMartel• 13 years ago

I want to build this as an angularjs directive too, but knowing me, it'll probably be not until winter when I finish. (So I hope you make it sooner!)

diggan2• 13 years ago

Directive wouldn't be the best I'm afraid. I've created a provider for it that can be viewed here: http://victorbjelkholm.github.io/ngProgress/

vvpan• 13 years ago

I hope progress bars will not be an excuse to build bad slow-loading websites. I think if you are not GMail you should stay away.

Bluestrike23• 13 years ago

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.

cbhl5• 13 years ago

I think that if I ever had to load your "fast" website on a dial-up connection I would hope that it had some sort of progress bar to fall back on.

tunato• 13 years ago

coould be good for mobile apps as well!!

level09• 13 years ago

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 ?

jrolfs• 13 years ago

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.

Lifebot2• 13 years ago

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?

Justsignedup3• 13 years ago

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 :)

Lifebot2• 13 years ago

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.

dclowd99013• 13 years ago

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).

jlgreco• 13 years ago

I don't think nearly so many people would find this idea objectionable if the loading bar was placed at the bottom of the screen, not the top.

snitko• 13 years ago

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.

Vendek2• 13 years ago

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.

ddunkin• 13 years ago

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.

Vendek2• 13 years ago

Good, you started rethinking it by describing the problem. It's a start.

Justsignedup3• 13 years ago

I always pre-fetch my life, so my life is instantly there.

shawnz• 13 years ago

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.

nc• 13 years ago

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.

Justsignedup3• 13 years ago

a) AWESOME JOB -- spent last 10 hrs making eh?

b) Awesomely devious! I love the fake loading animations. Dude you are a fucking genius!

c) Did I mention awesome?

sengstrom• 13 years ago

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...

marbletiles• 13 years ago

This gives the pointer a blue beachball on Mac Safari. Is that intended? Have never been sure what the blue beachball's supposed to be.

rstacruz3• 13 years ago

Hi, I'm the author of NProgress. Yes! It's intentional.

You can disable this by removing the `cursor: wait` rule in the CSS file.

lzm• 13 years ago

That cursor makes me think that the browser has crashed/hung/is not responding.

Bluestrike23• 13 years ago

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.

monsterix• 13 years ago

Quite some negativism in the comments below here!

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

platz• 13 years ago

So it just increments at random when you call Start, until Done is called (assuming setX isn't used)?

roryokane2• 13 years ago

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()`.

bratsche2• 13 years ago

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).

_greim_• 13 years ago

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.

bratsche2• 13 years ago

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.

mistercow4• 13 years ago

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. 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.

pearjuice• 13 years ago

since it will take a while for the user's brain to adjust to the slower speed

Wait, what?

tripzilch• 13 years ago

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.

Trufa• 13 years ago

A lot of negativity here, I find this quite beautiful and useful for some cases where the UI allows it.

hackerboos• 13 years ago

I guess the fear is that this will become a trend and appear on pages that don't require it.

gedrap• 13 years ago

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

tjholowaychuk• 13 years ago

welcome to open-source :D haha

mparramon2• 13 years ago

I'm thinking on forking this to remove the jQuery dependency. Would somebody be interested in this?

gerrit• 13 years ago

Yes please

mparramon2• 13 years ago

Follow this repo for more info: https://github.com/mparramont/nprogress

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

knodi• 13 years ago

I like it, looks good.

chrisfarms• 13 years ago

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.

NathanKP• 13 years ago

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.

adyus• 13 years ago

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.

kmfrk• 13 years ago

Been looking for a good load spinner for my AJAX. This looks perfect. Thanks so much.

mistercow4• 13 years ago

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/

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• 13 years 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• 13 years 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• 13 years 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.

wfunction2• 13 years 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.

dspillett• 13 years ago

I work for Microsoft as a UX prototyper.

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).

tlarkworthy• 13 years ago

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!

adventured• 13 years ago

Reminds me of this:

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.

lelandbatey2• 13 years 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/), 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• 13 years ago

This is a fantastic hack: it's fake, but everyone still loves it. It makes the user experience better. Nice work.

jabr• 13 years 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.

mistercow4• 13 years 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.

grinich• 13 years ago

The iPhone SMS sending bar does the same thing.

n1ghtmare_• 13 years ago

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.

WA• 13 years ago

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.

coldpie• 13 years ago

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.

gaelian• 13 years 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• 13 years 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• 13 years ago

That's funny, true and sad at the same time.

rgrieselhuber• 13 years ago

Stripe used to do these and I always thought it was cool but there might be a good reason they stopped.

bmelton2• 13 years ago

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.

ronaldx• 13 years ago

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.

hadem• 13 years ago

How is this "fake"? I can set the exact percentage of the progress bar.

roryokane2• 13 years ago

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.

stinky6132• 13 years ago

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.

mihok• 13 years ago

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.

jamoes• 13 years ago

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).

stinky6132• 13 years ago

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.

dclowd99013• 13 years ago

Usually, the customer themselves don't even know what they want. See: Malcolm Gladwell's talk on coffee.

the_cat_kittles• 13 years ago

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!

rstacruz3• 13 years ago

I'm not sure about that—"Rico Sta. Cruz" isn't some pseudonym I can restyle, it's my actual real name :)

anigbrowl• 13 years ago

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.

I suggest rereading this insightful article from last year when the Pinterest layout was flavor of the month. http://jfornear.co/the-pinterest-layout-will-not-save-you/

austinz• 13 years ago

Thanks for the insightful article. On a tangential note, that link's home page is easily the weirdest thing I've seen all week.

hyperplane• 13 years ago

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.

cleblanc• 13 years ago

We decided to open source our loader @ Arthrex today, very similar but a different feel.

http://jqueryajaxloadingbar.herokuapp.com/

https://github.com/arthrex/jquery.ajaxLoadingBar

marcamillion• 13 years ago

This gives me a spinning 'loading' cursor in Chrome on Windows 7 - for the entirety of the time it takes to load.

I don't like that - feels like the system is going to hang, and it feels more like a drag on my system than a regular progress bar.

msteinert2• 13 years ago

I don't see any license specified. Is there a plan to license this software?

cbhl5• 13 years ago

README on the GitHub repository says MIT at the very bottom, but agreed that it would be nice if this was more prominent.

msteinert2• 13 years ago

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!

lhadron• 13 years ago

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.

bib971• 13 years ago

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/.

dclowd99013• 13 years ago

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?

This bar's UI takes all of 20 minutes to make.

Bjoern• 13 years ago

Relevant

https://news.ycombinator.com/item?id=6238482

https://news.ycombinator.com/item?id=5761898

tzaman• 13 years ago

Always wondered why a trivial library like this one couldn't be dependency-free (jQuery mostly)

miguelmendes• 13 years ago

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..

diggan2• 13 years ago

Hey everyone!

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.

http://victorbjelkholm.github.io/ngProgress/

jheriko• 13 years ago

most people don't even notice this is there based on quick real world testing.

sorry...

RyanN• 13 years ago

I just made something similar yesterday that shows a progress bar based on amount scrolled through targetted content: https://github.com/RyanNielson/jquery-progress

I whipped it up quickly so I'm sure there's room for improvement. Feel free to post any issues or enhancement ideas on Github.

ShaneCurran_• 13 years ago

Would I be correct in saying this is now used on YouTube?

pelle12• 13 years ago

does this work well for mobile sites? like in jquery mobile?

NProgress: slim, site-wide progress bars

Related Stories