> In light of the great opportunity for user confusion - because a little rectangle around the number is hardly a "clear" indicator - and the reality that many users do not have a number pad, I think the solution I'd recommend is to rethink the choice of key equivalents so as to obviate the problem.

So a rounded rect around a number is not a clear indictor that it's a different character? People have been able to clearly see the difference between í, ì, and i for hundreds of years, so that's a pretty lame excuse. I've never been confused seeing these numpad glyphs in good ol' Carbon menus.

> That said, if you insist on going down this path, it might work to include NSNumericPadKeyMask in the key equivalent mask for the item.

This only affects the key used to trigger it, not the appearance of the glyph in the menu item.

> But seriously: Think about how much you want to annoy notebook users first.

OK, we'll annoy them by taking away key equivs they've been used to using in our app for the past umpteen years.

Why is it that people on these lists prefer giving their opinions instead of technical knowledge?

Because we're trying to be helpful and sometimes the best answer to "How do I fight the OS?" is "Maybe you should revisit the perceived need to do so." You *were* asking for help, right?

You're absolutely correct that a user would note that there's a difference between a 1 and a 1 in a roundrect showing as the menu equivalent. No argument there at all. The confusion lies in sussing out what the implications of that different glyph are. To extend your example, it's not so much about distinguishing diacritical marks as knowing how they affect pronunciation. I've been a Mac user since 1985, and routinely use and write for several different platforms. I can't say it would occur to me that putting a number in a roundrect means "use the numeric keypad." I *may* have seen it once or twice in the last few decades, but it's not a common idiom. You're relying on a learned behavior that's difficult or impossible to invoke for an increasing chunk of your potential market. Is that really something you want to vehemently defend instead of thinking maybe it's *less* problematic to ask existing users - who may already be unable to use the keystroke anyway, regardless of how many years your program has been offering the option - to learn something different?

Or maybe you just prefer to insult those who can't use your program to its fullest effect and those who want to help you change that fact.

> You're relying on a learned behavior that's difficult or impossible to invoke for an increasing chunk of your potential market. Is that really something you want to vehemently defend instead of thinking maybe it's *less* problematic to ask existing users - who may already be unable to use the keystroke anyway, regardless of how many years your program has been offering the option - to learn something different?
>
> Or maybe you just prefer to insult those who can't use your program to its fullest effect and those who want to help you change that fact.

In this thread, there are three separate issues being conflated. I've quoted Greg, as an example of where this conflation leads, but I'm not picking on his response specifically. In fact, it's perfectly rational -- just a bit out of context, IMO.

The issues are:

1. The software Steve is dealing with (Finale, I believe he has stated earlier) has special needs. I've used music notation software for note-by-note entry in the past, and it's a horrendous chore without some dedicated keys to assist. You can use a MIDI (piano) keyboard for dedicating keys to pitch entry, but you still need to use keys on the computer keyboard for duration (quarter notes, eighth notes, dotted notes, etc) entry. This used to be what the numeric keypad was dedicated to in Finale, and I guess it still is.

It's no use saying that Steve needs to consider whether users *have* a numeric keypad. For users of music notation software that do a lot of note entry, it more or less necessary to have the MIDI keyboard (or to suffer a lot of pain), and it's not unreasonable to predict that such users might also acquire a numeric keypad, if their Mac doesn't already have one.

Such software has already established the precedent that it needs lots and lots of keyboard shortcuts. (Finale is well over 10 years old, IIRC.) Steve isn't condemning users to a keyboard shortcut nightmare, he's continuing a well-established though specialized UI pattern. On this point I 100% agree with Steve's right to continue the tradition without molestation.

2. Cocoa doesn't do for shortcut display in menus what Carbon did, and Steve thinks it should. On this point I 100% disagree with his position, or at least his moral outrage. It might be that Cocoa doesn't implement what he's asking for simply because no one asked before, in which case the functionality may appear in the future. On the other hand, if Apple is reluctant to sanction *generally* that apps should make a distinction between numeric keys and numeric keypad keys, I think it's well within Apple's rights to limit the scope of its own frameworks to match such guidelines. In that case, I think Steve needs to quit whining that Apple engineers aren't doing his job for him, and implement his own menu drawing for his specialized case.

3. It's a question whether boxed numerals displayed in a menu are a *discoverable* design for presenting numeric keypad shortcuts to the user. On this issue, I tend to agree with the opinions expressed by Greg and Kyle that there's really no discoverable approach that will educate users directly from the menu appearance. (If this were on non-Mac computers, then a representation like "Num 1" might be an acceptable solution, because non-Mac numeric keypads have a "Num Lock" key, which gives the user a clue. But that doesn't help with a Mac numeric keypad.)

Under the circumstances, I think there's no good solution except directing users to the documentation or help or tutorial which makes the connection between the menu appearance and the corresponding keys. (Finale and similar apps used to come with a quick-reference card that showed this sort of information. I have no idea if it still does.)

However, I don't see a problem in having a discussion on this issue. Someone may come up with a clever idea that even Steve likes.