What is Responsive Web Design?
March 31, 2015
As a front-end developer I’m often asked questions along the lines of:
How long would it take to make our current site responsive?
What would it cost to update our existing site to be responsive?
Truthfully: It depends.
There are a lot of factors that go into creating a responsive website, and many of them require discussions and decisions between the client, the designer, and the developer.
I fully appreciate how frustrating it can be trying to get a straight answer, but when it comes to responsive design, there are many moving parts. As such, there often isn’t a single best approach. With that in mind, I think it’s worthwhile to start at the beginning.
What is Responsive Web Design?
Let’s look at what “Responsive Web Design” actually means:
Responsive web design (RWD) is an approach to web design aimed at crafting sites to provide an optimal viewing experience—easy reading and navigation with a minimum of resizing, panning, and scrolling—across a wide range of devices (from desktop computer monitors to mobile phones).
It’s important to note, Responsive Design doesn’t mean designing for mobile. It doesn’t mean designing for desktops, or tablets, or watches. It doesn’t mean making a mobile version and a desktop version. It means designing in a way that the content is accessible to any user, regardless of what device they’re using or how large their screen is.
Responsive web design should focus around the accessibility of the content. On the web, content is king.
Really? What about …?
Yes really, responsive web design is all about the content.
(Don’t) Name Breakpoints “mobile”, “tablet”, and “desktop”
It’s common when discussing designs to talk about “mobile”, “tablet”, and “desktop”. These names refer to the approximate size of the device screen, and make it easy to overlook the fact that desktop users will see the “mobile” and “tablet” designs simply by resizing their browser window.
It’s better to give the design breakpoints names that reflect the window size. Names like:
(Don’t) Hide Content at Different Screen Sizes
When the breakpoints are named poorly, sometimes people will ask about changing out content for different screen sizes. For example:
Can we hide the print button on the “mobile” breakpoint because mobile users can’t print?
In truth, mobile users can print. Even if they couldn’t, how would a desktop user print when they shrink their window? No one asks about desktop users who don’t have a printer, so the correct solution is to design so that everyone can use the feature, and allow users the option of ignoring features they don’t need.
Another common question:
The sidebar widget makes the page really long. Can we just hide it when the screen is too small?
This suggests the sidebar widget doesn’t contain important content, and should likely be removed from the page altogether. If content is displayed for some users, it should be accessible to all users. Users are very good at scrolling, so page length needn’t be a concern.
So How Does a Site go From Static to Responsive?
Because responsive web design is content-centric, migrating to a responsive design requires an audit of the existing content. The audit will help to determine what content is responsive as-is, and what content needs to be addressed.
It may be surprising, but the web is mostly responsive by default. It only takes 247 extra bytes to add enough styles to be completely responsive. Text content, like headings, paragraphs, and lists will default to expanding fluidly to fill their container.
Content that usually isn’t responsive by default includes:
- Drop down menus
When you’ve determine what content needs to be addressed, you’ll need to decide how to move each piece of it forward to be responsive. The options are to rewrite, refactor, or remove.
Images are pretty simple to update to be responsive. They usually fall into the refactor category by adding styles to fix alignment and size. For performance, it’s worthwhile to set images to use different sizes for different screens. That way, a user on a small screen downloads smaller images than a user on a large screen.
Drop Down Menus
Responsive navigation is trickier. It’s important to update the navigation so that it can be easily used on a touch screen device. It’s also important to think about users with assisted navigation, such as screen readers. Making sure the menu can be navigated via keyboard only, and touch screens usually involves updating the menu so that it doesn’t rely on mouse hovering. This is usually a win for all users, as hover-based menus are often frustrating to use.
Page-blocking modals can be tricky to set up responsively. In some cases, it’s better to put the contents of the modal inline on the page, and in others, it’s worth leaving the modal as is and styling it so that it fits the screen appropriately.
Carousels are one of the more complicated components for responsive design. While it’s certainly possible to set up carousels to be responsive, data suggests that they’re hardly used and not worth the effort. In my experience they’re often buggy and fail at accessibility compliance. Remove them and replace them with static content like a single call-to-action. The exception would be where a carousel is used as an image gallery, such as how Facebook displays images.
After the Audit
Once the audit is complete, the next step is to come up with a plan of attack. For small sites, this might mean planning a development effort to reskin the site responsively and plan a release date. For larger sites, this might mean planning a multiple-release schedule that involves reskinning parts of the site in sequence so that changes are released in smaller steps.
The complete reskin approach has the advantage that can all be wrapped up in one project and completed in one shot. The disadvantage is that serious issues might not crop up until after the site is released, and it may be too late to easily change.
The modular reskin approach has the advantage that each module can be tested and verified before the next modules are started. This allows low-level structural issues to be fixed before they’re too hard to fix. The disadvantage is that the project scope is more likely to change, as small extensions to any individual module will likely push back the final release and possibly raise the total cost of the project.
So About That Estimate?
Once all of the tasks outlined above have been completed, and a detailed plan in place, we can move on to creating a realistic estimate for the project. But if you really insist, it’ll take 6 to 8 weeks.
Have any questions or comments? Let us know on twitter.
Stay up to date with our email updates!