Google's Android - Architected for Participation

I'm taken a bit by surprise that, a day after the release of Google's Android SDK, the blogosphere is relatively silent about the entire affair. After all, isn't this the much hyped game changing gPhone that every gadget blog has waxing for at least a year? By contrast, Apple's iPhone on the events when it was announced, released and even subsequently hacked had at least a hundred times more commentary. Is Google's gPhone a bust even before hardware is delivered to the masses? Is Symbian's CEO right that it's just yet another Linux platform? Should we all yawn in unison with Scoble?

See, the PR problem with Andriod is that a SDK is only something a developer could love. The gadget fans aren't interested in something you can only experience through a simulation (note: the handsets do exists and UI experience has been tuned with actual use). Technical non-developers only see this as yet another mobile Linux play along the lines of Nokia's Maemo, and OpenMoko. Could Google with all its smarts and after a couple years in stealth development released something bordering on average?

I think the real issue here is that the Android platform is too different conceptually for most technologists to get a firm grasp. People require good mental models to understand things and the kind that Android is latching on appears to appeal to only the developer mindset. Even worse, many developers don't instantly recognize the problems that Andriod is attempting to solve in the mobile space. The mobile environment is complex primarily due to social and political factors, software development is equally complex but on a somewhat orthogonal dimension. When we enter the world that intersects these two worlds and we definitely find ourselves in a hole that takes a lot of work to dig out off.

Google's Android tackles head on the primary hurdle of mobile development, that is, the fragmented nature of the mobile space. It addresses the problems from several different layers. One layer is the complex licensing requirements for mobile operating systems. How much work does a developer need to do to get either Symbian on his device, license J2ME on top of that and acquire something like a DivX recorder/player. It's work only the device manufacturers aspire to do. Open sourcing the product removes these contractual complexities out of the equation.

Most device/hardware manufacturers simply lack capability of developing quality software. Take a look at Nokia, the world's largest mobile handset vendor with a market cap equaling that of Apple. One would think that they wouldn't be starved of competent software practitioners. Unfortunately, Nokia applications that run on a personal computers to support their handsets are simply horrific. Don't even look at their developers tools!

One would however think that Nokia understood mobile interfaces well, unfortunately it boogles my mind how difficult it is for me to enter into a conference call without the ability to consult the invitation for a pass code. Behavior like this, that requires several information sources to complete, are extremely annoying on a Symbian phone. An intelligently designed interface, with corresponding framework support, bridges the competence gap for many device manufacturers.

There's also the issue of granularity of the software applications that are deployed on a phone. Symbian and J2ME based applications lack the kind of fine grain control one would need for a phone. For example, it becomes excruciating when every application has its own way method of entering information. Shouldn't all applications do URL entry or address entry in the same way? Shouldn't applications be usable together to accomplish a task. The mental model that jumps to mind is that of Java versus Javascript on the web browser. Javascript won simply because it had finer control and was intertwined with the browser's capability. That deep integration allowed one to fine tune the user experience. This capability was out of reach of Java applets because it was based more on a desktop metaphor. (see: "What Javascript did that Java did not" ) The desktop metaphor is based on the idea of independent isolated applications. A mobile framework, that is deeply intertwined with a phone's capabilities, is the key to improved usability.

Finally, there's the issue of the limited screen space of a mobile device. Actually, the more devices I've experienced the more similar the UI constraints. It's not only the screen real estate, but the limited input control and casual nature of devices like TV set top boxes and multimedia devices that constrain interaction. Unfortunately, only the few like Apple have done it a way that isn't annoying.

The problem however goes beyond how to make one single seamless experience. Considering the unbounded uses of a mobile phone, we need to understand how to make many experiences work seamlessly together. Apple's iPhone despite it's multi touch innovation still feels like a collection of isolated independent applications that never seem to interact with each other. Arguing that Apple has actually understood mobile interface design may be farthest from the truth. The capability of applications to operate within a framework of cooperation, to perform a user's task, is essential.

The best software analogy I can make about Android is that it's the Eclipse framework for the mobile space. The Eclipse framework one can argue was the first framework that was emphasized the pluggable development of third party tools. The framework from the very beginning incorporated IDE support for developing plugins, it included built-in installation capabilities, UI mechanisms to manage the proliferation of plugins and a well defined framework for contributing additional plugins. It is no coincidence that Andriod is delivered with an Eclipse plugin. The lessons learned from Eclipse are evident not only in the overall platform strategy but in the many of the code snippets itself. Andriod draws inspiration from other architectures of participation.

In summary, Android follows that path of many of the successful open source projects. That is, architect the solution for participation and the developers will not only come but will play well together. This is in stark contrast with Apple where such an architecture of participation is clearly an afterthought (i.e. objective-c and absense of security ).