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!lorien
daemon@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