I like the presentation and I understand the reason why people would want to use this thing.
That said: Please.. Show static content first. Don't do the Blogger thing. That looks
- ridiculous
- stupid
- like Geocities did
In other words: For 'apps', games etc. this looks really neat. But a website, say a blog..., shouldn't need to show a progress indicator before any content shows up.
We totally agree. PACE doesn't block or change the rendering of the page at all. You should use PACE if you want to provide your users with additional information about the progress and activity of the page load and future ajax requests.
The poster you are replying to is using those bullet points to describe the loading bar used on Blogger, which probably has nothing to do with this loading bar other than the fact that they are both loading bars. It's being pointed out as a poor usage of loading bars for anyone that might considering using this one (i.e. "please don't use this tool in a place where it makes no sense").
I don't really think this is what is at play here. There is no doubt that delivering a complete web page (when possible) is often preferable. The question here is, if your page is going to take x milliseconds to load, will it seem faster with a progress bar? The research says it does.
This is a terrible UI experience. Note: I have been living and working with iOS 7 since the first beta. I know it's new and shiny to everyone else, but this is absolutely the worst thing to add to your site. It serves no functional purpose and just clashes with devices that do this natively.
Why not just detect which browser is viewing the site and not show the progress bar for mobile and safari browsers? That should solve this "double watch" issue.
Because broswer detection is an anti-pattern , and you dont know in a few years if chrome will do the same... Will you go back to all your projects to fix them ?
There are plenty of options that don't look like the iOS loading bar. And it does serve a functional purpose. Manipulating the user's sense of time is an important part of improving UX.
"really" being the key word. if it's not immediate, it's good practice to show some sort of loading indicator, and neither angular or backbone are immediate.
This is fantastic, and surprisingly worked perfectly with my own super complicated browser-side AMD style module loader. I'm very impressed that it "just works" and seems like magic. Thank you so much for making this! (seems like everybody else is complaining, HNers are so ungrateful)
Smart. There was a study recently that showed that the barber pole style of progress bar in particular did make people perceive things as faster, but I imagine it has a lot to do with how long the delay really is.
It looks very pretty, but sadly my Macbook Air couldn't quite keep up with everything happening on the page. My ability to even scroll kind of stuttered to a stop.
Not sure why a loading bar needs to be so resource-intensive.
(Granted, I'm plugged into a high resolution display, but even so most sites I visit don't have issues like this.)
Here's my take: this is very valuable on sites that dynamically load new pages without an actual browser navigation (read: pjax).
It is not useful (and indeed it is an anti-pattern) for static sites in which case you'd want to just use the browser loading mechanism, that the user (hopefully) understands and is used to.
This is just like NProgress except even better and easier to use - thank you for sharing this!
The only caveat I encountered with this was that I had to update the z-index in the generated css file to "999999" for it to work with bootstrap. Notable, NProgress has the same incompatibility with bootstrap.
I see the article was published on the 18th, and hubspot created the repo on the 11th, so I wonder if this was just a coincidence. Either way, nice work
We were inspired by a number of sources. We loved NProgress when it came out, but felt that mixins `Nprogress.set` calls into our code was cumbersome. After we started work on (what was originally codenamed MProgress (https://github.com/adamschwartz/mprogress) ;), Codedrops published their article. We were psyched because we thought we had an even bigger opportunity. So we curated and crafted the best themes from all over the web (Codedrops, included) and coupled them with the easiest-to-configure progress bar solution out there.
Notes...
To get it over the bootstrap navbar I z-indexed to a million.
The ajax calls on my site seem to happen too fast to invoke. Fast pageloads are the benefit of no traffic!
It doesn't seem to work with Firefox 25 + Ghostery, I don't see a loading bar and all the examples are empty white boxes. Disabling Ghostery it works properly.
Sure, it's an input type="color" with some css applied to it. On webkit, it becomes a picker, on other browsers, just a text input.
When it is changed, we loop through various elements and change their background color. The way the themes are generated is a little more complicated, but I don't think that's what you're asking about.
Let me know how it goes. We don't specifically monitor the loading state of images right now, (although the document readyState will be effected by images). If it doesn't seem to work right for you create an issue and we'll add image monitoring.
That said: Please.. Show static content first. Don't do the Blogger thing. That looks
- ridiculous
- stupid
- like Geocities did
In other words: For 'apps', games etc. this looks really neat. But a website, say a blog..., shouldn't need to show a progress indicator before any content shows up.