Responsive Web Design (RWD) is a technique for developing Web pages that automatically re-size themselves based on the device they are being viewed on.
Today, Web sites are the life blood of how we get our message across. And there is certainly no shortage of different types of devices on which to view this information. And therein lies our dilemma.
You see, the problem is that most Web pages are designed using pixels. That is, we size the text and layout based on them being so many pixels high and wide. In the olden days, this was fine because everyone used similarly sized screens to surf the Web. But today, that is no longer true, and a Web site might be viewed on everything from a gigantic gaming screen down to a tiny little smartphone and all sizes in between (e.g., iPad).
Unfortunately, a pixel is a fixed unit of measure. If you display something that is 100 pixels wide on a gaming screen it will look very small, but if you put that same 100 pixels on a mobile device, it may look enormous. And this causes a problem for Web designers who want to create pages that look consistent no matter what device is used to display it.
OK, I know what you're thinking: "Who cares what kinds of problems Web designers have? They're freaks!" And to that I say, first, calling a Web designer a freak is a compliment, so be careful how you use that word, and second, if you, in your i world, have developed any browser-based business applications, then you just might be a Web designer too…sort of.
Designers have attacked this problem a number of ways, but one that is receiving a lot of attention today is Responsive Web Design (RWD).
It addresses the issue by using a three-pronged strategy: flexible sizing elements (text and layout), flexible images and media, and media queries.
Flexible Sizing Elements (Text and Layout)
As I noted above, text size and column width (the layout) has traditionally been set in pixels, a constant unit of measure. To make Web pages truly flexible, RWD calls for setting sizes either in terms of em's or percentages, respectively.
The "em" is a proportional unit of measure, not an actual one like the pixel. Technically, the em size of a text element is the ratio of the pixel size you want that element to be to the pixel size of the default text size in use at that moment.
OK, take a breath. Let's take this step by step.
Default Text Size
Every browser has a default text size built into it. If your Web page doesn't specify a size for the text you are displaying, then it will default to the browser default. Of course, most Web pages have Cascading Style Sheets (CSS) attached to them and the CSS more than likely have a default text size in them, so that should override what is in the browser. But no matter how you slice it, there is always a default text size somewhere. Often, it is 16px.
In Use at the Moment
This is where RWD gets a bit dicey. There is a default for the page, but there may be other defaults set within the CSS. That is, the default for the page might be 16, but the default in the CSS for the leftmost column might be 12, and the default for a box within that column might be 8. For the calculation, you have to know where you are and what the default is for that moment. It's not as simple as just knowing the default for the browser or the page as a whole.
Ratio of the Pixel Size of That Element to the Pixel Size of the Default Text Size
So, if you want to have a headline that is 24 pixels high, and the default pixel size is 16 pixels, then the em's value is calculated like so:
target / default = 24 / 16 = 1.5 em
I realize that most people don't think in terms of ems, but it doesn't take too long before you start developing a feel for them. Or you can just start guessing at em values and see how it looks. I've done that. What's important is that, by defining the text size in em's vice pixels, as the screen size grows or shrinks the text will resize itself automatically.
You can use a similar technique to create flexible layouts, but using a percentage rather than em's. Instead of setting up a layout element as being x number of pixels wide, you will specify it in terms of a percentage of your overall page size. You could assume that your Web page is 960px wide and that you want your header (for example) to be 900px wide. But when you set up your CSS code, you would specify the header width as 900/960 or 93.75%.
The advantage of doing it this way is that, now when your screen size changes, your header width will change as well, always being 93.75% of whatever the screen size is.
Flexible Images and Media
In addition to text and layout, we also have images (pictures, drawings, etc.) and media (movies, sound, wacky video, etc.). And again the goal is to resize them so that they don't blow out the window they are being seen on.
A liquid layout (an older, pseudo RWD technique that is being superseded by RWD) just resizes based on the width and height. But Responsive Web Design uses several techniques that not only modify the size, but also optimize the load time for those images.
The last piece of the puzzle is the use of "media queries" to determine what size device you are trying to display the Web page on and then take appropriate action to display or hide information that is not essential on a small screen. That is, if you're showing your page on a smart phone, you may not need all of the logos. You may want to just have useful information appear.
Media Queries are a function of Cascading Style Sheets, and they let the page dynamically see what size screen it is about to be displayed on and then, if the CSS are conditioned properly, display things for maximum viewability. One of the key parms that it will provide is the max-width value that we talked about above.
RWD is not a here today, gone tomorrow trend; it's something that appears to be here to stay. For more information on RWD, consider the following.
- Ethan Marcotte's excellent (and short) book Responsive Web Design from A Book Apart.
- A short review of RWD from the WebDesignShock web site, Responsive Web Design – A Most Complete Guide.
- And, for a dissenting view, this blog post by Matt Henry