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:
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.
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.
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.
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:
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:
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.
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.
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).
Apps and web pages that don’t let you zoom are a pox upon the world. ↩