Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!src.honeywell.com!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!news From: kane@gac.edu (Christopher Kane) Newsgroups: comp.sys.next Subject: Re: Edit App (command-G), user interface consistency Message-ID: <1991Jun17.135120.242@gacvx2.gac.edu> Date: 17 Jun 91 19:51:16 GMT References: <1727@toaster.SFSU.EDU> Lines: 64 Nntp-Posting-Host: erick.gac.edu 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@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....