mo@LBL-UNIX@sri-unix (08/02/82)
From: mo at LBL-UNIX (Mike O'Dell [system]) In reply to Sam Hsu's question about menus.... We have used a version of "Menunix" for training a couple of new secretaries and have had interesting experiences. (FYI, Menunix is a menu-based shell done by Gary Perlman, et al, at ucsd.) For the first day or two, the people liked the menus very much. However, one of them actually wandered in and asked "Isn't there some way I can just type the command I want to do instead of having to do the menus?" We think this means the menu interface is nice for rank beginners, but as soon as they learn what the most frequently-used menus have to say, they just want to type the command and not be prompted and prodded by the machine. On occassion, the people go back to the menu interface when they want to learn something new, but really seem to be using it as a help system with the ability to support examples and experimentation. They are generally back in their normal shell within a few minutes. My personal biases are similar (and may be coloring the interpretations!). The menus are nice when you are trying to get a feel for something very alien, but as soon as you have a "working set" in your head, you just want to type the commands. I don't care how fast you can repaint the menus, and that I can read very quickly; I simply want to type the commands. -Mike
GEOFF@SRI-CSL@sri-unix (08/02/82)
From: the tty of Geoffrey S. Goodfellow Please have my WORKS address changed from GEOFF@MIT-AI to GEOFF@SRI-CSL.
smb (08/02/82)
The specific failing of menu-based systems is that they force multiple "mental actions" by the user. That is, even if the system responds instantly to present a new menu, I then have to take another step -- which implies thinking about it, and probably a cursor movement (by whatever technology you want). A simple typed command, on the other hand, may be more work, physical and mental -- but it's one thought sequence, and one action sequence. --Steve Bellovin duke!unc!smb smb.unc@udel-relay
grunwald (08/03/82)
#R:unc:-378100:uiucdcs:13900002:000:1854 uiucdcs!grunwald Aug 3 13:05:00 1982 My biggest gripe with typing something in is that when one makes a mistake, it is very difficult to re-enter the line and fix the mistake. The Berkley C shell has some nice features, but they are not as good as some other systems I have used. One of my favorite systems for this was PLATO. They had a nice general mechanism worked out which allowed you to "edit" an input string any place in the system. The way it worked was as follows: the PLATO keyset is custom made, and they have a key labeled EDIT. Let's assume you enter some string and need to change it. The first time you press EDIT, the entire string is erased. Then, everytime you press EDIT, another "word" comes back, where a word is defined by their parsing rules (a little bit better than cntrl-w on unix). Additionally, there was another key you could press to return your "edit- buffer" one letter at a time. This could be mixed with the EDIT key to allow you to go to a word and then insert/delete characters within it. Additionally, pressing EDIT when holding the shift key returns the rest of the text stored in the "edit buffer". This was very useful, mainly due to the fact that it is available everywhere in the system. Using this feature allows one to almost do away with the "o" directive of XED. There was also another special purpose key called "COPY" which allowed you to copy text out of a "copy buffer", which was set up by the program. Using these features in the shell would most likely work like this: You could enter a command, using the EDIT keys to fix and changes. Then, if you wanted to run the same command with slightly different tags, the shell could move the old command into you "copy buffer". Then, on the next line, you would use the COPY key to get back the words one at a time (or all at once by shift-COPY) changing the parts you want as you go along.
wagner (08/08/82)
I think the biggest problem with menu systems is display bandwidth related. The first good menu system I used was SPF on channel attached 3270s. The menus never got in the way - the datarate of such a device is roughly half a megabyte per second. Try using the same system at 4800 baud (i.e. about 500 chars/second - 3 orders of magnitude slower) - suddenly I understood why the half of the computer centre located remotely couldnt stand SPF. One of the features that ameliourates the problem a bit is a way of stepping through common menu sequences without display of intermediate menus. In SPF, if you remember where you want to go, you can concatenate menu replies (sort of like UUCP routings - utzoo!decvax means send to utzoo, having stripped off utzoo so the next guy will re-read and send to decvax). IMS is a menu based database system. One of the things you can do to speed up menu response is run your remote terminal on a micro called a system/3 (which supports 8 or so terminals and a line back to the mainframe). In the morning, when IMS wakes up, it sends prototype menus down the phone lines to all its system/3 sites, who store it locally on disk or in memory (i dont remember which). Then, when IMS feels the need to show the user menu X with fillins, menu X is condensed to 3 characters from the more normal 100 or so, and flash! up it goes. The fillins, of course, still go up slower. Too bad it cant huffman encode them. Enough. Michael Wagner, UTCS