Implementing Responsive Design: building sites for an anywhere, everywhere web
By: Tim Kadlec
Publisher: New Riders
Pub. Date: July 31, 2012
Print ISBN-10: 0-321-82168-8
Print ISBN-13: 978-0-321-82168-3
Web ISBN-10: 0-13-297938-1
Web ISBN-13: 978-0-13-297938-2
The delay in time as data is sent from one point to another.
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.
Primarily, you’ll stick to using width, height, orientation, resolution and perhaps aspect-ratio. Browser support for color, color-index, and device-aspect-ratio is subpar. Monochrome, scan, and grid don’t really apply to most devices at the moment.
When you start to define breakpoints entirely by the resolutions of common devices, you run the risk of developing specifically for those widths and ignoring the in-between (case in point, rotate the iPhone to landscape and you’ve just introduced a 480px width). It’s also not a particularly future-friendly approach. What’s popular today may not be popular tomorrow. When the next hot device emerges, you’ll be forced to add another breakpoint just to keep up. It’s a losing battle.
Follow the content
A better approach is to let the content dictate where your breakpoints occur, and how many of them you need. Start resizing your browser window and see where there’s room for improvement.
The mediaQuery bookmarklet (http://seesparkbox.com/foundry/media_query_bookmarklet) is a handy tool for seeing just what size your screen is as you resize, as well as what media queries are currently applied.
Wrapping It Up
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
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.
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.
Wait, what’s the answer here?
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.
An interactive medium
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.
It is a bad carpenter who quarrels with his tools.
Anatomy of a user agent string
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.
What can you do with user agent detection?
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 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 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.
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.
These are notes I made after reading this book. See more book notes
Just to let you know, this page was last updated Sunday, May 29 22