10 ms·
NProgress: slim, site-wide progress bars
- k-mcgrady 13y agoThis 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-website-loading-bars/ http://www.usabilitypost.com/2013/08/19/new-ui-pattern-websi...
- mef 13y agoyoutube.com does it as well.
- grey-area 13y agoThe iOS7 browser has an identical progress bar. I saw it in a leaked screenshot somewhere, I'm sure :)
- waxjar 13y agoChrome for iOS has/had it.
- Bluestrike2 13y agoChrome + Safari in iOS 7.
- NoodleIncident 13y agoDolphin browser for android does it too.
- bhauer 13y agoFirefox 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 13y agoI think the Android stock browser has the same blue progress bar - or at least my phone running CyanogenMod has.
- benburleson 13y agoAm I the only one that remembers SWF load-progress indicators and how retarded they were?
- robmclarty 13y agoI 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 13y agoThis 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
- mmcclure 13y agoWhat have you done...now I'm going to play Winterbells for the rest of the afternoon.
- ianhawes 13y agoAnddddd there goes my day. Winterbells.
- cbhl 13y agoToday I learned that Winterbells is now available on iPhone. What has the world come to?
- swah 13y agoThere aren't JS games close to this yet, right?
- 13y ago
- civild 13y agoI noticed YouTube had started using this (or at least the same idea), very subtle and sleek.
- krstck 13y agoI 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 13y agothe 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 13y agoMore on website loading bar: http://www.usabilitypost.com/2013/08/19/new-ui-pattern-website-loading-bars/ http://www.usabilitypost.com/2013/08/19/new-ui-pattern-websi...
- lmartel 13y agoI 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 13y agoYou're not the only one.
- jasdeepsingh 13y agolooks really slick.. looking forward to build this as an AngularJS directive or such. :)
- rxaxm 13y agoi'll be watching your comments 'til you post this!
- LadyMartel 13y agoI 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!)
- diggan 13y agoDirective 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/ http://victorbjelkholm.github.io/ngProgress/
- vvpan 13y agoI 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 13y agoThose 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.
- cbhl 13y agoI 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 13y agocoould be good for mobile apps as well!!
- level09 13y agoThis 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 13y agoI'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.
- Lifebot 13y agoQuestion 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 13y agocompu-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 13y agoThat'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 13y agoThere 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).
- dclowd9901 13y agoIt'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 13y agoI 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 13y agoIt 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.
- Vendek 13y agoI 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 13y agoBut 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 13y agoGood, you started rethinking it by describing the problem. It's a start.
- Justsignedup 13y agoI always pre-fetch my life, so my life is instantly there.
- shawnz 13y agoAre 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 13y agoYou'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.
- Justsignedup 13y agoa) 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 13y agoWhen 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...
- bonaldi 13y agoThis 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 13y agoHi, 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 13y agoThat cursor makes me think that the browser has crashed/hung/is not responding.
- Bluestrike2 13y agoHonestly, 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 13y agoQuite 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
- platz 13y agoSo it just increments at random when you call Start, until Done is called (assuming setX isn't used)?
- roryokane 13y agoAs 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()`.
- bratsche 13y agoIt 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_ 13y agoThere 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.
- bratsche 13y agoYou 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.
- rstacruz 13y agoThe "placebo progress bar" UI pattern isn't new. 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).
- mistercow 13y agoCompare 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.
- Trufa 13y agoA lot of negativity here, I find this quite beautiful and useful for some cases where the UI allows it.
- hackerboos 13y agoI guess the fear is that this will become a trend and appear on pages that don't require it.
- gedrap 13y agoWell, 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
- tjholowaychuk 13y agowelcome to open-source :D haha
- mparramon 13y agoI'm thinking on forking this to remove the jQuery dependency. Would somebody be interested in this?
- gerrit 13y agoYes please
- mparramon 13y agoFollow 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-js.html http://developingandstuff.blogspot.fr/2013/08/nprogress-no-j... As preparation for a talk: https://twitter.com/mparramon/status/369945214494191616 https://twitter.com/mparramon/status/369945214494191616
- knodi 13y agoI like it, looks good.
- chrisfarms 13y agoIs 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 13y agoVery 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.
- kmfrk 13y agoBeen looking for a good load spinner for my AJAX. This looks perfect. Thanks so much.
- mistercow 13y agoIt'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.
- terabytest 13y agoOne 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 13y agoI 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.
- rgrieselhuber 13y agoStripe used to do these and I always thought it was cool but there might be a good reason they stopped.
- bmelton 13y agoSimilarly, 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 13y agoI 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 13y agoHow is this "fake"? I can set the exact percentage of the progress bar.
- roryokane 13y agoIt’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.
- stinky613 13y agoI 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.
- the_cat_kittles 13y agoVery 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 13y agoI'm not sure about that—"Rico Sta. Cruz" isn't some pseudonym I can restyle, it's my actual real name :)
- anigbrowl 13y agoNot 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 13y agoThanks for the insightful article. On a tangential note, that link's home page is easily the weirdest thing I've seen all week.
- hyperplane 13y agoIf 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 13y agoWe 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
- marcamillion 13y agoThis 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.
- msteinert 13y agoI don't see any license specified. Is there a plan to license this software?
- cbhl 13y agoREADME on the GitHub repository says MIT at the very bottom, but agreed that it would be nice if this was more prominent.
- msteinert 13y agoThanks 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 13y agoCopyright 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.)
- lhadron 13y agoNice, 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 13y agoA 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 13y agoI'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 13y agoRelevant 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
- tzaman 13y agoAlways wondered why a trivial library like this one couldn't be dependency-free (jQuery mostly)
- miguelmendes 13y agoGreat 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..
- diggan 13y agoHey 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/
- jheriko 13y agomost people don't even notice this is there based on quick real world testing. sorry...
- RyanN 13y agoI 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.
- ShaneCurran_ 13y agoWould I be correct in saying this is now used on YouTube?
- ShaneCurran_ 13y agoWould I be correct in saying this is now used on YouTube?
- pelle12 13y agodoes this work well for mobile sites? like in jquery mobile?