[net.cog-eng] long names and hardware...

weamc@pyuxa.UUCP (12/05/83)

I am not sure that the problem is in hardware. I run my terminal hooked
to my computer at home at 9600 baud, and I can draw amy kind of menu
I like. Personally, I think that ASCII terminals are an elegant solution
to a very difficult problem, and I do not think that bit-mapped terminals
are the answer. Look at the chaos in micros, with everybody implementing
their own version of screen-handling. Software becomes very unportable.
A higher baud rate will partially solve the delay problem with menus, and
the rest of it will be solved by better use of the cursor-addressing
features of terminals. Many programs (written more than two or three
years ago) do not use cursor-addressing, so they put out many time-wasting
blanks.
  As for bit-mapped graphics and "windows," I think the jury is still out.
Windows are cute, exercise and demonstrate the graphics capability of a 
system, and the idea is the latest buzzword, but a higher baud rate
(i.e. the ability to re-write the screen quickly with another application)
will address most of the issues that windows supposedly address. Does
anyone recall if Xerox ever did any research to indicate that windows
improve human performance?????
                                 Andy Cohill

rene@umcp-cs.UUCP (12/07/83)

>>  As for bit-mapped graphics and "windows," I think the jury is still out.
>>Windows are cute, exercise and demonstrate the graphics capability of a 
>>system, and the idea is the latest buzzword, but a higher baud rate
>>(i.e. the ability to re-write the screen quickly with another application)
>>will address most of the issues that windows supposedly address. Does
>>anyone recall if Xerox ever did any research to indicate that windows
>>improve human performance?????
>>                                 Andy Cohill

I thought the idea of windows was to address a problem that
non-programmer users complained of - the lack of a cluttered desk. The
people buying systems for their office sort of liked having little
bits of paper strewn around to remind them of tasks they need to do,
with the current one on top of the clutter. When I saw a demonstration
of SCION's (neato!) Superscreen (I suppose it's copyrighted or
something), they told me all the windows flipping on top of one
another and crawling around the screen and changing size and so forth
were to recreate the cluttered desk of the busy executive.

					- rene
-- 
"Peoles have feeelings, too"
Arpa:   rene.umcp-cs@CSNet-relay
Uucp:...{allegra,seismo}!umcp-cs!rene

jfarrell@sun.uucp (Jerry Farrell) (12/07/83)

[I removed the address to net.nlang because I'm fairly sure we've
exhausted whatever interest that group had in this discussion.]

Andy Cohill asks whether "... Xerox ever did any research to indicate that
windows improve human performance?????" after noting the benefits of
(more-or-less) compatible ASCII terminals.  The question is a little
confused, since windows have been around on ASCII terminals for quite a
few years;  I think what he's referring to is more bit-mapped displays,
pop-up menus, and mouse interfaces.  The answer, to the best of my
knowledge, is no, except for the well-known superiority of mice over
most other positioning devices.  It might be an interesting
undergraduate psych experiment.  There is the evolutionary evidence,
that no programmer who had access to an Alto or beyond built a keyboard-
oriented interface for a game or personal hack....  Playing Missile
Command with a mouse is a vast improvement over a trackball, not to
mention over 10X TREK.

jf

eric@apollo.UUCP (Eric Peters) (12/07/83)

Andy Cohill@pyuxa.UUCP writes 

>    As for bit-mapped graphics and "windows," I think the jury is still out.
>  Windows are cute, exercise and demonstrate the graphics capability of a 
>  system, and the idea is the latest buzzword, but a higher baud rate
>  (i.e. the ability to re-write the screen quickly with another application)
>  will address most of the issues that windows supposedly address.

As a user of a bit-mapped, window system for the past several years (I leave
it as an exercise to the reader to determine the brand), I have to throw my
two cents in.  I've tried, and I cannot go back to using an ASCII terminal
for real work, even at very high Baud rates.  It's not nearly powerful or
convenient enough.  Right now my screen is covered with windows representing
several different processes.  In fact I just now got some mail on another
subject, and took a few minutes to read it and respond to it, without upsetting
my session of "readnews" in this window at all.  In fact, "readnews" in Process
12 was just underneath a rather large window for Process 16 where I was reading
that mail.  Bet no one even noticed!  It takes only an eyeblink to "pop" one
in front of another.  I look at my screen and I can graphically see everything
going on in my machine.  I see several fonts (one called "extremely_tiny" is
useful for "readnews"!), and my on-screen clock is a good sized, easy to read
seven-segment display.

I could go on about the advantages of windows and bit mapped graphics, but I
suspect that until you've lived with a really good system and then tried to
go back to the old way, can you appreciate the difference.  I'm certain it
improves THIS human's performance.

As for long names, we've taken an approach here that I have not seen mentioned
anywhere else:  We divided all command names into pairs <verb><noun>, and
then came up with a fairly short list of abbreviations for the common actions
and objects.  The result is a large set of command names that can be generated
from a small number of abbreviations.  For instance, "f" as a noun always stands
for "file", so "cpf" is "copy file", and "dlf" is "delete file" and so on;
"t" stands for "tree", as in directory tree, so "cpt" is copy tree, and "dlt"
is "delete tree".  This scheme works best with the most commonly used concepts,
such as files and trees, and perhaps gets a bit ragged at the edges (such as in
"salrgy" for "salvage registry (of passwords)"), but it does enable a novice or
casual user to handle a fair number of the most useful commands while remembering
only a handful of the most common abbreviations.

Right now, there are 29 nouns and 32 verbs, so both lists easily fit in windows,
and are, in fact, lurking right behind this window that I'm in.

Eric Peters  (...decvax!wivax!apollo!eric)

dave@rocksvax.UUCP (Dave Sewhuk) (12/08/83)

You think that today's ASCII terminals are OK for menus!!  You can have
at most 1920 characters of context on this menu in a single font.
Having used screen editors with real windows on bit mappped displays to
put together documents based from data in 3 files I would say that you
do not have enough context to help you.  Consider you need 2 lines of
that 24 line screen to lay down box edges to define the edges of the
file windows that leaves you with only 580 characters for equal
windows.   That is only 7 lines of text.  Also ASCII terminals have to
send keystrokes to down serially.  To scroll around you have to
use those blasted awful "arrow" keys, or commands to jump you from
window to window, no thanks.  I like having lots of context, it saves
me from making as many hardcopies, plus the ability to stuff text from
one window to another with the mouse.  It is nice to see that structure
in on that .h file in one window and the thing your working on in
another.  You tend to get things spelled correctly.

I think we need better hardware than plain ASCII terminals to do that
job.  Also consider that it is hell on the vt100 to send half of those
commands.  They involve sending some 5 bytes of data to do one little
operation.  That and no vt100 runs at 960 cps throughput.  They all run
throughputs on the order of 480 cps on plain text.  Those fancy scroll
functions take many milliseconds to run after you get those 5 bytes there.
It makes a busy screen take a long time
to get the cursor to move or scrolling seems sluggish.  When I see things
taking a long time I get restless, not a good mode to running in.


-- 
Dave

Arpa: Sewhuk.HENR@PARC-MAXC.ARPA
uucp: {allegra, rochester, ritcv, ritvp, amd70, sunybcs}!rocksvax!dave

henry@utzoo.UUCP (Henry Spencer) (12/08/83)

Being able to re-write the screen quickly with another application
will not solve the problem of wanting to look at both *simultaneously*.
The key point of windows is not flipping back and forth but being able
to attend to multiple activities *without* flipping back and forth.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

weamc@pyuxa.UUCP (12/08/83)

My terminal is still  smoking from the flames that Bell Labs people
sent me about my remarks about the BLIT, so I am posting a general
reply.
     My information about loading the system came from the UNIX person
at PY responsible for installing the software for the BLITs. *He* told
me it dragged the system down. I used the word *reportedly* because I have
not worked on a system with a significant number of BLITs installed.
     For those of you that sent me notes about BLIT not being being an
acronym--do you think that I made that up??? I have heard several
people refer to it as the "Bell Labs Intelligent Terminal." There is more
than one person here with that idea. Given the propensity of people
at the Labs to make acronyms, it seems more likely that it is an acronym
than not.
    For those of you that lambasted me with stories of how wonderful
your BLITs are, I am reasonably sure that you are right. What I said,
if you read it closely, was that I don't think the ASCII technology is
dead yet. for one thing, I can hook an ASCII terminal up to virtually
any computer in the country and do useful work. You *cannot* hook up
a bit-mapped terminal that way. (Before I get anymore flames, I know that
the BLIT can function as a dumb terminal--that's not the point.) I think
the ASCII technology can be extended to provide many of the features
of bit-mapped terminals and still retain the universality of ASCII.
   What distresses me is the headlong rush to make everything have 
windows, just as last year it was to make everything user-friendly,
and the year before that it was something else. The computer community
is a little too much in love with technology and buzz-words. 
            
                           Andy Cohill

rpw3@fortune.UUCP (12/14/83)

#R:pyuxa:-41000:fortune:29300001:000:2289
fortune!rpw3    Dec 13 22:18:00 1983

One of the things we tried to be careful about in our keyboard design
was to make sure that all of the function keys were legal UNIX commands
when typed to a shell (yes!). Since the function keys are triplets of
{Ctrl-A,<letter>,CR}, and since ^A as part of a name is o.k., we won.
Other terminals such as Tv 950's do similar stuff.

Sooo, if you find yourself doing something a lot, or if you are setting
up your secretary or a casual-user friend, you run "mkcmd <fcn key>",
which runs 'mkcmd' with the first two chars of the key as an arg.

'mkcmd' is:

	case X$1 in
	X)	echo 'usage: "mkcmd file" or
	"mkcmd dir/file" (default dir=$HOME/bin) or
	"mkcmd <function key>"'
		exit
		;;
	X*/*)	file=$1
		;;
	*)	file=$HOME/bin/$1
		;;
	esac
	$EDITOR $file
	exec chmod a+x $file

When you exit from the editor, you can then use <fcn key> to invoke the
script you just wrote. ('mkcmd' is also useful for text words, like "mkcmd foo")
'Csh' aliases can also be used, if you prefer.

Now I am NOT saying this is God's gifty to anybody, but think... How many
common operations do you do at your "desk", anyway? How many does "casual
user" do? For me,

	F1 = clearscreen (terminal deliberately has no clear key)
	F2 = mail (and fancy handling thereof)
	     (Shifted-F2 = print batches of saved mail, running through
	      sed to get one page per, etc, etc)
	F3 = readnews/notes (etc.)
	F4 = prompt (with echo/read's) for who and subj, then fire
	     up $EDITOR in $HOME/memo/$who/$date.$subj with the standard
	     intracompany memo form in the buffer already

	F9 = mount a floppy and show directory
	F10 = show directory and dismount floppy

That covers about 95% of the actual "desk" time I use outside of editors.
For my boss's secretary, F2 alone covers 98%.

I may not have made my point very well, and this is NOT an attempt to
incite flames, but discussion. I am seriously concerned about "human
engineering", but it seems that we have not even defined the problem
very well.  Fancy hardware will never make complicated jobs easy. Time
and motion study of the office still has a place. The 90/10 rule is
still valid.

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065