Automatically Add Loading Bars to Your Website | Hacker News Reader

Automatically Add Loading Bars to Your Website

github.hubspot.com

122 pointsafschwartz50 comments

Open articleView on HN

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.

this isn't doing anything like that!! It's just reporting progress, the content still loads just fine.

do you really need to use a list of adjectives like that, if you don't understand something at least try to be a little polite about it.

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.

You could also use it just for ajax navigation.

Can't upvote this enough!

No, please, stop, don't do this.

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.

Sincere question: what does this have to do with iOS 7?

Putting a thin progress bar at the top of your page is competing with Mobile Safari's thin progress bar at the top of your page.

Aside from the whole Department of Redundancy Department feel, they both display progress at different rates.

"A man with a watch knows what time it is. A man with two watches is never sure."

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 ?

Check out the "minimal" one on the page. iOS's new web progress bar looks like that.

I think Chrome Android has this sort of progress bar way before iOS7.

Chrome for iOS as well.

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.

Or you could just speed your site up so you don't need to show someone a progress bar.

Or use Angular or Backbone and then you really don't need a progress bar.

Yes, do this instead. Seriously, unless you're showing me his-res images from The Louvre, just give me the content as quick as digitally possible.

We use Backbone heavily, moving data between the client and server can benefit from a progress indication.

What does using Angular or Backbone have to do with needing a progress bar?

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

HERE WE GO!!!!

Another HN fanboy talking crap about scalability (of which he likely knows nothing) and claiming that his favourite magic bullet will save the day.

This is the straw that broke my back. I'm no longer going to lurk.

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)

Thanks so much!

Good God, why would I ever want to see Loading Bars on a website.

If you can't front-load enough to give 100 bytes of text to read, don't bother answering my http request.

A team related to mine released a new UI for their software. It included a loading bar, of sorts, while it was loading a new page on the tool.

Users complained it was too slow. They removed the loading bar. Users stopped complaining it was slow.

I've since stopped trying to find new ways to add loading bars, and just focused on making my software faster.

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.

In that case, I definitely want to add a loading bar so I can do a subsequent performance release by just removing them. ;)

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

I'm on a Pentium-powered Dell, and it works great! HyperThreading FTW!

You're also looking at a bunch of them all on one page along with other animations. We haven't had any issue with real-world usages.

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.

Second take: whhhhhaaaaaaaat native color pickers!!? That is really neat, must have missed that addition.

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.

Strange enough, codrops recently published an article with very similar effects and styling: http://tympanus.net/codrops/2013/09/18/creative-loading-effe...

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.

Just added a link to the credits section of the readme, sorry that wasn't there before.

Not bad - 8kb, drop-in installation, 9 designs for progress bar included.

Those interested might also be interested in a previous discussion on a similar progress bar.

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

Just FYI, the difference is that this progress bar is monitoring things loading on the page, that one is just an animation.

Looks great - works great! Thank-you!

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.

Yep, the perils of being a marketing company. Ghostery blocks all of hubspot.com. Shouldn't be a problem for people using the library though.

I'm actually very curious on how they build in the color picker into the site to designate the site's colors. Anyone have any knowledge on this?

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.

Yeah, I am pretty sure that you're correct.. This was a new input to me (<input type=color />) - learn something new everyday.

Looks great. I am building an image intensive app currently and will definitely be putting this to use. Thanks for sharing!

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.

Ghostery blocks it.

> Mac OSX

It's Mac OS X. Plus you shouldn't name it that. Call it Wave or something else.

Reply on news.ycombinator.com