We’ve been doing some thinking in the past few months about categories of “apps” – whether those deployed onto devices, or web apps sitting in a browser. It’s extended out of the conversations about “when to app” that I started last year, and attempts to put together a schema for categorising apps that can help us to help developers understand where our products and services can help.
(As an aside, I fear that my years of doing data modelling have probably scarred me, and finding ways to categorise things is that scar…)
First of all there are apps that are a means to an end in themselves. Games would be an obvious example here, but also pure-app content services like Spotify would fall into this category. These types of apps could be built by an individual, or by a small team – but are as likely these days to come out of an agency or significantly sized-venture (games studios by way of example).
Next up are apps that allow content to be accessed when mobile (usually to overcome interruption of network connection or to aggregate from multiple sources). Spotify is an example of cross-over with the first category. Tools like TweetDeck use 3rd-party social network data sources, and The Guardian app allows caching of their own content onto mobile devices. BA.com allows access to flight schedule information and boarding information whilst on the go.
Finally, service-enabling apps give access to transactional services as opposed to “just” content. The BA app allows for transactions such as check-in and upgrades and the London cab firm Addison Lee’s app allows you to book a taxi. These apps give access to services that exist in the world outside of the app (compared with say Spotify, which as a service only exists in the world of Apps).
This model seems to form a kind of continuum – at the left hand side, it’s more likely that developers will be looking to monetise their apps from either selling it directly and/or through in-app advertising (if, indeed, they are trying to monetise the app at all). At the right hand side, it’s more likely that any money to be made will come through selling through the application – either in terms of content delivered via the app, or through selling things via it (cab rides, plane tickets, or whatever else).
Understanding an app in this kind of abstracted way I think will help us to be able to more effectively express to developers how to use our platforms as different core functions will be required depending on what an app is trying to do at this kind of macro level. There is a second model that I’ve been working on that describes underlying app business models which I will run through in a few days time, but in the meantime I’d welcome any feedback…