Aucb.165
fa.editor-p
utzoo!decvax!ucbvax!C70:editor-people
Sat Dec 12 16:58:10 1981
EDITOR-PEOPLE Digest V1 #2
>From Admin.JQJ@SU-SCORE Sat Dec 12 16:32:25 1981
EDITOR-PEOPLE Digest Friday, Dec. 11, 1981 Volume 1 : Issue 2
Today's Topics:
Administrativa
keyboard designs (C-M-x is slower than 3 chars., but so what?)
Editor Command Language Debate (let's separate issues)
(QWERTY keyboards weren't designed to slow down typists!)
wanted--track balls
multiple keystrokes
Keyboard Layout
----------------------------------------------------------------------
From: Admin.JQJ at SU-SCORE
Subject: Administrativa
We've gone to a digest format for a change since the volume of
messages has gotten very large. If you have problems with this
format, or receive multiple or truncated messages, let me know (reply
to EDITOR-PEOPLE-REQUEST@SU-SCORE). Incidentally, I do not intend to
continue with the digest format unless the volume of mail remains
high.
Note also that due to disk space limitations at SU-SCORE the
archives in EDITORMAIL.TXT have been pruned. In the future, I plan
to retain messages from the last 3 months on line, with the rest
moved to tape. If you need the text of a very old message, send me
a note and I'll retrieve it.
------------------------------
From: sdcsvax!norman at NPRDC
Subject: keyboard designs
Reply-to: norman at NPRDC
Our experimental and theoretical studies of typing agree with the
comments made by Tom Moran. These results are for skilled typists
(around 90 wpm). (Our typing model cannot type capital letters yet.)
Although we have not studied a three-key combination
(META-SHIFT-letter) we have looked at two key combinations
(SHIFT-letter). The 2-key combination takes MORE than twice as long
as typing two regular characters. The time required to type the
capitalized letter is almost exactly twice that of a regular letter,
but in addition, the preceding and following letter keys seem to be
slowed up somewhat.
When a three key sequence is required, I predict that it will be even
slower than 3 regular characters. And if a less than
secretarial-level typist is involved, then probably some eye
movements will be required: each eye movement adds 200 msec, and
each keystroke is a minimum of 100 msec (except for skilled typists
who overlap movements), and adding this to the movement of the hands
off the home position and the necessary eye movements and corrective
actions to get back there means that a META-SHIFT-character
combination is apt to take between .6 sec and 1.0 sec. That's an
awfully long time to type a "single" command letter. Note that this
means that it is faster for almost every typist to type a 5 to 9
character sequence than a "single" character that requires meta,
control, and or shift keys.
HOWEVER, there is a big difference between real time and perceived
time and between real complexity and perceived complexity. Thus,
most typists of less than expert level skill would probably perceive
it to be easier and faster to type META-SHIFT-x than a command such
as "uncap", even if experimental studies showed that typing "uncap"
was faster. I would go with people's preferences. Most people would
be aware of a 1 second delay in getting response to a command
sequence on their screen, but unaware of the 1 second it takes to
type control-shift-meta-z. I believe that counting keystrokes is an
inappropriate method to judge an editor. The goal in editing is
certainly not to save a few seconds here or there. All the editor
studies I have seen measure time to complete a "routine" task as
their measure of the editor. However, most of us do non-routine
tasks (each new session is different from previous sessions). What I
believe is important in an editor is ease of planning the actions,
ease of retrieval of the appropriate command sequence, and ease of
correction of errors. Everyone makes errors, yet error correction is
not one of the criteria used for editor evaluation. There are
several different issues here:
ease of detecting that an error has been made
determining the current state
figuring out what happened
undoing the resulting state Note that the normal "last action
undo" is oftentimes (usually) insufficient.
I am a firm believer of the need for consideration of the users'
psychological characteristics. This means their information
processing mechanisms and also their mental models of the system.
Designers should provide a clean and consistent "system image" (SI)
for users to work with, with feedback, displays, and command
sequences all built around this one consistent SI. The instruction
manual, documentation, and help commands can then be constructed to
instruct this SI. The SI should be the first thing designed in
building a new system: all the rest follows from it. And, of course,
the SI must be one that the wide range of perceived users of the
system can deal with. System designers need to get design rules that
take into account the human user. Right now, designers seem either
to design for themselves or for some patronistic version of the
human, which offends most real users and gives the concept of
"friendly systems" a bad image. (A "friendly system" is not to be
confused with one that is verbose or one that hampers experts. Any
system that hampers a class of users is obviously not friendly for
that class.) As you see, I can write books about this topic -- and I
probably will.
don norman (norman@nprdc)
------------------------------
Date: 10 Dec 1981 1824-EST
From: Goldberg at RUTGERS (Robert N. Goldberg)
Subject: Editor Command Language Debate
I thought the original message about investigating cross-product
languages was very interesting. The current stream of messages seems
to mix several very different issues together, however.
If the purpose of this discussion is to resolve something or at least
clarify the issues, then I think we ought to draw a distinction
between the cross-product issue and the discussion on how many
keystrokes a control-meta-x key takes, or whether modeless editing is
better than modal editing.
For cross-products, we should consider the conciseness of the command
language in terms of primitives (*not* key strokes). It seems to me
that the major benefit of the cross product approach is that there are
fewer concepts or commands for the user to remember. Leaving
keystrokes aside, what problems are there with the expressive power of
this approach, if any? What are reasonable primitives and concepts?
I don't think we will ever agree on the keystoke issues being debated.
>From my own experience talking to experienced editor users, I have
come to the conclusion that many of the fine details being debated
(e.g. modal vs. modeless languages, two single keystrokes vs. a
single awkward one) depend more critically on personal taste and
previous experience than on demonstrable, quantifiable characteristics
of the command language. Some people can contort their fingers with
ease; others find it difficult. I know at least one veteran who has
a weak pinky and prefers to type a sequence of 4 printing characters
to typing a ^Z (but ^K is no problem for him). We might just as well
be debating whether cars should have automatic or manual
transmissions based on the number of clutch-strokes and shift-lever
motions.
------------------------------
Date: 10 Dec 1981 1928-EST
From: GILBERT at MIT-XX (Ed Gilbert)
Subject: Re: Moran's Comments
I just want to comment on an aside you made in your message to
editor-people.
The QWERTY keyboard wasn't designed to slow people down. I don't
have my reference materials here so I must hedge the details, but
here is what really happened:
In about the late 1870's Glidden and Sholes were working on a
typewriter which would eventually evolve into the popular and
long-lived Remington line. People operated the machine so quickly
that the type bars would jam. They needed an arrangement of the type
bar "basket" in which common sequences of two letters would have
those two letters on opposite sides of the basket. In the most
straightforward design of a manual typewriter this would have a
direct effect on the keyboard layout, but they were interested in the
type basket, not the keyboard. The brother of one of the two men, a
high school principal, determined the arrangement.
I do not consider myself an expert on the history of the typewriter,
but I believe this to be true. The only person I have talked to who
has done a lot of reading on the subject also feels that this is the
correct story.
It would seem that if all other variables were fixed and we only
addressed the issue of whether two letter sequences appeared on the
same or opposite side of the keyboard, then putting them on opposite
sides would allow for faster typing. Other factors, such as which
fingers type which keys, were probably not addressed at the time and
may be the cause of the QWERTY keyboard's being slower than some
other designs.
Sorry for the long note about a minor point, but the myth that
Glidden and Sholes were trying to slow people down is rather
widespread and I thought people might like to hear the true story.
By the way, it appears that touch typing was an invention; it didn't
always exist. Its merits, in fact, were quite vigorously debated.
Ed Gilbert
------------------------------
Date: 10 Dec 1981 20:56:25-PST
From: allegra!bill at Berkeley
Subject: wanted--track balls
Does anyone know of a commercial source that produces track
balls? We're contemplating some experiments comparing one to a mouse
for the purposes of cursor manipulation in an editor. Any pointers
at all will be appreciated (and will save us lots of time making one
ourselves). Also, pointers to information about experiments of this
kind will also be appreciated.
-Bill Schell
(allegra!bill@berkeley or ucbvax!allegra!bill)
------------------------------
Date: 10 Dec 1981 12:21:06-PST
From: cbosgd!mark at Berkeley
Subject: multiple keystrokes
I think we all agree that using escape to simulate a "real meta key"
loses, but it's hard to do better without redesigning the command
set, on a standard ASCII keyboard. Unfortunately, there are real
problems with the escape simulation if you also want to understand
arrow keys and function keys. I find that hitting more than one
shift key at the same time is about the same effort as one, as long
as the keys are all together (like control and shift). I don't know
where the meta and top keys are on these mystical terminals at MIT
and SU (would someone please tell me?) but can only guess that they
are like the Ambassador which is to the left of the left hand shift.
If they are in fact off somewhere else I imagine it would be much
harder. (For example, control D is one of the hardest characters for
me to type since I have to spread my fingers way out. Ctrl F is even
harder but seems rarely used in the UNIX environment.)
I asked our Human Factors people if they knew of any results on shift
keys and keystrokes, and they didn't. I am trying to interest them
in designing an experiment to find out. They have been quite adament
in praising the orthogonal command design - they feel that vi does
not go far enough in this regard.
One other comment worth noting is the notion of "stuttered keys".
For example, in vi, the d prefix means delete, the c prefix means
change, and so on. If you stutter it (dd, cc, etc) it means "affect
lines", thus dd deletes the current line, 5dd deletes 5 lines, and so
on. It turns out that a stuttered key is only epsilon more work to
type than just hitting the key once - I'd say dd is 1.1 keystrokes.
I haven't seen any editor other than vi make use of this property.
(You may be concerned about key bounce, but with a general undo this
is not a problem at all.)
Having special insert commands for the end of the line, for example,
may not seem like any improvement over a motion to the end of the
line followed by a regular append. But if you get in the habit of
using them, you find that there is an advantage. The . command,
which repeats the last change, will remember that it was an "end of
line" append you just did, so the repeat automatically appends at the
end of the line. Since lines are of varying lengths, often moving up
or down will leave you in the middle, so this wins big.
The whole notion of a "repeat last change" command appears to have
been underrated by the EMACS community. When making a set of very
similar changes to a file, all you have to do is lean on the n and .
keys (neither of which is shifted or controllified) and you get an
interactive query-replace without a special command for it. Yet you
also have much more general uses: you can get out and look around
without having to retype the command to resume. The command need not
be "replace", but could be "append", "delete", or many more general
cases. An EMACS user would probably write a macro to do this, which
limits this kind of usage to people who understand how to write
macros.
------------------------------
Date: 10 Dec 1981 1218-PST
From: LAWS at SRI-AI
Subject: Keyboard Layout
Tom Moran makes an interesting point about within-hand vs.
between-hand sequences. As it happens, most of the VI commands for
common operations are on the left hand. (E.g., move word, delete,
change, replace, substitute, delete character, find.) The
repeat-action keys are on the right. This may help explain why I
find it easier to type w..... to move six words than to type wwwwww
or 6w. (I have learned to vibrate the .... finger much faster than
I can similarly repeat an arbitrary character.)
-- Ken Laws
------------------------------
End of EDITOR-PEOPLE Digest
***************************
-------
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
