New UI Pattern: Website Loading Bars | Hacker News Reader

New UI Pattern: Website Loading Bars

usabilitypost.com

190 pointsanon1385124 comments

I implemented this on the Package Control (https://sublime.wbond.net) site over the past few months while developing it.

To get a smooth transition from page to page I use Backbone.js with pushState and Handlebars to do client-side rendering of various pages. This allows for nice subtle touches like the logo fading out when navigating to a package detail screen and the search bar animating position when switching from the homepage to the search page.

The thing that was missing was any sort of indicator that the page was loading. A progress spinner at least indicates some sort of activity, but can be relatively useless is knowing when something will complete.

To provide a better progress indicator, I used a combination of the XHR readyState value, plus the number of total bytes downloaded when in readyState 3 to set the width of a bar. I then used a CSS transition property on the width property to have the bar smoothly grow from one width to another.

Originally I had tried using JS to animate the width, but CSS transitions seem to do a much better job of creating a nice smooth animation. The downside is that IE8 and 9 aren't supported, but I just do full page refreshes with them anyway since they do not support pushState.

What did you use for making "Installs" plots?

I used D3 and adapted some of the code from http://bl.ocks.org/mbostock/3943967.

I tried to recreate this effect in raw JavaScript.

http://fiddle.jshell.net/zuBDW/2/show/

It doesn't load new content with ajax, nor does it pre-fetch. It just shows a website loading bar. I think this UI element is very nice. Especially for heavier pages, showing a website loading bar might combat users leaving, as something is happening.

For Ajax-loading I think it is a nice alternative for a center-center spinner.

The importance of something happening is actually quite important for many users (I've found). An absurd example of this can be found in one of my one-off projects: http://gifmachine.xwl.me

The first version of this didn't have any kind of gloss, just 2 text inputs and a "go" button.

I showed it to some people I know and their immediate recommendation was to have some feedback to see how long things where taking. However, I didn't have any kind of a way to actually tell the user how things where going, so I took the next best approach: I fake it.

If you look at the source code, you'll see that when you press the "make a gif" button it starts loading the loading bar. That loading bar is totally useless, as it is entirely client side and shows no progress at all.

But people love it! Everyone I showed it to said it was a big improvement, making it nicer to use.

Even though it's a fake loading bar.

It is an improvement:

1. It lets you know that you clicked the go button correctly and that the computer isn't waiting for more input (perhaps you could disable the inputs as well).

2. It gives a user a reasonable expectation of how long the process should take i.e. it's not instant and they have to wait a bit.

(Clicking on "Make a gif" without putting in any input at all takes me to a non-existent gif: http://i.xwl.me/9539b2.gif)

The internal console at the company I work for has something like this (although it admits to being fake). The only complaint I have about it is that if the operation actually hangs, the bar reaches the end and just sits there, which is somewhat problematic.

I [fake upload progress][demo] for browsers without xhr2. To be consistent with the unknown file size and progress, the bar progresses asymptotically, and thus can never reach the end. It is also consistent in perception with what the user expects: a short upload has a fast bar (because it doesn't stay long enough to be slow) and a longer upload has a slow bar (because the fast part is comparatively much shorter in duration compared to the slow one). It is also consistent on the final part, i.e when it jumps to the end: if it was a small file, the bar was cut early yet growing fast it is expected to cross a bigger chasm.

[demo]: http://codepen.io/lloeki/pen/ydmCh

On OS X and iOS there are two different kinds of progress bars. Normal progress bars and indeterminate progress bars. Normal progress bars are used when you know the actual progress. Indeterminate progress bars are used when you don't know the actual progress and you don't know how long it will take.

Here is a video showing an indeterminate progress bar:

https://www.dropbox.com/s/mko66awdbwy6xzu/pb.mov

This is similar to bootstrap's .active.progress-striped progress bars[0].

We use bootstrap already, but I wanted the user to feel a sense of progress, whereas the indeterminate ones merely give a sense of action.

The iOS Messages app has a SMS progress bar that is totally fake: its duration is actually the mean duration of the last time it took to send SMSes, and is made to fill up to ~80% in that duration. It takes advantage of the knowledge that the exact same task takes about the same time. So despite being fake, its progress statistically makes sense and gives valuable, quantitative feedback to the user.

[0]: http://getbootstrap.com/2.3.2/components.html#progress

Am I the only one who thinks fake bars are an awful idea? If you don't know how long the operation is going to take, why not just use a throbber or an oscillating bar or something? A fake bar just messes up the conceptual model that people build while using the app. Especially when the thing is broken for some reason.

I was thinking this should be position fixed in case you are scrolled half way down the page - you would not see the position absolute bar at the top, but it should be attached to the browser navigation right? The issue with position fixed is getting it to span the full width... any thoughts - maybe my UI sense is wrong here too?

[edit] Actually, doing a little testing on it now - position:fixed seems to just work. I like this solution a lot need to test it out... would be great to attach this to xhr progress events...

Yes, good catch. If you want to recreate the Youtube bar, you'd need position fixed. For this faux-progress bar, position absolute works most of the time, because you usually load a new webpage without scrolling down.

Keep in mind though that if part of your loading time is parsing large amounts of JSON returned from your backend, this blocks the main thread and your loading bar will be stuck for that time.

This is where web workers will come in handy. I did a little promo video tutorial on loading data with Flickr using web workers. You can watch that at http://www.youtube.com/watch?v=4eDl1UOkp18&feature=c4-overvi...

I can't wait for those to be useful everywhere.

Are there any implementations of a task queue using web workers? It would be cool to have something where you can just decorate a function to do it on the web worker's thread instead of have to manually write the postmessage and onmessage stuff and have a separate worker.js

This would be nice for long-running requests (i.e. payment submissions).

This seems like the very definition of solving the wrong problem, especially for something like Medium.

My thought exactly. If your site is taking so long to load that you feel the need for a progress bar, it's time to trim the fat.

Youtube videos already have their own bar, why is the rest of the page so bloated that it needs bar? All the thumbnails? Maybe it's time to stop loading so many by default. Too many widgets for comments, ratings, favorites, etc.? Again, time to cut down on all the widgets.

Medium really needs to trim the fat. I was scraping[0] and I noticed they send their content twice! Once in HTML and once as a Javascript object.

(0) http://mediumsearch.herokuapp.com

I don't think so. As more sites move away from full page refreshes toward just changing the DOM (using Angular, Backbone, Turbolinks, etc.), I think we're going to see way more of these.

The problem is that you can never rely on a load being fast. If you trim the fat on the app side and get a pageload down to 100ms, it might load almost-instantly for you on a 100Mbit/s connection.

But it still won't for someone on a 768Kbit/s DSL connection. In that case, you can't just let them sit there for a second or two with no feedback. A loading indicator is necessary for those instances.

I agree that sites should trim the fat and make pages load as quickly as possible so that a loading bar isn't really necessary. But you have a) instances where you're not in control of load times, like when you're relying on an external API (like Facebook, for example) to return data, and b) even if your app is blazing fast, you're still subject to slow connections that necessitate a loading bar.

I think in cases where you are loading significant external data that may take several seconds a loading bar is appropriate; see for example the loading bar on a Youtube video. Perfectly legitimate. Or a loading indicator on a gallery of thumbnails. Appropriate uses.

But the page itself should not necessitate a page wide loading bar. That's a design flaw. Your page is bloated. Even a 768Kbit DSL should be able to load the page itself rapidly. If you're beyond that just for the basic page itself then you've failed in your job as a designer/developer, IMHO.

And I've designed web apps that never actually send you to a different page (just update the DOM), and in my experience they are extremely fast. Even making many API calls retrieving tons of records to a very modest server. That design is not in and of itself a reason to have load bars.

Agreed. The whole point of a client-side update mechanism is to do something better than a loading bar. And that thing should be (1) immediate and (2) particular to what the user did.

It's like there's a Law of Conservation of Bloat: browsers are hugely fast; computers are hugely fast; even broadband is getting to the point of usability (in North America) -- how can software tumors metastasize? Where is there an opportunity to slow things down and make them shittier?

It sort of puts paid to the idea of progress.

>Wirth's law is a computing adage made popular by Niklaus Wirth in 1995.[1][2] It states that "software is getting slower more rapidly than hardware becomes faster." - Wikipedia

There's also a related "law": “What Andy giveth, Bill taketh away.”

Bill clearly seems to be Bill Gates, but who is Andy? I would have expected "Gordon Moore", or... :-)

Andy Grove was CEO of Intel

> "software is getting slower more rapidly than hardware becomes faster."

I used to think this was true. For me, the perceived inflection point where perceived speed of software started improving was somewhere around 2008. This may be because I switched to a mac in 2006 and the releases around that era had a big performance focus.

How much patience did people have back in the 90s when broadband and computers were slower? (Hell, it sometimes took 30 minutes just to dial into AOL without getting a busy signal.) Now that computers and broadband are faster, do you think people have just as much patience as before or less?

I'd imagine that, until broadband becomes truly instant, you will have a need to ensure users that the page is still loading. A user's patience will never grow. It will only shrink. The least we can do is buy ourselves precious seconds by using a progress bar. It is the difference between "Your call is important to us, please hold" and "You are now 5th in line to be answered. Please hold." The illusion of progress goes a long way in fooling the user's brain into having just a smidge more patience.

Well, OK, but that's orthogonal to the question of: what is causing this bloat, and why is that considered sacrosanct, as opposed to the user's time and energy? Reasonable people can disagree as to where that line is drawn, of course, but with sheerest garbage like Medium, where the putative goal is to give people something to read, it looks to me like they're driving a process for the sake of driving a process, and deserve to be mocked for it.

It's only a matter of time until someone rewrites the whole browser in JavaScript and is lauded for it as the genius of Web 3.0.

Why stop at the browser? http://bellard.org/jslinux/

Well in that case the term "genius" is inadequate.

"Induced demand, or latent demand, is the phenomenon that after supply increases, more of a good is consumed." http://en.wikipedia.org/wiki/Induced_demand

Medium is not even the worst, it’s quick and I’ve never seen that progress bar. Blogger/Blogspot is my most frustrating online experience when I have to read text: it’s very slow to load even on a fast connection and shows fullscreen spinning cogs, breaks Safari Reader on desktop and mobile, overrides gestures and makes me lose track.

Really, you don’t need Javascript to load a page of text.

I only see it on medium after losing internet connection.

Agreed. To me, the gears make it feel that the page is taking longer to load. It's especially rubbish because the page that loads is normally just text and static images, not some complicated webapp. Should have been fast to begin with.

Because the team who developped these stupid templates dont care about users, that's a fact. Or why would they do that ? they just want to kill their plateform and move on. that's the only explanation.

Blogger is insane with that loading bar. If it's a page of text, the blogger-spinning-logo probably takes more bytes than the content.

Bingo.

I like using this for ajax file uploads. For example, in a photo gallery with thumbnails already occupying the client area then it's a convenient place to indicate upload progress from a drag + drop without placing a temp element in the grid or overlaying some other element with progress info. I'm not sure how well it solves the problem (usually I'm just interested in general file progress and not a specific percentage) but it does give a good indication of progress in a convenient location.

This belong in a reddit post with the title "if you think your website needs this: fuck you and the horse you rode in on".

I've seen blog sites whee an idiotic spinner comes up for a few seconds while something or other is "loading". Something or other that is ultimately going to show me some text.

I wish people would leave page loading to the browser, instead of using half-assed JS that breaks every so often.

> I've seen blog sites whee an idiotic spinner comes up for a few seconds while something or other is "loading". Something or other that is ultimately going to show me some text.

You must be talking about every single blogspot.com site.

It seems to me that HTML5 needs an endpoint to handle AJAX and COMET-style loading. Fewer and fewer web pages actually use reloads all the time, content is just retrieved and switched out with JavaScript.

Loading bars are necessary, and they certainly aren't new. The browsers just need to be updated.

Since we're seeing a lot more of these kind of single-page apps, it might be wise for the browser vendors to implement a JS API to trigger the loading indicator on-demand, so it would show the loading UI that users are already familiar with. Has there been any movement on this?

For browsers that also show a loading progress bar (like Safari), it could also allow the page to set a precent loaded value. XMLHttpRequest2 supports progress monitoring.

That's a great idea.

COMET is in HTML5 already: http://www.w3.org/TR/eventsource/

An earlier version of Safari mobile showed a loading wheel whenever it was loading AJAX/COMET.

I found it infuriatingly annoying: it displayed at inappropriate times, when something was happening in the background but the user was not waiting.

Unfortunately this is not something that can be handled well by the browser.

The New Republic uses something like this in a cool way. As you scroll down the article, a progress bar on top shows how far you are through the article.

Try it: http://www.newrepublic.com/article/114362/odds-clinton-dies-...

because the browser scrollbar doesn't work well enough?

while i mostly agree, it does make it clearer that it's your progress across an entire article: with just the scrollbar you never know if you'll be facing "page 2, 3" links at the bottom.

If the article was on one page this wouldn't be an issue.

It's still an issue...

I often wonder how far an article really goes. A lot of the times there are tons of content below the article, or perhaps just a long commenting thread twice as long as the article itself (or, as stated, a multiple page article (which you don't know about in advance)). I often scroll down for the sole purpose of finding out how long the article is.

I really like the information the New Republic conveys (but I dislike having a bar on top like that).

What is it with these sites that break down articles into several pages? NYTimes is a particular culprit that annoys me. Does anyone find an article easier to read in this format? I presume it is to force more Ad views on people?

>I presume it is to force more Ad views on people?

Yep

There's some research that, that people like content paged.

Here's one such paper http://hfs.sagepub.com/content/25/3/279.short

Because the browser scrollbar indicates where you are in the page, not your progress through an article.

What if there are 500 comments at the end of the article?

Looks as if it's only the length of the article body.

A little superfluous, but I can dig it.

Or you're a Mac OS or iOS user and the scrollbar will be invisible when you're not scrolling.

So because one browser developer fucks over its UI, you should fuck over the UI of all other browsers, too?

because the browser scrollbar isn't necessarily present on a Mac.

On touch screens it usually disappears?

please this is not cool at all. Seriously, why we need another scroll bar on top. Because they create cool ngprogress and you want to be creative with it ? Nice try but due to my point of view, this doesn't work.

The problem with loading bars is that they lie. They promise a linear view of a 0-100% process that does not proceed linearly. Instead, they sputter and freeze, and most frustratingly often seem to get stuck at around 95%. Believe me, telling your user that the page is 95% loaded and then freezing for several more seconds is much more infuriating than a simple spinner.

This behavior goes way back to software like Real Player (buffering...), Windows Installer (which would actually hit 100% and then reset to zero for another round), and is seen today on YouTube, Netflix, and the browser's own feedback bar.

Can you predict the next few seconds of network bandwidth? Do you know the relative times of content downloading versus parsing json and browser rendering for various clients? All these play into the feedback you're promising, and you don't really know.

Here is a nice implementation example. http://www.ynh.io/2013/05/24/rebuild-youtubes-progress-bar.h...

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

Excellent. I was actually looking for an article about Medium- and YouTube-style loading bars this morning.

YouTube seems to actually track loading progress with their bar.

Medium's uses CSS animations to create a sort of "ticker" effect that doesn't actually convey progress, but rather activity. Still, this is pretty cool.

This is going to get pretty darn confusing for people running iOS7 Safari. http://imgur.com/Mv8lu1J

Just to mention where this comes from: iOS 7. I don't like it on the phone, and it's a bad experience on the web. I'm a firm believer in subtlety in user interfaces, but this is so subtle that it's nearly invisible.

Not necessarily IOS 7 [though maybe it popularized it]. There's a number of android apps (firefox, reddit is fun) that do the same thing and I don't like it there either. I'd prefer some kind of larger more noticeable way for me to see that it's loading, and that it's actually doing something. Sometimes if loading is slow it's easy to not notice these 1 pixel bars changing.

Also empithany (the gnome 3 browser) used it before

Yeah, this isn't at all coming from iOS 7. Most any Android app that loads some content in an embedded web view uses this pattern.

This is also in Chrome for mobile.

I wouldn't call it a bad experience nor subtle however - at least not on mobile devices; I noticed the progress bar the first time I used the app and it never gets in the way.

Facebook seems to have a much better solution to the AJAX-loading progress problem. It looks like they use an iframe as transport, which causes the native browser spinner to appear. Much better than a custom design.

Of course, it would be even better if websites could programmatically enable/disable the browser progress spinner, in much the same way we are now trusted to mess with the history API.

I use this on my site.. but for a different reason. Showing scroll location on very long articles. Like this one http://paulstamatiou.com/android-is-better

I was actually going to also have it display a toast-like "7 minutes [of reading] left" on the top left when you scroll a good amount.

Hey, just a heads up -- it looks like your SSL certificate is mismatched to your domain, and chrome throws up red flags over it.

oops, that's because I don't use ssl and typed it in incorrectly :) I should redirect it though

Why? There's a scroll bar in the OS that does exactly the same thing. At the same time. But accurately.

which automatically hides

If you want to see it you can quickly get it (at least with the latest Mac OS, I don't know about Windows).

Having a thing across the top is perpendicular and doesn't relate to the vertical structure of a scrolling page. You have change the vertical position of your eyes to see it in a context where vertical position is significant.

Using a horizontal bar to denote vertical position is a tad unintuitive. I feel like this doesn't really solve the problem you are talking about, and instead adds to the confusion of readers who notice the bar.

Edit: Keep in mind that as I'm reading the story, my eyes are nowhere near the top of the browser. If you want to give me context, the top of the page is not the best place to provide it. It does make for a cool demo though.

Actually I read the article but never noticed that scroll locator at the top. Anyways it is kind of useless if you are on windows where the scroll bar is always in the view. Anyways nice article!

I made a jQuery plugin called Progress to do this. https://github.com/RyanNielson/jquery-progress

I whipped it up pretty quickly so if there are any issues or enhancement ideas feel free to post them on Github.

It is very nicely done at the ST Package Control website - https://sublime.wbond.net/

I noticed that yesterday. Cool effect, and seems simple enough: just using CSS transitions to change the width across a certain interval.

"Does a web page really need a loading bar, especially that the browser already has a loading indicator of its own"

Neither Chrome nor Firefox (at least on Windows or Linux) have an implemented loading bar for showing a web site's progress. I cannot speak to Internet Explorer 8 or greater because I tend to avoid them at all costs (and my company's system only has 7).

When a page is loading under Chrome on Linux, a spinner is show in the tab where the favicon is normally displayed. It isn't a "progress bar" but it is an indication that the page has not fully loaded yet.

Chrome does that spinner on Windows, too, as does Firefox. I'm glad for it but I like the progress bar idea, personally. It gives me a sense of progress. It is kind of like being on hold. It is the difference between "Please hold" and "You are number 4 in line. Please hold."

Sidenote: The Amazon App Store app on Android does something similar. I've seen other apps do this as well but I can't think of them at the moment. Is this a design pattern we will see more of like the Ajax spinners of the Web 2.0 craze?

I like it. Progress bars aren't immediately obvious, especially in a browser like Chrome. I have watched people when doing our usability tests and they click several times or try to reload on certain slower pages because they can't tell anything has happened.

If your browser has a non-obvious loading indicator, I'd say that's a problem with the browser UI and should be solved there, not on websites.

It has appeared to me that there are pageloading techniques that interfere with browser spinners. Many times a page is loading and there is a plain arrow where on other sites it shows a spinner.

absolutely, but we don't have a lot of control over that.

However, websites can't control what browsers their users use, nor can they control how those browsers give feedback regarding load times.

They can control their own code.

Not saying that websites should implement this, but companies aren't going to want to point to browsers being the problem. Every company wants to (try to) control their users' experiences, for better or worse.

Seeing this on Youtube made me realize how slow the page loading really was. Medium's is even worse: my mind processes the bar as taking a good 5 seconds, primarily because there seems to be 3 phases of the bar moving. I don't like it at all.

A colleague of mine did this for a large project we worked on which needed to load a lot of video assets: http://download.kone.com/ultrarope/index.htm

I think it's more important to try and emulate the native browser loading behavior first. I threw together an example with an iframe and a resource that never completes:

http://loadlet.herokuapp.com/

Extra loading indicators may be nice, but I think that a native feel should come first.

My team just released our version with turbolinks/ajax support.

https://news.ycombinator.com/item?id=6245244 http://jqueryajaxloadingbar.herokuapp.com

1st Ave Machine used to have that feature, their site was (and is) rather heavy.

They changed the website look and feel, had to look up the release date of the video for which I first saw this UI pattern (Sixes last by Alias): 2005

Edit: site now: http://1stavemachine.com/

I'm surprised outlook.com hasn't been mentioned yet, which does a similar thing, but with flying dots.

Saw this on Youtube last week. It's good, I guess, in that it's easy to understand straight away. At the same time, I find it kind of useless eye candy, and I can't interact with it. Usually when I experience a slow load I find a ridiculously high number next the Ghostery icon.

Coincidentally I noticed this pattern just yesterday here: http://paulstamatiou.com/android-is-better and I really like it. The scroll bar isn't enough to tell how much reading is left.

I think that's more of a reading progress bar than a website loading bar. Still pretty slick though.

That's brilliant! I always find myself looking at the scroll bar to see how far I've gone, but this is much more convenient.

Are you serious?

The scroll bar isn't enough to tell how much reading is left.

I hope you're missing a </sarc> tag there...

Scrollbars are virtually non-existent on Macs these days. Plus this works well on touch-based devices too. Overall, I like the concept and find it useful as well.

Edit: I'm referring to the reading progress bar concept, not to the loading status referenced in the original post.

Fair enough, and good point on the touch-based devices, I can see how it would be useful for those. I don't use a Mac, so can't comment but same applies.

Scrollbars aren't but they still show on a scroll event (unless I'm mistaken - I'm only using 10.8).

A lot of comments or post-content links/ads disrupts the usefulness of the OS scroll-bar.

I can't recall right away what website had it but if I read a really long article on my mobile phone, it showed a similar bar on the top but that was showing me progress on how far I had read. As iOS hides the scroll-bar once I stop to read, I found it a nice touch.

Here's a general-purpose JS implementation of a progress bar that achieves a similar visual effect: http://ricostacruz.com/nprogress/

That's a built-in feature(?) of GNOME Epiphany (as visible in http://www.youtube.com/watch?v=cFoEYkztAfY for example).

Slowly but surely HTML5 and JavaScript are turning into Flash.

Blog post from 2014: How to create beautiful HTML5 intros to your web page.

Given how much of the web is dynamically loaded now, it seems like there really out to be a built-in API for displaying load progress to the user.

Isn't the point of dynamically loading content to reduce the perceived waiting time though? I wonder if focus on cleanly showing the user the page is rendering might be better placed on getting content to load faster instead.

At the UI level, perceived time is usually more important than real time. Half a second with nothing happening feels long. A whole second with feedback in some form (a loading bar, a spinner, etc.) feels fast.

For longer wait times, this becomes critical. 5 seconds with no feedback feels incredibly, ridiculously long. 5 seconds with feedback feels like completely reasonable. I sometimes use almost entirely fake progress bars which asymptotically approach full when I have no way to measure how long something will take. It's bizarre, but even knowing that the progress bar is fake, watching it fill up makes the time seem shorter than staring at a spinner.

Actually improving loading time is important, of course, but the ROI is tiny compared to basic user feedback.

There's another loading bar example on http://www.jellibug.com

I've seen this on YouTube, I actually like it but it should be in the browser not the page.

I don't see the ones on Medium or Youtube. I'm using Firefox on Win7.

They don't appear on the initial load, only when you switch between pages on the site.

My old company SquidCube had this over a year ago.

Reply on news.ycombinator.com