Text File

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 <jgoerzen@complete.org> 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.