April 17th, 2014 at 3:41 pm by Dr. Drang
Because of the OpenSSL bug, I’ve been doing a lot of password changing recently. 1Password has generally been a big help in this, but my continual interaction with it has revealed one annoying aspect of its design.
As we all know, 1Password is exceptionally good at recognizing which web site you’re browsing and filling in the username and password fields of the login page automatically. But when you need that information in another application—to set up an email account or a calendar subscription, for example—you have to search the 1Password database and copy out your credentials. This is best done through 1Password mini, a menubar app that has access to the most used features of the full 1Password application. It’s the interaction with 1Password mini after a search that’s annoying.
Here’s the problem:
You type the search term in the field at the top of the 1Password mini menu and the results appear below it. To put the password you want on the clipboard, you move the mouse down to the appropriate item, where a right-pointing arrow appears. You move the mouse over to the arrow and a submenu pops up with your username and password. Select the password from the submenu and it’s on your clipboard, ready to paste wherever you want.
The annoyance should be apparent in the screenshot. You move the mouse to the right edge of the main menu to pop up the submenu, but the submenu invariably appears to the left of the main menu because there’s no room for it on the right.
Most Mac submenus pop up as soon as your mouse touches the item in the main menu. 1Password’s submenus don’t work that way because Agile wants you to be able to select the item in the main menu to go directly to the site in your browser.
This may not seem like a big deal, but when you have to keep moving your mouse back and forth, you notice the inefficiency. And when you’re using a trackpad instead of a mouse, the lowered precision of your pointing device makes it more likely that you’ll miss one or more of the targets as you move around. Then you have to start over again.
There are, I know, keyboard methods for selecting menu items. I can use the ↓ key to select the appropriate item in the main menu, then the → key to bring up the submenu, then the ↓ key again to select the password. But when I see a menu, my natural inclination is to reach for the mouse or trackpad. Three decades of using menus that way is hard to erase.
I’d feel much better if the arrow were on the left side of the menu. After all, the 1Password menu is always going to be near the right edge of the screen and the submenu will always appear to the left of the main menu. I know there are problems with that:
- It’s conventional for the arrow to be on the right side. I would point out that it’s also conventional for the submenu to pop up when the item in the main menu is selected, and Agile has been willing to dispense with that convention.
- There’s a sidebar in the menu that categorizes the search results, and its natural position is on the left.
I’m not sure what the best solution is. It wouldn’t surprise me to learn that Agile tried several different configurations and decided this one is the least objectionable. Still, I can’t help but think it’s wrong for a right-pointing arrow to lead to something that’s always on the left.
Well, I’ve learned a few things from the responses to this post:
- Some of you have lots menubar apps running, which puts your 1Password mini menu far enough in from the right edge of the screen that the submenu appears to the right of the main menu. What’s surprising to me about this is that the last time I posted a screenshot of my (much smaller set of) menubar apps, I got several “Why don’t you use Bartender?” replies. I thought I was the last person on the planet who didn’t use it.
- My guess that Agile has done a fair amount of thinking about this problem was right. Also, whoever’s running the 1Password Twitter account knows how to handle complaining customers.
@drdrang If you only knew how much that’s been discussed internally… Thank you for taking the time to let us know your thoughts on it too!
— 1Password (@1Password) Thu Apr 17 2014 9:30 PM
- You can copy the password of the selected item without revealing the submenu by typing ⇧⌘C. This is a great tip from Agile.
- There may be some changes in how 1Password mini looks and/or works in an upcoming release. This came from a beta tester who probably should have kept quiet about it
April 16th, 2014 at 10:27 pm by Dr. Drang
I haven’t seen The Winter Soldier yet, but I did find a couple of podcasts to help me prepare. They’re both episodes of the Talking Comics podcast, which I’d never listened to before.
The first is episode 127, “History of Captain America.” This is a three hour episode, but the first half is the sort of non-Cap stuff of their typical show. I suggest fast forwarding to about 1:25, when they shift to Cap. Bob Reyer, who seems to be the podcast’s resident historian, does a nice job of running through the whole Captain America timeline, starting with the Simon/Kirby days before WWII and going up to the present.
It’s a much better narrative than what you’ll get by reading the Wikipedia entry for Captain America. I find all of the Wikipedia articles on comic book characters unsatisfying because the biography sections treat the characters as if they’re real, and there’s a lysergic quality to the chronicle because all the inconsistencies and retcons are treated at face value. The history you really want to hear is one that accepts that different writers and artists have taken the character in different directions and doesn’t try to make it sound as if every story is part of a coherent whole. Reyer does that quite well.
Unfortunately, the host of the show has the disturbing habit of interjecting continually instead of just letting Reyer talk. He doesn’t actually say anything or steer the narrative, it’s just a long, intermittent stream of uh-huh, yes, alright, mmm-hmmm, right, yes, uh-huh. For an hour and a half.1
My favorite part of the show is when Reyer moves from the Steve Englehart years, considered one of the book’s highlights, to Jack Kirby’s return in 1976. Kirby both wrote and drew the book, and Reyer whispers “It was horrible,” as if saying anything negative about the King was sacrilegious.
It was horrible, though. I remember being bitterly disappointed in the Kirby issues. I was, you see, a big Kirby fan. He was gone from Marvel when I started collecting, but I bought all the monthly books that reprinted the Silver Age stories that he and Stan Lee did. Also, I bought the Marvel Treasury Editions, in which the best of those stories were reprinted at high quality and in an extra large size.
I don’t remember disliking Kirby’s storyline; it was the drawings that put me off. Kirby’s characters had always been on the blocky side—that was part of what made his Ben Grimm so good—but now there was a stiffness about every character that hadn’t been there ten years earlier. It was as if someone were doing a Kirby parody. You don’t see it so much in the covers, especially the one John Romita inked,2 but it was prominent in the panels inside.
My collecting years started at the end of Englehart’s Nomad series, and I remember him also as the writer of Doctor Strange and the Avengers. The Talking Comics people interviewed him in a special episode also timed to coincide with the release of The Winter Soldier. I’m a sucker for stories told by the people who made the comics I read, so I’m probably not the best judge of this interview: I wish it could have gone on longer. I loved hearing him talk about the Secret Empire storyline, Nomad, and the Rutland Halloween crossover.
It was also interesting to hear about the kinds of sales comics racked up in those days. What’s considered a big seller now would have been on the chopping block back then.
Of course, I also listened to The Incomparable’s Winter Soldier episode and will probably listen to it again after I see the movie. The spoiler horn goes off early, but that doesn’t bother me. One good thing about getting older is that by the time I see the movie, I’ll have forgotten the spoilers. Well, not the big one, but I knew that one already.
I may have been especially sensitive to this because I listened to the show on a day in which I had a phone call with a client who added a drawn out mmmmmmmmmm-hmmmmmmmmm to the end of every one of my sentences. ↩
I’m surprised I didn’t pee my pants when I bought Captain America 193. Jack Kirby and John Romita collaborating on a cover that I was able to buy new off the spinner rack! ↩
April 15th, 2014 at 9:41 pm by Dr. Drang
I ran across this article by Chris Beckett, “The Underrated, Universal Appeal of Science Fiction,” today during lunch while I was reading something else posted at The Atlantic. Later in the day, I noticed that both Dan Frakes and Jason Snell tweeted links to it—approvingly, I believe.
I don’t disapprove of the article. It’s nicely written and the thesis—science fiction deserves respect!—is well supported. But the topic is awfully stale. Defensive articles like this were thick on the ground back when I was first getting into science fiction in the late 70s. The only difference between those and Beckett’s are the examples of stories that don’t get classified as science fiction because mainstream critics like them. Back then, the examples were Brave New World and 1984; now, they’re The Handmaid’s Tale and… 1984. Some things are evergreen, I guess.
Outside of the articles, though, there are some significant differences between the acceptance of science fiction then and now. First, science fiction has taken over popular culture. As I said a few years ago,
But you have to remember that science fiction was a film ghetto before Star Wars. Not only were the movies artistically bad (for every 2001, there were a hundred Logan’s Runs, and sf was still fighting the legacy of the low-budget BEM films of the ’50s), they regularly failed at the box office.
Take a look at this list of top grossing movies by year. Before 1977, science fiction and fantasy are hard to find; after 1977, they dominate. This may not be giving science fiction writers the kind of literary acknowledgement Beckett wants, but their work is much more likely to optioned for film adaptation, which is not only lucrative, it also provides an opportunity for the work to reach a huge audience.
And it’s not as if there’s no literary acknowledgement. Look at the short bio at the bottom of Beckett’s article:
CHRIS BECKETT is a university lecturer based in Cambridge. His short stories have appeared in Interzone and Asimov’s, and he is the author of Dark Eden and the short-story collection The Turing Test.
I know Beckett’s university position is not as a teacher of science fiction, but he does speak at academic conferences on science fiction, something you’d have been hard pressed to find in the 70s. Yes, there were a few science fiction classes being taught at universities back then. James Gunn was doing it at University of Kansas (there’s now a Gunn Center for the Study of Science Fiction there), but he was a pioneer. Now, science fiction classes are everywhere—the halls of academe recognizing science fiction as a topic worthy of study.
Despite these improvements, I’m sympathetic to Beckett’s lament that people’s eyes glaze over when he introduces himself as a science fiction writer. No one’s more familiar with that situation than an engineer.
April 13th, 2014 at 11:44 pm by Dr. Drang
When I checked my RSS subscriptions this morning, I found two followups to my recent man page post, one by Nathan Grigg and one by Rob Wells. These came after several tweets and emails on the topic. Everyone has their own favorite way to get at man pages. I don’t think any of the suggestions I was given will become my favorite way, but I thought it worth mentioning some of them. You never know what will click with you.
To recap, here’s the problem everyone wants to solve:
You’re in the middle of typing a command at the Terminal, and you realize you need to look up an option or some other aspect of the command in its man page. You can’t issue the man command without deleting what you’ve already typed, which might be extensive if you’re putting together a long pipeline. What’ll you do? What will you do?1
Nathan’s trick is specific to the zsh shell, but there’s a similiar—albeit slightly slower—technique available to bash users. In a nutshell, Nathan saves the half-written command into a sort of buffer or command stack that zsh has, opens the man page, then pulls the half-written command back after finding what he needed. As Nathan points out, the most useful thing about this technique is
… it is useful beyond just looking at manuals. Often while typing some command, I realize I need a quick mkdir or cd or even ls before I’m ready to execute.
Personally, I wouldn’t use this for reading man pages because I like having the man page in a separate window, but I’ve often found myself constructing a long command only to realize I’m in the wrong directory and have to stop to
cd to the right place.
As it happens, there’s a set of keystrokes you can use in any shell that do what Nathan does almost as efficiently. They’re part of the Emacs keybindings that Mac programs have enabled by default.2 Control-U deletes everything on the command line from the cursor back to the beginning, putting it in a special “kill ring,” which is like the Mac’s Clipboard, but separate from it. You can then type
cd or whatever command you need, and when that command is finished, bring back (“yank”) the half-written one from the kill ring with Control-Y.
Several people mentioned the Control-U, Control-Y trick. I’d never thought of it for man pages because, as I say, I prefer reading them in a separate window as I look at the command I’m constructing. But it’s a great trick to know when you realize you need to run a command before the one you’re in the middle of building.
Invoking this from LaunchBar will bring up the same Terminal window that appears when you use the Control-click method I described. Several people told me about ways they used
x-man-page://. It, like
pbpaste, is a holdover from the days when Apple appreciated the Unix users among its customer base and provided nice tools for them. Memories…
Rob also mentioned Dash, the multi-language documentation browser from Bogdan Popescu. As I said in a Twitter conversation with Ryan Lane, who also recommended it, I’ve tried Dash but it’s never stuck with me. I should probably give it another look.
I appreciate all the suggestions, including those I didn’t mention here. One thing I noticed about all of them is that they’re very keyboard-centric. I suspect the suggesters were all slightly appalled by the notion of using the mouse or trackpad to bring up a man page. I’m sympathetic to the notion that keyboarding is faster—I’ve certainly created my share of keyboard shortcuts—but I’m not convinced keyboarding is faster in this case. And I’m always cognizant of this bit of wisdom from Bruce Tognazzini:
We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:
- Test subjects consistently report that keyboarding is faster than mousing.
- The stopwatch consistently proves mousing is faster than keyboarding.
This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster.
People new to the mouse find the process of acquiring it every time they want to do anything other than type to be incredibly time-wasting. And therein lies the very advantage of the mouse: it is boring to find it because the two-second search does not require high-level cognitive engagement.
It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist.
While the keyboard users in this case feels as though they have gained two seconds over the mouse users, the opposite is really the case. Because while the keyboard users have been engaged in a process so fascinating that they have experienced amnesia, the mouse users have been so disengaged that they have been able to continue thinking about the task they are trying to accomplish. They have not had to set their task aside to think about or remember abstract symbols.
Keyboarding with LaunchBar to get to a file or application is certainly faster than using the mouse to dig around in folders. I suspect, however, that Control-clicking a word that’s on the very line you’re editing is faster than keyboarding. But maybe I think that because I’m a slow typist.
Benny Kjær Nielsen (you know, the MailMate guy) tweeted me this morning about the adaptive man page command in Terminal’s menu. It’s named , where xxx is the command to the left of the cursor. It’s keyboard equivalent is given as ⌃⌘?, which really means ⌃⌘⇧/.
It’s a technique worth knowing, but I doubt I’ll use it much. Two reasons:
- The ⌃⌘⇧ combination feels very clumsy to me. I’m OK with the ⌃⌥⌘ three-key combo because they’re all in a row, but when the Shift key screws up the alignment and makes me have to look down at what I’m doing. I could, of course, change the default shortcut, but that leads to the second reason.
It’s kind of dumb about what it considers to be the command to the left of the cursor. If, for example, you type
and then type ⌃⌘⇧/, you’ll get a new Terminal window telling you that there’s no man page for the
ncommand. It’s smart enough to not include the hyphen, but somehow not smart enough to know that the hyphen means it isn’t a command.
Since I often find myself partway through a set of options when I realize I need to look something up, this second problem will make the shortcut more a source of confusion than a help. It may work well for you, but I’ll stick with Control-clicking.