J and K make poor navigation shortcuts
In a post yesterday 37 Signals reported another instance of J and K being adopted for navigating through a list. Hmm. Great functionality, but J and K are unfortunate choices for navigation shortcuts.
Keyboard shortcuts are great if you can remember them, which you can do best when they fit a model of some kind.
One useful model is abbreviation, where the key you press matches the first letter of the word describing the action you’re performing. Pressing n and p to navigate a list is easier to remember once you appreciate that they represent next and previous.
Another model is position. Using the arrow keys to navigate is easy to remember because the key you press causes the selection onscreen to move in the corresponding direction. Using the ASDW keys to navigate is a common substitute for keyboards lacking arrow keys and is almost as easy to remember once you associate ASDW by physical position with left-down-right-up. (Forget abbreviation here: D does not mean down, nor W west. Just remember their positions, and think of them like arrow keys.)
Safari uses [ and ] to move back and forward through your browsing history. This works reasonably well because the two keys form a matched set, and because you press the left key to move back and the right key to move forward.
If you’re wondering how left and right mean back and forward, consider a book: if you’re halfway through a book, the pages on the left which you’ve already read represent your reading past, while the pages on the right which you’ve yet to read represent your reading future.
Hardest of all to remember is convention, which means no model at all. People have always done it that way, and so will you. Conventions are often practical and exist because a choice had to be made, like whether cars drive on the left side of the road or the right. Arbitrary, but useful.
Now, back to those J and K keys. They’re not abbreviations and they’re not positionally descriptive, so they must be conventions—and they are, apparently originating from Emacs, a 30-year-old text editor. The J key has long had a little bump on it to aid touch-typists, which might have had something to do with it, but the more important point is that many people have adopted the convention, and so the convention persists.
But the unsuitability of J and K for navigation shortcuts isn’t that they’re conventional, though that’s hardly a strength. Rather, it’s that they’re used for navigation but confound attempts to model that navigation positionally. Pressing J for forward and K for back confuse precisely because they flout a longer-standing tradition. J lies to the left of K on the keyboard, and centuries spent reading books have established that left means back and right forward. Therefore, when two adjacent keys are used to move back and forward, the key on the left should be used for back.
J should mean back and K should mean forward, but they mean the opposite of that. 30 years of convention doesn’t make that any easier to remember. Your only option is to burn those two keys into muscle memory so you don’t have to remember.
And that’s sad.
[ via Daring Fireball ]
Google Reader uses j / k but also provides n / p (next, previous) to navigate between articles. I find I use the n / p more.
Clearly you’ve never used vi
J-K-L playback control is also a common convention in video editing applications like Final Cut, but in this case, J goes back, K stops play/shuttle, and L goes forward. So, not only does the EMACs convention go against abbreviation and position, it also competes with other conventions.
I like the Google approach of using both an older and a newer convention. Though Apple does not do this with J-K-L, they do allow for the remapping of key-commands in Final Cut.
I’m not sure why Fffffound (or Google, or anyone for that matter) would use an obscure and illogical EMACs convention for navigating anything in this day and age.
-systemsboy
Sorry for the ridiculously late and lengthy reply. I never reply to blog posts, but I have to now because it will bug me if I don’t.
Please keep in mind that I am not defending j/k at all. While knowing of it, I have never used this particular shortcut before.
First things first, that shortcut has absolutely nothing to do with Emacs, but with vi. Please don’t confuse them; this is the biggest “holy war” in all of computing, the equivalent of mixing up Steve Jobs and Bill Gates. In both editors (which are still in heavy use today), the arrow keys work for navigation by default, and in Emacs and modern vi derivatives like vim, all the shortcuts can be remapped to whatever you like anyway. The point of Emacs is that despite being old, you will never be locked into archaic conventions. Literally *anything* about its behavior can be adjusted to taste. The upside is the payoff of being able to “live” in Emacs instead of being chained to a particular OS, and these shortcut mappings will continue to be useful in the future for another 30 years.
Secondly, j/k don’t move back and forward in the sense that you mean. They move down and up. Remember the old Apple keyboards from the 80s with the arrow keys in a row, before they eventually realized their mistake and switched to the natural-mapping cross IBM arrangement? The decision to use hjkl was no more or no less illogical than the wasd that is praised here. The difference is that since today essentially all keyboards have arrow keys, there is no reason to use ersatz arrow keys of any type. If you criticize one, criticize them all.
While we’re at it, the level of Eurocentrism in this entry is quite high. Left/back for right/forward only holds in left-to-right cultures. If directions must be used, up/down hold across all cultures, due to the constant reinforcement we receive from gravity each day.
Instead of looking down on convention, I think you should realize it is the most powerful of all. In a new app today, would you want undo/redo to be mapped to cmd-z/y or cmd-u/r? Celebrate convention. The encouraged homogeny in interfaces is by far the greatest advantage of the Mac OS environment relative to Windows or Unix.
I think n/p is even worse than j/k. Both are hard to remember since abbreviations are ambiguous. Do I want [b]ack and [f]orward, [n]ext and [p]revious, or [n]ext and [b]ack, left and right, or what? Do I want to [e]xit or e[x]it? At least j/k has the advantage of proximity, being easier to access. Although shift-del to delete/cut and shift-ins to insert/paste make much more sense than cmd-x and cmd-v, Apple’s zxcv paradigm eventually won out over IBM’s CUA simply for being placed next to each other and close to the access key (although wrist experts know that this is actually a bad idea).
At any rate, my opinion is that any program worth using allows you to define the shortcuts and everything else about the interface anyway. This is typically trivial to implement and causes the absolute least memorization problems. Why would you use anything that forces you to use *their* shortcuts? Why would you put up with having to use a different set of shortcuts for a different program? For novices who are customization-averse, it should definitely be standard for keyboards to have dedicated common keys (for cut, forward, undo, etc) by now. cmd-z and the like are kludges and unnecessary evils. Instead of discussing n/p vs j/k, look at the bigger picture.
KJ, a delightful response! When I originally attempted to learn the origin of the j/k navigation convention, the Emacs sources outnumbered the vi sources, but not by a great margin. Thanks for the clarification.
If the original navigational function of j/k was down/up, it reflected the vertical orientation of terminals, but today’s uses are more varied. In Gmail, for instance, when you’re viewing a message, there’s no vertical list and the visible links say Next and Previous. Today, and more generally, the j/k keys traverse a list, regardless of the orientation of that list.
Your comment about Apple’s zxcv paradigm was apt and appreciated, but overlooks, I think, a crucial distinction. Whereas Apple was creating a convention for something new to the world, cut/copy/paste, traversing a list is not new and is familiar to anyone who has read a book or has flipped a wall calendar from May to June. Apple was free to choose a convention, but the creators of vi had to consider existing convention. My central point is that they chose poorly. If the convention was to represent up/down, two keys vertically related would have made more sense, and barring that, if a concession was made to favor the easier side-by-side motions of two horizontally adjacent keys, j should have been Back and k Forward. Yes, that’s Eurocentric, but it had to go one way or the other, and Eurocentric remains a reasonable default.
I also liked your comment that customization eases this issue, but most users would never customize these shortcuts, so the defaults would remain the de facto standard.
And you’re right that keyboards should support navigation of this sort with dedicated keys. It’s surprising that they don’t. There are many conventions, though, and keyboards would grow pretty large if they attempted to accommodate them all.
Responding to an old post, but…
John, you wrote:”Apple was free to choose a convention, but the creators of vi had to consider existing convention.”
And so they did, but I’d question whether they chose poorly, as you claim. See, for example, http://en.wikipedia.org/wiki/Vi#History – as the article notes, on the machine that Bill Joy (the author of the original vi editor) was using, the HJKL keys would have had arrow key markings on them.
Even though vi-style cursor movement is now a fossil remnant of hardware design choices, it is not without its advantages. Just as Apple chose XCV in part due to the physical proximity of the cluster, with HJKL one has the ability to issue movement commands without moving one’s fingers from the home row. A few days of playing Rogue, (http://en.wikipedia.org/wiki/Rogue_%28computer_game%29) would burn the convention into your hindbrain…
…and once the convention’s there, it sticks. vi makes few concessions to novices; rather, it’s often cited as an example of optimizing for experts, an aspect of interface design that’s far too often overlooked. vi keybindings continue to be used because programmers continue to use vi, and because its conventions saturate UNIX culture. Features such as GMail’s keybindings are, to a certain extent, “expert” features…most users never know they’re there, and wouldn’t care if they did.
As KJ observes, many more “sensible” choices for navigation keys would still be ambiguous. By exploiting convention, app authors leverage the mental shortcuts that some users have already built up. When I first used Google Reader, for example, I was very happy to find it provided vi-style navigation, as it was that much less I had to remember in order to improve my efficiency using the app, and the motions fit neatly with my existing motor memory.
Of course, modern keyboards DO have arrow keys…but they are used for other purposes in web browsers, and web applications co-opt them only at great peril. Using a well-established, non-colliding convention seems like a reasonable approach.