Aucb.870
fa.editor-p
utzoo!decvax!ucbvax!C70:editor-people
Fri Apr 9 11:32:46 1982
thoughts on a vi quiz
>From sdcsvax!draper@NPRDC Fri Apr 9 11:28:29 1982
Here are some comments on issues underlying Bill Mitchell's recent quiz on
vi - issues that are sort of obvious but perhaps would benefit from being
raised explicitly.
Bill's quiz was circulated on Usenet under the newsgroup net.games. It
consisted of 20 problems each of which described a textual change to be made
and asked for a solution in terms of vi commands. Your score was "the
number of keystrokes" meaning the number of transmitted characters, and you
were to aim for the lowest possible number. This note is in no way a
criticism of Bill: I enjoyed the quiz and learned something about vi from
the published answers. It is however intended to make you think about the
implications of such quizzes for serious purposes.
EFFICIENCY != NUMBER OF KEY-STROKES
The assumption behind the scoring of the quiz is that fewer key
strokes = more efficient. I propose that the real goal that users and
interface designers (i.e. the folks who decide on editor command languages)
should aim for is to minimize the time taken to make some changes to the
file from the moment this intention is first formed in the user's mind.
Counting keystrokes neglects the time taken to plan the command(s), and the
different difficulties in finding and typing various character sequences.
LEARNING IS INEFFICIENT IN THE SHORT RUN
Various points arise from this modified criterion. Clearly the
reason why many intermediate level users learn only a small subset of vi is
that at any given moment it is quicker for them to use a long way round to
their goal (in terms of keystrokes) rather than consult the manual.
However, Bill's attempt to teach them a wider set of commands is still
obviously reasonable: learning effort invested now will generally save lots
of time in the future in consistently shorter command sequences.
Nevertheless, even after complete learning of the command set some
apparently short solutions remain long in the time taken to compose them.
THE COST OF PLANNING TIME
The most obvious example is problem number 8 in Bill's quiz which
concerns a very long expression involving many parentheses:
text now: "((x*3)-(y-(1*2*3(((())))))x*(i+(j*k))*z)"
text desired: "((x*3)-x**z)"
solution: hd%e.
There is a very short solution involving commands that operate between
matching parentheses, but it must take the hottest expert a very long time
to count the parentheses and so determine how to use the "short" command.
In this particular case, I suspect that even deleting the unwanted
characters one by one would be a competitive solution and certainly
solutions that used unique salient characters as search targets would be
faster overall even though using more keystrokes.
This is simply an extreme illustration of the drawbacks to the attitude that
many users acquire and which is fostered by quizzes of this kind: that
clever solutions minimized with respect to key-strokes are best. In fact,
it goes against one of the main advantages of screen oriented editors - that
the user can move the cursor about without careful thought and rely on
feedback to tell her when the right target has been reached: this is in
contrast to line-oriented slow feedback editors where the user expends much
effort in composing unique search strings. The same point arises in
connection with question 10. Bill asked "delete characters 30 through 40 in
the current line" and marked down solutions which said "30|10x" because that
would only delete 30 through 39. In practice the user who immediately typed
"30|10x" and then an extra "x" when they saw the mistake would save time
over those who spent time trying to recall whether "30 through 40" meant 10
or 11 characters.
USE FEEDBACK TO SAVE PLANNING
The conclusion from these observations is that the user really needs
to learn effective strategies for achieving desired changes and that in
feedback-intensive editors like vi these should often involve the use of
feedback. None of Bill's questions address this goal directly - and it's
hard to see how they could - and a few seem definitely counterproductive
from this point of view. Even "delete the next five sentences" seems
dubious as a training exercise since it implies that users should sit
inactive for long periods counting sentences in order to be able to type
"d5)" rather than starting at once on "d)d)d)d)d)" or "d)...." and halting
when the desired effect is seen on the screen. The kind of skill that is
probably useful is knowing how to move the cursor to a target about two
thirds the way along a line (i.e. skills to substitute for the existing
skills a pointing device such as a mouse latches on to). The options
include a) design a search string (long planning) b) guess the number of
words and do "7www" i.e. jump there a word at a time using an estimate of
the distance to make a good initial "saccade" c) do the same thing in
characters e.g. "40|<SPACE><SPACE>...". Which is best? How should users
train themselves in dead reckoning on the number of words or characters to a
target? We know very little about the skills really useful in achieving
fast overall editing speeds but it is clear that they should try to minimize
thinking time as well as keystrokes and that they should exploit feedback
when this can save planning time.
KEY-PRESS TIMES. (WHAT FUNCTION MAPS NUMBER OF KEY-PRESSES INTO TIME TAKEN.)
My second point concerns how long it takes to press keys. A command
involving a shift key takes me much longer than a lower case letter command.
Experiments have shown that an uppercase letter takes even an expert typist
about twice as long as a lowercase one. I think Bill was much too generous
to EMACS in counting say "<CTRL>x" as two keystrokes - it takes me at least
three times as long (and probably more like five times) as typing "x".
However this is only true of a shift character embedded between normal ones.
A sequence of control characters only carries a penalty for finding the
control key the first time. Vi is also in trouble here since it uses
uppercase and control characters too. Number keys are medium slow for me
too - I have never learned to touch type them. Thus "5w" is probably as
slow as "wwwww" for me. (This clearly interacts with the question of what
strategies you should learn: it is obvious that "2w" is no advantage over
"ww", and "4w" saves two keystrokes but means you have to find two keys
instead of one and spend time counting instead of typing - where is the
break-even point?) Similarly commands that use characters whose position
varies between keyboards are unlikely to be worth learning, unless they are
used very frequently, because of the long search time entailed.
The conclusion from this then is that even ignoring thinking time, the most
efficient command sequence cannot be determined by counting characters
because the time each takes to type varies widely, and the time a sequence
takes depends on the combination of characters as well as their individual
types. Thus, for someone like me, who can touch type lowercase alphabetic
characters but nothing else, commands that are 3 characters each but all
lowercase are probably faster than ones which are single-character but of
mixed case and type; sequences that repeat a character are relatively fast,
and ones that alternate cases and intersperse rare punctuation and control
characters will be the slowest. This however is speculation - we really
need some empirical measurements. It may be that single character commands
reduce everyone to 1-finger typing at a 1 char/see except for repeated
characters and a few fixed sequences (e.g. "wq"). In that case minimsing
key-strokes would be a good measure.
CONCLUSION
The criterion for efficient editing, which should be invoked both in
comparing two editors and in training users to employ particular command
sequences should be the total time taken for going from the intention to the
accomplished change. The number of characters typed is a poor measure and
the time can be strongly affected by the difficulty of planning and by the
differential difficulties in typing particular characters (e.g. control
characters) and sequences of characters. The sort of experiment needed is
to time skilled users on tasks such as making corrections on a given file to
make it conform to a previously memorised version.
It should be possible to extend this kind of argument to both a
critique of particular command sets such as vi, and more strongly to the
kind of sequences worth learning and using in a given editor.
Steve Draper
UCSD, San Diego
ucbvax!sdcsvax!draper draper@nprdc
-----------------------------------------------------------------
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.
