Converting your website to responsive design – Part IV

This is our final part of our look at converting your website to Responsive Design series, using our site as an example.

Today in Part 4, we look at some tips and tools in going responsive, as well as summarize our thoughts and conclusions of the process of converting our site to a Responsive Design.

Development tips

QA - Test on multiple devices

The easiest way to test a responsive design is to resize your browser to emulate small (smartphone), medium (tablet in portrait mode), large (tablet in landscape mode), and extra-large (monitor) screen widths. But it’s also important to test on a variety of real mobile devices, tablets, and smartphones in both portrait and landscape mode. Each device may have a different operating system and mobile browser version and therefore may render markup slightly differently.

Set source ordering for mobile grids

Some layouts require different ordering for mobile. For example, if you have a sidebar on the left, and content on the right, in a mobile view this layout would stack on top of each other, showing the sidebar first, and the content below it. However, in a mobile view, the content should be the main focus of the page, and should not be pushed down.

Foundation provides source ordering classes for the grid, so that the sidebar content will be pushed down below the content in a mobile view, but would remain the same in a desktop view.

Responsive video

Embedded videos from YouTube or Vimeo have a fixed width and height, and therefore often appear huge on smaller screens. Foundation provides a flexible video container class to wrap around these videos to constrain them to the current device’s width.

<div class="flex-video"> [Youtube embed code] </div>

After converting your site to Responsive Design, it is a good idea to review any existing content (static or dynamically loaded from a CMS) that displays videos and add the video container class to ensure these pages will display to it’s proper aspect ratio on a mobile device.

Printer-friendly styles

Foundation 3 includes some default print classes that are included in the main foundation stylesheet:

.print-only, .show-for-print – shows the content on printed pages only
.hide-for-print – hides the content for printed pages.

Also, by default, Foundation outputs the URLS next to every link when printing. To disable this feature, you have to manually disable it by adding the following CSS:

@media print {
a[href]:after,abbr[title]:after { content: none; }
}

Add a viewport meta tag

By default, a mobile device like the iPhone will try to display the page in a 980px zoomed viewport. A good example is the nytimes.com on an iPhone shows the entire page in a 980px width. Because our site is now responsive and does not need a default desktop browsing experience, we can set the viewport and tell the browser not to default to a desktop browsing viewport:

<meta name="viewport" content="width=device-width">

IE8 does not support media queries

CSS media queries are used to make the site responsive to different sized displays, but it is not supported in IE8. As IE8 is only really used on a desktop and not supported on any small display devices, it’s not really a scenario that would occur very often in the wild. The only reason it would be required is if your site needed to support very small monitor/screen resolutions in IE8. If your site does need to support it, there is a Respond.js project that addresses this issue for IE6-8.

Responsive images

By default, Foundation sets all images to be the maximum width of its containing element. This prevents the image from extending its boundary, but also automatically resizes images to a smaller when the container’s width is reduced in smaller width devices. Meaning, by default the image display becomes responsive and gets smaller as the screen gets smaller. A large image will not stay as a 900px wide image in an iPhone display on a Foundation-powered responsive site.

The problem is the display of the image is resized: the original, higher resolution 900px wide image is still loaded and displayed. An image for a 24” monitor is not usually suitable for a 4” smartphone. It would be optimal, and the page would load faster, if a smaller resolution image was loaded and displayed for smaller displays, but larger sized images would remain for larger displays. Unfortunately there currently isn’t an easy way to have a lower res image load for a mobile site, and a larger for tablets or desktop.

As of right now, there are a variety of custom solutions and hacks to address this issue, but there’s no simple solution to this complex problem. The W3C community is currently investigating and discussing a solution for an official spec, but no single, standard solution exists yet. And it’s entirely possible there may never be, as Matt Wilcox of Opera concludes in his white paper on the topic:

It's possible that a single grand solution will prove impossible, and we'll have to use a few techniques to achieve the things we want. It's possible that the only true solution will be patience while the constrained bandwidth and poor device capabilities problems slowly fade away—but while that may only be a few years away in privileged countries, the majority of the world will take a lot longer.

Development tools

The simplest tool in your arsenal is to simply resize your browser as you develop and test. This can become painful if you’re trying to resize to the exact widths and heights of the most popular mobile devices. There are a variety of tools and websites to fix this problem:

Responsive workflow and rapid prototyping

With a Responsive Design site, we discovered that we had to alter our usual workflow. A traditional workflow involves creating a wireframe, doing the visual design, then development. This approach requires more work to produce wireframes and different visual design mockups for each supported device. This can become impractical for larger sites, not to mention a heavier increase in budget and resourcing.

We implemented a much leaner, responsive workflow approach. We would have mini 2 day sprints where we’d meet and discuss with the entire team how the site and certain pages (like navigation on 2nd and 3rd tier content pages) should work. The developer would then work closely with the design team on a functional, or semi-functional, prototype of the feature. At the end of the mini-sprint, the developer would demonstrate what he worked on and the team would discuss again, sometimes going back multiple times to get the feature right.

With Responsive Design, the workflow needs to be much more iterative and prototyping earlier. Foundation and other Responsive frameworks help in this regard since they allow for rapid prototyping. Since we have all the UI components within the Foundation framework, we can easily assemble them to build semi-functional prototypes. This kind of quick-turnaround approach also requires a very engaged project team with a design team very involved with the technical aspects of Responsive Design.

Further reading

Summary

In summary, to convert a website to Responsive Design, first decide on a framework like Foundation or Bootstrap. Then decide if it’s easier to build a new template from scratch and import each page, or update your existing codebase. Then convert your code to use the components and styles of the framework. Once you have a functioning site for the desktop, you can then focus on making it responsive. Finally, QA the site on multiple browsers and multiple mobile devices and you’re done!

Conclusion

Mobile and tablet traffic is growing at a rapid rate, and web browser capabilities are improving, almost every day with some browsers such as Chrome and Firefox. Therefore it’s important to have a site that can adapt and respond to this growth of traffic from a disparate collection of devices.

Converting a website to a Responsive Design can be a little time consuming, especially starting from scratch and then importing each page or template one at a time. However, it ultimately improves your site by having it more sustainable in the long run. For example, when a new mobile device is introduced, such as newly released iPad mini or Microsoft Surface, your responsive website can be easily modified to support these devices by simply adding a new CSS3 Media Query to support the new screen width.

Using a framework like Foundation can help make development easier by using the framework’s guidelines and tested components rather than creating each from scratch. We were struck by the both the breadth of base components and optional Javascript components provided by Foundation. We also liked the fact that the base styles of these components were minimal and mostly un-styled, allowing our design team to easily override the base styles, rather than disable, then style.

The framework also provides an easier way to build rapid prototypes, which are useful when adopting a Responsive Workflow. We really enjoyed the process of adapting our usual workflow to a Responsive workflow because it allowed us to work more closely with our coworkers. It was exciting to build something quickly and get immediate feedback from team members, and then go back and iterate on a prototype until it was a fully functional component.

We hope you enjoy our new site.

Need help with your next responsive design project? We make new digital experiences possible with end-to-end capabilities that include strategy, usability, design, development, and analytics. Get in touch to learn more.