In the past couple of months, I have taken on a few Responsive Design projects, mostly for my new employer, PostMedia. Over the course of these couple months, I have come to realize a few things; some through my own trial and error and some through a reaction to what someone else has said or done.
This site/blog/portfolio will soon get a facelift, and naturally, I will be making the design responsive. So, as I embark on my own redesign – Worst. Client. EVER. – I decided to write down the things I have learned thus far on my Responsive Design journey. I invite you to add your own at the bottom of this post. The end of 960px widths is here.
1. Not Everyone Understands What “Responsive Design” Is
If you are a designer or a part of the web industry, you have likely come across a responsive site or two. You marvel at how you can take your browser edges, shrink the viewport and watch as the design adapts to your ever-changing window. It’s a novelty, a party trick, equivalent to a scrolling marquee or blinking text.
But, what does it really do? Why spend all this extra time and energy making a site responsive? Just so you can shrink the browser window?
The original definition of “Responsive Web Design” comes from the man who coined the phrase, Ethan Marcotte: “[Responsive Web Design is] a design that can adapt to the constraints of the browser window or device that renders it, creating a design that almost responds to the user’s needs.”
While this is a great start to defining what Responsive Design is, I feel it it missing something. And this is the part that people seem to miss. If I was to create a definition for the term and all the connotations that go with it, it would look something like this: “Responsive Web Design is a design that can adapt to the constraints of any browser window, on any device, using the same HTML base code and adapting to both current and future devices.“
The latter part seems to be the part that people miss. Let’s start with “the same HTML base code”. Maintaining a single base code for all devices has huge ramifications across all companies, small and large. It saves a large amount of maintenance, rewrite time, adaptation time, etc. Remember, if you have a “mobile site” currently, any change you make on your “desktop” site needs to be replicated on its mobile counterpart. Responsive Design removes this duplication of effort.
The final part, “adapting to both current and future devices”, is the other key component that is often overlooked. If you are targeting a set number of screen widths – let’s say 1200px, 1024px, 768px and 320px – then your design isn’t “responsive”. It’s just simply adjusting itself to each screen width; you could have done this two years ago with some JavaScript and/or a distinct mobile site. The power of responsive design lies in the percentages, ems and adaptive widths it uses, so that when a device comes out with a resolution you did not plan for – let’s say 540px – your design doesn’t require an entire update just to conform. It will already display nicely on this device without scroll bars or zooming/pinching.
2. EMs are King
I love PXs. I love the ability to create pixel-perfect designs and have complete control over my templates. A misconception of using EMs, instead of PXs, is that this control goes right out the window.
When coded properly – I am using “code” in the HTML/CSS context – your design can be just as pixel-perfect as a site that uses PXs as their base. EMs are a relative unit of measurement, whereas PXs are fixed. For a responsive design, the word “fixed” should be avoided at all costs.
“But EMs are so hard to calculate!” I can hear you saying. It’s actually easier than you think. I hate math, so in my designs and markups, the less math I do, the better. So, instead of math, we can use cheat-sheets. My personal favourite is the one at PXtoEM.com. It allows you to convert both ways, and provides a list of EMs based on what base size you are currently using.
If you insist on doing the math or you have a context not covered by a cheat-sheet, the formula is simple: target ÷ context = result. This formula, borrowed from Ethan Marcotte, is easy to use, once you get the hang of it.
A real-world example: you are trying to style your H1 tags to be 36px high. Since modern browsers (without a reset sheet) have a base font size of 16px, your formula would look like this: 36 (target) / 16 (context) = 2.25em. Tada! A responsive H1 tag.
3. Responsive/Adaptive Images Aren’t Quite Here Yet
One of the current drawbacks to a responsive design is the lack of solutions in place to deal with images. On a desktop browser, downloading a 200KB header file isn’t too bad. However, downloading the same file on a handheld device is problematic for two reasons: the time it takes to load and the bandwidth you are forcing your users to consume.
There are several solutions that currently exist, but each one has its own drawbacks: some require the use of PHP and .htaccess; some require creating two (or more) different sets of all your images, one for desktop, one for mobile; some simply ignore the bandwidth stumbling block and force the images to conform through CSS; some use browser cookies. The thing that unites them all is that none of them are perfect. I expect that in the next year or two, the web design community will have a consensus choice, but alas, that currently does not exist.
Personally, I prefer the Adaptive Images solution and when this site goes responsive, that is the one I will use. But this is simply because it makes sense for me: I run this site on a WordPress back-end that uses PHP and I have easy access to my .htaccess file. This solution will not work for everyone, so you will need to search around if this criteria does not apply to you.
Like I said: responsive images is currently a problem.
4. The “Mobile First” Mantra Doesn’t Always Apply
Two years ago, Luke Wroblewski posted about the benefits of designing for “mobile first”. In it, he suggested that we as designers should focus on the mobile iteration of our application first and design out from there. I believe this does not apply to most contexts.
Although this is more of a personal design preference, I feel it is easier to design from the outside-in; that is to say it is easier to start with a desktop design and progress from there to the smaller screens. With a desktop design, you have a much larger space to design with and placing all of the necessary elements into a layout is easier. From this design, you can shrink the screen, removing any objects that don’t fall into the “highest priority” category.
I understand that this point has evolved to be “you should consider mobile design at all times” and for Responsive Design, this could not be more true. However, designing a small screen and building out from there seems counter-intuitive.
5. Consider The Mobile Experience
Browsing the web on a mobile device is completely different than browsing on a desktop. This is an obvious truth, but considering what that means is essential to any Responsive Design.
On a tablet, when a user browses a gallery, they expect the ability to “swipe” their images to take them to the next one. The same applies for a handheld device. Although this functionality does not have to be built into the desktop version – when was the last time you tried to swipe your mouse? – including a small script, such as WipeTouch (3KB) can easily create expected behaviours on device elements.
This “experience” can be extended to other elements as well, not just photo galleries. What these elements are is for you and your client to decide. For further reading and some great Mobile UI examples, I recommend browsing through the jQuery Mobile UI demonstrations. I’d start with the page transitions.
Did I miss something? Do you think I’m way off-base with some of my thoughts? Drop your own thoughts into the comments below.
Header photo courtesy of wasabicube, via flickr.
