How De Tijd approaches interactive storytelling, part 1
The last couple of years a part of the digital team at Belgian financial daily De Tijd has been developing digital formats with a strong focus on data driven journalism. The stories are the product of many years of internal development with a small team. It’s still not common compared to other types of media, and we still have a lot to learn, so sharing our approach seems to be the sensible thing to do. This is the first time we publish an article on our process.
Last week we published an interactive article on spatial planning in the Belgian part of the North Sea. It’s part of a four-week print/online series on how the North Sea can play a big role in food, energy and transportation innovation. Besides an art installation in the coastal city of Oostende on sound pollution in the sea (the multimedia team had nothing to with it, but I think it’s pretty cool), the standalone videos and the podcast mini-series (still in production), we published this interactive article.
DO YOU HAVE DATA OR DO YOU HAVE AN IDEA?
First you need an idea, a baseline to support the story. There are a few ways to handle this. In our case usually two: either you have an idea, and you look for data, or you get your hands on information, mostly a dataset, and you develop an idea starting from there. In this case it was the latter, in the form of a government brochure. The journalist heading the series sent us a digital leaflet on spatial planning in the North Sea. We had no idea the sea surface could be planned as if it were a city, but there you go.
We then had a few brainstorms -we being the journalist, two data and visual journalists, a front end developer and me, as a coordinator. We knew one of the big caveats was that we’d end up with a fancy version of the brochure, which obviously was a red flag for a number of reasons: we’re not the government’s spokesperson, and it’s just plain boring. That’s why we needed a story, or at least a rough outline, which probably was -and kind of always is- the hardest thing to find. It’s never a linear process, always messy. The steps in the process -idea, story outline, data, building the story- ideally succeed each other neatly, but don’t bank on it, we never do.
That said, the brainstorms produced an outline: the North Sea is growing with activity, how do you manage all that in such a small place? Once we had a basis for the story, we could look for data.
FROM (OPEN) DATA TO SCROLLYTELL
In this particular case, our starting point was the marine spatial plan. To our surprise, there was an abundance of open data. The Royal Belgian Institute of Natural Sciences showed the way (take note, other government agencies), and we could download the detailed plan in different easy-to-use formats. There’s a few dozen layers, too much to show in our story, so we picked the ones most relevant to what we wanted to tell. A few years ago, we had a tendency to put a lot of work in publishing an entire dataset in searchable maps or databases, today we think we need to offer context first, or we risk losing people in the data dump.
We picked seven layers, it’s not a vast amount of data, but we thought it’d be too complex to see them all at once. That’s why we chose the scrollytelling format we developed. It allows you to take the reader step by step through a complex or multilayer graphic. It’s one of the tools we developed over the past few years within our own framework called Flatrock, which is named after a town in Canada, a country deeply loved by our front end developer. It’s a framework that allows us to produce versatile, lightweight and search engine friendly websites. Anyway, scrollytelling was our favourite pick.
Next step: the storyboard, absolutely essential. These types of projects are almost always collaborative, because it involves technical, visual, number crunching and storytelling skills. I’m not sure the world has produced a human that combines all of those skills in one. So the storyboard. You need it for everyone to keep an overview of the story. We always use Google docs, and everyone involved has access to it.
JUMPSTARTING THE STORY
The spatial plan emerged out of necessity: the Belgian territorial waters are part of one of the busiest sea routes in the world, busier than the Panama or Suez Canal. At the same time, it’s not bigger than the average Belgian territorial province. We decided we needed that image to lure the reader in: an animation of ships.
The friendly folks at marinetraffic.com gave us a dataset spanning 24 hours of marine traffic off the Belgian coast. In order to create a bit of order in the structured chaos, we grouped the seemingly infinite amount of ship types -who knew a large juice container was a separate type of vessel- in four categories, each with a distinctive colour. We spent a lot of time tweaking the colours, first on a dark map, then a light map. In the end we switched back to a darker version the morning after publishing the interactive. It was worth our time, though, the first image should be made to stick. Sidenote: we downloaded the data points of the map itself and produced the extremely detailed map in R.
We got a lot of feedback on that animation, mainly that people had no idea it was so busy. The image worked, and it made people scroll. Obviously, people love to scroll, but you don’t want them to dead scroll their way to the end, without reading. We wanted to have a balance between scrollytelling chapters scratching the surface and regular detailed chapters. We ended up with this structure: scrollytell 1 -> chapter 1 -> scrollytell 2 -> chapter 2 and 3. It could have been a different structure, but this struck a nice balance, at least in our opinion.
The scrollytelling format is a great way to explain complex graphics step by step. As a final step we let the reader mindfully play around with the data. They’ve attended class, now it’s time for practice, or something to that effect. We’ve done it before and it works. Usually we open up the entire dataset, or at least a good part of it, this time we chose not to. We talked about a limited part of it, it made little sense to do it all. In all honesty, we probably could have added a bit more info, but the clock was ticking.
The people involved in this interactive were: Stephanie De Smedt (reporter), Thomas Roelens (datajournalist), Raphael Cockx (front end developer), Thomas Segers (datajournalist), Dries Ceuppens (video journalist), Kaat Van Overwalle (editor) and Andries Fluit (coordinator).
This is the first time we publish an article on our working process. It is our intention to do it more often. If you have any questions or suggestions, use the comments section below or email me at firstname.lastname@example.org.