Some of you may be using our Mobile Movie Times application or seen the demos of our various other mobile consumer apps. You may say “that sure looks a lot better than WAP”. Yes, all of our apps are locally executing rich clients optimized for their devices. Many of you may have noticed that most consumer-focused large web properties are pursuing (google, yahoo, ebay) are also not building WAP portals but instead focusing on locally executing optimized apps targeting a particular platform. So why is this? WAP’s been around for years. What’s wrong with it?The big problems with WAP that we see are no ability to execute functionality locally, lack of separation of presentation and data, a murky future standards picture, no ability to work with data offline, and no ability to take advantage of an increasingly diverse set of mobile device capabilities.For the record, there are several applications and use cases where none of these are problems, especially one way delivery of text only information. It may be that in an effort to allow an application to run on as many platforms as possible without rewriting them as native locally executing apps that use of WAP on some devices can be a way to multiply the payoff of investing in building the backend of a mobile application. That said, for most applications the following issues all inhibit WAP from delivering a truly optimal user experience on targeted devices<h3>Executing Logic Locally</h3>
The best applications (mobile, web-based and desktop) all execute some portion of their logic locally. This can be for:

  • validation
  • modifying forms, menus and screen display based on user behavior
  • rapidly showing different data based on user actions and interests without roundtrips to the server

These ideas are behind much of the current trend of Ajax-oriented websites: highly responsive, interactive, adaptive web pages and user interfaces.

WAP sites don’t do this and they don’t have enough of a scripting model to enable these features. AJAX-capable browsers can try to do these things (the pros and cons of mobile Ajax browsers are the subject of another post). But most web and mobile app providers trying to create optimal user experiences are building “native applications” in the APIs of the mobile platform to achieve these benefits.

Separating Presentation and Data

Neither WAP nor traditional HTML pages separate presentation from data. Form controls and their embedded data are tied together in one stream of information. This is why most WAP sites that interact with users are painfully slow. By contrast, optimized native applications run locally on the device and send only the changed data back and forth. It is possible to approximate these benefits with Ajax and other use of Javascript on a mobile browser, but it is inherently more difficult and the data exchange less efficient (again, we’ll talk more about Ajax browsers later).

Future Standards

At one time it seemed like the mobile web industry might come together on some standards based on some derivative of both WAP and XHTML Mobile Profile. That effort ended with major vendors each taking their own tack on the mobile web using divergent subsets of a proposed WAP 2.0 standard. We’ll talk more about that later. But at this point, it is not a controversial statement that WAP 2.0 and XHTML MP are not being used consistently and robustly by major mobile software providers and device manufacturers.

Working with Data Offline

Mobile networks are still not always available with 100% coverage and this is likely to remain true for quite a while. The best mobile applications (such as Blackberry’s email) are optimized for syncing intermittently and transparently and allowing the user to use the application offline. The best usage experience even for “vertical” single purpose apps are written to the native device operating system, making optimal use of available storage, trickle syncing data to and from the server transparently to the user, and allowing the user to be as interactive as possible when not having coverage. WAP browsers (and Ajax browsers) are not capable of this.

Taking Advantage of Device Capabilities

Mobile phones are a diverse lot and, with the emergence of new “more than just voice call” features, becoming moreso by the day. There are several major device operating systems: BREW, Symbian, J2ME, Linux, Windows Mobile to name a few. More importantly phones have an increasingly differentiated set of capabilities: everything from taking pictures to recording voice to playing music to syncing contacts and PIM information to voice dialing to GPS. The best applications take full and optimal advantage each device’s capabilities in all of those areas and more. Browser based applications (of any flavor) just don’t do this. To do this requires writing to the APIs of the device, even when a device uses supposedly “open API” such as JSR extensions to J2ME for specific capabilities.

So How Do We Build Such Optimized Native Apps Efficiently?

All this said, its quite expensive and difficult to write application to these various devices in their native operating systems with their unique APIs in C, C++, or Java. And it becomes moreso once you want to target multiple devices. J2ME offers a variety of devices, but certainly not the majority of the market.

But this hasn’t daunted the the biggest web properties(such as Yahoo and Google) with extremely horizontal apps such as email and maps that can be targeted to many millions of users. The cost of hiring large teams of developers to spend months to years writing apps can pay off in these situations.

But is it possible to write apps at a higher level than the native procedural languages (maybe even higher level than WAP or HTML)? And can we do so and still allow single applications to be executed on a wide variety of other devices? And perhaps even better allow the apps to function at a gracefully degraded level by delivering content WAP and AJAX browsers on platforms and devices that its not economical to devote a lot of attention (while still just “writing them once”, as is referred to in another post here). All this is a topic for another post some time soon.