Automation, Interoperability, and the Future of MobileBy Collin Fletcher | August 28, 2013 | Mobile News

  • In mobile development, there’s a general metric to go by: does the hardware or software decrease our interaction with the device as much as possible? Good intuitive design should be unobtrusive, thus emoting clarity in function and limiting the amount of fiddling with the device.

    “Get in, get out, get on with your day,” is one way of seeing it. Or another is the idea that technology should better areas of life, not so much replace them.

    Nowadays, interoperability on mobile apps is an architecture meant to cut out the steps of launching an app and preparing it for its task. On iOS, an example of this could be Agile Tortoise’s app Drafts. By both the name and a first glance, Drafts might appear as just another note-taking app. But what you do with the note is what makes it powerful. The app takes full advantage of iOS’s URL-scheme architecture to centralize text input-based apps, launch an app, then apply the text.

    With a little creative thinking, the possibilities are (almost) endless. For instance, in Drafts I’ll type the snippet “See Europa Report on Monday at 2 pm at Valley Art calendar To-do”, then hit the ‘Parse in Fantastical’ button, and the app then opens with the calendar event being entered. That’s the simplest way someone can use Drafts. There’s an entire subculture of users pushing the limits on URL-scheme automation and Drafts for iOS.

    On Android, Google Now performs a similar function, but takes it a step further. Centralizing apps and automating input is there, but Now also uses device awareness to guesstimate your next step. If Google reads a flight confirmation in an email, Now stores the check-in ticket, marks your calendar for the flight, then displays the ticket once it’s detected your location being at the airport. All this without the user lifting a finger.

    Cutting out the manual user operations – as both examples do – makes these apps feel like magic to the average user. But as any attempt to leave a human out of a manual operation, there’s a lot of room for things to break. And in both these cases, things do. A lot. It’s not so much the fault of Agile Tortoise or Google, it’s the fault of today’s technology limitations. Drafts is a friendly iOS hack. The operating system wasn’t built for something like Drafts, but Drafts uses what it has available to do powerful things. Now very well may be the future of Android, but it’ll take an entire app ecosystem to recognize and innovate according to that vision.

    So my plea is this: app developers, device makers and even users; let’s all think about each other. Sure it sounds very kum bay ah, but if all players in the mobile space develop with each other in mind, perhaps the end user experience will turn out better. Hardware manufacturers should make devices that can handle the processing and input necessary for a bigger context (wearables anyone?). Designers of future operating systems should build the architecture to support better communication amongst apps. And developers, big and small, should find ways to build upon each other symbiotically.

    I lied when I gave the metric for mobile development. If there were one, I’m not sure decreasing user interaction is the halo. But automation is why we invent. And invention is how we progress. From walking, to riding a horse, to the buggy, the train, the automobile, and onward – the core of technology resides in this kind of process. And for mobile computing, I’d say automation is the big next step.