Dan’s Blog (2.0)

Since upgrading my iPhone to the 2.0 software, I’ve dived into Apple’s app store and I’ve been making a point of trying out apps from across the store but focusing on content creation tools (such as the excellent Wordpress app which I’m using to write this post). At the same time, I’ve continued to make use of all the great iphone webapps and mobile Web sites I’ve come to know and love. Increasingly, across many platforms (not just iPhone) application developers and content providers will  face this choice: to build a webapp or to build a native app. There are advantages to both approaches, and some work that’s just getting started that I believe will significantly change the face of mobile development over the next 2 years.

The rush of content and application developers to develop iPhone apps has been impressive and somewhat predictable. The app store is the next big thing. Google, Microsoft and others are now jumping on the bandwagon (probably much to the dismay of the folks at Handango who can rightly claim they’ve been doing an app store since before app stores were cool). Many of the apps in the Apple app store are really good and could not (currently) be written as web apps because they either take advantage of device capabilities (such a location) or because they need direct access to graphics or sound capabilities (3D gaming) not available to the browser engine. However – discounting this need to access the platform functions, there’s nothing about, say, the iPhone Facebook App that couldn’t be written as a webapp. Indeed, if you visit iphone.facebook.com, you get a webapp version that gives you more features, has better usability (in my opinion) and benefits from more frequent updates (but does not, for instance, give you access to the camera so you can automatically take pictures and upload them to your profile, because the browser doesn’t have access to the camera API). Hahlo is another good example of a Webapp that currently beats out all the native application options as a Twitter client (except for its lack of access to the address book, camera, or location). This is the crux: it’s easier to build, update and maintain a webapp than an app (for cases such as the Facebook offering) but native apps give you access to platform features (and other capabilities such as local storage) that webapps can’t.

Enter a new class of webapp: a mobile browser based application. These applications are built using Web technologies (the so-called Ajax platform), can either be deployed as a standard Web application or as a “widget,” and can advantage of platform functions through some ingenous software layers currently being built. Google’s Gears Mobile, Nokia’s Web Runtime platform and upcoming versions of Opera Mobile all are making a start of it, but right now these efforts are all highly fragmented and incompatible. The OMTP, through its BONDI initiative, is attempging to bring some focus to this area, by coming up with a common set of industry requirements for enabling secure access to platform APIs and then driving some work forward in W3C’s Web Applications working group to help to make this an industry standard.

I was interested to read that in all the discussion of the iPhone app store, Apple has also quietly made it easier to write webapps and to surface these webapps to the user as if they were native apps. Essentially, the “web clipping” mechanism allows you to put an icon on your screen to represent a webapp, and with the release of the latest firmware, it is now possible to launch these webapps without the normally associated “browser chrome” (which mirrors the approach Apple has taken with it’s latest beta of Safari on desktop). This approach further blurs the lines between webapp and native app.

In the short term, it means more confusing choices for application developers. But in the long term, at least for an increasingly large class of application (for example, social applications or any app that doesn’t require direct access to platform features like 3D accelerated graphics), it’s clear that the Web will prevail.

Filed by Daniel Appelquist at 15:00 under London, Mobile Web
Tags: Ajax, BONDI, iPhone, Mobile Web, Opera, W3C

11 Comments

Zipiko Screenshot

I’ve recently been trying out Zipiko, a very simple but powerful social tool for organizing events and ad-hoc get-togethers. Zipiko has a really good mobile Web UI through which you can develop your network by inviting friends to events via their phone numbers. Your friends get an SMS which they can respond to with a simple “YES” or “NO” to let you know if they’re coming or not. Unlike some mobile Web apps comming onto the market, Zipiko seems to realize that not everyone lives in the United States and has thankfully enabled international phone numbers – thanks!

Zipiko is an example of a really great mobile Web app: it’s simple, it’s well designed, it’s well suited to the mobile use case and it integrates well with text messaging. Unfortunately it does NOT work well with low-spec browsers. I tested it on iPhone and on Windows Mobile (mobile IE) where it seemed to work well. On Blackberry (my “low bar” for mobile browsers) it was a disaster.

But what really struck me was how much better Zipiko could be if had access to device capabilities and information stored in your device. Instead of asking me to type in the phone numbers of my friends, it could simply look them up in my address book. Instead of asking me where I am, it could look up my location. It could automatically syncronize events with my device’s calendar. This is a comon theme, particularly for social web apps.

This access to device capabilities from the browser or “web runtime” environment is what I’m working on this week, in Austin at meetings of an initiative called BONDI. BONDI is attempting to drive standardization of these APIs and the security model around their use (you wouldn’t want just any Web app poking into your address book or locating you). This was also a real topic of interest for the Mobile Widget Camp which I helped to run on Sunday in collaboration with Enrique Ortiz and the Austin Technologi Incubator. More on that in a follow-up post.

After trying out Zipiko, I’m more convinced than ever that the industry needs interoperable mobile web apps and widgets that can access device capabilities.

Filed by Daniel Appelquist at 18:04 under Mobile Web
Tags: BONDI, MobileWeb, zipiko

3 Comments