RWD Podcast Episode 5: Conditional Loading

This week our question comes from one of our subscribers, Ellis Taylor. Ellis replied to last week's newsletter and asked about best practices when it comes to loading in additional content at various breakpoints. Conditional loading content in responsive design using progressive enhancement methods and smarter content strategy.

Listen to episode 5

For me this opens up a few specific topics and I hope to touch on each of them to give you a bit more information to approach this issue for your own website.

Before we get into that though I just wanted to give a shout out to our newsletter sponsor this week. Moboom is running a free conference in San Francisco and it will be featuring Ethan Marcotte. Moboom also provide browser based responsive web site design/builder so you should check that out too.

Okay, lets look at this content query.

The first thing is really to look at the purpose behind responsive design.  The idea is that we produce a “one web” approach. This is a single source of content that will respond to the viewport (read device, screen size, orientation, browser width) to best suit the consumption of the content, or the facility to accomplish a goal.

Lets look at a map example.

Maps

Most people are going to have a business location on their website. We can provide a post office box, a physical address, a picture of a map, some instructions on how to get there etc etc.

On a desktop you probably would like the opportunity to zoom in and out of the map. You might want to zoom out to see the connecting roads that will help you get there, while you also might want to zoom all the way in to get a street view so you’re familiar with how it might look as you walk toward the location.

There are very few map based applications on your desktop that will allow you to do this, and if they do exist the chances are you don’t have them because google maps will do the job just as well if not better (maybe you will have google earth installed).

This all changes when you get to a tablet or a mobile device. Most of these devices ship with a mapping application already installed as part of the operating system (the iOS suite of products come with the initially ill-fated yet always improving Apple Maps; while the Android suite will utilise Google Maps.  For me, I have both on the iPhone because I find they are becoming more comparible and sometimes prefer the Apple Maps.)

With that in mind it is more limiting for a user browsing your website on the phone or tablet to find out how to get to your place of business by using a google embedded map; and if they’re not going to get the most out of the map it’s actually going to cost them more bandwidth and additional http requests for a substandard experience.

As a mobile user your far better off with a link to the map that will open in your mapping application of choice.

It’s situations like this where I am an advocate of the introduction of additional content as the viewport is increased. The reason is because

1. We start with a named link to a map
2. At a point where the viewport is largeenough the link will load in an interactive map.
3. At worse we’re always going to have alink to the information the user requires (regardless of viewport, device, or if JS is available).

Related Content

Another possibility is loading in additional content for users that are on larger viewports. This is often seen where a visitor will be presented with related content on larger screens because there’s a space available for it — and usually because someone is trying to fill the screen with content.

In this scenario we might want to not show the related content because it will be so far below the fold for the mobile user that it’s unlikely they’ll see it. It’s really a question of the reasons behind hiding it.

Is it because

1. You want to lighten the page weight forthe user
2. You don’t want them to have to see along scrolling page
3. You don’t think people on small screensare going to be interested in the additional content.

For me, HTML is really cheap. It’s very light weight and if you’ve got your server configured to send files gzipped then it’s going to be super small. This does get a little bit more complicated if you’re related content is going to contain images as well as they will each have their own http request, however in that case you could implement a lazy loading image script to ensure only images within the current viewport are shown (although I’ve got a big issue with that when I open an article to read before I get on the tube only to discover a bunch of content (images) has not loaded.

If you don’t want them to have a long scrolling page — well I’m not really sure if that’s a usability issue. I would look at the number of click actions your getting on your additional content elements and compare it between Desktop and Mobile devices (although a little off topic I can go through how to set this up in a later podcast if any shows some interest). But again, it’s not really a reason not to have it.

If you don’t think they’re going to be interested, then are people really going to be interested in the content on a Desktop?

What ever your reasoning is, if you decide to do it then you should approach it from a progressive enhancement point of view. 

Your content should be mobile first, which means if you’re not going to show the related content then it shouldn’t be a part of the original request at all.

Then, once the page has been loaded, you can check the viewport width and decide if additional content needs to be loaded.

This then would ajax in any additional content that you wanted to see.

On a desktop this content would load in straight away (assuming that it meets the viewport width requirements) so you will be penalised with additional http requests for every page.

The Lesson

So that’s a really quick fire overview of the theory behind it and two examples where you might want to load in content based on the viewport width.

The lesson is

• Stick with one code and content base where you can
• If you’re considering hiding content on a small device question whether it needs to be there at all
• If it does need to be there then build it from a mobile first, i.e. load the content in at larger screens.

Tools

Tools that will allow you to achieve this can be

• ResponseJS (not respond.js) – need to define breakpoints in a json inside the body tag.
• Conditioner.js –  (relies on Require.js)
• Lazy Load – only loads a default image in the place of the real image until that becomes part of the viewport.
• Enquire.js

Another issue that is often faced is keeping your media query breakpoints in check with the breakpoints you use for firing javascript.  This is a much deeper topic and if you’re interested then hit me up on twitter on @reswebdes or reply to the newsletter and let me know.