dat@hpcnoa.UUCP (dat) (07/22/85)
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? (It certainly can't be as easy as it seems...especially based on the haphazard menus I've seen on some systems!) Thanks a lot! -- Dave Taylor HP Colorado Networks Fort Collins, Colorado ..ihnp4 \ ..decvax!hplabs \ !hpfcla!d_taylor ..ucbvax!hplabs / ..hpbbn /
gaynor@topaz.ARPA (Gaynor) (08/01/85)
****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 ---------------------------------------
jqj@cornell.UUCP (J Q Johnson) (08/02/85)
re: menus selected by number versus menus selected by mnemonic letter You have to consider the context of the menu usage before deciding on a best strategy. Consider, for example, a large menu of 9 items. A natural way to display it might be in a 3x3 grid, in which case a natural way to select would be to use the numeric keypad. Using the numeric keypad is particularly attractive if you have a long sequence of menu selections. It is less attractive if menu selections are interspersed with text input, since the keypad use implies loss of homerow registration. Personally, though, I don't like menu systems unless I have a pointing device such as a mouse, light pen, or touch screen.
henry@utzoo.UUCP (Henry Spencer) (08/02/85)
> Consider the following mini-menus; > > [ menu with numbered selections ] > [ menu with first letter of command as selector] > > Which is better? ... It depends. [Sigh, what a startling answer...] If the customers are working *entirely* with menus and are seldom if ever typing text, note that a numbered menu can be used entirely from a numeric pad. This will be especially significant for non-touch-typists who haven't got the QWERTY keyboard burned into the synapses in their fingers. On the other hand, if people are using the QWERTY keyboard for text entry as part of the system anyway, that changes things. Have you considered displaying both and accepting either? -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
hestenes@sdcsla.UUCP (Eric Hestenes) (08/05/85)
> > 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 > !hpfcla!d_taylor The latter is better ( for most purposes ). I think the reason was due to the enhanced predictability of the letter - choice item pair over the number - choice item pair. However, the number is itself better for some situations, for instance, when you have two menu choices that start with the same letter. Gary Perlman studied this question experimentally; I'll look up the paper and post a summary ( unless gary chooses to do so first ). eric -------- Eric Hestenes Institute for Cognitive Science, C-015 UC San Diego, La Jolla, CA 92093 arpanet: hestenes@nprdc.ARPA other: { ucbvax } ..sdcsvax!sdcsla!hestenes
perlman@wanginst.UUCP (Gary Perlman) (08/06/85)
In article <42700001@hpcnof.UUCP> dat@hpcnoa.UUCP (dat) writes: >can anyone give me pointers >to articles/books on how to design menu systems? About the specific question you asked, see: Perlman, G. (1984) Natural artificial languages: Low level processes. Int'l Jl of Man-machine Studies, V.20, pp 373-419. The result is found in Experiment 2, starting on page 393. I have an obscure paper more specifically on menus: Perlman, G. (1984) Making the Right Choices with Menus Presented at the IFIP INTERACT '84 conference on human-computer interaction, London, England Ben Shneiderman has an evolving tech report on research on menu design. Finally, the guidelines of user interface design by Sidney Smith (at MITRE) and Jane Mosier, is the most extensive source of information on user interface design research (hundreds of pages). You can get my papers from me, through US mail. Shneiderman is at the University of Maryland computer science department in College Park, MD. Smith is at MITRE in Bedford, MA. -- Gary Perlman Wang Institute Tyngsboro, MA 01879 (617) 649-9731 UUCP: decvax!wanginst!perlman CSNET: perlman@wanginst
peter@graffiti.UUCP (Peter da Silva) (08/31/85)
> 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... If the mouse is an alternative to keys, instead of a replacement, it's great. Sometimes you have to move your cursor to somewhere illogical...