A Practical, Applicable Approach to Responsive Web Design

January 4th, 2013 by Kyle Kellogg

When choosing a design for your web and mobile needs, it is important to chose a design approach that suits the needs of the project. There are two approaches that I want to discuss in this post. The first approach involves creating two compelling experiences, one for the web and the other for mobile. This design approach allows for separate designs and gives the designer more freedom in regards to the user experience for each device. The other approach revolves around a responsive design, which uses CSS3 properties to decide which media to show and where to place that media based on the constraints of the browser. This is not to say that responsive design cannot do both web and mobile with the same freedom, but that responsive design may have additional effort needed in order to achieve the same results. Responsive design is quickly becoming an effective way to design and develop maintainable web sites that reach a majority of endpoints and browsers.

To begin, let’s address what responsive web design is and how it differs from an adaptive approach. For our purposes here, and most others that I can think of, let’s limit responsive web design to be the combination of  a design and layout that respond to the size, orientation, and visible capabilities of whatever they’re being viewed in. What do I mean by visible capabilities? I’m talking about the specific capabilities or quirks of how the browser/renderer shows your user what you’ve made, i.e. drop shadows – but only if they’re available. Let me be clear:  We’re defining a responsive approach as being limited to changing styling and not functionality or content (although, in a little bit, I’ll describe a cheap and effective way to blur that definition in order to accommodate a semi-adaptive approach).

The benefits of a responsive approach may be self-evident, but for specificity’s sake we’ll review them. You end up with a single product and a single codebase. It’s much easier to maintain than making multiple, synchronized edits to a split (mobile-specific and non-mobile) approach. It’s usually quicker and more cost-effective to create than a split approach, however that can vary depending on how forward thinking you are with the website or web app as retrofitting one to support a responsive design can be a bit more involved than creating one from scratch. It can cater to your users’ or customers’ devices’ capabilities, which allows for a unified look and feel while still being forgiving for older or less capable browsers. It lends itself to reusing graphics, which can later be made adaptive by loading graphics only as big as they need to be (see more about responsive images here). It helps us meet the demands of a world in which resolutions and devices are changing at a lightning-quick pace. There already exist many excellent foundations and tools to build upon or with (Grids: http://cssgrid.net/,http://www.responsivegridsystem.com/, http://goldengridsystem.com/, http://responsive.gs/, http://simplegrid.info/ or make your own at http://gridpak.com/) (Foundations/Frameworks: http://foundation.zurb.com/,http://twitter.github.com/bootstrap/index.html, and http://www.getskeleton.com/) (Tools: http://bohemianalps.com/tools/grid/). There are many more grids, foundations, frameworks, and tools out there to assist you – just search for whatever you’re looking for and you’ll probably be provided with many options to choose from.

Like any approach, a responsive approach also has some considerations that must be taken into account before proceeding with it. Developers and designers must both be forward-thinking in their approaches so that all variables are considered. For instance, if you’re developing and know that a specific section must be right aligned for desktop targets but center or left aligned for mobile targets then plan ahead so you’ll be able to accommodate that when the time comes. If you’re designing, consider how much a specific grouping or section will change with each target so that nothing crazy needs to happen on the developers’ side. This planning will be extremely helpful in cutting down the overall time for creating a finished product. This approach also necessitates that certain requirements be met, so shims for media queries (http://code.google.com/p/css3-mediaqueries-js/) and HTML5 tags (http://code.google.com/p/html5shim/) will be necessary as well as feature detection (I prefer http://modernizr.com/). As you are developing, you’ll need to curate and optimize your codebase so that you’re not adding too much and creating a long load time. Most importantly, however, responsive web design is not a magic bullet – remember its limitation of affecting only styling.

Now that I’ve gone over some of the benefits and considerations, let’s get to the important bit – how can you apply this to current and future projects? Let’s break it down into steps:

  1. Planning
    1. Plan your targets. Will you have a different design or layout for desktops, tablets, and mobile devices? A different design or layout for iOS and Android? Nail down exactly what you’ll be designing and then developing for.
    2. Plan your designs and layouts. How will your designs and layouts differ in your targets? Imagine how they’ll flow from one to the next and describe everything in as much detail with still graphics, animations, or words as best as you are able to.
    3. Plan your development. How can you best architect the markup to allow for a fluid layout for each target?
  2. Designing
    1. Create designs for each target based on your planning.
    2. Using your designs, save/export each asset you’ll need.
    3. If your graphics are changing size, save/export each size as it’s own asset.
    4. Compile assets into a spritesheet for use by the developer(s). If you want, you can split it up into one spritesheet for each target.
  3. Developing
    1. Create your markup. Allow for a loose architecture that can be adapted to all targets.
    2. Input your content and implement responsive images (if you so choose).
      1. If you need to swap some content or shake the layout up a bit for a specific target, or for each target, consider adding with target classes so that you can swap by changing the visibility and/or display styling. While not lightweight, this is a quick and cheap way to adopt a semi-adaptive approach.
    3. Styling
      1. Create basic styling first. Start with your primary target and work from there.
      2. Move from your layout up to implementing the design specifics (font sizing, et cetera)
      3. Add on to your basic styling for each target, making only the necessary changes to each.
      4. Remember to make full use of Modernizr, or whatever feature detection you’re using, so that as much of your implemented design will remain as possible no matter what browser or renderer it’s being viewed in.
      5. Try and keep the tips from this video about Github’s CSS performance (http://vimeo.com/54990931) in your mind when styling
  4. Testing
    1. Test on as many devices, browsers, resolutions, and operating systems as possible.
    2. Though I’ve never had much luck with them, you can try to use http://browsershots.org/ to capture what your site looks like on operating systems or browsers you don’t have access to.
    3. You can also use http://mattkersley.com/responsive/, http://screenqueri.es/, http://www.responsinator.com/, and http://responsivetest.net/ to test at sizes your browser may not get to or multiple sizes at once.
    4. Once you’ve tested, test it again – trust me.

Those steps, while in a logical order, are also in order of importance (from greatest to least) – except for testing, which is of utmost importance throughout every project. I cannot stress enough how important the planning stage is to a responsive approach (or any approach, for that matter). With enough forethought and constant, consistent consideration for that planning, testing is merely a matter of double-checking your work to make sure you haven’t forgotten to cross a ‘t’ or dot an ‘i’ somewhere. You’ll find small things, but it shouldn’t be anything big enough to warrant serious time and effort in order to rectify. It’s unlikely you’ll be able to nail this the first time around, so test as frequently as you want or are able to. The more you test the more likely it is that you’ll get relevant feedback from recent changes and gain an understanding of how to improve your own processes. If you’ve planned and designed everything really well, with considerations to how the layouts and designs can flow into one another, you’ll find development becomes much easier. Each step stands upon the shoulders of the step before it, so have a strong base and you’ll be able to build bigger, better projects.

Hopefully you feel more confident in applying a responsive approach to your next website or web app.

Leave a Reply