By Dr Paddy Byers
I’m putting more and more of my personal information and life into the hands of web providers. It’s been a gradual and unsystematic process, partly triggered by becoming detached from corporate infrastructure, and partly stimulated by the arrival of new (and free) web services that make it worthwhile. So, the most recent target was the ridiculous mess of address books and odd bits of paper that constituted our domestic contacts database.
Rather than turn again to Google I decided to try something new and opened a BigContacts database. This is a very new, beta stage service, which provides a 500-entry database for free, has a nice ajaxy web front end and, as it happens, also has a mobile (XHTML) web client.
Now, when I decided to migrate to the web-based service, it didn’t really occur to me that I might want to access the data from my mobile. However, now the data is there and mobile access is possible, I find that the mobile service is convenient and – I suspect – it will become such a matter of routine that I’ll wonder how I managed without it.
So, a few thoughts about this experience and how it relates to mobile web apps in general.
First, on the relative merits of a web application as compared to a resident application.
We’ve been through most of these issues many times on this blog. Remember that this data belongs to the family and not to an individual, and therefore having it reside on a personal machine (my laptop, for example) doesn’t make sense. We don’t have a single “family” PC, but a number of personal PCs and a business Mac. A web-based app happens to be a much better fit for this situation.
The other well-known issue is the lack of a user install cycle – each day the service can be improved without me having to upgrade any software. For a contacts application, the reality is that the functionality of the archetypal PC app was fixed 5 years ago by Outlook, and issues with installed base, file compatibility, simultaneous migration of multiple clients etc mean that the core functionality can only now evolve very slowly, if at all.
So, do these benefits transfer to the mobile version? Obviously the conventional approach on the mobile is to have the contacts data resident, and synchronised to the phone periodically. But what if my contacts app represents data in a way that’s not compatible with my phone’s database? (It does, in this case, because there is useful added functionality that can’t be supported by the phone’s simpler schema.) What if I don’t want that dataset taking up space permanently on my phone when I only access it occasionally?
Of course there are also all of the counter-arguments in favour of resident apps. By my main point here is that none of this was done just in order to make a phone application. Rather, all of these benefits are incidental, in that a great mobile service was created as a by-product of the creation of a web-based app for the desktop.
So, this is more of a “long tail” application (on mobile at least), which is made possible on the mobile web by virtue of the small incremental cost of development.
Second, on the integration of web applications and the technologies that will enable it.
If you track the development of desktop personal information apps (ie contacts, calendar, agenda, todo, email), they have been required to share more and more of their data as functionality is added (eg email addressees and contacts, calendar events and contacts, todo deadlines, etc). All eventually reach the point, as has happened with Outlook, where each is just a facet of a single, integrated and monolithic application. The data interchange needs mean that the functionality becomes merged.
So, does the same thing apply to my web contacts application? How can it provide sufficient functionality as a standalone app? Shouldn’t I use an application from a provider that also has web calendar, mail and other relevant apps? Or is there something different about how web apps are constructed that separately provided apps can be interoperable without becoming inseparable?
Certainly I’d prefer to be in the situation of being able to choose applications on their individual merits, or how well their functionality meets my particular requirements. Secondly, even if I get a set of apps from a single provider, there will always be a boundary between that suite of apps and the rest of the universe – and I will often want those apps to work with other apps whose functionality is not in the suite. Suppose I want my data to link to a social networking app, or a bookmarking app, or I want to get directions to their address?
It’s true that no applications will interoperate unless explicitly designed to do so. But we’re seeing a set of technologies emerge on the web that fundamentally enable integration of services from multiple providers in way that was previously never feasible or commercially viable. Moreover, the web ecosystem is positively encouraging the use of these and their associated architectural principles in a way that never happened before. For example, separation of presentation, data, and functionality via distribution-transparent web interfaces; the use semantic data interchange formats such as microformats; the use of federated ID management through OpenID. (Forget the fact that the screen is small and communication is slow; what’s the biggest usability problem with many (otherwise great) mobile webservices? It’s logging on. OpenID can solve that but also ensure that access can be revoked if the phone is stolen.)
I keep coming back to what Chris Hoffman (Minimo) said when he described the Minimo Google maps derivative site. (I described the approach here – it is a dedicated mobile site that uses the Google Maps API to provide its implementation.) I realise it’s not quite on-message for the “one web” crowd, but it tells you that there’s something very powerful about the API interface when this is the most effective way of creating a mobile experience with essentially the same look and feel and identical functionality to the regular site.
So, for me, my address database another accidental success for the mobile web. It’s also a pointer to the technologies that will enable us to do serious business using the infrastructure out there. So, the photo: the cloud is the new virtual machine coming to mobile.