Mobile Web Applications

The mobile web is maturing -- but be careful to not stuff your application chock-full of "features."

The Maturing Mobile Web

The term “mobile web” has evolved significantly over time. What started as barely-text-only web applications has matured to a very capable and satisfying mobile experience for many users.

As an increasing amount of rich content is made available to the mobile browser, the “mobile web” will continue to grow — and with it the platforms that can best leverage it.

iPhone, Android and Palm webOS are well-positioned to enjoy content-oriented growth through mobile web applications as they are each formidable mobile web client platforms.

Other, non WebKit browsers are also maturing. Regardless of the platform, or the browser engine, the mobile web experience continues to improve and is becoming an increasing part of our daily lives.

Some of the key drivers for this include:

  • Faster Internet Connections — coverage breadth and speed continues to improve.
  • Bigger, faster color displays — now that we have networks to deliver higher quality images, we need something to display them on.
  • More intuitive input devices — the human finger is always attached; and learning how to pinch and zoom can be taught to most bi-peds on the planet today.
  • Better Software — Ajax, browser-based SQL databases, and capable JavaScript libraries (like jQuery) reduce bandwidth requirements, increase application architecture flexibility and simplify programming tasks.

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.

<link rel="stylesheet" href="primary.css" type="text/css" />

<script type="text/javascript">
   if (navigator.userAgent.indexOf('iPhone') != -1) {
      document.write('<link rel="stylesheet" href="iphone.css" type="text/css" />');
   } else if (navigator.userAgent.indexOf('Android') != -1) {
      document.write('<link rel="stylesheet" href="android.css" type="text/css" />');
   } else {
      document.write('<link rel="stylesheet" href="desktop.css" type="text/css" />');

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.


<script type="text/javascript" src="jquery-1.3.2.min.js"></script>
.myclass {
cursor: pointer;


var selectedItem = "";

function flip() {
function setup() {
 $(".myclass").click(  function() { $("#detailview").html("Details for " + this.innerHTML + " go here ....<br /><a href='javascript:flip();'>Back to list<\/a>"); flip(); }  );

<body onload="setup();">
<h1>Simple Example</h1>
<div id="listview">
<li class="myclass">One</li>
<li class="myclass">Two</li>
<li class="myclass">Three</li>
<li class="myclass">Four</li>
<div id="detailview">
   Detail View goes here

Hopefully this column has given you some things to think about when designing a mobile application, along with some practical examples of targeting mobile devices for web applications.

Frank Ableson is an entrepreneur, writer and mobile software developer who probably should have been a hardware designer, but soldering got in the way. Frank's technical interests are in mobile and embedded computing. Frank is the lead author of Unlocking Android 2e, an intermediate text on software development for the Android platform. Use coupon code linuxmag for a 30% discount.

Comments on "Mobile Web Applications"


Actually the borwser detection, as showed, should not be used for choosing CSS! Imagine using an Android tablet. Your application would switch to a CSS optimized for a small display while the tablet might actually have a full size one. But there is a proper switching feature already implmented through apropriate media attribute in the html link element (according to the HTML standards).

Consider the HTML code below. There are two stylesheets defined. common.css is used for regular screen browser, while hh.css is used for handheld devices.

<LINK REL=\"stylesheet\" title=\"Common\" HREF=\"common.css\" media=\"screen, projection\">
<LINK REL=\"stylesheet\" title=\"Handheld\" HREF=\"hh.css\" media=\"handheld\">



Thanks for your suggestion.

Browser detection is a bit more of an art than a science, in my opinion. If for no other reason than many platforms attempt to \”emulate\” other, more popular platforms.

Even \”handheld\” as a media type is arbitrary, no? What are the screen dimensions of your tablet?

My example was meant as \”simple\” means, though if the dimensions of the device are super important to your application putting additional care into stylesheet selection (and beyond to a specific js file containing relevant constants or \”fallback\” functionality…) would be time well spent for your application.

A Media Query which tests for actual dimensions is arguably the best approach:

Here is an example for obtaining a style sheet targeted towards a smartphone:
<link rel=”stylesheet” type=”text/css” href=”smartphone.css” media=”only screen and (max-device-width: 480px)” />

Here is a media query targeted towards a desktop computer:
<link rel=”stylesheet” type=”text/css” href=”desktop.css” media=”only screen and (min-device-width: 481px)” />

I have a couple of articles soon to be published which go into this in more detail. I will post links back here when they are available.

Thanks again.



I appreciate, lead to I discovered just what I used to be having a look for. You’ve ended my four day long hunt! God Bless you man. Have a great day. Bye


Heya i?m for the first time here. I found this board and I find It truly useful & it helped me out much. I am hoping to provide something back and aid others like you aided me.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>