My Approach to Responsive Design

Responsive design is all the rage these days, and for good reason. It builds upon the same concepts that founded great web design back in the 2000s: keep our content and our design separate so that we can then provide that content in the most usable form depending on the audience.

There was a time when this focused on showing content on a computer screen, the printed page and for screen readers alike. While most people aren’t printing the web out to read it on paper much, and admittedly most users on the web will never need a screen reader, let alone know what it is, we have evolved in a different way. The idea that a “computer” is a large screen with a keyboard attached to it is long gone, and many of us consume content on the web far more often via our phones than laptops.

At its core, responsive design can have two pretty simple meanings. One is simply that the concept is a replacement for the term “fluid web design”. While most sites built over the first fifteen years or so of the web’s existence were “fixed width”, meaning they were some number of pixels wide and that didn’t change regardless of the resolution of your screen. If the site was designed for a 1024×768 resolution (the most common for the latter half of the previous decade), and someone visited the site on an 800×600 resolution screen (the previous most common size), they would need to scroll left and right to see the entirety of the site.

Fluid design, on the other hand, would set the width of the design to some percentage of the screen’s width, say 90% (leaving 5% on each side for margins in this example.)

Fluid design and responsive design are not completely synonymous, however. When iPhones first hit the screen, even a fluid width design would not automatically shrink to the 320×480 pixel dimensions of the device at that time. Instead, they would cause the phone to zoom out, shrinking everything on the screen and requiring that we tap certain sections to zoom back in on them, making their text large enough to read.

This leads to the second, more appropriate meaning of responsive design: creating website designs that adapt to different sized screens in a more meaningful way than just automatically shrinking and expanding as we changed the width of the browser.

There are still plenty of responsive designs, perhaps they could be called fully responsive, which do this. The Twenty Fourteen WordPress theme is an example. Follow that link on your desktop machine and resize your browser, you’ll see that the design changes ever so slightly in an attempt to accommodate.

This is great, particularly if you’re a web developer in control of publishing your own content. You can understand the little eccentricities that are involved in creating content that works in those situations, things like the length of your paragraphs, the size of your images, and the number of items in your navigation.

For those of us developing WordPress themes for others to use to create content, however, I argue that being “fully responsive” is just not a practical solution. The average person typing text and adding images to blog posts and pages aren’t going to want to sit there and think, “How can I make sure this will look exceptional on all screen sizes?” They’re not going to want to drop in code every time that will change the image used, so that a nice big 1100 pixel wide photo is shown on a Macbook Pro but only a smaller (in both dimensions and file size) 300 pixel wide image is loaded onto phones which may be on a slower 3G connection.

Instead, when I create responsive designs I work around three general sizes.

800px and below

This will accommodate nearly all small tablets and phones, and I typically design these around a 100% width concept. Whatever the size of your mobile device, you’ll get a similar experience.

1024px

This is still a common resolution as there still are many users running ten year old computers. The developing world, sure, but your uncle, your grandfather, and people who simply don’t have the means or desire to update their hardware every two years. There’s another popular device that uses this standard: iPads. I use this as the base size for my designs, as there’s still enough of an audience to warrant this, and it serves as a middle ground for the other two.

1200px

The final size I tend to use is for all of us new machine users. We’ve got resolutions ranging from 1280 to 1920, and I want to provide an experience for these–who tend to be the majority of users on this site–so that they’re not left with the medium resolution size which could mean they’re seeing the site at nearly half the width of the screen. I say “could” because, even though the resolution of their device may be nearly 2000 pixels wide, many users at this size aren’t running their browser, or any windows on their machine, at full screen. They’ve got a huge amount of real estate and are only using as much as necessary to view one, maybe two windows at a time.

With this type of responsive design, every little change you make to your browser’s window size won’t tweak things. It’s when you make drastic changes in the size of the screen that we see things starting to morph around. Elements that couldn’t fit comfortably into the medium size appear when you widen the window, and many items that aren’t completely essential or perhaps don’t really apply to mobile devices, disappear altogether when you shrink your screen up to 800 pixels or less.

This site is a perfect example of this (as of the current design, circa 2012 – the writing of this post, in January 2014).

Because I’ve got three sizes I can depend on, I can write my code to serve up different sized images for mobile users than for desktop. Reading certain pages on this site via your phone doesn’t mean loading up 1000 pixel wide images that take forever to load on your phone, annoying the user and hurting my traffic.

Responsive design isn’t just about making your site morph to the size of the screen, it’s about providing the best experience for the user regardless of what device they’re using.

Up Next: Force Modern Tribe's Events Calendar Pro Plugin to Use HTTPS for CSS