fromAugust 2011
Mobile Drupal
Feature:

Finding Our Path In The Mobile Wild

John Albin Wilkins
0

In web time (like dog years), I am ancient, having been developing for the web since 1993. I remember being blown away by the revolutionary capabilities of nested tables and spacer images. I’m not kidding! Before that, we had no layout techniques at all; the best we could achieve was slapping align="left" on an image and letting the text flow around it. (Okay, seriously. Stop giggling.) And the success of tables led to the biggest challenge I had ever faced as a web developer: throwing away all the tried and true layout techniques I’d learned and starting over with unproven, experimental, but-obviously-better layout methods using CSS. In 2001, it was hard and, while there was a big community of web developers sharing and figuring stuff out, none of us really knew what we were doing.

It’s ten years later and we are at a similar pivotal point in web development. Some of the key tenets of what we’ve learned about designing for desktop browsers are being overthrown by the explosive growth of mobile web devices and a layout technique simply called “Responsive Design.” While, on its surface, this is just a new layout method, it has far deeper implications. With unproven solutions before us, it is time to re-evaluate our understanding of our canvas, our users and our content.

In hindsight, our mistake is easy to spot; we had grown accustomed to the ever-increasing screen sizes from yesterday’s 800-by-600 CRTs to today’s 2560-by-1440 LCDs. And our website layouts have grown with them. While it was natural for us to follow this course, we were terribly, terribly wrong.

Mobile phones with Internet access have been steadily increasing in popularity. And few us seemed to notice that meant our average screen real estate was actually shrinking, not growing. Morgan Stanley now predicts that mobile web usage will surpass desktop usage by 20151. We need to change the way we build websites. And fast.

A quick journey down a proven path: Mobile-only Experiences

When the iPhone was first unveiled in 2007, some developers were ready for its vastly improved mobile experience. Pioneers in mobile development had been working with the mobile web since 1996’s Nokia 9000, the first phone to have true Internet capabilities. But those early phones had severe limitations in bandwidth and processing power and required using technologies apart from HTML, the lingua franca for web developers. With the iPhone, any existing site worked, but it usually required a fair amount of pinching and zooming. As the results were so tantalizingly close, many developers started getting excited about customizing for it and, following the examples of developing for previous mobile devices, built two different kinds of solutions:

  • Native Apps (phone-specific applications) and
  • Separate, mobile-specific websites

But trying to build a parallel mobile experience that mirrors the content of the normal website is hard. Not just hard, really hard. Building a second mobile-only solution that was parallel to a desktop-oriented website wasn’t just twice the work, it was ten times more work. While the results of that work could be outstanding—for example, see Palantir’s work on building the Drupalcon Chicago mobile apps2—the amount of work required has been daunting to most web developers.

When building a mobile-only website, the steps appear deceptively simple. Brian Fling’s book, Mobile Design and Development (available free online3), succinctly outlines the process:

  • Detect: Quickly figure out which device is being used to access the content and what its device capabilities are.
  • Redirect: Send mobile devices to a mobile-only website and send desktop browsers to the standard website.
  • Adapt: Based on the device capabilities detected, build markup that best matches. Note that targeting specific devices is a fool’s errand, given the proliferation of different devices, which is why we focus on building for common device capabilities instead.
  • Deliver: Send the data to the mobile device in the most performant manner possible. While front-end performance is important in any context, it’s especially important for mobile networks.

When you start to break down what all that entails, you get a sense of how incredibly difficult these steps can be. Fortunately, if you do choose to follow this route, Drupal has several tools to help build mobile-only sites.

The WURFL module4 integrates the WURFL project5 (an open-source initiative to provide a comprehensive directory of mobile device capabilities) and its database-driven PHP API implementation6. With this tool, your site can quickly distinguish between mobile and desktop users and can detect (and later respond to) the features of mobile devices.

  • The Mobile Tools suite7 offers several features to help with this stack. It can redirect users to a mobile-specific domain based on the information provided by WURFL, provide a “Switch to mobile/desktop” block, and alter the generated markup of your page by way of CTools/Panels, Context, Display Suite, and Views module integration.
  • Domain Access8 is a stalwart domain-related module that greatly expands the capabilities of mobile/desktop domain name split. If your mobile site is a separate domain, all of Domain Access’ features can be applied to your mobile site, including mobile-specific editorial control over content, mobile-specific navigation menus, theme switching and—Domain Access’ most powerful feature—mobile-specific Drupal configuration. (Think domain-specific settings for footer message, number of nodes on homepage, default home page, etc.)

While the mobile-only approach definitely provides the most tightly integrated and performant solution for a mobile device, its higher costs must be carefully considered when starting any web project.

Enter Responsive Design

Then in May of 2010, Ethan Marcotte wrote an article on A List Apart entitled “Responsive Web Design”9. The technique he laid out showed that you could build a website using only CSS that adapted to changes in screen sizes by altering its layout and tweaking design elements.


Figure 1 shows the Hicksdesign website (hicksdesign.co.uk) as it appears at four different screen sizes.

Ethan’s basic idea of a single source responding to different screen sizes wasn’t original. The “One Web” ideal was detailed in the W3C’s best practices for mobile web development10 published in 2005. And this ideal is also the basis behind the simple fluid layout methods, as well as the doomed-to-failure-because-of-its-name “Switchy McLayout” from a 2006 A List Apart article. But what distinguished Ethan’s responsive design technique from previous efforts was its ability to actually deliver on the promise of One Web, with its reliance on CSS and its practical advice on handling images in varying-sized viewports.

Ethan released a book entitled Responsive Web Design11 this past June that expands on his original article and defines responsive design as requiring these three features:

  • Flexible grid: A grid that expands or shrinks in proportion to the viewport.
  • Flexible images: Using some simple CSS, let the browser resize the images to match the flexible grid.
  • Media queries: CSS3 media queries can be used to target CSS at specific screen sizes or device capabilities.

Using those 3 ideas, a website can alter its layout and design to respond to the screen size of the device requesting the page. When an iPhone user requests a page, the CSS3 media queries ensure that targeted CSS presents a mobile-friendly design to the user:

  • Instead of 2 or 3 columns of content on a desktop screen, the content layout can reflow into a single column.
  • Images can be rescaled to fit in the smaller context.
  • Other graphic elements (background images, margins, etc.) can all be altered to better suit the constraints of the iPhone.

Flexible grids and flexible images

Flexible grids are pretty straightforward. Instead of defining our grid using fixed pixel measurements we use percentages. To convert a 615px wide column in a 995px wide grid, you would just calculate 615 ÷ 995 = 61.8%. With all our measurements in percentages, our grid naturally expands and collapses proportionally to the viewport.

And it is shockingly easy to get our images to contain themselves within our flexible grid. Simply add:

img, embed, iframe, object, video {
  max-width: 100%;
}

Here we deal with several different kinds of media in the same way (including embedded media players using iframes.)

Naturally old versions of IE have some issues. Shocking, isn’t it? Fortunately there are work-arounds described in an excerpt from Ethan’s book online12.

The Magic of Media Queries

CSS has always had a media type. This was a basic way for CSS to respond to different classes of devices. We’re all familiar with the media types print, handheld, screen, all, and even aural. But designers and the W3C realized that these device classes were too rigid and broad to fix a lot of the issues designers faced. How does one deal with tablets which roughly fit halfway between handheld and screen? To make matters worse, most designers ignored the handheld design entirely which meant that for mobile device makers to render web pages even halfway decently, they had to steal the screen styles and use them. So, CSS3 decided to extend the media types into media queries. Instead of defining device classes, designers could target styles to specific device features. For example the following media query would apply the enclosed styles to just viewports that were between 481px and 900px wide:

@media "all and (min-width: 481px and max-width: 900px)"

When we put all three of these ingredients together, we can now have one source of markup with many possible layouts.

But then the yelling began. Responsive design wasn’t without its controversies. Once people wrapped their head around how the technique worked, some people called “Foul!” on two grounds: performance problems and a missing “mobile context”.

What Mobile Context?

Many mobile-only sites are built on the assumption that mobile users are on-the-go users. When they visit a restaurant website, they want the location, the phone number and maybe the menu. Seeing a photo slideshow of the cuisine just gets in their way. So mobile-only sites build web pages specifically for this mobile context. And, since responsive designs deliver the same page to mobile and desktop, they must be ignoring the mobile context.

However, Jeremy Keith puts the lie to our assumptions about mobile context on his blog13. People are using their mobile devices while leisurely sitting at cafes or while watching TV. And laptop users on trains are using the web via 3G dongles. Which of those is the “mobile” user? We can no longer make assumptions about mobile or desktop users; the device doesn’t dictate the goals.

The performance problem

Performance is important for all web users, but it is especially true for mobile devices which have to deal with bandwidth caps, latency and less-capable CPUs. Responsive design seemed to suffer from two issues:

  1. Browsers will download all your stylesheets before evaluating the media queries which meant mobile devices were downloading all the styles and images targeted at mobile and those for desktops.
  2. Flexible images meant that browsers would download a larger-than-needed file and let the CPU scale it to a smaller size; a double performance-whammy.

Responsive design seemed counter to the established mobile-specific development model. The detractors said that throwing more code at mobile devices was the exact opposite of what you should be doing.

The detractors are not wrong, although responsive design is not inherently bloated. It is quite easy to have very light-weight media query differences. Our real problem with performance is how we’ve been treating our poor desktop users. Merlin Mann has created a photo gallery called Noise to Noise Ratio14 containing screenshots of websites with so many extra features its hard to find the content.

We need to rethink how we build websites. Fortunately, the ideas of Luke Wroblewski’s “Mobile First,”15 also called “Content First,” show us how it can be done:

Losing 80% of your screen space forces you to focus. You need to make sure that what stays on the screen is the most important set of features for your customers and your business.

If we re-focus our site building to provide the essential content, we are directly countering the performance problems inherent with the everything-and-the-kitchen-sink approach.

And there are more techniques we can use. CSS3 has numerous features that can replace kilobyte-heavy images. JavaScript tools like Nathan Smith’s Adapt.js16 and the Filament Group’s responsive images script17 can progressively enhance and load images or CSS for select screen sizes. HTML5 features in newer devices and browsers can simplify markup and form features. And we need to stop ignoring the fantastic front-end performance tips of the likes of Nicole Sullivan and Steve Souders; the Yahoo! Developer Network has a nice list18 to get you started.

Where do we go now?

It’s clear that responsive design alone isn’t the solution. But the technique has kicked off a huge re-evaluation of websites and is leading us towards a revolution in site building. Front-end developers and designers need to listen, to join in the conversation and to try building their own solutions. We’ll get a lot of things wrong, but even our failures will help us define best practices in this new environment.

Drupal is uniquely situated to deliver solutions that will help improve the performance and ease of building responsive designs. I’m already starting to see new modules and themes that leverage our existing toolset; be sure to follow me (@JohnAlbin) on Twitter and read my blog posts on Palantir.net as I explore the possibilities. It’s an exciting time to be in the Drupal community.

Passionate mobile web developers:

The web community is full of passionate people talking about mobile. Here are just a few of the voices I listen to. You can find a fuller list at http://twitter.com/JohnAlbin/mobile-dev/members

References

“Mary Meeker: Mobile Internet Will Soon Overtake Fixed Internet” http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overt...

Other articles from this issue:

Columns

How to Create New Features in Views 3

Earl Miles
How to Create New Features in Views 3
0
Coming Soon

Features

Writing Drupal 7 Modules

Matt Butcher
Get a jump-start on writing Drupal 7 modules in PHP. Use this tutorial to create a fully functional module leveraging common APIs in Drupal's framework.
0
Coming Soon

Articles

Workbench: Content Management with a Short Learning Curve

Robin Barre
Workbench is a suite of Drupal modules which helps content administrators do their jobs. The goal of this article is to introduce people to using Workbench to manage content and to ease training and support for a Drupal site.
0
Coming Soon
See all articles from this issue