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.
Finally ...
... 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:
