
NProgress: slim, site-wide progress bars - ianstormtaylor
http://ricostacruz.com/nprogress/
======
mistercow
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/](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.

~~~
lelandbatey
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/](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.

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

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

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

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

~~~
mistercow
Compare the subjective wait for the spinner and progress ar in this demo:
[http://jsfiddle.net/gUkgX/1/embedded/result/](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
> since it will take a while for the user's brain to adjust to the slower
> speed

Wait, what?

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

------
lmartel
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
You're not the only one.

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

~~~
infinita740
This guy make fun of it in his flash games (progress bars go forward then
backward)
[http://www.ferryhalim.com/orisinal/](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

~~~
ianhawes
Anddddd there goes my day. Winterbells.

~~~
cbhl
Today I learned that Winterbells is now available on iPhone. What has the
world come to?

------
anigbrowl
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/](http://jfornear.co/the-pinterest-layout-will-not-save-you/)

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

------
k-mcgrady
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...](http://www.usabilitypost.com/2013/08/19/new-ui-pattern-website-
loading-bars/)

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

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

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

~~~
gedrap
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](https://news.ycombinator.com/item?id=6143604)

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

~~~
rstacruz
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
That cursor makes me think that the browser has crashed/hung/is not
responding.

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

~~~
gerrit
Yes please

~~~
mparramon
Follow this repo for more info:
[https://github.com/mparramont/nprogress](https://github.com/mparramont/nprogress)

Also, I'll be documenting the process here:
[http://developingandstuff.blogspot.fr/2013/08/nprogress-
no-j...](http://developingandstuff.blogspot.fr/2013/08/nprogress-no-js.html)

As preparation for a talk:
[https://twitter.com/mparramon/status/369945214494191616](https://twitter.com/mparramon/status/369945214494191616)

------
tuananh
More on website loading bar: [http://www.usabilitypost.com/2013/08/19/new-ui-
pattern-websi...](http://www.usabilitypost.com/2013/08/19/new-ui-pattern-
website-loading-bars/)

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

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

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

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

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

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

------
Lifebot
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?

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

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

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

------
ronaldx
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
How is this "fake"? I can set the exact percentage of the progress bar.

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

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

------
hyperplane
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
We decided to open source our loader @ Arthrex today, very similar but a
different feel.

[http://jqueryajaxloadingbar.herokuapp.com/](http://jqueryajaxloadingbar.herokuapp.com/)

[https://github.com/arthrex/jquery.ajaxLoadingBar](https://github.com/arthrex/jquery.ajaxLoadingBar)

------
bib971
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/](http://buunguyen.github.io/rainbow.js/).

------
dclowd9901
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
Relevant

[https://news.ycombinator.com/item?id=6238482](https://news.ycombinator.com/item?id=6238482)

[https://news.ycombinator.com/item?id=5761898](https://news.ycombinator.com/item?id=5761898)

------
Justsignedup
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?

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

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

~~~
msteinert
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!

~~~
cbhl
Copyright forms the basis of F/OSS licenses; if you don't own the copyright,
you can't put it under a F/OSS license in the first place.

Good to see that there's now a License.md file. (I would have called it
LICENSE instead, but eh, bikeshedding.)

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

------
RyanN
I just made something similar yesterday that shows a progress bar based on
amount scrolled through targetted content:
[https://github.com/RyanNielson/jquery-
progress](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.

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

------
diggan
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/](http://victorbjelkholm.github.io/ngProgress/)

------
miguelmendes
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/](http://www.dizer.de/mografia/) , you can check
the loading bar on the top, in form page. Start typing..

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

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

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

~~~
LadyMartel
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!)

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

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

------
the_cat_kittles
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!

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

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

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

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

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

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

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

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

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

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

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

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

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

sorry...

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

------
knodi
I like it, looks good.

------
tunato
coould be good for mobile apps as well!!

------
monsterix
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](https://news.ycombinator.com/item?id=6238482)

