msellers@mntgfx.mentor.com (Mike Sellers) (01/06/89)
In article <8092@aw.sei.cmu.edu>, weh@sei.cmu.edu (Bill Hefley) writes: > In article <4455@Portia.Stanford.EDU> rdsesq@Jessica.stanford.edu > (Rob Snevely) writes: > >The issue is not ease of use, the issue is how effectively a person can > >use a program as a tool to make his/her life or job better or easier. > > Agreed! Yes. It is often not easy to make a user interface that allows for users that may be completely expert, completely novice, or some of both depending on the task that also does not get in their way or increase their "cognitive load" (which I define as the extra attention spent on thinking about using a tool instead of just using it). Couple this with users who may be anywhere from novice to expert in their native task domain but who may also have a very different level of computer usage expertise, and you can get into some very tricky situations. (On top of all this, of course, is the fact that the company I work for is selling their products for money, so we can't just say "oooops! well they sure didn't like that one -- let's try again next year." :-) Sometimes I sure wish we could, but then I guess that's what grad school is for...) >> So I propose both, >> why cant we have a word processor that has two interfaces. A "user-friendly" >> pull down menu -- dialog based interface for new users. and a command >> oriented interface for advanced users. This would allow those users who >> want or need a command oriented interface access to it while allowing >> new or intermediate users to have the point and click. Also since the >> menu interface would be around all the time, it would help to eliminate >> the problems of going from on to the other cause they are interchangable. > > A couple of years ago, I led a team of folks developing a window-based user > interface (roughly 1000 x 800 pixel resolution, on a 16" high by 10" wide > monochrome display) for a process control application. We found that a > hierarchical menu structure, closely coupled with a command line interface, > was very straight-forward for our target user population to deal with -- > both novice and more experienced operators. To reinforce the coupling of > the dual modes (as well as an training aid), the command line displayed the > equivalent of each menu selection. We incorporated a fixed-function key > that allowed backtracking. The single shortfall (in our minds) was that we > had to add an extra acknowledge action at the end of every command to ensure > that the operator was ready to execute (and did not want to backtrack). > By the way, other software packages with similar capability that I've seen > also have had to do this (see the Search dialog in Pro-Cite's bibliography > package for the Mac, as an example.) > > For a picture of our interface, see Marken's paper (pp. 1026-1030) in the > Proceedings of the 1988 Human Factors Society Annual Meeting. The two > windows are refered to as "Menu Viewport" and "Directive" in his Figure 1. > > ____ ______ _____ _____===== Bill Hefley We have implemented (and have been selling since early '88) a product that uses these ideas and many others. What I find remarkable is that these ideas seem to be somewhat (r)evolutionary, both to other engineers and to our customers (and by the looks of these messages, somewhat to others as well). If there are other good real-world examples of things that have been implemented and are being used, I'd sure like to hear about them (nothing confidential, of course). In my case, briefly, Mentor Graphics Package Station (a 3D Wireframe Editor and Thermal Analysis Tool, etc. -- runs on Apollo workstations) has a user interface where commands may be entered by using a hierarchical menu system, by typing in keyword phrases, by typing in 4-letter acronyms, by using function keys, or by using a tablet menu. These seem to cover all the bases real well (without assuming continuous speech processing), and seem to work well for users at every different level. The "arguments" to any given command are brought up on a "prompt bar" that uses both text and graphic prompts to get the information needed. The user can tab back and forth across these fields as they choose until they are all filled in (some have defaults, and others are dialog box-like things); a carriage-return is used to signal that the user is ready to have the command executed. Also significant is that you can bring up any command while filling out the prompts for any other command -- so the output from one can be the input to another. Commands can be stacked real deep (up to 8 or 10 I think); you have to try this to really understand how much easier it makes execution of complex tasks, since you don't lose the data for one command when executing another. On-line help is available in several different forms; one way is to get help on a specific command, and you can use any of the above methods to choose the command to get help on. The menus are arranged across the top of the screen, and have no more than 9 entries per menu (most have far fewer). Almost all are no more than 2 levels deep, and none are more than four levels deep. The keyword phrases are nearly the full names of the command (usually multiple words), and the acronyms follow a completely consistent set of rules for their generation (I don't happen to like the rule set much myself, but our customers seem to like it a lot -- I think in a case like this almost *any* consistency is better than none!). Users can also rename commands as they choose, and make up their own using our macro language. In my mind one of the few things lacking in this scheme is a set of rules for trying to find a command by what the user has typed in, even if incorrectly. We checked into this (using Soundex or something similar), but it turned out to be pretty much overkill. The reports we get back indicate users of other systems have cut training time (to where they can navigate and use the system with a high degree of confidence) by as much as an order of magnitude over some other systems. Anyway, that's my real-world example. The product was highlighted in several industry magazines last spring; I can provide more info if you're interested. Disclaimer: This information is factual to the best of my knowledge, but is solely my opinion and not that of Mentor Graphics or anyone else. -- Mike Sellers ...!tektronix!sequent!mntgfx!msellers Mentor Graphics Corp. msellers@mntgfx.MENTOR.COM Electronic Packaging and Analysis Division "If we pull this off, we'll eat like kings!"
kmont@hpindda.HP.COM (Kevin Montgomery) (01/10/89)
> The menus are arranged across the top of the screen, and have no more than > 9 entries per menu (most have far fewer). Almost all are no more than 2 > levels deep, and none are more than four levels deep. Gee. max of 7 +- 2. Who would have thought of such a thing? ;-) :-) (seriously though- I think that the STM capacity does play a role in that it is QUITE easier to have a hierarchical menu structure with max selections = 7 +- 2. At each stage one can manipulate (cogitate, remember, whatever) all selections at the current level. I have trouble believing that people were designed to remember long lists, or we wouldn't need to invent techniques to do so (imagery, loci, distinctive metaphor, etc), as some user interface folks seem to think at times). disclaimer: STM is ill-defined, so don't read too much into it. > In my mind one of the few things lacking in this scheme is a set of rules > for trying to find a command by what the user has typed in, even if > incorrectly. We checked into this (using Soundex or something similar), there are algorithms to do this- it's not too hard when you consider that you just have to find the most-alike command to what the user entered. And you have a list of the commands. As I recall, in one of Sahni's intro CS (or algorithm analysis) books he gave an algorithm that would find the best word match (even allowing 'dipley' to match 'display' if no closer matches exist). You're right, though- is a bit of overkill. I know *-I-* wouldn't want everyone's csh running that algorithm every time- I'd advocate looking for exact matches, then testing a flag to see if to do extended searching. If a non-exact match is found, confirmation should be required (a confirmation threshold could be user selectible, so if only one char was wrong, it wouldn't bother confirming all the time). (I was going to implement this in a graphics shell I was working on at UDel, but I ran out of time and they graduated me (rats!) ;-) ) kevin
reggie@pdn.UUCP (George W. Leach) (01/11/89)
In article <3500003@hpindda.HP.COM> kmont@hpindda.HP.COM (Kevin Montgomery) writes: >> In my mind one of the few things lacking in this scheme is a set of rules >> for trying to find a command by what the user has typed in, even if >> incorrectly. We checked into this (using Soundex or something similar), > >there are algorithms to do this- it's not too hard when you consider that >you just have to find the most-alike command to what the user entered. >And you have a list of the commands. As I recall, in one of Sahni's >intro CS (or algorithm analysis) books he gave an algorithm that would >find the best word match (even allowing 'dipley' to match 'display' if >no closer matches exist). You're right, though- is a bit of overkill. 8th Edition UNIX would try to correct eroniously typed path strings. I forget if it would handle commands or not? Confirmation was utilized, if I remember correctly. And it did not appear to cause much noticable delay in responce time. -- George W. Leach Paradyne Corporation ..!uunet!pdn!reggie Mail stop LG-129 Phone: (813) 530-2376 P.O. Box 2826 Largo, FL USA 34649-2826
chuck@melmac.harris-atd.com (Chuck Musciano) (01/17/89)
In article <5317@pdn.UUCP> reggie@pdn.UUCP (George W. Leach) writes: > 8th Edition UNIX would try to correct eroniously typed path strings. >I forget if it would handle commands or not? Confirmation was utilized, if >I remember correctly. And it did not appear to cause much noticable delay >in responce time. Win Strickland, a Georgia Tech grad student, did his master's thesis in the '82-'83 time frame on just such error correction. It would analyze typing errors due to erroneous keystrokes, rather than misspelling. It was called a "backstop", and you would place it as the last element of your path. The Ga Tech Software Tools shell ("swt", for those who might care) would let you put a command as the last element of your path, which made such a backstop possible. I wish my Unix shell would allow such things, I would write my own backstop. Chuck Musciano Advanced Technology Department Harris Corporation (407) 727-6131 ARPA: chuck@trantor.harris-atd.com