geoff@circus.camex.com (Geoffrey Knauth) (06/15/91)
Has anyone noticed that both of these pick sequences are command-G? Utilities -> User Commands -> Grep Source Services -> Librarian -> Target Are there other examples of re-use of key equivalents? Geoffrey S. Knauth E-Mail: geoff@bos.camex.com Camex / DuPont Imaging Systems Inc. VoiceMail: (617) 426-7550 x451 75 Kneeland Street Reception: (617) 426-3577 Boston, Massachusetts 02111 --standard disclaimers--
eps@toaster.SFSU.EDU (Eric P. Scott) (06/15/91)
In article <2126@camex.COM> geoff@circus.camex.com (Geoffrey Knauth) writes: >Has anyone noticed that both of these pick sequences are command-G? > Utilities -> User Commands -> Grep Source > Services -> Librarian -> Target >Are there other examples of re-use of key equivalents? Sure. How about Command-g for Find Next and Grab. As long as both operations aren't contextually meaningful at the same time, it's not a problem. (I'll probably eat those words later.) -=EPS=-
robertl@bucsf.bu.edu (Robert La Ferla) (06/16/91)
Another one is: Edit->Find->Line Range... Utilities->User Pipes->Indent Shouldn't Interface Builder check to see if you re-use a hot key and warn you? I think so. Robert La Ferla Lotus Development Corporation Advanced Technology Group / NeXT Improv
eps@toaster.SFSU.EDU (Eric P. Scott) (06/16/91)
In article <ROBERTL.91Jun16015807@bucsf.bu.edu> robertl@bucsf.bu.edu (Robert La Ferla) writes: >Shouldn't Interface Builder check to see if you re-use a hot key and warn >you? I think so. Interface Builder doesn't have the context to do this. The Services menu is bound at run time, and NXCommandKeys defaults can remap everything anyway. Besides, you have to give your beta testers something to do. :-) -=EPS=-
eps@toaster.SFSU.EDU (Eric P. Scott) (06/16/91)
In article <ROBERTL.91Jun16015807@bucsf.bu.edu> robertl@bucsf.bu.edu (Robert La Ferla) writes: >Another one is: > >Edit->Find->Line Range... >Utilities->User Pipes->Indent Nope. The first is a lowercase L, the second is a capital I. They look the same on-screen in 12-point Helvetica. -=EPS=-
robertl@bucsf.bu.edu (Robert La Ferla) (06/17/91)
Thanks for pointing this out; I am using Helvetica as a system font. As for Interface Builder checking key equivalents for redundancy, of course it can't check the Services menu. The point is that it can check all of the other menus. Try entering two menu items with the same key equivalent and see what happens when you test the interface. It ignores all but the first one. Robert La Ferla Lotus Development Corporation Advanced Technology Group / NeXT Improv
kane@gac.edu (Christopher Kane) (06/18/91)
In article <1727@toaster.SFSU.EDU> eps@toaster.SFSU.EDU (Eric P. Scott) writes: > In article <2126@camex.COM> geoff@circus.camex.com (Geoffrey Knauth) writes: > >Has anyone noticed that both of these pick sequences are command-G? > > Utilities -> User Commands -> Grep Source > > Services -> Librarian -> Target > >Are there other examples of re-use of key equivalents? > > Sure. How about Command-g for Find Next and Grab. As long as > both operations aren't contextually meaningful at the same > time, it's not a problem. (I'll probably eat those words later.) > > -=EPS=- Grep Source and Target have the same command-key equiv. because the generic commanddict file that gets put in each users directory in 2.0 names 'G' as the key equivalent. .commanddict should be edited to remove or change this to something else. In general, it is NOT alright to have two menu items with the same key equiv. It can be confusing to the user (which is why NeXT makes a big deal about user interface guidelines), and can lead to unexpected results. A programmer shouldn't depend on some order in which the menu items in a program are searched for one that can respond to the key. The way this is done internally in 2.0 may change in 3.0, and so no particular order should be assumed, and thus a programmer can't count on one or another menu option being selected (and future versions of the Appkit may choose to select none if there are conflicts). The importance of some interface standards can be illustrated easily by looking at the uses to which command-P is put. In Librarian, it's Preferences..., in Edit, it's Page Layout... (IMHO, what it should be), in NewsGrazer, it's New Post..., and there are probably more examples. Just think what a mess things would be if everyone choosed there own key equiv. for Save. The only time in which it would be ok if both operations aren't contextually meaningful at the same time is if the menu option for them are disabled when not meaningful. This puts an additional burden on the programmer, can still result in user confusion, and is better avoided altogether. > In article <ROBERTL.91Jun16015807@bucsf.bu.edu> > robertl@bucsf.bu.edu (Robert La Ferla) writes: > >Shouldn't Interface Builder check to see if you re-use a hot key and warn > >you? I think so. > > Interface Builder doesn't have the context to do this. The > Services menu is bound at run time, and NXCommandKeys defaults > can remap everything anyway. > -=EPS=- Well, Erick's right about this. And when a program provides "user editable" menus like Edit does, it becomes the program's/programmer's responsibility to check to make sure the user hasn't assigned something like command-s or command-c to one of the items. Christopher Kane kane@gac.edu NeXT Campus Consultant Gustavus Adolphus College St. Peter, Minnesota Disclaimer: My mention of NewsGrazer in conjuction with menu command-key equivalents should NOT (NOT, NOT, NOT!) be construed as advice to use said program as an example of how command-key equivalents should be done. Just the opposite, in fact....
glenn@heaven.woodside.ca.us (Glenn Reid) (06/18/91)
Christopher Kane writes > The importance of interface standards can be illustrated easily by looking > at the uses to which command-P is put. In Librarian, it's Preferences..., in > Edit, it's Page Layout... (IMHO, what it should be), in NewsGrazer, it's New > Post..., and there are probably more examples. Just think what a mess things > would be if everyone choosed there own key equiv. for Save. I agree with all of this whole-heartedly. As a developer, I have to say that it's difficult to keep track of all the menu equivalents and to keep yourself from assigning the same letter to two or more menu items. Interface Builder could certainly help with this, although the run-time binding problem is acknowledged. The user interface guidelines tread a fine line between over-prescribing (reserving so many key equivalents that there are none left over for your own unique features) and under-prescribing, which leads to some doubling up and unfortunate collisions. I think they've done a pretty good job of treading that line. They are very tough about the important ones (printing, saving, copy, cut, paste, bold, italic, new, open, revert, and so on), while providing good guidelines for the others. The problem comes with multiple applications from multiple vendors, each of which is doing the "most intuitive" thing for their product. The only real solution, I believe, is to have excellent support for the user to edit these for his or her own applications and system, as well as providing good support tools for developers to come as close as possible to doing the right thing. The current support for editing key equivalents in Preferences is not adequate, and expecting people to run "segedit" is not acceptable, either. To get a start on helping us developers do the right thing, maybe we could collectively build a list of known key-equivalents in various apps that already exist, as a reference point for implementing similar features and also as a tool for finding interface problems in existing products. Here are the current "non-standard" ones for TouchType, as a starting point (ideally these should be sorted by key equivalent, too, but I'm too lazy): Info/Preferences k File/Save As Illustrator... I (capital eye) Edit/Fix Selection G Edit/Redraw Screen D Edit/Select Line H Edit/Select All a Edit/Deselect All A Format/Align/Left L Format/Align/Center C Format/Align/Right R Format/Align/Justify J Format/Align/At Baseline _ (underscore) Format/Align/At X-height T Format/Word Space/Tighten { Format/Word Space/Loosen } Format/Word Space/Default | (vertical bar) Format/Leading/Set To... l (el) Format/Leading/Increase . (period) Format/Leading/Decrease , (comma) Format/Leading/Default / (slash) Format/Rotate/To... r Format/Rotate/Default ! (shift-1) Format/Rotate/15 Clockwise # (shift-2) Format/Rotate/15 CounterClockse @ (shift-3) Format/Rotate/1 Clockwise % (shift-4) Format/Rotate/1 CounterClockwse $ (shift-5) Format/Page Layout P Font/Size... F Font/Visual Selection V Kerning/Touch Kern K Kerning/Tighten [ Kerning/Loosen ] Kerning/Revert \ Kerning/Pair Data/Remember... ; (semicolon) Tools/Colors e Tools/Arrow 1 Tools/Text 2 Tools/Show Tool Panel 5 Tools/Show Active Fonts 6 Tools/Show Kern Panel 7 Tools/Show Ruler Guides g Windows/Zoom In > Windows/Zoom Out < Windows/Reset Window 0 (zero) Windows/Zoom True WYSIWYG W As you can see, being a keyboard sort of guy, I love command-key equivalents, but there just aren't enough reasonable possibilities for all of them. Also, I don't know if this affects this "study", but TouchType supports the following Emacs-style editing commands: Forward one character control-f Backward one character control-b Next line control-n Previous line control-p Kill to end of line control-k Move to beginning of line control-a Move to end of line control-e Delete next character control-d I hope this turns out to be useful, 'cause it was a pain to type it all in :-) -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us NeXT/PostScript developers ..{adobe,next}!heaven!glenn 415-326-2974 (NeXTfax 326-2977)