Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site sdcsvax.UUCP
Path: utzoo!linus!decvax!ittvax!dcdwest!sdcsvax!davidson
From: davidson@sdcsvax.UUCP
Newsgroups: net.cog-eng
Subject: Re: expert-friendly: are long names a waste of time?
Message-ID: <53@sdcsvax.UUCP>
Date: Sat, 3-Dec-83 00:54:44 EST
Article-I.D.: sdcsvax.53
Posted: Sat Dec  3 00:54:44 1983
Date-Received: Sun, 4-Dec-83 07:43:22 EST
References: <1490@utcsstat.UUCP>
Organization: U.C. San Diego, EECS Dept.
Lines: 53

Continuing in the context of Laura's analysis, we have (1) novices,
(2) experts and (3) casual users to please with our command languages.

All but the rankest novices will know at least some commands, and all
but the most expert will not know a great many others, especially in a
system like UNIX, where a command is any program and there are hundreds
of them.  If a user knows a command, they will want to enter it in as
abbreviated fashion as possible, and aside from the question of how
they learned it, they will be better off with short names.  Both command
completion systems and regular expression abbreviation systems require
more keystrokes than short names. 

Let us suppose that the purpose of large names is to enable users to
guess at the names of commands they are not very familiar with.  Now
the name of a command, even when mnemonic, is fairly difficult to
guess, especially when there is a choice of several hundreds of
commands.  This is a common problem in EMACS, where there are hundreds
of commands with long names like case-paragraph-raise (initially
capitalize the words in the paragraph), which are similar to other
commands like case-paragraph-upper (capitalize all of the letters in
the words in the paragraph).  The response to this is that if you don't
know an EMACS command, you use apropos to find its name.  The long
names simply become a clumsy way to specify keywords.

In UNIX, we have a similar situation, but we have the advantage of
short command names and a (slightly) more sophisticated keyword based
help system (also called apropos).  If you know a command, you want its
name and options to be first, short, and second, mnemonic, in that
order of priority.  If you don't know the command name, you find out
with apropos.  If you don't know a particular option, you find out with
man.  Both the command lookup facility and the option descriptions in
the manual could stand improvement, but the division of labor is quite
efficient.

Given the choice to make command and option names as short as possible,
it is still important to make them both mnemonic (easy to guess and
recognize) and iconic (easy to associate with their meaning).  The
biggest help here is to have some regularities.  For example, the
regularity among the compiler names cc, cp, and ct help casual and
expert users guess the names.  A second big help is option consistency
across commands, e.g., l for long, R for recursive, etc.  Existing
conventions like this need to be documented and stressed, so that new
commands will tend to be consistent.

As for menu systems, I have used some excellent ones on the MIT and
Xerox Lisp and Smalltalk systems.  I've used some passable ones on more
affordable systems, including the SUN workstation.  Window oriented
menu systems can be great, as long as one of the windows is a command
window!  Being trapped in a menu system, or having only one line of
historic context in a command window is simply not worth the advantages
of menus.

-Greg