On Tim Cook being “the first”

Alanna Petroff, writing for CNN.com:

It’s a landmark moment for both the gay community and the business world. Tim Cook is now the first and only openly gay chief executive in the Fortune 500.

Of course, many lesbian, gay, bisexual and transgendered employees still struggle with discrimination at work. The executive suite also remains extremely closeted, but there are a few high-ranking openly gay businesspeople.

Not to detract from their accomplishments or their struggles, but none of these examples come close to Tim Cook in terms of power or visibility. It’s like pointing out the US had prominent black politicians before Obama; not to take away from any of them, but there is a clear difference. Cook is the first openly gay CEO of a Fortune 500 company, and it’s a company with a track record the other 499 would kill to have.

I remember when “Apple is so gay” was a common juvenile taunt. For all I know, it still is. Regardless, times have changed, and we should all be comfortable responding to that taunt with “You say that like it’s a bad thing.”

Double Hotkeys with Keyboard Maestro

When it comes to hotkeys, there are too few key combinations I’m comfortable with, and my memory is too weak, for me to assign a unique hotkey to each of the things I want to do quickly. Spotlight is great, but it almost always takes more than two keystrokes, often several, for me to get to what I want.

What I want is to jump to things with exactly two keystrokes. Specifically, I want one hotkey to display a menu and the second hotkey to select from that menu — basically, something as easy as old-fashioned text-based menus.

Here’s how to set up exactly that in Keyboard Maestro, which is an amazingly terrific utility.

First, create a group with the “Shows a palette for one action when:” option, and specify a hotkey as the “when”. Here’s one group I created, named “Jump to Application”, with the hotkey Control-J:

Jump to Application

Second, add some macros for things you want to do quickly. For these second-level hotkeys, I almost always use plain letters with no modifier keys, because they’re easy to type, they’re easy to remember, and they won’t conflict with any top-level hotkeys. Note that they also won’t conflict with any other macros you define in Keyboard Maestro, even if they use the same letter. Here are the ones I defined; I went a little crazy with the names of the macros, for reasons you’ll see in a moment:

Jump to Application  Macros

And that’s all there is to it — you’re done!

Here’s what I see when I hit Control-J:

Jump to Application  palette

I put the shortcut keys in the names of the macros and used tab characters to make them line up. This way, I can look at the menu (or as Keyboard Maestro calls it, the palette) to remind myself when I forget. But mostly I don’t look. I just hit Control-J,J to jump to BBEdit, and so forth.

A huge advantage of this approach is that only the first hotkey (in this case, Control-J) has to avoid conflicts with other shortcuts, or for that matter with plain text entry. Instead of trying to find twelve available and memorable key combinations, I only need to find one and pop up a menu with twelve items.

I’ve been calling this approach “double hotkeys”. If there’s another name that people use, I’d love to know. I’m also curious what other apps use double hotkeys, and what other ways there are to achieve the same thing. I loved how Accessorizer uses double hotkeys, and have since noticed it as an option in Divvy, which is a very clever app, though I haven’t made a habit of using it yet.

Swift’s Range Operators

I was going to wait until I had more first-hand experience with Swift before blogging any opinions, but then I remembered this is the Internet. So here I am, late to the party, weighing in on Swift’s range operators, about which I have a definite opinion.

Swift’s original range operators, as defined in the first beta of Xcode 6, were:

  • x..y for a half-closed range (including x, excluding y)
  • x...y for a closed range (including both x and y)

There were lots of complaints about this choice, mostly in two categories as I recall:

  • Complaint #1: .. and ... are too easy to confuse with each other, the same way = and == are easy to confuse in C.

  • Complaint #2: .. and ... are too easy to confuse with the same operators in Ruby, which are defined with the opposite meanings.

Note that these complaints aren’t about personal taste. They’re about making it too easy to write buggy code.

Here is a complaint that absolutely nobody made, so please don’t take it too seriously, but it did occur to me as a possible annoyance:

  • Complaint #3: Some people want ... to be a system macro that automatically gets replaced with an ellipsis character.

A few people, including me, have proposed this alternative, which I am still convinced is best:

  • x..<y for half-closed
  • x..=y for closed

Here’s what I like about this option:

  • There is a parallel structure to the operators. “..” means this is a range, followed by a qualifier, either “<” or “=”, that indicates whether the last element of the range is less than or equal to y.

  • Neither operator is a substring of the other. You can’t make the mistake of typing one too few characters.

  • The meanings of the operators are clear from their appearance (addressing Complaint #1). You won’t have to pause each time to ask yourself “Which one was the closed one again?”

  • The operators don’t conflict with other languages (addressing Complaint #2). When I posted my suggestion, I didn’t think either operator had a precedent in any other language. It turns out ..< is used in Groovy, but it has the same meaning there as here.

In Xcode 6 beta 3, one of the range operators was changed. As of this writing, the operators are:

  • x..<y for half-closed
  • x...y for closed

This is fine with me, although I may change my mind if I ever start programming in Ruby. By only changing one of the two operators, the Swift designers[1] leave them half-open, if you will, to Complaint #2.

I want to mention one more proposed alternative that seems nice in theory but that I don’t think should be adopted:

  • [x..y) for half-closed
  • [x..y] for closed

This notation is already familiar to people with a little math, and easily learnable by anyone else. It’s concise. It’s unambiguous. It allows for the possibility of variations like (x..y] and (x..y).

But I think it could be open to Complaint #1. Depending on the font the programmer is using, and the resolution of their monitor, and how sleep-deprived they are, a parenthesis could maybe be mistaken for a square bracket. Or the difference might not be striking enough to register when they’re eyeballing the code, looking for why the program crashed.

Furthermore, I think mismatched brackets and parentheses could cause headaches in text editors other than Xcode. When we see an expression like that, we’re used to being able to double-click one of the delimiters to select the whole expression. I don’t know, maybe existing text editors could easily be updated to handle that, but it seems like a potential problem to me, and I do think this kind of consideration should influence language design. It’s worth looking for an option that both makes theoretical sense and plays well with the tools we use in practice.


[1] To the extent there is any such person other than Chris Lattner.

Radar’s UI For Entering New Issues

UI rule of thumb: use the biggest buttons for the most likely actions.

UI rule of thumb: Convey a sense of progression by putting a sequence of steps in a row or column, one after another.

Corollary to that second rule of thumb: Having led the user through a list of actions, don’t make the last thing on the list “Cancel everything I just did”, because that is very likely not what they want.

Pop quiz: How many of the above rules of thumb does Radar break here?

Extra credit: Did you think to yourself, “On iOS it’s normal for the ‘Done’ button to be at the top right corner, so this makes perfect sense”? Or did you think to yourself, “This is not iOS”?

Radar new issue UI

UPDATE 2014-09-09: Great news from Zach Drayer:

Just a Tool

When it comes to the “Mac or PC” question, I am not neutral. It’s more that I decided at a certain point to wash my hands of the business of telling people which to buy. I am not the right person to ask, if only because I lack perspective, and I will avoid that conversation whenever possible. When pressed, I will say “Buy what’s right for you”, because that really is sound advice.

What I never say is “It’s just a tool.” To be honest, that sentence makes me feel a little sick and sad inside. Like many people who live by their tools, I feel there is no such thing as “just a tool”.