Double Hotkeys with Keyboard Maestro

Posted on by
5

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. [UPDATE 2015-08-04: Keyboard Maestro 7 displays the macro shortcuts in the palette, so I've removed them from my own labels.] 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.

[UPDATE 2015-08-04: In case you'd like to try this, I've exported the macro group that I use for the above. You can download it here if you'd like to use it as a starting point. After downloading and unzipping the file, you can either double-click it, drag it to the Keyboard Maestro Dock icon, or use the File > Import Macros… menu option.]

Swift's Range Operators

Posted on by
4

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

Posted on by
Reply

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

Posted on by
Reply

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".

The Power of Unoriginal Storytelling

Posted on by
Reply

A friend posted this video on Facebook:

The video tells a story, but its purpose goes beyond storytelling: it is a marketing tactic used by a company that sells copywriting services. The blind man represents potential clients, the pedestrians are potential customers of those clients, and the mysterious woman represents Purplefeather.

According to the description on YouTube it is an "[h]omage to Historia de un letrero, The Story of a Sign by Alonso Alvarez Barreda", where "homage" really means "remake". You could argue that it was sleazy of Purplefeather to rip off the earlier film. You could also argue that there's nothing wrong with a remake, especially when the source is itself a retelling of a previously told story. Regardless, I'm not sure why Purplefeather wouldn't demonstrate its copywriting skills by writing something original.

Something else feels off to me: I've seen comments in various places describing the story as "beautiful" and "powerful", but to me, the core message of the story is not particularly heartwarming or inspiring. The good samaritan is kind of a jerk, altering the sign without permission and without telling the blind man what it says. And the good samaritan as a proxy for the storyteller (i.e., the filmmaker) seems a bit self-congratulatory, as if saying to the audience, "Aren't you glad I taught you this lesson about marketing?"

To me it is an interesting parable about human nature, but the same point could have been made with the "blind" man actually being a con artist whose "sales" have been slumping until he himself comes up with the clever marketing tactic. Different story with the same lesson: how you convey your message affects the material rewards it will get you. And perhaps a secondary lesson: people want to be compassionate, but sometimes you have to sell them a little on the idea.

On the other hand, "Historia de un letrero" was a winner at Cannes in 2008, I suspect because it was seen as heartwarming. Maybe the filmmakers would not have won if they had told my con-artist version of the story. So maybe the story is itself a demonstration that how you convey your message matters — even when the message is that "How you convey your message matters."