Xref: utzoo comp.windows.misc:880 comp.sys.next:1087 comp.sys.mac:24538 comp.cog-eng:778
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!uwvax!astroatc!nicmad!madnix!zaphod
From: zaphod@madnix.UUCP (Ron Bean)
Newsgroups: comp.windows.misc,comp.sys.next,comp.sys.mac,comp.cog-eng
Subject: Re: replacing the desktop metaphor (Why any metaphor?)
Summary: command line *AND* menus
Message-ID: <329@madnix.UUCP>
Date: 30 Dec 88 01:35:25 GMT
References: <850@mtfmi.att.com> <673@cogsci.ucsd.EDU> <1489@umbc3.UMD.EDU> <4455@Portia.Stanford.EDU>
Organization: MADNIX, operated by: ARP Software  Madison WI
Lines: 25


   I'd like to point out that some programs integrate command-
and menu-type interfaces in such a way that they reinforce each
other. Usually this means the menu tells you what the command
would be, and you can either click on the menu or type the
command. This makes the first use painless, yet you quickly learn
the commands you use most often. It reinforces the learning curve
rather than bypassing it. As your needs change, you can learn new
commands without digging out the manual, yet you're not stuck
behind the menus for common functions.
 
   It's not enough to allow both commands and menus without
relating them-- that just gives you the worst of both worlds. I
also don't think context-sensitive "help screens" are quite
enough-- if you only need a command occasionally you really want
to "point and shoot".
 
   Some command-driven programs (notably EMACS) allow you to
remap the commands to different keys. It would be neat if you
could remap the menus at the same time. This would not have to
change the order of nested menus, but they'd have to display and
respond to the new command key. Otherwise you find that the
author has hidden your favorite command behind some
ALT-CTRL-SHIFT sequence.