10:20 AM
Creating a Mobile-First Responsive Web Design

Introduction

We're going to walk through how to create an adaptive web experience that's designed mobile-first. This article and demo will go over the following:

The Need for Adaptivity

As the web landscape becomes increasingly complex, it's becoming extremely important to deliver solid web experiences to a growing number of contexts. Thankfully, responsive web design gives web creators some tools for making layouts that respond to any screen size. We'll use fluid grids, flexible images and media queries to get the layout looking great regardless of the size of the device's screen dimensions.

However, mobile context is much more than just screen size. Our mobile devices are with us wherever we go, unlocking entire new use cases. Because we constantly have our mobile devices with us, connectivity can be all over the board, ranging from strong wi-fi signals on the couch to 3G or EDGE when out and about. In addition, touch screens open new opportunities to interact directly with content and mobile ergonomics lead to different considerations when designing layout and functionality.

In order to create a site that's truly designed for mobile context and not just for small screens, we want to ensure that we tackle the many challenges of mobile development upfront. The constraints of the mobile context force us to focus on what content is essential and how to present that content as quickly as possible. Building fast-loading, optimized experiences mobile first has a trickle down (or up, depending on how you look at it) effect for tablet, desktop and other emerging contexts.

Structure

Authoring lean, semantic HTML5 markup keeps adaptive experiences manageable and accessible, and also provides opportunities for enhanced experiences (quick example: using proper HTML5 input types brings up the appropriate virtual keyboard on many touch devices). Semantic markup is extremely portable and can be accessed by many mobile devices, tablets, desktop browsers and future web-enabled devices, regardless of feature set or capability.

Setting the viewport

In order to accommodate for sites not optimized for mobile screens, many modern mobile browsers set a larger browser viewport, which allows for better viewing of non-mobile-optimized sites. Users can then pinch-to-zoom in on the content they want. That's fine for non-mobile experiences, but because we're optimizing our experience for mobile browsers, we'll use the viewport meta tag to set the screen width to the device width:

<meta name="viewport" content="width=device-width, initial-scale=1" />

It's important to note that we're not disabling the user's ability to zoom the page (which you could do by adding user-scalable=no to the content attribute), even though we're optimizing the content for small screens. It's recommended to keep user zooming enabled to keep things as accessible as possible. However, there are use cases to disable user-zooming, such as if you're including fixed positioned elements.

Content fragments

In order to keep the experience as lightweight as possible and to improve the perceived loading time, we're creating two additional HTML documents for our auxiliary content, reviews.html andrelated.html. Because this content isn't required for the main use case (buying the product) and includes a number of images, we won't load it by default to keep the initial page size down. By default the content is accessible via links on the page, but if a certain level of javascript support is present, we'll conditionally load the content when the user requests it or when the resolution reaches a certain breakpoint.

HTML Special Characters

A simple technique to reduce the need for background images (thereby saving HTTP requests) is to use HTML special characters for simple shapes. In the case of our rating stars, we're using &#9733; to create a solid star (★) and &#9734; to create empty stars (☆) for our ratings. And because it's HTML and not an image, it stays crisp even on high resolution screens.

The tel: URI Scheme

Another simple yet effective technique we're including in our footer is a clickable link to the customer service number. This is accomplished by using the tel URI scheme, which looks like this:

<a href="tel:+18005550199">1-800-555-0199</a>

We sometimes forget that mobile devices can make phone calls, and also that some desktop configurations can launch VoIP applications to initiate a phone call. We're including an easy way for users to facilitate a phone call, which in some cases might make sense (i.e. a mobile user who might prefer finishing the transaction over the phone versus going through a checkout flow on their mobile device).

Now that we have a strong, semantic foundation in place, let's move onto adding style enhancements.

Style

When crafting our CSS, we'll do everything in our power to keep things lightweight and as fluid as possible. We understand that all these devices have many different screen sizes, and that tomorrow's devices won't have the same resolutions as today's. Because screen size is an unknown, we'll use the content itself to determine how the layout should adjust to its container.

Separate style sheet for larger screens

We're creating two separate CSS files, style.css and enhanced.css in order to deliver basic styles for screens less than 40.5em and using media queries to serve up enhanced styles for screens larger than 40.5em.

<link rel="stylesheet" type="text/css" href="style.css" media="screen, handheld" />
<link rel="stylesheet" type="text/css" href="enhanced.css" media="screen and (min-width: 40.5em)" />
<!--[if (lt IE 9)&(!IEMobile)]>
<link rel="stylesheet" type="text/css" href="enhanced.css" />
<![endif]-->

We're using the conditional code <!--[if (lt IE 9)&(!IEMobile)]> in order to serve up enhanced.css to non-mobile versions of IE less than version 9, which unfortunately don't support media queries. While this method does indeed add an HTTP request to the mix, it gives us greater flexibility over our styles. Alternately, we could use respond.js to deliver enhanced styles to IE.

We're using the em unit instead of px to maintain consistency with the rest of our relative units and account for user settings like zoom level. Also, the content should determine the breakpoint (we're using 40.5em as a breakpoint) because device dimensions are too varied and are always changing so are therefore unreliable.

Mobile-First Styles

Starting with baseline shared styles and introducing more advanced layout rules when screen size permits keeps code simpler, smaller and more maintainable. Here's just a quick example to demonstrate this point:

/*Large screen styles first - Avoid*/
.product-img {
 width: 50%;
 float: left;
}
@media screen and (max-width: 40.5em) {
 .product-img {
 width: auto;
 float: none;
 }
}

We want to avoid complexity as much as we can, so here's what a mobile-first approach looks like:

@media screen and (min-width: 40.5em) {
 .product-img {
 width: 50%;
 float: left;
 }
}

Instead of declaring large screen rules first only to override them for smaller screens, we'll simply define rules as more real estate becomes available. The web by default is a fluid thing so we'll do our best to work with it instead of against it. It's important to note that some mobile browsers (Symbian browsers, Blackberry <OS 6.0, Netfront, WP7 pre-Mango, etc) don't support media queries, so serving base styles by default reaches more devices and browsers. As Bryan Rieger puts it, "the absence of support for @media queries is in fact the first @media query."

Applying Media Queries

We're continuing our mobile-first style when we apply our media queries. Our related product list starts off two to a row, but increases to 3 in a row when the screen size is at least 28.75em wide (roughly the size of mobile phones in landscape mode) and then to 6 to a row when the screen size is at least 40.5em (roughly tablets in portrait mode or small desktop screens).

/*Default styles*/
.related-products li {
 float: left;
 width: 50%;
}

/*Display 3 per row for medium displays (like mobile phones in landscape or smaller tablets)*/
@media screen and (min-width: 28.75em) {
 .related-products li {
 width: 33.3333333%;
 }
}
/*Display 6 to a row for large displays (like medium tablets and up) */
@media screen and min-width: 40.5em) {
 .related-products li {
 width: 16.6666667%;
 }
}

Assuming small screen by default allows us to support more platforms and also makes it easy add more breakpoints without having to modify existing styles. Defining styles as they're needed also keeps file size down, reduces complexity and keeps code more maintainable.

Using Relative Units

We're using percentages and em units in our design in order to keep things as flexible as possible. Relative units are far more compatible with the tremendous variance brought on by screen size, pixel density and zoom level.

While media queries are responsive web design's secret sauce, we want our fluid grids to do most of the work. Maintaining a whole slew of set-width styles across many media queries can become unwieldy, so we'll make sure the stylesheet's foundation is entirely flexible. Ethan Marcotte provides a formula for converting dimensions and font sizes from pixel-based to relative units:

target ÷ context = result

Using CSS to Reduce Requests

Too many HTTP requests can be a huge killer for performance, especially on mobile. We're incorporating some CSS techniques to save HTTP requests which will improve the site's performance. Using CSS gradients instead of background images reduces the amount of image requests and gives us more control over the design. We're including the appropriate vendor prefixes to ensure maximum compatibility (there are tools for this) and hoping that one day that these rules will become standardized to save us some time.

/*Using CSS gradients instead of background images*/
header[role="banner"] {
 position: relative;
 background: #111; 
 background: +linear-gradient (top, #111 0%, #222 100%);
}

We're also using data URIs instead of background images for some of the smaller icons (for icons like search, social features and location). While data URIs might look a bit ugly and can increase up the stylesheet file size, the reduction of requests results in a faster perceived download time.

Views: 81 | Added by: sockscap64 | Tags: Mobile | Rating: 4.0/1
Total comments: 0