perm filename OGDEN.DOC[2,TES] blob sn#039430 filedate 1973-04-26 generic text, type T, neo UTF8

             A Vague and Noncommittal Overview of OGDEN:

        an Overly General Display Editor for Non-programmers

                      compiled by Larry Tesler
             from various meetings of the POLOS project

                           April 26, 1973

Third draft.
Please make comments, corrections, and additions.


POLOS Project
                           April 26, 1973              OGDEN OVERVIEW

                  T A B L E   O F   C O N T E N T S

                               SECTION                           PAGE


            I.A       LONG-TERM GOALS  .  .  .  .  .  .  .  .  .  . 1

            I.B       SHORT-TERM GOALS .  .  .  .  .  .  .  .  .  . 1

            I.C       OGDEN   .  .  .  .  .  .  .  .  .  .  .  .  . 1

            I.D       INTERIM FACILITIES  .  .  .  .  .  .  .  .  . 2


            II.A      FEEDBACK   .  .  .  .  .  .  .  .  .  .  .  . 3

            II.B      CONTROL .  .  .  .  .  .  .  .  .  .  .  .  . 3

            II.C      POSTING BOARDS   .  .  .  .  .  .  .  .  .  . 4

            II.D      WINDOW PANES  .  .  .  .  .  .  .  .  .  .  . 4

            II.E      UNDOING .  .  .  .  .  .  .  .  .  .  .  .  . 5

            II.F      FILING  .  .  .  .  .  .  .  .  .  .  .  .  . 5

            II.G      DISTRIBUTION  .  .  .  .  .  .  .  .  .  .  . 5

            II.H      COMMUNICATION .  .  .  .  .  .  .  .  .  .  . 6

            II.I      GRADED CAPABILITIES .  .  .  .  .  .  .  .  . 6

            II.J      USER MODEL .  .  .  .  .  .  .  .  .  .  .  . 6


            III.A     ATOMS AND MOLECULES .  .  .  .  .  .  .  .  . 7

                           April 26, 1973              OGDEN OVERVIEW

            III.B     FRAGMENT STRUCTURE  .  .  .  .  .  .  .  .  . 7

            III.C     OUTLINE STRUCTURE   .  .  .  .  .  .  .  .  . 7

            III.D     INTENTIONAL STRUCTURE  .  .  .  .  .  .  .  . 8

            III.E     GALLEY STRUCTURE .  .  .  .  .  .  .  .  .  . 8

            III.F     PAGINATED STRUCTURE .  .  .  .  .  .  .  .  . 8

            III.G     TOPICAL STRUCTURE   .  .  .  .  .  .  .  .  . 9

            III.H     TABLE STRUCTURE  .  .  .  .  .  .  .  .  .  . 9

            III.I     FIELD STRUCTURE  .  .  .  .  .  .  .  .  .  . 9

            III.J     CROSS-REFERENCE STRUCTURE .  .  .  .  .  .  . 9

            III.K     DEPENDENCY STRUCTURE   .  .  .  .  .  .  .   10

            III.L     DISPLAY AREA STRUCTURE .  .  .  .  .  .  .   10

            III.M     HISTORY STRUCTURE   .  .  .  .  .  .  .  .   10

            III.N     STRUCTURER .  .  .  .  .  .  .  .  .  .  .   10


            IV.A      CREATION OF BOXES   .  .  .  .  .  .  .  .   11

            IV.B      TEXT BOXES .  .  .  .  .  .  .  .  .  .  .   11

            IV.C      MATH BOXES .  .  .  .  .  .  .  .  .  .  .   11

            IV.D      GRAPHICS BOXES   .  .  .  .  .  .  .  .  .   11

            IV.E      VOICE BOXES   .  .  .  .  .  .  .  .  .  .   12

            IV.F      TRANSFER AND EXCHANGE OF BOXES  .  .  .  .   12

            IV.G      ROTATION   .  .  .  .  .  .  .  .  .  .  .   12

            IV.H      EXPANSION  .  .  .  .  .  .  .  .  .  .  .   12


                           April 26, 1973              OGDEN OVERVIEW

            V.A       RAGGED DISPLAY   .  .  .  .  .  .  .  .  .   13

            V.B       GALLEY DISPLAY METHOD  .  .  .  .  .  .  .   13

            V.C       PAGINATED DISPLAY METHOD  .  .  .  .  .  .   13

            V.D       MIXED METHODS .  .  .  .  .  .  .  .  .  .   14

            V.E       INCREMENTAL FORMATTING .  .  .  .  .  .  .   14

                              AND PAGINATION .  .  .  .  .  .  .   14

            V.G       CROSS-REFERENCES .  .  .  .  .  .  .  .  .   14

            V.H       INDICES .  .  .  .  .  .  .  .  .  .  .  .   15

            V.I       INSETS  .  .  .  .  .  .  .  .  .  .  .  .   15

            V.J       COMPUTED TEXT .  .  .  .  .  .  .  .  .  .   15


            VI.A      INTENTION LANGUAGE  .  .  .  .  .  .  .  .   17

            VI.B      REFERENCE  .  .  .  .  .  .  .  .  .  .  .   17

            VI.C      VERIFICATION  .  .  .  .  .  .  .  .  .  .   17

            VI.D      EXPOSITION .  .  .  .  .  .  .  .  .  .  .   17

            VI.E      COMPOSITION   .  .  .  .  .  .  .  .  .  .   18


            VII.A     EXPERIMENTAL SYSTEMS   .  .  .  .  .  .  .   19

            VII.B     PRODUCTION SYSTEMS  .  .  .  .  .  .  .  .   19

            VII.C     MAXC/VTS   .  .  .  .  .  .  .  .  .  .  .   19

            VII.D     NOVA/VTS   .  .  .  .  .  .  .  .  .  .  .   19

            VII.E     ALTO    .  .  .  .  .  .  .  .  .  .  .  .   20

                           April 26, 1973              OGDEN OVERVIEW

                              ORGANIZATION   .  .  .  .  .  .  .   20


            VIII.A    LEVELS OF REJECTION .  .  .  .  .  .  .  .   21

                              MONITORING  .  .  .  .  .  .  .  .   21

            VIII.C    USER ACCEPTANCE MEASURES  .  .  .  .  .  .   21


                           April 26, 1973              OGDEN OVERVIEW

                              SECTION I



I.A.  We would like to develop a personal office computer linked to
others of its kind and to shared resources such as microfiche
libraries, XGPs, and outside phone lines.  The system should be
oriented towards common office use.  Functions should include
Composition, Display, Printing, Filing, Distribution, and
Communication.  Media shall include text, graphics, and voice.


I.B.  During the next year, we shall experiment with a distributed
system demonstrating some of the facilities desired in the eventual
system.  We hope to learn about various system organizations and
begin to learn about user interfaces.

We will decide in summer 1973 whether to use NOVAs, ALTOs, or a
combination of these in the initial experiments, and in what
programming language to build the system.


I.C.  Between now and the summer, we will try to construct an overly
general display-oriented editor herein called "OGDEN".  It will be
written in LISPX to take advantage of its data structure, debugging,
and undoing capabilities.  OGDEN will be a single-user system to be
used as a test bed for new ideas.

We will concentrate at first on solving problems we do not
understand, such as multiple structures describing the same document
and distributed control.

                           April 26, 1973              OGDEN OVERVIEW

OGDEN will be user interface-independent.  This will allow us to
construct different interfaces without redesign of the whole system
and to compare them in a common framework.

A set of implementation notes on the OGDEN system is being maintained
during its development.


I.D.  To handle the PARC workload while the new systems are under
development, we will import first TNLS and then DNLS to our MAXC.  We
will also participate in the development of a successor to PUB during
the summer so that we will have adequate formatting capabilities
without depending on an ever-changing experimental system.

                           April 26, 1973              OGDEN OVERVIEW

                             SECTION II

                           USER INTERFACES


II.A.  At least four feedback media will be available: Text, Marks,
Graphics, and Audio.  We will study whether to use each of these and
if so where and how to use them.

For text feedback, there are questions of continuous feedback versus
periodic feedback.  For example, when text is inserted, should the
surrounding text be realigned at each character as is done at SU-AI
or only at the end of the insert command as at ARC?  Where should the
text being inserted be displayed, and should it stand out in some

Mark feedback may be useful for delimiting segments that are to be
operated upon.  Where should marks be placed with respect to the
segment; what should they look like; how should they behave?

Drawn boxes may be more useful than marks for delimiting sections of
text as well as drawings and other document units.  Graphic devices
that convey the idea of change may also be useful: arrows for
translation, rotation, and expansion; explosions for deletion, and so

Audio feedback includes voice acknowledgment, voice error messages,
and characteristic tones.


II.B.  The same media are available for control as for feedback.

Text commands may be entered by keyboard or keyset.  Abbreviation
mechanisms should be studied.  Ways to enter nonstandard characters
must be designed.

                           April 26, 1973              OGDEN OVERVIEW

Bug marks may be positioned by a mouse or similar device.  There is a
question of where to place the mark with respect to mouse position.
The user may have designated a "command-scope" (such as character,
word, or statement) before placing the mark, or the system may place
the mark exactly as indicated and then deduce the command-scope from
the location of pairs of marks.

A box may be drawn as a series of lines or may be cued by noting just
a few points.  If there is a command-scope, only one or two points
are needed; if not, then more points are needed but the command-scope
is implied.

Voice commands will be limited by speech-analysis technolgy, but we
may not want to use voice control extensively because of user

Commands will be interpreted with respect to the context in which the
user is working; this should reduce the complexity of the command
language.  Other DWIM-like facilities, such as spelling correction,
will further ease the user interface.


II.C.  The various modules of the system will communicate with each
other and with the user through "posting boards".  Posting boards
list the contents of the file being edited, state information such as
ranges, modes, and view specifications, and control information such
as requested actions, confirmations, and error messages.


II.D.  The user's display screen is a paned window.  Each pane
provides a view of a portion of a posting board.  The user can edit
those portions of a posting board that can be seen through the pane.

State information can be changed and commands can be given by editing
posting boards through window panes.  The command language thus
becomes a shorthand notation for editing posting boards.

System modules will also view posting boards through window panes and
use them much as the user does.

                           April 26, 1973              OGDEN OVERVIEW


II.E.  In OGDEN, we will take advantage of the full undoing
capabilities of LISPX.  However, user systems may be restricted to
simpler but adequate capabilities. The simplest scheme is an UNDO
button which runs time backwards an event at a time.  It must be
possible to make selected changes and then run time forward again.

Nothing drastic, big, or important ever happens quickly.  After a
while, the history list can be compacted to eliminate small changes
that were made long ago.


II.F.  Digital and optical (microfiche) files will be provided.

File directory schemes will be toyed with.  A file directory can be
just another document.  How does editing it affect the state of the

Iconic naming systems will be explored.  A picture of a room full of
cabinets with drawers and file folders is one approach to a spatial
filing system.  Or the screen can display a human figure and files
can be placed in the eyes, the pockets, etc.  File backup can use
closets, vaults, etc.  We may be able to try these out even before
graphics are available by using the character generator.

Protection should be based on the premise that a document is private
until the author releases it.  It should be easy to specify the
permissible access to a file.  Each user can have a file management
program to control and record access.


II.G.  Ways for senders to specify receivers and for receivers to
specify topics of interest will be explored.  Methods of notification
and of acknowledgment will be developed.

A reminder facility should be provided as well.

                           April 26, 1973              OGDEN OVERVIEW


II.H.  Terminals can be linked together for conferences,
consultation, and demonstrations.  Problems that arise include loci
of control, protection, and synchronization.

Voice communication is an integral part of the system.  This may be
routed through separate channels or be part of the data communication

Each participant in a conference can select what to view or ask to
view what others select, including posting boards, bug marks, and
cursors.  Selecting what to hear should work similarly.

Each terminal should be responsible for maintaining the connection to
each other terminal in a conference.  Centralization would thwart
this requirement.


II.I.  A complete spectrum of capabilities should be provided from
elementary to very sophisticated.  A user should be able to
accomplish significant tasks with the simplest set of capabilities.
As proficiency, confidence, and expectations increase, it should be
possible to acquire new skills.  With knowledge of more powerful
facilities, the user should be able to be more productive and
efficient.  Furthermore, the opportunity to learn more skills should
maintain interest in the system and encourage creative use of it.


II.J.  The system of the user to communicate more effectively.  At
the very least, the model must include a list of system capabilities
that the user has learned.  If a secretary accidentally types a
command she has never heard of, the system will give an error message
instead of doing something incomprehensible to her.  The content of
messages to the user should take into consideration her knowledge as
reflected in the model.

                           April 26, 1973              OGDEN OVERVIEW

                             SECTION III



III.A.  A document has an unstructured existence as a collection of
uniquely named "atoms" such as characters and vectors.  An atom is
primitive and indivisible unless an atom editor is entered, just as a
file is primitive and indivisible unless a file editor is entered.
This means that the choice of atoms is arbitrary; e.g., words instead
of characters could be considered atomic.

The collection of atoms and molecules that comprise a document can be
structured into "molecules" in more than one way.


III.B.  This most basic of structures is nearly linear.  The document
consists of a sequence of "fragments", each of which is guaranteed to
begin a new page (e.g., a chapter).  Each fragment consists of a
linear list of atoms, e.g., all the words in the fragment in their
galley order of appearance.

Formatting modes are generally local to fragments so that they can be
processed individually.

A sublist of a fragment list is called a "subfragment".  It can be
treated as a molecule in other structures, e.g., as a paragraph, a
text line, a phrase, or a drawing (made of vector units).  Notice
that subfragments may nest as well as overlap.


III.C.  An outline structure is valuable, as demonstrated by NLS.

                           April 26, 1973              OGDEN OVERVIEW

However, other ways of looking at a document are equally important
and we should provide them.

One way to display outline structure is as in NLS.  We might explore
other node-numbering systems and even graphical display of trees.

Outline structure can also be extended upward to the organization of
file directories.


III.D.  This is a formal outline structure.  Headings are stated in a
formal language (with the help of DWIM) and describe the
communicational intent of the material which they head.  Examples of
headings are: "Definition of a spocket", "Construction of a spocket",
"Price of a spocket", "Addressee".


III.E.  This is the primary format structure. A fragment is divided
into "boxes" such as paragraphs, diagrams, and footnotes.  Each box
is (theoretically) ticked along its left and right edges at "group"
boundaries where horizontal page cuts may be made.  A text group
consists of lines of words.  A graphics group or math group will have
an apropriate structure.

A galley structure can be displayed either to scale or "ragged",
i.e., with fewer words and larger characters on each line for easier


III.F.  This is the structure of a paginated document.  It adds
levels between fragments and groups.  Thus, galley structure is
fragment-box-group while one paginated structure is fragment-page-
area-column-group.  Display of paginated structure can be to scale or

                           April 26, 1973              OGDEN OVERVIEW


III.G.  Passages relevant to a certain topic, although spread all
over the document, can be threaded together.  Topics themselves can
be organized into an outline or into an alphabetical index.   A topic
outline or index covering several documents is also useful.


III.H.  Two-dimensional tables should be manipulable by either rows
or columns.  The row structure and column structure can be thought of
as separate to make this natural.

Tables of more dimensions occur frequently in documents when the data
depends on several variables.  These may be thought of as multi-
dimensional arrays or as tables within tables.

One-dimensional tables, either horizontal or vertical, are also
common, including most posting boards.

Although display of tables is usually governed by format structure,
it might be a useful option to have them displayed on a cartesian


III.I.  Letters and travel forms may be rendered as field structures.
A paned window may be regarded as a field structure whose fields are
views onto posting boards.  When a field structure is displayed, the
form is generally overlayed.


III.J.  Cross-references should be executable like the links of NLS,
but should also be resolvable like PUB cross-references.  They form
an unusual structure because they consist of unsystematic connections
between pairs of points.  To display a connection in cross-reference

                           April 26, 1973              OGDEN OVERVIEW

structure, the screen can be split to show the referrer in one half
and the referee in the other with an arrow between them.

Inter-file cross-references must also be provided.


III.K.  Some elements of the document will be dependent on others.
If the latter are changed, the former must be recomputed.  A
dependency structure similar to a cross-reference structure is needed
to represent this.


III.L.  This is the tree structure of display areas imposed by VTS
and ALTO design.


III.M.  The history list maintained for undoing changes is a
structure that pretends to have extension in time.  A possible
generalization of this is a context structure.  The usual way to
display history structure is to actually display successive states in
either reverse or forward temporal order.  A useful adjunct might be
display of a list of changes of state, or better, a network revealing
the interdependencies of these changes.


III.N.  A program called the "structurer" will enable any machine-
readable document to be parsed into OGDEN form, providing at least
the following structures: fragment, paginated, and outline.  The
structurer will be driven by a syntactic description of the document,
taking advantage of the internal consistency of format of printed and
professionally typed material.

                           April 26, 1973              OGDEN OVERVIEW

                             SECTION IV

                       EDITING CONSIDERATIONS


IV.A.  A box is an important kind of molecule.  When one is created,
its location in galley structure is told as well as its format, e.g.,
"indented quotation".  One way to represent box formats graphically
is with a menu of outlines.  The user can select an outline, position
it on the screen, and fill in its interior with sub-boxes, other
molecules, and atoms.


IV.B.  Text boxes are fairly simple, but problems of variable spaced
fonts, a large repertoire of characters, and underlining must be


IV.C.  Non-cartesian two-dimensional formalisms have their own
problems and require special handling.  The input notation could be
Algol-like or two-dimensional.  The latter is harder to implement.
Math boxes frequently occur in text.


IV.D.  Both line drawings and half-tones should be representable with
captions.  It is possible that we will allow creation of line
drawings in the editor, but another approach for all graphics is to
generate them elsewhere and merely provide in the editor for their
inclusion in a document.

                           April 26, 1973              OGDEN OVERVIEW


IV.E.  A voice box can be played but not seen.  It often will have a
caption.  It should be creatable in the editor.  Audio compaction and
speech speedup are areas we will have to study extensively.

It may be possible to edit speech if phrases are discrete.  Bouncing-
ball visible representations of length, amplitude and stress may be
of assistance in this.


IV.F.  There are two ways to specify movement of an atom or molecule
within the structure currently displayed (usually a format
structure).  One way is NLS-style, where the source is demarked, the
destination is signified, and the command is given.  The other is
ATTACH-style, where the source is "cut" out of the document, the
destination is signified, and the material is "pasted" in at that
point.  The main difference is that while hunting for the
destination, the attach method allows the user to see the cut
material (or part of it) on the screen at the location of the cursor.
The cut-and-paste concept may also be more intuitive.


IV.G.  In later systems, a rotation capability may be available.  If
a box is not circular, there is a question of whether rotation causes
the outline to rotate or just the contents.  If the latter, are the
contents clipped?  Should rotation even be allowed?


IV.H.  Scaling of pictures is an important capability, and may belong
in the editor.  Scaling of text is also useful, but may be considered
"font changing" in a simple system.

                           April 26, 1973              OGDEN OVERVIEW

                              SECTION V

                         FORMATTING METHODS


V.A.  The document could be displayed "ragged" during editing.  This
is convenient when an 8.5"x11" page can not be displayed with
characters large enough for easy editing.  However, the user should
be able to request a view of fully formatted text and see it
immediately.  There are several methods of handling this.


V.B.  In the "galley display method", each fragment is displayed
fully formatted with respect to left and right margins, but page
boundaries are not marked, footnotes and diagrams are placed near the
relevant text, and headings and footings are incomplete.  Cross-
references to pages and similar items are either estimated or dummied
in (e.g., ****).

It should be possible to edit in formatted form.  To minimize
eyestrain, a zooming capability could be provided.

Upon command, any fragment would be paginated, but if an attempt were
made to edit that fragment, it would first revert to galley form.

Justification and hyphenation should be available at the option of
the user.


V.C.  This method requires continuous maintenance of a fully
paginated document during editing.  Any change which affects the
length of a page, the referent of a diagram, a cross-reference

                           April 26, 1973              OGDEN OVERVIEW

target, or the like would require incremental re-pagination.  This
could easily propagate to the end of the fragment or even to the end
of the document.  For short documents, it would be easy to keep up,
but it is not clear whether that is true for long documents.


V.D.  It would be possible to defer re-pagination of those pages of
the document which the user is not looking at to make the paginated
display method give better response.  Cross-references would have to
be estimated or dummied in.

Several methods could be provided having different performance
characteristics.  Either the system or the user could choose the one
most appropriate for the particular blend of attributes belonging to
the document at hand.


V.E.  No matter what display method is employed, incremental
formatting probably will be necessary.  This is simplified by
confining the scopes of modes to local domains such as fragments and
groups.  To handle interdependencies, either state information will
have to be kept for each increment, or dependent values will have to
be estimated or dummied in at times.


V.F.  The system should in general do as much work as possible for
the user, but in cases such as pagination there are esthetic
judgments to be made which can not be delegated.  The system can do
its best and let the user intervene to improve its decisions.


                           April 26, 1973              OGDEN OVERVIEW

V.G.  Some of the problems of cross-references have been discussed
above.  Distinctions must be made about the type of the value of a
cross-reference, e.g., page number, section number, file name.
Targets of cross-references may be specified by pointing or by


V.H.  It is possible to maintain a sorted index continuously, or to
maintain its entries continuously but sort it all at once, or to
construct it as a separate process altogether.  Selection of entries
to be indexed and the form in which they are to appear may be made
instance-by-instance by the user, automatically by the system, or by
reponses to automatic prompts.


V.I.  Most insets relate to a piece of text and can appear in
galleys.  However, if an inset would be broken by a page boundary, it
might be desirable to reformat the text that it dents so that it can
be moved up or down.

In rare cases, an inset does not relate to specific text, as a
picture centered in the middle of a page of text or a series of
pictures in the corner of each page of a book.  This causes grave
problems for the galley display method, because everything it has
decided can be altered drastically during pagination.


V.J.  Although most text is literal, some is variable, to be computed
by the system instead of entered by the user.  Examples are the date
of a letter, an address that can be computed from a name, and the sum
of a column of figures.

The dependency of computed text on other information should appear in
the structure of the document so that changes to that information
will be reflected in the value of the computed text.  Dependency
structures can accomplish this purpose.

                           April 26, 1973              OGDEN OVERVIEW

Graphic and voice items can be computed as well; for example, a
rectangle just large enough to outline a segment of text.

                           April 26, 1973              OGDEN OVERVIEW

                             SECTION VI



VI.A.  The outline headings of an intentional structure are in a
formal language to make the communicational intention of the material
meaningful to the system.  This is helpful to the user in many ways.


VI.B.  Intention headings may be used simply as labels.  The user can
ask to view the material so labelled or may specify a cross-reference
target by stating the heading.  These uses of intention headings are
trivial, but disambiguation and spelling correction may gain by the
formality of the intention language.


VI.C.  The system ca be asked to verify the soundness of an argument
or the completeness of a explanation by analyzing the statements of
communicational intention.


VI.D.  A document can "read itself" to a user by following the train
of thought symbolized by the statements of communicational intention.
This reading process will be partly interactive, but the system can
help the user by suggesting things to read.  These suggestions can
also be influenced by awareness of the user's knowledge as recorded
in the user model.  After the user has read something, the system can

                           April 26, 1973              OGDEN OVERVIEW

update the user model based on the formal statements of
communicational intention.


VI.E.  It is feasible to provide automatic composition of letters and
of first draft reports.  The user could say "write a letter to Joe
Doe about the new spocket technology", and the system would select
material guided by its intention to explain spocket technology and by
knowledge of previous correspondence with Joe Doe.  Automatic
abstracting might also be facilitated by intentional structure.

                           April 26, 1973              OGDEN OVERVIEW

                             SECTION VII



VII.A.  Experimental systems will be tried on a handful of users to
minimize widespread distress.  Most experiments will be made first in
OGDEN and only after some success will they be repeated in less
flexible small-machine implementations.


VII.B.  A simple production system should be brought up as soon as
possible.  It should evolve in parallel with the experimental
systems, but should lag it enough so that transient perturbations are
dampened.  Even "production" systems should be regarded as
essentially experimental and subject to the axe.


VII.C.  The primary experimental vehicle will be a system running on
MAXC through the MCA to the VTS.  This system will be for one user at
a time to try out new ideas and reject bad ones before they are
implemented at lower levels.  The programming language will be LISPX.

Once a primary system gains acceptance in single-user use, it will be
programmed for small machines.


VII.D.  One possible small machine configuration consists of several

                           April 26, 1973              OGDEN OVERVIEW

NOVAs hooked to the the Video Terminal System.  Possible programming
languages are MPL (when it works), LISPX (if it works), and BCPL (if
we can work it).


VII.E.  Another small machine configuration consists of several ALTOs
operating mostly independently with central connections to shared
facilities such as microfiche libraries and XGPs.  Possible
programming languages are LISPX, SMALLTALK, MPL, and BCPL.


VII.F.  It is possible for one machine to be performing many
functions for one user (usual ALTO mode) or to be performing one
function for several users (e.g., a VTS NOVA).  Modules should be
programmed so that they can be used in either way.  That is, several
functional modules may be loaded into one machine and told to service
one user, or one functional module may be loaded and told to service
many users.

One way to distribute processing is to consider each module to be a
responsible party.  When it is assigned a task, it is expected to
complete the task even if its normal procedure does not work.  If it
assigns subtasks to other modules, it should verify that they are
completed correctly and on time (as far as it is possible to tell).
When they are not, they should be re-assigned to other modules, such
as old versions of programs and modules resident in other machines.
When all else fails, an explanation should be reported to the module
that assigned the task.  Trouble reports should be filed in a central
facility if possible.

Inter-module protocols should be simple, but not so barren as to
stifle redundancy checking and verification.

For many purposes, the user may be thought of as a module.  Thus,
posting boards can list needs to be satisfied by any module willing
including the user.  However, carrying this notion too far may
produce an uncomfortable mode of interaction for the user.

                           April 26, 1973              OGDEN OVERVIEW

                            SECTION VIII



VIII.A.  Most ideas can be rejected as soon as they are conceived.
Most of the ideas that are actually pondered can be rejected before
they are spoken.  Most of the ideas that are discussed can be
rejected before they are programmed.  Many of the ideas that are
programmed will be dumped or drastically revised before completion.
Many of the ideas that are actually programmed will be rejected by
the programmer or colleagues during initial testing.

The surviving ideas will be tried on a few potential users among the
people working at PARC.  We will avoid pulling the rug out from under
our secretaries very often.


VIII.B.  We should include performance and utilization monitoring in
our programs both to locate opportunities for improved performance
and to discover the frequency of use and success of various features.


VIII.C.  Ways of obtaining and recording subjective evaluations from
users should be developed.


VIII.D.  It will not always be clear that one system is entirely

                           April 26, 1973              OGDEN OVERVIEW

superior to another.  Some features may be better in one and some in
the other.  A particularly bad feature can drag down others that
would be acceptable were that one improved.  Thus, measures should
include several variables and their interactions should be noted.