Archive for March, 2007

mobile Ajax

Posted in mobile platforms on March 12, 2007 by Adam
I’ve gotten a lot of response to my posting on WAP. The predominant theme has not actually been defending WAP in any way. But instead has been “ok but what about mobile Ajax?”. Mobile Ajax, of the type capable by browsers such as Opera and Good Technology’s Good Mobile Intranet provides several of the capabilities missing in WAP apps. Specifically it will allow for executing logic locally, such as rich validation and dynamic forms. It also provides some separation of presentation and data in the ability to download data asynchronously without browser roundtrips.While Mobile Ajax is a big step forward over WAP and provides a much better user experience. It still has several limitations:

Working with Data Offline

Mobile Ajax-based applications do not allow for working with data offline. Native apps can be installed locally and run locally while completely disconnected. Inevitably some platform vendors will try to resolve this with proprietary extensions, similar to AvantGo’s “mobile offline browsing” that they’ve been trying to get adoption of for years. This may work for information feeds (the sweet spot for products like AvantGo). I don’t see it working for transactional applications or websites. Or any apps or web pages with user interaction (which should be a hallmark of web 2.0 properties right?). By contrast, intelligently design natively executing applications handle these offline scenarios quite nicely.

Taking Advantage of Device Capabilities

Browsers, including Ajax browsers, are all about making devices seem the same. On desktops, distinguished for the most part only by differences in screen resolution, this assumption has become more and more true. Mobile devices however are extremely heterogeneous: a dizzying array of screen resolutions, input and directional keys and widgets, and differing sound and video capabilities built into the hardware. That diversity is only increasing. To truly take advantage of a device’s native capabilities in any of these areas, a native application written to the device OS’s native APIs is necessary.

Industry Recognition

These are not observations unique to us. Large web properties such as Google and Yahoo are aggressively putting out native mobile applications for accessing horizontal consumer services such as maps or email. They are doing this with J2ME apps, Palm OS apps (despite the dubious future of the Palm OS) and even, horrors, Windows Mobile. This despite their status as highly competent web Ajax sites, who would presumably be in a great position to build mobile Ajax sites for these services.

Difficulty of Development

The problem with doing native applications is the difficulty and time to do it well. Beyond the diversity of device operating systems (J2ME, Windows Mobile, BREW, Symbian, Palm, RIM), there’s just the inherent step function of writing an actual application in procedural code (and many flavors of them) versus the convenience of maintaining a server-side web application.

The effort in “going native” pays off for truly massively horizontal applications such as email and maps. However, if you go beyond the top dozen or so web applications, to those with less than tens of millions of users, the effort necessary to build a mobile equivalent becomes more difficult to justify. Especially as those web properties or connected applications become more and more about user interaction or transactions.

Does this mean that Mobile Ajax will become predominant in those situations (for those sites or applications that can’t afford to “go native”)? I don’t think so. Most sites are still not aggressively using Ajax. Its just much more work to do so across a diversity of site functions, than to build more ordinary web pages. And once you do so, that mobile Ajax site is still of limited use since it can’t be used offline and is not necessarily taking advantage of unique device capabilities.

A Better Way?

So what are we, Mobio, doing? As you can guess, we build mobile applications that do run natively on mobile devices. As you will see from our forthcoming applications, we do manage to do them across many devices, with applications that are not as broadly applicable as email or maps.

We can and will take advantage of mobile Ajax browsers in the future on platforms that we may not choose to target directly. As mentioned you can create attractive applications with mobile Ajax, but it will be missing some of the offline and device-specific capabilities available with native applications.

However in either of these cases we do our authoring and application development in a way that manages to abstract us from much of the drudgery of creating device and OS optimized native applications, and even allows generation of mobile Ajax apps from the same source code. The way that we do this is the subject of future posts.

Advertisements

mobile 2.0

Posted in mobile platforms on March 7, 2007 by Adam
Following up on my previous post on how we believe the best mobile apps are built , I’ve been asked what the somewhat nebulous term “mobile 2.0” means to me. From a technology perspective I would summarize it as the following things:

  • locally executing applications that work to some level even when disconnected and thus have…
  • locally cached data
  • leveraging relevant open standards where possible. for example be opportunistic about the presence of Opera, Minimo, IE, Nokia on peoples devices
  • controls that are optimized for the capabilities of a particular device and the unique functionality required by mobile apps. there is a natural tension between this goal and the previous point of just using a browser

From a user experience perspective I would suggest that it is the following three things:

  • “context and user aware applications”: delivering the app to users with knowledge of their preferences, their previous uses, their defaults and their likely current actions, to accelerate their tasks and put them into the right form/page/screen/action without a lot of navigation
  • “shared knowledge among applications” – in order to ease the previous goal of minimizing user data entry and navigation on mobile devices, applications should share information about user profiles, preferences, authentication, past usage and defaults. in this context its worth the extra effort to perform this integration
  • user interaction and content contribution – this is probably the only point that truly echoes web 2.0. mobile 2.0 apps should incorporate user feedback and results in intelligently rapid ways

From a business perspective the following trends will drive massive user adoption and make mobile applications tools that everyone uses

  • low to no cost through an advertising and transaction revenue model – users shouldn’t have to pay for services
  • cheap to free data plans – this still has to happen and may be the biggest barrier to entry
  • tools and platforms to make the nontrivial technology and user experiences described above happen for many applications and content in as cost effective and rapid way as it did for the web