blog

Being Mobile Friendly

We recently commenced an effort to make the Gruden website more mobile-friendly. With the overabundance of iPhones in our office, that provided an easy start, and an easy platform to test with.

We’ve always been believers in the separation of presentation and content. We code our HTML to best practices, with a focus on semantic markup and well-structured documents. With this background, we didn’t want to go about creating a completely separate (or crippled) version of the site for mobile users. Mobile Safari on the iPhone makes it obvious that you really can deliver the real web on mobile. So instead, we looked into the little things we could do to incrementally improve the mobile browsing experience.

Everything we’ve done to date has been achieved with CSS. There’s no browser or user-agent sniffing, no redirecting users to an m-dot or dot-mobi version of the site. While such approaches are well-suited to providing mobile versions of an app (GMail comes to mind), they can be misleading when dealing with a website. As far as the end-user is concerned, they’re looking at the same website, and there’s no need for bookmarks or shared links to present something different on different devices.

So there are three main areas we’ve looked at:

• Trimming pages to improve readability
• Increasing hit areas to help touchscreen users
• Improving content flow to fit narrow screens

Targeting the iPhone

<link rel="stylesheet" href="/lib/main.css"
    type="text/css" media="screen,print">
<link rel="stylesheet" href="/lib/mobile.css" type="text/css"
    media="handheld, only screen and (max-device-width: 25cm)">

The iPhone, along with other recent mobile browsers (such as Opera), loads the “screen” stylesheet ordinarily. It ignores “handheld”, though we keep that around for the older mobile browsers that do support the type.

But the iPhone also supports media queries, from the CSS3 spec. This lets you target devices based on the media features they support, including device-width/height, orientation, aspect-ratio, color, resolution. We’re targeting devices with a max-device-width of 25cm, which will include the iPhone, and any netbooks that go the way of supporting the directive.

Trimming Pages

We’re not actually doing anything server-side, and we’re still presenting most of the same content, so total download sizes aren’t going to be reduced dramatically. We already make an effort to keep download sizes pretty slim, however, and we’re not targeting those old mobile phones with web-lite browsers and 2kpbs downloads.

What we’re really interested in is removing noise; because we’re targeting small screens, we don’t want to be filling the screen up with unnecessary content or large images that are little more than decoration.

Home — Safari

Home — iPhone

The Differences

The most obvious difference, as a user, is that we don’t have Flash on the iPhone. So we’ve a couple of images as fallback content instead of the Flash-based carousel of portfolio items.

But we’ve also trimmed some content. We’ve removed the footer altogether — the content is available on our Contact page, and this was a couple of screens worth of content on the iPhone. And we’ve removed the big background image (a series of tubes).

We’ve also pushed content to the edges of the screen rather than leaving whitespace around the content area. In CSS, we’ve changed most elements to use % based widths rather than pixels to better allow the device to fit the content.

Solutions — Safari

Solutions — iPhone

The Differences

These are obvious. We’ve removed the large images, and removed the floated columns layout. The images are effectively decoration anyway, and would fill a screen if we left them in. This leaves the page with just the key content.

Increasing Hit Areas

With touch becoming a common interface, we can no longer rely on the precision of a mouse pointer, or even a stylus. Wherever we can, we’ve increased padding on elements and switched many a elements to display:block, with exaggerated boundaries.

Some of this can be seen in the home page examples above, where the top menu items all have a little more padding in the iPhone version.

Portfolio — Safari

Portfolio — iPhone

The Differences

In the desktop browser version, each Portfolio item has two links — the name, and a “read more”. In the iPhone version, we hide the “read more” and have the name link displayed as a block, so the whole box becomes clickable.

Improving Flow

Regardless of which screens we’re targeting, horizontal scrolling has never been particularly user-friendly. On the desktop, we minimise this by limiting the width of the content area. On the iPhone, we’ve eliminated floated columns in a number of locations. Combined with the change to % based widths, this makes most pages better fit the width of the screen, and to flow vertically as much as possible.

Portfolio Item — Safari

Portfolio Item — iPhone

The Differences

In this example, instead of floating the portfolio images alongside the content, we’ve dropped them to sit below the content instead. Because the HTML is written to flow correctly even without CSS, this was a simple matter of adding width:100% to any columns in the mobile CSS sheet.

The Beginning

This is only the beginning of our venture into making the Gruden site mobile-friendly. It does, however, demonstrate our key principles. Any difference between the desktop and mobile versions of the site needs to consider the user, and their context. We don’t want to remove any important content, but, as always, we need to keep in mind how the user is interacting with the site.

With the increase in popularity of mobile devices (be they phones or netbooks) with full featured web browsers, sites are going to see more and more visitors coming from devices with unique physical constraints. The changes we’ve made are all simple to implement, but provide immediate benefit to these users. And we’re going to keep working on those incremental improvements.