Deep Plane Thoughts: The Appocalypse

Welcome back to Deep Plane Thoughts.  This week I write this on my way to LA to shoot a Jaime Oliver TV show – I’m the tech monkey who will show him how to use Bing Maps in his "War Room".  Hilarity will ensue.

But back to the matter at hand.  A few months ago I gave a talk on the future of mobile apps.  I was basically arguing that we are rapidly approaching the “Appocalypse” as users are overwhelmed with 300k apps on in their mobile marketplace, no real way to find the one they want when they need it, and a pretty outmoded concept in general that will result in massive user abandonment of all but a few head apps and the entire marketplace for developers – from a financial perspective – will rapidly erode.

My core contention was this: why the hell should I have to install an app to figure out what time the subway comes to the 2ndAve/LES stop in NYC?  Or to know what constellation I’m looking at in the sky?  Or to calculate the tip at a restaurant?  All these ‘applications’ are really nothing more than a query to one or more structured data sources often wrapped in a (crappy) UI.  Think about it: there is nothing as inelegant as me having to say "I wish I could take the subway  to Rockefeller Plaza, so I think I’ll hang out here on the corner in 21 degree weather and search an application marketplace on my teeny little keyboard and small screen using a keyword search from 1994 and hopefully stumble across some piece of code I can download over a congested 3G network and install in my limited local storage that, by the way, will consume battery life as it turns itself on to receive push notifications I don’t need, all so I can figure out if its the F or D line I need to take up north."  Insane.

No, what is more sane is pushing ‘apps’ to search.  Rather than requiring an absolutely explicit indication of intent on the part of the user (I.e. I install an app because I need the train schedule), we do what we’re trying to be good at – implicit intent detection.  When I query for Rockefeller Plaza and I’m sitting at the Thompson LES, a logical intent is travel to/from Rockefeller.  The magic will be in understanding how we can map derived intent into a new lightweight model of ‘apps’ that are really nothing more than a bunch of published interfaces on the web.  Less geeky: imagine a bunch of applications in the cloud that are waiting for a search engine to call on them and ask them for information they might have.  In the above example, this means me querying for subway times from LES to Rockefeller triggers the engine to go ask the most reputable ‘subway app’ in the cloud for that information, getting the information from the app, and displaying in in the SERP.

Lest you think I make stuff up, remember our friend UDDI.  The above isn’t really a wholly new idea.  Some quick history: UDDI (Universal Description Discovery and Integration) was basically a big directory in the sky where web services could register themselves so applications would know which web service they should use if they wanted to, for example, authorize a credit card. UDDI is dead and gone but the idea is still magnificent – indeed, it’s more relevant today than it was in 2000 when it was conceived.  Because now with nearly 500k ‘web services’ disguised as ‘apps’, consumers are more confused than ever about how to do stuff on the web.  Yes, that’s hyperbole and I know there are lots of apps (like my Sonos Controller) which aren’t web services, but you get the idea.

So what do we need to avert the Appocalypse?  A few things:

  • UDDI V.Next: We need the ability for apps to register their interfaces and methods – for those less technical – this means we need applications to publish in a structured format what information they know about, how to ask them about it, and how they will respond back to the asker.  The apps would publish this to a directory in the cloud.
  • Micropayments: Information ain’t free and we shouldn’t expect people to curate information for nothing.  Today I pay $1.99 for an application for the subway schedules.  Moving forward there would be some way to charge the engine or the user for access to the information.  It would be far less – fractions of a cent for much of the information like the subway routing.   I haven’t figured this out, but our folks over in Dallas have.  
    • I have just take a quick aside on Dallas – what a beautiful cloud service.  It’s an information marketplace that supports a limited version of the two above bullets.  It’s more focused on acting like a massive 5TB database than an app broker but that’s 60% of the way there to UDDI v.Next.  And they’ve figured out micropayments. 
  • Persistent login/accounts: so people can micropay for info from apps that search ads won’t cover and to reduce the misfire of apps as systems more carefully tune intent models based on the user.
  • Ratings/Instrumentation: so the system can learn what ‘app’ best for a given query.  We can use ratings for explicit learning, and an evolution of good old machine learning will help systems implicitly understand what apps to fire based on what intent.

The Appocalypse needs to be averted especially as you look at how people are using the web – according to Morgan Stanley by 2013.5, more people will access the interwebs on mobile than on desktop.  Yikes.  (whether you believe that and whether it truly means anything since time spent on each modality isn’t forecast here – that’s another question.)

clip_image001

This isn’t to say there aren’t reasons for applications to exist.  There are plenty of client-side applications with particular UIs, local storage requirements, complex interaction models,  etc that aren’t today possible or desirable in a service-brokered model.  A compass, for example, wouldn’t really work very well.  Evernote – which isn’t about info retrieval but creation and storage – another example.  Tap Tap Revenge that Bing seems to have an unnatural fascination with – heavy client-side code for animation and song storage not dependent on a crappy network – these are ok to be an app.

I also realize what a lame example the subway was since it exists for free today inside some mobile maps app, but I’m about to land and I don’t feel like rewriting a new example.  So use your imagination.

And I also explicitly asked for a GIN and tonic.  Pretty sure I just got tonic.  The horror.  Til next time,

Stefan

5 thoughts on “Deep Plane Thoughts: The Appocalypse

  1. Pingback: Tweets that mention Deep Plane Thoughts: The Appocalypse « Revenge of the Nerd: The Sequel -- Topsy.com

  2. Pingback: what if everything you knew… was wrong? | Hiding in plain sight

  3. I think apps are a refreshing. They use more mainstream programming concepts, so it is easier for developers, they are built on a pay-once economic model, and a small developer such as myself is required to maintain no servers, letting me focus solely on create well designed and well thought-out apps.

  4. Pretty much the next step given the explosion of huge datasets (e.g. infochimps) and services like redis (redis.io). Very good article Stefan, good luck with Jamie Oliver.

  5. The general app experience is really optimized for the *second* time you need to look something up. The first time you might struggle with which app to use and how to use that app, but once you’ve picked your app, downloaded it, configured it and used it a few times, then it’s easy. Often there’s a conflict between ease of *first* use and ease of use for an experienced operator- one difference between, say, MacWrite and “vi”.

    The up-front pain is in finding the right tool for the job, the one that wraps its database queries in an *excellent* UI. This level of pain is minimized if you’re willing to pay a buck or two and you skim the user ratings before you download; it’s maximized if you only buy “free” apps.

    On an iPhone, the app you needed (assuming you have signal) to tell which train to take is the maps application which already on the phone so no download is needed.

    Also recommended: NextStop. Based on a simple database query it gives you a countdown showing how long until the next trains arrive at the stops nearest you (or in some specified location) based on the published schedule.

Leave a comment