Responsive Web Design for Mobile Done Right

We get asked about mobile web development all the time. Those that have heard of responsive web design say that's the way they want to do it. Those that haven't "ooh" and "ahh" when we give them a demo.

That is so cool! We definitely want that.

It's totally understandable. And yeah, it is way cool. However, at the end of the day, I think both developers and business users are seriously missing the use case for responsive development.

Let me be clear here: responsive web design has a very important role to play in the exploding market of mobile and tablet browsing—but that role is not to turn your desktop website into a mobile version. (Or worse, to turn your mobile website into a desktop version. That's another blog for another time. Read my thoughts on that here.) There's a couple of great uses of responsive that I'll get into shortly. 

Failures of Mobile as Responsive

First, let me point out some areas where responsive development as a path to mobile fails:

  • It's processed client-side (on the user's browser). I won't go into detail on each of the methods used for responsive development, but they all have something in common: they're processed in the browser. If your goal is to create the best possible experience for your users, you want to depend on your server for processing and caching rather than your users' devices. This makes your site faster, more responsive, and smoother than even the best front-end alternatives.
  • It doesn't allow the user to opt out (e.g. "click here to view full site"). Chances are, at some level, you'll be removing something from your pages in order to make them "mobile friendly." That's good, less is more; unless someone knows where that upcoming events block is on your full site, but can't seem to (or doesn't want to) find it on your mobile version. 
  • It ignores the user's request data, such as their browser (user agent). Technically, this doesn't have to be true; it's just a trend I've seen. Your browser sends data to a server so it can make adjustments as necessary to tweak the site for the browser. Responsive says, "whatever, I'm just going to send everything and we'll figure it out as we go." It's borderline rude.
  • There is a very limited number of real users who will be resizing their browser to 300px wide. Don't try to tell me this is a useful feature. The fact that it responds from desktop to mobile as you shrink your browser window is useful to exactly two groups of people: developers showing off, and the people they're showing off to. (Ok, and the people who say "I wonder if this site does it too...") Point is: these people don't make you money; they're not worth focusing on.

Focus on your users

Good user experience sells, both on and off the web. Good user experiences are born out of focus on your users. Whipping up a design then just shrinking it into mobile (or vice versa) doesn't produce the user experience your users deserve. Server side processing gives you these advantages:

  • You can create a vastly different site for each set of users. Processing server side brings with it the ability to do anything you want. You can take exactly the same content and represent it in a way that accounts for the medium you're presenting it in. Hover effects and drag-and-drop don't work well on touch screens, but really dress up a desktop site. Server side processing gives you the ability to focus on a group of users, and only on those users.
  • You can't beat the speed. Browsers are getting faster and faster, but they still can't compete with "already done". When you make the decisions on the server, you can save those decisions for later with caching. Not to mention the excess requests (files) and DOM (web page) modifications you save by processing it for your users.
  • The user stays in control. When you're paying attention to users' requests, you can make more of the right assumptions for your users. You can assume that they want the tablet site, without locking them into it if you made the wrong assumption about the information they'll want. Maybe they did want that high-res image on their mobile phone. Maybe you should serve retina graphics for retina displays. You can give a desktop a site designed for a smaller window, without assuming smaller screen means it's a touch screen.

Responsive is important

I think the perfect place for a responsive website is for it to respond to the interactions of the user, and fill in the gaps where server side can't react adequately. The right approach is a hybrid of the two methods: letting each technology do what it does best, without trying to force it to do what it doesn't excel at.

On the server, there are a number of intelligent assumptions we can make about the device capabilities based on the request. We know an iPhone has a touch screen, a slower processor, and a slower internet connection on average. We know a desktop isn't likely to be smaller than 1000px wide (though window size could drop to 800px in normal use) and has hover capabilities. We can make decisions based on this information at the server level. Ultimately, we can cache this data and respond instantly when any given device sends a request for a page.

On the client-side we can respond to realistic actions. It makes sense for users to shrink their browser a bit or turn their device sideways. These are perfect examples of the right way to use responsive web design.

It comes down to this: if a user can't—or won't—change something about their device, that element doesn't need it to be responsive. That should be cached to improve user experience. On the other hand, a web site should respond to actions a user is likely to take. Simply put:

Responsive sites should to respond to actions, not devices.


What I'm describing here is focused on best case scenarios. I don't think for an instant that everything I've outlined here is universally applicable. If budget were not an issue, this is the guide we would follow to account for a wide variety of devices and screen resolutions. We have built mobile sites using both client-side and server-side techniques, as well as hybrids, similar to what I've described above. Sometimes it's worth having a mobile site even if it can't be perfect; budget is an important piece of any design process.