Bringing Web 2.0 to Mobile Devices

Abandon the “versionitis” approach to mobile-site design

The design philosophy that guided previous development of web content for mobile use of the web was to create separate versions of websites, ones designed for viewing on small-screen devices with limited RAM and CPU resources.A side effect of that design philosphy is that mobile operators, particularly in Japan, created a variety of non-standard markup vocabularies for use in developing web content optimized for delivery in their networks.

The result was a mess — a situation that Andreas Bovens describes in his paper “Mobile Web Development in Japan: A Tag Soup Tale” [BOV05] as “the versionitis problem”: N different mobile-specific sites for N different mobile carriers (in Japan, separate sites for Au, Jphone/Vodaphone, and DoCoMo), all with their own idiosyncratic design quirks.

Bovens argues that the solution is for carriers to move to fully supporting the same web standards that guide the development of sites intended for viewing on PCs; that move would potentially enable developers to, as Bovens describes it, “create only one version of a website and serve it to all kinds of devices, cell phones included”. Others have argued that there are certain types of web applications that cannot be viewed effectively on mobile devices, and Bovens acknowledges as much, but contends that for the vast majority of existing web content, a “one version of a website and serve it to all kinds of devices” design approach can be followed to make the contentusable on mobile devices — if that one version is designed with consideration for mobile use.

Design sites and web apps to be mobile-considerate

Setting aside for a moment that debate about whether or not a “one version of a website and serve it to all kinds of devices” approach to developing web content is is a sound approach, it needs to acknowledge that, given that the number of mobile users of the web is still quite low, it's not worthwhile or practical for most developers to create mobile-specific versions of their web sites and web apps, even if they though it would be a good apprach. They just do not have enough mobile users to justify the costs of developing separate mobile versions of sites.

However, in most cases, developers can, with very little additional effort and cost, provide a usable mobile experience simply by designing their sites and apps in a “mobile considerate” way. Last year's XTech conference included a presentation from Håkon Wium Lie [LIE05] that gave an example of how a single version of site could be designed for “all screen rendering”, so that it degrades gracefully (with no pejorative sense intended for the work degrade), displaying in three columns on a PC-based browser, in a narrow single column (and still remain navigable) on a small-screen mobile device, and in something between those extremes (in progressively narrowers columsn, then in two columns, then in one) on devices with screen sizes that fall between those poles.

James Cotton and Patrick Commarford have published on this area of web design [COTT05], as have others, and many vendors of mobile web browsers have developed guidelines offering tips on how to make web content usable on mobile devices. Opera, for example, has a guide titled “ Making Small Devices Look Great” [MSDLG].

However, what's probably needed most in this area is for developers, vendors, usability experts and others to get together to discuss and document what they agree are some common guidelines for making web content usable on mobile devices. The discussion has actually already been formalizesd, as a part of the work of the W3C Mobile Web Initiative, and that work has already produced results, in the form of “Mobile Web Best Practices 1.0” [MWBP], which is currently at Working Draft status within the W3C.

“Mobile Web Best Practices 1.0” is an important document. Web developers should all read the current version of it, follow its progress at it matures, and, in the mean time, start to put into practice the many specific guidelines detailed within it.

Anticipate heavy service-driven and “idle time” mobile-web usage

Bringing Web 2.0 to mobile devices does not just involve making sites mobile considerate or working to make sure that sites degrade gracefully when viewed on small screens. The fact is that while many use cases for mobile web browsing are the same as those for non-mobile browsing, there are some specific use cases that are characteristic of mobile-web use — ones that are not as characteristic of non-mobile web use.

One characteristic aspect of mobile-web usage is that it heavily service-driven. For example, in Tokyo, where most people do not own cars, but instead travel by train and by foot, services that provide information about navigating the city by train and by foot are in heavy use on mobile devices.

Much more thought and discussion needs to be put into specific approaches for designing web applications for service-driven mobile usage; suffice it to say that for now, developers should start taking time to make themselves familiar with how users are currently using their mobile devices — what applications they use and depend on most on their devices (not necessarily just their web browsers and e-mail clients), and what applications they find most compelling and most usable.

Another characteristic of mobile web usage is that users turn to the mobile web during “idle time”. Unlike most non-mobile usage, where users sit down in front of their PCs with a specific purpose in mind (though it may be a purely recreational use such as chatting with friends), users often initiate mobile-device usage without a specific intentition of what they plan on doing or finding.

Turning back to the example of Tokyo: users spend a great deal of time in transit — primarily, riding on trains and waiting for trains. It's quite common to see many people in Tokyo flipping open and using their mobile devices during those times. Often they do have some specific purpose in mind (usually, sending mobile e-mail), but increasingly more often, the purpose is just spend time doing something other than just remaining idle — reading news or checking syndicated feeds, perhaps, or maybe just doing what might simply be described “looking for something interesting”.

Developers need to carefully consider that “idle time” use case, and think about how to design services, sites, and applications that anticipate it

Exploit mobile specific hardware capabilities

Web 2.0 has taken software technologies that have already been with us for a long time (Javascript, CSS) and made better use of them. But discussion of Web 2.0 generally doesn't involve much talk about making use of new hardware technologies. The reason is that there's very little “new” interaction that needs to take place between browsers and the hardware in non-mobile devices. In PC-based browsing, we have basically been working with the same set up display technologies, input devices, and other hardware features for many years now.

On the mobile side, things are quite different. One fundamental difference is of course that displays and input devices you have come to rely on are not available on mobile devices, where screen sizes are typically 240 pixels wide (and less), where in place of a keyboard you have only a number pad doubling for character input, and instead of a mouse and cursor, you have the simple equivalent of arrow keys (and maybe, if you are lucky, page-up and page-down keys).

But mobile devices are not just different from PCs in regard to limitations; they also have hardware features that many PCs lack and that in fact would not have much of a compelling use case even if they were present on PCs.

Chief among those hardware features is the presence of GPS chipsets and other location-sensing hardware on an increasing number of mobile devices around the world. Those hardware capabilities enable a whole class of applications — location-based services with pinpoint accuracy — that don't really have much of a use case at all on non-mobile devices.

Getting back to Tokyo: A number of application vendors in Japan have already had great successes in exploiting location-aware hardware capabilities on mobile devices to build very sophisticated location-based services. One example is the NaviWalker real-time, location-aware trip-routing service built by Navitime. If there is currently anything that might be considered a “killer application” for mobile devices, location-based applications such as NaviWalker are it.

Another mobile hardware feature worth mentioning: built-in cameras, which in Japan and Korea are not just for taking photos but are also being used as input devices — in place of typing — for reading QR codes and other matrix/bar codes, and for applications such as real-time OCR-enabled word translations.

Developers need to familiarize themselves with the characteric hardware features of mobile devices— and work on building applications that exploit them.

Take advantage of increased opportunity for social interaction

A key piece of Web 2.0 is the facilitation of a variety of group behaviors and social interactions that Tim O'Reilly, in his oft-cited “What Is Web 2.0” essay [ORE05] , describes as enabling users to “harness collective intelligence”.

As an example, along with the usual suspects (Wikipedia, Flickr, del.icio.us), he describes the Cloudmark spam-filtering engine (which, by the way, has its origins in an earlier free-sofware product called Vipul's Razor, designed by one of the co-founders of Cloudmark), a system that enables users to share information about spam with another in real time (in a programmatic way, through a distributed spam-database).

Cloudmark is an interesting example in that, unlike most of the applications cited as examples, there is nothing at all flashy about it and it can't come close to providing anything that might be described as a “rich user experience”. In fact it basically lacks a visible UI (and isnt't actually a web application at all). It does its work in a relatively old-fashioned way, using software technology that has been around for a long time. Its true innovation lies in that it provides a way to automatically facilitating a certain class of user-to-user interaction that wasn't taking place previously.

One thing that vendors and developers can all bank on is that as more mobile devices with harware features such as GPS chipsets and Bluetooth get into the hands of more users, it is going to enable whole new classes of user-to-user interaction that have not been taking place previously: everything from location-aware Web-based social networking systems to peer-to-peer “proximity” uses of mobile devices.

Developers should put serious consideration into the opportunities for increased social interactions that powerful mobile devices enable, and build out applications to facilitate those interactions.

Say goodbye to web apps and hello to widgets?

Finally, we come around to a discussion of that most-obvious aspect of Web 2.0: the rich user experience enabled by browser support for AJAX/Javascript.

The short answer to the question “How do AJAX and Javascript relate to mobile web browsing?” is this: AJAX-enabled browsers from the major mobile-browser vendors are available today, now. Web developers who focus on developing for users of the mobile web have already built web applications that make use of those, and will be building a lot more.

So the next question commonly asked is, “How do I take a web application designed for viewing on a PC screen, and for interacting with using a pointing device and cursor, and make is usable on a mobile device.” The short and obvious answer is, you can't. Despite having Javascript and AJAX support, mobile browsers can't let you do drag-and-drop because current mobile handsets do not have pointing devices (that limitation will go eventually, but in the mean time, we're stuck with it). And obviously, if your application requires “windowing” within a browser frame and/or requires mutiple columns, it's not going to be usable on a small screen.

Anyway, that question actually turns out mostly to not be a terrifically interesting or relevant question. A perhaps much-more-interesting question is, “What might Javascript and AJAX be used for other than developing big, heavy, monolithic web apps that mimic (often quite poorly) the behavior of “fat client” applications (e-mail clients, word-processing applications) that users already have on their PCs anyway?”

The answer to that question is, Javascript and AJAX can be used for quite a lot of things other than creating web apps. And at least one person has spent some time thinking about, and writing about, the possibilities: Ajit Jaokar,whose essay “Mobile web 2.0: AJAX for mobile devices — why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development - Part two”, is a must-read for anyone considering development for mobile devices.

Last year at XTech, Daniel F. Zucker, Michimasa Uematsu, and Tomihisa Kamada presented a paper titled “Markup-based SmartPhone User Interface using the Web Browser Engine” [ZUCK05], and other vendors have written and presented information along similar lines.

In a nutshell, what has happened with regard to AJAX and Javascript in mobile devices is that browser vendors have created platforms that enable developers to create rich applications based on HTML, CSS, Javascript, and AJAX support — applications that are powerful but at the same time lightweight by design. Widgets, basically. And it seems quite likely that those applications developed around those platforms will displace some of the applications that have been developed using other technologies (chiefly, Java and BREW applications), and may in fact obviate the need for certain types of web-based apps.

One vendor, Opera Software, has created a platform that enables development of such applications for cross-device PC/mobile use.

Conclusion: Make a science of user engagement

Within “What Is Web 2.0” [ORE05], Tim O'Reilly makes the following comment about Amazon:

Amazon has made a science of user engagement.

That phrase. and the model that provided by Amazon over the years of actively exploring ways to engage with users to the greatest degree possible is something that should be taken to heart by any working on development for the web.

In particular, developers should be working to now on ways to engage mobile users of the web — to find out what kinds of applications they really need, and to deliver to those needs.