- Email: [email protected]
Word processors, text processors: aspects of the user interface
Journal of Microcomputer Applications (1985) 8, 175-179
COMMUNICATION
Word processors, user interface
text processors:
aspects of the
R. E. Berry and J. A. Hall* Department of Computer Studies, University of Lancaster, Bailrigg, Lancaster LA1 4 YN, UK *Monotype International, Cambridge Science Park, Milton Road, Cambridge, UK The widespread availability of text processors and word processors is proof of the demand for these facilities by users. The functionality of the packages is not usually questioned and is unlikely to be while demand is high. But, we argue, the user interface could and should be subjected to a more critical scrutiny.
1.
Introduction
An application area to which microprocessors have given significant impetus is text or word processing. These terms mean different things to different people, because views are inevitably coloured by the packages with which they can claim experience and familiarity. Another significant fact which colours views is the background and orientation of the user. An experienced secretary may find the transition to the different philosophy of a word-processing environment as problematical as she (or he) finds the peculiar control sequences of function keys bewildering. At the other end of the spectrum, the people who would consider themselves to be experienced computer users may not be perturbed about the strange control sequences necessary to invoke a particular action. However, they may well be disenchanted to discover that, despite being familiar with several text editors, the particular package they wish (need) to use offers them yet another user interface to master. A further impressive but rather worrying feature of many packages is the range of facilities, and therefore the instructions to implement them, which are on offer. In many cases the user of a word-processing package is looking for a limited number of useful facilities. There are relatively few of us ready to adopt the role of the typesetter with all the attention to detail that it requires, but at times it seems there is little option.
2.
Text processing
The term text processor is usually applied to a package which takes an existing file of text containing embedded commands and subjects it to such processing as will print the original text in the manner determined by the embedded commands. A survey of what processing packages are available might be useful but would undoubtedly be tedious.
0745-7138/85/020175+05
$03.00/O
175 0 1985 Academic Press Inc. (London) Limited
176
R. E. Berry and J. A. Hall
Instead let us subject two different packages to an admittedly superficial scrutiny. Readers might argue that Digital Standard Runoff under VMS (Digital Equipment Corporation, 1982) or indeed nroff under UNIX (Ossana, 1979) are not packages for microprocessors, but this is to ignore the reality that the terms microcomputer, microprocessor embrace more and better products almost daily (microVAX is already with us), and hence it is thought legitimate to comment on these,packages. Both use an identical philosophy. It is assumed that text is prepared using whatever text editor is available on the machine concerned. A command is prefixed by a full stop, it must appear on a line by itself and it must appear at the beginning of a line. Commands are available, and are necessary, to start a new paragraph, indent a line, start a numbered section etc. The result, as can be imagined, is that a text becomes liberally spattered with command lines which in extreme cases can be a serious impediment to easy comprehension and correction of the original text. A further criticism of these and other text-processing packages is that one can only discover unfortunate page breaks by processing the text and examining the output. The large number of commands, about 140 for DSR, is a disadvantage. The real question is perhaps whether the disadvantages outweigh the advantage of the excellent control one can exert on the layout of the resulting text.
3.
Word
processing
A word-processing package usually combines the role of a text editor with some of the functionality of a text processor. Wordstar, widely available under CP/M and other popular operating systems, offers such an approach. It combines the roles of text editor and text processor. Editing commands are typically ‘control characters’ (a character key pressed together with the control key) or alphabetic characters. Since, as with any editor using this approach, the commands are easy to forget, they are displayed by default in one of four menus. For example when inserting text the default menu occupies the top ten lines of the screen. Not all the menus are easily assimilated as a great deal of information is displayed in a relatively small area. Familiarity with the commands implies that the display space is wasted and so Wordstar allows its user to choose one of four levels of help which dictate how much menu is displayed. The default is the verbose option, while at the other extreme, the user can request that no help information is displayed. The left to right limits of the typing area are usually displayed as the last line of the menu, the remainder of the screen is available for the user’s text. When entering text, the user simply types as if all text were on one long line. When the right margin is passed, Wordstar justifies the words on the current line and starts a new line with any word that was incomplete when the right margin was passed. In this way the text is justified as it is typed and, for the most part, the user sees on the screen the form that the printed document will take. This brief overview does not do justice to the Wordstar package but provides a contrast to the previous example and the one which follows. As an all-in-one package it is impressive but text editing is often much more convenient in other specialist text editors.
Interfacing word/text processors
4.
177
Criticisms
There are of course many variants on the two themes presented here. One or more of these might adequately match an individual’s requirements, or perhaps we compromise too easily. There must be a class of users who do not wish to learn the intricacies of a particular package because, being intermittent users, usage details are forgotten from one time to the next. This is particularly true if the number of commands is of the order of one hundred or more. Those same users might also, as part of their normal work, make frequent use of a text editor for, say, program preparation. If the same text editor can conveniently be used for text preparation, then we almost invariably enter the text as we wish to see it. So we probably leave a blank line between paragraphs, indent lines as we require, and so on. In this fashion we build into the layout of the text the information that in other circumstances must be conveyed by an explicit command. Recognizing this we can make a start on reducing the command repertoire which is more easily remembered if it is small (Miller, 1956). This trend is observable in other areas. Those of us who witnessed with some misgivings the rapid expansion in the number of order codes of microprocessors have watched with some relief the rising popularity of the reduced instruction set computer, RISC (Patterson, 1982). It may not yet be widespread but it is being taken seriously. Such thoughts as these were sufficient to prompt the experimental construction of a text processor.
5.
Another text processor
Some time ago we made much use of the UCSD system (Bowles, 1980) on the PASCAL Microengine. As a result we were familiar with, and appreciative of, the UCSD editor which made text entry an easy matter. The text-processing program was written in PASCAL and the design aim was simple. We assumed as input a textfile produced by the editor containing processing commands which dictated how the resulting text was to appear. In the beginning, when it was small and simple, the program was thought by the authors to be well written. It was also successful, and because it was successful the temptation to add more features was hard to resist. Now, like many programs, it would benefit from a rewrite. Were it to undergo such a rewrite, then the UCSD-specific features, in particular string handling, would be changed to produce a version conforming to IS0 PASCAL standards (Addeyman et al., 1979). If the program itself does not merit a detailed description, then some of its better features certainly do. The input to the program was assumed to be a sequence of paragraphs. A blank line normally delimits successive paragraphs. A non-blank line containing the margin command, # # , would be interpreted as starting a new paragraph. Lines in which the margin command was the rightmost character pair were treated as literal lines. The normal action of the program was to read a paragraph, store it as an array of words and then construct and print a right-justified version of this paragraph. If the first line of an input paragraph was indented then the output paragraph would be indented by the same amount. Further, the position of the starting character of each line of a paragraph was stored in an array. This practice means that, in addition to dealing correctly with a conventional paragraph, we can also deal with paragraphs which are
178
R, E. Berry and J. A. Hall
progressively indented on the left. In noting that this is achieved without embedding commands within the text, we also observe it is only possible to do this with the left margin. If, because of justification at the right margin, words are moved from one line to another, then this is correctly handled. However, if justification causes more lines to be used in the printed paragraph than were in the original paragraph, then the excess lines are assumed to start in the same position as the last line of the input paragraph. A specific design goal was to keep to a minimum the number of commands in the command repertoire. This was achieved by both limiting the work done on the user’s behalf, for example, no automatic numbering of sections, and also by making use of the layout information embedded in the text by the user. Commands consisted of two characters, a command signifier ( #) and a command indicator. In so far as it was possible the command indicator provided a visual clue as to the purpose of the command. The list of implemented commands was as follows: # # left margin symbol; # % new page; # @ centralize; # _ # -
underline on; underline off;
# \ # /
subscript; superscript;
# < # >
blank on; blank off.
Of the commands embedded within the text, perhaps two are worthy of comment. The # # command proved to be very flexible. Its action can be understood as follows. Any text to the left of # # on a line is not eligible for justification. All text to the right is assumed to be eligible for justification. By default # # is assumed to be invisible at the left of each line of text, and so by default all text will be justified. A line containing an explicit # # command would, necessarily, act as a paragraph terminator. A little familiarity makes this an extremely useful command. The commands #\, #/, for half line forward, half line reverse, are notable for a different reason-they proved very troublesome to implement! It is thought that this was due to the rather simplistic way that ‘words’ and associated information were stored within the program. A word is assumed to be followed by a space unless it is at the end of a line. However, the elements of a subscript/superscript list should not be treated as words since, unless spaces are specifically embedded, no list element except the last should be followed by a space. In this respect mathematical formulae, which except for special symbols can be processed by the program, proved challenging. Upon entry to the program (known as Tidytext) the user is presented with a menu. This menu was carefully designed and constructed to make it as easy as possible to change the various default values listed for the user. The menu, given below, made it unnecessary to embed commands within the text to change line spacing, line length, paper size etc.
Interfacing word/text processors
179
program TIDYTEXT on 28/9/84 No C(ontinuous paper Yes J(ustification required Single S(pacing (s(ingle, d(ouble) F(irst page number K(ill how many pages N(umbering of pages required W(rite number at (t(op, b(ottom)
1 0 No TOP
L(eft margin width (tenths inch) R(ight margin width (tenths inch) P(itch (t(en, d(ozen) chars inch
13 13
T(ype of paper (p(erf., {A)4,5)
Dozen Perforated
D(enote commands by O(utput to file M(enu to be printed
# remote: Yes
The menu was in large part the work of Jerry Hall and has been highly regarded by all who have used the program. A convenient and robust user interface is well worth the effort. The menu is convenient because a single character selects the menu entry and, where possible, a single character selects the response. The remainder of the response is filled out automatically to preserve legibility. An interactive number reading procedure was written so that numerical input could be checked a digit at a time. In no circumstance was an invalid reply permitted. Exit can only be made from the menu when the user responds to the prompt for a space or a new-line character to do so. If requested, the menu can be printed prior to the text to which it refers. Tidytext has satisfied a wide variety of users, and has been used for correspondence, papers, examination papers and theses. The migration of users away from UCSD-based micros means that the program now has few users and the effort of constructing a ‘standard’ version usable on other machines is hard to justify, particularly in view of the fact that the printer interface would have to be made much more flexible than is presently the case. None the less it was thought at the time that the general philosophy of a small but useful menu and an extremely limited command set to embed in the text was right. Subsequent experience of more sophisticated operating systems and associated text processors have done nothing to change this view, they have tended to confirm that it was and is right!
References Addeyman, A. M., Brewer, R., Burnett-Hall, D. G.
et al. 1979. A Draft Description of Pascal. Software Practice and Experience, 9 (5), 381424. Bowles, K. L. 1980. Beginners Guide for the UCSD Pascal System. New York: Byte Books
(McGraw Hill). Digital Equipment Corporation 1982. VAX-II DIGITAL Standard Runoff, Version 2.0, May. Miller, G. A. 1956. The magical number seven plus or minus two: some limits on our capacity for processing information, Psychology Review, 63 (2), 81-97. Ossana, J. F. 1979. NROFFITROFF User’s Manual, UNIX Programmers manual 2A, January. Patterson, D. A. & Sequin, C. H. 1982. A VLSI RISC. IEEE Computer, 15 (9), 8-21.
COMMUNICATION
Word processors, user interface
text processors:
aspects of the
R. E. Berry and J. A. Hall* Department of Computer Studies, University of Lancaster, Bailrigg, Lancaster LA1 4 YN, UK *Monotype International, Cambridge Science Park, Milton Road, Cambridge, UK The widespread availability of text processors and word processors is proof of the demand for these facilities by users. The functionality of the packages is not usually questioned and is unlikely to be while demand is high. But, we argue, the user interface could and should be subjected to a more critical scrutiny.
1.
Introduction
An application area to which microprocessors have given significant impetus is text or word processing. These terms mean different things to different people, because views are inevitably coloured by the packages with which they can claim experience and familiarity. Another significant fact which colours views is the background and orientation of the user. An experienced secretary may find the transition to the different philosophy of a word-processing environment as problematical as she (or he) finds the peculiar control sequences of function keys bewildering. At the other end of the spectrum, the people who would consider themselves to be experienced computer users may not be perturbed about the strange control sequences necessary to invoke a particular action. However, they may well be disenchanted to discover that, despite being familiar with several text editors, the particular package they wish (need) to use offers them yet another user interface to master. A further impressive but rather worrying feature of many packages is the range of facilities, and therefore the instructions to implement them, which are on offer. In many cases the user of a word-processing package is looking for a limited number of useful facilities. There are relatively few of us ready to adopt the role of the typesetter with all the attention to detail that it requires, but at times it seems there is little option.
2.
Text processing
The term text processor is usually applied to a package which takes an existing file of text containing embedded commands and subjects it to such processing as will print the original text in the manner determined by the embedded commands. A survey of what processing packages are available might be useful but would undoubtedly be tedious.
0745-7138/85/020175+05
$03.00/O
175 0 1985 Academic Press Inc. (London) Limited
176
R. E. Berry and J. A. Hall
Instead let us subject two different packages to an admittedly superficial scrutiny. Readers might argue that Digital Standard Runoff under VMS (Digital Equipment Corporation, 1982) or indeed nroff under UNIX (Ossana, 1979) are not packages for microprocessors, but this is to ignore the reality that the terms microcomputer, microprocessor embrace more and better products almost daily (microVAX is already with us), and hence it is thought legitimate to comment on these,packages. Both use an identical philosophy. It is assumed that text is prepared using whatever text editor is available on the machine concerned. A command is prefixed by a full stop, it must appear on a line by itself and it must appear at the beginning of a line. Commands are available, and are necessary, to start a new paragraph, indent a line, start a numbered section etc. The result, as can be imagined, is that a text becomes liberally spattered with command lines which in extreme cases can be a serious impediment to easy comprehension and correction of the original text. A further criticism of these and other text-processing packages is that one can only discover unfortunate page breaks by processing the text and examining the output. The large number of commands, about 140 for DSR, is a disadvantage. The real question is perhaps whether the disadvantages outweigh the advantage of the excellent control one can exert on the layout of the resulting text.
3.
Word
processing
A word-processing package usually combines the role of a text editor with some of the functionality of a text processor. Wordstar, widely available under CP/M and other popular operating systems, offers such an approach. It combines the roles of text editor and text processor. Editing commands are typically ‘control characters’ (a character key pressed together with the control key) or alphabetic characters. Since, as with any editor using this approach, the commands are easy to forget, they are displayed by default in one of four menus. For example when inserting text the default menu occupies the top ten lines of the screen. Not all the menus are easily assimilated as a great deal of information is displayed in a relatively small area. Familiarity with the commands implies that the display space is wasted and so Wordstar allows its user to choose one of four levels of help which dictate how much menu is displayed. The default is the verbose option, while at the other extreme, the user can request that no help information is displayed. The left to right limits of the typing area are usually displayed as the last line of the menu, the remainder of the screen is available for the user’s text. When entering text, the user simply types as if all text were on one long line. When the right margin is passed, Wordstar justifies the words on the current line and starts a new line with any word that was incomplete when the right margin was passed. In this way the text is justified as it is typed and, for the most part, the user sees on the screen the form that the printed document will take. This brief overview does not do justice to the Wordstar package but provides a contrast to the previous example and the one which follows. As an all-in-one package it is impressive but text editing is often much more convenient in other specialist text editors.
Interfacing word/text processors
4.
177
Criticisms
There are of course many variants on the two themes presented here. One or more of these might adequately match an individual’s requirements, or perhaps we compromise too easily. There must be a class of users who do not wish to learn the intricacies of a particular package because, being intermittent users, usage details are forgotten from one time to the next. This is particularly true if the number of commands is of the order of one hundred or more. Those same users might also, as part of their normal work, make frequent use of a text editor for, say, program preparation. If the same text editor can conveniently be used for text preparation, then we almost invariably enter the text as we wish to see it. So we probably leave a blank line between paragraphs, indent lines as we require, and so on. In this fashion we build into the layout of the text the information that in other circumstances must be conveyed by an explicit command. Recognizing this we can make a start on reducing the command repertoire which is more easily remembered if it is small (Miller, 1956). This trend is observable in other areas. Those of us who witnessed with some misgivings the rapid expansion in the number of order codes of microprocessors have watched with some relief the rising popularity of the reduced instruction set computer, RISC (Patterson, 1982). It may not yet be widespread but it is being taken seriously. Such thoughts as these were sufficient to prompt the experimental construction of a text processor.
5.
Another text processor
Some time ago we made much use of the UCSD system (Bowles, 1980) on the PASCAL Microengine. As a result we were familiar with, and appreciative of, the UCSD editor which made text entry an easy matter. The text-processing program was written in PASCAL and the design aim was simple. We assumed as input a textfile produced by the editor containing processing commands which dictated how the resulting text was to appear. In the beginning, when it was small and simple, the program was thought by the authors to be well written. It was also successful, and because it was successful the temptation to add more features was hard to resist. Now, like many programs, it would benefit from a rewrite. Were it to undergo such a rewrite, then the UCSD-specific features, in particular string handling, would be changed to produce a version conforming to IS0 PASCAL standards (Addeyman et al., 1979). If the program itself does not merit a detailed description, then some of its better features certainly do. The input to the program was assumed to be a sequence of paragraphs. A blank line normally delimits successive paragraphs. A non-blank line containing the margin command, # # , would be interpreted as starting a new paragraph. Lines in which the margin command was the rightmost character pair were treated as literal lines. The normal action of the program was to read a paragraph, store it as an array of words and then construct and print a right-justified version of this paragraph. If the first line of an input paragraph was indented then the output paragraph would be indented by the same amount. Further, the position of the starting character of each line of a paragraph was stored in an array. This practice means that, in addition to dealing correctly with a conventional paragraph, we can also deal with paragraphs which are
178
R, E. Berry and J. A. Hall
progressively indented on the left. In noting that this is achieved without embedding commands within the text, we also observe it is only possible to do this with the left margin. If, because of justification at the right margin, words are moved from one line to another, then this is correctly handled. However, if justification causes more lines to be used in the printed paragraph than were in the original paragraph, then the excess lines are assumed to start in the same position as the last line of the input paragraph. A specific design goal was to keep to a minimum the number of commands in the command repertoire. This was achieved by both limiting the work done on the user’s behalf, for example, no automatic numbering of sections, and also by making use of the layout information embedded in the text by the user. Commands consisted of two characters, a command signifier ( #) and a command indicator. In so far as it was possible the command indicator provided a visual clue as to the purpose of the command. The list of implemented commands was as follows: # # left margin symbol; # % new page; # @ centralize; # _ # -
underline on; underline off;
# \ # /
subscript; superscript;
# < # >
blank on; blank off.
Of the commands embedded within the text, perhaps two are worthy of comment. The # # command proved to be very flexible. Its action can be understood as follows. Any text to the left of # # on a line is not eligible for justification. All text to the right is assumed to be eligible for justification. By default # # is assumed to be invisible at the left of each line of text, and so by default all text will be justified. A line containing an explicit # # command would, necessarily, act as a paragraph terminator. A little familiarity makes this an extremely useful command. The commands #\, #/, for half line forward, half line reverse, are notable for a different reason-they proved very troublesome to implement! It is thought that this was due to the rather simplistic way that ‘words’ and associated information were stored within the program. A word is assumed to be followed by a space unless it is at the end of a line. However, the elements of a subscript/superscript list should not be treated as words since, unless spaces are specifically embedded, no list element except the last should be followed by a space. In this respect mathematical formulae, which except for special symbols can be processed by the program, proved challenging. Upon entry to the program (known as Tidytext) the user is presented with a menu. This menu was carefully designed and constructed to make it as easy as possible to change the various default values listed for the user. The menu, given below, made it unnecessary to embed commands within the text to change line spacing, line length, paper size etc.
Interfacing word/text processors
179
program TIDYTEXT on 28/9/84 No C(ontinuous paper Yes J(ustification required Single S(pacing (s(ingle, d(ouble) F(irst page number K(ill how many pages N(umbering of pages required W(rite number at (t(op, b(ottom)
1 0 No TOP
L(eft margin width (tenths inch) R(ight margin width (tenths inch) P(itch (t(en, d(ozen) chars inch
13 13
T(ype of paper (p(erf., {A)4,5)
Dozen Perforated
D(enote commands by O(utput to file M(enu to be printed
# remote: Yes
The menu was in large part the work of Jerry Hall and has been highly regarded by all who have used the program. A convenient and robust user interface is well worth the effort. The menu is convenient because a single character selects the menu entry and, where possible, a single character selects the response. The remainder of the response is filled out automatically to preserve legibility. An interactive number reading procedure was written so that numerical input could be checked a digit at a time. In no circumstance was an invalid reply permitted. Exit can only be made from the menu when the user responds to the prompt for a space or a new-line character to do so. If requested, the menu can be printed prior to the text to which it refers. Tidytext has satisfied a wide variety of users, and has been used for correspondence, papers, examination papers and theses. The migration of users away from UCSD-based micros means that the program now has few users and the effort of constructing a ‘standard’ version usable on other machines is hard to justify, particularly in view of the fact that the printer interface would have to be made much more flexible than is presently the case. None the less it was thought at the time that the general philosophy of a small but useful menu and an extremely limited command set to embed in the text was right. Subsequent experience of more sophisticated operating systems and associated text processors have done nothing to change this view, they have tended to confirm that it was and is right!
References Addeyman, A. M., Brewer, R., Burnett-Hall, D. G.
et al. 1979. A Draft Description of Pascal. Software Practice and Experience, 9 (5), 381424. Bowles, K. L. 1980. Beginners Guide for the UCSD Pascal System. New York: Byte Books
(McGraw Hill). Digital Equipment Corporation 1982. VAX-II DIGITAL Standard Runoff, Version 2.0, May. Miller, G. A. 1956. The magical number seven plus or minus two: some limits on our capacity for processing information, Psychology Review, 63 (2), 81-97. Ossana, J. F. 1979. NROFFITROFF User’s Manual, UNIX Programmers manual 2A, January. Patterson, D. A. & Sequin, C. H. 1982. A VLSI RISC. IEEE Computer, 15 (9), 8-21.