Applications have represented a gigantic leap forward in terms of mobile functionality. They have opened up new ways of accessing data, connecting to services, and interacting with people. Why, though, are mobile applications so dumb as to what is going on in the rest of your phone?
The beauty of phones — even feature phones — is how well each service is interconnected. Open an SMS or receive a call, and your phone tells you who it’s from, sourcing the actual name from your phone book. Send an email and your phone will work with a contact book in a Webmail service such as Gmail or Hotmail if one is available. You don’t really have to think.
The relationship with independent service APIs, however, is more fractious. Sending a Facebook message requires opening the Facebook app, which typically has no access to your phone book or vice versa. Check into Foursquare a minute later, and it’s as though the interaction on Facebook never happened. You can find yourself searching for the same contact three times in three different apps, when the person’s name and number have been sitting in your native contact book all along.
Constantly opening and closing applications, a process that’s inherent in using a smartphone, doesn’t exactly make for a flowing user experience or great productivity. Human brains were not designed to constantly switch between different design metaphors and cognitive rules, and working in this way tends to slow down our work rate.
What we really needed is a different kind of solution — one that extends applications using native functionality. Applications are definitely here to stay, but they need to become more vertically integrated into a device. They need to become atoms within the device.
By “atoms,” I mean widgets, essentially, that provide contextually relevant links to service APIs. You may have an atom in the phone book for instance, which provides a contextual link to send a Facebook message right from a contact’s entry in the phone book. This atom wouldn’t provide access to a whole Facebook app, but it would provide the contextual nugget you needed at the time you needed it.
An atom-focused approach would be of real benefit to users. Instead of needing to open and close multiple applications, you could carry out the same tasks through the native functionality of your mobile device. Google has not been shy about providing tight integration with Google Docs, Gmail, Google Calendar, et al into its Android smartphones, so why not integrate with other services as well?
Of course there are business reasons why mobile manufacturers are sensitive to taking the atoms route. It does, of course, mean opening up native functionality to application developers. Give away too much control over the native functionality, the logic goes, and developers will hijack the user experience and platform.
There is no reason why this should be the case. The level of Facebook integration in Motorola, Microsoft and Sony Ericsson devices and the upcoming INQ Cloud Touch could be described as “atomic,” and the user experience remained intact. The new Sony Ericsson Arc has a great user experience and tight Dropbox integration.
Some people of course, will still want the tightly controlled experience of an app. Apps and atoms can coexist (as they do on devices such as the BlackBerry Torch), but to make internet services more valuable, engaging, developers and manufacturers need quite literally to start thinking outside the box. Or better still, blow the box apart and create atoms.
Christian Lindholm is Managing Partner at Fjord, a European service design consultancy. He was previously the Vice President of Global Mobile Products at Yahoo. During his ten years at Nokia, he invented the Navi-key user interface. He contributes to Bloomberg BusinessWeek, VentureBeat and GigaOM and blogs on his own site, christianlindholm.com.