Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site decwrl.UUCP
Path: utzoo!linus!decvax!decwrl!daemon
From: daemon@decwrl.UUCP
Newsgroups: net.cog-eng
Subject: Menu Driven Systems
Message-ID: <4738@decwrl.UUCP>
Date: Fri, 6-Jan-84 02:32:39 EST
Article-I.D.: decwrl.4738
Posted: Fri Jan  6 02:32:39 1984
Date-Received: Sun, 1-Jan-84 02:03:57 EST
Sender: daemon@decwrl.UUCP
Organization: DEC Western Research Lab, Los Altos, CA
Lines: 109

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