(Ken Struys' Blog)

web-developer, serious schemer

Mobile Web Development

Recently I've been doing a lot of Mobile Web Development, and I decided I would write down a couple of the lessons learned buildng mobile web applications.


Mobile is generally a very different style of layout. You're restricted with the amount of information you want to put on a page and you have to consider things like browser resolution. Mobile web apps are portrait site with little to no fixed width/padded/margined elements. You avoid fixed width to make sure your product works on as many phones as possible. By fixing the width of an element, you create a minimum width of the page. You also want to make sure you fill the browser window and make use of the entire screen.

Most of your layout is going to be done with percentage widths. This isn't that hard, the only place where it becomes a little tricky is when you have a mix of floats and percentage widths. The browsers won'talways calculate the percentage correctly. Generally, if you're good and don't have any unnecessary containers around everything, you shouldn't have a problem.

Decide up front, before even wireframes, what phones/resolutions you're targeting. Does this product have to work on really low width phones like the Blackberry Pearl? Are you just targeting the iPhone? maybe you want to make it look native, checkout jQTouch. How about Androids? Well then you might not want the apps look/feel similar to the iPhone. If you get a requirement like: "As a user, the product must work on every phone in the market, so the app maximizes reach", then remember to consider all resolutions (even low width screens). You are going to be restricted even more on how much you can fit and it might hinder the UX of iPhone.

Here are a few examples of sites that are/aren't targeted for low res phones:

I visited all of the mobile sites and resized the window down to 240px width to find errors

Progressive Enhancements

Some of the errors you see above can be fixed.

  • When I visit digg 4, one of the really iconic features are the huge tabs. The tabs are part of the design of the original site and I understand why they had to be there with fixed width/padding/etc. Thoora has a similar problem when you resize smaller then 240px; the catch phrase hides behind navigation bar. The tabs for digg are actually there, but are now floating below the logo. One thing they could change is simply setting the background colour of the navigation to their brand blue. When it's sitting over the header it would appear normal and when it floats below, the header just looks taller. This slight change is a huge advantage because you can actually see the text for My News/Upcoming.
  • Flickr actually did a really nice job with handling resizing. When on a wide profile screen, the search box floats to the left so you don't have to scroll to get what you want. At the same time the layout shows off a nice picture from their product. If you get a chance try out resizing on Flickr's mobile site. The only restriction on Flickr's site, is they set a min-width on the body to 320px. It's reasonable, but will mess up on <320px wide phones. Again they picked their market and they have a link to an old version of the mobile site made for older phones. One thing they might do is make a list of models that have <320px width (the list shouldn't be growing) and do redirection to the old mobile site.
  • Answers just didn't accommodate for small phones. One thing I really don't like about their mobile site, is it doesn't include original design features of answers.com, instead of including their logo they just typed Answers.com in plain text. Even worse, on all small profile phones, their nav is overlapping the name of their company. Easily fixed, get the branding in place (add the company's green somewhere), and move the navigation below the logo.

Meta/Link Tags

There are tons of smartphone specific meta/link tags make your product cleaner. Here are the ones I commonly throw in:

Phone Number Detection

Phones will try to auto detect phone numbers and make them hyperlinks. If something is a phone number, I'll make it look like a button, so I disable this feature.

<meta name="format-detection" content="telephone=no"/>

Mobile Icons

When a user bookmarks the page on their phone, meaning they have it on their home screen, you want to have a nice icon on iPhones/Andriod to make your webapp more appish.

<link rel="apple-touch-icon" href="/link-to-image.png"/>

<link rel="apple-touch-icon-precomposed" href="/link-to-image.png"/>

<link rel="shortcut icon" href="/link-to-image.png" >

Note: apple-touch-icon-precomposed works for Android.

Disable Scrolling/Zoom

If you build your app correctly the user won't need to scroll left/right or zoom. Disable these features:

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />

Status Bar Color

Make the status bar on the iPhone either black or grey (default).

<meta name="apple-mobile-web-app-status-bar-style" content="black"/>

Hide the Address Bar

This one is just for the iPhone and it's actually JavaScript but it will hide the address bar on the iPhone giving you an extra 60px of height. Any scrolling on the iPhone will cause the phone to hide the address bar so scroll a pixel down the page on load.

<script type="text/javascript">

(function() {

    addEventListener('load', function() {

        setTimeout(hideAddressBar, 0);}, false);

    function hideAddressBar() {

        window.scrollTo(0, 1);





There are a couple different DOCTYPEs you can use or surprisingly, you can just not include it. I would go into the explanation of what doctype to use by Andrew Hedges of Digg did a really good job see his point here.


Redirection is something you really need. Your users aren't going to know about the mobile site without it. I typically use a simple cookie to handle correct redirection behaviour. The user should be able to switch between the mobile and full website when they wish and if you don't follow this chart for handling redirection then you will confuse them. In the chart we have three states for the cookie, not-set, mobile preferred and full site preferred. In theory you only need two states, but assuming you're using a reverse proxy cache you’ll need to know when to miss the cache and set cookies.

DeviceRequest URLRequest CookieResponse CookieResponse
Mobilesite.comNONEMOBILE_PREFredirect: m.site.com
Mobilesite.comMOBILE_PREFMOBILE_PREFredirect: m.site.com
Mobilem.site.comMOBILE_PREF MOBILE_PREFm.site.com


Couple note's on things that might give you headaches. Some browsers especially older ones will try to "optimize". By optimize I mean remove "unneeded" elements and even stop scripts from running. You don't have firebug on these phones and it's hard to tell when it's happening. If you do have empty elements (I know you shouldn't have these anyways) stop browsers from removing them with a non-breaking space:

<div class="background">&nbsp;</div>

In terms of scripts, jQuery is a script, it's parsed and evaluated. Older phones might choke on jQuery and randomly stop the loading the library. I typically end up writing all my js from scratch if I have the slow phone requirement but there are more modern solutions like using lightweight js libraries.

You're going to want to make sure you design things to be clickable. This often means making block elements with anchors wrapped around them. This is invalid HTML and some browser will drop the anchor element making nothing clickable. My solution is putting onclicks on the block elements, and then inserting anchors as well on inline elements. This way everything stays clickable and will still work with JavaScript disabled (anchor as fallback). You can also set your inline elements to block and avoid the JavaScript completely but it sometimes doesn't layout correctly on Blackberry.

Blackberry <=4.6, JSONP is not supported correctly. It seems to work when you do a JSONP request from the same domain (in-which case you can just use AJAX) but you will have to proxy any cross domain JSONP requests to get any blackberry (pre 2008ish models) to work.


There are some good tools out there for mobile. I love using the user-agent switch add-on for Firefox. You can use it to set your browser to have an iPhone user-agent and will be redirected to mobile versions of sites. I often forget to disable it and end up browsing sites all day in mobile version just to see how everything is done. Also assuming you have a Mac, the iPhone simulator is excellent for testing mobile web apps. Also firebug's net panel is useful for ensuring cache headers are working correctly and that you’re not downloading any massive assets. Generally each page of your mobile site should be under 40KB (with an empty cache).

You also have some really terrible tools out there. With the exception of the iPhone simulator, I haven't found a simulator I ever want to use again, especially the blackberry simulators, they are slow and absolutley awful. Luckily I'm usually able to borrow a blackberry and android from someone for testing.