Ajit Jaokar is the founder of the London based publishing and research company futuretext (
The Gmail of the species
By Dr Paddy Byers
Recently Mike Rowehl compared a number of email apps and Gmail came out on top, even when put alongside native built-in applications. The applications compared were the Gmail (Java ME) client, Flurry (Java ME client) and the native Nokia email client on the E61. There was also passing reference to the Blackberry email system. The cited advantages of the Gmail system include connection speed and latency, usability, stability and configuration simplicity.
There’s a bigger message here and it stems from the fact that Mike’s evaluation wasn’t comparing like with like – because it was comparing the native email application with Gmail and Flurry, which are services.
What do I mean by this?
The difference is that an email application is designed to interface (via standardised protocols) to an email service provided by someone else (ie the ISP or operator). The standards concerned are, of course, SMTP, POP and IMAP, relevant encodings, and so on. The Gmail client, on the other hand, is only one aspect of an end-to-end offering from Gmail, which includes all of the back-end infrastructure. The Blackberry – which also provides a superlative mobile email experience – is also part of a service offering rather than just being a device.
What is it about services that results in a superior user experience?
Here are a couple of issues that immediately come to mind.
Firstly, there are different technical constraints. The applications are constrained in that the interface they must conform to is outside of their control. It is well known the POP is totally ill-suited to the requirements of a mobile service, whereas IMAP is complex and heavyweight, and designed to handle hierarchical folder-based repositories rather than tagged archives. The designers of the Gmail system, on the other hand, were not constrained by these standards; they have the freedom to place functionality on the server side or client side as best fits their needs, and optimise as appropriate.
These technical differences are clearly illustrated by the superiority of attachment handling by Gmail as compared with the native app. The service designers have the opportunity to transcode mail attachments to a format the client understands, to optimise the content for the screen and form factor, and to stream the content so it doesn’t all need to be transferred to the device before it can be viewed.
Second, there are different commercial imperatives. The service providers only make money if they build subscriptions and traffic; so they are incentivised quite differently to optimise their solution for simplicity, usability, efficiency, and overall effectiveness. Application providers, on the other hand, don’t have access to an income stream from service delivery and have to prioritise features quite differently. They will also often compete with one another on features – and might even add features that degrade the user experience by cluttering the UI – and other parameters that are less directly relevant to the end user.
So I think the conclusions Mike draws are not related at all to native vs java execution environments per se, but a reflection of a fundamental difference in nature between application development and service provision. Unless someone takes a service provision perspective there’s nobody to ensure the end-to-end system works flawlessly and, more important, there’s nobody working to meet the end users’ real needs.
This makes a couple of other recent developments particularly concerning.
We heard about Google being frustrated in its deployment of Google apps and Mike Rowehl’s other recent observation, in which certain operators are acting deliberately to impede third party service providers.
On the one hand these operators promote platform openness by fostering Java ME and other application platforms, but they don’t provide the ecosystem, infrastructure and commercial hooks to allow service providers to make their offerings effective.
The operators clearly have a legitimate role in the overall value chain; but they have to recognise that it is a two-way street and that the third party service provider also has a role. The service provider, more than anything, is the playmaker; that is, the service innovator and business innovator, and often also the technical innovator. Application (and other technology) providers play their part, but their role is always subsidiary to the service provider. I’ve commented before on the weak position of technology providers that are not part of a service provision business model.
So, to the picture.
We’ve previously thought of the “walled garden” as being one where the user is confined to a particular space and can’t get out; but the problem we’re talking about here is the one where the service provider can’t get in. In our open garden, the service provider is the garden designer and horticulturist, who will be creative in order to captivate his audience. He doesn’t just hand over his wares at the gate. These open gardens will be enabled not just by openness in platform technology, but openness of ecosystem for service providers.
Where do the applications come in? Well, the applications are like the individual plants – they might be beautiful and complex as creations in their own right, but ultimately they are just the vehicle by which the designers’ vision is expressed.
