At my company, we get many inquiries where people want to create a mobile version of their existing sites. Unfortunately, many of these good people do not yet fully understand the intricacies and fragmentation of mobile web browsers and significant differences that exists between mobile and desktop world. This article is meant to provide some useful information to our prospective and valued clients. At my place, it is our philosophy that a well educated client is the best client, and it is our responsibility to provide clear and precise information to them.

My team and It have been working with Internet web applications and mobile applications including mobile web sites for last several years. We will be discussing some of our experiences and lessons learned through more recent mobile sites designs. Hopefully, you will find a few nuggets of knowledge that you can apply to your next mobile site development plans and move to exciting emerging world of mobile web.

Understanding the Nature of Mobile Web

A mobile device, even with all the new features of touch screen and key board, is primarily a device designed for making phone calls. The other functionality is all after thought and a natural evolution of any device.  Therefore, a mobile phone is not a miniaturized version of desktop or your laptop even though some manufacturers like Microsoft have pushed their software and marketing in that direction and have failed so far with an average consumer.  The limitations of phones are not because of software or hardware in phones, but many other issues surrounding the operating environment of mobile phones.

Mobile web faces several technical hurdles of limited bandwidth,  small device memory and need to preserve battery life on the phone.  The small screen and thin sizes add to portability of the devices while the same features makes it harder to run full functionality web browser on the phones.  Therefore, alternative is create a light weight web environment suited to mobile phones and that’s what most manufacturers have done.

 

Limitations of Mobile Phones for Browsing Web

One key difference between desktop PCs and mobile devices is the means of user input. On a desktop you have a mouse and keyboard; on a phone (with some exceptions) you have 0-9 and possibly a joystick. This means that mobile users must cycle through links manually, as they do not have the luxury of point-and-click. To get a sense of what this is like, try tabbing through a webpage on your desktop PC. Depending on the number of links, you could end up spending many long seconds trying to get to a link that is only a mouse-click away. For this reason, it is extremely important that mobile websites are architected in such a way that all links are readily accessible. The basic means of fulfilling this requirement is to make use of the  acesskey attribute, and the Opera Mini browser has a virtual mouse to help alleviate this hassle.

One of the guiding principles should be keep the “clickiness” low. A user should be able to get to any page on your site with only 3 clicks. Let the important, popular information bubble-up and reduce the number of clicks to get anywhere.

On a mobile phone where the screen resolution might be 120 pixels wide, the thought of having as many links as possible still limits you to only a few on each screen, so you’d think the depth approach would be better. The problem here is the slow connection speed and cost of the transfer over cellular, so more clicks the more it costs and the longer it takes to get to the information the user needs.

How to detect phones

There are several ways for your website to detect the browser viewing it is on a phone and its capabilities. I’ll outline briefly a few tips, link to a couple resources, and talk more about what you can do with that information rather than how get the data. With this information you can tailor the customers experience to their device so it is the best possible. That way they can leverage the most out of their own phones features and capabilities rather than being stuck with a cut-down version of the full site.

User-Agent Strings

As you probably know, a user-agent string is the string that a browser announces itself as, for instance IE7’s UA string is:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)

There has been a big stink over sniffing user-agent strings, and I personally go back and forth on the relative benefits and drawbacks of the technique. The concept of sniffing for a user-agent string in itself is not bad or evil; it is what you do with this information where most sites completely fail. For example, I have seen banking websites that sniff the UA string and try to force you to “upgrade to IE6,” even if you are using IE7. Fully capable browsers with small market shares often get excluded from sites even thought they could probably run the whole site comfortably.

This is why browsers like Opera, and Firefox with plugins, allow you to lie about what browser you are using. The problem is not the sniffing of the UA string, but the fact that companies do evil, incorrect things with the data. Do not assume that just because the UA string is not in your enumerated list of “Accepted strings”, it is not possible to view the site. This is where you build in progressive enhancements to the website experience.

Object detection is another method to consider, where you search for specific objects in the target browser to see whether it will run your features. This has the advantage that it is browser independent, and if a browser does not have the support required to run a certain feature, it will just avoid the feature altogether, rather than breaking. Then if support is added, it will pick up that feature without you having to change your code.

WURFL

WURFL is an open source list of known phones and their capabilities. This can be put into a database and when a mobile device visits the your site you can sniff the UA, look-up the capabilities of that device (including screen-dimensions, default browser, etc) and serve them the best possible experience.

A simple example is the tel protocol. Desktop Browsers recognize a handful or different protocols – http, ftp, mailto, and a few others. One that they tend not to recognize is the tel protocol. href=”tel:1234567890″ allows you to click a link and the system will dial that number. For a desktop machine this is not very practical, the vast majority of us don’t make phone calls via the computer (although skype re-invented this as the callto protocol). A phone, on the other hand, is a perfect machine to use the tel protocol for phone related links, but not all phones support it, so you want to check first.

Using WURFL and your favorite programming language, you can make something like the following:

if ($tel_capable == true){  echo ‘click to call me at 1234567890‘;} else {  echo ‘call me at 1234567890’;}

This allows you to generate tel links for phones that can handle it, but not for less capable phones. The same might go for image dimensions. Knowing the screen-size you can increase or reduce your masthead logo to fit accordingly. It does give the same information no matter what the device or capabilities, but you get a more or less enhanced experience.

HTTP Headers

Some devices send along a special header with each HTTP packet, which gives more information about the browser and version. It is similar to the UA string, but is device dependant. The additional header property is called Profile and is sometimes a URL to a file that can be extracted and the device capabilities extracted. Blackberries do this with a link to an RDF file that tells you more about the device than you can imagine. A URL from a blackberry devices looks like this:

http://www.blackberry.net/go/mobile/profiles/uaprof/<BlackBerry-model>/<software-version>.rdf.

Your server can fetch that RDF file, cache it and parse it for various capabilities. The RDF vocabulary is a standard across many mobile devices. Vendors that use this approach allow mobile sites to keep up-to-date with any new devices, without having to keep their own database of device types.

Every year there are hundreds of new phones on the market not to mention the legacy phones that have already been sold and are used on a daily basis. It is impossible to keep a complete list of every phone and their capabilities. Even if that were possible, there is the issue that individual carriers using the same phone might disable certain capabilities. It is a pretty hairy world of devices out there – there is no magic bullet! No matter how much you read and think you know, you will always have to test and retest over and over and be content with slight differences between devices.

What works and what doesn’t?

After several sites, you quickly learn what you can and can’t expect to work. This is a short list of things to keep an eye on when going mobile. You can find more details about standards support in Opera Mini/Mobile 4 here:

• Designing with Opera Mini 4 in mind
• JavaScript support in Opera Mini 4

JavaScript

There are a few basic coding items to avoid in the mobile web space. Chief among these, at least for now (now being 10/2007), is client-side scripting. While it’s tempting to try and port that elegant bit of AJAX from your conventional web to your mobile web, you will only create headaches for yourself. One of the central challenges of coding for the mobile web is how to create a compelling user experience without resorting to any form of scripting voodoo. Some browsers do support various levels of JavaScript, but as a developer you should not expect it to work across all devices. This is a perfect example of progressive enhancement possibilities. If the site works without JavaScript, then all devices can work with the site. At this point, you can begin to add JavaScript into the code to enhance the experience for the few browsers that do support it. JavaScript also tends to be a pretty heavy processor hog, so continuous scripting can drain a battery fast – just because you can doesn’t always mean that you should.

CSS Styling

In terms of CSS, the main thing to remember is that mobile browser support for stylesheets varies greatly. Thus, I would personally advise you to keep things simple. It is also a good idea to constantly be testing your pages on an array of actual devices. This is the only reliable way to see what works and what doesn’t. For example, you may discover that 4 out of 5 devices support positioning of background images. On the 5th device, however, the background image simply disappears. The question you then must ask yourself is: do I find some other way to code this or do I accept the fact that one device out of five will not see the background image?

Fonts

From an aesthetic standpoint, the single most important thing to remember is that most mobile devices default to their own font sizes and families regardless of styling. Thus, when working on the Siminn project we made no attempt to influence font size or family. In cases where we wanted a larger font, we simply relied on the generic XHTML heading elements. That said, we did make one important and quite useful discovery. In general, the default font size of every given device was too big for our needs, and we tried to work out how to decrease it. What we discovered is that the inclusion of font-size=smaller in the body tag worked as a kind of global reset for font sizes in every device we tested. With this little bit of code we were able to sufficiently reduce the default font size and thus more faithfully reproduce the design that we had been tasked with coding.

HTML Mark-up

XHTML-MP – the mobile web subset of XHTML – is fully supported on most modern devices. Therefore, make good use of the elements contained in XHTML-MP. Think in terms of un-styled, accessible, semantic, valid mark-up. There are enough elements at your disposal in XHTML-MP to faithfully render most mobile web designs. But the key is to make your pages legible with or without the accouterments of CSS.

Conclusions

These two seemingly simple case-studies demonstrate the vast difference in needs of the customers. As you start into the world of mobile development there are several things you need to keep in mind. Sites will never be pixel perfect! This is a reality on the 3-4 major desktop web browsers, and with hundreds of different phones and mobile browsers to consider as well this problem is compounded enormously! There is no silver bullet. You can’t read 2 books and several articles about mobile web development and cover everything. Much of the effort is trial and error. When starting out, emulators are a good way to get a rough idea of how the site will work. It gives you some feel for the navigation, architecture and flow of the site, but the look and feel varies from the emulator to the real device. The best thing you can do is get a few real phones to test on. I’m sure between yourself, co-workers and a few friends, you can manage to test your site on a good cross-section of the phones out there. Finally, there is some help. The W3C mobile web initiative does have a checklist to see how well your site is doing and so does dev.mobi – if you take heed of these two lists, your site should give a quality experience to most customers.

Mobility in our daily lives is ever increasing. The ability to get data, when we want it, from anywhere and any device is the future of Internet. The cell phone is just the tiniest jumping off point in this vast new world of the mobile web.