I am a big fan of keyboard shortcuts. If some function or operation doesn’t have shortcut I tend to write a little program and attach Ctrl + Alt + [key] shortcut to it.
Yesterday while coding with Visual Studio I started thinking how well they had assigned the shortcuts. There are enormous amounts of commands and still most of them are intuitive and not a single one overlaps with an other, system wide key combination. Only exception is Ctrl + W and it irritates the hell out of me that it doesn’t close the active tab by default as it should.
What are the best practices that should be kept in mind while assigning keyboard shortcuts to own programs?
What are so common and “reserved” combinations that should not be used other than specific functionality (e.q. Ctrl + S, Ctrl + W….)
In small applications I believe it’s best to use Ctrl as a modifier key, but how about in bigger ones? Should there be two modifier keys (Shift/Alt?) or make like in Visual Studio? Should Shift be used only to reversal functionalities (Ctrl + Shift + Tab, scroll tabs backwards)?
Or how about when program is running minimized in the tray, or doesn’t have GUI at all. Should windows-key be used in that combination?
Start with the common Windows bindings : Ctrl + C to copy, Ctrl + S to save, etc. Users should not be surprised when they try any of these most common hotkeys.
Look at other applications with similar functionality to your own. e.g. if you do something like word processing (applying text styles) then look at Word. If you have something likea drawing tool, maybe look at Photoshop, etc.
Make a list of all the commands you expect to have in your program when it is “finished”. This may be many more than are available now, and some of these commands may never come into being, but this exercise can help you avoid changing hotkeys with every release – reserve them from the start.
Now, delete out of the list all the commands that you think will not be used many times a day. e.g. Ctrl + C for “(C)opy” is good, because that may be used up to 60 times an hour. But Ctrl + C for “(C)heck if new verison has been released” is a bad hotkey, as it’s unlikely users would want to do this more than about once a week or less.
When in doubt about how often a hotkey will be used, leave it out. It’s better to have lots of spare keys available for future features than to bind every key on the keyboard and then have to keep changing the bindings. Using fewer hotkeys reduces complexity for the user, the amount of testing you need to do, and the chance of a stray keypress doing something the user didn’t intend. If users really want a hotkey, they’ll ask for it and you can add it. But in general only the really commonly used features need hotkeys.
Draw up a spreadsheet of letters with columns for modifiers. Enter your expected high-usage command set into this grid, and prioritise each cell to make the most important commands use the simplest and most obvious key shortcut. In many cases you’ll find that only one command falls onto a specific key. Also try to group related commands on the same key but with different (Ctrl/Shift/Alt) modifiers (e.g. Ctrl + S save, Ctrl + Shift + S save-all). This will leave you with any commands that can’t easily be mapped to an obvious key. Consider if renaming some options might help shift things around to achieve a better mapping (e.g. synonyms like “Options”, “Settings”, or “Preferences” may help you find command names that map more readily to good mnemnomics)
You are now left with commands that can’t be bound to the most obvious key (e.g. “Cut” can’t be bound to Ctrl + C because it’s used for “Copy”, so in menus you’ll usually see it bound as Edit->cu(T) and Edit->(C)opy. So you could consider using Ctrl + T for consistency with the menu mnemnomic approach (although in this particular case, there is of course a pre-existing standard, Ctrl + X = cut).
Add a key binding system so your users can add/alter hotkeys to customise their UI.
Where possible, try to be consistent. As you’ve pointed out, shift is often used to “reverse the direction” of a navigation command. When selecting, follow the windows conventions (Ctrl to toggle, Shift to extend). But mainly, be consistent across your application – it doesn’t really matter in most cases what effect Ctrl, Shift, and Shift + Ctrl have on an operation, but if possible try to apply similar logic to all your command bindings.
Be careful about using Alt as a modifier. The user should be able to use Alt to navigate in the menu system. So really you should only use Alt in conjunction with Ctrl/Shift, and make sure that your hotkey handling doesn’t break the normal Alt handling that the menu system provides.
If your program has much text entry, then avoid using unmodified keys for hotkeys. It’s really annoying when you press M to do something and not only does that thing not happen, but an M appears in a text entry field in some random part of your UI! Make it Ctrl + M or Ctrl + Shift + M and the problem is easily avoided. This also allows hotkeys to activate commands even while the user has their input focus in a specific place, avoiding any nasty modality.
If you use multi-key sequences, then don’t mix-and-match the modifiers. For example, ctrl+A, ctrl+B is fine, but ctrl+A+B or ctrl+A, shift+B are bad as the user has to release ctrlctrl half-way through the sequence. (Visual Studio Test commands, I’m talking to you!)
Don’t do things on hotkeys unless you are the input focus application. e.g. there is a certain very popular program that (by default) grabs Ctrl + A and thus does something extremely annoying every time you try to select all in an unrelated program. WHY oh WHY!? If you think a global hotkey is a great idea, then add it as an option that users can turn on if they want it, so they will be aware that the hotkey exists.
I’d agree that Visual Studio has a good default set of bindings. But in many ways it was very poorly designed – VS2010 is the first ever edition of VS that I’ve used that hasn’t made frustratingly large breaking changes to the core key bindings of the previous version. This was usually the most painful part of upgrading to a new VS version. I was very pleased and surprised to find that the most common features (like “build”) were still on the same hotkeys by default in VS2010! Hopefully they’ll stick with them for a while now…