Michael Hammer, Richard Ilson, Timothy Anderson, Ed Gilbert,
Michael Good, Bahram Niamir, Larry Rosenstein, and Sandor Schoichet
Office Automation Group
Laboratory for Computer Science
Massachusetts Institute of Technology
Cambridge, Massachusetts, USA
Originally published in 1981 Office Automation Conference Digest (Houston, Texas, March 23-25, 1981), AFIPS, pp. 209-219. Copyright © 1981 American Federation of Information Processing Societies.
Introduction
Contemporary word processing systems are being subjected to a variety of contrasting, even conflicting, pressures. On the one hand, existing systems are widely perceived as being too difficult to learn and use for all but the simplest of document production applications: training times are high, errors too frequent, and the user population is generally restricted to a small cadre of specialists. In particular, the professional in the office, who is responsible for the content of documents, is rarely a user of the systems that are used to produce these documents. Yet because of an anticipated shortfall in the available population of office support staff, and because of the real benefits that derive from the use of advanced office systems, it is very desirable that professionals and other office workers be able to make effective direct use of automated office tools. A document production system that is simple to learn and easy to use can do much to realize this goal.
At the same time. recent advances in printing technology, such as “dry” phototypesetters and moderate cost laser printers, can be exploited to raise the quality of the appearance of documents that are produced with a word processor. These printers are characterized by their ability to place virtually any pattern of dots on a page. This enables them to print text in a wide variety of styles and sizes, to employ variable inter-character and inter-line spacing, and to match many of the other qualities typically associated with typeset documents. The advantages that these printers can yield are substantial, including lowered costs for paper, copying, and mailing (since typeset documents require less paper than their typewritten counterparts); improved readability and comprehension; and a greater variety of document formats and layouts. However, to control such output devices in order to realize their benefits, to specify how and where text is to be printed, imposes additional burdens on the operator. New sets of commands are required, which further complicate the interface that the user must employ. Although there is a strong demand in the office for the document quality that these printers can achieve, attaining this new functionality would seem to be at odds with the equally important goal of reducing the difficulty of using document production systems. For a system to be useful, it must be usable.
Etude is an experimental document processing system that seeks to address both these issues: to increase the functionality of office document production systems by exploiting the capabilities of new printing technologies, while reducing the complexity of the user interface. This paper presents the design philosophy of Etude and summarizes its features. Complete specifications of the Etude system can be found in [3], and a discussion of the techniques used to implement it is presented in [4].
“Ease of Use” Problems and Etude’s Solutions
In order to make a new system truly easy to use, it is first necessary to identify and understand the factors that make conventional computer-based systems difficult to use. In this section, we identify what we believe to be the principal impediments to the effective use of word processing systems, and present the ways in which Etude addresses them.
One problem with many computer-based systems is the low level of the interface through which an operator communicates with the system. Frequently, the user is required to go into great detail in order to specify commands, and to use terms that are unnatural to him and to his application. For example, in the case of conventional formatting systems, the user must essentially be an amateur typographer in order to produce a typeset quality document. He must explicitly control the selection of type styles, leading, and page layout, issues with which he is unfamiliar and in which he possesses no particular expertise. This places demands on the operator that he is unlikely to be able to meet. Providing the average office worker with a low level formatting language amounts to a prescription for the production of ugly documents. Even the user who manages to learn a low level formatting language will not be able to successfully tap the capabilities of sophisticated electronic printers.
Etude allows a user to express himself in terms that are natural to him and his task, both when editing and when formatting. For editing, Etude has an “English-like” command structure, in which familiar primitives are combined into commands. A typical command has the form: action / (optional) modifier / object. An action might be delete or copy; a modifier could be next or a number, like 3; and an object could be word, line, paragraph, and the like. Thus, typical commands include delete 3 words and copy next paragraph.
The typical user of Etude does no direct formatting of his document in the sense of providing low-level commands to the system to specify type faces, spacing, margins, and the like. Rather, the user merely identifies and names the components of the document in terms of the familiar vocabulary of conventional office documents. For example, an operator might identify the document on which he was working as a report, indicating within it the title page. the abstract, the sections, the summary, and so on; within each section, he would indicate the paragraphs and any other constituent structures to appear. (This approach to format specification is the same as that employed by the Scribe formatting system. [5]) Etude employs a database of formatting information that specifies how documents and document components of different types should appear, and uses it to construct formatted documents in keeping with the user’s requirements. Substantial formatting expertise is embedded in this database; moreover, it can be modified or extended as needed, to conform with the requirements of individual offices and the people who work in them.
A second major shortcoming of present word processing systems is the delayed feedback loop inherent in “batch” formatting. In conventional systems, the user intersperses commands with the text of his document. These commands control the “format” the text in which they are embedded (i.e., how the text will appear when printed). The formatter component of a word processing system interprets these commands, and constructs pages with appropriate appearance. However, the operator, when in the process of specifying format commands, does not see their effect; he is working “blind,” with the raw form of the document. In short, the “editor” and “formatter” components of the system are not integrated with one another; they are invoked in a sequential fashion. In large part, this is a consequence of the fact that the translation required to create a formatted document from its specifications is time-consuming and therefore tends to be done infrequently (i.e,, in “batch” mode). The net result is a delay that considerably encumbers the process of creating a document with a desired appearance.
Moreover, once the document has been “formatted,” it cannot be directly modified by the operator; if he wishes to make a change, he must reinvoke the editor to modify either the text of the document or the formatting commands, and then apply the formatter again. In other words, the user must deal with two separate versions of his document: the formatted version, which he cannot directly modify, and the unformatted version, which can be edited but is cluttered with formatting commands.
Modern display-based word processors represented a major advance over their predecessors because they allowed the user to see the results of his editing commands. Etude goes further and shows the user the effects of his formatting commands. Because Etude integrates editing and formatting into a single system–unlike conventional word processing systems–it can show both the content and the appearance of a document on its display. Thus, the Etude operator sees and manipulates a fully formatted version of the document, one that represents a final image of what the document would look like if it were printed. Depending on the capabilities of the display screen, this can include multiple type faces and sizes, variable leading (inter-line space), a variety of page layouts, and other capabilities typically associated with typeset documents. The purpose of providing this interactive, real-time formatting facility is to reduce the feedback loop, so that an operator specifying the appearance of his document will not have to wait until the output is produced by a printing device to determine if its appearance is suitable; he can see it right on his screen. (In this regard, Etude has certain points in common with the Xerox Document System. [6])
Also of major importance is what we call the anxiety factor, a common characteristic of conventional computer-based systems of many different kinds. Frequently, a long period of acclimatization must elapse before an operator is sufficiently expert with a system to feel truly comfortable with it. In the interim, the user’s feelings are akin to those associated with walking a tightrope while wearing a blindfold. Because of the often obscure nature of the interface that he is forced to employ, the operator cannot fully anticipate the consequences of the actions he performs. This leads to feelings of tension and uncertainty. Moreover, the user develops a fear of committing an unrecoverable error, and thereby becomes overly timid and cautious in his dealings with the system.
Etude addresses this issue through the design of its user interface and by means of a set of operator support facilities. The command language employs natural terminology, and allows the user to synthesize commands whose meaning is manifest to him. On-line help and menu facilities are available to assist in resolving uncertainty. A go ahead key, which the user must press to confirm major changes to his document, and a cancel key, which enables incomplete operations to be retracted, make it less likely that the user will commit a catastrophic error. Most importantly, an undo key enables already completed operations to be rolled back, whenever an action yields an undesirable result. The unit of rollback is a full Etude command, which may entail substantial activity (as in move sentence (to) end-of paragraph). The undo facility provides an operator with a secure feeling, one which encourages experimentation and enables him to learn the system one step at a time.
Another shortcoming with conventional systems is that they do not support an incremental learning process. Even systems that are relatively easy to use are usually difficult to learn. In order to perform any significant work, the operator must usually be familiar with an extensive body of commands and features. It is usually not possible for him to develop a simplified model of the system’s operation in order to use a smaller set of its features. Instead, a full understanding of its capabilities is required, even to employ just a rudimentary set of commands. Moreover, the transition from novice to experienced user is not a smooth one with most contemporary systems. On the one hand, a system that makes extensive use of prompting, menus, and other such devices in order to simplify operation for new users is likely to be extremely cumbersome for the same user once he has developed some familiarity with it. On the other hand, it is difficult for someone to become expert with a system that is tailored to experienced users. In short, there is often a conflict between ease of learning and ease of use.
Etude seeks to resolve this tradeoff by providing a catholic user environment that allows the operator to determine the nature of the interface he will employ and the amount of support he is given. Command primitives can in most cases be typed, selected from a menu, or designated via a special function key. help information and menus are available should the operator need them and are optional so that an experienced user is not burdened with them. The operator can press the help key after any other key to receive an explanation of the first key’s function. He may also press the help key whenever he is confused or uncertain; Etude then explains the current situation to the user, showing him how he got into the situation and what he may do next. (This explanatory material is displayed on the screen in a special window that is created at the time. This window overlays, but does not replace, the material with which the user is working, thereby increasing the utility of the information it carries.) At any time the operator can press menu to see a list of the alternatives available to him at that time, without the explanatory text that comes with help. Like help, menus are context-dependent, and show only currently meaningful alternatives.
The Etude System
Etude was designed to explore certain novel concepts in the design of easy-to-use document processing systems; a prototype implementation has been constructed to establish the implementability of these features and to provide a testbed for an experimental human factors evaluation of the Etude user interface. This section summarizes the facilities of Etude as seen by the operator.
Etude is intended to operate on a hardware platform that provides a high-resolution bit-map display device–a screen sharp enough to display actual type faces. (Etude may also be used with conventional CRT screens, but only a page-size bit-map display will support of all of Etude’s capabilities.) The Etude operator sees the display divided into a number of windows. The center portion of the screen is the text window, in which a full page of formatted text is displayed. This page may include text in a variety of type styles and sizes, may be right-justified, and may be organized in a variety of page layout formats, as determined by the format specifications associated with the document and its components. The display is intended to represent the appearance of the document as it would be printed by a typeset quality output device; it is constantly maintained to reflect the current status of the document as it is changed in the course of the editing process. The left margin of the page serves as the format window, in which the components of the document’s structure are indicated. (Etude has several user-selectable pagination and display modes, which determine such options as whether page-breaks are recomputed dynamically or on explicit request, and whether component names are displayed or not in the format window.)
Part of the screen is reserved for interaction and status windows. The former displays the user’s commands and the system’s responses, as well as error information; the latter shows a variety of contextual information. Help information and menus are displayed on request in special windows that pop up on the screen when necessary. These windows are placed so as not to obscure the area of current interest to the operator, which in general is defined to be the area around the position of the cursor.
Figure 1 is a photograph of the display screen taken during an Etude session. The text window is visible in the central part of the screen. The text is right-justified, and includes an italic as well as a normal typeface. The left edge of the screen identifies the document components associated with various parts of the text; these control how the text is formatted and displayed. For example, items in a number (for “numbered list”) are block indented from both margins. It should also be noted that the numerals “1” and “2” associated with the items were not typed by the operator; they were automatically generated by the system, and would be automatically changed if, for example, the first item were moved to the end of the list. (In fact, these numerals are entirely inaccessible to direct manipulation by the operator.) The status window is displayed across the top of the screen.
Figure 1: The Etude Screen
Etude does not have separate “input” and “edit” modes; typed characters are immediately inserted into the document at the position of the cursor and displayed on the screen. As mentioned above, as text is typed the display is continuously reformatted in accordance with the prevailing document components at the cursor position.
An Etude command is structured like an English imperative; it consists of a verb phrase and one or more noun phrases. A command is signalled by pressing a special “verb” key (or by pressing the menu key and then selecting a verb from the displayed menu). A noun phrase consists of a series of modifiers and an object. Etude provides a number of basic objects (character, word, sentence, line, component, paragraph, column, page, window, and document) that are widely used in many different contexts, as well as a set of document-specific components. There are four basic modifiers (next, previous, start-of, and end-of); any positive integer may also serve as a modifier. Modifiers and objects may be combined as in English; for example, start-of paragraph, end-of next 3 sentence(s), previous 10 line(s). Document-specific components may also be used in phrases; for example, start-of address might be used while editing a letter.
Most verbs, all modifiers, and key objects can be indicated with a single keystroke. This can he achieved either with dedicated function keys (our preference), or by combining alphabetic keys with a “special” code key (a conventional approach, employed in the current prototype). Also, they can be typed or selected from an explicitly requested menu. The tradeoffs involved in keyboard layout, and in identifying those primitives that deserve dedicated keys, are explored in [7]. We have designed an Etude keyboard, and will employ it in the next version of the system
Etude verbs fall into three categories: editing, formatting, and user aid. The editing verbs are relatively standard, and include copy, move, search, remove, and the like. These verbs typically operate on regions of a document. A region may be defined by a noun phrase or by a series of cursor movements bracketed by begin and end. One novel command is label, which allows the user to associate a name with either a particular point in the document or with a region. These labels may be subsequently employed wherever a position or region is required (as in goto or move commands). This feature is particularly useful when moving back and forth between distant points in the document, or when a particular region of the document is repeatedly the object of commands.
To move the cursor, the user can combine the editing verb goto with a noun phrase. As a shortcut, the built-in objects can be used by themselves to indicate “goto next object.” For example, repeated use of the paragraph key moves the cursor through the document a paragraph at a time. If the previous key were truck before the paragraph key, the user would move backwards through the document. Alternatively, arrow keys may be used to move the cursor. Etude’s system architecture allows for cursor motion through the use of a pointing device such as a joystick or a “mouse,” but the system is not dependent on their availability.
The formatting verbs are used to associate the name of a document component with a particular region of text. Such an association can be established as text is being keyed, or the component name can be linked with existing text. In general, the user must explicitly indicate the beginning and end of the region of text that constitutes a component of the document. For example, in the process of typing a letter, the user would specify begin returnaddress, type the return address, and then type end. Etude would employ its database of typographic information to determine how the return address of a letter should be formatted and placed on the page. The user could then proceed to name the next component of the letter, type its contents, and signal its end. Special facilities are provided to reduce the overhead of such specifications for experienced users. In situations where the end of a component of a given type is immediately followed by the beginning of another one of the same type (as in sequences of paragraphs, or of items in a list), a single key (new component) can be employed, instead of a end … begin sequence. Similarly, bold or italic type faces can be selected by pressing the bold or italic keys, and pressing normal to signify the end of their scope. It should be stressed that these are merely time-savers for experienced users. The uniform begin … end approach can always be applied, and novices need not learn anything else.
Existing text can be associated with a document component by means of the make command, as in make previous 3 lines (a) quotation. This specifies that the three lines preceding the cursor represent a quotation, and should be formatted as such. Component changes (e.g., turning a numbered list into an enumeration) are accomplished via the change verb. Remove dissociates text from a document component; the text is left intact, and becomes part of whatever document component surrounded the removed one.
It should be noted that Etude provides an extensible facility for defining new document types and document components, and for changing existing ones. At present, it is in the form of a database (based on that of Scribe [5]), which defines the format of document components in terms of a number of key attributes (such as type face, margins, etc.). We expect that Etude will have some set of “built-in” document types and components, and that a user organization will extend this set to meet its own needs. Currently, a user seeking to access and modify this database will have to be considerably more sophisticated in formatting concepts than the novice Etude user.
Access to this database can be limited to those having the expertise and authority to change it. It should be noted that organizational standards and a guaranteed level of document appearance quality can be achieved by carefully restricting the modification of the database. We are beginning to develop techniques to simplify the process of document component definition as well. But the key issue is that a novice user can rely on the components provided him, enabling him to do productive work with a minimum of training; the standard documents and components should represent terminology already familiar to him, and should address the bulk of his needs.
There are several important consequences of this extensibility and of the naturalness of Etude’s formatting vocabulary: first, that it is infeasible for each component to be available on a function key; second, that an operator cannot be expected to remember the names of all the components he might wish to employ; and third, that some component names are likely to be lengthy. Etude addresses these issues in the following ways. The most basic components (such as paragraph and sentence) are in fact provided by special keys. If the operator does not remember the name of the component he wishes to use, he can press menu, which will display to him all the components associated with the document’s type. He can then select from this menu (currently, by using arrow keys and go ahead). At any point in the typing of a component name (even after a single character), the user can press go ahead. If the characters typed so far uniquely identify a component name, the system will immediately extend them out to the full name. (Thus, “ret” would be extended to “returnaddress.”) If there is no unique extension (e.g., “i” is the beginning of both “item” and “italics”), Etude will extend as far as possible (in this case, to “it”) and then ask the user to continue typing. At this point, if the user presses menu, Etude will respond with a menu showing just those component names beginning with “it.” In other words, Etude provides a built-in, natural abbreviation facility, which does not require that the user memorize abbreviation codes in addition to natural names. For users who wish to create their own abbreviations, an abbreviation command is provided.
The user aid verbs provide Etude’s supportive working environment. As described above, undo allows the user to reverse the effect of his last operation or sequence of operations. This feature encourages experimentation without anxiety; if a result is not what the user intended, he can always undo it. (The implementation of Etude provides the underlying structure to enable such rollback to extend arbitrarily far into the past, at some associated cost (in the form of the storage needed for maintaining historical information). In practice, we expect that enabling up to the last five commands to be undone will suffice.) Menu can be used at any time to get a list of valid alternatives, and help can be used to explain one or all of these options in successively greater detail. Go ahead is used to confirm operations, such as remove and copy, that can make major changes to a document, and for related purposes. Cancel aborts the current operation and returns to the state that followed the last completed operation. Again repeats the preceding operation.
As described earlier, Etude has had twin goals: to extend the functionality of conventional word processing systems while reducing the complexity of the user interface. In addition to enabling the user to utilize multiple type fonts and sizes, variable spacing and leading, and similar features usually associated only with typesetting systems, Etude also provides a page layout facility that considerably exceeds those of conventional word processing systems. This facility, described in [8], is based on a very general mechanism for constructing pages out of containers, rectangular areas that may contain material potentially drawn from a variety of sources. In the current version of Etude, this enables the production of documents with multiple columns of text, running headers and footers, white space for figures surrounded by text, figure captions, and the like. (We are in the process of developing facilities for generating graphs, images, and other non-textual material on the workstation and directly inserting it into a document.) However, in keeping with the Etude approach, these capabilities are not directly provided to the end-user, who is likely to be ill-equipped to utilize them effectively. Rather, the definitions of document types and components in the formatter database indicate how pages are to be composed and where components are to be placed on them. Thus, the user need only name the correct kind of document or component; for example, an article might be defined to have a two-column format and a 2 x 2 figure might be a region of white space, 2 inches square, located one third of the way down the page.
A prototype implementation of Etude has been operational since February 1980, and a revised implementation effort is currently underway. The prototype operates on a DECSystem 20 computer and drives a high resolution, bit-map display terminal; it can also drive a conventional terminal. (In the latter case, the full set of Etude capabilities can not be demonstrated. Rather, a representation of the final image of the document is displayed on the screen, in which, for example, italic text is represented as being underlined, and proportional spacing is not employed. Nonetheless, we believe that there are virtues associated with the ability to utilize Etude from a less costly display device.) We are migrating Etude onto a stand-alone office workstation environment.
Numerous important and complex implementation problems are raised by a system with the functionality of Etude. These are explored in [4] and [9]. In brief, the key issue is that of developing a representation of a document that enables “real -time” formatting with acceptable efficiency and also supports a friendly user interface and working environment.
We are undertaking a series of experimental studies to assess the quality of the Etude system and the approach to user interface design that it embodies. A study of the relevant human factors literature [7] suggests that Etude is generally compliant with the received wisdom regarding the design of interactive systems, but this can only be established by experience with the system.
Toward an Integrated Office Workstation
Etude is just the first step in a longer range effort to develop an integrated set of tools that will comprise an office workstation, a personal and interactive computer-based system that will provide an office worker with access to a wide range of support capabilities. Because of the fundamental position occupied by documents in the office, our initial focus has been on document processing. We are now engaged in the extension and enhancement of Etude, broadening its scope to include aspects of document production heretofore beyond the realm of word processing. Among these additional facilities is a graphics subsystem, that will enable an operator to develop a figure on-line and directly incorporate it into an Etude document.
An integrated office workstation is more than just a collection of office tools. It must provide consistent user interfaces to the tools, uniform data structures underlying them, ready context switching among them, and a supporting infrastructure. We believe there will be different versions of such a workstation for different classes of office personnel, such as clerical workers, professionals, and managers. We also believe that a small set of fundamental capabilities can form the underpinning of all the facilities to be provided in these various contexts. These include a document production system (such as Etude), an office database management system, an image handling system, and a communications mechanism. Out of this collection of tools can be built virtually any office application system. We are in the process of identifying the functions and facilities that these basic components will provide, and are designing a common base of software that will underlie all of them. For example, an office database system differs in a number of important ways from more conventional database managers. It must be able to cope with multiple modes of data, including text, graphics, and images. It must deal with non-uniformly structured data, and must support very easy entry and retrieval of data. We view the office database system as a universal filing system for the documents and information bases used in the office, as well as a gateway into corporate database systems.
By enabling the production of typeset quality documents while providing ease of use, Etude goes beyond both conventional word processing and typesetting systems. It forms the basis for a usable, integrated office workstation.
References
- Ilson, Richard and Sandor Schoichet. An Integrated Model for Formatted Documents. Proceedings of the 1980 Computer Networking Symposium, Dec., 1980, pp.178-184.
- Office Automation Group. Annual Progress Report. Memo OAM-017, MIT Lab. for Computer Science, Office Automation Group, June, 1980.
- Ilson, Richard. An Interactive Editor and Formatter. Working Paper WP-004, MIT Lab. for Computer Science, Office Automation Group, June, 1979. Revised version expected December 1980.
- Hammer, M., R. Ilson, et. al. The Implementation of Etude, An Integrated and Interactive Document Production System. Memo OAM-026, MIT Lab. for Computer Science, Office Automation Group, Dec., 1980.
- Reid, Brian K. and Janet H. Walker. Scribe Introductory User’s Manual. Third edition, Unilogic, Ltd., 605 Devonshire St., Pittsburgh, PA, 15213, 1980.
- Ehardt, Joseph L. and Patricia B Seybold. Experimental Systems: Xerox Document System, M.I.T. Etude. The Seybold Report on Word Processing 3, 9 (Oct. 1980).
- Good, Michael. Etude and the Folklore of User Interface Design. Memo OAM-018, MIT Lab. for Computer Science, Office Automation Group, July, 1980.
- Schoichet, Sandor. Page Makeup in Etude. Working Paper WP-020, MIT Lab. for Computer Science, Office Automation Group, April, 1980.
- Ilson, Richard. An lntegrated Approach to Formatted Document Production. Master Th., Massachusetts Institute of Technology, Aug. 1980.
Copyright © 1981 American Federation of Information Processing Societies, which no longer exists. If you are aware that this republication infringes on an existing copyright, please notify me so I can either get republication permission or remove this article from the site.