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.
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.
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.
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.
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.
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:
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.
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.
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
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.
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.
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.
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?
>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.”
> "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.
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'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.
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.
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.
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?
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.
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.
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.
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.
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!
"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.
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.
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.
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.
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:
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.
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.
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.
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.
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.