Responsive Design: Progressive Enhancement, Part Deux!

Okay, I know the term du jour is Responsive Design, but just think of it as progressive enhancement. The term (and philosophy) progressive enhancement replaced graceful degradation back in 2003, but back then it was mostly pertaining to CSS and JS.

This time around, we’re talking about the whole kitten-caboodle kit and caboodle, from design to layout to content to media to HTML to CSS to JS… Like I said, everything.

While this may sound like a lot to take in, here is the basic idea: Start with most primitive device capabilities you can imagine (I mean, no JS, no CSS, low bandwidth, intermittent connection), make sure that your site is downloadable, readable and gets your most message across, then build up from there, adding layers of enhancements as we go, just like we all do with progressive enhancement, right? Right??

And a fundamental flaw that I hear and see all the time in people’s approach is designing “for the iPad” or “for the iPhone” or “for any specific device.”

When you are planning your designs, get a basic version into a browser, grab the bottom-right corner and pull it around. How does the page looks when its at full-screen? How does it look when its smaller? And smaller still? What about when its as small as your browser will let you go, can you still read your content and navigate your site? Will people still understand what you’re trying to get them to understand?

Don’t try to build a page that looks perfect at 1024×768 because “that’s how big the iPad’s screen is”, because tomorrow something will come out that is different from that. And the next day, something that is different from that. Instead, load your page in your browser and slide that bottom-right corner around. When you see something start to look uncomfortable, check the screen size and make a CSS adjustment that fixes the issue you’re seeing. This is responsive design: designing for anything that might come to be, not what we have today. Today is already yesterday; build for tomorrow, so you’re ready when it gets here.

Before we get started, let’s take a look at a few cool examples, to really get a grip on what we’re talking about here… Again, grab that bottom-right corner on each of these and pull it around to see the “magic”…

Cool, right?? So how do you start? Well, this is the hardest part, the start… But it isn’t impossible! I’ve read that if you’ve already been designing/developing in the liquid/flexible world then the change-over is much easier, and I’m sure that’s true, but being someone that wasn’t, I can tell it wasn’t all that hard if you haven’t been either.

There are a slew of articles at the end of this post, stuff I’ve found useful, inspiration, cool, interesting, or for some other reason decided to copy and paste here, so feel free, the more you read, the sooner all of this will make sense and feel natural to you. And, again it will, trust me.

But to get started, the first things you need to know are:

  • What is progressive enhancement?
    The essence is that you build a page/site that will properly function (read: all text is readable, all links are navigable) in the “least common denominator” (LCD).  The LCD used to be IE6, but that’s no longer the case.  Our new LCD could be an iPad or iPhone (with its smaller-than-a-desktop screen), a Blackberry (possibly lacking JavaScript or with limited CSS support), or even a flip phone or a basic handheld (with no JS or CSS, and possibly no images!).  Once the text and links work in these devices, you progressively add features in a manner that leaves the LCD working, but enhances things on better devices.
  • What is a fluid grid?
    A fluid-grid does not have constrained dimensions (meaning, no width: 994px;), but instead allows the page to expand as wide as your user’s device allows it to.  Of course, this could get ridiculous if someone has an enormous monitor, so you can still use max-width (where that is supported). (There is also the notion of fixed-fluid, where you build a completely fluid site, but then give a container a fixed width. This allows your page to easily expand in the future if you decide instead of width: 994px;, your site should now be width: 1024px;; all you would have to do is change the container’s fixed width and all of the fluid elements within would instantly bounce into shape.)
  • What is a @media querie?
    @media queries allow us to apply CSS based on certain criteria, such as device orientation (portrait/landscape), media type (screen, print, all, etc.), or screen width. These screen widths are referred to as “break points” and are what I was describing above when I talked about sliding that bottom-right corner of your browser until something looks uncomfortable; that’s your break point.
  • What is an em?
    An em is a unit of measurement based on the the width height (Thanks for the correction, Greg!) of the letter “m” in the font currently being used.  In our case, we will use it to say things like padding: 2em;, which will set the padding of an element the width of two letters “m”, relative to the font-family and font-size applied to it.

The hardest nuts to crack…

  • Crap, I gotta do maths… Your designs will likely still come in PhotoShop, with everything lovingly and carefully measured in pixels. You will need to convert some of those to percentages and ems.
  • Switching from fixed- to fluid- or fixed-fluid-layout.
  • Switching from px to em and keeping track of “where you are”, because both percent and ems are relative to their container
  • Making your image sizes fluid and deciding which image sizes to show on which devices.
  • Dealing with IE (@media queries are not supported until IE9, and min- and max-width are not supported until IE8 IE7 (Thanks for the correction, Greg!)).
  • Determining what page components this device really needs? (display:none; does not a mobile site make; users still have to download that content, even though it’s hidden from their view.)

So, how do I start thinking like this?

  1. If necessary, depending on the project, getting your design and business teams on board could be a huge hurdle. The bottom line that I would present is this: it is one site to design, one site to maintain, one site to host, one site to serve, device-, OS-, browser-agnostic. Build one thing for everyone. If you can monetize those points, even better, but they should be able to see the benefits from just that.
  2. Figuring out how to translate PhotoShop to CSS is the first hurdle. If you have designers that know the basics of HTML/CSS, you might consider trying the “design in the browser” movement. I’ve tried this in the past, and found untangling the designer’s HTML/CSS more work then building my own, but try your designer(s), can;t hurt to give it a shot, right? If not, as I said above, you will need to do maths. At the very least, figuring out major section percentages, based on how many pixels this container is of the total container, can be annoying, but once you get the main containers, you’re usually pretty much set, as the elements within that can just be percentages of that element.
  3. Choosing the necessary page elements. This is where shit starts to get ugly… Define “necessary” for me, please. Now ask someone else to do the same. Now do that at a conference table with 14 people from 12 different business divisions. Sounds fun already, doesn’t it? And before you even do that, can you even do anything about it if you can decide on elements to leave off for basic devices? This process requires some form of dynamic server process, be it if statements based on header information, or perhaps you want to try playing with a server-side Modernizr, either way, if you can do it, it will be a fun conversation…
  4. As usual, start from the (new) start… Get a nice, new, clean set of HTML, probably start with HTML5 Boilerplate, custom it for your template needs, and start pushing your stunning design into that gorgeous, exciting new mark-up, remembering: you are first designing for the crappiest cell phone you can imagine. Don’t be afraid to download Lynx, that is your initial audience.
  5. Then build up. Once you look good in that crappy experience, who’s next? What can you add? Background colors? Adding background: #eaeaea; doesn’t mean anything to a browser that doesn’t understand it, but will suddenly pop into place for browsers that do. Font colors? Images? Same thing: browsers that don’t or can’t, won’t; those that do and can, will. Just remember to keep looking back at the simple browser in a small screen to make sure the enhancements you’re making aren’t breaking backwards.
  6. Same goes for JS: Once you have a tags with hrefs that will work in simpler browsers, you can use feature detection, even stepping up to something like Modernizr, to determine when you can add bells and whistles like Ajax fetching instead of page refreshes, accordions and tabs instead of vertical content or page refreshes, etc.
  7. Soon enough, you’ll find yourself with a real-live, full-fledged web experience that works all the way back to days when the web was a black screen with green or orange letters…

Now, like all good things in in our industry, this is all still a moving target, and a growing standard, so you will find varying views on some best practices, different techniques for the same issue, etc., that’s why we have to keep reading and keep practicing. Some of these methods may or may not work for you in all situations, so, as usual, play!

 To help you get started, here are a few resources I recommend reading, in the order I would recommend reading them (I’m trying to give you general-to-specific articles, to help ease you into all this…). Note the dates on some of these, this is not a new concept…

So, okay, that’s a lot of shit to read, but I don’t think you necessarily need to read it all, but I also think maybe you should, when you get minutes here and there. Again, if I copied and pasted it, I think maybe it’s something you might find interesting.

In any case, definitely give it a shot. Start with your blog, or some other really basic site, get a feel for things, then start working your way up to tougher and tougher designs. This won’t be an easy migration, but when you hand a client a site, and they notice that it works well in their browser, on their iPhone, and on their Blackberry, they’ll appreciate your professionalism. And you’ll appreciate what a damned-good coder you are!

Happy developing,

10 Responses to Responsive Design: Progressive Enhancement, Part Deux!

  1. Ralph says:

    Nice round up about responsive web design.
    I do use the ‘resize browser’ technique when I’m designing/developing, but if I see that at a certain viewport size I need to take some media query action, how do I know at what viewport size I am. Is there some kind of tool/bookmarklet that shows that?

  2. May I humbly suggest my Adaptive Web Design as a good primer on progressive enhancement as well?

    BTW – Good luck in Germany! I hope you love it. If you make it in to Dusseldorf, be sure to hook up with Marc Thiele. He’s awesome. He also runs Beyond Tellerrand, an awesome web conference.

  3. Greg Rewis says:

    Just a small “nit-picky” detail – an “em” on the web is the height of the M, not the width. The em does refer to the width of the M in the print industry where it was the width of the block of metal used in old printing presses – as the M generally filled out the entire block. However, since we don’t have “metal blocks” in the digital world, we simply use the height of the M.

    Also, IE7 introduced support for min-width/min-height:

    Otherwise, great write-up!

  4. aarontgrogg says:

    @Ralph: There is a Chrome Extension, Window Resizer, that places a small notification in the lower-right corner of your browser every time the window resizes. I’m sure Firefox has an equivalent?

    @Aaron: Thanks for the recommendation, and for Marc’s info, we will definitely be heading to Dusseldorf at some point! Headed to Heidelberg today! :-)

    @Greg: Wait, you don’t use metal blocks in your HTML??? :-) Thanks for the corrections, duly noted!

    Vielen dank, Tschüss,

  5. Tom Hermans says:

    Great article Aaron. I’m one of those “design in the browser” guys. Is great for prototyping, handy to make adjustments site-wide (over multiple page templates) and the eye candy can still be done in Photoshop. I also read an article where they’d use Indesign as layout-tool..
    And Modernizr is awesome..

    @Ralph, I used to have a piece of JS-code that would fetch the size of the window and add an element with the width/height values updated with every resize.

    Nowadays I use this, the creation of a pseudo-element (in this case on my site-title element = logo top left), which tells me which mediaquery is active. (see it in action on my ‘in-redesign-redev’ stage site:

    /* mediaquery reporter */
    .site-title:before { position: absolute; top:0; content: “320 and up”; background-color: red; color: white; font-size: 16px; padding: 5px 10px; }

    .site-title:before { position: absolute; top:0; content: “480 and up”; background-color: green; color: white; font-size: 16px; padding: 5px 10px; }

    .site-title:before { position: absolute; top:0; content: “768 and up”; background-color:blue; color: white; font-size: 16px; padding: 5px 10px; }

    Just put any of these in the correct media-query (I start with 320, and go up..)
    Delete ’em when you’re ready of course ;)

  6. Ralph says:

    Thanks a million, Aarron! That extension is exactly what I was looking for. Another handy tool in my toolbox to speed up development.

    @Tom Hermans – Thanks for your input. That’s some clever use of the pseudo-element, but I really needed a tool like Aarron shared with me. It tells me exactly the size of the viewport I am while resizing the browser window.

  7. HumanBlade says:

    Huh, you actually respond to commenters, so I won’t feel like such a putz. Your 2nd paragraph uses the phrase ‘kitten-caboodle.’ I believe the idiom you’re grasping for was ‘kit and caboodle’ which actually makes sense. A kitten-caboodle would, I assume be an all-inclusive trivial gathering/bunching of kittens. Unless this was what you were going for?


  8. aarontgrogg says:

    @Tom Hermans: Thanks, nice to hear from you again! I do do some in-browser development, but find that I box myself in too much when I try to design at all, I’m always thinking “hmm, how would I develop that” or “Um, that would be really hard to do, what if I…”… :-)

    @HumanBlade: Thanks for the correction, yeah, I was indeed not talking about gathering kittens… Erps! :-)


  9. Marco says:

    Thanks a lot Aaron! Very well organized introduction!
    A side note: the link for “What is progressive enhancement?” is broken; it should be

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.