Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site topaz.ARPA
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!topaz!gaynor
From: gaynor@topaz.ARPA (Gaynor)
Newsgroups: net.cog-eng
Subject: Re: menu system design pointers?
Message-ID: <3019@topaz.ARPA>
Date: Thu, 1-Aug-85 06:56:48 EDT
Article-I.D.: topaz.3019
Posted: Thu Aug  1 06:56:48 1985
Date-Received: Fri, 2-Aug-85 05:57:46 EDT
References: <42700001@hpcnof.UUCP>
Organization: The NJ Home for Perverted Hackers
Lines: 122

****care package for line-eating bugs: &&&&(rogue food) %%%%(hack food)****

In article <42700001@hpcnof.UUCP>, dat@hpcnoa.UUCP (dat) writes:
> 
> 	Consider the following mini-menus;
> 
> 	1=selection one
> 	2=selection two
> 	3=selection three
> 
> 	selection:
> 
> 
> 	S)election one
> 	C)hoice two
> 	P)ossibility three
> 
> 	selection:
> 
> and so on...
> 
> 	Which is better?  More specifically, can anyone give me pointers
> to articles/books on how to design menu systems?

     The prime consideration in the design of a menu is, obviously, its
ease of use.  One should be able to execute commands quickly and easily.
This is what would prompt me to use a set of mnemonic characters each
corresponding to a command over numbering them.
     Problems arise when a single letter is THE logical choice for several
commands in the same menu.  Alternative command names themselves can help
(eg use K(ill for D(elete if D(equeue present), perhaps inspiring you to
blow the dust off your thesaurus, or maybe use a bit of literary ingenuity
(X(ap for D(elete, C(ue for Q(ueue).  With a little imagination, you might
also have a bit of fun (at the lusers expense, maybe >:-)), including more
radical command names.  Also, remember that the letter need not be the
first in the command name, like Heap)S(ortData.
     Careful nesting of menus will avoid much of the problem of 'command
collisions'.  A good top-down design is hard to beat.
     If you still being thrashed by a logically grouped set of commands like
Dequeue, Delete, Debug, DeltaThis, DeltaThat, DropPants, DrDolittle, ...,
try the ol' expanding opcode trick.  D)e(Q)ueue, D)e(L)ete, D)e(B)ug, ...
     I particularly liked the UCSD-Pascal set-up, maybe you might want to
take a look at it.  I'm mostly only familiar with this topic thru personal
experience, so I really am short on references.

     Here's a menu layout that I particularly liked, for a graph manipulating
program...


  conventions:

      the path of commands that it took to get to the
      current menu is always displayed in the upper
      left-hand corner when accepting new commands

      when accepting commands, they are displayed at
      the top of the screen, seperated by a reasonable
      amount of white-space

  notes:

      I left out any explanation or help facility as I
      was the only one that ever used this program.  It
      did not slip my young, agile mind, though :-).  A
      '?', 'h', or 'H' should generate a list of additional
      topics for which help is available, as well as all
      the commands (ie a '?' to the first menu below would
      not only allow explanations of the various commands,
      but would also display things like I(nternalRepresentations,
      V(ersion, SolutionTo)P(arkingProblemsInNYC, ...).
      The next char typed would do up help for that char.

      Also, there's a choice to be made about whether commands
      should come straight from the keypad as soon as typed,
      or displayed until end-of-input produced (<cr><lf> usually).
      Perhaps the option could be supplied, toggling between
      the two modes.  I personally prefer the former, for speed,
      as one certainly will become used to an oftenly used piece
      of software.


------------------------------------------------------------------->
|
|  Q(uit  E(dit  P(rint  S(hortestPaths  M(inimalSpanningTree
|
|  T(opoligicalSort  D(epthFirstTraversal  B(readthFirstTraversal
|
|  2(ConnectedComponents  ...
|
V

------------------------------------------------------------------->
|
|  {E(dit}
|
|  Q(uit  P(rint  S(ave  K(ill  R(ead  A(dd  D(elete  T(oggleDirected
|
V

------------------------------------------------------------------->
|
|  {E(dit -> A(dd}
|
|  E(dge  V(ertex
|
V

...and so on...  This isn't exactly how it was set up, but close.

     Any other suggestions, innovations, flames, references?  Post
'em up!

p.s.  I dislike mice for several reasons.  You have to be CAREFUL
where you put that cursor!  It's not that easy to control yet.  Also,
having touch-typed for quite a while, in the time it takes to position
the four-legged bastard, I could have knocked off up to 10 (or more, I
haven't timed) keystrokes.  They have their uses, but...

_______________________________________
|Any and all opinions expressed herein|  'Silver', gaynor@topaz
|are to now be construed as Law.      |                  @ru-green
---------------------------------------