5 simple rules for creating mobile-savvy websites

It’s appalling when you go to a website on your iPad, iPhone, Xoom, Atrix, Droid, Torch, other favorite mobile device and you get a hard-to-navigate desktop site. It’s even worse when you’re redirected to a stripped-down, oversimplified site that eliminates most of the value of the original destination. Both situations happen way too often.

But they don’t need to. The first situation occurs because the website hasn’t used the simple technologies available for Web templates to autoadapt the presentation for the smaller screens of mobile devices. The second scenario transpires when the site has implemented one of the many “mobilize” services that essentially scrape Web pages or take RSS feeds from a site, then create a WAP-compatible version for nearly any mobile device to use.

The problem with that WAP approach is that it is lowest-common denominator, stripping basics such as links in many cases, to support yesteryear’s phones that weren’t designed to access the Web. These devices — most Nokia handsets, BlackBerrys that shipped before the Bold, and all cell phones that included proprietary carrier information services — account for less than 0.5 percent of mobile Web usage, so optimizing for them at the expense of iOS, Android, BlackBerry OS 5 and later, Windows Mobile, Windows Phone, WebOS, and the high-end Nokia devices’ version of Symbian is simply silly.

Don’t be silly. Instead, be effective in addressing the growing army of mobile users by applying these five rules to your website.

1. Detect the device accessing the website
You likely already detect the browser to handle Internet Explorer’s many oddities, using either on-page JavaScript or a server-level Apache script. Harness that user agent information to detect the mobile devices you care about. Zytrax has a great, frequently updated, and comprehensive list of user agents.

Tip: The Motorola Mobility Xoom tablet identifies itself as simply an Android device, so if you’re not careful, you’ll end up treating it like a smartphone in terms of what you display. That would be cruel to Xoom users. The work-around is to also detect the browser window size and use that information to distinguish an Android tablet from an Android smartphone. However, you don’t have to do this for the iPad, as it has a distinct user agent from other iOS devices.

2. Componentize your Web pages
Once you’ve detected the mobile device accessing your Web pages, you want those pages to present themselves appropriately. To do that, you need to first architect your pages as components, using DIVs. You simply can’t show all of a Web page designed for 1,024-by-768 screen size on a mobile device designed to run at 320 by 480 pixels — at least not in a usable way.

Therefore, you need to put elements into named DIVs so that you can later manipulate which ones display on which devices and how they show up. This is the heart of creating an autoadjusting website.

Tip: Avoid using absolute page widths, table widths, and the like. Instead, use percentages where possible, so you don’t create an element larger than the mobile devices can display at 1:1 ratio. (They’ll scale down these larger elements, shrinking your page along with them.) The exception is for embedded objects such as images. You want these to scale down, which most mobile browsers will do — if you set an absolute width or height for them.

3. Work through your layout scenarios and program them via AJAX and CSS
Here’s where design skills come in: You need to figure out how you want your pages to look in the common browser windows. There are really just three sizes to worry about:

• 320- or 480-pixel width for smartphones — the measurement depends on whether you want to optimize for vertical or horizontal viewing; I recommend the vertical-optimized width of 320 for these devices
• 768 or 1,024 pixels for tablets — I’d optimize for the horizontal width of 1,024
• Whatever width you prefer for desktop browsers — that may be 1,024 pixels as well if you’re designing your site to work with 17-inch monitors that used to be very common

Don’t worry about the small variations among smartphone and tablet screen sizes. These three size classes will work across the board. If you want to optimize for widescreen tablets, such as the Motorola Mobility Xoom, then add 1,280 to the mix of sizes.

Now decide what you want to display in each of the three (or four) layout scenarios. In some cases, you’ll simply decide not to show certain components on a page, to keep the site from getting too complex for a smartphone. Instead, some of those removed components could be made available as links to new pages, or you may decide they won’t be visible to mobile users. In other instances, you’ll move components, such as by vertically stacking them in one column for a smartphone but retaining the more traditional, horizontally oriented columns approach for tablets and desktops.

Next, create a CSS for each scenario, hiding DIVs you decide not to display, substituting alternative versions where needed, and applying the appropriate layout parameters for the device class in question. Use JavaScript to detect the mobile device, then load the appropriate CSS for that device. Alternatively, use Apache scripts to detect the mobile device and redirect to the appropriate page.

This approach means you have separate pages for each class of device to manage, serve, and report on, but you avoid the JavaScript overhead and the complexity of the all-in-one page design. You might also have JavaScripts and/or PHP code that do layout modifications that CSSes don’t handle.

Your Web pages of course should be based on templates that have these DIVs and the accompanying CSS and JavaScript links, so you’re not hand-coding each page for the various options. Sure, custom pages will need custom coding, but most pages should be based on templates — especially if you use a content management system to generate your pages.

Tip: Once you’ve done the CSS work for each class of device, you may want to expand the font-family list to accommodate the fonts available on popular devices. For example, your CSS might add Lucida Grande and Palatino to the font-family list to take advantage of those iOS system fonts (you might do the same for your Mac desktop users as well). Likewise, you may add BBAlpha Sans and BBAlpha Serif for BlackBerrys to use their native system fonts. The beauty of the CSS font-family list is that the browsers will ignore fonts they don’t have, so you can list all the possible fonts in the one CSS.

Tip: For those pages you can’t make mobile-savvy but need to leave accessible from your Web pages, you have a couple of options. Either make them unavailable, with a intermediate notice page explaining they are not mobile compatible, or send users to the desktop page instead, perhaps with an interstitial notice page so that they know the move is not an error.

4. Eliminate proprietary technologies where possible
A well-designed website should already stick to HTML4, the core HTML5 capabilties widely deployed, JavaScript, and CSS, so it works on the variety of desktop browsers in popular use. But in reality, many websites were originally designed in the days when Internet Explorer was the de facto standard, so they use ActiveX controls and other items that work only in IE. You should ditch these legacy dependencies; they are simply not supported in mobile devices, nor do they work in desktop Firefox, Safari, or Chrome.

Chances are that you site also uses Adobe Flash videos. Although all popular desktop browser support the plug-in for this format, only Android OS 2.2 currently supports it for mobile. Thus, most smartphones and tablets can’t render Flash videos (it’s not just an iOS issue).

It’s not sensible to stop displaying existing Flash videos to your desktop and Android 2.2 users, but you shouldn’t add any more Flash videos to your website. You should also use your JavaScript and CSS to determine to remove Flash videos from mobile devices’ Web pages — it’s cruel to tease readers with videos they can’t play. Over time, you should switch your videos to a format such as H.264 for which most HTML5-capable browsers (that is, the popular desktop and mobile ones today) will have codecs.

5. Give users a way to access the full desktop version
Many users don’t like sites to reconfigure themselves automatically to better fit the mobile experience; they want the full desktop version regardless of the device’s capabilities. Fine — give them an option to switch to the desktop site. If you want to be really sophisticated, save a cookie indicating their preference, so they automatically get what they chose the next time they come to your site. (You can implement the cookies via server-level Apache or on-page JavaScript or PHP, as you prefer.) Just be sure to let them change their mind later through a consistent Mobile Settings link on your pages.

Embrace mobile by embracing standards
Sure, you could pay a service to parse and scrape your existing website or suck in its RSS feeds, and then generate a mobile version. But this approach both costs you ongoing money and results in a canned experience that’s rarely satisfying. It simply makes more sense to use the standard Web technologies to (re)design your website to be mobile-savvy. If you do it at the template level, you can quickly make your site — or at least huge swaths of it — mobile-friendly.

As more and more folks adopt tablets and smartphones, websites need to anticipate their usage.