Re: Controls & Key Equivalents

On Nov 23, 2010, at 1:36 PM, Kyle Sluder wrote:

> On Tue, Nov 23, 2010 at 9:36 AM, David Dunham <[email protected]> wrote:
>> Eric is probably better off implementing Accessibility, so that all users can operate his app with keystrokes, rather than the few who can remember the obscure shortcuts.
> 
> Agreed!

Unless I am missing something, there is nothing for me to do to implement the keystroke control of my application unless I am writing my own custom controls. It would appear the only thing necessary is for the user to go to the Keyboard System Preference pane and select "All controls" for Full Keyboard Access. Unless I am mistaken, all standard Cocoa controls support the keystroke accessibility features and the Accessibility documentation describes what it necessary for custom controls to support full keyboard access.

There are power users out there to would like to press Cmd-, to bring up a Preference dialog and then press Cmd-T (for example) to change the state of a checkbox on that Preference dialog, and then press Return to dismiss the dialog. If this is a preference they often need to change, the obscure shortcut for most will be quickly learned and may be faster to change with the keyboard then with the mouse. The keyboard Accessibility features do not appear to offer the same speed of access as that checkbox may be in the middle of the dialog forcing the user to press several keys to navigate to it and then change its state. While I haven't seen anything related to this, I am wondering if the Accessibility features of Mac OS X might be connected to the key equivalents for controls and, when Full Keyboard Access is enabled, might provide some standard way to display the key equivalents to the user...anyone know?

So, the question still remains how to appropriately let the user know there is a key equivalent when that checkbox might be in the middle of the dialog and there may also be 10 or more of them, each with their own key equivalent. 

There appear to be 5 options:

1. Note the key equivalent in the documentation only

2. Place the information in a tooltip for the control

3. When the user holds down the command key, append the key equivalent to the label of the control. BBEdit, for example, does this on it's "save changes" sheet...the Don't Save button becomes Don't Save Cmd-D. Although, I did note that Text Edit does not offer the same feature, although, Cmd-D still maps to Don't Save. I'm curious, who you think has done the right thing here and why?

4. When the user holds down the command key, replace the label of the control with the key equivalent.

5. Since controls can be assigned attributed strings, always use a character in the label for the key equivalent and underline the character. Users will learn that means they can press Cmd-<char> for that control. This was the most preferred option when posed to http://ui.stackexchange.com - http://bit.ly/f5Wv3E



Personally, I am leaning towards either #3 or #5 and probably more towards #3 because at least I can point to one respected application that does something kinda, sorta (but not really) similar.



Of course, I do find it interesting that the HIG speaks against such functionality in general:

You should provide keyboard shortcuts only for frequently used commands, not for every command. Presenting the user with too many keyboard shortcuts can be overwhelming and can make an application's user interface seem difficult to learn.

 In general, it’s not a good idea to assign other keyboard shortcuts to buttons.

and that (unless I am missed something), while Apple does allow key equivalents to be assigned to controls, they have provided no standard way to present those key equivalents to the user which may enforce the notion that this shouldn't be done at all and that no other modern Cocoa application appears to offer such functionality.