Next post Previous post

Blockheads

December 3, 2017 at 9:44 AM by Dr. Drang

Yesterday, I was reading a Washington Post article about the differences between the House and Senate versions of the tax r̸e̸f̸o̸r̸m̸ bill, when I came across this:

WaPo graphs in iPhone app

At first, I focused on that extra block at the bottom of the House graph and thought was “Why does the House’s graph have more blocks than the Senate’s when it costs less?” ($1.09 trillion for the House and $1.17 trillion for the Senate.) Then I noticed that the Senate graph looked wider than the House graph. Because I was reading the article in the WaPo app on my iPhone, I couldn’t zoom in to make a careful count,1 but after taking a screenshot and looking at it in the Photos app, I confirmed that the House graph is 12 blocks wide and the Senate graph is 13 blocks wide.

So the block count in each graph is correct, 9×12+1=107 for the House and 9×13=117 for the Senate (each block represents $10 billion), but the presentation is wrong. If you’re going to compare two numbers with this kind of graph, the row widths should be the same.

You might well ask why use any graph at all when you’re comparing only two numbers. The charitable answer is that this article compared five pairs of numbers, not just these two, so the blocks could be used to compare numbers across pairs (even though the page layout puts the graphs too far apart to do so). The less charitable answer is that newspapers have become overly enamored of “dataviz” and use graphs even when it makes no sense.

Update Dec 3, 2017 11:22 AM
Thanks to this tweet from Tomonori Ishikawa, I no longer feel guilty about my less charitable interpretation. He points me to a Wapo article in which a large block-style graph is used to compare exactly three numbers—there are no other graphs in the article. I can understand why “data journalists” would want to justify their employment by adding gratuitous charts to an article, but I can’t understand why there are no “data editors” to spike them.

Why would someone make such a silly mistake? My first guess was that these graphs were not drawn but generated automatically by some JavaScript library that used responsive web design principles and somehow the widths of the two graphs came out different. So I opened the article in the WaPo app on my iPad to see if the graphs looked the same on a wider screen. They did. Portrait or landscape, with any variation of Split Screen width, the House graph had 12-block rows and the Senate graph had 13-block rows. The responsive design explanation was looking bad.

But then I opened the article in Safari on my MacBook Air and saw that both graphs were 13 blocks wide. The numerical difference was easy to see in these graphs.

WaPo graphs in 1320 px wide browser window

That was with a wide browser window. As I narrowed the window, the widths of the graphs changed and the blocks rearranged themselves. Most of the time, the widths were the same, but there were exceptions. With a browser window width of 1305 pixels, the graphs looked like they did in the iOS apps:

WaPo graphs in 1305 px wide browser window

Making the window slightly narrower reduced the width of the Senate graph to 12 blocks and made the two the same again. At a window width of 1260 pixels, the widths were different again, with 11 blocks for the House and 12 for the Senate:

WaPo graphs in 1260 px wide browser window

So the graphs were responsive. A little snooping around in xScope showed that the House section of the page was always 2–3 pixels narrower than the Senate section. So as the window width decreased, the House graph would become narrower before the Senate graph. Apparently the graphs used in the iOS app were made at one of these unfortunate transitions.

xScope dimensions of page items

You might take issue with me describing the different-width graphs as “wrong.” After all, the numbers of blocks are correct. But I stand by my description. Graphs are supposed to make data interpretation easier; if they mislead, especially in such a simple case, they are wrong.

Update Dec 3, 2017 8:59 PM  I got a couple of followup tweets from Reuben Fischer-Baum, a graphics reporter for the Post. First, he didn’t take issue with the title of the post or my putting “data journalist” in quotes. Second, he explained that the difference in graph widths was caused by a bug in the article’s CSS, not JavaScript, and that the graphs in the iOS app are screenshots from the website. If the screenshots had been taken with a different browser window width, the graphs probably would have had the same block width, and I would never have written this post.

Anyway, the article is fixed now in both its web and iOS manifestations. Good work by Reuben to fix the problem so quickly (although I still question the value of including the graphs at all).

  1. Apps and web pages that don’t let you zoom are a pox upon the world. ↩

Next post Previous post