By: Brian Suda

March 12th, 2008

Reader Rating: 9.5

The number of users browsing the Web from a mobile device continues to rise, yet most mobile web sites are still sub-par.

The thing is, creating a great web experience for users of mobile devices is much easier than you might think. In this article I'll introduce seven fundamental steps that, if followed, will help you avoid the pitfalls that have caused many other mobile sites to fail. By the end of this article you'll know exactly where to focus your efforts in order to build a successful mobile site.

1. Don't Mix Up Your Markup

A few different types of markup are available for building a mobile web site. You'll need to choose one that suits the needs of your customers and stick with it.

WML

In the early days of mobile web devices, the only way to surf the mobile web was to browse WAP (Wireless Application Protocol) sites. A WAP site uses WML (Wireless Markup Language) as its primary markup language. WML is an XML markup language based on the card-and-deck metaphor.

Luckily for us, WML has since been superseded by several other technologies -- in fact, if you're just getting into the mobile web game, you can probably ignore WML entirely. WML is mostly used by legacy systems or by sites that explicitly target customers with low-end phones that are six years old or older.

One potential group of customers still using WML browsers, however, is those in developing nations. The Nokia 1100 and 1101 [1], for example, are extremely basic, extremely cheap phones, of which an estimated 200 million units have been solid worldwide, making this phone the best-selling model to date, worldwide. If your site is targeted to this market segment, WML might be the best solution for you.

XHTML

For most sites, we can ignore WML and make use of a markup language with which you're probably much more familiar -- XHTML.

Most built-in phone browsers these days can handle XHTML just fine. A mobile phone recognizes two flavors of HTML:

1. XHTML -- the same, basic XHTML rendered by desktop web browsers


2. XHTML-MP -- the MP here stands for Mobile Profile

The difference between these two languages is that XHTML-MP consists of slightly fewer elements and tighter restrictions. These differences exist to make it easier for the mobile device to parse and render a web document, but writing XHTML-MP markup shouldn't introduce any significant changes to your process for writing regular XHTML.

Anecdotally, when my team and I develop mobile web sites we usually use regular XHTML, and this approach has served us just fine.

2. Know Your Phones

As plasma and HD TVs slowly hit the market, broadcasters have run into the problem of where to place their logo and news tickers. Previously, they knew that all TVs were the same 3x2 dimensions, so they knew the relative width of the screen. Now, they're beginning to feel the pain of dealing with a wide assortment of TV resolutions and dimensions -- an issue that web developers deal with on a daily basis.

Of course, the mobile world is even worse! Not only must we cater for different screen sizes and resolutions, but also different shapes, as Figure 1 illustrates. From rectangles that are short and long, to those that are tall and skinny, to perfect squares, the mobile world contains a rich tapestry of variation that almost makes you want to pull your hair out!

If you consider the most common phones available, they can be categorized on the basis of screen size -- give or take a few pixels:

• 128 x 160 pixels
• 176 x 220 pixels
• 240 x 320 pixels
• 320 x 480 pixels

Knowing these screen dimensions helps you optimize some of your content, however it's best to keep the shape and style of your site as minimal and linear as possible. There is no mouse on a mobile phone -- only an up-down feature -- so you can't demand that users jump around the page.

iPhone/Internet-tablet versus old green-screen phones

There are a couple of exceptions to the norm in the mobile phone market. They are the really high-end devices like the iPhone or the Nokia Internet Tablet, and the very basic, old "green-screen" monochrome dot matrix devices such as the Nokia 3310 [2], both of which are shown in Figure 3.

Low-end mobile phones have several limitations, including screen resolution and a severely limited ability to render XHTML documents. As I mentioned in the previous section, if a majority of your customers fall in this group, then maybe WML is still for you.

At the other end of the spectrum, high-end devices often have the ability to run a web browser that's comparable to one you might use on a desktop machine. Delivering a quality user experience to these devices can be tricky -- while the device may be perfectly capable of rendering a full, traditional web page design, it's probably transmitting data over a cellular network, which is much slower than standard broadband Internet speeds. So even though the device can handle a normal web site, the customer's situation and the reason why they're requesting your services may mean that sending them the normal version of your web site isn't the best solution.

We'll see in the next section what this means for the design of your mobile site.

3. Target the Right Customers

The goal for any web site should be to know your customers in order to deliver to them the most appropriate content.

This goal is even more important with mobile sites -- not only do you need to know your customers, but you need to know what they are likely to be doing on your mobile site, as well as where they'll be when they're doing it. Traditional web site customers are most likely sitting at a desk facing a large monitor that has a decent resolution. Visitors who are browsing your mobile site are unlikely to be in the same circumstances -- they might be waiting in line, riding on the train or the bus, running to the departure gate, or lost in an unfamiliar town late at night and trying to get somewhere.

Google is one company that has invested considerable effort into streamlining its web applications to suit mobile users. The web developers at Google have identified and focused on three main groups, and they attempt to target their applications to those customers' needs. These are three solid categories, and are worth examining for your own mobile site. Let's look at them now.

a) The Casual Surfer

These customers act in a similar way to customers of traditional web sites. Casual surfers are not really interested in any one thing, but have a few spare minutes between tasks to take a look around. In the world of desktop PCs, those few minutes might occur between meetings, or while the user's on a short break. For a mobile customer, those few minutes might occur when the user's sitting outside waiting to meet friends, in a car or taxi traveling somewhere, or even during the morning commute. If your site is focused on the sort of content that would appeal to casual surfers, then be aware of the limitations on the time and screen-size of your mobile customer.

The goal should be to make your content more "sticky", so that casual surfers come back for more. For example, you shouldn't serve up long pieces of content. Instead, aim for small, bite-sized chunks that are just enough to keep customers interested, but not so long that users can't browse your site in the time they have available.

b) The Repeat Visitor

Repeat customers are those that are constantly returning for some sort of specific news or data. If your site is the kind of site that offers information about stocks, weather or sports scores, you probably have plenty of repeat visitors. The interface of a mobile device is very limited, so if you know what your repeat visitors are coming back for, time and time again, let that naturally bubble up to the top of the site. Avoid burying the content your customers want behind 3 or 4 clicks.

Mobile web site customization can be difficult, but it's not impossible. A traditional site might ask you to log in, but on a mobile device, data entry is not as easy to perform, so it's best avoided.

One option is to allow visitors to use their desktop machines to streamline their mobile experience. Take a page from Apple's iTunes Music Store as an example. A repeat customer might customize his or her version of the mobile site while at a desktop machine; this could generate a special URL in which all of that user's preferences are encoded. The next time the user visits your site from a mobile device, he or she can take advantage of this special URL, enjoying an experience that's completely customized to his or her preferences.

c) The "Urgent, Now!" Visitor

Depending on your business, your definition of "Urgent, Now!" will vary. For an online store, a customer might consider the following message urgent:

"My books were supposed to arrive yesterday. They're late. Where are they?"

A more seriously urgent scenario might be:

"I'm running 15 minutes late. Will I be able to catch my flight?"

For some customers, everything is urgent! But by identifying the most important needs of your customers and making the relevant information accessible within one click or less, you'll increase the usefulness of your mobile site enormously.

4. Publish the Bare Minimum

One of the common myths about mobile web development is the misguided notion that content from your traditional web site can be easily re-purposed into smaller bit-sized chunks for the mobile version. A simple change of style from media="screen" to media="handheld" is all you need to do to magically mobilize your site, right?

Wrong.

While it's indeed possible to filter content with the liberal use of display: none in your mobile style sheet, in reality, this isn't a good idea. In fact, many CMS systems can output a mobile, streamlined version of your web site, but even this is not always what your customers will want.

The W3C defines the concept of One Web [3] as follows:

As this definition suggests, some things are simply not available (or even usable) on some devices. Additionally, some devices (such as a mobile phone) are much better at certain activities (like making phone calls) than other devices. Therefore, a device designed for a specific activity should utilize its unique features on the Web.

While the concept of having only one site, and to simply style it differently depending on the medium the visitor is using, is popular with many standardistas, a separate mobile site is required in order to deliver an optimized experience for mobile users. Customers who are surfing on a mobile device have different needs and requirements, so to force-feed them the same content as that displayed on the traditional site is a recipe for disaster. The following images show a good example of this principle. The Best Buy mobile site displays only two functions (Product Search and Find A Store) -- a far cry from the traditional site.

5. Choose a Great Domain Name

As you build the mobile version of your site, you'll need to decide upon the domain by which users will access it, and work out how to advertise the fact that it exists. There are several options for choosing a mobile domain. Let's explore each of them.

1. Use a separate domain altogether (e.g. www.example-mobile.com).

Creating a separate domain has never been necessary for any of the sites I've worked on. A separate domain name can hurt your site's overall branding and can confuse users -- how many people will actually remember both the URL for your traditional web site and your mobile version? And which site should you promote in your advertising? Such an approach can end up being a hassle, and is therefore not recommended.

2. Use a subdomain (e.g. m.example.com).

Creating a subdomain is probably the most popular option. Using a subdomain (such as mobile, or just m to keep it short) keeps your mobile site part of your brand without creating confusion. Obviously, if it suits your customers, you might want to localize the term 'mobile'. And if adding 'm' to the start of your domain name spells something horrible, you might consider placing the mobile element at the end of your URL (e.g. http://example.com/mobile/).

Either way, you should assume that people will get the address of your mobile site wrong. Anticipate this eventuality by setting up several different common subdomains -- m, mobile and others -- and redirecting them all to a single mobile site, just as you should redirect typos like ww and wwww for your traditional web site to www.

3. Use a .mobi top level domain (e.g. example.mobi).

The question of registering a .mobi TLD has been the cause of heated debate among web developers ever since the availability of .mobi domains was announced. Personally, I've never used a .mobi domain for any of the projects I've worked on, but this decision may come down to a personal preference. If you have a few hours to kill, a quick search will provide you with plenty of information [5] about the pros and cons of using a .mobi domain.

4. Do nothing, and let the server send the best page based on the user agent.

Performing user agent detection is perhaps the most interesting option from a developer's point of view. It's also the most elegant from a user's point of view, but unfortunately it's the approach that's most prone to issues.

Here's how it works: when a user visits the site example.com, the server looks at the visitor's user agent and tries to detect if the visitor's using a mobile device or a desktop browser. Given that information, the server will send the most appropriate page for that user agent. The beauty of this approach is that it allows you to use a single URL, which anyone can use with any device. Whether they're on computers or mobile devices, all users will magically view the version of the site that is best optimized for them. When it's done well, this can be great solution. But when it's done poorly, it can be a disaster.

The second option that we discussed (using a subdomain) has one other advantage: a user browsing with a high-end device might first visit the mobile site, then realize that this site doesn't contain the information he or she wants. The user then has the option of navigating the traditional web site to locate the information. The user experience might not be optimized, but the user should still be able to find the desired information.

With user agent detection, however, there's only one URL, and therefore only one version of the site that can be returned to that device. The customer can't choose the version to view -- even if he or she is capable of viewing the site. If you plan on performing user agent detection, you'll need to allow for exceptions so that devices can override the detection process in order to view a specific version of the site. As you can see, if you head down this road, things can get very messy, very quickly.

When you're deciding on a domain name for a mobile site, the colleagues and companies I've worked with have always chosen option #2. Creating a subdomain is the easiest of the options to set up (you already own the domain), it's the cheapest option (there's no need to register the .mobi), and it means that you avoid having to spend hours tweaking the server (and potentially messing up normal traffic). The end result is a sandboxed subdomain built specifically for mobile devices. And if traffic numbers are not what you expect (for better or worse), a subdomain gives you the flexibility to grow or scale back the mobile site without impacting on the traditional web site.

6. Validate Your Markup

Desktop browsers can be quite forgiving. A few misplaced HTML tags here and there will, more often than not, be fixed on the fly so that your page is rendered correctly. However, the "smarts" built into desktop browsers in order to perform this error handling equate to more code, which means a bigger install and more processing power.

Mobile browsers, on the other hand, are much less forgiving. A browser running on a mobile device generally won't have the luxury of a 2 GHz processor and 100MB of disk space. Therefore, you must check, validate, and recheck your markup, time and time again.

Much of the checking and validation of a mobile web site can be done through a normal desktop browser. If you're developing in XHTML, for example, you can reuse all of the same tools that you use to validate traditional sites:

• The W3C validator can be used to find simple markup errors -- there's even a mobile-specific version [6].
• The Ready.mobi site [7] lists a few additional mobile specific checks.

You'll notice at this point that we haven't yet discussed checking to see if the mobile site works correctly on a mobile device. Once you've received the green light from several validators, you'll need to get a few different types of phones to perform some actual tests.

7. Test, Test, TEST!

Testing your site with a web browser on a desktop computer can only get you so far in terms of simulating the mobile experience. There are many elements of mobile device usage that can't be replicated accurately in this way. For example, a mobile operator might restrict packet sizes to something smaller than you expected, and therefore won't even send your web page or its images! Additionally, content mime types could be an issue between browsers -- are you serving the pages with the correct text/html or application/xml+xhtml? What kind of image formats can the phone display?

Due to the small footprint in memory and on disk, mobile browsers are not as robust as desktop browsers, so the best advice is test, test, test! Granted, not everyone can afford to test on every phone that's available on the market, but there are alternatives:

1. Emulators

There are plenty of online emulators [8] and offline emulators [9] that allow you to quickly see images in context and the general layout, but they're not real devices, and therefore they have their own quirks and differences. These tools can act as a good first pass to find common issues. Also, they're free to use, so there's no reason to not have a peek in an emulator, but you can't call a site viewed on an emulator "tested".

2. Rent Time

Renting time is another option. There are services that allow you to upload or view the content one multiple phones in real time. You control the different phone's features remotely. This service does cost money, but it's still cheaper than purchasing lots of different phones. For a basic mobile web site, this service probably isn't needed.

3. Buy a Handful of Phones

Buying a small subset or representative phones is a possibility. If you're planning on doing more mobile development, spending a little money up front can really help. You probably need to purchase 5 or 6 phones representing the major brands and types.

You'll need some sort of Windows smart phone -- we test on an HTC Mogul PPS-6800 using Internet Explorer on Windows CE, which gives a representative coverage for all Windows Mobile devices. You'll also need a Nokia model phone. We test on a Nokia 6600 running Symbian Series 6 OS and the built-in Services and optional Opera browsers. You'll need a Sony Ericsson phone. The model we use is a T630, which covers Sony's Internet Services. Lastly, you should test in whatever model is most popular in your audience. You do not need these exact phones, but these types of devices will allow you to quickly see the minor differences in the phone browsers and cover the majority of potential customers.

4. Ask Your Friends

Finally, you can simply ask your friends. We all know at east 5 or 6 co-workers or colleagues who would happily lend us their phone for a couple of minutes. Once you've tested your web site with the online emulators and validators, test it on the borrowed mobile phones. The pre-tests should have fixed all but the issues that are specific to each phone. Take notes, make corrections, and test again, and again -- and again! -- until you're satisfied.

Depending on your budget, one of those options will suit you. Spending just a little time and money really can go a long way -- especially if this is your first mobile web site. Getting your test suite right will allow you to find common issues, while helping you to build a library of working HTML, CSS, and JavaScript code that's known to be tested and can be reused in future projects.

Conclusion

In this article, we looked at seven key factors that you should consider when building a mobile web site. Along the way, I demonstrated that getting started in mobile web development isn't as scary as you might once have thought. With a little background reading, your existing web development knowledge, and plenty of testing, it's possible to build yourself a very usable, successful mobile web site.

I look forward to viewing the results of your efforts the next time I'm stuck in traffic!

[1] http://en.wikipedia.org/wiki/Nokia_3310
[2] http://en.wikipedia.org/wiki/Nokia_3310
[3] http://www.w3.org/TR/
[4] http://www.w3.org/TR/
[5] http://www.google.com/search?q=should+i+use+a+.mobi+domain
[6] http://validator.w3.org/mobile/
[7] http://ready.mobi/
[8] http://mtld.mobi/emulator.php
[9] http://developer.openwave.com/dvl/tools_and_sdk/phone_simulator/