Blockheads

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.

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. ↩︎


Last thoughts on modifier keys

When I wrote the post about ordering Mac modifier keys a few days ago, I was thinking primarily about the proper order of the symbols when writing about a keyboard shortcut, like ⌃⌥⌘P.1. I mentioned parenthetically that this order isn’t always observed when people speak about keyboard shortcuts or when they write the names of the keys out fully, as in “Command-Shift-3 takes a screenshot.”

Jason Snell, in both a post at Six Colors and in conversation with John Siracusa on the lastest episode of Upgrade, took a stand against Apple’s ordering:2

Command is the commander! Command is the monarch of all keys! Command always comes first, in my book.

Siracusa agreed, and so do I. The ⌘ key is, and has always been, the key that signals a keyboard shortcut. While other modifier keys are sometimes used without ⌘—in cursor control and text selection, for example—I can’t think of any Apple applications that don’t use ⌘ to signal a keyboard shortcut for a menu item. And that primacy in shortcuts to menu items is, I think, why Apple puts it last rather than first.

Keyboard shortcuts are always presented right-justified along the right edge of the menu. The most common shortcuts are just ⌘ and a letter, like ⌘N to start a new document, for example. It’s typically the variations on the basic command that get additional modifier keys, like ⌥⌘N to start a new project. If that were presented in a menu as ⌘⌥N, the menu would look wrong because the ⌘ symbols wouldn’t line up.

Here’s the File menu in Safari:

Safari File menu

There are two different New commands and three different Close commands. This, in Apple’s opinion (and mine), wouldn’t be right:

Altered Safari File menu

It’s not just having the ⌘ symbols aligned. The additional modifier symbols go in front because ⌘ is king and must sit next to the N or the W. The importance of the modifier decreases as you move away from the letter.

It should go without saying—but I’ll say it anyway—that the letter (or number or whatever) key is the most important because nothing happens until it’s pressed.

Having said all this, and despite agreeing with Apple’s symbol ordering, my ear for shortcut ordering works just like Jason’s and John’s. The main reason I use keyboard shortcut symbols in my posts instead of words is that I can read ⌥⇧⌘W and not be bothered because I don’t “hear” it as I read the symbols. “Option-Shift-Command-W,” on the other hand, gets sounded out in my head, and it sounds wrong.

I suspect that’s why Apple’s own documentation sometimes gets the order wrong when the modifiers get written out as words. In speaking out the keys, “Command” is natural to put first because it announces that what’s coming is a keyboard shortcut.


  1. Which happens to be the shortcut I use for previewing a blog post locally before publishing it. ↩︎

  2. In the original post, I said I didn’t know where the order was documented. A few people pointed me to both the Human Interface Guidelines and the Style Guide, where Apple gives the proper order explicitly. ↩︎


My next Mac

Will probably be an iMac. I guess that spoils the suspense, doesn’t it?

My iMac at work is the 27″ Late 2012 model, the one that came out one step before Retina came to the iMac. I don’t regret buying it, as my previous iMac (a 2006 model, I think) was absolutely on its last legs—constantly swapping to hard disk and running hot. I hadn’t meant to wait so long to replace it, but there was a long delay before that 2012 model came out, and I didn’t want to buy something that would be last year’s model almost as soon as I set it up.

My home Mac is the venerable 2010 13″ MacBook Air, the first good Air. In the normal course of things, this would be the Mac I replace next, and I’ve been expecting to do so for a few years now. but…

But Apple never came out with a Retina MacBook Air, choosing instead to go with the MacBook, which I find a little too far on the portable side of the portability/power spectrum. A couple of years ago, I had a crisis when my Air crapped out on me. It seemed wrong to put money into a five-year-old machine, but I wasn’t enthused about any of the MacBooks in the lineup at the time. I didn’t know the just-released 2015 MacBook Pro would turn out to be the best laptop ever made, I didn’t want to spend MacBook Pro money on my home/travel machine.

The $280 logic board upgrade turned out to be a good investment, as I’m now 2½ years into my rejuvenated Air. Yes, it takes a while to wake up when I open the lid. Yes, its 128 GB SSD is tiny. No, it can’t take advantage of many of the iOS integration features that newer Macs can. And no, I don’t think it’s a good idea to install High Sierra on it. But it’s given me 30 months of faithful use, much more than I expected at the time.

The announcement of the Touch Bar last year made me certain I’d be getting a MacBook Pro with it. A software-configurable set of controls seemed perfect for someone who’s always ginning up little scripts. But no one seems to like it, possibly because its configurability isn’t especially open to users. Bummer.

I’ve delayed the decision on my home Mac for such a long time that now my office Mac is long in the tooth, too. Still working fine for most tasks, but just a Core 2 Duo machine that often makes me wait to scroll through long PDFs of scanned engineering and architectural drawings, something I need to do at work quite often. And no Retina.

So it looks like my best bet is to buy a new iMac for work and bring my current office iMac home. This will put the power where I need it the most and will give me extra ooomph here at home. Especially with disk space (3 TB vs. 128 GB) and RAM (24GB vs. 4GB).

It will be weird, though, as I haven’t had a desktop computer here at home in a dozen years. Will I enjoy being tethered to one spot in the house? And what about a travel computer?

Both of these questions are made less pressing by the device I’m typing this on: a 9.7″ iPad Pro. While I agree with Gabe that it is by no means a Mac substitute, it can handle a lot of what I do at home and virtually everything I need to do on the road.1

As for which iMac, I think I’ll settle on a middle-of-the-road 27″ configuration with a 3TB Fusion drive. Sort of the 2017 of what I bought in 2012.


  1. I bought the iPad Pro last year as a sort of experiment to find out how comfortable I’d be working on it. I intend to write a full post about the results of that experiment soon, but in the meantime, you really should read Gabe’s post over at Macdrifter. I’ll probably use his post as a jumping-off point. And there may be a quiz. ↩︎


Modifier key order

If you write about Mac keyboard shortcuts, as I did yesterday, you should know how to do it right. Just as there’s a proper order for adjectives in English, there’s a proper order for listing the modifier keys in a shortcut.

I haven’t found any documentation for this, but Apple’s preferred order is clear in how they show the modifiers in menus and how they’re displayed in the Keyboard Shortcuts Setting.

Canonical Mac modifier key order

The order is similar to how you see them down at the bottom left of your keyboard.

Modifier keys

Control (⌃), Option (⌥), and Command (⌘) always go in that order. The oddball is the Shift(⇧) key, which sneaks in just in front of Command.

Keyboard Maestro recognizes this standard order and presents its “hot key” shortcut the same way.

Keyboard Maestro hot key field

(When people speak about keyboard shortcuts, it’s not uncommon to put Command first, e.g., “Command-Shift-3 takes a screenshot.” I’ve seen it written out that way, too. Apple is usually pretty careful to use the same order when using words as when using symbols. This page, for example, uses “Shift-Command-3,” to match the ⇧⌘3 you’d see in the Keyboard Shortcut Settings. But even Apple slips up. On the grand Mac keyboard shortcut page, there are a few instances of “Command-Shift” instead of “Shift-Command.”)

The last bit of standard syntax is that the letter key in the shortcut (if there is a letter) is always presented as a capital, even when the Shift key isn’t used. I suspect this was a serious topic of discussion at Bandley 3 back in the early 80s as the Mac was being developed. They got it right. When entering a keyboard shortcut, you’re not typing a letter, you’re pressing a set of physical keys on the keyboard in front of you. The symbols on the letter keys are capitals, so that’s the appropriate way to identify those keys.