In this article we are going to take a brief look at a couple of “why’s and how’s” of building mobile web applications.

The Mobile Version

In its most basic form, today’s mobile web is just the “normal web” rendered on a small device. This capability was not practical just a “generation” ago, however today with the advanced rendering capabilities available, mobile devices can render “normal webpages” on their small screens. The image below is the “full version” of the Facebook website on iPhone.

However, many sites prefer to offer content which is specifically targeted to a given platform — and for good reason.

While the rendering engines are fantastic on these devices, the small screens on these devices are still, well, small. And the varying keyboard experience is certainly not the same as a full-sizedkeyboard.

However, there is another reason why mobile web applications should be distinct from their “desktop” counterparts, and it has less to do with physical attributes of the device and more to do with how the devices are used in the first place. Remember the 80/20 rule? Yes, that rule — again.

The application of the 80/20 rule in software is that 80 percent of the benefits from a software package can typically be enjoyed through only 20 percent of the features. There is a time and place for deep menus and right-mouse button functionality, however most of us never tread in those parts of an application, and we shouldn’t count on users of our applications relying upon those deep features either — especially mobile users!

Think about it — how much of MS Excel/Open Office do you really know how to use? I know very little of pivot tables and conditional formatting, yet I get great utility from the software and use it nearly every day for one reason or another — and I dare say that I am not alone in this. As we look at mobile software we should keep this in mind: our users want highly accessible, functional and often, attractive software — not dull-looking clunky versions of their desktop software counterparts. This same thinking applies whether we are writing native applications or mobile web applications.

What can we learn from market leaders like Facebook and GMail? These popular websites offer both a “mobile version” and the option for the mobile user to access the “full” website. Facebook even offers the user the opportunity to download a custom application built for its subscribers. They recognize the value of a stream-lined mobile version, yet are quick to recognize that some users will prefer the more full-featured version. One lesson here is that if you have the budget, offer multiple choices!

Targeting mobile

So how do we know which features to support in our “mobile version”? Keep things simple — strip out all of the “nice to have” features and start with the basic “must have” features. It will be easier to get things rolled out at first and your users will quickly tell you which features they miss. If those requests make sense, proceed with caution and add them. Of course, if you have an ample budget, start with a focus group and get feedback from them. For the rest of us — start simply and grow incrementally, but do so with a mind to avoid application feature bloat.

Craft the purpose statement of your application — and keep this handy at all times during development. When you question whether a specific feature should be added to your application, run it past your purpose statement and make sure it “fits”.

Browser Detection

When building a mobile web application we need to know which version of a website to serve up to our visitors. There are a few techniques to accomplish this task, generically known as browser detection. Here are some strategies for targeting content to a mobile user.

Send the visitor to a specific site, designed for a particular platform. For example: mobile.mydomain.tld or iphone.mydomain.tld

Use the “User-Agent” HTTP header field and use a dynamic scripting environment such as PHP or .NET to generate mobile-specific content.

Construct an entirely parallel site geared towards your specific mobile device — this can often be “redirected to” through a dynamic script as described above.

Use selective style-sheets with a common HTML code base. An example of this approach is provided below.

Keep in mind that some users will simply want your “full site” on their device, so don’t assume everyone will be happy with the stream-lined mobile version — particularly when the site renders so well on their smartphone.

For a recent project I created three style-sheets, one for desktop users, one for iPhone and one for Android. The core styles went into a primary css document and three distinct style sheet files contained platform-specific settings such as font-sizes. Here is how this was accomplished.

One note of caution — you will want to make sure this code runs before your document has loaded. Don’t call this code as an onload handler! If you don’t believe me then go ahead and try it. Using document.write after your page has completed loading will result in an entirely undesired result!

Once you have your specific browser targeted, you can optimize your font selection or other platform-specific feature via CSS selections.

There is one more aspect of mobile web development I would like to share before bringing this article to a close: switching between “views”.

Many applications include a classic pattern of showing data elements in a list and then showing a specific entry in a more detailed view. Traditionally, this would result in a “round-trip” to the server to show the details. With some planning and some help from JavaScript, this can be avoided, or at least minimized.

In the following example, we will see how to switch between a “list view” and a “detail view” within the same HTML file, with the help of the popular jQuery JavaScript library. The sample is ultra-simplistic as it just displays the contents of a List Item (<li>) element in a separate <DIV> element. However, this model can be readily expanded to include browser-based SQL storage to contain the data used in the detail view as well as selective use of Ajax to retrieve only the minimal amount of data without re-rendering an entire HTML page.

Oh my goodness! Awesome article dude! Many thanks, However I am having troubles with your
RSS. I don’t know why I can’t join it. Is there anybody else having similar RSS issues?
Anyone who knows the answer can you kindly respond? Thanks!!