Re: Controls & Key Equivalents

On Dec 2, 2010, at 16:48, Eric Gorr wrote:

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

I do know, and you should too by now: the answer is no.

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

We already gave the answer many times.

1. ask a question
2. someone answers the question
3. don't like the answer, ask the same question again
4. someone gives the same answer
5. don't like the answer, ask again
6. someone gives the same answer again
7. don't like the answer, ask again
...

How many times do you want to repeat?

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

Obvious: TextEdit does it right. It does not even do what it does itself, as the SYSTEM does this. It's even documented! I already said this in my FIRST reply for this particular situation.

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

Obviously, 3,4,5 are certainly wrong. Apple wouldn't have removed this if they thought this was the correct way of doing it.

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

I say it yet again: ALLOW is not the same as SHOULD.

"may enforce the notion"? Sorry, we are way beyond that by now, several people here have already told you that this IS the situation.

Christiaan