|
From: Anthony K. <ant...@sb...> - 2007-04-20 14:34:39
|
Bernard Bel wrote on 4/18/07 11:56 AM: > Rainer has very well exposed the headache of key-shortcuts on > international keyboards. I could write a variation of his message > adapted to French keyboards... > For this reason, for instance, you get the "help" question mark either > typing Command-/ and Command-? as it covers the cases of both keyboards. Yes, I think that this is a good practice even if only designing for a single keyboard layout. In general, I believe that the use of non-alphabetic keys for shortcuts should allow either the un-modified or the shifted character to invoke the command. So, while the shortcut might be shown as Command-? in the menu, a U.S. user should not have to type Command-shift-/, Command-/ should work. The problem with this approach -- that I now understand more clearly -- is that these characters are paired differently on other keyboard layouts and supporting every layout could be a headache or could be impossible. I have also found in my experiments that the Caps-lock key can cause more problems. When it is on, _some_ of the characters produced with Option get changed to their shifted equivalents but others do not (generally seems to be when option-shift produces a capitalized version of the same character). So, currently, with the caps-lock key on, BP's shortcuts like Command-Option-A and Command-Option-O do not work. > According to the Mac guidelines every command accessed by a shortcut > should also be accessible from a menu. Therefore, to avoid bypassing too > many MacOS X commands we might reduce the number of shortcuts. BP does follow the guideline of keeping all commands in the menus pretty closely. The only exceptions would be text editing shortcuts and the shortcuts for the prototypes window. Reducing the number of shortcuts is a viable option. I discovered yesterday that while OS X will yield Command-H to BP, it will not yield Command-Option-H (used for displaying the tokenized alphabet) the first time that it is pressed. It initially steals this keypress to hide all other applications. If they are already hidden, then it will pass the keypress to BP. (Confusing!) > I like Anthony's idea of using command-p for playing either the selection > in a text window or the sound-object prototype when the prototype window > is in front. It would be great to modify the menu according to this > context, and it is not very difficult to do it (unless MacOS X made it > complex). This will be easy to implement. I hope to get it done today. > The idea of a toolbar with clickable buttons is attractive, though it > would be time-consuming to implement. However it has drawbacks. Text > editing toolbars are easy to use because there is always the same type of > icons for text formating, text alignment etc. But I feel reluctant to > create BP2 specific icons for operations such as "expand selection" etc. > For this I prefer verbose buttons on the Control panel. This is exactly how I feel about toolbars with icons. For all but the most commonly used toolbar commands, text labels are easier to understand in my opinion. And I do not think that tool-tips helps this problem -- it reduces productivity to have to constantly mouse-over each toolbar icon to find the one that you want. > I agree with Anthony's suggestion to make Command-; open all 8 setup > windows, and Command-option-; to open only the Top and Bottom settings. > The semicolon is also a lowercase position on French keyboards, and if it > is uppercase in some other languages (which I doubt because it has > something to do with the case of the next word) either users will learn > using the key combination or they will use the menu command. Be careful > that the option key also opens the 8 windows if launched from the menu. I have finished implementing this to work in this manner. However, I would like to reconsider the choice of shortcuts since Command-Option-; may not work on many keyboards. > Abandonning Command-H for the alphabet window is fair. In fact we might > drop the shortcut for the alphabet window because it is not one that is > often opened and closed, unlike the data and grammar windows. I have not changed this yet. Should I do so? > Command-Y might be reserved for "redo" if later implemented as the > "Trace" window does not really need a shortcut. Command-shift-Z is now usually used for a separate Redo command. Thanks for all of the feedback. I think it is very important for us to ensure that BP will work smoothly for users in many countries. My experience with open source software indicates that we are likely to have people all over the world trying BP. In the future, we may even consider enlisting the help of some of our users to localize BP for several languages. Anthony |
