Enter Dataviews

One of our most recent works, “How Americans Die,” is an instance of what we call a “dataview.” The impetus behind dataview was a hope to provide clear and concise storytelling, while giving the supporting data more prominence and explorability. With our team leader, Lisa Strausfeld’s idea that “the data is the story, and we’re just walking you through it,” it made sense to flip the paradigm of charts placed in a body of text. Instead we wanted the chart to be fully immersive on screen and add notes, like signposts, to guide you.

We found a perfect editorial partner in Bloomberg View contributor Matthew Klein, who has a deft hand at mining data, analyzing it, and paring it down to the most compelling points. View publisher, Tim O’Brien noted Klein’s data-centric work and brokered the marriage with our team. So we based our initial build of the dataview around an in-progress jobs report piece that Matt worked up to debunk the cheer of overall employment numbers increasing and expose the lack of high-paying positions available since the recession. It was a bit of a back-and-forth cutting the copy down into shorter, tweet-like notes, and getting the pacing right, feeling it out as we went along. We also added features for better comprehension like dropping the opacity on certain datasets in a group and highlighting time periods along the x-axis to make the view better reflect the note contents.

Anatomy of a Dataview

I started the foundation of dataview as a general purpose dynamic chart, so D3.js was an obvious choice (its axis feature alone is enough reason to use it). Other than that it uses JQuery and few functions from Underscore.js. I’ve been building off of the same prototype codebase for each instance which is written in CoffeeScript. The data is brought in as static CSVs, and I’m not currently using any packaged MVC pattern. The framework is built to be relatively data agnostic, though most of the data we have been working with are time-based, so it is fine-tuned for a linear time series. To freely pan around on the x-axis, it became obvious that I needed to properly handle JavaScript dates as a opposed to a series of strings like “January 2000.” This involved creating a dynamic array of dates for the extent of the current view, at a desired fidelity—year, month, week, etc.—to use for mapping the mouse position to corresponding data points. Underscore.js’s sortedIndex function was also used here to choose the closest date if the position did not map exactly.

The main components are broken out into datasets, scenes, and notes. It handles each dataset as a unique object and gives it attributes such as color, units, label, and source. Scenes are described as being within a certain time period, containing specific datasets, and having a choice of render method. Currently the choices are lines, areas, stacked areas, columns, or stacked columns—standard charting. Other parameters can be given for an animated pan/zoom on a desired scope or having multiple y-axes. Notes are pulled from the html and paired with each scene. These are also used for the Internet Explorer < 9 version, which is a slideshow of screenshots.

As you move from scene to scene the chart is simply updating by changing the extent of time and domain of data. It moves the previous rendering along the axes in the scale of the next to be drawn. This gives the appearance of sliding around one boundless chart, housing all the data. The dataview adapts to the client screen size on load and stays responsive by keeping the view state and re-rendering the whole svg once the window is no longer resizing. Given the lean amount of content in each view, this allows it to work well on desktop or mobile. We’ve been adding features with each iteration—highlighting different datasets by clicking their label, keyboard arrow control—but still need to add better touch events and a way to scrub the data without a mouse.

Composing “How Americans Die” took Matt about 50 hours. On projects like this, he hands off a thorough Excel document with all data, versions of the charts, and corresponding notes, which makes it very easy for me to bring it all into the framework. (This is the current manual process for authoring a dataview, but we hope to soon make an easy interface so the form can be used more widely by other editors.)

Tuning and Feedback

Another result of wanting to publish quickly, was that we didn’t do much user testing. Google Analytics gives us a good indication that a large majority of visitors click all the way through, however, comments on HackerNews from “How Americans Die” have been an abundant source of feedback. There was confusion over why deaths were shown as either total individuals, or per 100k, or as a percentage—people felt it difficult to compare values. Also UI concerns like, “Either I am blind, or they aren’t there but there were a few slides where I was trying to figure out the Y axis representation because it wasn’t labeled clearly.”

Other than that, it was great to see people exploring the data and coming up with their own questions and conclusions. We hoped this format would lead to a more open-ended navigation of the content. It seems like we’ve had some success, but plan to continue pushing this (possibly adding an open graphing feature for all datasets to be revealed at the end of the narrative).