The joy of data-driven journalism

8 February 2016

Even before doing their front-end development challenge I was excited by the type of work Code for South Africa are doing. Becoming a web designer and front-end developer originated from a strong desire I had over a decade ago to design and build effective stories. To harness data, design, and the web to maybe have a chance at creating some decent journalism. I never ended up doing anything of sort, though, as other things took over my schedule.

The challenge was effectively a test for both myself and them to gauge whether the type of freelance work they need done would be a good fit for me. Creating robust client-side data visualisations that work on a wide range of devices and browsers was enjoyable, but the journalism side of things was more of a highlight for me. The process of wrangling some real data, finding a story in that data, and then using my front-end development experience to make that story a broadly accessible story on the web was a lot of fun. I was happy with my end result, especially in light of my rusty (or lack of) experience in doing this kind of thing, and the limited time I had to do it in.

I was given a query dump of record attendances of members of parliament (MPs) for different parliamentary committee meetings. The task was to create a story from that data accompanied by data visualisations. I figured the expected angle would be MP tardiness. Their absenteeism was indeed significant, but I was able to uncover an interesting aspect of this absenteeism that potentially pointed to the fact it wasn’t necessarily their fault. I also narrowed the story’s angle toward a controversial bill that was passed by parliament during the period of the data supplied. Go ahead and read it for yourself to find out more.

If you are interested in the technical side of things, then you should browse the GitHub repo and to read the detailed README to understand both my approach and the challenge that was posed. This was a time-boxed challenge, and I had other work on my plate during the week I did it, so there are obviously a number of things I could improve. Some design-related things are mentioned in the README, but there are a few accessibility improvements I could have also made thanks to some feedback I got from Steve Barnett. Seeing as I got this feedback after I had already submitted it, it felt like cheating to make those updates, so I haven’t. I have, however, updated the README since, just so it reads a little bit better.

I’ll just quote my synopsis here:

Essentially my approach was quite simple: Put users and the story first. Let the tech and design decisions come from that priority, not the other way around. It’s relatively easy to bang out interactive tools that rely on lots of client-side JavaScript and asynchronous data queries, but this wouldn’t have necessarily improved the data-driven story it is supposed to serve. Trade-offs were made accordingly.

Want to discuss something? Feel free to contact me.