Wikipedia defines Responsive Web Design (RWD) as:
[…] an approach to web design aimed at allowing desktop webpages to be viewed in response to the size of the screen or web browser one is viewing with.
At its most basic, that’s pretty much it. Design and build a page that responds and adapts to the device being used to view it with.
Not too long ago, this was assumed to be a monitor that was connected to a desktop computer. The size of those monitors started to grow and continued growing, allowing for larger websites with more content and functionality. When mobile devices (phones and tablets) started increasing in usage, it became difficult to navigate larger websites on those smaller screens. One solution to this ever-growing issue was creating a separate mobile (m-dot) website which served the same content but tailored for mobile devices.
The m-dot solution is not without its own issues. In this scenario, companies end up managing two completely separate websites, including servers, codebases, content, etc. Determining whether a user should be using the desktop or mobile site can be complicated and is not always accurate. And then what if you redirect a user to the mobile site who doesn’t want to be redirected? Links become duplicated because there is now a desktop and a mobile version of the same page, so sharing links becomes an issue as well. There’s got to be a better way, right?
Enter Responsive Web Design.
A single website means no duplication of content or code and no added costs for additional servers. No need to redirect users to a different website means not forcefully redirecting users or having a chance to do so incorrectly. No duplication of links means your website and content are shared more easily and more accurately and Google likes you more (seriously, since early 2015 Google increases search engine rankings for sites that are considered mobile-friendly).
So how does it work? In theory, it’s pretty simple:
- use a flexible grid (percentages and viewport units instead of points and pixels)
- use flexible images
- and arguably the most important, media queries
Combining these techniques (read Ethan Marcotte’s Responsive Web Design for more details) will allow you to create a website that shrinks and grows and ebbs and flows to respond and adapt to whatever device is used to view it with, from the smallest mobile phone to the largest computer monitors and TVs.
Yes, I said TVs. Who says your website will only be viewed on phones, tablets, and computer monitors? It can just as easily be viewed on TVs, mobile gaming devices, and nearly anything with a screen and internet connection.
For years and years, we used pixels to define widths, heights, font sizes, and nearly everything else as we built a website. Ignoring pixel density for now, the size of a pixel is not dynamic. If I define the width of a block of text as 640px, it’s not going to be completely visible on a mobile phone with a width of 320px without scrolling and/or zooming. And if the user zooms out to see the full element, now the text has shrunk to half its intended size. Not good. So we use relative units instead. Now we can define that width as 100% and it will appear as full width on every device, with the text staying the same size and wrapping as it needs to depending on that specific device.
This has the same benefit for images as well, although it can have some unforeseen side effects. Instead of defining the width of an image as 100%, we can define it’s max-width as 100% so that it won’t grow outside of its container but so it also won’t grow beyond its native size. This may not suffice if the image is uploaded with its original dimensions hard-coded, as the width would be constricted but the height would not resulting in the image being stretched vertically. For this, we can also define the height as “auto” so it maintains its original aspect ratio.
Media queries are our bread and butter, because they allow us to completely change the layout of a page at a particular breakpoint. When I say “breakpoint”, I’m referring to a specific width/height at which I can change from one layout to another. On a mobile device with a smaller width, I may want a group of images to be displayed in a single column. But once there’s enough space, say 480px, I may want them displayed in two columns. And three columns at 640px, and so on, and so on. At each of these breakpoints, I use a media query to apply new and different rules to this group of images to lay them out how I want.
Notice that I’m starting with the smallest width and moving up to the largest. Although media queries are widely supported, it’s best practice to support mobile first (see Luke Wroblewski’s Mobile First) and then enhance as necessary.
Another great thing about media queries is that you’re not limited to one, or two, or three. You don’t (and shouldn’t!) change the entire site to move from a “mobile” layout to a “tablet” layout and again to a “desktop” layout, because there’s no such thing. Each media query is designed for and tailored to the content that’s contained within. I’m changing that grid of images to two columns at 480px and three columns at 640px, but those were all staff photos that shouldn’t grow too large. I have another grid of scenic photographs that I won’t want to change to a two column layout until 720px and a three column layout until 1280px. You’re not constrained whatsoever.
So that’s it, right? Switch to percentages and viewport units and add some media queries and you’re done? Easy peasy lemon squeezy?
Not even close. After all, it does say “Back to Basics” in the title. That’s just the tip of the iceberg. In practice, it is much more detailed and fine-grained, and it changes drastically from one project to the next.
Which is what I love so much about my job. Every project is a new design, and every design brings a new challenge and a new coordinated team effort. From our UX Designer who has to keep these principles in mind when designing, to back-end development which needs to provide each client with the tools necessary to manage the content and maintain that responsiveness, to front-end development to bring all those pieces together.