- Email: [email protected]
Branching selection of suggestions
fnteracting with Computers vof 4 no I 1’19921 68-82
Branching selection of suggestions Joris Verrips
An on-screen editor has been developed that offers syntactically correct suggestions for words after the user has entered only the first letter. Branching selection operates on these suggestions to pick the correct word by using a specialized form of incremental matching. Part of the user interface; its evaluation; an essential part of its implementation; and an example of how the editor can be used are all offered by the paper. Keywords: human-computer incremental matching
interaction,
screen editor, interface,
Some users spend a lot of time typing commands and other types of text that consist of a relatively small number of different words. It might be useful if the machine could anticipate - once the first letter of the next word has been typed in - and make suggestions to the user who could then select one of the suggestions with only a few keystrokes. Examples of the sort of text that might be entered using branching selection of suggestions are programs in any available programming language, name tables and a list of references, but the technique could also apply to the selection of (edit-) functions using menus. One may wonder whether it is worthwhile saving keystrokes since most people spend little time typing predictable texts and do not need computers to read them. Many current applications support abbreviations for commands (e.g. ‘rep’ for ‘REPORT’) and frequently used commands are perhaps better placed in a menu structure. However, error-free suggestions might help users to concentrate on their real work, might speed it up and might stimulate the use of long and meaningful (variable) names. Different implementations of this idea exist, for instance a program called Mindreader,’ a programming environment for ABC’ (Geurts ef al., 1990), a language sensitive editor called Brief3 and the ‘electrical’ option in Emacs.* ‘Mindreader
is a product of Brown Bag Software Inc (New York) and is available as shareware.
2ABC is a language developed at CWI (Amsterdam) editor and interpreter.
and is available as freeware with an integrated
‘Brief is a product of Solution Systems (MA, USA). ‘Emacs is a product of the Open Software Foundation. Paramaribostraat 68
138”, 1058 VP Amsterdam,
The Netherlands.
~53-5~38/92/01~8-15
Tel: 31-20 - 6852275
@ 1992 Butterworth-Heinemann
Ltd
Comparable mechanisms are implemented in the Dutch railway timetable software ‘NS Reisplanner’ and in ‘Special search’ of Norton Utilities. Some of these products require users to type in abbreviations, others need a starting substring. A suggestion is accepted when a special character like TAB, SPACE, ; or \ , is entered or when the substring has reached a certain length.
Description of TYP TYP is a tool which resembles a normal screen editor and reads in a database of ‘virtual macros’ which are suggested to the users when they type in the first letter of the next word. It originated from the design for a Pascal editor which requires a minimal number of keystrokes. At a latter stage, automated formatting, simplified syntax, minimal mental effort, minimal memory effort and language independence were added to the design criteria. Once a letter has been typed in, up to three lists can appear on the screen: syntactically correct alternatives, syntactically correct but rare alternatives and, optionally, syntactically incorrect alternatives that also start with this letter. The second and following letters that are typed in enable the computer to ‘filter’ these lists. First, several predicates are applied to every word in the list. If a highly selective predicate produces an empty list, then a more liberal one is used to produce a short list of alternatives. Note that the filter processes the lists with predicates which are defined on the words in it. These predicates are: l
0 l
the next letter of the word is identical with the letter that has already been typed in. the word contains the upper case of the letter that has been typed in. the word contains the lower case of the letter that has been typed in.
To implement only the first predicate will not do for long lists of suggestions with comparable ‘starting substrings’. The second predicate can then help to select between words like ‘my_bicyclE’ with ‘me’ and ‘my_bicycle_seaT’ with ‘mt’. Note that Pascal is not case sensitive, the program can be made to add uppercase letters according to several styles, either in the database or in the text. The third predicate allows one to use selective letters: in a list with ‘repeat’, ‘readln’, ‘reaD’, ‘reset’ and ‘rewrite’ one can select these words with ‘rp’, ‘rn’, ‘rd’, ‘rs’ and ‘rw’ respectively. Generally speaking, consonants are selective. If only a single alternative is left in the first list or in the first and the second list and a new identifier-name is syntactically impossible, then this alternative is ‘automatically accepted’ and inserted in the text. A sound is given to signal this to the user. Thus, after the keystrokes ‘rp’ we will often hear a sound and see a screen with ‘repeat . . until’ around the cursor. Automatic acceptance is automatically turned off when a string of text like ‘Please give an integer:’ is entered. Every new word typed in is inserted into the suggestion lists. The process a user starts when he or she types a first letter may be described as branching selection (BS) or as filtered suggestions (FS) in contrast to direct Verrips
69
selection (DS) which is used when nonalphabetical characters or function keys are typed in. In DS the characters or strings that are coupled to the keystroke are directly inserted in the text. After each selection, be it BS or DS, a sound is given to signal that the user may start with the next word. This selection method seems better than the acceptance methods of other systems that I know of, but more difficult to implement and possibly harder to learn as well. Some examples
of abbreviations
The predicates will often filter the suggestion lists with remarkable ease. Consider the following list of identifiers and imagine that they would all be syntactically correct in a certain context. ‘Gerrits-Car-Tyre’, ‘Gerrits-Bicycle-Tyre’, Salary-Number’, ’ Gerrits-WindowingJJtility’.
‘Gerrits_Door_Knob’,
‘Gerrits-
It can easily be shown that ‘gc’, ‘gb’, ‘gd’, ‘gn’ and ‘gw’ will select these words and that some words can be selected with other ‘abbreviations’ as well. Sometimes, however, problems occur. For instance, abbreviations do not have fixed meanings between different texts or even within the same text. Consider the following text and imagine @ = the cursor. Program test1 ; Var counteR : Integer ; Begin @ End . The identifier ‘counteR’ can be automatically selected with any of the following abbreviations: ‘co’, ‘cu’, ‘cn’, ‘ct’, ‘cr’. ‘ce’ will not work if ‘Case . . Of . . End’ is also available. Now consider the next text. Program test2 ; Var counteR, counT : Integer ; Begin @ End . ‘counteR’ can only be automatically selected with ‘cr’ and ‘counT’ with ‘ct’. Other abbreviations will produce a list that contains both ‘counT’ and ‘counteR’. If one now decides to add another identifier with the name of ‘CoRT automatic acceptance becomes bothersome and will not be of any help. But one can still type in ‘CoRT’ as usual (actually ‘car’ will do as will ‘cut’ for ‘counT’ and ‘cre’ or ‘cur’ for ‘counteR’). I have typed many long programs with many different variable names and 70
Interacting
with
Computers
~014 no 2 (1992)
this situation has only happened occasionally. It is a problem because most users will not readily understand what is happening and it can then take much more time to find out how to use it in such special cases as well as the fact that automatic acceptance and branching selection can be toggled on or off at any moment. Design Design was difficult. I tried to use ‘top-down design’, but failed many times, and I have done significantly more then I set out to do. Moran (1981) describes 4 levels for the design of a user interface: 1. 2. 3. 4.
task level; semantic level; syntactic level (with two sublevels); keystroke level.
Moran has suggested that one should proceed from the first level to the fourth in that order. But that is not how it happened. I started with an interesting data structure that supported direct selection and formatting and ‘discovered’ and ‘tuned’ branching selection some time later. I have also tried to apply didactic principles. One might argue that I have tried to do it my way with a consequent waste of time and effort. A document that describes most of the design process is available directly from the author. Before evaluation I made a short study of the literature that resulted in two important design criteria - the system should: l l
be consistent and simple - so as to make it easy to learn; take few ‘operations’ to use it (operations are acts like looking at the screen, making a keystroke or thinking (a ‘mental operation’).
I concluded that using TYP should be faster than typing, even for experienced typists and that it would be usefui to study logfiies. The value of TYP and the like, if any, is to reduce the attention a busy and preoccupied user has to pay to typing in programs and to stimulate the use of long variable names. Time spent is not equivalent to attention, but it has the advantage that it can be measured. On the use of long variable names there is no consensus. Of course, studying Iogfiles cannot guarantee that many people will like using a program or that there will be a market for it. Motivation and individual differences are important factors during evaluation. It is therefore very difficult to make accurate predictions about its user-friendliness (and about its usefulness!) because programming itself already requires motivation as well as a lot of attention and learning. Evaluation TYP was not evaluated Verrips
in practical
situations
nor with different
classes of 71
programmers, but in an artificial setting and mostly by a single highly motivated and experienced user (myself). This was necessary to guide development within a tight budget and to get experience with the problems faced by users. Example programs from different tutorials on Pascal were typed in with a notepad at hand. Some programming exercises were performed without serious preparation at all. Also, users who were naive to the system were observed during and following a short introduction and were encouraged to talk about their experiences and asked to suggest improvements. Syntactic filtering of suggestions is one of the improvements based on feedback from users, as they seemed to expect ‘reasonable’ suggestions. In a later phase, benchmark tests were performed by typing in ten programs from books in order to compare TYP with ordinary screen editors. These tests showed how important cognitive ergonomics can be. Although the first version of TYP reduced the number of keystrokes by 50% it increased time spent by lOO%! It seemed useless to continue development or try to commercialize the product if even the system creator could not use it. I assumed it would not be very difficult to adapt the program and decided to understand and optimize my own performance first. By using simple models of human-machine interaction like a GOMS analysis (Card et al., 1983), and a multi-party grammar (Shneidermann, 1982), and extensive experiments with logfiles it could be shown that increased eye-screen contact, the calculation of effective ‘abbreviations’ and the need for a decision to accept suggestions were the factors that caused this time loss. These assumptions were confirmed by observations of more subjects who were ‘system naive’, and they were better understood through pseudocode of user processes (see Appendix 2). In order to simplify the process for the user, automatic acceptance was implemented with priority for uppercase and priorities between the three lists, and automated uppercase and syntax were added with the result that the program now gives a sound to signal to the user that he or she can start with the next word. Like about 20 other functions, sound is controlled by a toggle switch which can be set ‘off’ if required. Many minor problems had to be solved to understand and implement these functions, and for the syntax a ‘left-looking type grammar’ was specified which The time-stamped logfiles were can be generalized to other applications. processed to produce histograms of the pauses between keystrokes both within branching selection and outside of it. As more problems were recognized and the interface was adapted to get round them, results improved gradually. I found little need for statistically reliable information and I still wonder whether a thorough didactic and cognitive ergonomic analysis of frequently used interfaces requires a large number of test subjects. To me, it seemed more important to make precise models of user processes and to find arguments for the decisions one has to take, than to reach statistical certainty. Interindividual differences can complicate matters more than I would like, but I would 72
interacting
with Computers ~014 no 1 (1992)
Table 1. Comparison
Program
of performance
used
Number of branching selections BS expected type BS automatically accepted BS < 2 characters Corrections Stringlength Keystrokes Time (set) Characters / min
between Normal line editor 0 0 0 0 40 4700 4700 1831 156
normal line editor and TYP
TYP 372 369 (3 syntax ‘errors’) 346 12 23 5053 2131 1544 196
emphasise the importance of time measurement, because I assume that time measured often means attention spent. A controlled experiment was done to compare TYP to a normal screen editor. As TYP can simulate a simple screen editor the same logfiles could be made and compared. See Table 1 for results. Ten short texts were typed in. Five were entered using a simulated normal editor and the other five were entered using TYP. During the test, I took regular rests and did not examine the results until I had finished them all. The texts were taken from Findlay and Watt’s An introduction to methodical programming, translated as Oefenboek (1987). The texts chosen were: 4.6,4.7,6.9, 6.10, 6.11, 7.12, 7.13, 8.6, 8.7 and 8.8. Most words were selected by using only two letters. As the first letter is always the first letter of the next word it is clear that the predicates were very selective in these short programs typed in by an expert. The numbers of new identifiers in these programs were 7, 5, 8, 4, 4, 6, 5, 2, 4 and 3. The order of the versions used was: rest 5 min, TYP for text 1 to 5, rest 5 min, normal editor for text 6 to 10, rest 5 min, normal editor for text 1 to 5, rest 5 min, TYP for text 6 to 10. TYP generated more white space around brackets and assignments then the normal editor. To correct for this one may calculate 5053 / 1813 = 166 instead of 156 characters/min. The following conclusions can be drawn from Table 1: TYP is now faster than typing using an ordinary line editor, and probably requires less attention. Most selections are automatically accepted, and the syntax functions correctly. As this user types fast and accurately, the advantages of TYP may be underestimated. As this user is an expert TYP user, the learning effort may also be underestimated. I think that it is remarkable that for an experienced user who types fast and who trained regularly, the number of keystrokes per minute in TYP is not more than about 50% of the usual rate. It means that a user of TYP spends time on psychological operations that he or she does not perform when using an Verrips
73
ordinary editor. See Appendix 2 for a serial model of the user processes in branching selection. More experiments were performed to find out if the optimum has been reached. I have typed the same text many times and compared logfiles. Pauses between keystrokes of more then a second almost disappeared which I take to indicate that reading operations almost disappeared as well. But there are two groups of pauses that remain, the majority being pauses of about 350 msec and a minority being pauses of 500-900 msec, probably reflecting a decision about which ‘abbreviation’ to use, but that is hard to prove, equally possible are that the pauses allowed one to ‘forget’ words once the right one has been selected and the sound heard, some abbreviations seem to be ‘calculated’ at first and ‘remembered’ later. Therefore, no serious improvements of branching selection are likely. For this user, TYP will not become much faster. I would have liked to repeat these experiments and test learn-ability with a group of programmers, but I have not found enough volunteers for this to be possible. Discussion TYP seems an interesting alternative for language sensitive editors as a result of the cognitive ergonomic reasoning in its design, but, as yet, it has not been compared to these commercially available editors. Its most interesting property is that it effectively supports the selection of a few hundred names without any abbreviation whatsoever and thereby enables a lot of metacommunication through these (long) names. Some of this was shown in the experiments. Branching macro selection might be applied in many different contexts and compares well with direct manipulation techniques that use arrow keys or a mouse, a line editor and (a series of) menus as within databases’ SQL. Compare for instance the work of Shneidermann (1982), Beck and Elkerton (1989). I would like to quote Jakob Nielsen (1987): ‘Overloading functionality on command keys causes problems as more and more applications get mutualIy inconsistent in their command key usage. Some other
approach to accelerate expert performance is needed.’
When users have to choose from anything between 20 functions (the upper limit of easily remembered function keys) and a few hundred functions (where branching selection regularly needs three keystrokes), branching macroselection might offer such an approach. Acknowledgements I would never have been able to control and finish this project without the heIp and advice from Laurens Hoekstra and Cerrit van der Veer for which f am most grateful. 74
Inferactingwifh Compufers 0014 no 2 (19921
I would like to also acknowledge Bloemgarten, Dick Gtinen, Johan
Lutterkort, Mente naive volunteers.
Nauta,
Steven
the advice
Karreman, Pemberton,
from
Harry
Beulink,
Salvador
Paul Klint, Gert Jan Laan, Karl Frans Vink and many system
References D. and Elkerton, J (1989) ‘Development lists’ Sigcki Bulletin, 20, 3, 72-75
Beck,
Card S., Moran, T.P. Interaction Lawrence
and Newell, Erlbaum
A.
and evaluation
(1983)
The
of direct manipulation
Psyckology
of Humnn
Computer
Geurts, L., Meertens, L. and Pemberton, S. (1985) The ABC Editor CWI publicaties Amsterdam. (A book on ABC (old name: B) is published by Prentice Hall Inc. 1990) Kay, A (1990) ‘User Computer Interface
interface: a personal view’ in Laurel, Des& Addison Wesley, 191
Moran, T.P. (1981) ‘The Command interface of interactive computer
B (ed) The Art of Human
Language Grammar: a representation for the user systems’ Int. 1. Mnn-Mack. Studies, 15, 3-50
Nielsen, J. (1987) ‘A user interface study of the Macintosh’ in Salvendy, G. (ed) Cognitive Engineering in the Desigrl of Human Computer Interaction and Expert Systems Elsevier Science, 244-248 Shneiderman, B. (1982) ‘Multiparty Grammars and related features for defining tive systems’ IEEE Trans. Systems Man and Cybernetics SMC 12, 2, 148-155
interac-
Shneiderman, B. (1987) ‘User interface design and evaluation for an electronic encyclopedia’ In: Salvendy G. (ed) Cognitive Engineering in tke Design of Human Computer interaction and Expert Systems Elsevier Science, 207
Appendix 1: A left looking type grammar The purpose of TYP’s grammar is to define a predicate on words in the database that decides whether they are syntactically possible or not. This has to be achieved without a complete parse because there is no guarantee that a parse is possible, as there are no constraints on the text that has been typed in (or read in from disk). Each word receives a left-type and a right-type from the following list: S I W N D T B E
Statement Identifier Value Operator Decpart Type-identifier Special Empty
Most words have identical left- and right-types. The program looks to the right-type of the word that lies on the left of the cursor to decide on the possible left-types of the next word to be selected. It can usually find in Table 2 a set of acceptable left-types (1) on the row, although Verrips
75
Table 2. A left-right
syntax table
left-type of the candidates in the suggestion I W N D S righttype of word to the left of the cursor
S I w N D T B E
1 0 0 0 o* 0 1* 0
1 0 0 1 1 0 1* 0
0 0 0 1 0 0 1* 0
0 1 1 0 0 0 o* 0
0 0 0 0 0 0 1* 0
lists T
B
0 0 0 0 0 1 1’ 0
0 1 1 0 0 1 1* 0
E 0 0 0 0 0 0 0 0
Note that I and W have identical rows but different colums in Table 2. There are more types than W = Value in real Pascal, “example: = maxint + ‘maxint”’ ; would seem completely acceptable to this grammar but gives rise to a type conflict on compilation. See Figure 1 for some example keywords with their types (left-type, right-type).
sometimes a more complicated predicate is used (*) and the program may have to look farther to the left and determine whether the cursor is within a ‘Begin . . End’ section. Using this set of left-types the program may then decide which words appear in which suggestion lists. The ‘1’ in row 1, column 1 (1,l) of Table 2 means that a statement can be followed by a statement (e.g. ‘Begin’ can follow ‘Begin’) and the 0 in (1,3) that a statement is not usually followed by a value (e.g. one does not expect ‘Begin maxint’). As non-alphabetical words are never suggested the column with B might as well have been empty. Most syntactical ‘mistakes’ just will not occur e.g. the suggestion that ‘;’ lies to the right of ‘Set of’ as one will not type in ‘;’ but ‘i’, to get ‘Set of Integer’ which I judge ‘almost correct’. Likewise, a word like ‘do’
Begin
(S,S)
Repeat (S,S)
.. ..
If (S,N)
While (S,N) For (S,N)
:: ..
End (S,S) Until (S,N) Then (S,S) Do WY To (S,N) . . Do (S,S)
+ (N,N)
Label (D,D)
- (N,N) * (N,N) DIV (N,N) AND (N,N) OR (N,N) : = (N,N)
Type (D,D) Const (D,D) Var (DID) Procedure (DID)
Function (D,D)
Sin ( (W,N) . .) (W,W) Cos ( WJ’J) . -1 W’,W ( (W,N) . .I W,W) NOT (W,N) Maxint (W,N) Integer (T,E) Real (T,E) Set of (T,T)
Array [ (TN . .I OF (T,T) ; I;;;; , (B,B) = (W)
Figure 1. Example 76
keywords
and their types Interacting
with Computers
~014 no 1 (1992)
never has to be suggested to the right of an expression as in: “for count: = 1 to 100 div 4 do” because ‘do’ is already selected with ‘for’: (3,l) can be 0. Although it looks simple, some of the details are complicated, like, for instance, the dangling ‘Else’ and automated type assignment. Those details are language-specific and may include formatting. In C, the program uses the rule that type identifiers should be on the same line as variables (e.g. int count, number ;). As a consequence, results are not as good as for Pascal. This grammar has not been compared with ASTs and other ways of implementing syntax. In the implementation, IE and DE have special meanings.
Appendix 2: User processes: a grammar Marshall McLuhan has been quoted as follows: ‘I am not sure who discovered water but it wasn’t a fish’ (Kay 1990). A study of user processes shows that users clearly and often vividly describe what they experience, but that it takes much work to understand it formally. On a very global level one may describe the user’s process as follows: Read a line
XOR Think of a new line From left to right: Type first letter of next word Type a following letter Make sure the correct word is accepted XOR Select by function key or otherwise
Compare
this with
the ‘pseudo-code’
Read a line XOR From left to right Type next word
of a user in a normal text editor:
Think of a new line
I think these grammars show why it is a good idea to have the program emit a sound each time a word is accepted. The result is that users need not look at the
screen to make sure the correct word has been accepted. Logfiles and the literature (especially Card et al., 1983) show that this can take the user some time. But these same logfiles show that we need to understand things on a more detailed level. Some typical user processes are: I II III IV V VI VII VIII IX Verrips
Read paper (mostly one line) Gaze at screen / think Read screen (verification) Type first letter Type second letter Think of first letter Think of second letter Do nothing Remember next word (from line read) 77
There can be more structure to it: for example, experienced users read their paper only when they have already made their selection (perhaps short term memory is ‘emptied‘?) and usually look at the screen to verify selection. This means that they need not look at the screen nor at their paper while deciding on the letters to type in (and where to find them on their keypad). beginners, however, will look at the screen each time there is something new to see, and will sometimes select items with the grammar: read-word then type-first-letter then read-screen then type-appropriate-function-key. Of course, many individual differences can be found and measured. One may assume that users do only one thing at the time, although this cannot be proved. It took a lot of observation and many logfiles to find the following grammar for some experienced users: Type-One-Line == I (VI. (IV. vI1.v - VII. IV. V). (III i- VIII).IX) * where + = ‘or’ . = ‘followed by’ and ( ) * means repeat ( ) any number of times. This grammar predicts that pauses between keystrokes are longer outside branching selection than within it because of the verification operation (III). This can also be noticed when the text is typed over many times and reading operations and most verification operations diappear. These predictions were confirmed by an experiment using the author as the test subject. One can try to understand histograms of pauses as measured with Iogfiles in terms of operations: III. IX. VI. IV would take longer then IV. VII. V although as much individual variation is expected in the operations as in the (speculative !) grammars. In my view, grammars and pseudo-code are very important for design and understanding, but should not be taken too seriously in a psychological sense. They do not describe ‘psychological reality’.
Appendix 3: an example The best and quickest way to understand TYP is to work with it for a while. The prototype PTYP can be found on bulletin boards, and on line help is available. An example is provided here. The text to the left can be typed in with the keystrokes shown on its right. ! means a bell from the machine. For this example, TYP’s most recent version (2.0) was used, in PTYP one must first set toggles with EscS129.
78
lnteructing with Computers a01 4 no t (2992)
Text
Keystrokes
Program tabIe_of_squares ; var index : integer ; begin writeln ; for index : = 1 to 10 do writein (index, index * index : 20) ; writeln end .
tabie-otsquares; vrindex:ig; I% zi% = 1TABlOTAB wn (ix, i’i : 20; wn
To do this, the user may need information on the screen to help select the correct words and to learn to understand TYP. The screens that such a user would see are shown in the following. @ gives the cursor position. Under each screen image the keystrokes are given between “. . .f’ and some comments are given.
Program @ Keystrokes Comment
: None : Screen after loading @ = cursor.
of the database,
Program table-o@ Keystrokes
: “table_ot”
Program table-of-squares c Keystrokes Comment
f
: “squares!” : After the space, a bell sounds (as shown by the exclamation mark) to signal that a word has been selected and that branching selection has been left. This sound is not a keystroke, but was generated by the program.
Program table_oLsquares 43
Keystrokes Comment
Verrips
@
; TAB=>FKlvar
: “;!#I : We see a list of suggestions, select ‘var’.
either TAB, arrow right or FK 1 will
79
;
Program table-of-squares var i@
No suggestions Keystrokes
Comment
: “r!i” : After
vr only var was syntactically correct and was therefore accepted. There are no suggestions listed for “i” and this fact is communicated by the message given by the program.
Program table-of-squares var in@
;
No suggestions
Keystrokes
available.
: “n”
;
Program table_of_squares var index : @
Keystrokes Comment
available.
: “dex:!!” : the colon causes
a double bell. The non-alphabetical “:“, forces an end to BS and then acceptance of “:“.
Program table-of-squares index : i@
character,
;
var
TAB, => FK 1 integer Keystrokes
;
Program table-of-squares var index : integer ; b@
TAB, => FK 1 begin.
Keystrokes
80
. end
: “g!;!b”
Program table-of-squares var index : integer ; begin w@ FK end . FK FK FK TAB, =>
Keystrokes
‘
: “i”
;
1 2 3 4
with . . do while . . do write (. .) writeln
: “g!w”
Interacting
with Computers
~014 no 2 (1992)
Program table_of_squares ; index : integer ; var begin writeln ; f@ I
end.
Keystrokes
TAB, => FK 1 for.
: “n!;!f”
Program table_oLsquares ; index : integer ; var begin writeln ; for i@ FK 1 input end . TAB, => FK 2 index Keystrokes Comment
to do
: “r!i” : ’ to’ and ‘do’ are displayed far to the right of the cursor. The grammar is not faultless, as is shown by ‘input’. ‘index’ is suggested because it is the most recently used identifier.
Program table-of-squares var index : integer ; begin writeln ; for index := 1 to 10 do w@ FK 1 end . FK 2 FK 3 TAB, => FK 4 Ikeystrokes Comment
to. . do
;
with . . do while . . do write (. .) writeln
! !w” : “x!:!=!l!TAB!l!O!TAB! : Two TABS move the cursor around ‘to’ and ‘do‘. The two spaces shift “w“ a bit more to the right than ‘for’.
Program table_oLsquares ; index : integer ; var begin writeln ; for index := 1 to 10 do writeln (i@ ) FK 1 input end . TAB, => FK 2 index Keystrokes Comment
: “n!(!i” : The closing bracket sion with the cursor.
“)” is displayed
to the right to avoid confu-
Program table-of-squares index : integer ; var
;
begin writeln ; for index := 1 to 10 do writeln (index, index + index : @) end . Keystrokes Comment
: “x!,!i*!!i:!!” : !! means two bell sounds.
The non alphanumeric characters ‘*‘ and ‘:’ were given inside BS and forced acceptance of the suggestion which was then selected.
Program tabIe_of_squares ; index : integer ; begin writeIn ; for index := 1 to 10 do writeln (index, index * index : 20 ) ; writeln @ end .
var
Keystrokes Comment
: “2!0!;!wn!” : Note that “;” jumped
beyond the closing now save the text and compile it.
bracket
“)“. One can
Please note that this hypothetical user only used the programs’ third predicate and that it is hard to imagine how the number of keystrokes could be further diminished.
82
lnferucting wifh Computers voI I no 1 (299.7)
Branching selection of suggestions Joris Verrips
An on-screen editor has been developed that offers syntactically correct suggestions for words after the user has entered only the first letter. Branching selection operates on these suggestions to pick the correct word by using a specialized form of incremental matching. Part of the user interface; its evaluation; an essential part of its implementation; and an example of how the editor can be used are all offered by the paper. Keywords: human-computer incremental matching
interaction,
screen editor, interface,
Some users spend a lot of time typing commands and other types of text that consist of a relatively small number of different words. It might be useful if the machine could anticipate - once the first letter of the next word has been typed in - and make suggestions to the user who could then select one of the suggestions with only a few keystrokes. Examples of the sort of text that might be entered using branching selection of suggestions are programs in any available programming language, name tables and a list of references, but the technique could also apply to the selection of (edit-) functions using menus. One may wonder whether it is worthwhile saving keystrokes since most people spend little time typing predictable texts and do not need computers to read them. Many current applications support abbreviations for commands (e.g. ‘rep’ for ‘REPORT’) and frequently used commands are perhaps better placed in a menu structure. However, error-free suggestions might help users to concentrate on their real work, might speed it up and might stimulate the use of long and meaningful (variable) names. Different implementations of this idea exist, for instance a program called Mindreader,’ a programming environment for ABC’ (Geurts ef al., 1990), a language sensitive editor called Brief3 and the ‘electrical’ option in Emacs.* ‘Mindreader
is a product of Brown Bag Software Inc (New York) and is available as shareware.
2ABC is a language developed at CWI (Amsterdam) editor and interpreter.
and is available as freeware with an integrated
‘Brief is a product of Solution Systems (MA, USA). ‘Emacs is a product of the Open Software Foundation. Paramaribostraat 68
138”, 1058 VP Amsterdam,
The Netherlands.
~53-5~38/92/01~8-15
Tel: 31-20 - 6852275
@ 1992 Butterworth-Heinemann
Ltd
Comparable mechanisms are implemented in the Dutch railway timetable software ‘NS Reisplanner’ and in ‘Special search’ of Norton Utilities. Some of these products require users to type in abbreviations, others need a starting substring. A suggestion is accepted when a special character like TAB, SPACE, ; or \ , is entered or when the substring has reached a certain length.
Description of TYP TYP is a tool which resembles a normal screen editor and reads in a database of ‘virtual macros’ which are suggested to the users when they type in the first letter of the next word. It originated from the design for a Pascal editor which requires a minimal number of keystrokes. At a latter stage, automated formatting, simplified syntax, minimal mental effort, minimal memory effort and language independence were added to the design criteria. Once a letter has been typed in, up to three lists can appear on the screen: syntactically correct alternatives, syntactically correct but rare alternatives and, optionally, syntactically incorrect alternatives that also start with this letter. The second and following letters that are typed in enable the computer to ‘filter’ these lists. First, several predicates are applied to every word in the list. If a highly selective predicate produces an empty list, then a more liberal one is used to produce a short list of alternatives. Note that the filter processes the lists with predicates which are defined on the words in it. These predicates are: l
0 l
the next letter of the word is identical with the letter that has already been typed in. the word contains the upper case of the letter that has been typed in. the word contains the lower case of the letter that has been typed in.
To implement only the first predicate will not do for long lists of suggestions with comparable ‘starting substrings’. The second predicate can then help to select between words like ‘my_bicyclE’ with ‘me’ and ‘my_bicycle_seaT’ with ‘mt’. Note that Pascal is not case sensitive, the program can be made to add uppercase letters according to several styles, either in the database or in the text. The third predicate allows one to use selective letters: in a list with ‘repeat’, ‘readln’, ‘reaD’, ‘reset’ and ‘rewrite’ one can select these words with ‘rp’, ‘rn’, ‘rd’, ‘rs’ and ‘rw’ respectively. Generally speaking, consonants are selective. If only a single alternative is left in the first list or in the first and the second list and a new identifier-name is syntactically impossible, then this alternative is ‘automatically accepted’ and inserted in the text. A sound is given to signal this to the user. Thus, after the keystrokes ‘rp’ we will often hear a sound and see a screen with ‘repeat . . until’ around the cursor. Automatic acceptance is automatically turned off when a string of text like ‘Please give an integer:’ is entered. Every new word typed in is inserted into the suggestion lists. The process a user starts when he or she types a first letter may be described as branching selection (BS) or as filtered suggestions (FS) in contrast to direct Verrips
69
selection (DS) which is used when nonalphabetical characters or function keys are typed in. In DS the characters or strings that are coupled to the keystroke are directly inserted in the text. After each selection, be it BS or DS, a sound is given to signal that the user may start with the next word. This selection method seems better than the acceptance methods of other systems that I know of, but more difficult to implement and possibly harder to learn as well. Some examples
of abbreviations
The predicates will often filter the suggestion lists with remarkable ease. Consider the following list of identifiers and imagine that they would all be syntactically correct in a certain context. ‘Gerrits-Car-Tyre’, ‘Gerrits-Bicycle-Tyre’, Salary-Number’, ’ Gerrits-WindowingJJtility’.
‘Gerrits_Door_Knob’,
‘Gerrits-
It can easily be shown that ‘gc’, ‘gb’, ‘gd’, ‘gn’ and ‘gw’ will select these words and that some words can be selected with other ‘abbreviations’ as well. Sometimes, however, problems occur. For instance, abbreviations do not have fixed meanings between different texts or even within the same text. Consider the following text and imagine @ = the cursor. Program test1 ; Var counteR : Integer ; Begin @ End . The identifier ‘counteR’ can be automatically selected with any of the following abbreviations: ‘co’, ‘cu’, ‘cn’, ‘ct’, ‘cr’. ‘ce’ will not work if ‘Case . . Of . . End’ is also available. Now consider the next text. Program test2 ; Var counteR, counT : Integer ; Begin @ End . ‘counteR’ can only be automatically selected with ‘cr’ and ‘counT’ with ‘ct’. Other abbreviations will produce a list that contains both ‘counT’ and ‘counteR’. If one now decides to add another identifier with the name of ‘CoRT automatic acceptance becomes bothersome and will not be of any help. But one can still type in ‘CoRT’ as usual (actually ‘car’ will do as will ‘cut’ for ‘counT’ and ‘cre’ or ‘cur’ for ‘counteR’). I have typed many long programs with many different variable names and 70
Interacting
with
Computers
~014 no 2 (1992)
this situation has only happened occasionally. It is a problem because most users will not readily understand what is happening and it can then take much more time to find out how to use it in such special cases as well as the fact that automatic acceptance and branching selection can be toggled on or off at any moment. Design Design was difficult. I tried to use ‘top-down design’, but failed many times, and I have done significantly more then I set out to do. Moran (1981) describes 4 levels for the design of a user interface: 1. 2. 3. 4.
task level; semantic level; syntactic level (with two sublevels); keystroke level.
Moran has suggested that one should proceed from the first level to the fourth in that order. But that is not how it happened. I started with an interesting data structure that supported direct selection and formatting and ‘discovered’ and ‘tuned’ branching selection some time later. I have also tried to apply didactic principles. One might argue that I have tried to do it my way with a consequent waste of time and effort. A document that describes most of the design process is available directly from the author. Before evaluation I made a short study of the literature that resulted in two important design criteria - the system should: l l
be consistent and simple - so as to make it easy to learn; take few ‘operations’ to use it (operations are acts like looking at the screen, making a keystroke or thinking (a ‘mental operation’).
I concluded that using TYP should be faster than typing, even for experienced typists and that it would be usefui to study logfiies. The value of TYP and the like, if any, is to reduce the attention a busy and preoccupied user has to pay to typing in programs and to stimulate the use of long variable names. Time spent is not equivalent to attention, but it has the advantage that it can be measured. On the use of long variable names there is no consensus. Of course, studying Iogfiles cannot guarantee that many people will like using a program or that there will be a market for it. Motivation and individual differences are important factors during evaluation. It is therefore very difficult to make accurate predictions about its user-friendliness (and about its usefulness!) because programming itself already requires motivation as well as a lot of attention and learning. Evaluation TYP was not evaluated Verrips
in practical
situations
nor with different
classes of 71
programmers, but in an artificial setting and mostly by a single highly motivated and experienced user (myself). This was necessary to guide development within a tight budget and to get experience with the problems faced by users. Example programs from different tutorials on Pascal were typed in with a notepad at hand. Some programming exercises were performed without serious preparation at all. Also, users who were naive to the system were observed during and following a short introduction and were encouraged to talk about their experiences and asked to suggest improvements. Syntactic filtering of suggestions is one of the improvements based on feedback from users, as they seemed to expect ‘reasonable’ suggestions. In a later phase, benchmark tests were performed by typing in ten programs from books in order to compare TYP with ordinary screen editors. These tests showed how important cognitive ergonomics can be. Although the first version of TYP reduced the number of keystrokes by 50% it increased time spent by lOO%! It seemed useless to continue development or try to commercialize the product if even the system creator could not use it. I assumed it would not be very difficult to adapt the program and decided to understand and optimize my own performance first. By using simple models of human-machine interaction like a GOMS analysis (Card et al., 1983), and a multi-party grammar (Shneidermann, 1982), and extensive experiments with logfiles it could be shown that increased eye-screen contact, the calculation of effective ‘abbreviations’ and the need for a decision to accept suggestions were the factors that caused this time loss. These assumptions were confirmed by observations of more subjects who were ‘system naive’, and they were better understood through pseudocode of user processes (see Appendix 2). In order to simplify the process for the user, automatic acceptance was implemented with priority for uppercase and priorities between the three lists, and automated uppercase and syntax were added with the result that the program now gives a sound to signal to the user that he or she can start with the next word. Like about 20 other functions, sound is controlled by a toggle switch which can be set ‘off’ if required. Many minor problems had to be solved to understand and implement these functions, and for the syntax a ‘left-looking type grammar’ was specified which The time-stamped logfiles were can be generalized to other applications. processed to produce histograms of the pauses between keystrokes both within branching selection and outside of it. As more problems were recognized and the interface was adapted to get round them, results improved gradually. I found little need for statistically reliable information and I still wonder whether a thorough didactic and cognitive ergonomic analysis of frequently used interfaces requires a large number of test subjects. To me, it seemed more important to make precise models of user processes and to find arguments for the decisions one has to take, than to reach statistical certainty. Interindividual differences can complicate matters more than I would like, but I would 72
interacting
with Computers ~014 no 1 (1992)
Table 1. Comparison
Program
of performance
used
Number of branching selections BS expected type BS automatically accepted BS < 2 characters Corrections Stringlength Keystrokes Time (set) Characters / min
between Normal line editor 0 0 0 0 40 4700 4700 1831 156
normal line editor and TYP
TYP 372 369 (3 syntax ‘errors’) 346 12 23 5053 2131 1544 196
emphasise the importance of time measurement, because I assume that time measured often means attention spent. A controlled experiment was done to compare TYP to a normal screen editor. As TYP can simulate a simple screen editor the same logfiles could be made and compared. See Table 1 for results. Ten short texts were typed in. Five were entered using a simulated normal editor and the other five were entered using TYP. During the test, I took regular rests and did not examine the results until I had finished them all. The texts were taken from Findlay and Watt’s An introduction to methodical programming, translated as Oefenboek (1987). The texts chosen were: 4.6,4.7,6.9, 6.10, 6.11, 7.12, 7.13, 8.6, 8.7 and 8.8. Most words were selected by using only two letters. As the first letter is always the first letter of the next word it is clear that the predicates were very selective in these short programs typed in by an expert. The numbers of new identifiers in these programs were 7, 5, 8, 4, 4, 6, 5, 2, 4 and 3. The order of the versions used was: rest 5 min, TYP for text 1 to 5, rest 5 min, normal editor for text 6 to 10, rest 5 min, normal editor for text 1 to 5, rest 5 min, TYP for text 6 to 10. TYP generated more white space around brackets and assignments then the normal editor. To correct for this one may calculate 5053 / 1813 = 166 instead of 156 characters/min. The following conclusions can be drawn from Table 1: TYP is now faster than typing using an ordinary line editor, and probably requires less attention. Most selections are automatically accepted, and the syntax functions correctly. As this user types fast and accurately, the advantages of TYP may be underestimated. As this user is an expert TYP user, the learning effort may also be underestimated. I think that it is remarkable that for an experienced user who types fast and who trained regularly, the number of keystrokes per minute in TYP is not more than about 50% of the usual rate. It means that a user of TYP spends time on psychological operations that he or she does not perform when using an Verrips
73
ordinary editor. See Appendix 2 for a serial model of the user processes in branching selection. More experiments were performed to find out if the optimum has been reached. I have typed the same text many times and compared logfiles. Pauses between keystrokes of more then a second almost disappeared which I take to indicate that reading operations almost disappeared as well. But there are two groups of pauses that remain, the majority being pauses of about 350 msec and a minority being pauses of 500-900 msec, probably reflecting a decision about which ‘abbreviation’ to use, but that is hard to prove, equally possible are that the pauses allowed one to ‘forget’ words once the right one has been selected and the sound heard, some abbreviations seem to be ‘calculated’ at first and ‘remembered’ later. Therefore, no serious improvements of branching selection are likely. For this user, TYP will not become much faster. I would have liked to repeat these experiments and test learn-ability with a group of programmers, but I have not found enough volunteers for this to be possible. Discussion TYP seems an interesting alternative for language sensitive editors as a result of the cognitive ergonomic reasoning in its design, but, as yet, it has not been compared to these commercially available editors. Its most interesting property is that it effectively supports the selection of a few hundred names without any abbreviation whatsoever and thereby enables a lot of metacommunication through these (long) names. Some of this was shown in the experiments. Branching macro selection might be applied in many different contexts and compares well with direct manipulation techniques that use arrow keys or a mouse, a line editor and (a series of) menus as within databases’ SQL. Compare for instance the work of Shneidermann (1982), Beck and Elkerton (1989). I would like to quote Jakob Nielsen (1987): ‘Overloading functionality on command keys causes problems as more and more applications get mutualIy inconsistent in their command key usage. Some other
approach to accelerate expert performance is needed.’
When users have to choose from anything between 20 functions (the upper limit of easily remembered function keys) and a few hundred functions (where branching selection regularly needs three keystrokes), branching macroselection might offer such an approach. Acknowledgements I would never have been able to control and finish this project without the heIp and advice from Laurens Hoekstra and Cerrit van der Veer for which f am most grateful. 74
Inferactingwifh Compufers 0014 no 2 (19921
I would like to also acknowledge Bloemgarten, Dick Gtinen, Johan
Lutterkort, Mente naive volunteers.
Nauta,
Steven
the advice
Karreman, Pemberton,
from
Harry
Beulink,
Salvador
Paul Klint, Gert Jan Laan, Karl Frans Vink and many system
References D. and Elkerton, J (1989) ‘Development lists’ Sigcki Bulletin, 20, 3, 72-75
Beck,
Card S., Moran, T.P. Interaction Lawrence
and Newell, Erlbaum
A.
and evaluation
(1983)
The
of direct manipulation
Psyckology
of Humnn
Computer
Geurts, L., Meertens, L. and Pemberton, S. (1985) The ABC Editor CWI publicaties Amsterdam. (A book on ABC (old name: B) is published by Prentice Hall Inc. 1990) Kay, A (1990) ‘User Computer Interface
interface: a personal view’ in Laurel, Des& Addison Wesley, 191
Moran, T.P. (1981) ‘The Command interface of interactive computer
B (ed) The Art of Human
Language Grammar: a representation for the user systems’ Int. 1. Mnn-Mack. Studies, 15, 3-50
Nielsen, J. (1987) ‘A user interface study of the Macintosh’ in Salvendy, G. (ed) Cognitive Engineering in the Desigrl of Human Computer Interaction and Expert Systems Elsevier Science, 244-248 Shneiderman, B. (1982) ‘Multiparty Grammars and related features for defining tive systems’ IEEE Trans. Systems Man and Cybernetics SMC 12, 2, 148-155
interac-
Shneiderman, B. (1987) ‘User interface design and evaluation for an electronic encyclopedia’ In: Salvendy G. (ed) Cognitive Engineering in tke Design of Human Computer interaction and Expert Systems Elsevier Science, 207
Appendix 1: A left looking type grammar The purpose of TYP’s grammar is to define a predicate on words in the database that decides whether they are syntactically possible or not. This has to be achieved without a complete parse because there is no guarantee that a parse is possible, as there are no constraints on the text that has been typed in (or read in from disk). Each word receives a left-type and a right-type from the following list: S I W N D T B E
Statement Identifier Value Operator Decpart Type-identifier Special Empty
Most words have identical left- and right-types. The program looks to the right-type of the word that lies on the left of the cursor to decide on the possible left-types of the next word to be selected. It can usually find in Table 2 a set of acceptable left-types (1) on the row, although Verrips
75
Table 2. A left-right
syntax table
left-type of the candidates in the suggestion I W N D S righttype of word to the left of the cursor
S I w N D T B E
1 0 0 0 o* 0 1* 0
1 0 0 1 1 0 1* 0
0 0 0 1 0 0 1* 0
0 1 1 0 0 0 o* 0
0 0 0 0 0 0 1* 0
lists T
B
0 0 0 0 0 1 1’ 0
0 1 1 0 0 1 1* 0
E 0 0 0 0 0 0 0 0
Note that I and W have identical rows but different colums in Table 2. There are more types than W = Value in real Pascal, “example: = maxint + ‘maxint”’ ; would seem completely acceptable to this grammar but gives rise to a type conflict on compilation. See Figure 1 for some example keywords with their types (left-type, right-type).
sometimes a more complicated predicate is used (*) and the program may have to look farther to the left and determine whether the cursor is within a ‘Begin . . End’ section. Using this set of left-types the program may then decide which words appear in which suggestion lists. The ‘1’ in row 1, column 1 (1,l) of Table 2 means that a statement can be followed by a statement (e.g. ‘Begin’ can follow ‘Begin’) and the 0 in (1,3) that a statement is not usually followed by a value (e.g. one does not expect ‘Begin maxint’). As non-alphabetical words are never suggested the column with B might as well have been empty. Most syntactical ‘mistakes’ just will not occur e.g. the suggestion that ‘;’ lies to the right of ‘Set of’ as one will not type in ‘;’ but ‘i’, to get ‘Set of Integer’ which I judge ‘almost correct’. Likewise, a word like ‘do’
Begin
(S,S)
Repeat (S,S)
.. ..
If (S,N)
While (S,N) For (S,N)
:: ..
End (S,S) Until (S,N) Then (S,S) Do WY To (S,N) . . Do (S,S)
+ (N,N)
Label (D,D)
- (N,N) * (N,N) DIV (N,N) AND (N,N) OR (N,N) : = (N,N)
Type (D,D) Const (D,D) Var (DID) Procedure (DID)
Function (D,D)
Sin ( (W,N) . .) (W,W) Cos ( WJ’J) . -1 W’,W ( (W,N) . .I W,W) NOT (W,N) Maxint (W,N) Integer (T,E) Real (T,E) Set of (T,T)
Array [ (TN . .I OF (T,T) ; I;;;; , (B,B) = (W)
Figure 1. Example 76
keywords
and their types Interacting
with Computers
~014 no 1 (1992)
never has to be suggested to the right of an expression as in: “for count: = 1 to 100 div 4 do” because ‘do’ is already selected with ‘for’: (3,l) can be 0. Although it looks simple, some of the details are complicated, like, for instance, the dangling ‘Else’ and automated type assignment. Those details are language-specific and may include formatting. In C, the program uses the rule that type identifiers should be on the same line as variables (e.g. int count, number ;). As a consequence, results are not as good as for Pascal. This grammar has not been compared with ASTs and other ways of implementing syntax. In the implementation, IE and DE have special meanings.
Appendix 2: User processes: a grammar Marshall McLuhan has been quoted as follows: ‘I am not sure who discovered water but it wasn’t a fish’ (Kay 1990). A study of user processes shows that users clearly and often vividly describe what they experience, but that it takes much work to understand it formally. On a very global level one may describe the user’s process as follows: Read a line
XOR Think of a new line From left to right: Type first letter of next word Type a following letter Make sure the correct word is accepted XOR Select by function key or otherwise
Compare
this with
the ‘pseudo-code’
Read a line XOR From left to right Type next word
of a user in a normal text editor:
Think of a new line
I think these grammars show why it is a good idea to have the program emit a sound each time a word is accepted. The result is that users need not look at the
screen to make sure the correct word has been accepted. Logfiles and the literature (especially Card et al., 1983) show that this can take the user some time. But these same logfiles show that we need to understand things on a more detailed level. Some typical user processes are: I II III IV V VI VII VIII IX Verrips
Read paper (mostly one line) Gaze at screen / think Read screen (verification) Type first letter Type second letter Think of first letter Think of second letter Do nothing Remember next word (from line read) 77
There can be more structure to it: for example, experienced users read their paper only when they have already made their selection (perhaps short term memory is ‘emptied‘?) and usually look at the screen to verify selection. This means that they need not look at the screen nor at their paper while deciding on the letters to type in (and where to find them on their keypad). beginners, however, will look at the screen each time there is something new to see, and will sometimes select items with the grammar: read-word then type-first-letter then read-screen then type-appropriate-function-key. Of course, many individual differences can be found and measured. One may assume that users do only one thing at the time, although this cannot be proved. It took a lot of observation and many logfiles to find the following grammar for some experienced users: Type-One-Line == I (VI. (IV. vI1.v - VII. IV. V). (III i- VIII).IX) * where + = ‘or’ . = ‘followed by’ and ( ) * means repeat ( ) any number of times. This grammar predicts that pauses between keystrokes are longer outside branching selection than within it because of the verification operation (III). This can also be noticed when the text is typed over many times and reading operations and most verification operations diappear. These predictions were confirmed by an experiment using the author as the test subject. One can try to understand histograms of pauses as measured with Iogfiles in terms of operations: III. IX. VI. IV would take longer then IV. VII. V although as much individual variation is expected in the operations as in the (speculative !) grammars. In my view, grammars and pseudo-code are very important for design and understanding, but should not be taken too seriously in a psychological sense. They do not describe ‘psychological reality’.
Appendix 3: an example The best and quickest way to understand TYP is to work with it for a while. The prototype PTYP can be found on bulletin boards, and on line help is available. An example is provided here. The text to the left can be typed in with the keystrokes shown on its right. ! means a bell from the machine. For this example, TYP’s most recent version (2.0) was used, in PTYP one must first set toggles with EscS129.
78
lnteructing with Computers a01 4 no t (2992)
Text
Keystrokes
Program tabIe_of_squares ; var index : integer ; begin writeln ; for index : = 1 to 10 do writein (index, index * index : 20) ; writeln end .
tabie-otsquares; vrindex:ig; I% zi% = 1TABlOTAB wn (ix, i’i : 20; wn
To do this, the user may need information on the screen to help select the correct words and to learn to understand TYP. The screens that such a user would see are shown in the following. @ gives the cursor position. Under each screen image the keystrokes are given between “. . .f’ and some comments are given.
Program @ Keystrokes Comment
: None : Screen after loading @ = cursor.
of the database,
Program table-o@ Keystrokes
: “table_ot”
Program table-of-squares c Keystrokes Comment
f
: “squares!” : After the space, a bell sounds (as shown by the exclamation mark) to signal that a word has been selected and that branching selection has been left. This sound is not a keystroke, but was generated by the program.
Program table_oLsquares 43
Keystrokes Comment
Verrips
@
; TAB=>FKlvar
: “;!#I : We see a list of suggestions, select ‘var’.
either TAB, arrow right or FK 1 will
79
;
Program table-of-squares var i@
No suggestions Keystrokes
Comment
: “r!i” : After
vr only var was syntactically correct and was therefore accepted. There are no suggestions listed for “i” and this fact is communicated by the message given by the program.
Program table-of-squares var in@
;
No suggestions
Keystrokes
available.
: “n”
;
Program table_of_squares var index : @
Keystrokes Comment
available.
: “dex:!!” : the colon causes
a double bell. The non-alphabetical “:“, forces an end to BS and then acceptance of “:“.
Program table-of-squares index : i@
character,
;
var
TAB, => FK 1 integer Keystrokes
;
Program table-of-squares var index : integer ; b@
TAB, => FK 1 begin.
Keystrokes
80
. end
: “g!;!b”
Program table-of-squares var index : integer ; begin w@ FK end . FK FK FK TAB, =>
Keystrokes
‘
: “i”
;
1 2 3 4
with . . do while . . do write (. .) writeln
: “g!w”
Interacting
with Computers
~014 no 2 (1992)
Program table_of_squares ; index : integer ; var begin writeln ; f@ I
end.
Keystrokes
TAB, => FK 1 for.
: “n!;!f”
Program table_oLsquares ; index : integer ; var begin writeln ; for i@ FK 1 input end . TAB, => FK 2 index Keystrokes Comment
to do
: “r!i” : ’ to’ and ‘do’ are displayed far to the right of the cursor. The grammar is not faultless, as is shown by ‘input’. ‘index’ is suggested because it is the most recently used identifier.
Program table-of-squares var index : integer ; begin writeln ; for index := 1 to 10 do w@ FK 1 end . FK 2 FK 3 TAB, => FK 4 Ikeystrokes Comment
to. . do
;
with . . do while . . do write (. .) writeln
! !w” : “x!:!=!l!TAB!l!O!TAB! : Two TABS move the cursor around ‘to’ and ‘do‘. The two spaces shift “w“ a bit more to the right than ‘for’.
Program table_oLsquares ; index : integer ; var begin writeln ; for index := 1 to 10 do writeln (i@ ) FK 1 input end . TAB, => FK 2 index Keystrokes Comment
: “n!(!i” : The closing bracket sion with the cursor.
“)” is displayed
to the right to avoid confu-
Program table-of-squares index : integer ; var
;
begin writeln ; for index := 1 to 10 do writeln (index, index + index : @) end . Keystrokes Comment
: “x!,!i*!!i:!!” : !! means two bell sounds.
The non alphanumeric characters ‘*‘ and ‘:’ were given inside BS and forced acceptance of the suggestion which was then selected.
Program tabIe_of_squares ; index : integer ; begin writeIn ; for index := 1 to 10 do writeln (index, index * index : 20 ) ; writeln @ end .
var
Keystrokes Comment
: “2!0!;!wn!” : Note that “;” jumped
beyond the closing now save the text and compile it.
bracket
“)“. One can
Please note that this hypothetical user only used the programs’ third predicate and that it is hard to imagine how the number of keystrokes could be further diminished.
82
lnferucting wifh Computers voI I no 1 (299.7)