cak@Purdue@sri-unix (08/10/82)
From: Chris Kent <cak at Purdue> I figure I might as well throw in my two cents worth. About 5 years ago, I worked on a menu-based system for engineering support. That is, we had these HP3000s that were purchased to help design engineers do their jobs better. We built a push-down automaton that managed transitions moving around a tree-structured set of menus and applications, the interface to the terminal, database, etc., to isolate the applications from changes in the vendors software; but that isn't so much relevant to this discussion -- what matters is that it was menu based. So were all the applications. That is, they were typically data-entry and retrieval systems, where you filled in some of the blanks, hit enter, and the system filled in the rest. Example -- we automated assignment and retrieval of engineering drawing (blueprints to you and me) numbers. Previously, it was manual, different sites had ranges of numbers that they could assign, and retrieval of a drawing (for subsequent modification) was a manual process involving looking at paper records and the reduced originals. We changed all that; if you had a new drawing, you entered all the relevant data, and got a number. If you needed to find an old drawing, you could enter partial data such as the plant, machine, product, or whatever, and the system would come back with a list of matches. But I digress. The interesting thing was that the system started you off at some level in this tree of applications, with a menu. The neat thing about the menus was that you were not limited to choosing one of the items on the menu -- you could do that by typing the number in the blank, or you could type in the name of the application you wanted and go there directly. This was the key to satisfying our more experienced users. They didn't have to go down the tree one level at a time, if they didn't want to. Of course, these types of applications are different from typical programming tasks. I'm not convinced that an analogous system can be developed. Filling in the blanks for simple commands like "delete this file" is a pain, once you know how to do it. National Semiconductor builds a microprocessor development workstation called the Starplex; it provides menu front ends for all the system commands, but has a command line processor as well. If you type the command with no arguments, you get the menu. That's pretty nice; we were able to sit down and use it right away, without the manuals. Unfortunately, the command line syntax is so cryptic that you end up using the menus all the time -- which is unfortunate. (Actually, the only thing really nice about the Starplex is the menu system; the rest is pretty painful. Microprocessor companies are very much behind the current state of the software and workstation art.) Cheers, chris
jmr1 (08/11/82)
The system that you described regarding a menu driven system that
allowed the experienced user capability to by-pass the tedious stepping
through the menus sounds pretty nice....except...I wonder is it realy
worth all the overhead it would cost to make it as flexible as you say.
I'm one that belives in menus (what I like to refer to as intelegent
menus) to interface to users who should not be expected to understand
or learn commands and all thier options (menus are ideal for use in
aplication systems), but......they do take-up alot of overhead...
My feeling is that if it can be avoided menus should only be used
as interfaces to certain complex programs or tasks that require a lot
of options.
John Reese
ATT Long Lines
Chicago
Special Note:
It is a common fact that most programmers are notorious for
thier spelling (lack of spelling!)...I am a prime example of this
fact....I appologize for my spelling errors, sorry. To those that
will (and have already) say that I can use the spell program...
I used to use the spell program but I could never find the word
in the dictionary once spell told me it was wrong....maybe spell
should suggest some allternatives to a miss-spelled word once you
have made 15 attempts through spell.