Feinler@SRI-NIC@sri-unix (07/12/82)
I have worked with several different user interfaces over the years and I too prefer the command completion mode used by AUGMENT/NLS and MSG. The single character (or enough characters) recognition I find less winning because one almost always has to type spaces between the characters which means thousands of extra keystrokes over a period of time. In AUGMENT/NLS or MSG one types one or two letters and the commands are completed and displayed, thus if one made a typo it is obvious. I have never found that the command completion slows me down although I have heard that argument from time to time. Also, I feel I must dispell a myth about AUGMENT/NLS because I have heard it so many times and it just isn't true. It is NOT a difficult system to learn. I have trained several people who don't even LIKE machines to do useful work with less than a day's training. It is much easier to teach someone to use than say EMACS, in my opinion. AUGMENT/NLS is a very rich set of tools all under one 'umbrella' and it is true that for someone to learn to do everything that is doable under AUGMENT would take quite some time since it has text editing, programming, text processing, mixed text and graphics capabilities, data base management, etc., etc., etc. A user can do most of what she wants with the system rather nicely, which has nothing to do with the fact that if one wants to program this may take somewhat longer to learn than if one wants to do simple text editing. The point I am making is that when comparing apples with apples (text editing with text editing, for instance) AUGMENT/NLS is quite user friendly, powerful, and easy to learn. Jake Feinler -------
Reynolds@AMES-67@sri-unix (07/22/82)
In Reply To: WorkS Digest, V2, I64 Message from Jake Feinler Yes Indeed, I agree... Although I have never used AUGMENT/NLS, I did borrow the ISIS film from Doug Englebart a few years ago and was impressed with the power of NLS. The film does misslead one though, into assuming that you have to learn to deal with all the complexity of NLS just to get started, when only a subset is needed. We have had the same effect here bringing up our interactive users on TSS, a powerful but somewhat user unfriendly system. One has to spend some careful thinking in the TSS case in developing a beginning subset of system commands so as not to overwhelm the user. Another feature (problem?) of TSS is that users can define their own system commands (one letter commands if they wish), as a combination of existing system commands with desired parameters, or merely rename system commands according to their desires. This feature makes command completion really difficult to implement. What makes it impossible is the IBM penchant for half-duplex data communications to ASCII start-stop, asynchronous terminals. Logging on TSS over the net requires one to set the TIP to "transmit-on-linefeed". If one only uses locally connected IBM 3270 (full screen CRT) terminals one can live with a fairly crude editor, and the user interface is tolerable. Updating a full screen at a time at channel rates kind of spoils a person, I suppose. Maybe this topic belongs on HUMAN-NETS, but I'm interested in inputs on user interfaces. Let's keep them coming. Best, Don Reynolds (415) 965-6444 (Reynolds at Ames-67) ------
Zellich@OFFICE-3@sri-unix (07/23/82)
True, you may have problems if you drastically change commands; this has zapped us a few times in using Tymshare's evolving version. It helps a lot though, if you advertise the "gotcha" type changes when you field the new release. Note that the Augment/NLS interface uses \full words/ in command files, rather than single command-characters. Thus, the command files are not at all cryptic, and tend to just bomb out rather than doing the wrong thing if the command language changes and you forget to update a command file. There is no real problem renaming commands with the Augment/NLS user interface (if the particular program is designed that way - the "regular" subsystems aren't). The grammar parser is working from a table describing what is to be collected from the user next, and what to do with it. It allows not only literals in the command table, but also variables and list-variables. Thus, in some of our subsystems, we have allowed the users to change the standard command words by simply carrying them as useroptions and stuffing the words into a list structure which is passed into the grammar-table environment. You still have the problem of a particular user not thinking too clearly and defining duplicate command words, but that can be checked for in the "Define" (or "Rename" or "Change Command-word", or whatever you want to call it) command. You could \also/ check for first-letter duplicates, and warn the user if you wanted to, so multiple characters wouldn't be required to invoke the duplicate commands. There are problems possible with single-character command invocation, but you can solve most, if not all, of them by careful design. Cheers, Rich -------