(1 item) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(6 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(4 items) |
|
(2 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(5 items) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(8 items) |
|
(2 items) |
|
(7 items) |
|
(2 items) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(3 items) |
|
(2 items) |
|
(2 items) |
|
(8 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(6 items) |
|
(1 item) |
|
(2 items) |
|
(5 items) |
|
(5 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(16 items) |
|
(10 items) |
|
(27 items) |
|
(15 items) |
|
(15 items) |
|
(13 items) |
|
(16 items) |
|
(15 items) |
Larry O'Brien says in a recent blog:
"By the time you're debating what chords to use to activate obscure functions, I think you've gone too far. Gimme' 10 (okay, 12) function keys and menu-based accelerators."
Unfortunately, I have to disagree. Larry's suggestion sounds perfectly sensible, and I feel like I'm committing some kind of usability crime by disagreeing with him here, but I can't ignore my own experience. I know that I'd find VS.NET unusable with so few shortcus. There are far more than 10 (or even 12) things that I do on a regular basis in VS.NET, none of which I want to be forced to go through the menu system to use.
These include (but are not limited to) in no particular order, Build (Ctrl-Shift-B), Go To Definition (F12), Intellisense Complete or bring up list if ambiguous (Ctrl-Space), Bring Up Intellisense List Even if Match Is Unambiguous (Ctrl-J), Bring Up Parameter List Intellisense (Ctrl-Shift-Space), Save (Ctrl-S), Switch to Code View (F7), Switch to Design View (Shift-F7), Help Index (Ctrl-Alt-F2, and then Alt-L to get the focus in the right place; that last step won't be required on VS.NET 2005 - yay!), Help Search (Ctrl-Alt-F3), Search dialog (Ctrl-F), Search and Replace (Ctrl-H), Reformat code (Ctrl-K, F), search for next instance of whatever is selected, or whatever word is under the cursor if there is no selection (Ctrl-F3), same as previous one but searching up, not down (Ctrl-Shift-F3), Incremental Search (Ctrl-I), Find next instance of whatever the last search found (F3), Find previous instance of whatever the last search found (Shift-F3), Quick Watch window while debugging (Ctrl-Alt-Q), Step Over (F10), Step Into (F11), Step To (Ctrl-F10), switch between source windows (Ctrl-Tab and Ctrl-Shift-Tab).
Oh and of course, all the standard ones that lots of apps support: Ctrl-C, Ctrl-X, and Ctrl-V for the clipboard, Ctrl-P for print, Ctrl-Z and either Ctrl-Shift-Z or Ctrl-Y for undo and redo, to pick a few of the more popular ones.
There's a whole host more VS.NET shortcuts that I could list that I use as regularly as these. I could probably come up with a similarly large list for Word. There's no way that 12 function keys is possibly going to be enough for any program which is your primary tool.
What's worse is that the numeric function key bindings are doomed to be arbitrary - at least with those that use letters there is some scope for mnemonics.
Of course some users will never use this many shortcuts. I only use shorcuts this extensively on the applications I use the most. I think I'd struggle to list 10 accelerators for Excel, because although I use it, it's not one of my primary tools. An extensive set of accelerators is not something likely to benefit the beginner, or the casual user. These things are for people who live and breathe the program.
With his Lotus 1-2-3 example, Larry alludes to something Don mentioned. If you're going to use sequences of keys as shortcuts, why not just use the menu accelerators? This seems like an attractive idea, as it reduces the number of different structures you have to learn - you can associate the key bindings you learn with the menu structures you know, rather than having to memorise both independently. The only problem I have with that is that it's not obvious to me that a good hiearchy for a menu structure will automatically constitute a good approach for key bindings. Right now, some of the key bindings offer a faster way of getting to things than the menus, even with key sequences involved. (BTW, is a key sequence like Ctrl-K, K a 'chord'? If so, then maybe whoever came up with these things isn't a pianist after all, as I previous suggested. On the piano, chords are things where you hit several keys at once. So Ctrl-Alt-Q feels like playing a chord, but Ctrl-K, K does not.)
For example, Ctrl-Alt-M, 1, or Ctrl-Alt-M, 2 etc. opens Memory Windows 1, 2, etc in VS.NET. Through the menus this is Alt-D, W, M, 1 (2, or whatever). Depending on how you count it, that's either 1 or 2 more presses to go through the menu. (It depends on whether you count individual keys, or 'key presses' in the sense where Alt-D is a single press, as is Ctrl-Alt-M. A 'key press' in this sense is one piece of input. If that seems like a bizarre rule, consider it in the context of typing in text - an uppercase 'A' is just one piece of input, even though you may have to press two keys to get it.)
Admittedly that's not a brilliantly compelling argument. However, I notice that when I have a choice between menu accelerators and keyboard shortcuts, I always prefer the latter for things I use regularly - I prefer to put the effort in to learn the shortcuts, and avoid the menu. I have no idea why. Maybe it's because I don't trust menus to stay still - I know they're configurable on lots of apps. Indeed I know the menu layout changes all the time in VS.NET depending on what kind of mode it's in. The modeless nature of keyboard shortcuts appeals to me. (Well. Almost modeless. There are some mode-specific ones. So maybe that argument falls down too.)