How to make your website mobile today

It's 2010 and your users are on smartphones and iPads. Here's how to make sure your website is too

You've long held off, but it's now time -- even past time: You need to make your website mobile. Between what you see in the news and what your site logs reveal, it's clear that the number of people surfing the Web from their mobile devices is growing by the day.

Here are a few tips to help your site (and you) get up to speed in this new mobile world.

[ InfoWorld's Dori Smith shows you how to use HTML5 on your website today. | Keep up on key mobile developments and insights with the Mobilize newsletter. ]

Addressing the device proliferation challenge

If you start off by panicking about all the cell phones you (and your family and your friends and your coworkers) have had over the years, and then ask yourself how you're going to support all those mobile OSes and models, rest easy.

The truth is that while mobile browsing is growing by the minute, virtually all that growth is from just a few devices -- mainly those running Apple's iOS (iPhone, iPod Touch, and iPad) and Google's Android (used by HTC, Motorola, Samsung, and others in a bunch of models).

Here's the proof: Quantcast's August data showed iPhone and iPod Touch together claim 56%, Android devices 23%, and RIM BlackBerrys 10%. AdMob, which focuses on sites with ads, found similar results in its May survey PDF: iPhones accounted for 54% of usage (it doesn't track iPod Touches or iPads), Android devices for 33%, and BlackBerrys for just 7%.

The good news: The popular Apple and Android devices' browsers run on WebKit, the open source rendering engine, as do the less-popular WebOS-based Palm Pre and Pixi and the new RIM BlackBerry Torch.

The bad news: These devices come in all sorts of screen dimensions, as the table below shows. (If the table, screen images, and code snippets in this article do not appear correctly, see the original article at InfoWorld.com.)

Platform

Device

Screen dimensions

Android

HTC Tattoo, HTC Wildfire

240 × 320

HTC Aria, HTC Hero, HTC Legend

320 × 480

Google Nexus One, HTC Desire, HTC Evo, HTC Droid Incredible, Samsung Galaxy S

480 × 800

Motorola Droid, Motorola Droid X, Motorola Droid 2

480 × 854

BlackBerry OS 6

BlackBerry Torch 9800

360 × 480

iOS

Apple iPhone 3G/3G S, iPod Touch

320 × 480

Apple iPhone 4

640 × 960

Apple iPad

768 × 1,024

WebOS

Palm Pixi

320 × 400

Palm Pre

320 × 480

The really bad news: Although all of these browsers run on WebKit, all of them run WebKit just a little differently. Peter-Paul Koch of QuirksMode ran 19 WebKit-based browsers through 27 tests and described the results as "thinly veiled chaos."

So let's try to bring some order to that chaos, first by being a little picky, and then by using a touch of HTML, CSS, and JavaScript to handle the remaining issues.

Yes, there are a lot of devices, but you don't have to support them all. Do so by eliminating the outliers:

* Sorry, RIM. Sorry, Microsoft. You had your day in the mobile market (well, RIM did; Microsoft never did quite figure out a solution to Windows + mobile device + usable), but it's over. There may still be plenty of these devices, but research has shown that they aren't used to surf PDF.

* Sorry, small screens. Unfortunately, a 240-by-320 surface is just too small for a good browsing experience. The Pixi's 320-by-400 screen is almost twice as large, yet barely made the cut.

* Sorry, third parties. Every device you should care about ships with its own Web browser. If you have an Android, you have a choice of browsers, including Opera Mini and Mobile Firefox. But you have to draw the line somewhere, and unless you have a fully funded lab, it's unlikely you'll be able to test your site on every permutation of browser and screen size. So stick with the browser that the device maker included.

Anything else you're thinking about dropping? This is where your server logs come in handy. Keep in mind, though, that while you may have few mobile visitors now, it might be solely because they don't (yet!) find your site welcoming.

The nitty-gritty of making your site over

Let's say you have a fairly normal website: It has content, a menu bar, a header, and footer (see Figure 1). You know it's built to standards, so you assume it's going to work just fine without any changes. And then you look at it on an iPhone 3G S (see Figure 2) or a Nexus One (see Figure 3). And you remember you thought that navigation bar was so snazzy when you got it working, but now realize mobile devices don't support hover effects. And you start trying to figure out which would be easier: redesigning the entire site or creating a duplicate mobile version?

Thankfully, those aren't the only two options. I'll take this site (you can see the live version on your mobile or desktop browser) and show you how to add a little more markup, style, and code. Then we'll be done -- no redesign or duplication needed.

The viewport. You start off with the viewport --a concept invented by the W3C, but one that garnered little attention until the iPhone came along. In the chart on the first page in this article, you'll notice that before the iPad and iPhone 4, Apple's devices were all 320 pixels wide. However, on those devices, Mobile Safari thought that it had a width of 960 pixels. That meant that internally, your site was compressed to a third the width, and then put out on the screen. Want to change that equation? That's the viewport.

That line goes into the head section of your HTML and tells mobile browsers that you may think your width is 960, but I think you should be satisfied with 320 pixels across -- or whatever the device-width happens to be.

At least that's the way Apple described how it should work; in practice, I've had better luck giving the viewport a fixed width:

This is one of those gray areas where there's no one right answer that fits all sites on all devices; you need to play with it to find what width works best for your site.

Media queries. Next up is a little bit of custom CSS geared toward the mobile crowd.

The first part of the link tag looks like a straightforward style sheet, up until the end. The media attribute is how you can identify not just mobile browsers in general, but which mobile browsers in particular. The only screen keywords are the voodoo that tells mobile browsers that this is just for them. After that, you can get picky about which browsers, but here you're looking for all mobile devices that have a maximum device width of 1,024 pixels -- that is, everything up to and including an iPad. Because of this line, every mobile device will load mobile.css.

Now, you can get a little more particular:

This starts off similar to the earlier broad media query, but then looks at the minimum pixel ratio of the device. If it isn't 2 or higher, you aren't interested. Right now, the only browser fitting that description is the iPhone 4 with its Retina display. This line lets you tweak details a little for Apple's latest toy, which gets to use mobile2.css.

For the next line, it helps to remember that these devices can be in horizontal or vertical orientation when your page loads. You can't just say you want all devices that are at least 480 pixels across; if the device is in landscape orientation, you may get a false positive.

This line brings in the same style sheet, but for different device: one with both a minimum height and minimum width of at least 768 pixels. That's the iPad, and it's going to get the same special style sheet as the iPhone 4.

Style your site. To understand what's going on in mobile.css, you first have to know a little about how the site is put together. See those big gray bars on the right and left of the page in Figure 1? The middle section, #container, is only 80% of the page. And while it looks nice on a big display to have all that room on the sides, it's a waste of space on a mobile device. So start off by making the content fill the entire width:

#container { width: 100%; }

Something you may have noticed while looking at Figure 2 or Figure 3 (or looking at sites with one of your own devices): Bold fonts aren't attractive. They take up too much room and don't display well. Let's stop that for the site's normally bold navigation:

#navbar { font-weight: normal; }

Next up, it's time to tweak your fonts. Each device comes with certain fonts, and I wasn't able to find any one font on all devices (but then, you can't even necessarily find out what Web fonts ship with a given device -- I'm looking at you, Android). But here's what's worked for me:

h1, h2, h3, h4, h5, h6 {

font-family: Albany, Georgia, "Times New Roman", "Droid Serif", serif;

}

Albany is a serif font found on the Palm devices, Droid Serif on all Android devices, and Georgia and Times New Roman are on the iPhone and iPad. If you're supporting BlackBerry as well, add "BB Alpha Serif".

If you prefer sans serif fonts, try:

h1, h2, h3, h4, h5, h6 {

font-family: Prelude, Verdana, Arial, "Droid Sans", sans-serif;

}

Prelude is a sans serif font found on the Palm devices, Droid Sans on all Android devices, and Verdana and Arial are on the iPhone and iPad. If you're supporting BlackBerry as well, add "BB Alpha Sans".

If you've used one of the higher-end mobile browsers and swapped orientation, you may have found it, well, a little disorienting. You're looking at a page where the fonts are a certain size, but then you go from portrait to landscape and the font size suddenly makes you feel like you're in a funhouse. So let's add a little styling to handle that:

.landscape { font-size: .5em; }

.portrait { font-size: .8em; }

I'll show you the JavaScript later that provides the functionality behind this, but suffice it to say for now that when the page has its class attribute set to landscape, your fonts are at half-size; when it's in portrait orientation, the fonts are at 80%.

The lucky iPhone 4 and iPad have some special styles of their own:

.portrait #header img { width: 50em; }

.landscape #header img { width: 75em; }

Looking back at Figure 1, you see that the header graphic is larger than will fit properly in most mobile browsers. The others will cut it off, and that's fine. But some browsers can handle oversized images, so tell them to compress it a tad instead.

A little bit of script. My sample page is already using an external JavaScript file to handle its navigation menu, so only a little more code is necessary:

addEventListener(

'load', function() { resetPage(); androidSS(); }, false

);

addEventListener(

'orientationchange', function() { resetPage(); }, false

);

These lines set up two event handlers: one to trigger when the page loads, and the other to trigger on orientationchange -- which is just what it sounds like. Both of them call the resetPage function:

function resetPage() {

var classVal =

(Math.abs(window.orientation)==90) ? "landscape" : "portrait";

document.getElementById("container").setAttribute("class", classVal);

setTimeout(scrollTo, 0, 0, 1);

}

This function only has three lines, but it accomplishes a lot. The first line checks the window orientation; if it's +90 or --90, it sets classVal to landscape; otherwise, classVal is set to portrait. The second line tells container that it has a new class attribute, classVal. The two together are what let you know if the device is horizontal or vertical. The last line does a little bit of useful trickery: If you look back at Figures 2 and 3, much of the screen real estate is taken up by the address bar. Here, this last line tells the browser to window to scroll a tiny amount, which is enough to move the address bar out of the way.

That darn Droid. Did you notice the one bit of code I skipped in the onload handler? It was the call to the function androidSS:

function androidSS() {

if (navigator.userAgent.match(/Android/i)) {

var fileref = document.createElement("link");

fileref.setAttribute("rel","stylesheet");

fileref.setAttribute("type","text/css");

fileref.setAttribute("href","mobile3.css");

document.getElementsByTagName("head")[0].appendChild(fileref);

}

}

It looks to see if the browser is an Android device by checking if its userAgent contains the string Android. If it does, this function appends another style sheet, mobile3.css. There's no way to reliably use media queries to target all (and only) Android devices; instead, you should use JavaScript.

The result: Appropriate -- not identical -- displays across devices

While testing devices, I found a number of websites that documented how the Android should handle various situations. I tested sites with the Android emulator in addition to, of course, using an actual Android smartphone. I found that only on rare occasions did the docs match either of the displays, and that was still considerably more common than the emulator matching the phone's output. To get somewhat dependable results, I ended up duplicating several of the styles from mobile.css. Here's what's different:

h1, h2, h3, h4, h5, h6 {

font-family: "Droid Serif", Georgia, "Times New Roman", serif;

}

.landscape { font-size: 16px; }

.portrait { font-size: 24px; }

The heading tags are set to fonts supported by the Android, as there's no need for iOS, WebOS, or BlackBerry support here. I also set the fonts for landscape and portrait to fixed pixel sizes to improve the chances of getting the desired results.

Don't get me wrong: The Palm and Apple devices had their share of fun quirks as well. Happily, there are free emulators for them, which you can get from the Palm Developer Center and Apple's iPhone Developer Program, respectively.

The end result is shown in Figures 4 through 8. No, they aren't identical; with screen sizes that vary as much as these devices do, they shouldn't be. But they're all clear and readable, and that's what matters when you're on the move.

With some simple Web technologies, it's not difficult to make your site feel friendly to even the smallest among us. Hopefully, you've seen that you can get a start without a whole lot of effort.

After you've become comfortable with these techniques, you can take the next step and work with the user agent detection method I described for Android. From there, you can detect other devices and load specific style sheets for each to invoke more layout-oriented CSS functions. For example, you may end up showing and hiding divs, placing divs in different locations, or actually changing the layout of a Web page based on the mobile device accessing it -- but that's for another day.

This article, "How to make your website mobile today," originally appeared at InfoWorld.com. Follow the latest developments in mobile technology and programming at InfoWorld.com.

Read more about software development in InfoWorld's Developer World Channel.

Dori Smith is the co-author (with Tom Negrino) of "JavaScript & AJAX for the Web: Visual QuickStart Guide," 7th ed., and "Styling Web Pages with CSS: Visual QuickProject Guide."

This story, "How to make your website mobile today" was originally published by InfoWorld.

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies