maker@dartvax.UUCP (09/25/83)
Another newcomer to the newsgroup, interested in interfaces. My
vote on the command/menu survey (I only saw the results), is: a
combination is best. Let the novice use menus whose selections are
made by specifying the command name, thus teaching himself the
commands. Supplying a command before requested inhibits the menu.
When he chooses, he dispenses with menus altogether (except on request)
and is using a command-driven mode. Now he can be blazing fast:
experts abbreviate, type ahead, don't see menus.
I also have written an interface tool: the Command Line Interpreter
(must be popular buzz-words). The design goal for the CLI was a
subroutine package (simple for unsophisticated programmers to
understand) that would handle most user interaction for the program,
with minimal programming. It has been used from PL/I for three years
now; I plan to make it run in our local "common-runtime" environment
(PL/I, Basic7, Pascal and Fortran 77).
Considered as a layer between the program and the user, the CLI
presents to the program a "perfect user": one who supplies what is
requested flawlessly, who never needs help, etc. All command parsing,
argument verification, script handling, type-ahead, menus etc are
handled by the CLI. The program makes a request for, say, one of a set
of legal strings via the call:
<string> = $string(prompt, legal_string_list); where the legal list
is in a free format, like "bluff raise call fold", or for an integer
in a specified range via
<fixed> = $fixed(prompt, lo, hi); or for other data types,
essentially just specifying what it needs to get, rather than how
interaction is to be done. The programmer using the CLI may easily
extend it to handle new data-types (like times, dates, angles, etc).
Input is returned in the form most usable to the program (already
converted integers, for example).
The user sees an interface which is safe, informative, terse or
verbose as desired, and flexible. It supports abbreviation, command
scripts, HELP, both menu and command modes (where using the menus
teaches one the commands; after a short time, you may forego menus for
speed), multiple commands/arguments per line, and an ABORT command that
always aborts the current action. Unsupplied input is queried for
(possibly with a menu). The programmer need not concern himself with
any of this. He may choose a pure menu-driven mode, pure menu-driven,
the natural combination mode which I favor, or even program-driven
mode, where the user only responds. Any mixture of modes may be used
in a program.
The CLI was built to be relatively small and simple to use, for both
throw-away interactive programs and long-lived large ones (one of
10,000 PL/I code lines has run for several years now, yet dozens of
one-page programs have been written with it).
I look forward to discussion.
- steve maker
decvax!dartvax!maker