Check out the additional posts by Simon Judge and Adam Cohen-Rose.
We're extremely grateful to Kasabi http://www.kasabi.com for sponsoring this event!
I confess I did not know what to expect to hear from the panel last Monday, since the topic of the event was a little confusing to me: what’s the story with “data-driven mobile apps”? Well, I can say I learnt something.
#momolo data driven apps panel chilling before the gig by Thayer18, on Flickr
On the stage, to share their knowledge with me and the rest of the audience, we had (L to R in the above Photo): Matt Biddulph as panel moderator, Ian Holt, to bring the data provider point of view, Hanna Donovan, Legh Dodds from Kasabi and Jeni Tennison, as unofficial voice of the government.
Here some of the interesting issues that they discussed.
A definition of “Data-Driven App”
Every panelist had his/her own definition for a data-driven app, which is funny you think about it, but makes sense as well. Hanna was the more excited about these kind of apps as “they give keys to the universe”, making things easy and helping to sort the confusion of having no information about a topic, or too much information. Sounds too much like the definition of just a good interface? Yes, said Leigh, and since every application makes use of data in one way or another, he noted, the archetypical data-driven app “must provide an insight on data”, that is helping the users to understand more about the data themselves. Matt also pointed out that “proper” data-driven apps get better the more data they receive. Especially for user-generated data, they can drive the addition of new features.
The problem of “API-vomit”
The interesting term was coined by Hanna and immediately adopted by both the panel and the audience. What is it about? Well, developers producing data-driven apps tend to put a huge amount of data on their applications, without first thinking of use-cases and thus making the interface confusing and difficult to understand. An app where data isn’t presented in a consumable way suffers from the “API – vomit” problem. The panel agreed that developers need to work with UI and UX designers, and sometimes with marketing people too, to figure out what’s the right approach to filter the information. Companies who provide APIs to developers could help them by giving feedback and working together to identify the use cases.
API as censorship tool?
Sometimes the data providers themselves try to define the use cases and, to make their API easier to use – and to help developers - restrict their data to those cases. A wise voice from the audience pointed out that the governments especially shouldn’t have to assume what data re-use is needed, to avoid the risk of their API becoming a tool for censorship. The API-vomit must remain a developer/designers problem, and there should be a trend to open as much data as possible.
Data gathering via mobile apps, what level of communication with users?
Developers of data-driven apps often ask their users to agree to share some useful information (from the location to the address book, from the Facebook status to their mobile pictures gallery). Users are warned about the request on a “cold and scary” installation interface and sometimes abort the download in fear of scam and privacy violations. The panel found that devs don’t have ways to explain directly to the users the reasons for requiring access to data, how they will use them and when. The actual rate of this mistrust feeling is still to be measured, but good practice for operators would be to provide space (few lines? links?) in the download screens for developers to explain why they require access and what they will do with the information.
Open data and common licenses
So, assuming that you get your data from your users, crowd sourcing a lot of information, you will probably mix them with data from the public sources available: governments and public entities, private companies, etc. Some content is open, such as the NHS dictionary of medicine and devices, or most timetables for travel services, but sometimes data are under license, creating a bit of a problem for developers that have to use the most restrictive license to the whole data. Leigh noted that the creative common license is not legally recognized in most countries yet, same for open data commons, and the attribution stacking problem is not easily to solve. A good point is that for public data, Jeni noticed, is that you can track their origin and provide it through API too, meaning that if something goes wrong, you can check where and when it went wrong.
... an interesting thought for developer of every kind of apps : when you start a project, don’t forget to ask yourself what’s the best problem that you can have; imagine the best scenario for your product and try to anticipate problems and evolutions, it will be an useful exercise.
The example we learnt from the world of data-driven apps is the following: Last.fm, starting as small tool to share music tastes, was all about indie music and a selection of good content for “music-nerds”. After joining the Xbox platform it went big and then bigger and became a window for the most popular of pop music, leaving the niche audience of its beginning a little disappointed. Too bad (?).
Thanks Valentina - and to close, that video from Gemma: