Common Techniques in Responsive Web Design

In this article, I’ll dive into some of the most common practices for building responsive site layouts and experiences. I’ll describe the emerging and available techniques for site layouts that flexibly resize based on screen real estate (referred to as “fluid grids”) so as to ensure that users get complete experiences across whatever screen size they are using. Additionally, I’ll show how to present rich media, especially images, and how developers can ensure that visitors on small-screen devices do not incur additional bandwidth costs for high-quality media.

As you play with some of the techniques I describe, here are a few ways to test what your site looks like on different devices resolutions:

1. Benjamin Keen has a responsive Web design bookmarklet that you can add to your Favorites bar (or Bookmarks bar) on your browser of choice. You can click on this bookmarklet to test your site layout in different resolutions.
2. If you’re using Windows 8, you can always test your page layout on Internet Explorer 10 by employing the Windows 8 snap modes. In Windows 8, you can use Internet Explorer 10 on your full screen (full mode), or you can multitask by docking the browser to snap mode, where it emulates the layout characteristics of a smart phone browser. Additionally, you can dock the browser into fill mode, where it occupies 1024 x 768 pixels (px) on a default Windows 8 screen size of 1366 x 768 px. This is a great proxy for how your site will look on iPad screens as well as traditional 4:3 screens.
3. Lastly, you’ll probably do a lot of what you see in Figure 1 (image courtesy Reddit.com).

Figure 1. Basic Testing for Responsive Web Design

Media Queries

Traditionally, developers have relied on sniffing out the browser’s user-agent string to identify whether a user is visiting a site from a PC or a mobile device. Often, after doing so, they redirect users to different subsites that serve up virtually the same content but with different layout and information design. For example, in the past, users who visited MSN.com could see the traditional PC experience or get hardware-specific mobile experiences by being redirected to http://m.msn.com.

But redirections require two separate engineering efforts. Also, this approach was optimized for two screen layouts (mobile with 320-px width and desktop with 1024-px width). It did not intelligently provide a great experience for users visiting from intermediate device sizes (such as tablets) as well as users with significantly larger screens.

CSS3 looks to help Web developers separate content creation (their page markup and functionality in HTML and JavaScript) from the presentation of that content and handle layout for different dimensions entirely within CSS via the introduction of media queries.

A media query is a way for a developer to write a CSS3 stylesheet and declare styles for all UI elements that are conditional to the screen size, media type and other physical aspects of the screen. With media queries, you can declare different styles for the same markup by asking the browser about relevant factors, such as device width, device pixel density and device orientation.

But even with CSS3, it’s very easy to fall into the trap of building three different fixed-width layouts for the same Web page markup to target common screen dimensions today (desktop, tablet and phone). However, this is not truly responsive Web design and doesn’t provide an optimal experience for all devices. Media queries are one part of the solution to providing truly responsive Web layout; the other is content that scales proportionally to fill the available screen. I’ll address this later.

What Does “Pixel” Mean Anymore?

The pixel has been used for Web design and layout for some time now and has traditionally referred to a single point on the user’s screen capable of displaying a red-blue-green dot. Pixel-based Web design has been the de facto way of doing Web layout, for declaring the dimensions of individual elements of a Web page as well as for typography. This is primarily because most sites employ images in their headers, navigation and other page UI elements and pick a site layout with a fixed pixel width in which their images look great.

However, the recent emergence of high-pixel-density screens and retina displays has added another layer of meaning to this term. In contemporary Web design, a pixel (that is, the hardware pixel we just discussed) is no longer the single smallest point that can be rendered by a screen.

Visit a Web site on your iPhone4, and its 640 x 960 px hardware screen will tell your browser that it has 320 x 480 px. This is probably for the best, since you don’t want a 640-px wide column of text fitted into a screen merely 2 inches wide. But what the iPhone screen and other high-density devices highlight is that we’re not developing for the hardware pixel anymore.

The W3C defines a reference pixel as the visual angle of 1 px on a device with 96 ppi density at an arm’s length distance from the reader. Complicated definitions aside, all this means is that when you design for modern-day, high-quality screens, your media queries will respond to reference pixels, also referred to as CSS pixels. The number of CSS pixels is often going to be less than the number of hardware pixels, which is a good thing! (Beware: hardware pixels are what most device-manufacturers use to advertise their high-quality phones, slates and retina displays—they’ll lead your CSS astray.)

This ratio of hardware pixels to CSS pixels is called device pixel ratio. A higher device pixel ratio just means that each CSS pixel is being rendered by more hardware pixels, which makes your text and layout look sharper.

Wikipedia has a great list of recent displays by pixel density, which includes device pixel ratio. You can always use CSS3 media queries to identify the device pixel ratio if you must, as so:

1. /*Note that the below property device pixel ratio might need to be vendor-prefixed
2.  for some browsers*/
3. @media screen and (device-pixel-ratio: 1.5)
4. {
5.   /*adjust your layout for 1.5 hardware pixels to each reference pixel*/
6. }
7. @media screen and (device-pixel-ratio: 2)
8. {
9.   /*adjust your layout, font-sizes etc. for 2 hardware pixels to each reference pixel*/
10. }

There are also some open source libraries that let developers calculate device pixel ratio using JavaScript across browsers, such as GetDevicePixelRatio by Tyson Matanich. Note that this result is available only in JavaScript, but it can be used to optimize image downloads so that high-quality images (with larger file sizes) are not downloaded on nonretina displays.

However, it is not recommended that you use device pixel ratio to define your page and content layout. While the reference pixel vs. hardware pixel disparity can be confusing, it’s easy to understand why this is crucial in offering users a better experience. An iPhone 3GS and iPhone 4 have approximately the same physical screen size and have identical use patterns, so it stands to reason that a block of text should have approximately the same physical size.

Similarly, just because you have an HDTV with a 1920 x 1080 p screen, this doesn’t mean sites should render content at this native resolution. Users sit several feet away from their TV and also use imprecise input mechanisms (such as joysticks) to interact with it, which is why it’s preferred that TV browsers pack multiple hardware pixels into a reference pixel. As long as you’ve designed your site with a 960-px wide layout for desktop browsers, the site will look comparable and be usable, regardless of whether your TV is 1080 p or an older model with 720 p.

As a general rule of thumb, your text content will look better on these devices. However, your image content may look pixelated and blurry. Thus, from a practical perspective, device pixel ratio matters most when you’re trying to serve high-quality photography/image data to your users on high-pixel-density screens. Moreover, you want to make sure that your brand logo looks sharp on your users’ fancy new phones. Later in this article, I’ll talk about techniques for implementing responsive images and point to some existing JavaScript libraries that can address this.

As we continue, I’ll use the term pixel to mean reference pixel and explicitly call out hardware pixel as needed.

Scaling Your Site Layout Responsively

Grid-based layout is a key component of Web site design. Most sites you visit can easily be visualized as a series of rectangles for page components such as headers, site navigation, content, sidebars, footers and so on.

Ideally, when we design responsive sites, we want to make the grid layout agnostic of the user’s screen size. This means we want our layout and content to scale to as much screen real estate as is available (within reason), instead of providing two or three fixed-width layouts.

Mobile-First Design

As I pointed out in the first article of this series, more than 12 percent of the world’s Web traffic comes from mobile devices. This fraction is significantly higher in nations with higher smartphone penetration and is expected to increase notably in the next few years as adoption picks up in Asia, Latin America and Africa.

Additionally, taking a mobile-first approach to site design is a good exercise in information design. Basically, it helps you prioritize the content and functionality that you want to make available on the mobile version of a site and then progressively enhance the site layout for larger devices. This way you ensure that your users have a valuable experience on their mobile devices—not just an afterthought to their desktop experience—and you can take advantage of additional real estate when available to provide a more visually engaging experience as well as navigation to additional “tier-two” content.

Case Study: The Redesigned Microsoft.com

When you visit microsoft.com on a mobile phone or narrow your PC browser width (with screen width under 540 px), you see a single hero image as part of a touch-friendly, visually rich slide show advertising one product at a time. (See Figure 2.) The top products are highlighted in the Discover section. Additional navigation is below the fold or in an accordion-style menu that is collapsed by default and is exposed when the user taps the list icon. Similarly, the search box is hidden by default to conserve screen real estate—the user needs to tap the search icon. This way, the mobile layout shows top products and links one below the other and only requires vertical panning. Content and product links below the fold are prioritized from top to bottom.

Figure 2. Microsoft.com as Designed for Mobile Phones

Once the width of the viewport exceeds 540 px (at which point we can assume that the user is no longer viewing the site on a phone but on a tablet or a low-resolution PC), you notice the first layout change (Figure 3). The search box is now visible by default, as is the top-level navigation, which was previously hidden under the list icon. The products in the Discover section are now presented in a single line, since they fit in the available width. Most importantly, notice that in this transition the hero image always occupies the available width of the screen.

Figure 3. Microsoft.com After Exceeding 540 px

The next layout change, shown in Figure 4, occurs at a width of 640 px or higher. As always, the hero image takes up all available screen width. The individual items within the For Work section are laid out side-by-side. The additional real estate also allows the caption for the hero image to be presented in line with the image and with motion, which is very eye-catching.

Figure 4.Layout Change at 640 px or Higher

The last layout change occurs at screen widths of 900 px and higher (Figure 5). The Discover menu floats to the left to take advantage of available horizontal space, which reduces the need for vertical scrolling.

Figure 5. Layout at Screen Widths of 900 px and Higher

Finally, and most importantly, the page layout—especially the hero image—continues to scale and fill the available horizontal real estate (until 1600 px) so as to maximize the impact of the visual eye-candy (Figure 6). In fact, this is the case for all screen widths between 200 px and 1600 px—there is never any wasted whitespace on the sides of the hero image. (Similarly, the relative layouts of the Discover and For Work sections don’t change, but the images scale proportionally as well.)

Figure 6. Maximizing Impact at Higher Resolutions

Techniques for Responsive Layout

Great, so how do we implement this kind of experience? Generally, the adaptive layout for Web sites boils down to two techniques:

• Identify break points where your layout needs to change.
• In between break points, scale content proportionally.

Let’s examine these techniques independently.

Scaling Content Proportionally Between Break Points

As pointed out in the evaluation of microsoft.com, the relative layout of the header, hero image, navigation area and content area on the home page do not change for a screen width of 900 px or higher. This is valuable because when users visit the site on a 1280 x 720 monitor, they are not seeing a 900-px wide Web site with more than 25 percent of the screen going to whitespace in the right and left margins.

Similarly, two users might visit the site, one with an iPhone 4 with 480 x 320 px resolution (in CSS pixels) and another using a Samsung Galaxy S3 with 640 x 360 px resolution. For any layout with a width less than 512 px, microsoft.com scales down the layout proportionally so that for both users the entire mobile browser is devoted to Web content and not whitespace, regardless of whether they are viewing the site in portrait or landscape mode.

There are a couple of ways to implement this, including the CSS3 proposal of fluid grids. However, this is not supported across major browsers yet. You can see this working on Internet Explorer 10 (with vendor prefixes), and MSDN has examples of the CSS3 grid implementation here and here.

In the meantime, we’re going to use the tried-and-tested methods of percentage-based widths to achieve a fluid grid layout. Consider the simplistic example illustrated in Figure 7, which has the following design requirements:

1. A #header that spans across the width of the screen.
2. A #mainContent div that spans 60 percent of the width of the screen.
3. A #sideContent div that spans 40 percent of the screen width.
4. 20-px fixed spacing between #mainContent and #sideContent.
5. A #mainImage img element that occupies all the available width inside #mainContent, excluding a fixed 10-px gutter around it.

Figure 7. Set Up for a Fluid Grid

The markup for this page would look like the following:

1. <!doctype html>
2. <html>
3. <head>
4.   <title>Proportional Grid page</title>
5.   <style>
6.     body {
7.       /* Note the below properties for body are illustrative only.
8.          Not needed for responsiveness */
9.       font-size:40px;
10.       text-align: center;
11.       line-height: 100px;
12.       vertical-align: middle;
13.     }
14.     #header
15.     {
16.       /* Note the below properties for body are illustrative only.
17.          Not needed for responsiveness */
18.       height: 150px;
19.       border: solid 1px blue;
20.     }
21.     #mainContent {
22.       width: 60%;
23.       float: right;
24.       /*This way the mainContent div is always 60% of the width of its parent container,
25.         which in this case is the  tag that defaults to 100% page width anyway */
26.       background: #999999;
27.       }
28. #imageContainer {
29.     margin:10px;
30.     width: auto;
31.     /*This forces there to always be a fixed margin of 10px around the image */
32. }
33. #mainImage {
34.     width:100%;
35.     /* the image grows proportionally with #mainContent, but still maintains 10px of gutter */
36. }
37. #sideContentWrapper {
38.     width: 40%;
39.     float: left;
40. }
41. #sideContent {
42.     margin-right: 20px;
43.     /* sideContent always keeps 20px of right margin, relative to its parent container, namely
44.        #sideContentWrapper. Otherwise it grows proportionally. */
45.     background: #cccccc;
46.     min-height: 200px;
47.     }
48.   </style>
49. </head>
50. <body>
51.   <div id=“header”>Header</div>
52.   <div id=“mainContent”>
53.     <div id=“imageContainer”>
54.       <img id=“mainImage” src=“microsoft_pc_1.png” />
55.     </div>
56.     Main Content
57.   </div>
58.   <div id=“sideContentWrapper”>
59.   <div id=“sideContent”>
60.     Side Content
61.   </div>
62.   </div>
63. </body>
64. </html>

A similar technique is employed by Wikipedia for its pages. You’ll notice that the content of an article seems to always fit the available screen width. Most interestingly, the sidebars (the left navigation bar as well as the right column with the HTML5 emblem) have a fixed pixel width and seem to “stick” to their respective sides of the screen. The central area with the textual content grows and shrinks in response to the screen size. Figure 8 and Figure 9 show examples. Notice the sidebars remain at a fixed width, and the available width for the remaining text content in the center gets proportionally scaled.

Figure 8. Wikipedia on a 1920-px wide monitor

Figure 9. Wikipedia on a 800-px wide monitor

Such an effect for a site with a fixed navigation menu on the left can easily be achieved with the following code:

1. <!DOCTYPE html>
2. <html>
3.   <head><title>Fixed-width left navigation</title>
4.   <style type=“text/css”>
5.   body
6.   {
7.     /* Note the below properties for body are illustrative only.
8.        Not needed for responsiveness */
9.     font-size:40px;
10.     text-align: center;
11.     line-height: 198px;
12.     vertical-align: middle;
13. }
14.  #mainContent
15.  {
16.     margin-left: 200px;
17.     min-height: 200px;
18.     background: #cccccc;
19. }
20. #leftNavigation
21. {
22.     width: 180px;
23.     margin: 0 5px;
24.     float: left;
25.     border: solid 1px red;
26.     min-height: 198px;
27. }
28. </style>
29. </head>
30. <body>
31. <div id=“leftNavigation”>Navigation</div>
32. <div id=“mainContent”>SomeContent</div>
33. </body>
34. </html>

Changing the Page Layout Based on Breakpoints

Proportional scaling is only part of the solution—because we don’t want to scale down all content equally for phones and other small-screen devices. This is where we can use CSS3 media queries to progressively enhance our site experience and add additional columns as screen size grows larger. Similarly, for small screen widths, we might use media queries to hide entire blocks of low-priority content.

MediaQueri.es is a great resource to browse to see what kinds of layout changes sites undergo at their breakpoints. Consider the example of Simon Collision shown in Figure 10.

Figure 10. Simon Collision at Different Screen Sizes

We can achieve a similar experience using CSS3 media queries. Let’s examine the simple example illustrated in Figure 11, where I have four divs: #red, #green, #yellow and #blue.

Figure 11. Example for CSS Media Queries

Here’s the sample code:

1. <!doctype html>
2. <html>
3. <head>
4. <title>Break points with media queries</title>
5.   <style type=“text/css”>
6.     /* default styling info*/
7. /* four columns of stacked one below the other in a phone layout */
8. /* remember to plan and style your sites mobile-first */
9.  
10. #mainContent
11. {
12.   margin: 40px;
13. }
14.  
15. #red, #yellow, #green, #blue
16. {
17.   height: 200px;
18. }
19. #red
20. {
21.   background: red;
22. }
23. #green
24. {
25.   background: green;
26. }
27. #yellow
28. {
29.   background: yellow;
30. }
31. #blue
32. {
33.   background: blue;
34. }
35.  
36. @media screen and (max–width:800px) and (min–width:540px)
37. {
38.   /* this is the breakpoint where we transition from the first layout, of four side-by-side
39.      columns, to the square layout with 2X2 grid */
40.  
41.   #red, #blue, #green, #yellow {
42.     width:50%;
43.     display: inline–block;
44.   }
45. }
46.  
47. @media screen and (min–width:800px)
48. {
49.   /*custom styling info for smartphones small screens;
50.     All columns are just displayed one below the other */
51.  
52.   #red, #yellow, #green, #blue {
53.     width: 25%;
54.     display: inline–block;
55.     white-space: nowrap;
56.   }
57.  
58. }
59.  
60.   </style>
61. </head>
62. <body>
63.   <div id=“mainContent”>
64.     <div id=“red”></div><div id=“green”></div><div id=“yellow”></div><div id=“blue”></div>
65.   </div>
66. </body>
67. </html>

Often though, you don’t need to write such stylesheets from scratch. After all, what’s Web development without taking advantage of the abundance of open-source frameworks out there and available, right? Existing grid-layout frameworks, such as Gumby Framework (which is built on top of Nathan Smith’s tried-and-true 960gs) and the Skeleton Framework, already provide out-of-box support for reordering the number of grid columns based on available screen width. Another great starting point, especially for a Wikipedia-esque layout, is the simply named CSS Grid. This provides users with the standard fixed-width left navigation bar, which disappears when the screen resolution shifts to that of tablets and smartphones, giving you a single-column layout.

More Media Queries

Depending on the needs of your site design, you might require other pieces of data about the device/viewport before making your CSS decisions. Media queries let you poll the browser for other attributes as well, such as:

• Device width and height. This is a useful set of properties to get not just the width available to the browser but the overall width of the device, which can give you insight into the device form factor.
• Device width and orientation (portrait vs. landscape).
• Browser aspect ratio and device aspect ratio.

And others are defined here.

Earlier, we broke down the two components of responsive layout to examine how they’re implemented. It’s crucial to remember that truly responsive layout is device agnostic—that is, not optimized for specific device widths—and is therefore a combination of the two techniques.

Images and Photos

Images are used on the Web for photo content as well as for styling (for background textures, custom borders and shadows and icons). Images make the Web beautiful, and we certainly want our sites to look rich and inviting to all users. However, the biggest concerns around images relate arguably to the most important part of the user experience—namely, performance and page load time.

Bandwidth Impact of Images

Our Web sites get served up in text—HTML, CSS and JavaScript. Often, these files don’t take more than 50 kilobytes or so to download. Images and other media are usually the most bandwidth-hungry parts of our pages. All the images on the homepage of a news site can add up to a couple of megabytes of content, which the browser must download as it renders the page. Additionally, if all the image content comes from separate files, each individual image file request causes additional network overhead. This is not a great experience for someone accessing your site on a 3G network, especially if you’re looking to serve up a gorgeous 8-megapixel panoramic landscape background. Besides, your user’s 320 x 480 px phone will not do justice to this high-quality image content. So, how do you ensure that users get a quick, responsive experience on their phones, which can then scale up to a richer media experience on larger devices?

Consider the following techniques, which you can combine to save users image downloads on the order of several hundred kilobytes, if not more, and provide a better performing experience.

Can You Replace Your Images with CSS?

CSS3 can help Web developers avoid using images altogether for a lot of common scenarios. In the past, developers have used images to achieve simple effects like text with custom fonts, drop-shadows, rounded corners, gradient backgrounds and so on.

Most modern browsers (Internet Explorer 10, Google Chrome, Mozilla Firefox and Safari) support the following CSS3 features, which developers can use to reduce the number of image downloads a user needs while accessing a site. Also, for older browsers, a number of these techniques degrade naturally (for example, the rounded border just gives way to a square border on Internet Explorer 8 and earlier), and this way your sites are still functional and usable on older browsers.

• Custom font support using @font-face. With CSS3, you can upload custom fonts to your site (as long as you own the license to do so) and just point to them in your stylesheet. You don’t need to create images to capture your page titles and headers or embed custom fonts for impactful titles and headers
• Background-gradients. Go to a lot of top sites, and you’ll notice that the background of the site is usually a gradient color, which helps the page look less “flat.” This can easily be achieved with CSS3, as seen here.
• Rounded corners. CSS3 allows you to declaratively specify a border-radius for each of the four corners of an HTML element and avoid having to rely on those pesky 20 x 20 px images of circles to create a rounded box on your site design.
• 2-D transforms. CSS3 allows you to declare 2-D transforms such as translate(), rotate(), skew() and others to change the appearance of your markup. IETestDrive has a great working example here. Common transforms such as rotation might cut back on the number of image downloads.
• Box-shadow and text-shadow. Modern browsers support box-shadow and text-shadow, which allow site developers to make their content look more three dimensional and add prominence to important pieces of content (such as header text, images, floating menus and the like)

Some of these properties might require a browser-specific implementation (using a vendor prefix) in addition to the standard implementation. HTML5Please is a convenient resource for identifying whether you need to use additional vendor prefixing for your CSS3.

Now, to be fair, users visiting your site on older browsers will see a functional but less aesthetic version of your site content. But the trade-off here is to ensure that the ever-growing number of people who visit your sites via cutting-edge mobile devices and 3G Internet have a fast, responsive site experience.

Use JavaScript to Download the Right Image Size for the Right Context

If your site experience inherently relies on pictures, you need a solution that scales across the spectrum of devices and network conditions to offer users a compelling experience in the context of the device they use. This means that on high-quality cinema displays you want to wow your audience with high-quality (that is, large file size) images. At the same time, you don’t want to surface your 1600 x 1200 px photographs to users on a 4-inch cellphone screen with a metered 3G data connection.

While the W3C is working on proposals for how to declare different image sources for a given picture, a few emerging JavaScript technologies can help you get started right now.

Media Query Listeners

Media Query Listeners are supported in modern browsers. They let developers use JavaScript to verify whether certain media query conditions have been met, and accordingly decide what resources to download.

For example, say your Web page has a photograph that someone posted. As a developer, you need to do two things:

• Decide the thresholds (or break points) for showing a high-quality (large-screen experience) or a small-screen experience, and based on that decision, download a high-quality set of resources or the low-bandwidth set of resources. Include the following script at load time to ensure that your page downloads the appropriate set of assets and provides users with the right experience:

1. var mediaQueryList = window.matchMedia(“(min-width:480px)”);
2. //NOTE: for IE10 you will have to use .msMatchMedia, the vendor-prefixed implementation
3.  //instead
4. isRegularScreen = mediaQueryList.matches;
5. //this returns a Boolean which you can use to evaluate whether to use high-quality assets or
6. //low-bandwidth assets
7.  
8. if (isRegularScreen)
9. {
10.   //run script to download the high-quality images
11. }
12. else
13. {
14.   //the condition has failed, and user is on smartphone or snap-mode
15.   //run script to download low-bandwidth images
16. }

• Optionally, add an event listener to watch for changes to the media size so that as a user resizes her browser window, you can run different sets of scripts to acquire high-quality resources as needed. For example, a user might first visit your site on Windows 8 in snap mode with a 320-px width. Later, the user might find your content interesting and open the browser in full-mode (and even share what she is seeing on her HDTV.) At this point, you might want to provide a better experience for your media:

1. mediaQueryList.addListener(mediaSizeChange);
2. function mediaSizeChange(mediaQueryList)
3. {
4.   //Executed whenever the media query changes from true to false or vice versa
5.   if(mediaQueryList.matches)
6.   {
7.     //run script to acquire high-quality assets;
8.   }
9. else{
10.   //in this case the user has gone from a large screen to small screen
11.   //by resizing their browser down
12.   //if the high-quality images are already downloaded
13.   //we could treat this as a no-op and just use the existing high-quality assets
14.  
15.   //alternatively, if the smaller image shows a clipped version of the high-quality image
16.   //trigger the download of low-bandwidth images
17.  
18.   }
19. }

Custom JS Libraries

Of course, there are also custom libraries to help you with this. These libraries work in a similar way by identifying the size and resolution of the user’s device and then delivering, on-the-fly, a scaled-down version of your source image over the network. Here are some examples:

• The Filament Group, which redesigned the Boston Globe site to be responsive, has a technique available here, which requires you to add some JavaScript files to your site and alter your site’s .htaccess file. Then, for each of your <img> tags, you provide a regular-size version as well as a hi-res version, and their plug-in takes care of the rest.

1. <img src=“smallRes.jpg” data-fullsrc=“largeRes.jpg”>

• A similar technique is available at AdaptiveImages.com. The benefit of this technique is that it does not require developers to hand-code their markup to point to low-resolution and high-resolution images, nor does it require developers to manually upload two different versions of the same image.

·        Tyson Matanich has made publicly available the Polyfill codebase, which is the technique used by microsoft.com in its adaptive redesign detailed earlier. Tyson also sheds light on the rationale behind the available functionality in the Polyfill library in his blog post. Some of the optimizations that Tyson and his team have made for the Polyfill codebase include the following (which work across browsers, even on Internet Explorer 6):

1. Allow developers to specify which images should load before the DOM is ready (must-have images for page content).
2. Allow developers to specify which images to load only after the rest of the page is ready (for example, images in a slide show that will only toggle 10 seconds later).
3. Allow developers to decide whether new images should be downloaded and swapped in at the time a browser is resized.

The blog post details all the optimizations that have been exposed to developers in the Polyfill API.

Text

Sites use text to communicate organization and content to their users in two predominant ways, namely body text and header text. It’s definitely valuable to think through how your site is going to scale these across different contexts.

Body text is particularly interesting if your site features articles, blog posts and tons of written content that users consume. Your mobile users want to read the same 500-word article on their desktop, TV and 320-px width screens and, as the site developer, you want to balance readability with convenience (that is, not having to scroll too much). The width of the article’s body can be scaled up to match the screen size, but more than that, you can offer larger type and improved line spacing to further improve readability for users with bigger screens.

Blocks of text are usually most readable when they hold approximately 66 characters per line, so if your site really depends on readability of long articles, optimizing type responsively for users can really improve their overall experience.

The following example uses the CSS3 media query max-width to progressively increase the readability of paragraph text:

1. /* pack content more tightly on mobile screens to reduce scrolling in really long articles */
2. p {
3.   font-size:0.6em;
4.   line-height: 1em;
5.   letter-spacing: -0.05em;
6. }
7.  
8. @media screen and (max-width:800px) and (min-width:400px)
9. {
10.   /* intermediate text density on tablet devices */
11.   p
12.   {
13.     font-size:0.8em;
14.     line-height: 1.2em;
15.     letter-spacing: 0;
16.   }
17. }
18.  
19. @media screen and (min-width:800px)
20. {
21.   /* text can be spaced out a little better on a larger screen */
22.   p
23.   {
24.     font:1em ‘Verdana’, ‘Arial’, sans-serif;
25.     line-height: 1.5em;
26.     letter-spacing:0.05em;
27.   }
28. }

AListApart.com has a great example of an article with responsively scaled type here.

Additionally, your site probably uses headlines to break up content—to make it easier for a user who is scanning through your site’s pages to quickly identify how information and functionality are structured. Sites often use headlines with large impactful type and add margins and padding.

Headers in HTML (specifically <h1>, <h2>, and similar tags) usually are automatically styled not just to use a large font-size attribute but also spacious margins and padding to ensure that they stand out and break the flow of content.

With a similar technique, you can consider scaling down the text size, margins, padding and other spacing attributes you use for your headlines as a function of the available device real-estate. You can also use available open-source solutions, such as FitText, to achieve this.

Optimizing Form Fields

If your site requires users to fill in forms, you might want to ensure that you can minimize interactions for touch users. This is especially relevant if you have a lot of text inputs.

HTML5 extends the type attribute for the <input> tag to let developers add semantic meaning to a textbox. For example, if a user is filling out a contact form, the phone number input can be marked up as <input type= “tel” /> and the email address field can be marked up as <input type= “email” />.

Modern browsers, especially those on touch devices, will parse this attribute and optimize the layout of the touch-screen keyboard accordingly. For example, when a user taps on a phone number field, the browser’s touch keyboard will prominently display a numpad, and when the user taps on the email address field, the touch keyboard will surface the @ key, as well as a .com key to minimize typing. This is a minor tweak that can really improve the overall form-filling experience on your site for users visiting via touchscreen phones and tablets.

One design to rule them all – Responsive design

In the last few years, the use of mobile devices to surf the web has increased significantly.

According to some researchers, by 2015, more mobile devices than desktop computers will be used to access the web. Mobile devices come in different sizes and capabilities. And since the desktop experience just isn’t good for mobile users, what are the options for improving the experience of mobile users on your website?

Improving the user experience across devices

Optimizing the user experience of a website across different devices is a complex process. Not only do you have to take into account the screen resolution of each device, but you also need to consider its capabilities (such as touch or pointer-based) and device size (1024×768 might be clearly readable for everyone on a 20-inch monitor but might result in a very bad experience on a 5-inch screen).

When you are planning improvements to the user experience of your website on mobile devices, there is no silver bullet approach. You have to research who your users are, which devices they use, and what they are trying to achieve on your website.

You also have to have clear goals for what purpose your website serves and how it should guide your visitors in the process of becoming your customers.

You have several options for improving the user experience of a public-facing website. Which one you choose depends on the different factors that apply to your scenario.

Mobile websites

In the past, when the web technology wasn’t as sophisticated as it is nowadays, it was a common practice to provide mobile users with a separate mobile website to optimize their experience. Being hosted on a separated URL, such as http://m.contoso.com, the mobile site would have a user experience optimized for mobile devices.

In some scenarios, organizations would even go a step further and optimize the copy on the mobile website. When a user navigated to the website using a mobile device, the main website would detect the use of a mobile device and automatically redirect the visitor to the mobile version.

It’s not that hard to imagine that building and maintaining two different sites is not only costly but also time consuming. Every update has to be done separately. Even then, with the diversity of today’s mobile devices, the questions remain whether a single mobile website would suffice and whether you wouldn’t need more websites to reach the whole spectrum of your customers.

Being able to reuse the content across the main and mobile websites simplifies the content management process. But the need to separately maintain the functionality of both websites makes it hard to justify this approach in most scenarios.

Mobile apps

One of the recent developments of the mobile market is the increased popularity of companion apps. By using the native capabilities of specific devices, you can build rich mobile apps to support different use cases. There is no better user experience on a mobile device than the native one offered by the device itself. For more information, see Build mobile apps for SharePoint 2013.

But is it realistic to build separate apps for all the different scenarios and for all the different mobile devices used to navigate the website? Although mobile apps are of great value for supporting specific use cases, there is still the need to access the information on the website from a mobile device in a user-friendly way.

Responsive web design

Instead of building separate mobile sites for mobile devices, what if we could have one website that automatically adapts itself to the particular device?

Responsive web design is a concept based on the ability to separate the design from the content on a website. Using the CSS media queries capability implemented in all modern browsers, and based on the screen dimensions of the specific device, you can load different style sheets to ensure that the website is presented in a user-friendly manner. And because CSS has its limitations, you can use JavaScript to further optimize the interface and interaction of a website on mobile devices. For more information, see Implementing your responsive designs on SharePoint 2013.

From the search engine optimization (SEO) perspective, responsive web design is the recommended way to optimize public-facing websites for mobile devices. After all, since the same HTML is sent to every device, it’s sufficient for an Internet search engine to index the content once, and it can be sure that the search results will apply the search query on every device.

Implementing responsive web design on a public-facing website is relatively easy assuming you start planning for it from the beginning. The great advantage of responsive web design above other approaches is that you maintain your website once to support a variety of audiences, and the different experiences are future-proof as they depend on the devices’ dimensions rather than their identity.

The following figures show how the sample Contoso Electronics website is displayed on different devices using responsive web design. Figure 1 shows the screen shot taken on a desktop device.

Figure 1. The Contoso Electronics website displayed on a desktop device

Figure 2 shows how the Contoso Electronics website looks like on different mobile devices.

Figure 2. The Contoso Electronics website displayed on mobile devices

SharePoint 2013 device channels

One of the new capabilities of SharePoint 2013 is device channels. You can use device channels to optimize how a website is displayed on different devices. By defining different channels and associating different devices with them, you can use different master pages to optimize how the website is presented to the user.

Figure 5 shows a sample configuration of device channels for a public-facing website built with SharePoint 2013.

Figure 3. Device channels configured for a public-facing website built on SharePoint 2013

Whereas responsive web design uses a device’s screen size to determine the presentation layer, device channels in SharePoint 2013 use the identity of the browser on the particular device to decide which presentation style to use.

Depending on how many different devices your site visitors use, managing the different devices and experiences can become complex. By using device channels, you get more flexibility in controlling the markup of your website for the different devices. Another benefit of using device channels is that you can serve different content to different devices, whereas the same content is served when using responsive web design. With device channels, you can apply additional optimizations to your website, such as resizing images and videos server-side using the renditions capability, which further improves the performance and user experience of your website. For more information, see How to: Manage image renditions in SharePoint 2013.

With all the different options at our disposal, which one should we use to get the best results?

Improving the user experience of a public-facing website in SharePoint 2013

First and foremost, it’s important to note that SharePoint 2013 supports all the methods mentioned above for improving user experience on mobile devices.

Whether you’re looking at building a separate website for mobile users, supporting certain use cases with a mobile app, implementing responsive web design, or using device channels, it can all be implemented in your website on top of SharePoint 2013.

Not only does SharePoint 2013 not stand in your way, but it also supports you in implementing some of those improvements.

For example, using the cross-site publishing capability, you can easily publish the centrally managed content on both the main and the mobile websites. With the Search REST API, you can have your content published in your mobile app, and if you’re looking at optimizing the presentation of your website across different devices, SharePoint 2013 offers plenty of features to help you.

With all these techniques at your disposal, it is up to you to decide which method, or combination of methods, is the best choice for what you’re trying to achieve. While you might be interested in supporting a particular complex process with a dedicated mobile app, it might still be of added value to ensure that everyone, regardless of their device, can access all the information on your website.

In most scenarios, it’s easy to choose whether or not the particular optimization technique offersadded value. A slightly more difficult choice, partly due to the similarity of both methods, is whether you should use responsive web design or device channels to optimize the presentation of your website for mobile devices.

Responsive web design and device channels comparison

Responsive web design and the SharePoint 2013 device channels capability are similar in how they let you optimize a single website to be displayed in a user-friendly way on different devices. Despite this similarity, there are a few important differences between both approaches. Table 1 presents a comparison of the different properties of both approaches.

Device channels	Responsive web design
Device management	Property management
Different HTML for every channel	Same HTML for every device
More management (support for new devices)	Future proof (device size)
More flexibility	Limited by CSS support and capabilities
Custom Vary-By User Agent response header required	Preferred by Internet search engines

Table 1. Comparison of device channels and responsive web design

Applying user experience

First of all, there is a difference in how both approaches determine which user experience should be applied for the particular user. Responsive web design uses the size of the screen to determine how the content should be laid out in the browser’s window. Device channels, on the other hand, use the identity of the browser to load the suitable channel.

While responsive web design can cause different experiences to be loaded depending on the size of the browser window, device channels will always load the same experience for the same device regardless of the browser window size. Using device channels can have great advantages, for example, from the troubleshooting point of view where the user and the helpdesk employee would see the same interface despite the possible differences in their screen resolutions or browser window sizes.

Page markup

Another difference between device channels and responsive web design is how the page contents are served. Responsive web design changes only the presentation layer of the website. Although you can hide some pieces of the page in the browser using CSS, they are still present in the website’s code and therefore loaded. When using device channels, you can use different master pages to ensure that only the relevant markup is served to users. Additionally, you can use the device channel panels to further control the content elements loaded on specific pages.

Although device channels allow for better control of the rendered HTML and therefore optimized performance of the website, more effort is required to ensure that Internet search engines will properly deal with all the different versions of the website presented to different devices. You can achieve this by using the Vary-By User Agent response header, but it has to be done manually.

Future-proofness

Responsive web design uses the size of the browser window to distinguish between the different experiences. This is a robust approach, and the chances are low that a new device will appear on the market that has a poor user experience despite the configured breakpoints. One reason for that might be related to some specific capabilities of such devices, but again, chances of this are very rare.

SharePoint 2013 device channels are based on the identity of the browser used to open the website. There are two challenges with this approach. First of all, in some situations it might be impossible to distinguish between the same browser installed on the same operating system but on two devices with distinct capabilities. Second, if a new device appears on the market, you would have to verify that this device is assigned to the right device channel on your website.

Choosing the right approach for optimizing the user experience

Although responsive web design and device channels are very similar, their capabilities differ and they have different impact when used for optimizing a website for mobile devices. Due to their similarities and their own strength, choosing between the two approaches is often difficult. Why not combine both approaches to get the best of what they offer?

Combining responsive web design and device channels

An interesting scenario worth considering is to combine responsive web design and SharePoint 2013 device channels to benefit from the strengths of both approaches.

When combining responsive web design and device channels, you could use responsive web design to create the baseline cross-device experience. Depending on your design for the different breakpoints, using responsive web design could be good for the 80%, or maybe even 90%, of the optimizations. The remainder—whether they’re caused by how the web design changes between the breakpoints or by the capabilities of the different devices that should be supported—could be covered by device channels and device channel panels.

By using responsive web design to build the baseline for the cross-browser experience, we benefit from its future-proofness and robustness. For the specific exceptions, we can benefit from the granular control that SharePoint device channels offer us.