设计键盘快捷键的最佳做法 [英] Best practices for designing keyboard shortcuts

问题描述

我非常喜欢键盘快捷键.如果某些功能或操作没有快捷方式，我倾向于编写一个小程序，并在其上附加 Ctrl + Alt + [key]快捷方式.

昨天，在使用Visual Studio进行编码时，我开始考虑他们分配快捷方式的程度.有大量的命令，但大多数命令还是直观的，没有一个与其他系统范围的按键组合重叠.唯一的例外是 Ctrl + W ，这使我烦恼，它默认情况下不会关闭活动选项卡.

在为自己的程序分配键盘快捷键时应牢记的最佳做法是什么?

除了特定功能(eq Ctrl + S ， Ctrl + W ....)

在小型应用程序中，我认为最好使用 Ctrl 作为修饰键，但是在较大的应用程序中呢?是否应该有两个修饰键( Shift / Alt ?)或在Visual Studio中显示类似的键?应该只将 Shift 用于反转功能( Ctrl + Shift + Tab ，向后滚动选项卡)?

或者说什么时候托盘中的程序最小化运行，或者根本没有GUI.应该在该组合中使用Windows键吗?

解决方案

• 从常见的Windows绑定开始: Ctrl + C 复制， Ctrl + S 保存等.当用户尝试使用这些最常见的热键中的任何一个时，都不要感到惊讶.

• 查看具有与您自己相似的功能的其他应用程序.例如如果您进行文字处理(应用文字样式)之类的操作，请查看Word.如果您有绘画工具之类的东西，也许看看Photoshop等.

• 列出程序完成"时希望在程序中包含的所有命令.这可能比现在可用的更多，并且其中一些命令可能永远不会出现，但是此练习可以帮助您避免在每个发行版中都更改热键-从一开始就保留它们.

• 现在，从列表中删除您认为一天不会使用多次的所有命令.例如<(c)opy"的 Ctrl + C 很好，因为每小时最多可以使用60次.但是 Ctrl + C 表示(C)如果发布了新版本的话就太难了"，这是一个不好的热键，因为用户不太可能希望这样做一次以上.一周或更短的时间.

• 如果不确定热键的使用频率，请将其保留.最好有很多备用键可用于将来的功能，而不是绑定键盘上的每个键，然后必须不断更改绑定.使用更少的热键可以降低用户的复杂性，需要进行的测试数量以及杂乱的按键操作可能会导致用户不希望做的事情.如果用户真的想要一个热键，他们会要求您添加它.但是通常，只有真正常用的功能才需要热键.

• 绘制一个带有修饰符列的字母电子表格.在此网格中输入您期望的高使用率命令集，并确定每个单元的优先级，以使最重要的命令使用最简单，最明显的快捷键.在许多情况下，您会发现只有一个命令落在特定键上.另外，请尝试将同一命令上的相关命令归为一组，但使用不同的( Ctrl / Shift / Alt )修饰符(例如 Ctrl + S 保存， Ctrl + Shift + S 全部保存).这将为您提供所有无法轻松映射到明显键的命令.考虑重命名某些选项是否可以帮助转移周围的东西以获得更好的映射(例如，"Options"，"Settings"或"Preferences"之类的同义词可以帮助您找到更容易映射到良好记忆功能的命令名称)

• 现在剩下的命令无法绑定到最明显的键(例如，"Cut"不能绑定至 Ctrl + C ，因为它用于复制"，所以在菜单中通常会看到它绑定为Edit-> cu(T)和Edit->(C)opy，因此您可以考虑使用 Ctrl + T 以确保与菜单记忆方法相一致(尽管在这种特殊情况下，当然存在预先存在的标准， Ctrl + X =剪切).

• 添加按键绑定系统，以便您的用户可以添加/更改热键以自定义其UI.

• 请尽可能保持一致.如您所指出的，平移通常用于反转方向"导航命令.选择时，请遵循Windows约定( Ctrl 进行切换， Shift 进行扩展).但主要是，在整个应用程序中保持一致-在大多数情况下， Ctrl ， Shift 和 Shift + Ctrl 进行了操作，但如果可能，请尝试对所有命令绑定应用类似的逻辑.

• 在使用 Alt 作为修饰符时要小心.用户应该能够使用 Alt 在菜单系统中进行导航.因此，实际上，您应该只将 Alt 与 Ctrl / Shift 结合使用，并确保您的热键处理不会破坏正常的 Alt 处理.

• 如果您的程序中有很多文本输入，请避免将未经修改的键用作热键.当您按下 M 来执行某项操作时，这确实很烦人，不仅不会发生这种情况，而且还会在用户界面的随机部分的文本输入字段中显示一个M！将其设置为 Ctrl + M 或 Ctrl + Shift + M 容易避免.即使用户将输入焦点放在特定位置，这也允许热键激活命令，从而避免任何讨厌的方式.

• 如果使用多键序列，请不要混合使用修饰符.例如， ctrl + A ， ctrl + B 可以，但是 ctrl + A + B 或 ctrl + A ， shift + B 不好，因为用户必须在序列中途释放 ctrl ctrl. (Visual Studio测试命令，我在跟你说话！)

• 除非您是输入焦点应用程序，否则不要在热键上执行任何操作.例如有一个非常受欢迎的程序(默认情况下)会抓取 Ctrl + A ，因此每次您尝试在不相关的程序中选择全部时，都会产生非常烦人的 .为什么哦为什么！如果您认为全局热键是个好主意，请将其添加为用户可以选择打开的选项，这样他们就会知道该热键存在.

• 我同意Visual Studio具有良好的默认绑定集.但是从很多方面来说，它的设计都非常糟糕-VS2010是我使用的VS的第一个版本，并且没有对以前版本的核心键绑定进行令人沮丧的重大突破.这通常是升级到新VS版本的最痛苦的部分.令我感到非常高兴和惊讶的是，在VS2010中，默认情况下最常见的功能(例如内部版本")仍在相同的热键上！希望他们现在能坚持一段时间...

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

这篇关于设计键盘快捷键的最佳做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！