App Overload is Solvable

Jenna Wortham, while asking an oddly irrelevant question about “app burnout”, actually cites a very interesting point from the CEO of Onavo, an app-data app maker.  Namely that of the 775,000 apps for iOS, fewer than 1,000 have over 50,000 users.  This is unsurprising – I would be willing to guess that the properties follow a standard power-law distribution like Zipf’s Law or a Pareto distribution.  These distributions occur in many fields – the archetypal application of Zipf’s Law is city sizes, and that of Pareto distributions is income.  They are distinguished by a “surprising” amount of concentration at the top, because the distribution is along an exponential rather than linear curve, while people generally think in linear terms.

However, the issue here is that within those 775,000 a lot more should be getting used.  For any given task, for any given user preference there is an ideal app.  Whether it’s a game or productivity app, there is a best way to do whatever you want to do that is currently unused.  Now, there are no shortage of app recommendations engines out there.   That helps, but it isn’t what I actually want.  Sometimes my requests are poorly structured – for example, I was discussing with someone the other day the battle between Seamless and Grubhub.  Seamless is great in New York, but the selection on Grubhub is much better in San Francisco.  I know this because I’ve spent a lot of time living around tech-savvy people in both.  But when I just want to order food, I just want to order food.

There is a huge gap when approaching a task of which the parameters are unclear – e.g., I want to order food in a new city.  It’s even more acute in the case of unusual, uncommon, or totally new tasks.  When I need to figure out the best place to get my car repaired while I’m on the road, current practice has me flipping between Yelp and Angie’s List to find the best providers (depending on which one has better penetration in the area and vertical) and then going to their websites to figure out pricing information.  Which is generally unavailable, but that’s life.

The gap here is the “App Hub”.  What’s the App Hub?  A combination of a search engine, a display engine, and a transactional backend.  The transactional backend is simple enough – your name and CC#, along with other vital information like address.  When you make a transaction through the App Hub, it automatically goes to the app you need, creates you an account or uses its own account as appropriate and places your order without you doing anything.  Maybe that’s ordering you a pizza on Seamless or changing the date of your hotel reservation, or maybe it’s something more automated like finding you the best car repair garage within 5 miles and auto-dialing the number.  The search engine is more complicated – one would launch with a simple menu of tasks like “I want to order food” but the end goal is a natural-language translator for poorly-defined tasks.  No mean feat.  And the display engine is something either pulls data via API or web-scraping and displays it in a standardized and normalized format, with Seamless and Grubhub displayed side-by-side with a uniform system of ranking.

Frighteningly ambitious?  Yup.  But as apps proliferate, app-addressable tasks increase, and human attention stays the same, it will only get more vital.

Tags: , , , , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: