MoMo London – 13th Feb. Round Up – Data Driven Mobile Apps
Posted on: February 20, 2012 – Filed under: London
Many thanks once again to MoMoLo volunteer Valentina Ciolino @MissFog for her write up of last Monday’s event. Thanks also to @GemmaPhelan for her video (below) and to @Thayer (for all her help and the photo below).
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!
Iconfess I did not know what to expect to hear from the panel lastMonday, since the topic of the event was a little confusing to me:what’s the story with “data-driven mobile apps”? Well, I cansay I learnt something.
 |
|
#momolo data driven apps panel chilling before the gig by Thayer18, on Flickr
|
Onthe stage, to share their knowledge with me and the rest of theaudience, we had (L to R in the above Photo): Matt Biddulphas panel moderator, Ian Holt,to bring the data provider point of view, HannaDonovan, LeghDodds from Kasabi and JeniTennison, as unofficial voice of the government.
Heresome of the interesting issues that they discussed.
Adefinition of “Data-Driven App”
Everypanelist had his/her own definition for a data-driven app, which isfunny you think about it, but makes sense as well. Hanna was the moreexcited about these kind of apps as “they give keys to theuniverse”, making things easy and helping to sort the confusion ofhaving no information about a topic, or too much information. Soundstoo much like the definition of just a good interface? Yes, saidLeigh, and since every application makes use of data in one way oranother, he noted, the archetypical data-driven app “must providean insight on data”, that is helping the users to understand moreabout the data themselves. Matt also pointed out that “proper”data-driven apps get better the more data they receive. Especiallyfor user-generated data, they can drive the addition of new features.
Theproblem of “API-vomit”
Theinteresting term was coined by Hanna and immediately adopted by boththe panel and the audience. What is it about? Well, developersproducing data-driven apps tend to put a huge amount of data on theirapplications, without first thinking of use-cases and thus making theinterface confusing and difficult to understand. An app where dataisn’t presented in a consumable way suffers from the “API –vomit” problem. The panel agreed that developers need to work withUI and UX designers, and sometimes with marketing people too, tofigure out what’s the right approach to filter the information.Companies who provide APIs to developers could help them by givingfeedback and working together to identify the use cases.
APIas censorship tool?
Sometimesthe data providers themselves try to define the use cases and, tomake their API easier to use – and to help developers – restricttheir data to those cases. A wise voice from the audience pointed outthat the governments especially shouldn’t have to assume what datare-use is needed, to avoid the risk of their API becoming a tool forcensorship. The API-vomit must remain a developer/designers problem,and there should be a trend to open as much data as possible.
Datagathering via mobile apps, what level of communication with users?
Developersof data-driven apps often ask their users to agree to share someuseful information (from the location to the address book, from theFacebook status to their mobile pictures gallery). Users are warnedabout the request on a “cold and scary” installation interfaceand sometimes abort the download in fear of scam and privacyviolations. The panel found that devs don’t have ways to explaindirectly to the users the reasons for requiring access to data, howthey will use them and when. The actual rate of this mistrust feelingis still to be measured, but good practice for operators would be toprovide space (few lines? links?) in the download screens fordevelopers to explain why they require access and what they will dowith the information.
Opendata and common licenses
So,assuming that you get your data from your users, crowd sourcing a lotof information, you will probably mix them with data from the publicsources available: governments and public entities, privatecompanies, etc. Some content is open, such as the NHSdictionary of medicine and devices, or most timetables for travelservices, but sometimes data are under license, creating a bit of aproblem for developers that have to use the most restrictive licenseto the whole data. Leigh noted that the creativecommon 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 goodpoint is that for public data, Jeni noticed, is that you can tracktheir origin and provide it through API too, meaning that ifsomething goes wrong, you can check where and when it went wrong.
Finally …
… an interesting thought for developer of every kind of apps : when youstart a project, don’t forget to ask yourself what’sthe best problem that you can have;imagine the best scenario for your product and try to anticipateproblems and evolutions, it will be an useful exercise.
Theexample we learnt from the world of data-driven apps is thefollowing: Last.fm, starting as small tool to share music tastes, wasall about indie music and a selection of good content for“music-nerds”. After joining the Xbox platform it went big andthen 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:
