Responsive Web Design is the latest in a long line of terms that have really caught on and, depending on who you ask, either signals a complete shift in the way that we work, or describes some cool new techniques to consider when designing and building websites. I tend to fall into the first group to such an extent that I believe a year from now, what we are now calling "Responsive Web Design (RWD)" will simply be called “Web Design.”
We need to call it responsive now because it represents a big enough evolutionary leap to require us to define specific techniques that we could use to accomplish it, but the more we do responsive sites, the more it sinks in that there's really no reason to not make a website responsive.
That said, here are a few important terms that may help to clarify what I’m talking about when I say “responsive.”
Adaptive Web Design uses a pre-defined set of layout sizes based on screen size. You can make informed decisions based on your site analytics that tell you which devices people are using when they visit your site, and then targeting those devices. There will likely be some device detection going on here as well, and some amount of server-side changes depending on the device.
Responsive Web Design on the other hand, is comprised of three things: a fluid grid, flexible images, and media queries (CSS rules that kick in at certain viewport widths, or based on other properties of the device viewport).
Finally, “responsive” (little "r") is a less strict way of describing this new world of design thinking, along with some of the techniques used to accomplish them. RWD has a real definition forwarded by Ethan Marcotte, this "little r" version is more a feeling; a sensibility; an ethos.
"Today, anything that’s fixed and unresponsive isn’t web design, it’s something else. If you don’t embrace the inherent fluidity of the web, you’re not a web designer, you’re something else."
What Set’s Responsive Apart from Adaptive?
A site should work on any screen size you can throw at it. It's not about the specific device being used, it's about the size of the screen. The web is responsive by nature. It's always been responsive, and it is through our own design decisions and coding practices that we have built sites that were not responsive but were, rather, trying to mimic the print world with which we were more familiar.
Being successful with RWD means accepting that you can't control everything. It's a change in philosophy as much as it is a change in design and coding practices. It's about UX folks, Designers, Front End Developers, Tech Leads, Software Engineers, all of us, understanding how web pages behave and using that to our advantage when planning and designing the experiences we ultimately build for our target audiences.
RWD is less about the techniques and more about the process.
Those of us that are doing RWD recognize that it's not something that just happens after the site has been planned and designed, and is now ready to be built. It involves a sea change in the entire process we follow from the first workshop with clients, to pushing the new site out the door onto the big scary Internet. Check out Jared Spool and Jason Grigsby talking about how RWD has impacted their design process.
What if you can’t pull up stakes and do an entire RWD process from soup to nuts? What if you just redesigned your organization’s website last year and you really need it to work better on handheld devices now, but can’t redesign the whole site for another year or two?
A “Responsive Retrofit” can be a viable option depending on the site. It is entirely possible that you do not need to completely redesign your site or go through an entire separate creative process. By not creating wireframes or designs and, instead, simply starting with the HTML and CSS that you have now, we add responsive CSS and can, in many cases, make the layouts work better on smaller screens. Results may vary and you may be limited in how much of the site you can make responsive. The important thing is to be able to evaluate the site up front and have a clear idea of how responsive it can be made, and what tradeoffs there may be.
Be forewarned: In a true responsive design you have plans that minimize the amount of markup, CSS, JS, and images that you deliver to devices. The retrofit approach very commonly increases the number of files delivered to the device and the overall “weight” of the page, and should only be considered if your site already performs well in terms of speed.
Here are six key things to look for when evaluating an existing static website for a retrofit:
- How well was the site coded? Is there nice clean HTML and few (if any) tables?
- Is the order of blocks already correct for what you want to accomplish in a layout where everything will stack in a single column?
- Are there classes and IDs for you to leverage without the need for overly complex CSS selectors?
- Does the site contain consistently sized images that will all work well at 300-400 pixels wide (small images don’t size up well, huge images are, well, huge)?
- Are all your page layouts consistent and few? Too much variety will make for more work.
- Is the navigation simple, and does getting to deep content not *require* the use of navigation? If so, do your mobile users need access to that content?
Of all of these things, the hardest nut to crack is almost certainly going to be your navigation. This is especially if you have a really deep architecture. But generally, if you like the answers to those six questions, your site may very well be a candidate for a retrofit.