Why newsrooms need storytelling tools and what we’ve learnt building them
It’s 2017 and the best digital journalism is better than ever. However, the average story has barely improved over recent years. The kind of story that gets written dozens of times a day. The story that describes unemployment numbers, but doesn’t show them. The story that describes specific places, but doesn’t locate them on a map.
Those average stories all too often lack that one obvious visual element. That’s a problem. Users expect it (and if they don’t, it’s only because we’ve lowered their expectations). Yet a lot of newsrooms cannot deliver.
We at NZZ Storytelling* made it our core mission to improve the average story. There’s no point in standing out every now and then when your users get a subpar experience every day.
*NZZ Storytelling is an interdisciplinary team of twelve data journalists, graphics designers and developers at NZZ in Zurich. We create graphics and interactives, we tell visual, data-driven stories and we provide tools and templates for editors to do the same. Some of our work can be found here.
The only way to tackle the problem at scale is by making sure a lot of people in the newsroom are capable of producing those simple visual elements. That’s why we built Q, a storytelling toolbox for editors. It’s now one year since we launched it and we thought it’s about time we share some of our learnings.
What is Q?
Q is a toolbox that allows reporters and editors to create simple graphics and interactive elements for their stories. We like to think of Q as the team member of NZZ Storytelling that is available 24/7.
What sort of graphics and interactive elements?
- Charts: Bar charts, line charts, stacked bar charts
- Maps: Pointer maps for one or several locations, with normal basemap or satellite view.
- Vote results: Live results and choropleth maps for popular votes (yes, we have a lot of those in Switzerland)
- Quizzes: Multiple choice, guess a number, guess a location
- Survey results: A chart for showing the results of surveys leading up to a popular vote (again, yes, we have a lot of those in Switzerland)
- «Parolenspiegel»: A visual overview of which parties and organisations support/oppose a specific referendum
So, let’s say I need a map. How does this actually work?
First of all, Q is browser-based. You can use it anywhere you have an internet connection. Simply log in and search to find out if there’s already a map of what you need (everything that is created in Q is available to anyone). If you’re lucky, you can just drag and drop it into your article and you’re done. Otherwise, you can use an existing map as a blueprint and make your adjustments. Or you start from scratch and add all the locations you need and customise the map (by selecting a base layer and a zoom level). Then you activate the map and drag it into your article.
Nifty. What if I need a chart?
Ok, we won’t go through all the item types now (we’re happy to share some more details if you have specific questions). The important thing to remember: Whatever you are creating, the process is exactly the same and the editing interfaces look very similar.
One year in, how’s it going?
Roughly 200 journalists (in a newsroom of 300-ish) use Q. To date, they have produced 2170 items in Q and used them in stories across NZZ.ch. That’s 2170 times that we have helped our users understand an aspect of a story that is hard to fully convey in text. While 2170 is a nice number, the important part is that we’re accelerating. It took us eight months to get to 1000 items. Three months later, we were at 2000 items. We think it should be possible to produce 1000 items every month. In total, Q-graphics have been seen more than 10 million times in 2016.
And beyond sheer numbers?
It’s hard work. You don’t just walk into a newsroom, tell everyone «Here’s your toolbox, now use it» and it’s fine. It takes a lot of explaining, convincing and coaching. Very roughly, I’d say a third of the editorial team welcomed Q and is using it regularly. A third was skeptical, but has tried it. And a third wants nothing to do with it. Overall, we’re very happy with where we are one year in.
Looking back, what are your key learnings?
Editors want pie charts real bad. Seriously, saying «no» has been a key part in building and extending Q. No to features, no to options. And it’s not just saying «no» to requests from editors: in most cases, in fact, we need to say «no» to our own ideas. a) because resources are limited, but even more importantly b) for our tools to work for a large number of people, we need to keep them simple. We’ve made it a rule that it should take no longer than five minutes to produce a graphic in Q. More options mean it takes longer than that and it becomes harder to ensure a consistent output.
The second big lesson is that your rollout is never complete. This is certainly something we underestimated. We are dealing with a lot of people and a product that evolves quite quickly. So it’s almost impossible to ensure everyone is aware of all the possibilities and using them correctly. At all times, there’s need for lobbying and support on various levels, from «Why should I use this?» to «How do I deal with edge case X?». So we spend a decent amount of time doing refresher courses, one-on-one support. It’s time-consuming, but we learn a lot about Q’s strengths and weaknesses. On the adoption side, we are lucky to have executives who supported the vision from the beginning and who, by mid-2016, decided that knowing how to use Q was as important as knowing how to use our CMS.
You mentioned Quesdays. What are those?
Actually I didn’t, but thanks for bringing it up. In September, we rebranded all Tuesdays to Quesdays to raise awareness in the newsroom. We challenged the newsroom to include Q-graphics in every single article where it made sense, and offered extensive support. It helped us onboard new users, re-engage existing users — and let us demonstrate the potential. On each Quesday, the newsroom produced 30–40 charts and maps. One unexpected, but very welcome effect was that here and there Quesdays surfaced frustration with the toolbox and aversion to the idea that editors should produce graphics. It’s easier to deal with once it’s brought up.
I’ve heard rumors that there’s a Slackbot for Q, too?
We cannot deny this. It notifies us every time a new item has been created, allowing us to quickly do a quality check and give feedback to the creator. It also alerts us when the number of items created in the past seven days falls below a threshold we defined as the lowest acceptable.
This whole Q-thing sounds great! Can we use it, too?
We get this question a lot. The short answer is: no (or at least: not yet). Ask us what’s next and we can explain a little more.
Okay. Okay. What’s next?
As of now, Q is still no more than a working prototype. We’re currently working on version 1.0 which will turn it into a serious piece of software. It has to be, as it has become an integral part of how we produce digital journalism at NZZ. It will make the platform more robust, integrate deeper with the CMS and become scalable, so that other newsrooms can use it, too (in the NZZ Media Group, but also beyond, though we haven’t decided on a strategy for this yet). Our next priority is adding more tools and improving the tools we have. Eventually, the goal is to tool-ify whatever we find ourselves producing multiple times in the same way.
Update: The core parts of Q are now open source.
Come to think of it: Do you also produce graphics for print from Q?
Unfortunately, no, but we’ve made the first steps towards a more integrated process. Our team produces a sizeable number of fairly standardised graphics for print, so we would benefit from more automation. So, if you have experience with this kind of thing, I’d love to hear from you.
This must all be a lot of work. Why don’t you use existing tools?
The main reason is that we were not looking for a number of dispersed tools, but a toolbox. One login, one user interface, one delivery pipeline. We assumed (and were proven right) that it would greatly help adoption in the newsroom when there was a one-stop-shop for graphics and only one thing to learn. There was no such thing we could just take and use.
Another reason, of course, is control. The graphics and elements we produce with Q are key elements in our stories and we want to be sure they look and behave exactly the way we want them to — now and in five years time. Building our own tools also allows us to control the expertise level required to use them. While Mapbox for maps and Datawrapper for charts are great tools — we use them quite often in our team — they require more time and expertise than we expect from an editor.
I’m really into technical details. Can you tell us a little more about what technology Q is built with?
Sure, but I’ll leave that to our lead developer Beni Buess, who almost single-handedly wrote the code that runs Q today:
And how exactly do you bring these graphics to readers’ screens now?
We have this feature in our CMS that allows us to put HTML into an article that will get sent to the user’s browser as-is. Using this feature, we place a div in the article containing the document ID from CouchDB and a script tag loading the Q-loader. The Q-loader will fetch the document directly from CouchDB (actually there is a CDN in between), check what tool was used to build the data model and then dynamically load the renderer code using SystemJS. The renderer code is a JS module exposing a function which gets called with a DOMElement and the data. It will then display the graphic, sometimes with the help of libraries like LeafletJS (for maps) or Chartist (for the charts)
Got it. What are your plans to develop Q further?
This has changed since and we are currently refactoring the system to render on the server whatever is possible. This makes testing much easier as we don’t have to make sure that all the code runs fine in all the different browsers people use to access our content. It has some other benefits as well:
- It allows us to send the markup for the graphic down the wire with the initial request of the article. This will greatly improve the reader experience.
- We can use all the libraries we want on the server without worrying about the performance of the devices our readers use.
- It will allow us to send an image of a graphic to environments where interactivity is not supported.
We also have some ideas on how to greatly simplify the development of new tools. We will provide forms for simple editors based on the json-schema describing the data model of a certain graphic type. This will allow us to bring a simple tool to production within days.
All in all: great times ahead.
Wait a second, I’ve read to the very bottom, but I still don’t get why you called it Q!
It provides tools for others to do their job. With one notable exception that we warn editors about when they load Q: «Were you expecting an exploding pen? We don’t really go in for that sort of thing anymore.» Got it?
Thank you for reading. If you have more questions or if you are working on something similar and think we should talk, get in touch. I’m @davidbauer on Twitter, the team is @NZZVisuals. You can also reach me via good old email at firstname.lastname@example.org. And please share this article with anyone you think would have something to say about it.