Mobile

Now that smart phones are becoming common, more and more visitors are going to come to your site using their phones, viewing pages on displays with different dimensions than the traditional desktop or laptop monitor, and interacting with your site using touchscreens and on-screen keys and buttons rather than mice and keyboards. Making sure your site works for these users is not difficult if you know the issues involved.

Early Mobile Browsers

Back before mobile browsers were good, many phones came with web browsers with very limited capabilities. There have been a number of sea changes over the years as wireless web access has evolved. Firstly, back in the late 1990s we had a technology called WAP (Wireless Application Protocol), which was used to send specially-constructed webpages to a phone’s browser. Those pages had to be written in a new language separate to HTML called WML (Wireless Markup Language). This meant that all pages had to be coded a second time by the author to make them available to phones, and in a language much more limited than HTML. This, frankly, was rubbish.

Phone technology and mobile browsers made progress and became capable of browsing the “real web”, albeit a web that was stripped of JavaScript and CSS in many cases. It was common for large sites to generate an entirely separate “mobile” version of a site, which would reside on its own subdomain like http://m.example.com and would contain stripped-down content, less images and often no layout to speak of, though at least it was coded in HTML.

A better solution that did not require building a separate version of an existing website was to use CSS media types to send a different stylesheet to mobile browsers that was more appropriate to their limited sizes and rendering capabilities. Whereas the typical desktop browser would use the stylesheet designed for “screen”, mobile browsers would look for a stylesheet designed for “handheld”, if you supplied one like this:

Nowadays, with modern smartphones like the iPhone and those based on the Android operating system, mobile browsers can view the same version of the website that browsers on the desktop see, with CSS, JavaScript and the full layout of the original intact. The way you interact with the page is different, but the content is the same.

Mobile Capabilities

Before you can design for these new smartphones, you should know as much as you can about their capabilities and weaknesses.

In terms of bandwidth, modern phones are extremely capable. Almost all phones support 802.11g WiFi, which means they can download content as fast as a laptop can. Many, like the iPhone, also support fast 3G networks when WiFi isn’t available. What all this means is that these phones can actually download data surprisingly fast, and in many cases, they can download the web page data faster than the processor in the phone is able to display it. The relatively slow processor is the main reason that pages seem to take a while to load.

Smartphones typically have between 2 and 3.5-inch screens. The iPhone has one of these 3.5'' displays which seems about the right mix of size and compactness. The screen is higher resolution than most desktop monitors, at 480-by-320 pixels, allowing it to display 163 pixels-per-inch. The Palm Pre has the same resolution on a 3.1'' screen, meaning it packs the same amount of detail into an even smaller space. This means that text is extremely sharp on the screen.

Neither the iPhone nor the Pre support Flash video or other Flash content. This, in my view, is for the best, because playing Flash content drains the battery on even a powerful laptop. If it were supported on a phone the battery would be unlikely to last even a single day. Apple, also, seem to be actively avoiding Flash, and are instead putting their weight behind HTML 5 and the additional rendering and animation capabilities that it brings with it.

Designing for Mobile Browsers

Because of the sophistication of the browsers in modern phones, you don’t really have to do a lot to modify your content to work well on them. JavaScript and CSS support in Mobile Safari is as good as it is in Safari 4 on the desktop. Obviously, try not to use frames, for all the same reasons that they are troublesome for on the desktop. Beyond that, the main things to watch out for are column width and button size.

Try to keep your columns no wider than 900 pixels. Any more than that and the reader will not be able to make the text bigger without having to continually scroll the text left and right to read it. They could also activate landscape mode to get more horizontal space (by turning the phone sideways) but this is not ideal.

Web page buttons should be big, and spaced reasonably far apart. Mobile browsers allow the user to zoom in close to page elements by double-tapping on them, but if the buttons are still smaller than the average person’s fingertip after they’ve been zoomed in, there’s still a chance that the button beside it will get activated.

Some tricks in the following section can help you customise your page for iPhone users.

iPhone tweaks

Since there are so many iPhones being used around the world, it pays off to give it a little extra attention. Combined with the iPod touch, which runs the same software, there are over 40 million devices running the iPhone OS, as of June 2009. That’s a whole lot of potential visitors.

When your page is loaded in, the iPhone displays it as if the page is 980 pixels wide. If your page is designed to be any narrower (if, for example, it was designed to fit within 800 pixels like this site was), this will result in it loading in a little smaller than it needs to be. To tell the iPhone that your page is a certain size, add this one line of code to the head of your HTML page:

<meta name="viewport" content="width=780">

In this case, my layout is 770 pixels wide, so I tell Mobile Safari to zoom in on the layout to show 780 pixels. This uses up all the available space on the screen with a tiny gap on the edges, as seen below:

This is readable as it is, and the user can double-tap on either the main content area on the left or on the navigation area on the right to zoom in and read them more easily, or to make the links easier to click on.

Detecting iPhones

If you want to detect an iPhone, and serve content specifically to iPhone and iPod touch users, you can check the browser’s user agent string, which is an identifier that the browser sends to a server when it is asking to view a file. The iPhone’s user agent string is reported as something like this:

As you can see, it includes the word “iPhone” in there, as well as saying that the browser uses the same KHTML rendering engine as Safari on the desktop. Using JavaScript, we can check for the presence of this text and then make the page behave differently using this browser detect:

It’s wise not to do too much here that is specific to a certain mobile phone, especially as more devices are coming onto the market with similar functionality. But a few little touches here and there are always welcome.