Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!dartvax!lorien From: lorien@dartvax.UUCP Newsgroups: net.cog-eng Subject: Re: D. A. Norman on Commands vs Menus Message-ID: <315@dartvax.UUCP> Date: Thu, 27-Oct-83 16:45:53 EDT Article-I.D.: dartvax.315 Posted: Thu Oct 27 16:45:53 1983 Date-Received: Fri, 28-Oct-83 08:35:14 EDT References: utcsrgv.2502 Lines: 69 I read D. A. Norman's "Design Principles for Human-Computer Interfaces" and the net.cog-eng article in which it was summarized with interest. In the paper, Norman presents a method for analyzing the tradeoffs between aspects of user interface design. An example he presents is the tradeoff between menu-oriented (easy for the novice, verbose for the expert) and command-oriented (quick for the expert, opaque to the novice) systems. In his conclusion, Norman points out that it's important to analyze separately these different design considerations that affect user satisfaction. In this particular example of a tradeoff (and perhaps you can suggest other examples), however, I find a blind spot. Have we so soon given up on creating a system that is *both* command- and menu-oriented? I am thinking in particular of a design suggested to me by my colleague, R. C. Call, in which a command, with arguments, can equally well be seen in the traditional sense as in a climb down a menu tree with typeahead. For example, in a tree that looks like: -----Main Menu---- SEARCH LIST / --Search Menu-- AUTHOR TITLE SUBJECT | , the command SEARCH AUTHOR JONES, J. can be seen by people who are used to operating systems as the SEARCH command with arguments AUTHOR and JONES. A novice user, however, might begin by typing only SEARCH. The system is so designed that if a particular command sequence doesn't land one on a terminal node, a menu full of choices is presented the the level at which they've landed. So our novice would see the "Search Menu". The (yes) tradeoff to this approach is that after executing a terminal node, you're always returned to the Main Menu, so you can't sit around in 'Search' trying out 'AUTHOR', 'TITLE', etc. searches, but must type SEARCH every iteration. Perhaps this feature could be a toggle? This is only a first shot at such a system, meant to stimulate discussion not necessarily of this particular design but of other possible schemes in which the interface is intelligent enough to recognize the user's level of ability. We shouldn't ignore the Future, either, as a resident Expert system in such an interface might be just the thing to tailor output based on a constructed cognitive model of the user. Right now I have written a standard climb-through-the-branches menu interface (with a few places where we were forced to compromise and allow some "Tarzan" swinging between branches without returning to the root), where you stick at whatever node you're at and have to explicitly type 'R' (for 'Return') to climb towards the root. In a few weeks, I'm considering implementing something of the above design and I'd appreciate any comments, critical included. Also if any of you folks are writing interfaces for bibliographic databases (especially online card catalogs like mine) I'd like to hear from you. thanks in advance, Lorien Y. Pratt Dartmouth College Library Hanover, NH 03755 decvax!dartvax!dartlib!lorien