A case study in responsive design | Boagworld - Web & Digital Advice

Web & Digital Advice

Digital and web advice from Headscape and the addled brain of Paul Boag... tell me more

Dan Sheerman Posted by: Dan Sheerman On Monday, 31st October, 2011

A case study in responsive design

Dan Sheerman has been working away to implement the responsive design for Boagworld. With the job complete he shares a few lessons learnt.

Development:
The estimated time to read this article is 5 minutes

Over the last couple of days, I’ve had the task of taking the Boagworld site and implementing all its responsive goodness. We went live quietly, so you will now be able to resize this very post as you’re reading it.

All done?

Can I have your attention back now you’ve had a good play, and poked holes at things that look dodgy in my stylesheets?

Okay, so Paul’s asked me to write a post outlining how I went about it, and some of the things I noticed along the way that might help if you’re attempting responsive front-end work for the first time, or just want some general tips, so here goes.

I don’t really like people telling me how to ‘best’ do things, so I’m going to try not to do that. Instead I will offer some general observations I had along the way and some ‘common sense’.

What are media queries?

Firstly, media queries. If you’re not already familiar with them, here’s a basic outline. What you’re looking at with media queries are essentially a form of conditional comments, just like the ones you’re used to using to crowbar IE into the shape. The difference is that with responsive/adaptive design, you’re targeting devices’ and browsers’ widths (and heights), as opposed to a specific browser version. The first thing you’ll notice about the media queries on Boagworld, is that there’s several stylesheets for different device widths. Unfortunately, they’re in the ‘wrong order’. There’s a reason for that.

Why build from mobile up?

When building for mobile devices, ‘common sense’ would dictate that we serve the least amount of data to those devices likely to view content on slower connections, or potentially less capable of dealing with lots and lots of (unnecessary) gumph.

In an ideal world, if we were browsing on a generic mobile device with a screen width of 480px and a slow EDGE connection, we’d want to be loading in just the styles necessary for the mobile layout.

We build the styles from mobile up starting with essential content. We then progressively call in more rules for more complex layouts that are utilised by devices with the ability and bandwidth to use them. Although it is not a hard and fast rule, devices with a smaller screen size are normally also slower at rendering web pages because of bandwidth and processor power.

Paul did it wrong. Don’t copy him!

With the Boagworld site, I already had the set of stylesheets that handled base styles, typography and branding along with the ‘desktop’ layout in percentages from Paul.

Without rebuilding the stylesheets that were already there, I’ve done the most horrible thing imaginable, and added all individual stylesheets in the ‘wrong order’.

As a result if you’re browsing on a generic mobile device with a screen width of 480px over a slow EDGE connection, you’re being served:

  • the full site stylesheet,
  • a few tweaks for generic big tablets in landscape,
  • a few tweaks for generic big tablets in portrait and generic small tablets in landscape,
  • a few tweaks for generic small tablets in portrait and generic smartphones,
  • and a few tweaks for generic mobile devices.

So sorry about that. I’m aware that it’s not the perfect way to do it, and I’ll certainly rejiggle the stylesheets to work properly (read: assign styles to selectors in the reverse order) at a time when I’ve got less shouting at Magento to do.

In terms of file size served, it’s actually not too bad, the most you’ll load in is an extra 9KB or so on top of around 15K (both quoted without compression) for all the desktop site’s styles.

There are a lot of individual stylesheets for the time being just for clarity and ease of development.

When everything gets rejiggled, I’ll be considering whether it’s more efficient to have larger stylesheets and fewer server calls, or smaller stylesheets only served when needed. I suspect with the filesizes, the difference will be negligible, but something that’s definitely worth considering.

Plan from the start, but don’t despair if you haven’t.

It’s always important to consider future implementation of responsive design when marking up any site. However, even when working with a fixed-width full site that has been coded with percentages, you can achieve some fairly comprehensive responsive techniques (as is seen from Boagworld).

When the content begins to look cluttered as the viewport is reduced, you can add break points that hide unnecessary or/and restyle elements. For example you can change display:inline-block to display:block so pushing columns below each other.

I did experience a weird bug when resizing with columns that were display:table-cell. So you may want to watch out for that one and use display:block instead.

Dealing with navigation.

We have two sets of navigation. One is more suitable for smaller screen sizes while the other is a ‘desktop’ version. Once this duplicated menu is added to the HTML it is simply a matter of showing or hiding them based on screen width.

It would be possible to simply restyle a single navigation bar but in our cause we wanted some elements (like subscription) to function a little differently so it was preferable to have two sets of HTML.

Dealing with content.

In terms of content, we’ve tried to keep it accessible at all resolutions. However, I did decide to hide the ‘fadey’ sidebar once the screen width drops down to tablet view. This is partly because the hover action required to ‘re-activate’ it, and partly to prioritise content readability.

Testing and browser quirks.

One thing you may notice if using Opera Mini is that the mobile menu drop-downs appear to post back to the server.

I had a hell of a time tweaking the JS to event.preventDefault() on those anchors. If anyone knows a solution, I’m sure you’ll let me know in the comments.

You’ll also, I’m sure, be thrilled to know I’ve tested it in Opera, and other browsers like Konqueror and Netscape to ensure graceful degradation for things like funky gradients – N.B. I haven’t actually tested it in Konqueror or Netscape… Or Android yet, actually.

Windows MobilePhones will, for their decision to make their mobile browser IE7 based, get Paul’s (really pretty) basic stylesheet. And as IE8 and below whistle loudly while strolling past media queries, that probably won’t change anytime soon.

And that’s about it. I’m sure we can rely on feedback to be left in the comments.

You may now resume dragging the corners of your browser about the screen like a crazy person.

Become a web expert with our newsletter

Receive invaluable advice every three weeks and get two free video presentations for subscribing. You can unsubscribe in one click.

Blog Updates

You can follow all my posts by subscribing to my RSS feed or signing up to my email newsletter above.

Podcast Updates

Subscribe to the podcast via itunes or RSS. You can also subscribe to my quick tips via itunes and RSS too.

Social Updates

I am completely addicted to Twitter so try following me there. I also have a Facebook page which contains considerably less waffle.

Comments

Boagworld is a community, not just the voice of one blogger. You've read the post, now its time to get involved.