Re: Cocoa-dev Digest, Vol 10, Issue 276
Re: Cocoa-dev Digest, Vol 10, Issue 276
- Subject: Re: Cocoa-dev Digest, Vol 10, Issue 276
- From: Quincey Morris <email@hidden>
- Date: Tue, 07 May 2013 12:25:52 -0700
On May 7, 2013, at 11:12 , gweston <email@hidden> wrote:
> 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.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden