Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site rabbit.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!vax135!ariel!hou5f!hou5g!hou5h!eagle!
allegra!alice!rabbit!ark
From: a...@rabbit.UUCP
Newsgroups: net.cog-eng
Subject: user-friendly?
Message-ID: <1986@rabbit.UUCP>
Date: Wed, 28-Sep-83 09:11:08 EDT
Article-I.D.: rabbit.1986
Posted: Wed Sep 28 09:11:08 1983
Date-Received: Thu, 29-Sep-83 05:41:03 EDT
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 8
It occurred to me last night that by borrowing two current buzzwords
somewhat out of context, we can describe the UNIX* system pretty well:
"expert-friendly"
Actually, I'm partial to user-hostile ignorance-based amateur systems :-)
* UNIX is a Trademark of AT&T Bell Laboratories
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watmath.UUCP
Path: utzoo!watmath!idallen
From: idal...@watmath.UUCP
Newsgroups: net.cog-eng
Subject: Re: expert-friendly: are long names a waste of time?
Message-ID: <6015@watmath.UUCP>
Date: Sun, 23-Oct-83 16:31:58 EDT
Article-I.D.: watmath.6015
Posted: Sun Oct 23 16:31:58 1983
Date-Received: Mon, 24-Oct-83 00:30:35 EDT
References: <558@minn-ua.UUCP>
Organization: U of Waterloo, Ontario
Lines: 19
But most short names are abbreviations for long names. RM is an abbreviation
for REMOVE FILE, RMDIR is an abbreviation for REMOVE DIRECTORY.
If you claim that nobody will remember a long name, then I claim
you make it worse by forcing people to remember the abbreviation too.
If you want to argue about what people will remember, then we should
talk about ways to minimize the amount of stuff that has to be remembered.
I don't know if memorizing arbitrary abbreviations is easier than
remembering whole words, but I do know that memorizing fewer things is
better than memorizing a lot of things.
Teach me command names in a cross-product approach, where I only need
to remember a few verbs and objects. Allow me synonyms for each.
(Let DATASET be synonymous with FILE; let DELETE be synonymous with
REMOVE.) Then, I can build most of my commands using the verbs and
objects I know.
--
-IAN! (Ian! D. Allen) University of Waterloo
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utcsstat.UUCP
Path: utzoo!utcsstat!laura
From: la...@utcsstat.UUCP (Laura Creighton)
Newsgroups: net.cog-eng,net.nlang
Subject: Re: expert-friendly: are long names a waste of time?
Message-ID: <1490@utcsstat.UUCP>
Date: Sun, 27-Nov-83 23:53:45 EST
Article-I.D.: utcsstat.1490
Posted: Sun Nov 27 23:53:45 1983
Date-Received: Mon, 28-Nov-83 00:38:58 EST
References: <6196@watmath.UUCP>, <507@dciem.UUCP>
Organization: U. of Toronto, Canada
Lines: 69
I have been thinking about those long names. They will be a pain to type,
right? So I will either have a shorter-to-type private version in my bin,
or the command interpreter will understand abbreviations (perhaps like
TOPS-20). So the question is "who are the long commands for"?
there are people who like Ian Allen, find them aesthetically pleasing.
this is all any very good for them, but if this is the primary reason
then we can just ask Ian Allen to put long forms in *his* bin...
there are novice users. Now, we never settled this the last time, but I
still think that novice users have a very short lifetime. Give them a
week or a month and they can learn to use "grep" and "cat" like the
rest of us. It is possible to design systems for them, but this is
(in my opinion) silly. They will be experts too quickly and will have
the same complaints about the long names that the rest of us have --
they take too long to type. Thus it is only the marketing types that
have "novice users" as their primary concern, since all they have to
do is SELL the product -- once they have sold it it becomes the problem
of the 'support staff' or some other group...
there are casual users. I define casual users to be users that never
will use the system often enough to become an expert -- or who use the
system infrequently enough that they have to relearn the system every time
as if "from scratch". Shoppers using a computerised store directory are
the first sort, and professors who use the system once a year to put in
a grant request and their latest paper are the second sort.
I have come to the conclusion that these people are the primary
beneficiaries of the 'long name' command syntaxes. But now that I
have isolated (what I perceive as) the problem, I have come to the
astonishing conclusion that THESE FOLK DON'T WANT LONG NAMES.
These are the people who want menus. They want a pop-up menu with the
answer to every possible mess they could get themselves into.
Now, what is it that the long words have over the menus...
THE MENUS TAKE TOO LONG TO GET DRAWN ON THE SCREENS.
(we will assume that you have solved the 'from leaf to leaf I'm
want to leap, across the branches I'm forced to creep' problem. It is
hard, but not unsurrmountable.) The menus take forever to come up
and get drawn. this problem is exacerbated by people who want to make
it clear to the user that they knew every feature that the vt100 has,
and thus play multiple bells and draw funny pictures in inverse video and
play with the scrolling regions. It looks spiff-o but it *takes too
long*. The problem with a menu system is that I can type faster than
it will give me the menus, so I get pissed off with the whole thing.
But this is not an inherant problem with menus. IT JUST MEANS THAT THE
HARDWARE WAS NOT DESIGNED FOR MENUS. So if you had real slick fast
hardware that didn't think that it was an ascii typewriter you could get
a blindingly fast menu system. What if you had multiple windows
(a la blits) and if the menu maintaining stuff lived in your terminal...
I dunno folks. I think that the idea has merit, but then I haven't
heard *anybody* talking about "hardware that thinks that it is a
typewriter being user-hostile". I have yet to see the HARDWARE DESIGN
raked over the coals as I just did...and there are a fair number of
vociferous coal-rakers in the field of human factors...
Maybe bitmapped displays are too new, or maybe I have been reading the
wrong articles. What do other people think? I have just killed the
pro-"long command names" group by assuming that long commands are
menu-replacements that are useful only because menus take too long
to draw on the screen -- probably that is unfair. But, for the life of
me, I can't see what else they are for...
Laura (puzzled) Creighton
utzoo!utcsstat!laura
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watmath.UUCP
Path: utzoo!watmath!idallen
From: idal...@watmath.UUCP
Newsgroups: net.cog-eng,net.nlang
Subject: Re: expert-friendly: are long names a waste of time?
Message-ID: <6206@watmath.UUCP>
Date: Mon, 28-Nov-83 18:05:00 EST
Article-I.D.: watmath.6206
Posted: Mon Nov 28 18:05:00 1983
Date-Received: Tue, 29-Nov-83 04:51:17 EST
References: <6196@watmath.UUCP>, <507@dciem.UUCP>, <1490@utcsstat.UUCP>
Organization: U of Waterloo, Ontario
Lines: 67
=======================================================================
From la...@utcsstat.UUCP (Laura Creighton) Sun Nov 27 23:53:45 1983
I have been thinking about those long names. They will be a pain to
type, right?
Right, but what good is a command name that is easy to type, if you can't
remember it? Remember the name first, abbreviate it only when you use
it often enough to need an abbreviation. The abbreviation might even
be a system alias for the long name. Or, it can be a personal alias
chosen when you find yourself using the command a lot. I wonder which
is easier to remember, an abbreviation I choose myself, or one someone
else chooses for me? With long names at least no one is *forcing* me to
remember their abbreviations. And, if I forget my own abbreviation I
can still use the full name...
there are people who like Ian Allen, find them aesthetically pleasing.
Wasn't me that said this. I like them because they are easier to
learn and remember than abbreviations. Less brain work.
there are novice users. They will be experts too quickly and will have
the same complaints about the long names that the rest of us have --
they take too long to type.
Quickly? How will nonsense names help them learn? If you want names that
are easy to type, then do the job properly and assign your favourite 26
commands to letters of the alphabet (very favourite eight to the home
row of the keyboard, of course). Novice users are either going to
remain novices, in which case you shouldn't expect them to use a
command language at all, or else they are going to become.......
... casual users. I define casual users to be users that never
will use the system often enough to become an expert -- or who use
the system infrequently enough that they have to relearn the system
every time as if "from scratch".
Every user who has ever forgotten or had to look up the name of a command
is in this category. There are no "experts"; only experts in some area.
Even our local UNIX gurus don't know all the INGRES database commands that
are in /usr/bin. Any time you go scrambling for the name of a command,
you aren't an expert. You are in need of mnemonic aid for a command name.
You don't need a cryptic abbreviation, you need something you can remember.
Something that works in with all the other command names you know.
I have come to the astonishing conclusion that THESE FOLK DON'T WANT
LONG NAMES.
Research report number?
These are the people who want menus. They want a pop-up menu with
the answer to every possible mess they could get themselves into.
Hey, you forgot to interview me. When I need to do something, I don't
want to have to call for a menu of all possible moves (especially at UNIX
shell command level -- at last count WATMATH had 400 command names out there).
I'd rather that the command names were structured so that I could build
on what I already knew (like deriving debug_pascal from compile_pascal).
I have just killed the pro-"long command names" group by assuming
that long commands are menu-replacements that are useful only because
menus take too long to draw on the screen -- probably that is unfair.
Not unfair, just not true. You can't replace the mental step between
"compile_pascal" and "debug_pascal" with a menu of 400 commands.
--
-IAN! (Ian! D. Allen) University of Waterloo
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.cog-eng,net.nlang
Subject: Re: expert-friendly: are long names a waste of time?
Message-ID: <3384@utzoo.UUCP>
Date: Tue, 29-Nov-83 17:56:49 EST
Article-I.D.: utzoo.3384
Posted: Tue Nov 29 17:56:49 1983
Date-Received: Tue, 29-Nov-83 17:56:49 EST
References: <6196@watmath.UUCP>, <507@dciem.UUCP>, <1490@utcsstat.UUCP>,
<6206@watmath.UUCP>
Organization: U of Toronto Zoology
Lines: 41
I'm afraid I have to go along with Laura. A user who does not know
how to do what he wants does not *want* to have to guess whether he
should type "list", "print", or "output" (to say nothing of "lpr"!)
to get a printout on the line printer. He wants a menu which says,
among other things:
list list contents of current directory
print print a file on the line printer
I hope this example clearly indicates the perils of requiring users
to guess command names, be those names long or short.
Ian! comments "novice users are either going to remain novices...or
become casual users". Wrong, this was just Laura's point: either
they will become casual (i.e., once-a-month) users, or they will
become experienced users. No way will they remain novices (in the
precise sense being used here). "Experienced" does not necessarily
mean "expert" or "knowledgable"; it means "I know how to do the things
I do frequently". This is exactly the right condition for abbreviations
and short commands. When dealing with things she does not do often,
the experienced user (that includes you and me, folks!) is effectively
a casual user, i.e. has no idea how to obtain function "foo". This is
exactly the right condition for menus. Why do you think summary cards
are so popular?
Ian! further observes that he doesn't want to call up a 400-item menu.
This is so ridiculous that I can only class it as a deliberate attempt
to obscure the issue, like the twits who still refuse to install Unix
because "its file system isn't crashproof". Nobody in his right mind
is going to set up a 400-item menu; it's going to be tree-structured,
with a top level set up by general areas of activity. With a fast display
and a mouse, getting to (say) Pascal compilation from there is click,
click, click. Faster than typing "compile_pascal", and no memory needed.
I agree with Ian! that if one *must* guess the name of a command, life
is simpler if names are formed systematically so that guessing is easy
and reliable. The point is that the system should not require me to
guess command names at all!
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!seismo!rlgvax!cvl!umcp-cs!koved
From: ko...@umcp-cs.UUCP
Newsgroups: net.cog-eng,net.nlang
Subject: Re: expert-friendly: are long names a waste of time?
Message-ID: <4151@umcp-cs.UUCP>
Date: Thu, 1-Dec-83 01:44:40 EST
Article-I.D.: umcp-cs.4151
Posted: Thu Dec 1 01:44:40 1983
Date-Received: Fri, 2-Dec-83 03:14:10 EST
References: <6196@watmath.UUCP>, <507@dciem.UUCP> <1490@utcsstat.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 50
Laura,
Your view of the world is too narrow to see over the top of your keyboard.
When you go out of the computer room at your school, you may run into
many computer users who are not interested in learning about computers...
they just want to get their work done.
Of course there are the novice users and those executives or secretaries
who could benefit from menus. Menus could possibly solve 90-100% of their
problems. This is being used in the *real* world. Long command names
for commands are not necessary for them since they do not need commands
at all.
The infrequent users need a way of remembering the commands (which may
be the full command name rather than the abbreviated form). Some of the
systems I have seen contain several levels of abbreviations and synonyms
for the commonly used commands plus personally tailored versions which
are automatically added to the system (global) versions. This seems to
work rather well when the synonyms and abbreviations are used. In general,
a user can use the whole command name (or its synonyn) or its abbreviation.
There is a set of users of computers who must contend with multiple sets
of operating systems, editors, mail systems, etc. which are operating
on different brands of hardware and software. If they must become experts
to remember the abberviated forms of all of the commands which they need
to commonly use, nothing would ever get accomplished. I find myself lucky
that I only use 3 computer systems (with completely different command
formats and different names)! I know of people who use more than 3
systems during a week (although I use all 3 almost every day)! This
may become more common with the proliferation of small cheap machines.
These people want to get work done, but having to learn all of the
abbreviations for each of the systems on which the person is working
is too much of a burden.
From experience, once the salesman has sold the software, the fun just
begins! Many places do not have *experienced* staff to install the software
and maintain it. If the commands are not spelled out completely, the
installer-user becomes confused and frustrated. This is one of the
reasons that computers and software have bad reputations (ie: the computer
made an error.... not that the person using the computer made an error
while using a program). Some of the people using the software are very
bright, but are not familiar enough with the computer to understand all
of the abbreviations and computer jargon. I constantly deal with people
who are non-experts who are trying to install and use software. These
problems repeat themselves often.
This is not to say that I am against short command names and abbreviations
and synonyms... On the contrary! However, they have their place, and
must be taken in perspective.
Larry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site pyuxa.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxl!cbosgd!cbdkc1!pyuxmm!pyuxnn!
pyuxi!pyuxa!weamc
From: we...@pyuxa.UUCP
Newsgroups: net.cog-eng,net.nlang
Subject: Re: long names and hardware...
Message-ID: <410@pyuxa.UUCP>
Date: Mon, 5-Dec-83 11:41:55 EST
Article-I.D.: pyuxa.410
Posted: Mon Dec 5 11:41:55 1983
Date-Received: Wed, 7-Dec-83 09:12:46 EST
References: <6196@watmath.UUCP>, <507@dciem.UUCP>, <1490@utcsstat.UUCP>
Organization: Bell Labs, Piscataway
Lines: 19
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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!decvax!harpo!seismo!rlgvax!cvl!umcp-cs!rene
From: r...@umcp-cs.UUCP
Newsgroups: net.cog-eng,net.nlang
Subject: Re: long names and hardware...
Message-ID: <4270@umcp-cs.UUCP>
Date: Tue, 6-Dec-83 18:26:45 EST
Article-I.D.: umcp-cs.4270
Posted: Tue Dec 6 18:26:45 1983
Date-Received: Fri, 9-Dec-83 04:50:14 EST
References: <6196@watmath.UUCP>, <507@dciem.UUCP>, <1490@utcsstat.UUCP>
<410@pyuxa.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 24
>> 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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site pyuxa.UUCP
Path: utzoo!linus!security!genrad!decvax!harpo!eagle!mhuxl!mhuxm!pyuxi!pyuxa!weamc
From: we...@pyuxa.UUCP
Newsgroups: net.cog-eng
Subject: Re: windows...
Message-ID: <420@pyuxa.UUCP>
Date: Wed, 7-Dec-83 13:53:27 EST
Article-I.D.: pyuxa.420
Posted: Wed Dec 7 13:53:27 1983
Date-Received: Fri, 9-Dec-83 07:40:43 EST
References: <6196@watmath.UUCP>, <507@dciem.UUCP>, <1490@utcsstat.UUCP>
<410@pyuxa.UUCP>, <370@sun.uucp>
Organization: Bell Labs, Piscataway
Lines: 22
I don't have anything against windows, per se. I am aware of the analogy
between over-lapping windows on a CRT and the little piles of notes
on a desk. What irritates me is the head-long rush to announce software
with "windows." I am not convinced that the analogy is an apt one, because
no one has done any research (that I've seen) to indicate that windows do
help the user. In a time-sharing system, bit-mapped displays would impose
an huge load on the system.
An example of this is the infamous BLIT terminal,
(Bell Labs Intelligent Terminal) which requires a special software front end
to run, and reportedly drastically slows system response.
I suspect that there are cheaper ways to provide some of the things that
windows provide.
As far as using a mouse goes, I have used a Lisa, and found the mouse
irritating because I had to keep moving my hand off the keyboard. I was
doing text input, which was part of the problem.
I don't have anything against new ideas, but it bothers me that they
are picked up and used before the paint on the old stuff is barely dry.
The poor slob of a user suffers as he is told, time after time, that
the framistan is the cure for all his or her ills. (Replace framistan
with data base, user-friendly, windows, mouse, UNIX, bit-mapped, etc...).
Andy Cohill
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 Apollo; site apollo.UUCP
Path: utzoo!linus!security!genrad!decvax!wivax!apollo!eric
From: e...@apollo.UUCP (Eric Peters)
Newsgroups: net.cog-eng
Subject: Re: long names and hardware... (windows)
Message-ID: <198@apollo.UUCP>
Date: Wed, 7-Dec-83 14:39:52 EST
Article-I.D.: apollo.198
Posted: Wed Dec 7 14:39:52 1983
Date-Received: Fri, 9-Dec-83 04:20:51 EST
References: <410@pyuxa.UUCP>
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 45
Andy Coh...@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)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!seismo!rlgvax!cvl!umcp-cs!rene
From: r...@umcp-cs.UUCP
Newsgroups: net.cog-eng
Subject: mice, pens, and graphics
Message-ID: <4291@umcp-cs.UUCP>
Date: Wed, 7-Dec-83 20:27:11 EST
Article-I.D.: umcp-cs.4291
Posted: Wed Dec 7 20:27:11 1983
Date-Received: Sat, 10-Dec-83 01:34:00 EST
References: <6196@watmath.UUCP>, <507@dciem.UUCP>, <1490@utcsstat.UUCP>
<410@pyuxa.UUCP>, <370@sun.uucp> <420@pyuxa.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 14
I have worked with mice a little, and I must say that though they may
be good for window addressing (is that how'd you say that?) they are
lousy for graphics. Bit pens work much better, more like a pen or
brush. There's no control with a mouse - you must move the entire arm
to move the mouse, whereas with a bit pad you can get fine movements
by moving just your fingers. Track balls are the absolute worse,
though. Anyone work with the graphics side of this tangent of the
discussion?
- rene
--
"Peoles have feeelings, too"
Arpa: rene.umcp-cs@CSNet-relay
Uucp:...{allegra,seismo}!umcp-cs!rene
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site pyuxa.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!harpo!eagle!mhuxl!mhuxm!pyuxi!pyuxa!weamc
From: we...@pyuxa.UUCP
Newsgroups: net.cog-eng
Subject: Re: long names and hardware...
Message-ID: <424@pyuxa.UUCP>
Date: Thu, 8-Dec-83 09:33:43 EST
Article-I.D.: pyuxa.424
Posted: Thu Dec 8 09:33:43 1983
Date-Received: Sat, 10-Dec-83 01:28:58 EST
References: <6196@watmath.UUCP>, <507@dciem.UUCP>, <1490@utcsstat.UUCP>
<410@pyuxa.UUCP>, <1107@rocksvax.UUCP>
Organization: Bell Labs, Piscataway
Lines: 28
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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 SMI; site sun.uucp
Path: utzoo!linus!security!genrad!decvax!decwrl!sun!jfarrell
From: jfarr...@sun.uucp (Jerry Farrell)
Newsgroups: net.cog-eng
Subject: Re: mice, pens, and graphics
Message-ID: <379@sun.uucp>
Date: Fri, 9-Dec-83 17:53:10 EST
Article-I.D.: sun.379
Posted: Fri Dec 9 17:53:10 1983
Date-Received: Tue, 13-Dec-83 01:21:10 EST
References: <4291@umcp-cs.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 28
Your general point that mice are not as convenient as styli for graphics
is valid (somebody at Xerox, I think it was Bob Flegal, once comnpared
it to drawing with a brick). But I'm a little surprised at your claim
that you have to move your whole arm, elbow, etc. I think this may be
an artifact of which mouse you use. I observed a while back that the
dePraz mouse (as used in the BLIT) requires a "power grip", which in
turn implies large-muscle motions. But the other mice I've used (Hawley
[Xerox mechanical], Kirsh [MSI, Sun, others], Lisa's) all are designed
for only one or two fingers on top, and enough on the side opposing the
thumb to permit finger & wrist manipulation. I just checked on this,
and find that I work with a wrist bone planted on the table-top, use wrist
rotation for almost any motion in X (I can cover this 80-column window
easily), and finger action for small motions in Y (15 lines of text is
about the comfortable limit of control). Larger displacements do take
arm motion -- but then, so do broad sweeps with a brush.
A confounding effect is the location of the sensor -- mechanical
designers want to move it back toward the wrist, to make room for the
buttons; users want it as close to directly under the index fingertip as
possible, to maintain the pointer effect.
For frequent changes between keyboard and pointing device, the mouse's
stability and cord position make it easier to acquire than a stylus,
which is a decided advantage in many UI situations; this and cost
probably outweigh the stylus' superiority for fine drawing, especially
given the relatively coarse resolution of most existing graphics systems.
jf
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!seismo!rlgvax!cvl!umcp-cs!rene
From: r...@umcp-cs.UUCP
Newsgroups: net.cog-eng
Subject: Re: mice, pens, and graphics
Message-ID: <4391@umcp-cs.UUCP>
Date: Sun, 11-Dec-83 13:13:17 EST
Article-I.D.: umcp-cs.4391
Posted: Sun Dec 11 13:13:17 1983
Date-Received: Tue, 13-Dec-83 05:15:29 EST
References: <4291@umcp-cs.UUCP> <379@sun.uucp>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 18
Perhaps the problem was with the type of mouse; I couldn't possible do
anything with just finger and/or wrist motion. However (I think I'm
repeating myself), you CAN'T draw pictures with a mouse, even if it
was of a better design. Mice are probably good for most graphics
(graphs and stuff) and as pointers (stability is very nice for lots of
mouse-keyboard transfers), but TRY using a paint system (I have). True
the resolution was only about twice that of a TV, but the pen was well
worth whatever difficulties it might have caused (of course, I was
only a user, and didn't pay attention to the other difficulties). Try
drawing a dragon with a mouse! (I actually drew one with a TRACK BALL -
*shudder*)
Can anyone think of a way to get the best of both worlds?
- rene
--
Arpa: rene.umcp-cs@CSNet-relay
Uucp:...{allegra,seismo}!umcp-cs!rene
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.cog-eng
Subject: Re: mice, pens, and graphics
Message-ID: <3419@utzoo.UUCP>
Date: Fri, 16-Dec-83 17:52:58 EST
Article-I.D.: utzoo.3419
Posted: Fri Dec 16 17:52:58 1983
Date-Received: Fri, 16-Dec-83 17:52:58 EST
References: <4291@umcp-cs.UUCP> <379@sun.uucp>, <4391@umcp-cs.UUCP>
Organization: U of Toronto Zoology
Lines: 9
When I visited New York Tech some years ago, all their tablets had
pens rather than pucks. Why? Because a substantial fraction of the
use of those systems was by real, honest-to-Ghod *artists*, who absolutely
insisted on pens. I think they were right. I would put a mouse (or
something similar) on a workstation I put together for myself, but
I'm not an artist.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site rocksvax.UUCP
Path: utzoo!linus!philabs!seismo!rochester!rocksvax!dave
From: d...@rocksvax.UUCP (Dave Sewhuk)
Newsgroups: net.cog-eng
Subject: Re: mice, pens, and graphics
Message-ID: <1144@rocksvax.UUCP>
Date: Fri, 23-Dec-83 17:08:45 EST
Article-I.D.: rocksvax.1144
Posted: Fri Dec 23 17:08:45 1983
Date-Received: Sun, 25-Dec-83 00:45:48 EST
References: <4291@umcp-cs.UUCP> <379@sun.uucp>, <4391@umcp-cs.UUCP> <3419@utzoo.UUCP>
Organization: Xerox, Rochester, N.Y.
Lines: 16
I don't like your arguments about "it had to have pens because the artists
wanted pens". That argument is a dumb as the one I heard about C.A.T. scanners.
The doctors didn't like the neat 2D graphic outputs at all, they only wanted
little slices through their patients bodies, because that was how they disected
bodies in school and could only think in 1 dimension, little slices. They
didn't like the rotating kidneys on the screen, only little slices through
them. Using you arguments you would think there is no need to try any other
display method and give them a fair shake.
People always seem to abhor change, good or bad.... or maybe they were
just put out that they didn't think of it first!!
--
Dave
Arpa: Sewhuk.H...@PARC-MAXC.ARPA
uucp: {allegra, rochester, ritcv, ritvp, amd70, sunybcs}!rocksvax!dave
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.cog-eng
Subject: Re: mice, pens, and graphics
Message-ID: <3426@utzoo.UUCP>
Date: Wed, 28-Dec-83 18:21:03 EST
Article-I.D.: utzoo.3426
Posted: Wed Dec 28 18:21:03 1983
Date-Received: Wed, 28-Dec-83 18:21:03 EST
References: <3419@utzoo.UUCP>, <1144@rocksvax.UUCP>
Organization: U of Toronto Zoology
Lines: 21
I agree that there is a potential problem with people insisting on
doing things the old way for no good reason. The point is that in
the case of artists, they have nontrivial motor skills which are
very much tied to pen-like objects. I don't know how much retraining
would be involved to get the same skills down pat with (say) a puck,
but I do know that the machines are supposed to adapt to us and not
the other way around! Claiming that the artists ought to be retrained
is like IBM's claim that I ought to get used to an extra key between
Z and SHIFT -- an outrageous imposition for no good reason.
Dave Sewhuk's example of doctors disliking new forms of presentation
from a CAT scanner is similar: ok, they disliked the rotating kidney
because it was unfamiliar, but their diagnostic training was built
around the old thin-slices style of presentation. It does seem likely
that the new form will make things easier in the long run, but in the
short run I would want my kidneys checked over by a doctor using a form
of presentation that he was familiar with. There is a big difference
between making new forms available and making old forms unavailable!
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry