While accessing the web on a mobile device is nothing new, a renewed interest in developing mobile web content has been ignited by the increased availability of WAP 2.0 devices, an abundance of skilled XHTML developers, and notable efforts by groups such as dotmobi and the W3C’s Mobile Web Initiative. There’s no better time than now to learn how to publish web content beyond the desktop.
I’ll let you in on a little secret: I can read minds. I know what you’re thinking: “Why should I care about mobile? After all, the mobile web experience isn’t nearly as good as the desktop web experience.”
You’re not alone. That’s a mistake many of us make as traditional “desktop” web developers, managers, and producers when assessing the mobile web experience. We long for it to be the same as the desktop experience.
Truth of the matter is the “mobile web” -- a phrase used throughout this article to loosely represent “accessing the web on a mobile device” -- can be every bit as good of an experience, but in its own right. If we treat the mobile web as its own environment rich with possibilities, rather than an extension of the desktop experience with restrictive limitations, we begin to understand how to embrace and even exploit those possibilities.
By now you may have heard the facts: Mobile handset proliferation is expected increase to 3 billion subscribers worldwide by 2009 . Web usage on mobile devices is steadily increasing. Yet what’s really exciting are two key factors: 1) More people worldwide have access to a mobile phone than a PC, which means more eyes to view the web content you’ve worked so hard to create, and 2) you can utilize existing web publishing skills.
But let’s bring things back to down to earth for a moment: It’s fair to say accessing mobile web content, as it stands today, is rather inconsistent. There exists a wide range of mobile device user agents (browsers), each rendering markup in different ways. The choice to use WML, XHTML Mobile Profile, XHTML Basic, or cHTML can be an overwhelming decision, to say the least. And what about web addresses? Is it mobile.mysite.com, mysite.com/wap, mysitemobile.com? Where does device detection fit in?
There is hope! This article is a start. It won’t answer all of your questions, but hopefully it will spawn a desire not only to learn more but also to go forth with confidence in producing a successful mobile web endeavor.
Context is King
The importance of comprehending context -- circumstances and conditions that surround a place, thing, or event -- within the mobile environment cannot be overstated. Your content is of little value to users if it ignores the context in which it is viewed, manipulated, and processed. Consider how you access data on your mobile device. You’re on the subway or tube, or you’re walking to your next appointment. You’re holding your handset in one hand, coffee in the other. You’re glancing up to prevent a run-in with a pole or to be sure you haven’t missed your stop.
The mobile web is very much a context-, content-, and component-specific environment. Or put another way, access to web content on a mobile device is largely influenced by surrounding conditions, informational relevance to the task at hand, and the feature capabilities of the device being used. Unlike the desktop web experience, where screen space is liberal, web access is fast and reliable, and data input is facilitated by keyboard and mouse, the mobile web experience is often a small screen, intermittent, one-handed experience. Invariably, this often leads to leaner content and a reduced feature set in comparison to desktop web content, but it also leads to opportunities unavailable in the desktop web environment: location-specific data, on-the-go messaging, and of course voice communication to name a few.
Any mobile web strategy must begin with an understanding of the target audience and what they want from a site or app, and what the contextual relevance of such a site or app is. Ask yourself, What is relevant to my users and the tasks, problems, and needs they may encounter while being mobile? Begin by answering that question, and you’re guaranteed to start on the right foot.
WAP 2.0: An XHTML Environment
Let’s begin with a few basic tenets of mobile internet technology. Wireless Application Protocol (WAP) is the protocol for enabling mobile access to internet content. Wireless Markup Language (WML) was the former language of choice for WAP 1.0. With the introduction of WAP 2.0, XHTML Mobile Profile (XHTML-MP) is generally the preferred markup language, with mandated backwards compatibility for WML.
Translation? WAP 1.0 = WML, WAP 2.0 = XHTML. This is good news for the average web developer because it means we’re beginning to clear the hurdle of WAP 1.0 and WML that once seemed insurmountable for those who didn’t specialize in mobile development. The learning curve is much smaller today than it was just a few years ago. Nearly all devices sold today are WAP 2.0 devices, and XHTML Mobile Profile, which will be familiar to anyone who has worked with XHTML Transitional or Strict, is the official markup language for those devices.
However, we can’t entirely ignore WML, as it’s the markup language traditionally used over the last few years for mobile websites, or “WAP sites” as they’re often called. Nor can we ignore cHTML, given its prevalence in Japan’s i-mode market. But much has been written about WML and cHTML, and this article aims to bridge the gap between desktop web development and mobile web development in an XHTML environment.
You and I have all the basic knowledge we need to begin developing mobilized websites and applications. XHTML Mobile Profile is merely a subset of XHTML, and it isn’t a far cry from XHTML Transitional or Strict. DevelopersHome.com has published a very extensive resource for learning the ins and outs of XHTML Mobile Profile: XHTML-MP Tutorial
Additionally, dotmobi recently released two sets of XHTML-MP templates that will aid developers new to mobile in creating mobile web content. At the very least you can view source to see the inner workings of XHTML-MP, which again won’t be much different than what you’ve already seen with ordinary XHTML. You can also study the source for sites already using XHTML-MP, such as Flickr Mobile and Yahoo Mobile.
Finally, because XHTML-MP is a subset of XHTML, initial testing and validation can be done within most desktop browsers. Thorough, final testing will certainly need to be conducted using actual devices, but you can test on the desktop initially to see if the markup renders correctly and semantically.
Finally, because XHTML-MP is a subset of XHTML, initial testing and validation can be done within most desktop browsers. Thorough, final testing will certainly need to be conducted using actual devices, but you can test on the desktop initially to see if the markup renders correctly and semantically.
Developing an Approach
If you’re reading this article, you’re probably considering retrofitting an existing website or web app to be more accessible to mobile users, or you’re planning a new website or web app and want to include mobile in the mix. What are your options?
While there are plenty of ways to develop mobile web content, summarized here are three primary methods. Following is an explanation of each method, including a look at the advantages and disadvantages of each.
1. Strip Images and Styling
Recognizing WAP 2.0 devices support XHTML in addition to WML, this method relies on the strength and implicit hierarchy of markup to deliver a navigable, content-rich experience. Styling and images are removed, leaving the raw, unstyled content.
Several resources already exist that allow both the user and the developer to perform this raw rendering with minimal effort. Skweezer.net , a mobile web service pioneered by Greenlight Wireless Corporation, has been in use since 2001. Skweezer’s freeware web portal serves its users with sites that have been reformatted and compressed dynamically. Likewise, Google also has a service that offers similar lean formatting. Over in the developer’s chair, Mike Davidson’s “two-minute” mobile mod allows site owners to repurpose an existing site with a domain mirror and global_prepend / global_append PHP files.
While this “quick fix” method may be attractive given its ease of implementation, it does little to address context. Further, file size may still be excessive, as markup and text-only content can still be heavyweights in their own right, often resulting in long, scrollable pages with large file sizes. (Keep in mind many mobile subscribers throughout the world pay per KB for data access.)
2. Handheld Stylesheets
Handheld stylesheets have typically been regarded as the poster child of a more mobile-friendly web. Because they are inherent in CSS, this method requires the addition of as little as one additional stylesheet to a properly coded site, and only one web address is needed. There’s certainly no shortage of resources for handheld stylesheet development, and those familiar with XHTML and CSS revel in the flexibility and control of these sister stylesheets.
However, things aren’t as rosy as they seem. Handheld stylesheet support on mobile devices is currently hit or miss, more often miss than hit. More importantly, handheld stylesheets deal primarily with aesthetics, rather than context, often giving little attention to whether the content is even relevant to mobile browsing.
3. Mobile-optimized Site
Methods that rework only the aesthetics of a site merely to fit it on a small screen likely fail to address the context-, content-, and component-specific needs of mobile users and their devices.
Little Springs Design refers to this issue as miniaturizing vs. mobilizing. Miniaturizing “treats the mobile environment and technology as a subset of the desktop environment.” It fails to consider the strengths and weaknesses of mobile devices. Mobilizing, on the other hand, “precisely targets mobile user needs, making [the] best possible use of technology.” Contextual user tasks — not the existing website — determine the architecture of the mobilized site.
Yet even this method has its issues. Developers must maintain at least two sets of files (desktop, mobile), and alternate web addresses may be required. Mobile-optimized sites are often audience- and device-centric, which is inconsistent with Device Independence. Further, what happens when mobile devices are as powerful as desktop machines?
Yet nine times out of ten the payoff for the end user will justify the increased development effort. A mobile-optimized site addresses first how content is accessed, second what it looks like. In other words, context before aesthetics, function before form. Pages are leaner, which means users are spared excessive bandwidth costs and generally enjoy a faster browsing experience.
Consider the following example: Kayak.com has been quietly climbing the ranks as the Google of travel searches. They don’t book flights or hotels, but rather search sites that do, and bring in revenue with paid advertising and results. Recently Kayak introduced a mobile-optimized version of their site, kayak.com/moby. Search flights, hotels, even places to eat and you’re given quick access to phone numbers and addresses.
Note the home page is merely a category springboard:
Choose “fly” and you’re shown the following screen. Note the simplicity of data input. One field facilitates departure and arrival cities using airport codes (or city names), and departure date isn’t necessary:
You can’t book a flight (imagine the data entry on your device), but you’ll get price, departure/arrival times, and a phone number to call for reservations. After all, a phone -- the device you’re probably using -- is primarily an instrument for sending and receiving calls. So naturally, providing the user with a phone number rather than order form is a beautifully simple, contextually relevant solution:
You can see additional screens as part of a review posted to my site: “Search travel info with Kayak.com Mobile”
In conclusion, it’s easy to advocate choosing the mobile-optimized method, but the approach you choose will likely depend on such criteria as user goals and objectives, development resources, and the content depth and breadth of your website or application. Your strategy may very well be to do nothing until the time is right to deliver mobile-optimized content. However, if you’re waiting for users to beg for a mobilized version of your site, you’re likely missing out on important opportunities.
An Eye to the Future
Without question the mobile web can be an exciting, challenging, and rewarding experience. There is, however, plenty of room for improvement, as we’re still in the early stages of mobile web development, relatively speaking. Following are just a few ways to improve the mobile web for users and developers alike.
A more desirable, disciplined, dependable experience – There’s a good chance you’ve already accessed web content on your mobile device. And there’s a good chance you were not delighted by the experience. We need mobile web experiences that are desirable, dependable, and disciplined. Desirable in that the overall experience is usable, affordable, and contextual. Disciplined in that the content provided is relevant to the opportunities and limitations of being mobile. And dependable in that we can expect greater consistency across devices and increased convention among mobile sites.
Greater user agent consistency – While estimates vary considerably, we can safely assume there are more than a few hundred web-ready mobile devices on the market and a few dozen types of user agents installed on those devices. This presents a considerable challenge for developers, as testing on -- let alone access to -- the range of devices a given target audience may use is often costly and impractical.
The solution is not necessarily that every device display content the same as every other device on the market, but rather greater consistency at a level such that developers can develop for and test on devices with less time and expense.
Less jargon – One of the biggest barriers to entry for traditional web developers is the sheer amount of jargon and acronyms that riddle mobile web nomenclature; the transition to mobile is akin to learning a new language in some cases. And while study on the part of the developer should be expected, we need to be less concerned about technical terminology and more concerned about user experience.
Consider this example from Feedburner’s Mobile Feed Reader page:
Download the “JAD”? Type that web address using my handset’s numeric keypad? No wonder some fear using the web on their mobile if we have to download the “JAD” file version by multi-tapping 50 characters.
You - The mobile web needs you. Your experience. Your talent. Your innate ability to solve problems users are facing while being mobile. Your voice to encourage your organization to mobilize its web content in a contextually relevant manner.
So what are you waiting for?
