|
Etude:
An Integrated Document Processing System
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.
Home
- Music - Software - MusicXML
- Events - Search - Store
- About Us - Publications
|