Wednesday, July 20, 2011

The App Interoperability Conundrum


I would argue that mobile computing began the early 20th century with the popularization of wristwatches. The wristwatch, like its ancestral pocket watch, allowed people to know, at any moment, what time it was. Mobile computers advanced significantly in 2007 when Apple introduced the iPhone. This device was not only a mobile communication device but it allowed people know, at any moment, where they are.
But I don’t want to discuss the historical importance of the iPhone, rather the paradigm shift in application design.
For the past twenty years or so, the personal computer (or PC) has dominated homes and offices throughout the world. The vast majority of PCs used some generation of Microsoft’s Windows operating system. Regardless of the criticism that Microsoft stifled innovation, Windows users have enjoyed one unquestioned privilege, interoperability.
Quite unconsciously, a PC user can perform information exchange between applications using operations like copy and paste or drag and drop. Not only can a user exchange information, like text or imagery, between applications like Internet Explorer, Excel and Word but also with third party applications. This interoperability is available because of two factors:
  1. All Windows applications understand the same data and file types, and
  2. Windows provides a built-in framework that software developers can use to enable the inter-application exchange of information.
It is without question that mobile devices will continue to proliferate in the consumer market with improvements in mobile infrastructure, device affordability and cultural acceptance. However I see an uneasy trend in mobile application, that is, mobile applications are becoming increasingly focused but less interoperability.
To illustrate this point, consider the following hypothetical example. I am in downtown Los Angeles, I’m hungry and need nourishment from a reputable establishment. On my iPhone I can use:
  1. Google Maps to find a nearby restaurant,
  2. MapQuest to get voice guided routing directions,
  3. Built-in camera to record my memorable meal,
  4. FourSquare to “check-in” and recommend this restaurant to my friends, and
  5. Yelp to post a review (and snapshot) of my dining experience.
In this workflow, the only interoperable elements were the street address I copied from (1) to (2) and the photo created in (3) and shared with (5).
Obviously this workflow could be optimized by using one app to perform two or more tasks like using Google Map to a find a restaurant and driving directions. But these five apps, in my hypothetical opinion, were the best in each task.
My criticism is not targeted at the number of app used during my lunch break but the lack of interoperability between them. For example:
  1. From Google Map, why is it not possible to send the restaurant address directly to my favorite routing apps?
  2. From the camera app, why is it not possible to share a photo directly with Yelp.
  3. From MapQuest, can I send the “route” to my friends so that they know where I am driving from?
  4. To rate (or “check-in” at) the restaurant with FourSquare and Yelp why did I have to locate the restaurant in each app? Why not just click the “get current establishment” button in each app?
These comments may seem like iPhone-bashing, but they are not. I am just bringing your attention the unintentional stovepiping caused by increasingly focused mobile apps.
To paraphrase Apple’s advertising slogan, there may be an “app for that” but what is lacking is the “app to app” interoperability. Again this is not a criticism of Apple or other mobile device vendors, just a mere observation of the consumer-driven “app paradigm”.
The "app paradigm” does have its advantages. Smaller focused apps with a handful of capabilities can be deployed quickly, updated frequently, serve niches and most importantly, be profitable. Many software developers have made a health living by serving the “long tail” with $0.99 apps.
But I predict that there may be an equilibrium shift in near future in which, due to the lack of app cohesion, that devices will eventually be ruled by a handful of super-apps. The foremost, without doubt, is Google. Google may (or should?) consolidate their shopping, social networking, mapping, translation, book and search services into a single super-app.

2 comments:

  1. I would love to see more app-to-app interoperability. Whenever I visit a restaurant I want to checkin with Foursquare and Facebook. Then I want to send a photo of the meal to MealSnap and Foodspotting.

    Perhaps a solution would be a single app which shares with the appropriate services similar to what Posterous Auto-Post achieves for blog posts.

    Another solution would be to take a page from Do@'s (http://www.doat.com/) strategy and use a super-app to drive a collection of HTML5 apps to achieve interoperability.

    Android's Intents (http://developer.android.com/reference/android/content/Intent.html) are a great approach to app-to-app interoperability for native mobile apps. A lot more flexible than Apple's.

    Used your article as a great overview of the app interoperability problem in my latest post: http://vaughan.io/post/10583410723/google-designers-dont-care-about-640-pixels

    ReplyDelete
  2. @Vaughan. Your article on app screen domination (or lower resolution neglect) is very interesting and completely relevant. And thanks for referencing this post.

    In retrospect, this article may be overly optimistic and perhaps end users are content with app isolation and lack of interoperability.

    It could be that, ultimately, interoperability is achieved not by matured device APIs but by cloud-based services.

    ReplyDelete