Lessons in Mobile Website Development: Responsive Web Design Is Key

Related: "Responsive Web Design: A Step-By-Step Guide"

Too many websites are neither optimized nor adapted to render well on mobile devices. Furthermore, too many developers think all they need to make a website "mobile" is to use the right style sheet or a responsive template, perhaps based on Twitter's Bootstrap. As harsh as it might sound, I believe taking this type of simplistic approach in mobile website development is a huge mistake. Users expect to be using their favorite mobile device—whether tablet, mini-tablet, or smartphone—to do most of the things they would do comfortably while sitting at a computer. Thus, it is crucial that your website offer a device-specific experience if you want to keep your existing customers and attract new ones to your business's website. To help you give customers the device-specific experience they're looking for on your site, I offer here a few tips I've gained from my own mobile development projects—including mistakes I've made and feedback I've received from users on websites I developed.

Welcome to the Era of Devices

Although it might seem paradoxical to say so, the mobile era is over: This is the era of devices. Everything that can run software is a device. This includes PCs, tablets, mini-tablets, smartphones, cell phones, smart TVs, tiny devices such as Google Glass, and whatever else the industry will create in the future. You should plan for your website to support some of these devices effectively right now while ensuring that your solution can be easily modified to support other devices that come along.

"Effective support" for devices can mean anything from simply preventing load errors and patent misbehaviors to providing the best possible experience for any given device. But beyond enabling your website to support devices, I advise you to reject altogether the dichotomy between desktop and everything else and stop calling everything that is not desktop "mobile."

Responsive Web Design Is the First Step

I imagine that, at this point, many readers are enthusiastically responding that, yes, this is exactly what they want: "I just want a solution that can be easily scaled to support any device. This is what I call smart software."

How do you go about building "smart software"? Your first step is to investigate responsive web design (RWD). RWD is a design methodology for web pages that incorporates technologies such as Cascading Style Sheets (CSS) media queries, proportional layout, and flexible images. Applying RWD means creating HTML pages where each container (i.e., div element) is given a relative size expressed proportionally to the width (and much less frequently to the height) of the host browser window. When the page is displayed on a small-sized host screen, the content in any given container might not fit the available space. Proportional layout and grid-based rendering automatically reposition oversized content, making it flow vertically toward the bottom or scroll horizontally. In the context of RWD, grid-based rendering consists of filling up containers with a fixed number of child block containers that display horizontally but wrap to the next row if there isn't enough space to contain them horizontally.

This methodology ensures that users will always view the page in a way that fits the size of the browser window. Because the only parameter taken into account is the current width of the host browser window, an RWD approach is equally effective with resized desktop windows and full-screen mobile browser views, whether tablet or smartphone. When the screen width is, say, 800px, you get the same output whether you're viewing the website on a tablet or in a resized browser window.

Two additional aspects help to make RWD even more powerful: CSS media queries and flexible images. CSS media queries refers to use of the media attribute of the link element to indicate under which dynamic conditions the given CSS file has to be loaded. In this way, you decorate each page with multiple CSS files, so that only one is selected at a given width. In doing so, you define breakpoints at fixed screen widths. For example, the following markup will apply smartphone.css if the screen size is less than 480px and apply default.css otherwise.

Note that browsers switch CSS automatically. You can find more information about media queries, including the complete syntax you can use in a media query, in the W3C Media Queries document.

Although browsers can reflow text automatically to ensure that it fits the current container, scaling down images is entirely up to you. To help browsers reduce the size of visible images in a way that is scaled to the actual size of the window, you can use some of the tricks outlined in Dudley Storey's blog post. Note, though, that all these tricks apply to client-side rendering. None of them is actually saving a single bit of bandwidth. In other words, the downloaded image is always as large as it is on the server; it's only displayed in an ad hoc smaller area. For a JavaScript-based solution that downloads a smaller image to be used on smaller screens, have a look at this Filament Group blog post.

Aim to Offer a Responsive Experience

RWD is a smart solution, delivering multi-device views without extra costs for the developer. But it is only the first step on the way to building an effective mobile site. RWD works well enough in many cases, but it is far from being the perfect solution for responsive website development. I used RWD successfully in a number of situations, but in other situations I opted not to use RWD. So when is RWD actually effective?

RWD does its job pretty well for relatively simple websites essentially made of read-only pages. RWD is, for example, great for a portal. RWD might be acceptable for pages that require some light forms of input and data collection—but check out site performance carefully with customers.

What if you have pages that contain workflows or just large input forms? Think, for example, of a reservations site. On a PC you can reasonably count on having 1200px of horizontal space on screen; on a smartphone you have less than half of that amount—not to mention less visible vertical space. How can you fit, say, the available seats (or courts or rooms) in the same context where your website also has to accommodate and display other data, such the date, the city, or other customer preferences? Most likely, you will need to rethink workflows and break up complex forms into smaller pieces.

You can't provide this solution using plain CSS. For this type of website, the server has to detect whether the device is a smartphone or a tablet and pick up an appropriate set of pages with ad hoc markup. In addition, smartphones and tablets might sometimes suggest you apply a completely different layout that is more suited to touch and other finger gestures. Furthermore, sometimes mobile devices might even require different use cases that just don't exist on desktops. Finally, tablets need larger fonts and more padding on UI elements than desktop views. In the end, an 800px view is different when it's a resized browser window and when it's a tablet. You can't meet these requirements using RWD only.

More importantly, note that although RWD is promoted as a full-site solution, you can use it discretely. For example, you can use RWD only in a few pages of the website and opt for server-side feature detection for the most crucial pages.

HTML5 and JavaScript

Mobile browsers are different from desktop browsers. The average quality of built-in browsers varies a lot even under the same operating system and hardware and is highly dependent on the device manufacturer. On the other hand, usually mobile browsers are much more consistent than desktop browsers in supporting HTML5 features, especially input types.

When it comes to using HTML5, many developers think that everything on a website that can effectively run on desktop devices can also be displayed on mobile browsers. A full-fledged cross-platform HTML5 application floods the device's memory with tons of JavaScript libraries and code. Very few mobile browsers can easily handle such a burden. More often than not, a solution you build with HTML5 to be cross-platform ends up losing the (very) long tail of devices. You won't probably lose many of the iPhone and Windows Phone devices, but you seriously risk losing a large share of Android devices and other operating systems.

When it comes to using JavaScript for websites, my best advice is to use plain-vanilla JavaScript and avoid resource-intensive features such as timers. Resource-intensive features could drain a device's battery and also slow down website performance.

The Bottom Line

If you are planning to support additional display channels for your website (e.g., desktop, tablets, smartphones), you probably have a business reason for doing so—most likely based on customer feedback. That's precisely the point: You should aim to make the site usable on a broad range of devices. Sometimes all you need to do to achieve this aim is to apply a new responsive template. But even when a plain RWD solution works, I'd encourage you to stop and consider whether you might be missing an opportunity to improve your site and make your customers happier.

The whole purpose of mobile websites is to offer an existing service through some new consumer tools. In doing so, you should consider what a user might really expect from the site when he or she tries to access it using a device. The user is not necessarily interested in having access to the complete set of website features available through a desktop PC. Most likely, offering a partial selection of features—say 30 percent—will satisfy mobile users' needs nicely. And you might even discover a way to add some new features to the mobile site and perhaps create some new use cases.

As I see it, companies have two challenges ahead. The first is to make their sites mobile aware. The second is to use device-specific views of their sites to provide a different and made-to-measure experience for customers and maybe also new functions that might not make much sense on the desktop but are crucial in mobile. I always try to look at the mobile version of an existing website as an opportunity to rethink the site and refresh the design. A mobile website doesn't have to be an awkward clone of the desktop site. Furthermore, I always look at a new web project as a device-driven architecture and endeavor to create a website that provides a responsive experience to users, regardless of what device they use to access and view the site.