Implementing Responsive Design

The delay in time as data is sent from one point to another.

Device-agnostic

Anything (component, layout, etc) that is designed to be compatible across different device types and operating systems.

 The Web is universal. It is ubiquitous. Unlike any medium that has preceded it, the Web can adapt to any screen and any context. It is inherently flexible and malleable. 

Follow the content

---

Fluid layouts are a start, but they can only take us so far. At some point, we need to adjust the layout, sometimes dramatically, to better accommodate different devices.

Smartphones try to let us experience the full Web. If the meta viewport element isn’t being used, most smartphones display a zoomed version of the site.

Media queries let us test for features like width and height and adjust the CSS we apply to our design accordingly. They can be used both externally and internally. Each method has benefits and limitations, so it’s important to choose the approach that best meets the project requirements.

While it’s common to pick specific device widths for breakpoints, a better approach is to let the content dictate where you need to include a media query.

Responsive sites can be made even more flexible and accessible using ems, instead of pixels, for media queries.

Be sure to test on real devices. Doing so will alert you to things like navigation that may require adjustment for different displays.

Custom data attributes

Preceded by a data- prefix, these attributes store custom data private to the page, often for scripting purposes.

While every website is different, three causes for this over-downloading repeated across practically all websites.

• Download and Hide

• Download and Shrink

• Excess DOM

Download and Hide is by far the top reason for this bloat. Responsive websites usually return a single HTML to any client. Even on “Mobile First” websites, this HTML contains or references all that’s needed to provide the richest experience on the biggest display. On a smaller screen, sections that shouldn’t be shown are hidden using the display:none style rule.

Unfortunately, display:none doesn’t help performance one bit, and resources referenced in a hidden part of the page are downloaded just the same. Scripts within hidden sections still run. DOM elements are still created. As a result, even when hiding the majority of your page’s content, the browser will still evaluate the page in resources and download all the resources it can find.

Download and Shrink is a conceptually similar problem. RWD uses fluid images to better match the different screen sizes. While visually appealing, this means the desktop-grade image is downloaded every time, even when loaded on a much smaller screen. Users cannot appreciate the high quality image on the smaller screen, making the excess bytes a complete waste.

Excess DOM is the third episode of the same story. RWD websites return the same HTML to all clients. Browsers parse and process hidden areas of the DOM despite being hidden. As a result, loading a responsive website on a small screen results in a DOM that is far more complicated than what the user experience demands. A more complicated DOM leads to higher memory consumption, expensive reflows, and a generally slower website.

These problems are not simple to solve, since they’re the result of how RWD and browsers work today. However, there are a few practices that can help you keep your performance under control:

• Use Responsive Images

• Build Mobile First

• Measure

Responsive Images are already discussed in this book at length, and help address the “Download and Shrink” problem. Since images are the bulk of the bytes on each page, this is the easiest way to significantly reduce your page’s weight. Note that CSS images should be responsive as well, and can be replaced using media queries.

Build Mobile First means going a step beyond designing a Mobile First website, and actually coding a dedicated website for the lowest resolution you care about. Once implemented, this website should perform as well as other mdot sites, and be reasonably lightweight. From that point on, only enhance the page using JavaScript or CSS, to avoid over-downloading. Clients that have no JavaScript support will get your basic experience, which should be good enough for these edge cases. Note that enhancing with JavaScript and keeping performance high isn’t simple, and best practices for it are not fully established yet—which brings me to my next point.

Measure. Treat performance as a core part of your website’s quality, and don’t ship without understanding and accepting its performance. If you know your mobile website weighs over 1 MB, you’re likely to delay its launch until you do something about it. Measurement tools vary, but I would recommend Mobitest for testing on real devices (http://akamai.com/mobitest) and WebPageTest for testing on desktop browsers (www.webpagetest.org), resized them using the setviewportsize command.

In summary, Responsive Web Design is a powerful and forward thinking technique, but it also carries with it significant performance implications. Make sure you understand these challenges and design to avoid them, so that users won’t abandon your website before they got to experience your amazing visuals and content.

Content Delivery Network

A collection of servers deployed in multiple locations to help deliver content more efficiently to users.

Ultimately, no definitive solution currently exists for responsive images. Each method has advantages and disadvantages. The approach you take will depend on the project you’re working on.

Of the two approaches we’ve discussed, settling on Adaptive Images is probably the best route to take since it doesn’t require any reliance on a third-party source.

 The design process is an art, not a science. There are very few rules involved. Ultimately, each client, each project, each team works differently. You need to find the process that works best for you and your project.

A number of different criteria factor into what that process entails: the size of the team, the budget, the capabilities of the designers and developers, the timeline—these all dictate what deliverables and steps are necessary for a specific project.

Remember that the individual steps in the process are less important than adhering to a few key concepts:

• The Web is interactive. Your tools and deliverables should reflect that.

• The process needs to be collaborative.

• It’s not about pages anymore. It’s about systems.

We need to move away from working with the Web as if it were a static medium. It’s not. It’s flexible. It’s unpredictable. Settling into a rigid workflow with rigid, static deliverables doesn’t help us maximize on this potential. It limits us by applying arbitrary constraints where there are none.

To date, our approach to designing for the Web has closely resembled designing for print. We use many of the same tools for designing a website as we would for designing a poster. But print isn’t an interactive medium; the Web is. People don’t just look at a website, they interact with it. They click. They hover. They tap. The Web is a living, breathing canvas that they can manipulate and bend to their will. The Web is much closer to being software than it is to being print.

Our tools, techniques, and deliverables should better reflect the Web’s dynamic nature.

Designing for mobile first also helps to focus the discussion on the content that matters most for your site.  

Responsive design is more than a simple strategy: it’s the trigger for a completely new way of approaching projects for the Web, a new workflow that better utilizes the unique strengths of this remarkable platform.

This new workflow must be agile and flexible. Because of the collaborative nature of the new approach, communication, iteration, and especially respect are absolute musts. Designers and developers should work closely throughout every project.

A user agent string is one of several HTTP headers that get sent by the browser whenever a page or resource is requested. Its purpose is to identify the client (browser) in use. Unfortunately there’s no standard convention for how user agent strings should be written and there’s a lot of useless information. Consider the following example taken from a Samsung Acclaim:

Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; SCH-R880 Build/FROYO) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

All that matters out of that string is the following information:

• Android 2.2.1: This phone is running the Android OS, version 2.2.1.

• AppleWebKit/533.1: This is the layout engine and build number.

That’s about it. The SCH-R880 part tells us that this is a Samsung Acclaim, and that’s potentially of value as well, depending on what you want to do.

If you’re uncomfortable dissecting user agent strings manually, don’t worry: there are a lot of services out there that will do it for you. Still, it’s good to be aware of the general structure of user agent strings in order to understand how these services gather information based on them.

You can use user agent detection in a variety of ways. There are simple scripts that will parse the string and tell you if the device is “mobile” or something else.

WURFL

WURFL is one of the oldest and most widely implemented device detection repositories.

Many scripts that help with feature detection have popped up, the most popular of which is Modernizr. Modernizr tests over 40 different features and provides three things to help with development:

• It creates a JavaScript object containing the results of the tests.

• It adds classes to the HTML element indicating which features are and are not supported.

• It provides a script loader so you can conditionally load polyfills.

Note

You can download the latest version of Modernizr from http://modernizr.com.

Bridging the gap with Detector

One helpful tool for bridging the gap between client-side feature detection and server-side detection is Dave Olsen’s Detector, which can be found at http://detector.dmolsen.com.

Detector is a browser- and feature-detection library based on modernizr-server and the popular ua-parser.php, a browser-detection script that collects general information about the device such as the operating system or device name. Using this information, Detector can dynamically create profiles for each user-agent string that accesses a page.

While it doesn’t come with the power of WURFL or DeviceAtlas, it also doesn’t have to rely on a hefty database of device information. In that way, it’s a much more nimble solution. For many projects you may find you don’t need the kind of detail that WURFL supplies. If that is true, Detector is an excellent solution.