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”…
- 24 Ways
- Smashing Magazine
- Do Lectures
- St. Paul’s School
- Andersson Wise
- Food Sense
- El Sendero del Cacao (yeah, really)
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?
- 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
@mediaqueries 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
emis a unit of measurement based on the the
widthheight (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
paddingof an element the width of two letters “m”, relative to the
font-sizeapplied 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
- Switching from fixed- to fluid- or fixed-fluid-layout.
- Switching from
emand 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 (
@mediaqueries are not supported until IE9, and
max-widthare not supported until
IE8IE7 (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?
- 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.
- 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.
- 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
ifstatements based on
headerinformation, 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…
- 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.
- 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.
- Same goes for JS: Once you have
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.
- 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…
- Rethinking the Mobile Web by Bryan Rieger, Sep-10-2010
- Responsive Web Design by Ethan Marcotte, May-25-2010
“[N]on-fixed layouts [are] more “future proof” simply because they were layout agnostic”, “make no assumptions about a browser window’s width” and “adapt beautifully to portrait and landscape modes”
“Media queries are, in short, conditional comments for the rest of us. Rather than targeting a specific version of a specific browser, we can surgically correct issues in our layout as it scales beyond its initial, ideal resolution”
- Mobile First by Luke Wroblewski, Nov-01-2010
“Mobile is seeing explosive growth; mobile forces you to focus; and mobile extends your capabilities“
- A Dao of Web Design by John Allsopp, Apr-07-2000
- How To Build A Mobile Website by Jon Raasch, Nov-03-2010
- Luke Wroblewski’s notes for “Rolling Up Our Responsive Sleeves” by Ethan Marcotte, Feb-2012
- How to Size Text in CSS by Richard Rutter, Nov-20-2007
- Font Sizing with rem by Jonathan Snook, May-01-2011
- Fluid Images by Ethan Marcotte, Apr-17-2009
- Responsive Images: Experimenting with Context-Aware Image Sizing by Scott Jehl, Dec-14-2010
- Smartphone Browser Landscape by Peter-Paul Koch, Dec-14-2010
- The Multi-Size Web, Eric Haidara’s collection of further readings
- Favelet Collection, to aid with developing and testing, responsively
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!