lorien@dartvax.UUCP (Lorien Y. Pratt) (12/30/83)
I've just written a proposal for a menu-driven system in which the
menus are available only for show, to help novices explore the command
structure of the system. There is logically only one input point, however
if the user types, say, 'Search', s/he will be shown a Search Menu with
options listed that might help with searching. From this displayed menu,
any command can be typed, however, not just Search commands.
Does anyone have any familiarity with this kind of system? The only
disadvantage that I can see to it is that one must keep all commands
unique (and unambiguous within as few letters as possible, for my
command parser to work nicely). It seems to get around all sorts of
difficulties that experts have with menu-driven systems, especially when
a BRIEF mode option is introduced. With typeahead available, the
system that I've proposed looks completely command driven in BRIEF mode.
I'd appreciate any working papers you folks might have or descriptions
of such systems that you've seen. Criticisms are also appreciated, but
think them out well, please. I'd be happy to share my notes with anyone
interested.
--Lorien Y. Pratt
Dartmouth College Library
Hanover, NH 03755
decvax!dartvax!loriendaemon@decwrl.UUCP (01/06/84)
From: atfab::wyman
In re: Menu Driven Systems
Lorien,
DEC's ALL-IN-1 Office Menu product works much the
way you seem to be proposing...
Although ALL-IN-1's menu's LOOK heirarchical, the menus
are really a pretty flat structure. Heirarchy can, however, be
introduced.
ALL-IN-1 menus are forms driven by DEC's FMS (Forms
Management System) product. Each menu/form has a name (in V1.x
that's up to 6 characters). ALL-IN-1 Forms come in a variety of
flavors:
1) Menu Forms - For picking options
2) Entry Forms - For entering/viewing data in sequential or
indexed files (sort of like PFS...)
3) Arg Forms - Used to collect "arguments" for
functions (like the name of a printer)
4) Help Forms - For Help
5) Seach Forms - For selecting records from data files
or looking up keywords in documents.
6) others, not so interesting...
The name of any form can be used while on any menu
to cause that form to be run. Thus, I can be at the MAIN menu and
wish to get to the MYDATA Entry form... I simply type "MYDATA"
and I'll be running in data entry mode with the appropriate files
open and active.
In addition to being able to get to things by specifying
the form name, all menus can contain options. These options can
either be calls to other forms or they can result in the
execution of one of the many ALL-IN-1 facilities. Each menu has a
data region associated with it (called "named data") which stores
the options available from that menu. However, the user also has
available, at any menu, all the commands available on the "MAIN"
menu -- unless his current menu redefines the command. Thus, even
though "WP" (Enter word processing) may not be visible on my
current menu, because it is a MAIN menu option, it will work from
my current menu.
It is also possible to specify things using a "fast
path"... This is useful when one doesn't know the name of a form
but does remember a path to it. What you do is type in the
commands in sequence that would get you there and any menu forms
between your current position and the end position are not
displayed. "Fast Path" can also be used to sequence events. For
example. If I see a mail message that I want to read, then print,
and then delete, I can type "r p d". The system will then show me
the message and when I'm done will ask me where I want it
printed. Once I've answered the question and the print begins, it
will delete the message. Of course, the "r", "p", and "d"
commands probably don't refer to mail messages unless I'm on the
mail menu... If I'm not on that menu, I simple preface the
command string with the name of the mail menu (ie: "em r p d")
and all will be done properly even though I might have been on
the WP menu which thinks "r", "p", and "d" should refer to the
current document, not the current message. (NOTE: to get back to
WP once finished with the message I would type "em r p d wp".
This all looks obscure if you've never done it... The user's seem
to like it alot.
This sort of command structure worked out real well when
we approached the problem of "Hardcopy" interface. We weren't
trying to build a system for the folks who usually run on
hardcopy terminals, rather we wanted something for the poor folk
who get stuck on the road with a hardcopy terminal and want to
talk to the system. In Hardcopy mode, all the menus are
essentially turned off but the command processing still works.
Field input is a bit different... Instead of having a form
displayed, the user is prompted by field name for the data
required. If ever confused or lost, there is a key sequence that
can be used to get a hardcopy representation of what the
menu/form would have looked like had the user been running on a
video terminal.
We've tried to work with systems that let you input
commands such as "Search" etc without carrying what menu you are
on but have found that in the abscence of any context, the system
either becomes more obscure, or less functional. For example, it
is necessary to know what you want to search and what you are
searching for... The parameters of a search are different
depending on context. "Create" is a good example: If you want to
"CREATE FOO", well, what kind of a thing is Foo? Is it a message,
document, or calendar? We could go for "CREATE/DOCUMENT FOO" but
that is not received well by the users. The option we've taken is
to have the user establish context by establishing a local menu,
then "overlaying" the definition of "CREATE", "PRINT" etc to
operate on the type of object appropriate in the context. Since
people don't seem to move between contexts rapidly (ie: they
settle in one context or another for fairly long periods of time)
This has turned out to be easier then forcing a statement of
object type with each command given.
This has been abit long winded, but I hope it gives you
some ideas.
bob wyman
DEC BOSA/ALL-IN-1
(DEC-Enet) ATFAB::WYMAN
(UUCP) {decvax,ucbvax,allegra}!decwrl!rhea!atfab!wyman
(ARPA) decwrl!rhea!atfab!wyman@Berkeley
decwrl!rhea!atfab!wyman@SU-Shasta