The NYT’s Visual Election Outcome Explorer

How we made the interactive D3 decision tree

The interactive tree allows readers to explore US Presidential election scenarios centered on battleground states

The Project: 512 Paths to the White House

The space of electoral college calculators is fairly well-trodden, so at first it seemed hard to do something new. The big problem here is the combinatorial explosion (2^n): even if you consider only nine states, you have 512 possible outcomes! So, you don’t offer much insight by simply enumerating outcomes or allowing undirected exploration. The challenge is to preserve minute details (micro) while providing an effective visual summary (macro).

We settled on a binary tree early on, but it wasn’t until Shan had the idea of collapsing parts of the tree into “decision” nodes that the design clicked. By pruning subtrees below the 270-vote threshold, you reduce the complexity substantially. More importantly, you get a much faster sense of what matters: who wins! And from there it was “just” a matter of implementation and refinement.

The Design Process

Shan and I work out of the San Francisco bureau of The New York Times, but we are in constant contact with our esteemed colleagues in Manhattan. Rapid iteration and feedback are essential to converging on a good design quickly; fresh eyes offer critical perspective that is difficult to achieve solo. We use a git-backed preview server that allows us to share versioned previews of graphics (any commit, any fork) and get feedback. This is very helpful for showing previously-explored ideas and by extension the process leading to the current version.

More generally, iteration is about evaluation: figuring out what works and what doesn’t, and then brainstorming ideas for the next iteration. It’s hard to predict what something will look like until you try, especially when working with data. Shan and I frequently attempt competing ideas; even if a concept lacks promise, we may learn something from it that can be used to improve the graphic.

A question I often ask: what is the most salient aspect of the visualization? Is it the insight you were hoping to show, or is it merely some artifact of how the data was collected, formatted or laid out? In other words, are the key insights the most obvious? And, are there distractions or unnecessary elements that you can remove to accelerate understanding?

Building It

Sketch of sample tree

The nodes are positioned using the Reingold-Tilford “tidy” algorithm, as implemented by D3’s tree layout. The static layout was therefore surprisingly simple (because of the existing D3 layout); the binary tree is computed recursively by summing the electoral votes for each path.

The hard part of this graphic, implementation-wise, is the animated transition as you flip states. Although this is superficially similar to collapsible interactive trees I had implemented previously, it turned out to be more challenging due to the pruning below decision nodes. To assist my thinking, I sketched out a sample tree with eight different interactions and the corresponding animations. With examples, it was possible to generalize the behavior of the transitions and start the implementation.

The technical crux was implementing the key function for the data-join correctly, so that parts of the tree are remapped correctly as you add and remove states. (See my tutorial on object constancy for details.) It was really exciting to see it work the first time, especially for the more complicated transition flipping between the two parties!

The other technical detail worth mentioning is the invisible Voronoi overlay to improve mouseover interaction. Again, what you care about or this graphic is who wins, so the Voronoi is constructed using only decision nodes: the path to the outcome closest to the mouse is highlighted. Shan had the idea to construct a human-readable sentence for the highlighted path, which served elegantly to explain how the graphic works.

Annotations and Examples

Pre-sets for specific scenarios

Our designs are almost always built up incrementally, starting with the core visual encoding of data. But at the same time, we almost never publish something without annotation, so we think constantly about how to guide the user. Annotations serve to both highlight interesting views and to reinforce the user’s understanding of the graphic. An unlabeled graphic may be confusing, even intimidating; but if you can explain one part of it clearly, the user may be able to bootstrap their understanding to the rest of the graphic.

For these particular scenarios, it was editorial judgment. Applying background knowledge to give the data greater context—such as the influence of the auto-industry bailout on Ohio’s economy—makes the visualization that much richer. After all, visualizations aren’t just about numbers, but about understanding the world we live in; qualitative information can add substantially to a quantitative graphic.

Just for You

You can option-click on any of the buttons to see the transitions in slow-motion! I added this for debugging, but we left it in because it’s fun to see exactly how the transitions work.





Current page