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 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.