🚀 go-pugleaf

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!"