10 Comments

Summary:

Applications represent 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?

Diagram of atoms

Diagram of atomsApplications 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.

Image courtesy of Flickr user Sarah G…

  1. You actually mean components. Like Windows has had for over 20 years. The way you could insert a visio diagram into Word, for example (that was a special type of component model called OLE).

    Share
  2. I get the concept (not unique) but I don’t get why it’s called atoms or atomic. “Atomic” has a specific meaning in, for example, database design. This is nothing related. Perhaps another term would be better suited. As indicated by Joe, “components” might be closer to it.

    Share
  3. Android intents go a long way towards solving this problem – apps can register intents so you can send files to them from other apps (usually by choosing the Share option). In other cases, you can set a default app for a certain action (like sending an email), or choose from a different app each time.

    Share
  4. I’m surprised WebOS wasn’t brought up as an example, it has integrated many of the stovepipes you speak of.

    Share
  5. The motorola attrix got a jump on this methodology of interconnectivity between app and native. It tries to matchup your accounts socially and I think they/you are definitely on the right track.

    Share
  6. Mike Kaufmann Wednesday, May 11, 2011

    Contextually! Is that a realword?

    Share
  7. Shyam Subramanyan Wednesday, May 11, 2011

    Terminology aside, this would be a good way to integrate apps seamlessly into the phone. Short of this, a Mac OS X Automator like toolkit could be helpful in integrating apps without losing control of the UX.

    Share
  8. I think this is a great idea, but I don’t see the phone providers liking it, since it will give up a lot of their control. In the U.S., we cannot even choose a phone and a service on our own. Until that changes, I don’t see this type of connection happening for us in this country.

    Share
  9. Considerable parts of what you describe are already implemented in Android.
    For example, I often want to upload files to my Dropbox, photos I’ve taken, maybe an attachment I downloaded. I don’t have to open my Dropbox app for that – the option is right there via the ‘share’ menu on practically every app where it makes sense.
    The framework is there for more complex scenarios as well – app developers simply need to use it (and some indeed do).

    Share
  10. Nokia NFC APIs are now available to all developers in an open beta program. These APIs support sharing content by tapping phones together, linking phones or accessories and reading/writing tags.
    http://blogs.forum.nokia.com/blog/nokia-developer-news/2011/05/04/nokia-nfc-apis-now-available
    If you have been thinking about enhancing your apps with NFC, now is the time to bring your vision to life. Developers can create applications that leverage NFC technology using APIs provided in Qt, Java ME, and Symbian C++. Of these options, using Qt is the recommended approach as it’s the core development framework for Symbian and is available for MeeGo powered devices as well.

    Share

Comments have been disabled for this post