What makes a good news app? Thoughts from a media hackathon

As I write this from Russmedia Digital, Austria, several small teams of news innovators have just under four hours to finalise prototypes and presentations of entirely new storytelling tools, applications and data journalism around the topic and data of international migrations. The picture is one of intense concentration and it's been that way since we arrived some time before nine o'clock.

It is a scene familiar to anyone who's been involved in a hackathon. The GEN Editor's Lab in Austria is the third Editor's Lab in the series and takes place at Russmedia Digital's headquarters. They're one of the most prominent and innovative regional press group, and gathered here are eleven teams representing the top tier of German-speaking news media outlets.

As part of the jury that will decide on a winner today, I decided to come up with a short, general set of criteria by which one might consider the efforts of journalistic hackathon teams. In this instance, the final selection of the winning team is to be done on the originality of the idea (rather than a 'finished' prototype) but, in general, I wanted to ask what makes for a good news app?

Of course, I'm no expert. I'm not even a journalist, designer or programmer by trade (though I spend the majority of my days finding ways to help these groups to work more efficiently with one another). So, I reached out to our team, some of whom have been working on our projects since 1999, and asked them what lessons have we learnt from over a decade of building news apps. By no means an exhaustive list, the following is a condensed simplification of the many replies and ideas I received. In general I suppose that most of this relates to the building of larger tools, rather than the specific narrative, storytelling apps we may see here at the Editor's Lab, but here goes...

1) Think data.

Overwhelmingly, this was the first thing most of our team mentioned. By data here, we're not so much talking about visualisations and graphics for readers to consume, but really the practice of moving information around in the newsroom. We've learned (often the hard way) that it's never to early to think about APIs, and that the export/import paradigm should always at the heart of your code. This is about scalability, about interoperability with other systems and connecting you to commercial opportunities. It's why Superdesk is really an API-driven framework more than a CMS 3.0. We're working towards futureproofing media.

2) Create once, publish everywhere.

Again, this is a crucial concept to bring in at the blueprinting stage. Where are my audiences? What devices are they using to engage with my content? What devices will they use in five years to engage with my content? If you can standardise content production in such a way that content creation is done once, and then your technology is able to repackage, scale and adapt that content for new outputs, you're on to winning efficiency savings. If you want to turn your newspaper into a radio station overnight, how can you reuse your print content on the radio? If you want to reach more people, you're going to have to broadcast through new channels.

3) Define your users. Listen to them.

At every part of the design stage we try to bring content creators (journalists, educators, broadcasters) into the process. But the first step is to ask who is this app for? We've had issues in the past where we've tried to build tools or features that are all things to all people. It doesn't work. You'll end up alienating both entry-level and advanced users with a toolset that has a steep learning curve, but doesn't possess rich enough features for enterprise use. Oh, and don't talk to your users. Listen to them.

4) Design for scale.

We've hit the refactoring wall on a few occasions. Refactoring per se is not always a bad thing, but you save yourself a lot more time in the long run if you build for scale. This applies to all aspects of your tool. Scaling server infrastructure, plugin architecture but also user growth must all be enabled. The last thing you want is your audience outgrowing your tool.

5) Localize early, localize often.

We try to develop our software so that every user can interact with the software in their own language and alphabet (we even tricked MySQL to accept Unicode even before it knew what Unicode was). Recently we released versions of Booktype and Airtime that allow for user localizations. This development took longer than we had hoped because we did not build it in from day one (edit: Booktype did, my mistake!). Newscoop however, around since 1999, had a localization framework from the beginning and has ensured that global deployment and adoption is much easier.

6) Less features, more speed.

Keep. It. Simple.

7) Fail. Fail quicker.

Naturally, no-one wants to admit they have a culture of failure at their organisation. However, it's vital to recognise the value of things that don't work. We've had many things that just haven't worked. We still do, every day. Our forums are full of bug alerts, frustrated users and feature requests - this for us is a great thing. Every one of these is a chance to improve and the frustration our community expresses is a positive sign. It means people care about our projects and they want them to succeed. By listening to these users, accepting failure and working with them to improve things, we build better software.

Have I missed something? Disagree completely? Let me know in the comments or reach me on Twitter!