Advanced_Intellect Augmentation_Techniques_Jul70 Advanced Intellect Augmentation Techniques Jul70

Advanced_Intellect-Augmentation_Techniques_Jul70 Advanced_Intellect-Augmentation_Techniques_Jul70

User Manual: Advanced_Intellect-Augmentation_Techniques_Jul70

Open the PDF directly: View PDF .
Page Count: 204

Download
Open PDF In Browser	View PDF

Final Report

ADVANCED INTELLECT-AUGMENTATION
TECHNIQUES

By: D. C. ENGELBART and STAFF OF AUGMENTATION RESEARCH CENTER

Prepared for:

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION
LANGLEY RESEARCH CENTER
LANGLEY STATION, MAIL STOP 126
HAMPTON, VI RGINIA 23365

CONTRACT NAS1-7897

STANFORD RESEARCH INSTITUTE
Menlo Park, California

94025 • U.S.A.

Final Report

July 1970

ADVANCED INTELLECT-AUGMENTATION
TECHNIQUES

By:

D. C. ENGELBART and STAFF OF AUGMENTATION RESEARCH CENTER

Prepared for:

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION
LANGLEY RESEARCH CENTER
LANGLEY STATION, MAIL STOP 126
HAMPTON, VIRGINIA 23365

CONTRACT NASl-7897

SR I Project 7079

Approved by:
DAVID R. BROWN, Director
Information Science Laboratorv
BONNAR COX, Executive Director
Information Science and Engineering Division

.CO~y

No.

41...... .

ABSTRACT

This report cover. a two-year project, at the eleventh year of a
growing, multiproject program that is exploring the value of
computer ai~s to augmenting human intellectual capability.
Outlined brieflY are the baCkground and the "bootsttapplng"
nature of the procram, its resources, and the activities it has
undertaken in pursuit of its goals.
Advances ma4e during the project were:
(1) Making operational an experimental interactive laboratory
comprising an XDS-940 computer, special interface and dilplay
hardware, a mOdified UCB-GENIE timesharing system, six NLS
consoles and lixteen typewriter terminals, a 96-megabyte
file-storace diSk, and a 96-character line printer
(2) Making extensive progress in the develo~ment of
special-purpose languages and softWare architecture to provide
for both highly interactive service and flexible system
evolution
(3) Moving our team of Iystem developers into an on-line
working mode, and beiinnin~ to learn how to adapt to thi'
environment -- with encouraging success, as represented oy our
emerging "software-engineering" methodOlogy
(4) Establishing a plan, and partiallY implementing the basic
services, for an information center to serve the experimental
ARPA Network.

User experience in applying our augmentation tools and techniques
to various normal working tasks within our center is described so
as to convey a SUbjective im~ress1on of What it i5 like to work
in an augmented enviroment.
It is conclu~ed that workinl-8up~ort, computer-aid systems for
augmenting individuals and teams, ot the general sort we have
been experimenting With, are undOUbtedly loing to be widelY
developed and used.
A very special rOle in this development il seen for multi-access
computer networks: they will become special market~l&ces where a
new kind of competitive evolution will take place, not only in
hardware, SOftware, and special services &1 "bought" from a
"utility," but &110 in roles, skills, working methods, and
employment ~yn&micl for the intellectual workers at the
terminalS.

iii

PREFAOE

The re.earch de.cribed in tni. report represent. conceptual,
de.iln, and develo~ment work bY a laree number of people) the
~rolram has been active as & coordinated team effort lince 1963.
The research reported here was a cooperative team effort
involving the entire ARC staff. The followinc is an alPhabetical
listing of the current ARC staffl
Geoffrey H. 8all, Walter L. Ba.s, Vernon R. Baughman, Mary G.
Caldwell, Roberta A. Carillon, David Cassere., Mary S. Church,
William S. Duvall, DOuglas C. Enlelb&rt, William K. Enllilh,
Ann R. GeOffrion, Martin L. Hardy, Jared M. Harril, J. D&vi~
Ho~~er, Charle. H. Irby, L. stephen Leonaro, John T. Melvin,
N. Dean Meyer, James C. Norton, Bruce L. Parlley, William H.
Paxton, Jake Ratliff, Barbara E. Row, Martha E. Trun~y, Edwar~
K. Van de Riet, John M. Yarborough.
The following former ARC staff members also contributed to the
researehl
Donald I. Andrews, Rocer D. Bates, David A. Evan., Stephen R.
LeVine, Stephen H. paavola, Helen H. Prince, Jon. F. Ru11tson,
Elmer B. Shapiro, F. K. Tomlin.

CONTENTS
ABSTRACT ••••••••••••••••••••••••••••••••••••••••••••••••••••• 1i1
PREFACE •••••••••••••••••••••••••••••••••••••••••••••••••••••••• v
LIST OF ILLUSTRATIONS ••••••••••••••••••••••••••••••••••••••••• ix
I INTRODUCTION •••••••••••••••••••••••••••••••••••••••••••••••• 1
A. General ••••••••••••••••••••••••••••••••••••••••••••••••• 1
B. Relearch A~proach and Strategy •••••••••••••••••••••••••• l
C. principal Ooncerns During the Contract period ••••••••••• 2
D. structure of This Report •••••••••••••••••••••••••••••••• )
II RESOURCES AND ACTIVITIES ••••••••••••••••••••••••••••••••••• S
A. Introduc~1on •••••••••••••••••••••••••••••••••••••••••• •• S
B. Re.aureel ••••••••••••••••••••••••••••••••••••••••••••••• S
C. AC~1vitie8 ••••••••••••••••••••••••••••••••••••••••••••• 19
III APPLICATIONS AND EXPERIENCE •••••••••••••••••••••••••••••• 2)
A. IntrOduction ••••••••••••••••••••••••••••••••••••••••••• 23
B. The Augmented Software Eng1neer •••••••••••••••••••••••• 24
C. The Augmented Manager •••••••••••••••••••••••••••••••••• 63
D. The Augmented Report-Writing Team ••••••••••••••••••••• 10)
E. The Augmented Presentation •••••••••••••••••••••••••••• 112
IV THE NETWORK INFORMATION CENTEW ••••••••••••••••••••••••••• 119
A. Overview of the ARPA Network •••••••••••••••••••••••••• 119
B. Some ot Our Pro8peetive Uses for the Network •••••••••• 122
C. Need for a Network Information Center ••••••••••••••••• 12S
D. NIC Development Activity •••••••••••••••••••••••••••••• 126
E. current NIC Plan •••••••••••••••••••••••••••••••••••••• 129
V CONCLUSIONS. RECOMMENDATIONS, AND PLANS ••••••••••••••••••• l))
A. Introduction •••••••••••••••••••••••••••••••••••••••••• 133
B. Conclu8ions Relevant to Other
Augmentation-System Deve1opers •••••••••••••••••••••••• 13)
C. our General orientation Towards Future Research ••••••• 146
D. Overview of Current
Augmentation Research Oenter Plan ••••••••••••••••••••• 1S0
Appendix AI User Features of NLS ana TODAS •••••••••••••••••• 17)
BIBLIOGRAPHy ••••••••••••••••••••••••••••••••••••••••••••••••• 195
DD FORM 1473 ••••••••••••••••••••••••••••••••••••••••••••••••• 199

vii

ILLUSTRATIONS
Figure 11-11

XDS940 COMPUTER FACILITY ••••••••••••••••••••••• 6

Figure II-21

SPECIAL DEVICES CHANNEL •••••••••••••••••••••••• 7

Figures 111-1 through 111-281
PHOTOGRAPHS SHOWING NtS DISPLAY
IN USE BY A SOFTWARE ENGINEER •••••••••••••• 3S-62
Figures 111-29 through III-56.
PHOTOGRAPHS SHOWING NtS DISPLAY
01 MANAGEMENT INFORMATION FILES ••••••••••• 7S-102
Figure V-11

"HERMAN MILLER" CONSOLE ••••••••••••••••••••••• 137

Figure V-21

ONE-PIECE CONSOLE ••••••••••••••••••••••••••••• 138

Figure V-3.

CURRENT CONSOLE DESIGN •••••••••••••••••••••••• 139

INTRODUOTION

General
The AUlmentatlon Res.arch Center (ARC) is a community ot
relearChers, lupported by .everal contract .ponlor.. It 1.
4edicatedto explor1nl the pOI.ibi11tie. tor aUlmentinl the
intellectual activitiel ot people working in complex
problem-.olvinl .ituationa.
By "augmentation" we mean increalinl the capability ot a
per.on or orcanilation to approach complex situation. and
identity problem. pre.ent there, to lain comprehenlion ot
the nature and context ot the.e problem., and to derive
.olution. latiltyinl liven constraints.
Such increaled capability may be retlected in any ot the
tollowinc way', falter and better com~rehen.len. the
pOI.lbi11ty ot IIin1nl a u.eful decree ot comprehenlion in
lituationa that were previou'ly too complex. talter and
better lolution., and the po •• ibl11ty of tindinl solution.
to probleml that previou.ly .eemed insoluble.

Relearch APproach and stratelY
ARC" orientationil baled on the tact that modern man 1.
contronted with problem. ~t increaainc complexity and urleney,
and the allumption tbat in att~cklnc the.e problem. the be.t
lenl-term paYOff. will more likely come throulh the
development ot more powerful problem-,olvin, tool. ot a
ceneral nature thanthroulh direct, piecemeal attack' on
.pecific proble•• ot immediate urleney,
Thil orientation wa. Ipelled out in 1962 1n a Plann1nl
document (Ref, 2) ~h&t provide~ ~he concep~u.l framework under
WhiCh ARC ha. been evolvln,. (Note. reterence number. are no~
conlecutive 1n thi. report, but reter to ~b. Chronolollc&l
bibl1olraphy.) our approach to aUlmentation re.earch ha. two
e •• ential a.pect •• ~be ext.rnllll&~ion ot lntellec~u&l
.tructur.sln .ymbollc torm, makine UI. ot hi,h1Y interactive
computer ly.te.l, and the apPlication ot a boot.trapp1nl _
.tra\ecy in there.earch prolram tor developine aUlmentatlon
.y.tem ••
The ~urpo.e ot externalilation via computer IYlteml 11 to
makelt po •• ible lor people to work with intellectual
structure. (.uah al computer prOlram. or hilhly
int.rconnec~ed bodie. of textual information) of much
creater .1ze and complexity than can be ettec~uall~ handled
with traditional ~echn1que., The a1m 1n de.1lninl the
computer .y.~em. hal -been to provide people with
the

I
INTRODUOTION

Sec~lon

lncrea.incly flexible and powerful way' of usinl .tructure.
Of .ymbol'~o repre.ent intellectual structures and 01
viewinl and mani~Ula~inl ~hese symbolic .tructure ••
The boot. trapping .tratelY hal been used in order to enlure
the tightelt PO"1blef.edbac~ 1n the procels of developlnl
aUlmentat1onaid. and in order to catalyze the re.earch
prolram by brincinc higher and hie her level. of
aUlmentation to the researchers them.elvel. All
aUlmentatlon aid. designed by ARC are~ntended for actual,
~ractical ule in ARClt.elf,and once implemented they are,
tor the mOlt part, uled heavily on a day-to-day balls,
C.

Prlncipal Concerns Durinl the Contract Period
DUrinl the period COYered bY thi. contract, three onloinl
procelle. reflected ~he principal concerns of ARC. the
fOllowinc lection. de.cribe the.e procelse ••
1.

NLSDevelo~ment

At the end ot the previoul contract period (lee Ref. 12),
the multi-u.er On-Line SYltem, NLS (whiCh had been
developed from prlviou •• inlle-u.er .y.teml), had been
carried trom the earlY dell In stale. throulh almo.t
complete implementation. Durinl the .ub.equent two yearl,
NL~ha. developed into an experimental operational Iy.tem
that 11 now in heavy routine u.e by the ARC .tatf.
ARO re.ources have been heavilY committed to lncrea.inl the
operational .peed and reliability 01 the many component. of
the .,.tem, improvinl the interaction otthe.e components
within the total .ystem, and improvinc and extend in I the
u.er features at the .y.tem.
2.

Evolution of Goal_
One u.ale trend that hal become evident durinl this periOd
1. a tendency tor .taft member. who are workinl on a common
proble.to cather around an NLS con.ole 10 a. to have
on~line acce.. I I a croup to the working 111e. that they
are u.inl in common. Even When working individUallY, croup
member. trequentlf .it at neilhborlnc con,ole •• 0 as to be
ablato converle about related ta.k. in prOlres ••
Thi. trend hal been reflected, throUlh boot.tr,pplnc, I I an
evolution ot ARO loal. trom the augmentation ot individuals

Seotion I
INTRODUCTION

to the augmentation of task-oriented teams.
MUCh thought has been put into deciding which areas of

research seem to offer the greatest promise for improving
the ability of aUlmente~ individuals to cooperate on a
common problem, ano during the next few years one of the
major activities at ARC will be the development of
team-augmentation facilities and techniques. Some of the
developments currently being eonsidered are discussed in
Section v.

ARPA Computer Network Participation
During the contract period we completed plans for
connecting ARC's computer facility into the ex~erimental
ARPA Network, which eventually will link the computer
facilities of about 14 computer-science research centers.
We feel that the Network is a significant step in the
evolution of augmentation technology, and we are working
with the other Network participants in orOer to ensure the
success of this experiment.
We have a&reed to provide a Network Information Center
(NIC) for the Network, and over the past two years we have
been committing an increasing portion of our resources to
the ~lanninl and development of NIC services. We expect
that ~he success of ~he Network experiment will be
significantly affected by the quality of services that the
NIe can provide.

Structure of This Report
The remainder of thiS report is divided into four major
sections and a supporting appendix. We have attempted to
describe What we have done and learned during the palt two
years, without elaborating either on the technical details of
our hardware/software system or on the past history of our
re.earch program.
These latter topics are covered in the references cited in
the Bibliography of thiS report. In particular, the
following may be Of interest:
The 1962 planning document (Ref. 2) provides the
conceptual background for our approach to aUlmentation
research,

I
INTRODUCTION

Sec~ion

The 1968 FJCO paper (Ret. 14) eives an overview of our
Augmen~ation Research Center,
The 1970 final report for another spon.or (Ret. 18)
di.culsel many technical details ot our s,ltem
implementation.
Seetlon II of th1s report describes the resources _. human,
orlanlzat1onal, har~ware, and sottware _. ~hat ARC hal
available tor its re.earch and discusses ARC's ong01nl
activities. This material is .upplementea bY APpendix A,
Which briefly describes several of the primary elements ot our
aUlmentatlon system.
Seetlon III is a colleetlon ot sUbjec~1ve descrlptions ot our
experience
augmented worker. 1n several ot ARC" central
activities. Two of the de.eriptlons (tor software encineerinc
and man&lement reaearch) are supported by illustra~ed
scenario. showine actual work in progress.

Section IV contains a description of the ARPA Network from a
u'er's standpOint and a discus.1on of some prObable, early
uS.S ot the Network. We point out lome of the service. that
Network participants will need in order to make effec~iv. ule
ot the Network and lndicate how we are attempting to .atilty
those needS through the Network Informatlon Center.
In Section V we discuss lome ot the conclu.1ons drawn trom our
relearch and indicate the directions 1n which we plan to
develop our re.earch 1n the fu~ure.

RESOURCES AND ACTIVITIES

A. Introduction

In this lection we describe the resources th&t have been
available to us during the past two years and the activities
we have undertaken to appl~ these resources to the pursuit of
our augmentation goals.
We use the term "resources" in tne broad sense to include all
the assets we possess as a team, including the followingl
(1)

Hardware facilities

(2)

System software

())

User systems

(4)

Personnel (human resources)

(5)

organ1zat1onal relationships.

Our major organizational relationships are to SRI and to the
ARPA Network.
The Augmentation Research Center operates at the grou~
level within the SRI Information Sciences Laboratory and,
consequently, has access to the extensive and varied
reaources available through a larie. diversifieC re8e&rch
organization such as SRI.
As an initial participant in the ARPA Network. we will have
access to all services that eventually become available
through the Network. The implications of this are explored
in Sections IVana V of this report.

Our other resources are ~i8cusse~ in some detail below, along
with brief descriptions of our major on-goin, activities.
B. Resources
1.

The Computer Facility
At the begining of tne contraet periOd the current ARO
computer facility was almost complete, and the basic
coniiluration has been relatively stable over the past two
Years. This Section briefly describes this facility
(diagrammed in Figures 11-1 and II-2) and discusses some of
the changes and additions made during tne contract period.
The most sig1n1ficant additions have been the ARPA

CONSOLE
TTY

COMMUNICATION
EQUIPMENT

MAGNETIC
TAPE

MAGNETIC
TAPE
CONTROL

CENTRAL
PROCESSOR
WITH TIMESHARING
HARDWARE

~""'---4 MAGNETIC
r-

TAPE

MAGNETIC
TAPE
PAPER
TAPE
STATION

16 Te etypes

I
I
I

16 K
CORE

CONTROL: RAD

16 K
CORE

SPECIAL
DEVICES
CHANNEL

TA-5919-3R

FIGURE 11-1

XDS940 COMPUTER FACI LlTY

T.V. Monitor
DISC
CONTROL

DISPLAY
CONTROL

DISC
FILE

5"C.R.T.

T.V. Camera

Keyset
Keyboard

DISPLAY
GENERATOR

12 NLS
Consoles

To
MIC

DISPLAY
CONTROL

DISPLAY
GENERATOR

EXECUTIVE
CONTROL
NETWORK
INTERFACE

ARPA Network

INPUT
DEVICES
CONTROL

LINE
PRINTER
CONTROL

LINE
PRINTER
TA-7101-3

FIGURE 11-2

SPECIAL DEVICES CHANNEL

Seetion II
RESOURCES AND ACTIVITIES

Network interface and an external core system.
A more complete description of the facility 11 contained
in Refs. 11 an~ 18.
a.

The Leased computer

Figure 11-1 is a block diacram of the facility as lea.ed
trom XDS.
A central processor with timesharing hardware operates
trom a 6hK memory in four bank. with 24-bit wordS and a
cycle tiMe of 1.8 microseconas.
On channels Sharing memory access with the CPU are three
magnetic-taDe arives, a paper-tape station, and
eommunication equipment for Sixteen typewriter
terminals.
A second memory bUSI provides ~1rect access to memory
for the RiDs (Rapid Acce.! Devices -- e.g., drums) and
the non-XDS portion of the facility, designated "Special
Devices Channel" in Figure 11-1.

There are three drums on the system, operat1nl trom a
common controller and aecesainl memory through an XDS
device called a Direct Accels commmunieation8 Ohannel
(DACO). EaCh drum has a capacity of 500,000 24-bit
wordS, a transfer rate of 120,000 words per .eeond,
and an average latency of 17 m1111seeon~s.
b.

Special Devices Channel
Figure 11-2 is a block diagram of the ~ortion of the
facility that has been put together bY ARC. The
following sections describe the major component ••
(1)

Executive Control
The executive control prov10es an interface to the
940 through the Memory Interface connection (HIe).
It acts as a multiplexer that allows asynChronous
access to core by any ot the six aevices connected to
it.
It includes extensive debugging and monitorinl &108,
allowing the monitoring of data and addresses tor any

Section II
RESOURCES AND ACTIVITIES

selected device and permitting "off-line" operation
of any of the devices.

(2)

Disc File System
The disc file system was put in operation in August,
1966. It consists of a Bryant Mo~el 4061 disc file
and alsociated controller. The system hal a capacity
of 32 million words, an average access time of 18S
milliseconds, and a data transfer rate of 43,000

words per second.

The disc controller was designed and built by Bryant
to interface with the executive control.
Specifications for the controller were develope~
jointlY by Bryant, Project GENIE at UC Berkeley, and
ARC.
(3)

Display system
The diSPlay system consist. of two identical
SUbsYlteml, each with a diSPlay controller, a display
generator, and .ix high-resolution S-inch CRTI. A
closed-circuit television system carries display
1mage. trom the CRTs to television monitors in tne
working area.
The display controllers were desilned and built by
ARO. They access an~ procels "command tables" that
are resident in 9kO core.
A command is roughly assoc1ate~ with a user and
pOints to a "~isplay list" in the user's core
space. The display list in turn pOints to buffers
containing actual display instruetions (commands
to the display generator to prOduce imltes).
~i.play controller han~les all core accelainl.
inclUding memory mapping for tne user"core
apace. xt pa.ses the display in.tructions along

The

to the display generator.

The display lenerator. and CRTs were purchased from
Ta8ker Instruments to ARC's specifications. They
have general character and vector capabilities.
Presentations for each

the six ORTs are

Section II
RESOURCES AND ACTIVITIES

generate~ sequentiallY,
~he display controllers

CRTs at a liven time.

ana unblank sienall from
select one or more of the

A h1gh-re801ut1on (87S-1ine) closed-circuit
television Iystern transmits ~1splay pictures trom
each CRT to a television monitor at a correapond1nl
NLS console.
(4)

Input Dev1ce control
In addition to ~he television monitor, each con.ole
has a keyboard, a binary keyset, and a mouse.
Appendix A Cescribes the use of these devices.
The state of these input devices is read by the 1n~ut
device controller at a preset interval (about )0
milliseconds) and written into a fixed table in 940
core.
Bits are added to information from the keYboards,
keysets, and mouse switches to indicate When & new
ch&raeter hal been received or When a Iwitch haa
cbanle~ state during the sample periOd.
A new
ch&raeter or switch change causes an interrupt to
be issued at the end of the sample period.
Mouse coordinates are dilitized by an AID
converter an~ formatted by the input ~ev1ae
controller as beam-position instructions to the
display generator. A user procr&m may include the
mouse coordinates, as wr1tten by the input ~ev1ce
controller, al part of a ~1spl&Y list. Tnis
allows the mouse ~olition to be continually
di.played with no attention from the CPU and no
perce~tible delay to tne u.er.

(5)

Line Printer
The line printer 1s a 96-character drum ~rinter
leased from Data Pro~ucts Oorporation (Model
M600-11Al. With the 96 characters, printing Ipee~ il
340 lines per minute.
The line ~r1nter controller proceases print butters
Of arbitrary length that have been let up in core by
a controlling program (lingle-line buffer. are

Section II
RESOURCES AND ACTIVITIES

normally used).
(6)

Network Interface
The network interface provides communication between
the 940 and an Interface Message Processor (IMP) on
the ARPA Computer Network. The int.erface operates
from message buffers in 940 core. Messages to the
Network are read by the interface from these butfers
and transmittea to the IMP. Similarly, messages
received trom the IMP are written 1nto buffer space
in 940 core. Instruetions from the 940 enable the
system for receiving messages and control the sending
of messages. A "linked-buffer" scheme permit.s
flexible memory allocation.
The interface message processor and its
commu"ications protocol are discussed in detail in
Ref. 19.

Typewriter Terminals
At the beginin, Of the project the onlY terminals in use
(other than the display consoles) were Model 33
Teletypes. Since then we have been experimentinc with
~ifferent type. of terminals. lOOking for improvements
in speeo, print quality, and portability.
The newer terminals now in use, and some Qf their
features, are briefly Oescribed in this section.
It ShoUld be remembered that tbe only terminals we
have considered are those with upper- ano lower-case
print and fUll-~uplex o~eration.
(11 The Model 37 Teletype was one of the first
terminals added. and three are now in use.
It operates at 15 characters per seeond (as compared
to 10 eharacters per second for the MOdel 33) and has
excellent print quality and rei1ability.
It hal a high noise level and is laree and heavy.
(2)

We have four GE Terminet-300 terminals in use.
These have

.wi~ch-seleetab1e

rates Of 10, lS, and 30

Sec:t.ion II
RESOURCES AND ACTIVITIES

characters per second. The~ nave a cha1npr1ntinl
mechanism that is relativel~ Quiet and have good
print quality when in adjustment.
These terminals seem to require more freQUent
maintenance than any others in use, but we have early
models and the~ may improve in later produc:tion.
(3) The best terminal we have found for portability is
the Execuport, manUfactured by Computer Transceiver
Systems.

These terminals are used by our staff for remote
operations, usually in a staff member's own home, and
come in a portable case complete with acoustic:
coupler and weighing only 26 pounds. They have
switch-selectable rates of 10, 15, and 30 characters
per second.
The thermal print mechanism is very quiet in
operation but print quality is poor; characters are
made from a S x 7 dot matriX.
d.

MOdifications in Progress
mo~1ficat.ions to the facility that will provide
significant improvement in service are now heing
implemented. These are an external core syst.em and
faster drums. In addition, an accurate clock system is
being added.

TWO

(1)

External Core system
An external core system has been completed and will
be integrated into the facility in the near future.
It currently consists of a lingle 32,OOO-word bank
with access switching to allow access by u~ to eight
devices. provisions are inclUded in tne design for
expansion to 16 devices and two core banks of 64,000
worC1s eacn. The core cycle tim-e is 1. S microseconds
and the word length 15 24 bits.
The primary purpose of this core system il to provide
storace for display buffers, the network interface,
and the line printer. These are tne devices that
need constant buffers for relativelY long periods of
time and therefore require "frozen pages" when

Section II
RESOURCES AND ACTIVITIES

operating from 940 core -- a 'ign1ficant factor in
limiting system response, since tbay take up space
that could otherwise be used for swapping.
(2)

Faster Drums
From system response stUdies (Ref. 18) it is apparent
that a primary factor in re8ponse is the swapping
ban~w1dth.
TO improve response (an~ add More users),
we are in the process of replacing the XDS drums with
Univac FH-432 drums.
These drums rotate at 7200 RPM, ~1ving a transfer
rate of 365,000 words per second (as compared to
120,000 for the present drums) and an average
access time of about 4 milliseconds.
In addition, we are formatting the new drums in a
way that will allow a page transfer to begin at
any position on the drum. Since a 20h8-word page
fills two-thirds of a band, this will give an
average page transfer time of about 8
milliseconds.
The interface for the drums will be deSigned and
built by ARC. It will connect to the 940 through a
second Memory Interface Connection (MIC). replacing
the current RAD-DACC combination shown in Figure
11-1.

())

Clock System
An accurate clock system is being added to assist us
in system measurements.
This eloek Iystem provides two type, of time
information -- absolute and relative -- that are
written into fixed location. in 940 core at regular
intervals. The long-term drift on the clock will be
less than 1 second in 250 days.

Software Systems
The central foeus of software aetivity at ARO i. tne
evolutionary development of the On-tine SYstem (NtS). This
takes place within a rich environment of .oftware systems.
many of which were created .pacificallV to aid in its

Section II
RESOURCES AND ACTIVITIES

development. The
major 8ys~ems.
a.

f~llow1ng

i. a brief

~elcript1on

of the

The Timesharing System (TSS)
MOlt basic to the o~eration of NtS. as well as all our
other software systems, is the timesharing system (TSS)
running on the XDS940.
TSB was originally developed by Project GENIE at UO
Berkeley, but responsibility for maintenance of the ARC
version currently lies with the Center itself. Nt! runs
as a sUDsystem un~er TSS, ana users allo have accels to
other subsystems such as the NARP assembler, KDF file
storage Iystem, and DDT debugging system.
The 8u~port of new har~ware and improved res~onse to the
NtS user are the major areas of improvement in TSS over
the past two years.

Software Architecture
(1)

Intro~uctlon

The development of NLS has been facilitated greatly
through the use of a powerful complement of lanluagel
and compilers, mOlt of which were designed at ARC.
The languages used range in generality from the NARP
assembly language through a collection of
special-purpose languages (SPts) unique to NLS
implementation. Their major features are discussed
brieflY below.
(2)

NARP

A few parts of NtS can be most conveniently COde~ in
assembly language (e.g., the data page an4 tne
diSPlaY-buffers), and tor these the NARP assembly
language is used.
Also, tor historical reason., the timeSharing system
(TSS) and most ot its SUbsystems (e.g., KDF and DDT)
are coded in NARP.

Section II
RESOURCES AND ACTIVITIES

())

MOL940
MOL940 (or .imply MOL) is a machine-oriented language
for tne XDS940 and wal created by ARC to a1d in the
programming of NtS.
MOL combine. the flexibility of assemblY language
with the algorithmic clarity ot higher-level
procedure-oriented languages. MuCh of NL! 1s coded
in ~OL.
During the contract period MOL has been SUbstantiallY
rewritten to improve its pertormance and provide new
programming features. The current MOL compiler was
produeed Using the new version of Tree Meta
(described below); consequently. the MOL compiler now
generates binary machine code directly rather than
producing assembly-language code as an intermediary.

(4)

Special-purpose Languages (SPLs)
Many of the higher-level operations ot NtS are
carried out by programs written in one of a set of
special-purpose languages (8Pts). Each of these
languages 11 translated into machine COde by a
custom-made compiler produced with the Tree Meta
system.
Each SPL represents an attemPt to formalize a
particular function of NLS, aiming at a syntax
appropriate to the data base and operations required
for NtS, while at the same time embOdying the
potential and peCUliarities of the XDS940 computer.
The four SPLs currently in use are the input-feedback
langUage, the structure-manipulation langUage, tne
content-analysis language. and the
strine-construction language.
Detailed ~elcr1ption8 ot the SPLS will be found in
Appendix D of Ref. 18.
AlthOUgh extensive chanles in the SPLs are planned
for the near future, no basic conceptual change. were
made during the contract periOd.

Section II
RESOURCES AND ACTIVITIES

(5)

Tree Meta
Tree Meta i5 a compiler-compiler developed at ARC; it
is used to produce compilers for MOL, for all the
special-purpose languages, and for itself as well.
Section IV-C-2 of Ref. 18 con~ains a brief overview
of the current version of Tree Metaj a more detailed
description is in preparation for release as a
separate report.

NUTILITY
TO aid our software engineers in maintaining the
aoproximately lS0 symbolic and binary files that make UP
NLS, a special subsystem called NUTILITY has been
developed.
This SUbsystem can archive or retrieve any of these
files. compile or produce listings for any of the
source-code files, and load the entire NLS system or any
part of it, requiring programmer interVention only in
the event of errors that NUTILITY cannot handle itself.

User Systems
This section brieflY describes our principal on-line user
subsystems; more complete deseript10ns are contained in
Appendix A.
a.

On-Line System (NLS)
The On-Line System, NLS, as currently implemented, is &
highly SOPhisticated system oriented toward the on-line
construction. editing, and viewing of files.
NtS is a SUbsystem of the timeSharing system described
above. Its size is currently about thirty thousand
machine instructions, of which about half make up the
mOlt frequently used portions. The source languages
used are NARP, MOL940. and the SPLs.
A complete description of NLS, incluOing program
Oocumentat1on, is in Ref. 18.

Section II
RESOURCES AND ACTIVITIES

Typewriter-oriented Documentation-Aid System (TODAS)
In response to growing pressures to make access to our
on-line files available to Network participants, as well
as to members of our own staff working at remote
locations, we develo~ed a new SUbsystem called TODAS
(Typewriter-Oriented Documentation-Aid System).
TODAS uses the same structure for working files as NLS
and provides most of the same editing and
view-specification capabilities, along with a few
special features of its own. Thus, users can freely
move from one type of terminal to another without losing
access to any of tneir on-line WOrking records.
TODAS offers our on-line users the possibility of
trading off speed of operation for freedom of location.
It also makes 1tpossible for us to increase the number
Of on-line users that can be serviced simultaneously,
since a TODAS user places less heavy demands on our
computational resources than does an NLS user.

output Processor (PASS4)
The output Processor (alSO called "PASS4" for historical
reasons) i8 a program for formatting on-line text files
for output through a variety of devices inclUding line
printers, paper-tape-driven typewriters, and computer
output to microform (COM) devices.

Personnel
The linal, critical element of ARC's resources is its staff
of prOfessional researchers and support personnel. The
experimental nature of our work requires high-caliber
individuals who can function effectively in our team. learn
quickly to work with our systems &n~ methOdologies, and
progress creatively along with the rest of the team and its
products.
our staff members need to be able to a~apt to the
rapidlY changing ARC environment and to persevere
through very disturbing periOdS Of system service level
fluctuation.
Our selection of people for specific taskS is influenced
not only bY skill. already developed. but also by
,

Section II

RESOURCES AND ACTIVITIES

potentials for further develonmeni.
Effective utilization of our human resources requires a
careful balance between select1nc those people most
likely to get critical tasks ~one well and tnose whose
~eveloped capabilities will be straine~ by the tasks
they undertake (and hopefully extended in the process).
In ARC's earlier years our primary need was for individuals
skilled in tool buil~ing~ with only secondary importance
assigned to methOdology development skills. ThU8, most of
our ~ar11er researchers were system-oriented software an~
har~ware engineers.
As the systems developed became more generally usetul,
providing aids and service levels beyond the system
engineers' basic needS, we entered a maturing phase of
facing the challenge to use the system for a broader range
of tasks.
PeOPle nave recently been adae~ whose interests focus on
the stuay of tne user system itself~ on use of the
system for management purposes, an~ on its role in
supporting the Network Information Oenter.
These people have brought different needs an~
perspectives into the grou~, directly aiding the ttesign
of many system improvements. Interaction at the
day-to-day system development level has provided & rich
learning exper1ence tor most people, particularlY in
technical area. they might not otherwise have learned
mUCh about.
This diffusion of knowle~ge in areas SUch as system
design, system builOinl, system analysis, and management
adds new perspective to each perlon's approaCh to
prOblems in hi. own area. of specialization.

II
RESOURCES AND. AOTIVITIES

Sec~icn

At present we have a full-time Itaff of 25, constituted AI
follows:
Prcfesl10nal ••••••••••••••• l8
Supervisory.....

Softwlre •••••••• 11
Hardware • • • • • • • •

Other •••••••••••

Non-professional...........
Technical.......

Clerical • • • • • • • •

c. ActiVities
1.

IntroQuction
Tbis .ection outline. the nature and purposes of the major
activ1tiea carrieO on durinl the pa.~ two years of our
project. It was the pursuit of theae activities that
produced tne developments, experiences, and conelusions
disculsed in the other sections of this report.
The greate.t portion of our resources were allocated to the
basic ARC bootstrapping pursuit, which consists of, these
major activities:
(1)

Development and operation 01 our .erv1ce s,.tem

(2) D.evelopment of methodologiel for harnes.ing the
user features offered by the service s,stem
(3)

APplication of the •• aUlmentation tools ana
to the pursuit Of all our activ1tles

~echniQu.1

(4) A.sessm.n~ Of our overall augmentation ay.tem to
guide it. further evolution.

Section II
RESOURCES AND ACTIVITIES

other major activities received considerable attention
and resources:

TWO

(5)

Oonnection of our Oenter into tne

(6)

Develo~ment

Network.
2.

Develo~ment

and

ARPA

Network

of an Information Center for the

operat~n

of Our service system

The coordinated develo~ment of hardware and software
aspects of our augmentation system. which has been under
way since 196), was continue~ w1th particular em~ha.11 on
activities aimed at preparing us for our role in the ARPA
Network.
We have committed a sUbstantial portion of our resources to
improving the reliability and capacity of the service
system and will continue to do 80, a major milestone beinc
our ~lanne~ transfer to a PDP-10 computer this fall.
Another major effort hal been preparation for expanded
remote-worker eapabilities. both to fac1litate use ot our
system by other Network participants and to continue our
efforts to increase the flexibility of workinl arrangements
for member. of our own research commun1ty.
There 18 alreadY one member of our team (a software
encineer) who work. remotelY from hi. home in sonoma
county (about 100 miles from our Center), and we bave
plans to exten~ this capability to other members a8
conditions permit.

Development of Methodologies for Harne.sing the User
Features Offered by tne Service System
It hal lone been part of our ~lans to apply toward this
activity relourcel com~arable to thOle for the .erv1ce
system development activity, but unloreseen difficulties 1n
the latter area have force~ UI to divert more of our
energies to it than was oricinally anvi8
ed.
H6wever. many methodolocical developments have ~een
evolving more or less naturally al individuals adapt the
features of the service system to their particular needs.
The stronlest ,uch evolution has taken place within the
area of software engineering, which 1s the focus of

Section II
RESOURCES AND ACTIVITIES

consistently heavy activity by many of our people.
In one specific area _. management system ••• we have
enga~ed in an explicit effort to develop improved
methodology. Th11 hal been tunde4 separately bY a contract
with the Rome Air Development Center, Which has enabled UI
to ap~lY one or two fUll-time people towar~ this Management
Systems Research activity for the past two years.

4. APplication of AUgmentation ToolS and Techniques to the
Pursuit of All our Activities
Our augmentation system is in daily use by most members of
our staff. Detailed discussions of several exam~lel of
this use are given in Section III.

S. Assessment of Our Overall Augmentation System to Guide Its
Further Evolution
One of the basic requirements for carrying out a
bootstrapping o~erat1on is to maintain constant awareness
of the status of that operation so as to be able to make
rational decisions about what developments Should be
undertaken next.
We have made some attempts to quantify this process through
the taking of system performance measurements and the
Simulation of various existing and proposed system
configurations. However. most of our work in this area
still has a very intuitive character, and we have oeen
hampered in our efforts to improve on this bY the necessity
for committing so much of our resources to basic
service-system development activities.
6.

Connection of our Center into the ARPA Network
To make it pOSSible for ARC to participate in the ARPA
Network (8ee Section IV). we had to design. build. and
install a device to interface our computer facility to a
Network Interlace Mesaage Processor (IMP). Thi. Network
interface is described in section II-8-1-f.

Development of a Network Information Center (NIC)
In ~reparinc to f111 our role as Information Center for the
ARPA Network. we have been involved in developing the tools
and methOdologies that we will need in order to provi~e an

Section II
RESOORCES AND ACTIVITIES

increasingly on-line, special-purpo.e library for a widelY
distributed clientele. The high technological base of this
Network experiment demands that we try to harness a8 much
as possible of th1s teehnolog~ for the Network Information
Center 10 that this service will be likely to enrich the
whole experiment.
In addition to investing our resources in special-purpose
capabilities for the NIC, we have felt compelled to
increase our investment of resources in basic
service-system development 10 as to be able to supply a
better level of service to Network participants,
We had to get our system architecture, our compiler
languages, our documentation, and our hardware
configuration into a state where we woulO be able to
expan~ our user-carrying capacity rapidly.
This led to
a number of major efforts:
(1)
A series of significant architectural and
compiler changes within our software systems

(2) Several rather intensive trial designs for
alternate expanded-capacity system configurations
(3)
A concerted effort in developing computer aidS
for analyzing performance characteristics of proposed
s~stems.

These efforts culminated in a decision to move our
systems onto a PDP-10 computer late tnis fall, and we
are currently involved in the leaSing, purchasing,
contracting, engineering, fabricating, and programming
activities necessary to accomplish thi. tran.fer.

III
A.

APPLIOATIONS AND EXPERIENCE

Introduction
This section consists of relatively informal accounts
deleribing the apPlication of our augmentation systems to
several areas of our own work While attempting to convey some
feeling for what it is like to work within an augmented total
system.
Section 111-6 was written by Charles H. Irby, an ARC software
engineer. It describes in considerable detail the waYI in
Which an augmented software engineer can exploit our com~uter
'Yltem. to help him in the continuing development of the.e
same systems.
In addition, Section 1II-B serves as an introduction to our
On-Line system, NLS. It is systematicallY illustrated with
~hotographl of an NLS display, showing actual sequences of
displays that the software encineer WOUld see a. he worked.
(Readers who are not familiar with NLS will find a
description of its user features in Appendix A, which
inclUdes a glossary of .pec1al NLS terminology.)
Section 111-0 deals with "augmented management" and wa.
written by James C. Norton, who headS our Management Systems
Re.earch Activity and is also involved with carrying out much
of our o~erational project management.
This section, illustrated with display photograPhs like
those of Section III-B, shoWS how lome of the mOlt
sophisticated features of NLS can be put to ule in a field
outside Of softWare engineering. SpecifiC applications to
project eost accounting, eo.t estimation, work Planning,
and other areas are covered.
The discussion develops a total-system concept of the
meanings of "management" and "management augmentation" and
reveals how augmentation interact. with various a.pects of
ARC.
Section III-D describes our use of augmentation sYltem. in
writing, editing, and prOducing report.. The author of this
section, David Casseres, il ARO" technical writer and has
been centrally involved in ARC report writing since the
inception of this contract.
Here we lee the u.e of augmentat10n systems 1n & field
Where it is difficult to applY them, becau.e the ~roblems
of technical writing are 80 many and so dependent on
individuals,

Section III
APPLICATIONS AND EXPERIENCE

It appears that although the benefits ot augmentation in
writing, editing, ana producing reports are con.iderable,
the most sicnificant benefits come from the u.e of a very
close team-collaboration method, which would be virtuallY
impossible without augmentation.
Section II1-E was written by Douglas C. Encelbart and covers
the augmentation of communication between a speaker and his
audience.
Thi. kind of communication, Which we have used for
explaining aspects of our work to audiences rancing from a
single person to thousands, 1s potentially one of the most
exciting areas of application for augmentation technology.
B.

The Augmented Software Engineer
One of the central objects of our augmentation research has
been to develop special tools and working methodS tor
augmenting the design and implementation Of our system
software.
Section III-B-l belOW outlines the general augmentation
needs of a 80ftware engineer and the aids provided at ARC
to meet these neeOs.
Section II1-B-2 describes the ways in which our software
engineers actually use the systems we have been developinl
in their daily work.
We pay particular attention to the use of the
system-guide file, SYSGD, which 1s central to the
software-engineering augmentation sy.tem.
The use of SYSGD i . illultrateO with photographs of an
ARC interactive Oisplay. Ihowing the views seen by the
software engineer as he works to implement a new NtS
feature, uBing SYSGD as & reference.
l.

General Considerations
The augmented software engineer nee4s tne following minimal
eapab1litie.,
(1) The ability to rapidly accels,
manipulate the source code

un~erstand.

and

Section III
APPLICATIONS AND EXPERIENCE

(2)

The ability to easily compile the source

co~e

(3) Easy acce.8 to appropriate loading and debUlging
capabilitie ••

The NtS, TODAS, NUTILTY, DDT, and di.c archive .ub8Y8~em.
together with the SYSGD source-code file directory provide
the ARC software engineers wi~h the,e capabilities.
To the ARC lottware engineers, the aspects of Nt! that are
perhaps of most importance are the ability to find a
particular place1n the code or documentation Quickly an~
then to change it easilY. Our co~e ana documentation tiles
are normal NtS text files, and the languages that we use
have been specially developed to be compatible with the NLS
system.
These language, are all 8tring·base~, and translation is
independent of the hierarchical .tatement structure.
This permits the programmer to u.e structural
conventions to make his source-code text easier to
understand and manipUlate.
They allo allOW NLS link. to be Uled for identifier.,
thUS permittinl one to u.e the "jump" commands to follow
lubroutine calls in the source cOde. In addition, level
clippinl, line truncation, and so forth may be u.ed to
control the depth ot detail Of the cOQe and as,sociated
documentation that one seel. These are very important
factor. in quiCkly finding a specific location (or
.eries ot loca~1on.) in a file.
content-analysis filterinli8 often used to locate
references to variables or SUbroutines or to locate a
partiCUlar piece of COde (tor example, code containing a
syntax error reporte~ by the compiler). The content
analyzer il al.o used to locate chanle. that have been
made to a file by a .pecific prorrammer or dUring &
.pecif1ed per1o~ of time by scanning the automaticallY
maintained "statement signatures." These .icnatures
contain the date of most recent modification for each
statement and the1nitials of the user who made the
modification anO may al.o be used without the content
analyzer to .ee Who wrote (or la.t modified) each
.tatement ot code or documentation and When he did it.
When viewing a secment of a tile, the softWare engineer

Sec~ion III
APPLIOATIONS AND EXPERIENCE

must be able to easilY mOdify the text of the file.
exten.ive editing ~ower of Nt! make. this possible.

The

The ability to easilY effect changes to various textual
and structural entities and to make multiple s~rinl
sUbstitution. over structural entities While controlling
the selection of statements tor the substitution via
level clipping, content analysiS, keyword reordering.
and 10 forth gives one great flexibility and power while
editing.
In addition to being able to modify the code and as.ociated
documentation quiCkly, the softWare engineer may compile
(or cross-reference) hi. code files directly from NtS.
Once again, he may use the statement-selection meChaniSMs
of NtS to control what the compiler get. as input. This
might be done, for example, to limit the compilation to
~u.t one branch of a tile (one specified Itatement and all
itl sUbstatements), thu. making it pOSSible to have in a
sinl1e file source code written 1n .everal different
languages.
We also have available as another SUbsystem the project
GENIE on-line loader and symbOlic debugger, DDT, for
testing and debugging the results of our ehange. to the
code files. Although DDT works at the as.embly-language
level, it is a powerfUl ~ebugler with such features a.
multi~le breakpoints, symbolic ad~reslinl,
single-instruction execution, conditional breakPointl, and
10 forth.

To aid the software engineers in maintaining their
a~~roximatelY one-hunOred-fifty or 10 symbOlic and binary
files, a special .ubsys~em called NUTILITY was developed.
Thi • • ubsY8tem is able to archive, or retrieve from
arChive, any of the files, to compile or produce lilting_
for any of the ,ource tiles, and to load the entire system,
requiring human intervention only 1n case ot errors.
Central to our collection of source-code tiles is an
on-line file called SYSGD. It containl the followin,.
(1) A schematic diacram Of the overlay Itrue~ure of the
Nt! system. The overlay. represent (al tar &s
~ract1cable) functional areas of the system, e.I.,
parameter specification, structure manipulation, and 10
forth.

Section III
APPLIOATIONS AND EXPERIENCE

(2) Links to other f11e8 that describe the architecture
and logic of the system.
(3) An overlay index li.t1nc all overlays, with the
following information about each overlay:

(a) A link to the file conta1ninc the lource code
for the overlay.
(b)
Information about where it runs in core, how
large it is, and where it i8 in the archive.

(c) A list of all the ~roeedure8 in the overlay,
with one-line functional descriptions and with links
to the code and documentation in the source-code
file.
A procedure index with a categorical listing of
according to function. The NtS keyword
system can be used on this index to retrieve a list of
~rocedures (with links to the source COde and
documentation) when a set of categorie. has been
.elected.
(4)

~rocedures

(5)

system.

section where one may document bugs found in the

(6) A section where one may record ideas tor improving.
the sYltem.

Because of ~re8ent file-space problems, it is not pos.ible
to keep the SYSGD file, the a.lociated documentation tiles,
and the source-COde files on line at all time. (they are
generally kept in a disc archive). This Situation renders
the SYSGD file leiS useful than it would be it ~he tiles
were alway. readily accessible.
The combina~ion of the capabilities discu.sed above gives
the ARC software engineer the ability to easily manipUla~e
the NtS system to fit the needs ot ARC experimentation,
thUS creatly increasing his own abilities as a loftware
engineer. These capabilities would be creatly enhanced by
the addition to NtS of an interactive incrementallanluage.
Thi. would eliminate the time now spent on com~111nl ~art.
Of the entire system and loading them in order to test
Changes ma~e in the lource code of the system, and would
allow one to debul at the source-COde level.

Section III
APPLICATIONS AND EXPERIENCE

The Aucmented Software Engineer 1n Action
a.

Introduction
This section i. in the torm of a Icenario, delcribinl
how a loftware engineer works to 1m~lement a new NtS
feature by manipulating files of text (both
~ocumentation and actual code).
The reader is
encouraged to pay 8~ecial attent10n to the following:
(1) ~he eale with which one can move within and
among tile 1
(2) The languale. that have been developed for
particular purposes and the way in Which they fit
into the NLS framework

()
The eale with which one can locate
and modify it

~esired

cOde

(4) The delign of the NLS .y.tem-guide tile and the
way. in which it can help the software engineer
(5) The use of the NUTILITY SUbsystem to
automatically archive. compile, print, and
cross-reterence files a. well as to load new versions
of the system
(6)
The use of the DDT debugcing program to te.t and
debug additions to the system at the machine-language
level.

Pleale note al.o that one movea within and among files
by means of "Jump" command.. At certain times when
jumping, the u.er hal an opportunity to chanle the
parameterl ("VIEWSPECS") that control the selection of
information to be di.played on the acreen. For example,
in the jump that occurs between Figure, 111-3 an~ 111-4
below. a "branch-onlY" parameter i8 set and the
level-clipping and line-truncation parameters are let to

"ALL".

one may jump to a selected statement, to a statement
that is structurallY related to the selected
statement, to a statement having a eiven name, or to
a statement speCified by a "link" (a textual
con.truct that .ymbo11cally point. to a particular

Section III
APPLICATIONS AND EXPERIENCE

statement within the file or within another file).
In a~dition, stacks ot display-start statement
identifier. and VIEWSPECS are maintained for the last
sevaral locations viewed within the file an~ tor the
last several files aece.se~, &n~ jumps may be m&~e
relative to these stacks so
to restore a previous
view.

Notes on Illustrations
In ~elcribinl the ~i.play views and the processes theY
reflect, we aSlume that the reader is familiar with the
user feature. of NLS to the extent that they are
ex~la1ned in Appen~ix A.
Appendix A also contains a glossary of soecial
terminology,

Nt!

In examining the photograPhs, note that the name of
an NLS comman~ appear. at the top of the display;
this is the comman~ currently specified bY the user.
ImmediatelY to the left of this "comman~ feedback
line" is a small block of text called the "VIEWSPEC
area," where VIEWSPEC parameters are di,playe~ on two
lines,
When the VIEWSPECS are ~isPlayed in small .
characters, they are currently 1n effect; when
they are enlarged, it mean. that the user has just
let them and they will co into effect when the
display is next re-created,
The upper line shows

~he

current level-clipping

and line-truncation parameters (.ee Appendix A tor

eX~lanat1on).
The lower line in the VIEWSPEC area
.hows code letters indicating the status ot
various display features that are controlle~ by
VIEWSPECS.

Scenario and lllu8tration.
Notec The illustrations for this scenario are grouped
together, beginning on page 35.
We log into the t1melharinc system, increase our drum

Sec~ion III
APPLIOATIONS AND EXPERIENCE

allocation, and en~er the NNLS (New NLS) IUb.ys~em
eiving a set of initial. and & u.er name (lee Fieure
III-l). The NLS display comes u~ (aee Fieure 111-2),
and we load the NLS system-guide file, SYSGD, with level
anC 11ne truncation let to one and with blank 11ne.
dilplayed between statements (see Fieure 111-3).
The major sections of the SYSGD tile (lee Fieure 111-3)
are as follows.

Program Overlay Structure

(1)

A diagram showing the overlay structure used in
the current implementation of NLS (see Figure
111-7 below).
Global Documentation

(2)

Links to other files that describe the tile
structure, a.sign PhilOSOPhY, system architecture,
and commonly u.e~ terminology of the Nt! system
(lee rieures 1I1-~ and 111-5).
overlay Index

(3)

A list of all Of the overlays in the system (each
overlay represents & funct10nal area olthe
Iystem) with pertinent data about each overlay
(lee rigures 111-8, 111-9, II1-24, 111-25, and
11%-26 below).
Catecoriel tor Procedures

(4)

Catecorical lilt of procedures, by function, to be
used with the keyword retrieval .Yltem.
tist of Known BUI'

(5)
A

(6)

~lace

where bUll may be recorded.

Map of Symbols
A map of symbols to be u.ed with the DDT deouI11nl
.y.tem.

Section III
APPLICATIONS AND EXPERIENCE

Thoughts for

(7)

Im~rovements

A ~lace where idea. about the further aevelopment
of NtS, TODAS, and NUTILITY may be recor~e~ (see
Figure II1-6).
The initials ot the creator (or last modifier) an~ the
date and time of creation (or mo~ification) are stored
internally as the "signature" of each Itatement. Since
statement signatures are available for dis~l&Y upon
request, one can easily determine who made or last
commented upon a given statement (see Figure 111-6).
TheSYSGD file is basically a directory file with a
sufficient amount of descriptive material so that one
can use the various retrieval tools of NLS to locate any
~e.ireQ procedure or documentation.
To illustrate how the SYSGD f11e is used, we go through
the steps necessary for a programmer to implement a new
command in NtS. The new command will be called
"transpose" and will interchange two textual entities.
The command language for u.ing this new command will be
modeled atter that of the "move" command.
Let UI begin (Figure 1II-7) with the diagram of the
Nt! overlay structure. From the Ilobal dOCUmentation
of the system we know that the main-control (mnctrl)
overlay consist. of the code that implements the
commanC2 language for NL! commands. We therefore use
the "Jump to Vectorlabel" command to 10 to the branch
within the overlay index branch that contains
information about the mnctrl overlay.

This

in~orm&tion

inclUdes the following (lee Figure

111-8)1
(1) A link to the source-code file for this
overlay
(2) A list ot all Of the procedures within the
overlay
(3) Brief documentation a. to the functions of
each procedure
(4)

Links to each procedure's source code.

See

Sec~ion III
APPLICATIONS AND EXPERIENCE

Figure 111-9; whereas Figure 111-8 shows only the
first line of each statement, Figure 1II-9 shows
all line. -. otherwise the two displays are the
same.
If we take the link to the "we" proce~ure (Figure
111-10), we see the top-level code for the NLS
command language, written in one of the
Special-Purpose Languages (see section II-S-l)
designed for this use. Jumping to the "move" command
code (Figure 111-11) an~ increasing the
level-clipping parame~er by one, we see the top-level
command-language code for the "move" command. Since
this is to serve as a model for our proposed
"trans~ose" command, we will copy the branch and make
the necessary changes to it.

The necessary changes are SUbstituting the string
"Transpose" for the string "Move", "qt" for "qm",
an~ "tr" for "m" (see Ficure 1I1-12).
If we look at the code for the "move" command (Figure
111-13), we see that it makes calls on routines in
the parameter-specification (prmspc) overlay to allow
the user ~o make selections on the screen. and to
routines in the text-editing (txtedt) overlay to
implement the algorithms for the commands.
Since the syntax for a procedure call permits an
entire link to be used in place of & procedure name,
we can use the "jump to link" command to see What
these routines in txtedt actually do.
If we jump "up" from the procedure pOinted to bY the
link (Figure 111-14), we see that once again this
code can act as a model since it only implements the
delimiting of the selecte~ entities and goes to
another routine, movetx,to actually move the text.
We therefore copy this branch also and ma~e the
necessary changes for the "transpose" command (lee
bottom of Figure II1-14J Figure 111-15 is the lame as
Filure 111-14 except that all lines are shown).
The necessary modification. are changing the
procedure names to correspond to our code in the
mnctrl overlay and changing the name of the
routine tha~il called to actually dO the

Section III
APPLICATIONS AND EXPERIENCE

tranl~oI1tion.

The "jump to name" comman~ takes us to the movetx
routine (Figure 111-16), which again serves as a
mOdel tor our new routine, trantx. After out~uttinl
the file we do "Jump rile Return u twice to let back
to the SYSGD file.
Thus our new command hal been implemented into the
source code for NtS. We must now compile the
main-control and text-editing overlays &n~ reload the
system. Rather than do the compilation trom NtS, we
will use the NUTltITY SUbsystem to both com~11e the
files and load a new version of the system, which can
then be run experimentallY under DDT (see Figures
111-17, 111-18, and 111-19). In Figures 1II-19 and
111-20, the new command is successfully tested.
Let us now eontinue our examination of the SYSGD tile
(for a reView, see Figure 111-)). AI shown above, the
SYSGD file can be used to help one examine and mOdify
the source code. There are al'o ways in which it can
help one locate procedures of a liven functional type.
The use ot the keyword system with the "index" branch
and the use of the content analyzer on the "ovlind"
branch are two examples of this aid.
The "index" branch containa categorical listings ot
the procedures in the system by funetion. U8inl the
keyword retrieval system, one can select and weight
categories and have the named entries (links to
~roceduresin thil case) presented in order of
deereasing relevance, according to the user's
weichting and order ot lelect10n. One may then take
the links and examine the documentation and code tor
each ~rocedure (see Figures I11-21, 111-22, and
111-23).
The "ov11n~" branch ot the SYSGD tile contains
information about each overlay in the system,
inclUding lists of all of the procedurel, organized
on an overlay basiS, with one-line explanationl of
functions (see Fieure. 111-24 an~ 111-25).
Since a brief description of each procedure'.
function is associated with its name, we can use the
content analyzer to help us find procedures of a

Sec~1on III
APPLIOATIONS AND EXPERIENCE

given type. For example. we can 1n.ert a
content-analysis pattern to search tor atatements
containinc ~he .tring "display" (Ieericure 111-26).
We compile the pattern (.ee Fieure 111-27) and
re-create the di.play with the content-analysis
filterinc in effect. Now onlY statements containinl
the strine "di.play" will be ,hown (see Figure
111-28).

The result Of this content filtering on this branch
of the file i- a list ot procedures that in 80me way
deal with the display. Thi. ia & u.etul way to
retrieve up-to-date 11sts ot procedure. of a liven
functional type.

_LOGOUT IRBY.
DELETE SCRATCH FILES.
TIME USED 0:0:0 IN 0:0:17
rOTAL TIME USED 12:15:11 IN 212:11:46
07/23/70 1107:03
ARC
[3-') IS UP

1."

-ENTER NLS.
PASSWORD- OJ(
07/23170 1107:10

-CHANGE DRUM ASS ro 300.
NEW D. A. = 300 OUT OF 300
_NNLS.
Inltlals please: CHI
User: lRBY

TA-7079-11

FIGURE 111-1

LOGGING IN TO TIMESHARING SYSTEM AND ENTERING NlS SUBSYSTEM

1
1
HJLV

:SYS6D

LOAD FILE

DUMMy

TA-7079-12

FIGURE 111-2

NLS DISPLAY BEFORE A FILE IS LOADED OR CREATED.
command has been specified but not executed.

A "Load File"

ALL ALL

GJLV

JUMP

I rEM

:SYSGD. 07/23/70 0'.':37

C~I

(overlay)

PROGRAM OVERLAY SrRuCrURE

(doc)

GlOBAL DOCUMENrArION

0
+

(Ovllnd)

OVERLAY INDEX & DEBUG INFORMArION

(Index)

CAtEGORIES FOR NLS PROCEDURES

(Bugs)

llsr OF BUGS

(map)

MAP OF SyMBOLS AND BINARIES

(thoughts)

r~OUG~rs

FOR IMPROVEMENrs

TA-7079-13

FIGURE 111-3

MAJOR SECTIONS OF THE NLS SYSTEM-DIRECTORY FILE, SYSGD. The
command specified in Figure 111-2 has just been executed: a "Jump" command
to display the "Global Documentation" branch has been specified but not executed.

ALL

JlJMP ro LINK

:FILEsrRUCrlJRE

8JlY

(doel

GLOBAL DOClJMENrArrON

fol" doeumeniailon on fIle sil"ueiure seeO(fllesirueiure.tl
f

f or do eumeni ai Ion on s pee I a I prob I ellis see (n I sdocument ai I on. t I
foT' document ail on on data forlllS see (dataforlllS. t I

TA-7079-14

FIGURE 111-4

"GLOBAL DOCUMENTATION" BRANCH OF SYSGD WITH "BRANCH-ONLY"
FEATURE IN EFFECT. The user is about to follow a link which will cause
the file-structure documentation to be displayed.

ALL ALL

JUMP TO ITEM

HJLV

:SYSGD. 07/23/70 0'.':37 CHI:
loverlay)

PROGRAM OVERLAY STRUCTURE

I doc)

GLOBAL DOCUMENTATION

IOvlInd)

OVERLAY INDEX , DEBUG INFORMA nON

IIndex)

CA TEGOlllES FOR NLS PROCEDURES

I Bugs)

LIST OF BUGS

I map)

MAP OF SYMBOLS AND BINARIES

It hought s) 0 THOUGH TS FOR IMPROVE MEN TS

TA-7079-15

FIGURE 111-5

The user has now returned to the same view shown in Figure 111-3 (several steps
have been omitted from the sequence). A "Jump" command to display the
"Thoughts for I mprovements" branch has been specified but not executed.

ALL ALL

HJLV

[thoughts)

JUMP ro NAME FIRSr

OVERLAY

THOUGIHS FOR IMPROVEMENrS
0«

70103/20

WI'

'''tt/25 1'51: 23

tt~: 23

traIls
TraIl returns can be done through a ~ush down stack. Every tIme
the seq-gen lIIakes a tratl branch It ~ushes the ~sld on a stack.
The user lIIay deftne a tratl return syntax. If he has one. and It
ts found tn a statelllent. the stack ts ~o~ed and the ~o~ed ~sld
used to start the seq-gen out agatn.
WI'

"/11125 1n1:24

WI'

"/tt/25 1n1:24

cont ent ana I yzer
Coroutlnes also seelll to be the answer to the content analyzer
case ~roblelll. A set of standard coroutlnes could be selectIvely
tnvoked to 1II0dtfy the text on the way to the rsr and CV tests.
rheJ would convert cases. skt~ ~unctlon. etc. rhey could be
Invoked and dts-tnvoked tnde~endent of the ~aren structure of the
pattern. a la dtrectlons.
WI'

"/11125 1n1:2'

Don' t have t he sequence gen. set the cont ent flags In the r I n9

TA-7079-16

FIG U,R E III -6

The "Th oughts for I mprovements" branch serves as a repository for ideas about
what could be done to improve the system. A "Jump to Name" command
has been specified to display a statement named overlay"-the user has
specified this name by typing it in.
II

R+ 2 1

GJLV

loverlay)

JUMP ro VECrORLABEL

MNcrRL

PROGRAM OVERLAY srRucrURE
I oct I
prlllSpc
IIlAct r I
vctedt -vctrl
t odls
t odprn
calc
key.d

dlsbuf -lnpfbk

•

d at

dl ddl

ut I It Y
seqgen

CdSPIY
sdblllnp - CICIllP I

st rlllnp

clnup

- rec I nt -

auxcod

txt edt -

I nk sub

TA-7079-17

FIGURE 111-7

FI RST BRANCH OF SYSGD FI LE:
USED BY NLS SYSTEM

DIAGRAM OF OVERLAY STRUCTURE

)
JUMP TO LINK
'HY

Inmctrl) lIlaln control overlay
link to file Inls. IIlnctrl. : JxbbJhnz) Ikdf ERICKSON)
starttnglocatton: orglllct=24000 page 5
cells used: 21450
procedures In the MNCTRl overlay
1wc) what charact er ,
Iwalt) walt for MNCTRl
Icaqlll) command accept. questIon mark
Idmanl) dIsplay. then go to maIn
I set dUIll) set up dummy st at ement
1cmdrtt) command reset
IlIldtspec) kludge for 'set'
imatn) read a character

TA-7079-18

FIGURE 111-8

A BRANCH GIVING SUPPORTIVE INFORMATION FOR MAIN-CONTROL
(MNCTRL) OVERLAY. Display shows only the first line of each statement.

A Jump to Link" comma"nd has been partially specified-no selection has
been made.
II

ALL

JUMP TO LINK

:MNCTRl

I"LY

(mnctrll

maIn control overlay

I Ink to fIle (nls. mnctrl. : JxbbJhnzl Ikdf ERICKSON)
st art I ng I ocatl on: orglllct=24000 page 5
cells used:
27450
procedures In the MNCTRl overlay
Iwc) what character
tOINlS. MNCTRl. wc : JgebJI
I walt) walt for MNCTRl
(NlS. MNCTRl. walt: J9WJ)
(caqlll) cOlllmand accept. quest Ion lIIark
(NlS. MNCTRl. caqlll : J9wJI
(dlllenll dIsplay. then go to lIIaln
INlS. MNCTRl. dllla!n : J9WJ)
( set dum) set up dUlllllly st at ement
INlS. MNCTRl. setdulII : J9wJI

TA-7079-19

FIGURE 111-9

SAME AS FIGURE 111-8, EXCEPT THAT DISPLAY SHOWS ALL LINES
OF EACH STATEMENT. The link in the statement named "we" has been
selected; this link specified another statement named "we" in a file called
"MNCTR L" under User "N LS" (the characters "jgebJ" in the link are
VIEWSPEC codes).

4
ALL
GJLV
Iwe) bp
:::'a:
:::'b:
:::' e:
:::'d:
:::'e:
:::'f:

:::'g:
:::' I:
:::' J:
:::'k:
:::' I:
.. 0:::'111:

:::'0:
:::'p:
:::'r:

:::'8:
:::'v:

=' x:
=SP:

JUMP ro I rEM

an zap CASE
6ROUP:edlt SrArE:xa.edlt OSPI"< Append Statement)
6ROUP:edlt SrArE:b8.edlt OSPI"< Break Statement)
6R0 UP: ed It
0 SP I .
ftEPEA r l·.)

TA-7079-20

FIGURE 111-10

RESULT OF "JUMPING" ON THE LINK SELECTED IN FIGURE 111-9
(from Index in SYSGD File to Source Code for "wc" Procedure in
Main-Control Overlay), A "Jump" command has been specified to display
a particular branch of this code,

II Jl y

COpy
t

BRANC~

Q='m: GROUP:edlt DSPlcMove hESJ) .
='c: SrATE:mc.edlt DSPI~ c Move
='W: srATE:mw.edlt DSPI~ c Move
=' n: srATE:mn. edit DSPI~ c Move
='V:
SrArE:mv.edlt DSPI~ c Move
='d: cdeasy ~ 0: -cvcrEDr. qllld>.
='1: srATE:IIlt.edlt DSPI~ c MO'le
='1: srATE:lIll.edtt DSPI~ c Move
='t: srATE:mt.edtt DSPI~ c Move
='s: SrATE:lIls.edtt DSPI~ c Move
='b: SrATE:lIlb.edlt DSPI~ c Move
:'p: SrATE:lIlp.edlt DSPI~ c Move
='9: srATE:1Il9· edtt DSPI~ ( Move
=CA: REPEAT I JECJ)
ENDCASE Goro ccaqlll>

CASE
Character) HJ=c.Character
Word) JEJ=w.Word
Number) JEJ=n.Number
VIsIble) JEJ=V.Vlslble
Invlstble) JEII-=l.Invtstble
LInk) JEJ=I.L1nk
rext) JEJ=t. rext
Statelllent) HJ=s.Statement
Branch) JEJ=b.Branch
plex) JEJ=p.Plex
Group) HJ=9· Grou P

TA-7079-21

FIGURE 111-11

CODE DESeRI BING COMMAND LANGUAGE FOR "MOVE" COMMANDS,
IN A SPECIAL-PURPOSE LANGUAGE. A "Copy Branch" command has
been specified to create a duplicate copy of this command-language code.

ALL ALL

GJLV

+ 0.:=' t:

JUMP fO PREDECESSOR

SROUP: edl t DSP [ ( franspose f IfESlfl
CASE
.:=' c: SfArE:trc.edlt DSP[H rranspose Charact er I
.:=' W: SfArE:trw.edlt DSPI"( rranspose Word) IfU.:=w,Word
.:=' n: SfArE:trn.edlt DSPI"( rranspose Number) IfEIf:n. Nunlber
.:=' v: S rArE:t rv. edIt DSPI"( franspose VIsIble)
.:='1: SfArE:trl.edlt DSP["( franspose InvIsIble)
.:='1: S rArE :t r I • e d I t DSP("( rranspose lInk) If Elf: I,ll nk
.:=' t: SrArE:trt.edlt DSP("( franspose fext) HIf:t, rext
.:='s: SfArE:trs.edlt
.:=·b: SrArE:trb.edlt DSP(" ( rranspose Branch)
.:=' p: S fA rE :t r p. e d It DSP(" ( rranspose plex) H*:p.Plex
':='9: SrArE:tr9·edlt DSP(" ( franspose Group) IfE*':=9' Group
.:=CA: REPEAr (.EC.)
ENDCASE soro (caqm>

TA-7079-22

FIGURE 111-12

By executing the "copy branch" command, then substituting "Transpose"
for "Move," "qt" for "qm," and "tr" for "m," we produce the commandlanguage code for the "transpose" command. A" Jump to Predecessor"
command has been specified to redisplay the unaltered command-language
code for "Move."

ALL

JUMP TO LlNIC

ALL

: THED T

• JL Y

:: m:

GROUP: edtt

DSP' e

::' d:

cdeal," 0: • .

TA-7079-23

FIGURE 111-13

COMMAND-LANGUAGE CODE FOR "MOVE" COIYIMANDS, WITH ALL
LEVELS SHOWING, We now "Jump" on a link to a routine named "qmc"
in the "TXTEDT" overlay file which implements the "Move Character"
command (the link in this case is a subroutine call in the "Move" commandlanguage code-photo shows display just before "Jump" command is executed),

ALL

COpy BRANCH

MHY

% move %

[ qmcl

+[IB1.IPl TO 41

+[IB2.IP5 TO I I

SO TO END.

[ qmwl +< wdr> [IB 1.IP 1 TO 41 +[IB2.IP5 TO I I
+[IP7.IPII SOTO <1110 vet x> END.
[ qmnl + IIB1.IPl TO 4) + IIB2 .IP5 TO II
+[IP7.IP1) SOTO END.
I qml) +IIB1.IPl TO 4) +IIB2.IP5 TO II
SO TO END.
\ qlllvl +\IB1.IPl TO 41 +< vdr) IIB2 .IP5 TO I)
+ END.
I qlllt) +lIB 1.IB2) : END.
I qtw) +IIB1.IPl TO 4) +ISB1.SPt ro 41
SOro END .

MOVErx

+lsB2.sP~

ro 81

Iqmwl +ISBt.SPt ro 41 +ISB2.SP~ ro II
+ISP7.SPII sora END.
Iqlllnl +lsBt.sPt ro 41 +ISB2.sP~ ro II
+IIP7.IPII soro END.
Iqlllll

+IIB1.IPt ro 41

+IIB2.IP~

ro II

sora END.
Iqlllvl +IIBt.IPt ro 41 +IIB2.IP~ ro II
+IIP7.IPII soro END.
I qllll I +IIBt.SPt ro 41 +IIB2.sP~ ro II
+IIP7.SPII soro END.
Iqmtl

+IIBt.IPt ro 41

+(tdr>ISB2.IBJ.SP~

ro II

TA-7079-25

FIGURE 1II-15

SAME DISPLAY AS FIGURE 1II-14 BUT WITH ALL LINES SHOWING.
We now follow a "GOTO" instruction by using the "Jump to Name"
command (photo shows display just before "Jump" command is executed).

All

JUMP F1L E RETURN

:MNCTRL

MJlY

I movef xl

:C
IF SFIBll :: SFIB2} THEN
!F B1 < B2 THEN
ST B1 .. SFIB!l P2. ~LlT~. P5 PL P4 P7. pa SEIB!!
ELSE ST B1 .. SFIB1} P7.pa P2. Hln. P5 P6. P4 SEIB1}
ELSE BEGIN
ST B1 .. SFIB1} P2, ~Lln. P5 P6. P4 SEIB1};
ST B2 .. SFIB2} P7. pa SEIB2} END:
r-e II U GO TO END.
If r-anf x} PROCEDURE I bug1. bug21 ;
REF bugl. bug2;
+eIIPl.IP2}
OELPTRIPl P2} OELPTRIP5 P6} :C
IF SFlbug!} :: SFlbug2} THEN
IF bug! ( bug2 THEN
ST bugl .. SFlbugll Pl. P5 P6. P4 P7. P! P2. pa SElbugtl
ELSE
ST bug! .. SFlbugll P7. P! P2. pa Pl. P5 P6. P4 SElbugll
ELSE BEGIN
sr bug! .. SFlbug!) Pl. P5 P'. P4 SElbug!};

TA-7079-26

FIGURE 1II-16

The "movetx" code has been copied and altered to produce the "trantx"
code for the new command. We now return to the previous file by
using the "Jump File Return" command (photo shows display just before
"Jump" command is executed).

advised tty open; :8
ARC 1.76 (3-') IS UP
.ENTER NlS.

PASSWORO- OK
07/23/70 1128:01
.ExECUrrVITY -1.

•
•
•

-RESET .

•

lI-F II e.

ct I f I Ie
rext; MNCTRl rxrEor •
lI-Wr-lt e .
lI-Cornpl Ie .
lI-Wr-t{ e B I nar-l es.
lI-Abor-t
lI-60

TA-7079-27

FIGURE 111-17

The NUTI L1TYsubsystem allows one to automatically archive, retrieve
from archive, compile, print, and cross-reference files (display is now
running in Teletype-simulation mode, as it was before N LS was started
up in Figure 111-1).

eMU rIL TV .

advIsed tty open: :1
ARC 1." (3-') IS UP
.ENrER NlS.
PASSWORD- 01(
07/23170 1121:53

.EXECunVITV -1.

•
•
•
-RESEr.
•

.R e ad BIn ar I e s .
• load NlS .
• F II e.
ct I file All files.

J.60

TA-7079-28

FIGURE 111-18

Once the changed code has been compiled, NUTI LlTY can be used to
automatically load a new version of the system.

AL l

fRANSPOSE WORD

MJlY

. DUMMy
rh4 sis a sf

a' emenL
+

TA-7079-29

FIGURE 111-19

Under DDT we run the new experimental N LS and build a dummy
statement to test the new "transpose" command. In this photo the
command has been specified and two words selected.

ALL

rRANSPOSE WORD

ALL

M JL Y

. DUMMy :
st at ement

s a rhls.

TA-7079-30

FIGURE 111-20

Here the "transpose" command has been executed.

ALL

KEYWORD SELECr

FIlElO

IHY

11ndexI

CArEGORIES FOR NLS PROCEDURES

fIle handlIng
l'llelol RANDOM FILE I/O
+. Ilodrfbl Irdhdr)
Ifllco~y)

•

FILE COPYING
1co~f III 1get .ka)

Ifllref) FILE BLOCK REFERENCING
• 1 lodrsv) 1lodrfb) I lodsdb)
1fllcontrol) FILE CONrROL
• lo~nffk) Ilodrfb) Ibrt"x) Irdhdr)

TA-7079-31

FIGURE III-21

Another branch of the SYSGD file allows one to select procedures
according to function with the "Keyword" commands. I n this photo
the user has selected the word "fileio" as a keyword; we see that the
statement named "fileio" contains two other names, "Iodrfb" and
"rdhdr," in a special format.

ALL

JUMP TO llNIC

IHY

:UTlLTY

llod ... fb) load ... andolll fIle block
OINLS. UTlLTY. lod ... fb : IgWJ)

l ... dhd ... ) ... ead heade ... block of fl Ie
INLS. IOCTL .... dhd ... :gWJ)

TA-7079-32

FIGURE 111-22

DISPLAY PRODUCED BY KEYWORD SYSTEM. When the selected
procedures are presented, one can "Jump," via the associated links,
and examine the documentation. and code for the procedure.

ALL

JUMP FILE REruRN

:SYSGO

• J LV

( I 0 dr f b ) IT his 1st he PRO CEO UREt hat eve r yon e c a I 1st 0 h a ve a
ran d0 m f I I e b I 0 c k loa de dint 0 cor e . AIso. ItIs po s sIb let 0
obtaIn a block of core whIch Is empty and not assocIated wIth
the ~lle. For example. a long lIteral regIster Is created In
thIs way.
rhere are several tIC blocks In core. some of whIch
may be 'frozen'. whIch means that they may not be moved or
used for anythIng else. LOORFB loads the desIred fIle block
Into one of these core blocks.
On entry. the A contans the
random fIle block nUlllber. and the B contaIns the block type.
or - t 1F no f I I e b I0 ck 1st 0 be rea dint 0 that cor e b I 0 c k .
rhe algorltnlll Is apporxllIlately as follows:
First. a block Is chosen. A quick scan Is made to fInd an
unused block. If all are In use. rWEN a circular counter
(NACP) Is used to find the 'next' core block that Is not
frozen. If a II are frozen. RERROR Is ca II ed.
RERROR Is called IF the desired clock does not exist.
If the newly found core block contlans a fl Ie block. then

TA-7079-33

FIGURE 111-23

DOCUMENTATION OF LODRFB PROCEDURE. The "Jump to Link" command
specified in Figure 111-22 has been executed, and the user has set up a "Jump
File Return" to display the SYSGD file again.

R+2

JUMP TO ITEM

HJLV

(

(OvlIndl

OVERLAY INDEX' DEBUG INFORMATION

( auxcodl

10rks and 10rk ri art I ng

(rec I nt I

recovery and Initializing

(dat al

dat a page

(utlltylO utility package

•

( I np1bkl

Input 1eedback

(mnctrll

main control overlay

IprmspCI

parallleter specification overlay

I vct edt I

spec I a I charact ers and vect or II be

I vct r II

vect or package

TA-7079-34

FIGURE 111-24

The overlay index branch of the SYSGD file contains
overlay in the system. A "Jump" has been specified
on the utility package. The VI EWSPEC code "R+2"
left corner of the screen shows that in executing the
structural levels of text are to be displayed.

information about each
to display the branch
appearing at the upper
"Jump," two additional

JUMP TO LINJ(

:UTlLTY

MJlY

[utt It y) utt lit y package
t Oink to file [NlS.utllty.1:lgebjJ) (kdf PARSLEY)
st artt ng I ocat Ion: orgut y=14000 page J
cells used: 17715
locatton for telllporarles: uH
prefix for generated labels: utI
procedures In the UTILTV overlay
[utgd) UTllTY general declaratIon.
[push) push b-reg onto general ttack
[ pop I pop genera I tt ack ont 0 b- reg
[reillt) release lIteral regltter
[getllt) get lIteral reglrter
[regadrl get regl rt er addre ..
[apchrl append character to a-rtrlng
[apsrl append a-rtrlng to another
[Idchrl load character frOIl a-rtrlng
[cpysrl copy one a-ttrlng Into another
[asrbufl lIlove a-ttrlng to buffer
[lIlvbfbfl lIlove buffer lup tn corel
[lIlvdownl lIlove buffer (down In core)

TA-7079-35

FIGURE 111-25

INFORMATION ON THE "UTILITY" OVERLAY, Including Part of the List
of Procedures in the Overlay. The first substatement in this branch contains
a link which the user is about to follow.

ALL

INSERT CHARACTER

MJLY

(OvlIndl
OVERLAY INDEX' DEBUG INFORMATION [.dlsplay.];
(auxcodl forks and fork startlng
r
lInk to fIle (nls.AuxCOD. : IgwJI Ikdf ERICKSON I
st art I ng I ocat Ion: I orgauX::24000 page 5
ce II s used: I 26234
locatlon for telllporarles: I ad
prefIX for generated labels:J axl
procedures In the AUXCOD overlay
(qkfl freeze natelllent
I NL S. AUXCOO. qkf : JgWJ I
(qkal re I ease frozen nat elllent
(NLS. AUXCOO. QKA : IgwJI
Iqplsll poInter show
iNLS. AUXCOO. qplsl : IgwJI
Iqpmll poInter delete
(tH S. AUXCOD. qpllll : IgWJ I

TA-7079-36

FIGURE 111-26

Here the user is back to the SYSGD file (several steps have been omitted
from the sequence). In the first line of text on the display he has inserted
a content-analyzer pattern for finding procedures containing the string
"display."

ALL

AL L

CONrENr ANALYZER

MJLY

(Ovllnd)
OVERLAY INDEX' DEaUG INFORMArION O[·dlsplay·]:
(auxcod)
forks and fork start Ing
+
lInk to fIle Inls.AUxCOD. : IgWJ) (kdf ERICKSON)
startIng locatIon: i orgaux=24000 page 5
ce II s used: J UHf
locatIon for telllporarles: I axt
prefIx for generated labels: I axl
procedures In the AUXCOD overlay
(qkf) freeze statelllent
(NLS. AUXCOO. qkf : IgWJ)
(qka) re I ease frozen st at elllent
INLS. AUXCOD. QKA : IgWJ)
Iqpls1t poInter show
INLS. AUXCOO. qplS1 : IgWJ)
Iqpmll poInter delete
INLS. AUXCOD. qplll1 : IgWJ)

TA-7079-37

FIGURE III-27

The pattern is compiled with command "Content Analyzer." The display is
not yet affected-the content-analysis code compiled from the pattern will
be run when the user changes a VI EWSPEC.

ALL

JUMP TO LINt<

:RECINT

MIL Y

(OvlInd)

OVERLAY INDEX' DEBUG INFORMATION
(setdls) set up display
O(NLS. RECINr. 8etdls : IgWJ)

[·dlsplay·];

Idlsmes) display mes8age
INLS. UTILrY. dlslles : IgWJ)
Itxt) create a new dIsplay pop
INLS. UTILrY. txt : IgWJ)
Iclrdpy) clear dIsplay
INLS. UTlLrY. clrdpy : IgWJ)
Iresdpy) reset dIsplay
INLS. UTILrY. resdpy : IgwJI
Iclralll clear entire display
INLS. UTILrY. elrall : IgwJI
Inulldpyl nUllber dl8play

TA-7079-38

FIGURE 111-28

RESULT OF CONTENT ANALYSIS: a list of procedures that in some way
deal with the display (since they contain the word "display")

Sec~ion III
APPLIOATIONS AND EXPERIENCE

o. The Augmented Manager
1.

In~rOduetlon

General Considerations
Mo.t people need ~o play the role of "manaler" at
varioul times, whether tha~ role i8 their primary
function or simply a nece.aary element for the
accomplishment of their other work.
We will u.e the terms "manlier" and "man'lement" in
this expanded len.e, applying them to an individual'.
management of hi. own time, resource., and .Kill. as
well &1 to individual and COllec~lve mana cement of
the work of other individuals and groupl.
Our experience with augmented management can be
de.cr1bed beat 1n ~erm8 of the augmentation tOOl' we
have developed an4 the methOdS we have evolved for
eXPloiting th.letool. in ~het&lk ot man&lement~
once a tool loeainto u.e. methOdology bec6me. as
com~lex and critical a concern a8 the de.len and
development of the tool it.elf, and our research in
the area of &ugmentinl management ha. been concerned
principally with the development of .pecial
methOdOlogies tor usinc our ba.ic aUlmen~&tion tool'
with onlY .econdary empha.i. on the development of
new .~eclal·purpo.etool'.
We have identified the follow1nc a. lome of the major
need. relevant to fulfilling the role of manaler 1n our
auemented communi~y.
(1) Fa.t and flexible mean. for aec •• sine and
.tudylnemanaiement working file. and other croup
working file.
(2) Technique. for leeatine .pecific piece. of
intormatlon1n & complex tile or collection of f11e.
(3) EffiCient method' for entering, uPd&tlnl, and
storing manalement inform&ti6n
(4) Technique. forinteraoting with other croup
members to verify and comment on information Within

Sec~ion

III

APP~ICATIONS

AND EXPERIENCE

the group'. working recoros
(S) Facilities for rapid and flexible com~osit1on,
mOdification, and pUblication Of management
Oocumentation

(6) special tool' for the processing of manacement
information (e.I., the Nt! calculator faci11ty).
Some of the Ipecific tools and methods developed in
re.ponse to the needs outlined above are described
brieflY below.
Our collection of on-11ne files now contains
considerable manalement information Of various kinas,
and we have pursued our investigation of
managemen~-1nformation operations by using NL! and
TODAS to provide and develop aids for management ot
the ARC on-line community.
There are many areas of potential apPlicat10n for
on-line aidl, and we have cholen those
ch appear
to be most useful operationallY for the purposes of
experimentation and development.
b.

Cost-Accounting Files
While still under continuous development, special
cOlt-accounting file. (described 1n detail in Section
111-0-2 below) are now in routine use. These file. are
extremely usefUl in terms of letting work done, and our
experience with developing and using them hal
constituted lome of our mo.t fruitful research on the
intensive eX~loitation of the overall on-line system.
The files have an intricate structure, desilned for
maximum mObility in accessinl information and for
maximum efficiency in interfacing with the NtS
calCUlator facility. Intelligent use Of these files
include. the entry of new intorm&~ion and the occasional
re.tructuring Of the information to take advantage ot
new ~os8ibilit1e8 1n the system and to meet neWlY
discovered needs. While fundamentally Simple, this kind
of usage requires the coordinated operation of the mOlt
advanced feature. of NL!) thus the cost-accounting file.
are a leading edge of our research on highly interactive
information .tructure ••

Sec~ion III
APPLICATIONS AND EXPERIENCE

work-Planning Files
We have begun experiment. in u.inl NtS tile. tor the
~lanning and moni~oring of ~a8k. within our project
aetivi~iel.
our first experlmen~involved the
management ot the TODA! development activity, for Which
we created a f11e called UPLAN to use in formulating
.~ecificat1on8 for TODA! and in planning for the
implementation of the specified featUres.
This tile contain. a branch for each identif1ed talk
with the followiniintormation organized tor ealY
study and retrieval:
(1) Description of the ta'k, with link. to other
working tiles used in ita development
(2) Comments on the relationship ot the talk to
other ARC taSKS
(3) Estimatel ot im~lementat10n cost. (mainlY
manpower) and .chedule ot work and implementation
Itages
(4) comment. on the current status ot Planning and
implementation.

We allo created a separate file called UMEET containing
agendal and notes for the TODA! development activity
meeting ••
We made u.e ot a researCh a •• i.tant working on-line
to take notes during the.e meetings. The research
as.istant worked from an agenda composed betore the
meeting 80 &S to have a convenient framework for
no~e-taking, and was a1.0 available for tinding
on-line information a. nee~ed durinl the mee~ings.
Succe.sive meetine alenda. and minutes were kept in a
sincle file 80 as to make it ealY fer u. ~o search
for record. of all diSCUSsion related ~o any liven
topic.
On a lea. formal basis, we have used various.other file.
tor work planning throulhou~ the project'sh1story,
This has ranle~ from the construction of lists of task.
in such & way as to reflect their interdepen4encie., to
the main~enance by individuals Of file. listing their

Section III
APPLICATIONS AND EXPERIENCE

perlonal tasks on hand along with plana for completing
theae tasks.
d.

Perlannel Files
SOMe of our ~er80nnel information i. now kept in on~line
files. Features 1n the timesharing .ystem ~erm1t UI to
rel~rict aceesl to some ot the.e files, while letting
others remain "pUblic." Even though our personnel
ro.ter 1s relatively small, we find it advantageous to
have the ability to .pecify automatic searches on the
personnel filel, e.~ecially for .uch taSks as cost
estimation.

DOCUmentation
All of our documentation, from large final re~orts to
the brief circulars distribute~ at conferences, is
compo8e~, stored, and uPdatea in on-line files.
our
flexible compolition and editing capab1l1tiel and fast
pUblication technology (from on-line file to formatted
hardcopy in a few seconds per pace) live management
control. over the documentation procesl that are not
pOSSible without augmentation.

On-Line Dialolue
We use the term "dialogue" to indicate the process of
formal communication via interactions with a common
information ba.e. This kind of dialolue plays an
important role in the formulation ana monitoring of
plan. for project activities, an4 while we are still
using informal experimental methoOs to achieve ihi., we
are in the procesl of formulating the initial Plans for
& long-term investigation of aOvanceO techniques for
&ulment1nl ~ialogue procesles.

SubleQuent lections offer detai1e~ descri~tions of several
man&lement application. that have been Oeveloped using NtS
ana TODAS, illultrate~ with Photograph' taKen from Nt!
~1'Play Icreens to show sequences ot
information-manipulation operations. A familiarity with
the basici of NtS (to the extent that they are eXPlained in
Appendix A) il aSlumed.
tn following the descriptions, it should be kept in mind
that the speed with Which NLS serve. its users is an

Sect.ion III
APPLICATIONS AND EXPERIENCE

important part of its utility. The Photographs in~1cate
t.ransitions that take only one or two second. under lood
conditions. This speed lendS great power and
flexibility to the relativelY simple service functions
performed by NLS.
2.

project COlt Records
In our routine operations, we need frequent and rapid
acceSI to summary data on project costs, with little
reference to lower-level details except when the COltl are
first checked for reasonableness and accuracy. Therefore
we decided to start by putting summary data on-line at ARC.
As needed in the future, we can add more levels of detail.
We first constrUcted a cost-history file for 1968-1969
costs on SRI projects ESU 7101 (RADO Contract
F30602-68-0-0286) and ESU 7079 (NASA Contract NAS 1-7897).
This tile il called HISCO.
The elements of RISOO included the following for each Of
the two projects, on the basi. of 4-week accountinl
periodS (as used by SRI's accounting system).
(1) Salary

(2) Burden
(3) Overhead

(4) Total cost
(5) Fee
(6) Total charges.

See Fieures 111-29, III-30, and 111-31 (illustrations
for this section are grouped together, bel1nn1nl on
pale 75). Each ot thes. three ligures shOwS &
display of one branch of the file, containing the
information for a specific project and year.
We &110 needed a .ection showing combined salary
costs and combined total charles for all of our
projects (see Figures 111-32 and 111-33). We put
the8e cost. in separate branches Of the file. The
last branch shows total costs for both projects

Section III
APPLICATIONS AND EXPERIENCE

combined. We retroactively studied eXisting records
fer all 1968 d&\a and kept up the 1969 COlts every 4
weeki, entering the new data by hand.
The usual way ot accessing HISCO was via pre·es~&blished
links from other workinl tiles whenever the user had &
question about recent coat,. The VIEWSPECS in the link
usually caused HISOO to be brought in with only
hieh-level statements on display, showing only the
headincs for project name, combined salary, total
charles, and total ARC costs (see Figure 111-34).

The user COUld then select the project he was
interested in (bY the command Jump to Item), open up
an additional level for viewing, and see column
headings and numerical data (rigures III-29, III-30,
and I11-31).
Then he COUld jump down through the accounting
periods to the one he was lookinl for.
If he waa making a calculation (perhaps already
.tarted in the f11e he was working 1n before he
loaded 81SCO), he could then call the calculator
and add, SUbtract, multiply or divide by any of
the numbers 1n HISOO. His previous caleulations
1n the previous tile woulO remain intact.
If finiShed with HISCO. he eould then return to
the previous tile (by the command Jump File
Return) and continue with the calculation, havinl
found in H1SCO the input number or numbers he was
look1nl for.
A. an arena for experimentation, HISCO proved valuable.
OperationallY, it wa. u.eful from time to time but revealed
& nee~ tor ~ore frequent updating of the .ummary data. our
experience with HISCO led to the development of a
rede.ilned cost-history tile ealled COSTS Which il up~ated
weeklY, w1th 4-week and eumulat1ve Iummaries.
The co.t elementl in thi. file are:
ll) Salary costa
(2) Total personnel costs

Sec~ion III
APPLICATIONS AND EXPERliNCE

(3) Non-labor costs
(4) Total costs
(5) Total charges with fee

(6) Balance remaining.
See Figures 1II-3S, 111-36, and 111-37. Figures
111-35 and 111-36 show the lame branch of the file
with different VIEWSPECSJ Figure 111-36 displays one
more level ~hanFigure 111-35, and this level .hows
the weekly data. Figure 111-37 .hows the weeklY data
for another project.
We also included fundinl information showing current
totall, unfunded totals, and total contract amount.
in the "cost," "fee," and "total" categor1es.
We use separate branches tor each project and for total
ARO project co.ts (Figure 1II-38). The skeleton format
for the file was set up in advance for the entire year
of 1970.
Before enter1nc any actual aa~a, we copieQ the first
top-level branch (containinl .ome 70 statements)
within the tile at the .ame level four or five time.
so a8 to create blank format branches. Then we
simply inserted the project name headine. tor each
project into a corresponding blank branch. we keep
one blank format branch in the file in cale any new
projects 'hould arrive.
Like HISCO, COSTS is usually reached throUlh a link trom
lome o~her working file, perhaps while a stUdY of
near-fu~ure COlts is in ~rogrels, or from a ~ropos&l
co.t estimate ~nder developmen~. Alain the tile 1.
usually entered with only the top-level .ta~ement. or
project head1n,s Showing (see rieure 1II-39).
If a partieular project i8 of interest, the
corre.pending branch is selected and another level
opened tor view. The second level Show.
per1od-by-period .ubteta18 in each ce.t catecorf. It
weekly data are deSired, another level il opened,bY
changing the VIEWSPEOSand a partiCUlar week is
selected by the command Jump to Item.

Sec~1on III
APPLIOATIONS AND EXPERIENCE

The statement for each week has the week-ending date
&. it' name. The realon tor usinl thi
orm of name
construction is not only 80 that the statement for a
particular week can be accessed by the Jump to Name
command u.1ng the ending date, but also 10 that the
date may optionallY be suppressed from the display.
(NLS has the capability ot suppressing all statement
namel from the display.)
The normal way of viewinc thele particular files is
with names suppressed; thus the dates do not clutter
the display. However, a uler who needs to know the
end1nl date tor a ~artieular week can see it by
executing a single command.
TO accels the information for another project within
COSTS, one executes Jump to Return twice to see the
top-level statements again (Figure 1I1-39).
One can move very quickly and accurately through a tile
that i8 let up 1n this fashlon, even without any
familiarity with the information it contains.
The primary function of COSTS is to ShOW a consiltent
week-by-week progres.ion, by category, ot COlts for each
project. The tile can also be used tor 8tu~y purposes,
throuch the use Of content-analyzer patterns, SOMe of
which are stored in the oriCin statement (.ee Figure
111-40, which is ~he same as Figure 111-39 but w1~h
different VIEWSPEOS). Any other pa~~erns can be crea~ed
as needed.
Thi. allowl a user to extract speCial categories ot
information trom the file very quiCklf. ror example,
a user may ealily create a di.play .howinc all
project CO'~8 for the eighth week of 1970, for each
ARC project. It is also p08sible to output such a
"filtered" display Via aline printer, thus obtaining
hard copy of a special-purpose extract trom the total
file.
The content analyzer is helPful when using the
calculator on all the data for one week, project by
project, to find total ARC charges by catelory.
When only one week's data are di.played (Figure
111-41), one can add items down each column and

Section III
APPLICATIONS AND EXPERIENCE
insert the answer in the "ARC total" space. One can
then elear the accumulator, and a~d down the next
column. Th1. 11 done very rapidlY through bUg
selection of input numbers and keyset entry of
command. -- Add, Add, Add, Add, Insert, Clear, Add,
Add, Add, Add, Insert, Olear, and so forth.
The COSTS file is now operationally useful to us, and we
expect it to be useful tor future experimentation with
automatic proces.ing techniques.

Estimate. for proposal.
a.

personnel costs
An estimator working on a propo.al can select from an
on-line file, by labor category, repre.entat1ve people
who may be involved with the proposed work; as he
selects them, he can transfer tb
names ana relevant
information about them to a file Where he 11 building up
hi. estimate.
The estimator loads a special file, maintained by
him.elt, Which is a directory to all of his other file.
an4 perhaps to a few files belonlinc to other people.
rieures II1-,2 and 1II-43 are two display. of a user's
filedlreetory. In Figure III-~2, only first-level
.tatement. are shownJ these are used for establiShing
catelories. InF11ure III-,3, another level i . shown,
containing the actual directory listin«s in each
category.
This "fl1e directory" contain. links to each ot the
file. that it listl. In the present cas. the tile.
prObablY would be cost histories, personnel listinc-,
previous .pec1al studie. of costl, and other
admini.trativeinformat1on.
He load. a previous cost e.tlma~., makes a workin, copy
ot it, change. the headine to reflect the name of the
new proposal e.tim&te, and eliminate. the amount. trom
the old e8tima~e.
Thil produce. a blank cOlt-e.timate format. It any
items from the old estimate &reinappropr1ate. they
are easily deleted; new item. are eaaily added IS
separate .tatement.. When the format il ready, it is

Section III
APPLIOATIONS AND EXPER1iNCE

output al a new file.
He can then load a file that lists names ot people in
the croup and lome projection Of expected addition ••
Fieurel 111-44, 111-45, and 111-46 snow portions ot such
a tile.
Usinl this personnel-listing file, he obtains
information about labor categories. A branch
containing content-analyzer patterns is kept in the
file. Thele can be easily reached by jumping to a
link that causes all the patterns to be ~isPlayed
(Fieure 111-47).
Each ~attern will select some particular category
of statements from the tile. For example, the
estimator will need to know which people have the
statuI of Senior professional.
He .elects the appropriate pattern with the
command Execute Oontent Analyzer, and then
jumps on a link that turns on the content
analyzer, starting the .earch at the beginnlne
ot the branch containing personnel liltinls and
restricting tne seareh to that branch.
Thi. prOduces a diSPlay showing onlY the
listing of senior profe.sionals in the croup.
This let of statement. can tnen be tran.ferred
to the new propolal cost-estimate file.
other patterns can be used to extract let. ot
statements according to other criteria -- for
example, all the hardware or softWare peo~le 1n
the group (Figures 111-,8 and 111-49).
ThUs the estimator can select, by labor category,
re~re.entat1ve people Who may be involve~ with the
~roposalJ as he selects them, he can transfer their
namel and the lnform&t1~nthat goel with them to the
file where he il building up hi. eltimate.
The payroll burden and oVerheadratel are cheeked for
currency and inserted 1nto the estimate, uling the
calculator to apPlY them to the ~irect labor. At this
point the labor portion of the e.timate 1s completed.

Sec~ion III
APPLICATIONS AND EXPERIENCE

Non-Labor Coats
A typical e.timate will involve lome travel COS~8, some
consultant eosts, and some report co.t.. Data
lupporting the cost Of eon.ultant8 may be checked by
reviewinc current consul~ant.~ costs bY project and bY
consultant. These are kept in a separate tile and
reached through a link for review. The data may be
copied 1nto the estimate if de.ired.
Report-production COlts are estimated uaing current
Institute schedules, which are based primarily on the
number of page. expected in the end prOduct. These
computations can be made u.ing tne calculator and the
existln& cost factor. from the last proposal (cheeked
for current applicability).
In addition, the proposal may contain Plans to add
equipment. In this cale, the estimator will use an
equipment stud, written 1n another file bY the people
1nvolvea in hardware des1ln.
The equipment costs contained in the special stUdy
are lummariled in total and reached by a link. The
speCial stUdy can be viewed and updated a.
appropriate and can be copied to 10 with the proposal
a. an appendix or used later for baCkup.
In thi. fashion, varioul informa~ion i. lathered from
variou. tiles and transferred into the developinl coat
estimate. Fleure. III-SO, Ill-51, and III-52 .hOW
port1on. of a completed on-11ne COlt e.timate actually
used for & recent ARC proposal.

purchase-Order Proces.lnl
In makinl elt1matea ot eo.tl for new equi~ment beinl
ARC, reterence to previous co.t1ntormation
i. very useful. We con.tructed &
purchal.-order/requi.ition proceal1n( file that contain. a
.eparate .tatement for each item purchased for the pa.t few
,ear.. Filure Ill-53 .hows a portion ot this file.
conltruc~edat

All outstandinl order. are contained at a .econd level
within a 11nlle branch (8ee rieure III-54)) therefore the
di.tinct1on between out.tanding and completed order. 1ea.¥to lee by reterenee to level. To reduce clerical

Section III
APPLICATIONS AND EXPERIENCE

error, we consider an or~er completed when the Qom~ pattern
18 inaerted and the .tatement 18 moved to it. alphabetical
~o.ition on the top level.
Thi. tile can be .earched u.inc the content analyzer in
some inter •• tine way.. If we wonder what we purchased on
PR A08927, the queltion can be an.wered simplY by executine
& content-analYZer pattern Ipecifying the number. We can
quiCkly lee all out'tanding order a chareed to a particular
project. Fieure III-55 .hoWI a content-analyzer pattern
that hal been temporarily written into the f11e, tor
finding any entries pertain1nl to order. tor relays under
Project 7101. Fieure III-56 ahow. a view ceneratea by
using th1. pattern.
This file i,kept up-to-date bY the .eeretary of the
hardware group, WhO is mOlt involved with reQui.itioning.
She doel this updatinc entirelY with TODAS.

JUMP TO ITEM
'HY

(RADCI COSTS 1968
PerIod
Salary Burden

7101

ovhd

Nonlabr Tot Cost

Fee

Totch98

1
2

10
11
t2
13

676
1080
1016
1167
2499
2522
3092
4187
2736
2309

4466

128
205
193
221
414
479
587
909
520
438
848

773
1234
1 160
1334
2854
2881
3532
5468
3126
2638
5102

23062
18061
23876
296 55
24434
B003
296 6 3
25978
40 t 68
8782
67 t 47

24639
20580
26245
3237 7
30261
30885
36874
37142
46 550
14 t 6 7
77563

739
617
787
971
907
926
1106
1114
1396
425
2326

25378
21198
27032
33348
31169
31811
37980
38257
47946
14 592
79 89 0

TA-7079-39

FIGURE III-29

A BRANCH OF FI LE HISCO

JlJMP ro SlJCCESSOR
IHY

(NASA) cosrs
Perlod
Salary

7079

1
2
3
4

8
9
10
11
12
13

1968

8462
10981
11897
10350
12394
11281
9038
94 72
1 1 157
10085
10308

Burden

1607
2086
2260
1966
2355
2143
1717
17"
2 1 19
1916
19 58

Ovhd Nonlabr rot Cost

9667
12545
13591
118 2 3
14160
12888
10325
10820
1 2746
11521
1171 6

301
787,
3083
4069
1271
12523
2650
1264
4025
6003
8338

20037
26399
30831
28208
30186
38835
23730
23355
30041
2H25
32380

Fee

1280
1686
1970
1802
19 28
2481
1516
1492
19 20
1886
2069

rotchgs

21317
280U
32801
30010
32114
41316
25246
24841
3" 6 7
31411
34449

TA-7079-40

FIGURE 111-30

A BRANCH OF FI LE HISCO

JUMP ro SUCCESSOR
IHV

(NASA) COS rs
PerIod
Sa I ar y

7079

1
2

8
9
10
11

12
13
~rojcum

4083
7296
9538
9 157
10171
8541
6463
7364
3217
2749
2348
3601
3175
193413

1969

Burden

Ovhd

715
1386
5171
219 3
2379
2050
1562
1767
772
660
563
864
762
42884

466 4
833 5
17958
11330
12238
105' 1
8129
9131

HU
3408
2912
4466

HJ7
233242

NonLabr rot Cost
16 25
3521
10113
3717
6812
7533
2215
4632
4133
1429
613
1442
1949
86 730

11141
20538
42780
26377
31600
28715
1836'
22984
12713
8244
6 4J 7
11815
98 2 3
556269

Fee
712
1312
2733
16 85
2015
1835
1180
1462
812
527

411
662
628
35541

rot Chg8
1 taH
21851
45514
28062
33615
30549
19549
2 4J 56
13525
8770
6849
11035
10451
591810

TA-7079-41

FIGURE 111-31

A BRANCH OF FI LE HISCO

JUMP ro ITEM
IHY

"U rotal

combtned Project Salary
Pertods
71 0 1 + 70n

1
2
1

67'

1462

to 10
tou

toUl
11.,7

1167

tonO

,
7
,•
5

10
11
12
13

24"

2522

lOU
4117

2736

.."

U.,

t Ull

'UI
U061
lUU
11517
141U
nl03

1 t 157
10015
10301

lUU
nlu
lU,.
14774

lU,.

un
,.72

uuo

.RES:

TA-7079-42

FIGURE 111-32

A BRANCH OF FI LE HISeO

TA-7079-43

FIGURE III-33

A BRANCH OF FI LE HISCO

JlJMP ro LINK
IHY

:I-IISCO. 02127/10 14U:SS JCN :.DSN=l:.RrJ=O:.LSP=O:.SCR=l:.HED=·ARC
ARC PROJEcr cosr HISrORy 1~68'1969
See a Iso {f un ds . cost h { st 0 r y : ZW9n I
By Pro ject :
7101 {RADCI COS rs 1 ~ 68
7101 {RADCI COS rs U 6~
70H {NASAl COS rs 1968
t
70H {NASAl COS rs 1 ~ 69
By It em:
combIned Project Salary 1'68
Combl ned Pro Ject Sal ary un
combIned rotal Pro ject 'charges 1968
CombIned rotal Project charges U6~

TA-7079-44

FIGURE 111-34

INITIAL VI EW OF FI LE HISCO UPON ENTRY VIA LINK

JUMP ro 1 rEM
, JLV

PROJEcr 7101 (RADC-old)
Tot a I
Fee
Fund I ng:
t
Cost
s 1515222
55658
Current tot a I: s 145HH
0
0
s
Unfunded total:s
0
s 1515222
S 55658
rotal contract:s 145HH
. wk-p er Sa I ary Percost NonLabr
Tot Cost Tot Cngs
85230
12110
UU4
rotal 1 14121
3521'
53724
2U 17
52142
r ot a I 2 1 13 06
21 2 2 5
rot a I 3
roial 4
rot a I 5
rot al ,
Tot a I 7
Tot a I a
Tot a I ,
rot a 11 0
rot a 111
Tot a 112
Tot a 113

Balance
18t358
127634

TA-7079-45

FIGURE 111-35

A BRANCH OF FILE COSTS SHOWING ENTRIES FOR 4-WEEK·
ACCOUNTING PERIODS

TA-7079-46

FIGURE 1II-36

SAME AS FIGURE 1II-35 BUT EXPANDED TO SHOW WEEKLY ENTRIES

JUMP TO ITEM
IHY

PROJECT 707' INASA)
FundIng:
Total
C08t
Fee
657437
Current tot a I :' , 617H7
U500
0
0
Unfunded tot a I:,
0
657437
Total contract:' '17H7
U500
wk-Per Salary Percost NonLabr Tot Cost TotChg8
Ico.blned wIth Week 2 on PSR')
1- 1

,
,

2 -1
3-1
4 -1

Total 1
5-2
'-2
7-2
1-2

Tot a I 2

1411
410
1847
3145
2114
2100
1J4I
1701
7"3

3711
1025
U1I
H'1
5717
5741
U72
4251
U151

14H
21
1121
UU
2
27
J2
Ul
452

,
,

521J
1051
'441
12707
57.,
5775
H04
4'42
1"10

5547
1120
'151
1J520
, 15'
, 145
1621
U40
15J25

Balance
60011
511"
52045
52045

HI"
U141
16120
31110
31110

'-3
10-3
11-3
12-3

TA-7079-47

FIGURE III-37

SAME AS FIGURE 1II-36 BUT FOR A DIFFERENT BRANCH OF FILE
COSTS SHOWING DATA FOR A DIFFERENT PROJECT

JUMP TO 1 TEM
May

ARC TOTAL PROJECrS
Fundlng:
Total
Cost
Fee
Current tot a I:
218UU
Unfunded total:
0
, 202717
Total contract:' 4U2lU
4U5123
wk-Per Salary Percost NonLabr TotCon rotchgs
1- 1
Ico.blned wlth Week 2 on PSR')

2-1
3- 1
4 -I

Total 1
5-2
,- 2
7-2
• -2

Tot a I 2

1141
4056
5"2
171"
5027
5114
UU
5207
20221

lOU5
100H
14150
44577
lun
lUU
120n
lJOU
50514

12U7
5514
U2U
50240
511
1522
" 10
SUS
24401

U7U
15676
4Un
"117
lJ512
21454
2UU
18761
75413

Balance

Hl12 UIGH
UUI 211744
UHO 2lHOJ
,.750 2U4OJ
U718 21"15
22420 n7U5
22nl 174727
n241 25675.,
77'17 25675.,

, -3
10-3
11-3
12-3

TA-7079-48

FIGURE 111-38

A BRANCH OF FI LE COSTS SHOWING COMBINED DATA FOR ALL ARC
PROJECTS

JUMP ro LINK
M JLV

:cosrs. 02127170 1534:27 JCN
ARC 1970 PROJECr cosrs:
PROJECr 7101 (RADC-old)
PROJECr 7079 (NASA)
PROJECT 8457 (RADC-new)
PROJECT xxxx (ONR)
PROJECT 8444 (Phlll~s)
ARC TorAL PROJECTS

TA-7079-49

FIGURE III-39

INITIAL VIEW OF FILE COSTS UPON ENTRY VIA LINK

ALL

JUMP ro LINK

MHY

:cosrs. 02/27/70 1~34:27 JCN :
t
[. 3-1 ·]OR[ ·PRoJEcr·]OR[·~ wk·]:
[ • Cur rent • ] 0 R[ • PRO J Ecr· ] 0 R[ • Fun dIn 9 :.]:
[ • Cur rent • ] 0 R[ • Un fun d e d·] 0 R[ • rota I co nt • ] 0 R[ • PRO JE cr· ] 0 R[ • Fun dIn 9 :.]:
[·Unfunded·]OR[ ·PRoJEcr·]OR[ ·Fundlng : .]:
[·rotal contract: ·]OR[ ·PROJEcr·]OR[ ·Fundlng : .]:
[·Cum·]OR[·~ Wk·]OR[ ·PRoJEcr·]:
no charges
.OSN.:::1:.RrJ.:::0:.LSP.::0:.OLS.::0:.SCR.::1:.HED.:::·ARC PROjEcr cosr HIsrORY "70
·:.NSW.:::O:.OPR.::O: [H]:lheadlng1:zxbbrDlnK)
ARC 1970 PROJEcr cosrs:
II-

Wk - Per

S a I a r y Per Cost

PROJEcr 7101 lRADC-old)
Fun dIn 9 :
Cost
Cur rent t ot a I: S 14~ ~ S6 4
Un fun d edt ota I : s
0
rot a I cont ract: S 14SH64

r ote 0 st r ote h9sea I an c e

Non Lab r

rot a I

Fee
~S6

.RES:

o
~~H8

S 1~1~222

o
S 1~1~222

TA-7079-50

FIGURE IlI-40

SAME AS FIGURE IlI-39 BUT WITH DIFFERENT VIEWSPECS TO SHOW
CONTENT-ANALYZER PATTERNS STORED IN FIRST STATEMENT
OF FI LE

AL L

ALL
MlL

JUMP ro HEM

v
ARC
JC.

lno

wk-Pel"

PROJEcr cosrs:
Sa I aI" y Pel" cost

PROJEcr 7101 (RADC-old)
H67
J-1
3646
PROJEcr 7079 (NASA)
410
J-1
1025
PROJEcr 8457 (RADC-new)
3- 1
PROJEcr xxxx (ONR)
3- 1
PROJEcr 8444 (ph I II ps)
3- 1
ARC ro rA L PRoJECrS
4056
J-1
100'2

NonL abl"

rot cost rot c h9s

Balance

5556

146 2 3

1517 8

222845

1053

1120

5889 ~

5584

15676

162H

281744

TA-7079-51

FIGURE 111-41

VIEW OF FI LE COSTS WITH CONTENT ANALYZER IN OPERATION,
SHOWING DATA FOR A SINGLE WEEK ONLY.
This' is done by using
the first pattern appearing in square brackets in Figure 111-40.

JUMP TO ITEM
lolL ,

JCN Scratch File. 02/27/70 0.5.:30 JCN
other Peopl,". file.
Specl a I 1I nk.
Vie-change
Iinel

TA-7079-52

FIGURE 111-42

VIEW OF A USER'S FILE DIRECTORY, SHOWING FIRST-LEVEL
STATEMENTS ONLY

ALL

MHY

JUMP TO ITEM
t

JCN scratch Flies 02127170 OU8:JO JCN
JCN dally worklng NOTES.
(Jplan.:zxOn)
,
Flnanclal and STATISTICAL data.
(fund8. : zxOn)
SpeCial operattonal COlt STUDIES.
(study.: zxOn)
Current 1'70 project COST SUMMARIES •
(cost 8. : zxnO)
STATEMENT of WORK ARC Project.
( st at e. : zxCn)
Cost ESTIMATE: ESU "·1" RADC 11/14/" •
(newe8.:zxbbn)
Schedules:
ESU
RADC 11/14/"
( schd •• : zxbbgn)
Cost ESTINA TE: ESU "·1 U ONR 10/U/".
(onre8t. : zxbbgn)
Schedules:
ESU "·11' ONR
'shdon.:zxbbgnJ
ARC: MSR deaonstratton OUTLINE.

"·1.'

1"2"" .

TA-7079-53

FIGURE 111-43

SAME AS FIGURE 111-42 BUT WITH ALL LEVELS DISPLAYED

JUMP TO LINJ(
tHY

AR C PER SONNEl

Present

people
people
New ........................... 2 people
Total .................. ; ..... 30 people +3 more durung t,70
(2/5/70) ....•.•••.••••

Borro.ed.~ ..................... t+

TA-7079-54

FIGURE III-44

PART OF A FILE CONTAINING INFORMATION ON ARC PERSONNEL.
(Not all levels are shown.)

JUMP TO LINK

Present 12/5/701 •••••••••••••• 27
Ball. S .I.f.
Bass. W.L.
Baughman. V.R.
Bosch. F. Van Den
caldwell. M.6.
Carliion. R.A.
Caneres. 0.6.
Church. M.S.
Duvall. W.S.
Engelbart. D.C.
Engllsh. W.K.
Geo11rlon. A.R.
Hardy. M.E.
Harrls. J.M.
Ho~~er. J.D.
lrby. C.H.
leonard. loS.
Melvln. J.lo
Meyer. N.D.

~eople

TA-7079-55

FIGURE I11-45

A VIEW OBTAINED BY JUMPING TO ONE OF THE STATEMENTS
SHOWN IN FIGURE 111-44 AND OPENING AN ADDITIONAL LEVEL

JUMP TO ITEM
MJlY

Meyer. N.D.
Nort on. J. C.
O·Connell. D.F.
Parsley. B.l.
Paxton. W.H.
Rat II f f. J.
Ro •• B.E.
Trundy. M.E.
Van 0 e RI et. E. K.
Borro.ed ...•.••....•....•••..•. 1+ peopl.
Bro.n. D.R. 111201
Lelo. B.
(11201
Yarborough. J.M.
Ne •..........•..••.•..•.••...• 2 peop I e
S yst ems Programmer .•..•••.•.•....... June 1HO
Research Englneer.(Hard.arel ..•.... Aprll 1'70~
Total ........................ 30 people

FUNC nONS

TA-7079-56

FIGURE 111-46

A VIEW OBTAINED BY JUMPING TO THE LAST STATEMENT SHOWN
IN FIGURE 111-45

ALL

AL L

CONTENT ANALYZER

8JLV

['*-secy']: ['*-SUPV']: ['Jsrpro1']:
[ '*-pro1']: [ 'Jtech']: [ 'Jresasst']:
*-hardware']: [, Jso1tware']:
..[,P' *-support']:
[' JUSersys']:
[, *-managementsys'J: ['Jprogrammlng']:
[ 'Jnet work In 10'] :
LINK .... I per sonne I: zxbbbhpi n)

TA-7079-57

FIGURE 1II-47

CONTENT-ANALYZER PATTERNS STORED IN THE PERSONNELINFORMATION FI LE. Each set of square brackets contains one
pattern, used to search for hidden "tags" in statements in the file.

JUMP TO L!Nf(

I.f ardware:

Baughman. v.R.
Engltsh. W.k.

I.fardy. M.E.
Meyer. N.D.

Rat It r r. J.
Row. B.E.
Van De Rtet. E.K.
Yarborough. J.M.

TA-7079-58

FIGURE III-48

VIEW OBTAINED BY USING CONTENT ANALYZER TO SELECT
ENTRIES IN PERSONNEL-INFORMATION FILE THAT ARE
TAGGED FOR "HARDWARE"

JUMP TO LINK

Software:
Bass. W.L.
Bosch. F. Van Den
church. M.S.
Duvall. W.S.
En91lsh. W.K.
Geoffrion. A.ft.
Harris. J .M.
Hopper. J.D.
lrby. C.H.
leonard. L. S.
Melvin. J.L.
Parsley. B.L.
Paxton. W.H.

TA-7079-59

FIGURE 1II-49

VIEW OBTAINED BY USING CONTENT ANALYZER TO SELECT ENTRIES
IN PERSONNEL-INFORMATION FILE THAT ARE TAGGED FOR "SOFTWARE"

JUMP TO LINK
MHY

03/17/70 1525:26 JCN :.OLS=O:.RTJ=O:.DPR=O:.HEO=' SRI
Il nks: (funds. annua I: zxbOn) (8chda. 1: zxbOnh)

:NEWES.

Pro~osal

(for the
P ersonne I Colt s
Dlrect Costs
rotal Estlilated
Flxed Fee
rotal Esttllated
• See attached

cosr ESTlMA rE
two year perlod It art lng 211/70)
1. 213.500
1.QU.1H
Colt
2.106.U'
115.114
Colt plu. Flxed Fee I
2.422.013
schedule.

Personnel a88ulled:

TA-7079-60

FIGURE III-50

PART OF AN ON-LINE COST ESTIMATE FOR USE IN A PROPOSAL

JUMP ro I rEM

01 r'ect Cost s
rr'8vel
Faclltty JConsu It ant s
Re~or't Cost s
rotal Dlr'ect
rotal Esttlllated
F t xed Fee
rotal Esttlllated
J- See attached

,
Costs
Cost
cost plus Ftxed Fee'
Schedules

1.ULI7,
7.280
1.044.072
40.000
1. a2 7
1.0U.IH

2.306.'H
115.334
2.422.013

TA-7079-61

FIGURE III-51

PART OF AN ON-LINE COST ESTIMATE FOR USE IN A PROPOSAL

JUMP TO 1 TEM

FACILITY COSTS
Total FacIlIty Costs:
C.OI\l~ut

1.044.072

er F ac I II t Y Su ~~ort

l ease Cost
MaIntenance and

Ant I cl ~at ed

O~eratlon

853.072
121.572
31.500

IIIl~rovelllent S

Interactive External Core
Conferenclng FaCility
Console SWitching Facility
Univac drUIll Interface
Bryant disc ex~anslon
Dtsc tnterface [XDS 7242)

U 1. 000
12.000
15.200

n.lOo
12.000
21.000
10.000

TA-7079-62

FIGURE III-52

PART OF AN ON-LINE COST ESTIMATE FOR USE IN A PROPOSAL

ALL

JUMP TO ITEM

MHY

, Accessory. Overvoltage Protection. lM·OV-2. lambda. t at 1]0.00.
8457-20. PO A'7"'. April 10. lHO. ekv. Jcomp ..

7 Ad a pt e r . Ra c k. l RA -3. l a.b da. 1 at U 5 • 00. 8457 - 20. PO U 77". Mar c h
31. 1HO. ekv. JCOIDP"

a Augat. 1042-10t thru 1042-1S1O. David 14. Rote Co .• 10 of each color
at S1.10. 7101-23. PO U7475. ekv. JCo.p"
, Amplifier. Video DistrIbutIon. -U1. Srate Valley Sroup thru
Ward-Davis. 3 at 1115.00. PO U71U. 7101-21. January 2". 1HO. ekv .
.. comp ..
10 Amplifier. Pul .. DistributIon. -'10. Srate Valley Sroup thru
Ward-DIVIS. 1 at 1115.00. PO U71U. 7101-21. January 26. 1HO. ekv.
'"comp ..
11 Augat Adaptor Plug, IlClug.). 81U-Ug'. Sterling. Electronics.
at 11.'4. PO AU31!. 7101-21. February" tHO. ekv. JCOIDP"

TA-7079-63

FIGURE III-53

VIEW OF A PORTION OF THE PURCHASE-ORDER PROCESSING FILE,
SHOWING CONTENTS OF INDIVIDUAL STATEMENTS

JUMP ro HEM
HJLY

PArrERNS useful for- sear-chIng (lInk hlddenl
3A outstandIng requIsItions ... no pur-chase or-der yet
( : I : ['PR ']AND -[ 'po ']AND -[ 'IP]:)
18 OutstandIng r-equlsltlons with a pur-chase order(: 1:[ 'po ']AND -[ '''COIllPIP]: 1
1C completed or-der-s
(: 1:[ '''comp''']:
10 Recent changes to thIs fIle: .SINCE (70/03106 01:001:
OUTSrANDING ORDERS
EACH ~N J SECOND LEVEL
fA
CabInet. Stor-age rype. 1000. Shelcor Inc .• 1 at "5.'0.
10140-710. PR A17SOI. May
• U70. ekv.
48 ro Regun CRr·s. 5CEP-" Sunbrlte ElectronIcs. , at "5.00.
8457-20. PO AU777. July 15. U70. lIleh.
4C 8Inder-s. Nylon Post Hanger-. '-HINBl. WIlson Jones. 10 at 12.17.
8457-20. PR A250t2. date. lIleh.
40 Car-d. 2 Input Nand Gate's. 502. Data rech. 5 at 127.00.8457-20.
PR A25006. ber-.
4E Asselllbly. 4 Pr-ong Table Leg. 126. West Coast thr-ough Palo Alto
OffIce Equlplllent. 10 at 136.00 (with 25 per cent dIscount). 8457-20.
4F Mar-ker-s.Cable. PWC-PK-1. l' x P. WH Br-ady Co .• to packs at

TA-7079-64

FIGURE III-54

100

VIEW OF A PORTION OF THE PURCHASE-ORDER PROCESSING FI LE,
SHOWING OUTSTANDING ORDERS LOCATED IN A SEPARATE BRANCH.
Upper part of screen shows a branch containing Content-Analyzer patterns.

All

CONrENr ANALYZER

6JlY

P·Relay·]ANO[qtot·];

TA-7079-65

FIGURE III-55

A CONTENT-ANALYZER PATTERN FOR SEARCHING IN THE
PURCHASE-ORDER FI LE

101

All

JUMP

HEM

IllY

3E
['Relay']AND['71QP]:
S48 Relay. Phillips. Advance. 670SK-2CL Kler-ulff Electr-onlcs. , at
13.70. PO 65148. 7101-22. Apr-II 20. U". lIleh.

TA-7079-66

FIGURE III-56

102

VIEW GENERATED BY A SEARCH ON THE PATTERN SHOWN IN
FIGURE III-55

Sec~ion III
APPLIOATIONS AND EXPERIENOE

The Augmented
1.

Repor~·Wr1tinl

Team

Introduction
Thi. lection discusses the ceneration of large,
contractually required report., since theae teat our
capab11itiel mOlt thorOughly. Smaller, less formal repor~s
involve a creat deal le.s effort) the advantage. dilcussed
below are equally pre.ent, but the problems are
in.1gnif1cant in comparison to the ones that arise with,
tor example, a final re~ort.
It Ihould be noted that much of this discussion is
applicable to proposals and other types ot documents, as
well as reports.

Team Approach
As in many other research groupa, none of our major reports
are written by a .1ngle individual~
Secaule of the broad scope of activities re~orted _.
ranging from management Iy.tems research to the detailed
delien of software implementations •• we U8e a team
approach, involving one or two individuals who
coordinate the effort and numerous other. WhO contribute
sections of material coverin, their particular
I~ecialties.

The present report contaln. material written by at least
six peOPle •• the exact number i. hard to determine
because lome material 1s adapted from ~reviou.
document., using archived file 1 .aved for this purpose.
Allo involved in the proces. are individuals whO mu.t
formally ap~rove sections a. ~hey are written, the
principal inve.tigator, who must ap~rove the overall report
at various staces of completion, and a technical
writer/editor.
TY~icall"
these perlons a. well &s the coordinators are
al.o major contributors to the text of the report.

This list exclUdes other SRI personnel out.ide of ARC ••
editor., illustrators, officers Who mu.t approve the
report, etc. Part ot the report-writing team'. jOb i.
to conduct 11alson with theae people.

103

Section III
APPLICATIONS AND EXPERIENCE

Augmentation bears upon all a.pec~. of this team eftort.
Becau.e of the flexibility of the tools (principallY NLS),
the various in~iv1duall involved use the system in various
individualistic ways.
To 8ome, Nt! i • • imply a super-typewriter; to others, it
il a high-powered stUdy ai~ for searching extstine
material and extracting information needed in the
current report.
Some people prefer to do certain types of work with
hard copy rather than at a console. These people use
NLS for rapid production of hard copy of latest
versions 01 parts of the report; after working on the
hard copy, they use NtS for rap1d 1ncorporation of
their changes and additions into the master files on
line.
To the coordinators, augmentation means the ability to
create an outline of topics to be covered in the report,
with notations indicating persons responsible for writing
particUlar sections, comments as to desired aMounts of
material and depth of coverage, deadlines for successive
drafta, etc.
Such an outline can be continually updated by changing
the baSic plan of the report, adding or deleting
sections, altering deadlines an~ assignments~ etc.; thUS
the outline becomes a continuing statuI report of
considerable complexity, yet with all information
rea~ilY accessible because of NtS features such as the
content analyzer.
As sections of the report belin to take sha~e as NLS
files, links to these files can be inserted at the
appro~r1ate locations in the outline.
Now the
coor~in&tors, examining the status of the report effort,
can jum~ instantaneously from a planning description of
part of the report to a view of the actual work in
progress; converselY, authors workinl on report sections
can examine and reexamine the outline as they work.
It is difficUlt to make a meaningful comparison between
report-writing at ARC and elseWhere, because the process
always depends heavily on tne 1n~1viduals involved and the
organization'. general philOSOPhy about reports, as well as
the facilities available. However, we can safely s.y that

lO~

8ec~1on III
APPLICATIONS AND EXPERIENOE

this kin~ ot close teamwork woul~ be quite im~o.s1blefor
UI without the aucmentation aids that support it. To
collaborate al tiChtlY as we do without augmentation, we
woul~ need an immense amount Of time and a staff of
full-time coor~in&tors, clerkl, and typists.

Advantages

Nt!

As a tool for coping with the mechanical problems of
report writing •• input ot material, a.semblY of
material into a report structure, organization within
the structure, text e~it1nc, an4 final output •• NtS has
proven to be superb. For .ome operations, such as
automatic searcning of thousands of words of text tor
particular words or phrases, NLS is several orders of
magnitu~e moreetfic1ent than paper-And-pencil
technology.
To illustrate the advantages of NLS, let u. briefly
consider a few specific examples.
For entering text, NLS become. a super-typewriter.
This is ~robably the Simplest possible use of NLS.
The advanta,es of NLS over a typewriter come from
several factors.
(l) Backspace-character and backspace·wor~ keYI,
which caule immediate deletion of the last input
character or word.
(2) The user" knowled,. that further correetionl
can ealily be made later.
(3) The availability Of NLS" stUdY eapabilities.
This i. ~he most eritical advantage, since it
allows the writer to 10 back rapidly over What he
hal alreadY written and reorient himself a8 he
moves from one topic to another.

As a tool for assembling, organizing, and
reorganizing ma~erial trom diverse .ourcel (recent
input, ex18~inl file8, etc.) NtS replaces 8uCh
technology as the loole-leaf binder, the blackboard
full of notes, the extra information writ~en on small
Ilips of paper and clipped to palel in the looleleaf

lOS

Section III
APPLICATIONS AND EXPERIBNCE

binder, etc.
In our present state Of evolution, this
is neee.aarily incomplete •• the older
metho~. are used in coordination with NtS,
However, NtS dominates the overall tecnnololY for
orlanizine material and to this extent it greatly
increase, efficiency.
re~laeement

The master copy ot a report in progress is a set
of Nt! files. The insertion of new mater1al as it
becomes available is accompli8he~ quicklY and
SMoothly, and the working material i8 completelY
legible at all Itagel.
The difference between workin, with a formatte~
NtS display and working with a binder of cut,
stapled, paated, and pencil·marke~ typewriter
co~y must be experienced to be appreciated.
Moreover, a complete, fresh,. fUlly formatted
printout of the eXisting draft can generally be
obtained 1n a few minutes, at any stage Of tne
job.
The term "editing" 18 u.e~ here to mean the task of
going throuCh a draft or a section of a draft and
correcting errors of spelling, grammar, style, and
(within limits) content.
our reports cenerally receive two editing passes:
one by ARO's technic&l writer, using NtS, an~ a
second by one of the SRI editing staff using
pencil·an~·paper metho~s.

NLS permit. the augmented e~1tor to work a grea~
deal taster than he could with paper and pencil.
Of course, he works with the knowle~ge that
another e~itor will 10 over the draft and
habitually leave. many ~ec1s1ons up to him.
The advantage. of NtS for ed1tinl stem from two
balic factors •• sheer speed, and the power Of
automatic searching.
The speed is just brute force in aetion: it is
qUicker, for exam~le, to specify the command
"Replace Word," point to a location, type the

106

Seetion III
APPLICATIONS AND EXPERIENCE

new word, and hit the "command accept" button
than it il to make the equivalent marks on hard
co~y.
Using "Jump" commands to locate
cross-referenced locations in the text is
faster, by orders of magnitude, than flip~ing
pages in a binder.
AutoMatic searching for specified strings of
text permits operations that are virtuallY
impossible for the unaUlmented editor.
For exam~le, many writers consistently
m1.spell"certain words. The augmented
editor can exeeute & "Substitute" command
that will correct all ocurrences of several
different consistent misspellings,
throughout a file, in a single operation.
For another example, suppose that halfway
through a lengthy draft, the editor suddenly
findS something that makes him uneasy about
the way a particular term is being used -- a
term used many times in the early portions
of the draft.
The unaugmented editor would be faced
with the prospect of reexamining many
pages of text, looking closely enough to
find all occurrences of the suspect term.
This situation is one that e~1tors
encounter quite frequently, an~ the work
involved is both lengthy and fatiguing.
With NLS, the problem disappears; the
editor uses the content analyzer to find
all occurrences el the term
automaticallY. If he then decides that a
different word Should be used, he can use
a "Substitute" command to make the change
throughout the tile or in specified
portions of the file.
b.

A Note on Structured Text
our use of ".tructured text" -- i.e., a format that
reflect. hierarchical relationShips among "statements"
or paragraphs _. is somewhat controverSial with lome of

~07

Sec~ion III
APPLICATIONS AND EXPERIENCE

our

re&~ers.

Many of NLS'. Most valuable features depend upon
structured text. Moreover, structured text has
advantages of 1ts own. The special formatting carries
information that i. not 1n the text 1tself, thus
increaSing the overall "bandwlCth" and perm1tting
greater economy in writing.
structured text is a direct consequence of the use of
the computer a. a writinl meaium, just as standardized
punctuation re.ulte~ from the introdUction of movable
type as 'he medium tor pUbliShing. Ho~efullY.
structured text will turn out ~o be only the first step
in the development ot new ways to show, by formatting
and other nonverbal means, various relationships among
the unit' of information that make up a document.
c.

A.sembly ot Reports
As noted above, NLS 1s used to put together material
from various sources to prOduce & complete draft. This
raises the ~os8ib1litY of keepinl on hand a large
collection ot material that de.cribes our work in its
various ,specta, frequently updated 10 that at any time
we can extract what 18 needed for a report. Thi.
material, ideallY, would make up a very sizable part of
eaCh report and woUld require only simple rewriting,
thUS greatly reduc1ng the labor of report-writing.
This idea has been with Us for years, and we have made
lome progress in im~lement1nl it. TO the extent that it
actually happens, it is very worthwhile; however, only a
very small part of a typical report is actually done
this way,
In the present report, tor example, only the preface,
the bibliograPhY, and the appendix are taken directlY
from existing material. Larger portions are derived
trom existing material, but with complex and
extensive rewriting to luit the needs of this report.

problems
The problem, of aUgmented report-writing tall into several
categories, descr1bedin the following section ••

108

Section III
APPLICATIONS AND EXPERIENCE

To some extent, th~ problems are not merely
report-writing problems but aUlmentatlon problems, l.e.,
problems ereateO by aide-effects of augmentation u~on
the total ARO .ystem.
a.

Technical Problems
The simplest problems are technical in origin. For the
mOlt part, they seem not to relate to gaps in technical
capability -- i.e •• "missing features" -- but rather to
inadequate performance of the technical systems on which
we have come to depend.
As noted elsewhere in thiS report, system response is
degraded when several users are working simultaneously;
because of our team approach to report-writing, this
degradation tends to be wors~ at the worst possible time
-- just when several people are trying to complete their
contributions to the report.
A more critical prOblem arises from technical
limitations on file storage. Two storage media, disc
and tape, are available for report purposes.
Tape, in the current .ystem confiluration, ia
inconvenient &nO ean only be used tor lone-term
backUp copies.
In the last few months regUlar procedures have
been established for tape archiving; so far,
however, relativelY lew files have been saved on
tape in such a way &. to be reasonably accessible.
Disc .torag8 8~aceil severely limited. Reports take
up a rreat deal of space compared to other types of
tiles 1n use by ARC, while at the same time they are
less usetu11n day-to-day work by ARC personnel.
Work on a report generally inVOlves considerable
Shuftling of files in order to obtain space for
the new report files) tile. not related to the
report are moved into out-of-the-way locations,
and we sometimes lose track of them in this
process. Duplicate copies are destroyed to make
more room. and here there is a chanc~ of
inadvertently destroying the last copy of a file.
FUrthermore, if only one copy of a file ia kept we

109

Sec~ion III
APPLICATIONS AND EXPERIENCE

face the pos8ibility that a system error will
destroy it.
The actual 108s of a file has become a
relativelY rare occurrence, as users have
become aware of the problems and develo~ed
habits and ~roeedures to safecuard their tiles.
However, we expend a great deal of time and
energy on these safeguarding measures, and this
.eriously slows our report-writing efforts as
well as all of our other on-line work.
When work on a report is finished (or ~emporarilY
halted) a reverse process takes ~lace: the report
file. are hidden away, with a risk of 10.1ng them.
b.

prOblema of Explaining the HAUgmentation Culture"
NL! and our other augmentation systems are part of an
exceedingly complex total system that includes all of
our set procedures for dOing things, our management
methods, our goals, and our strategies and priorities
tor doin, research. This total system is the tangible
part of the "augmentation culture"; the intangible part
consists of personalities, emotional interactions,
intellectual orientations, etc.
It is a tiny and incomplete culture with a brief history
-- a laooratory model. Nevertheless, like most cultures
it is 1neompletely understooa by the people inside it.
The long-term aide-effects of any innovation are
unpredictable, and occasionallY such side-effeets give
rile to ~roblem8.
The prOblems of the augmentation culture affect allot
our activities to varying Oegree.; with reports,
however, these problems are multiplied, because the
central task i. (in princi~le) to eXPlain th1s same
culture to a reader Who hal no d1rect experience of it.
In practice, we rarely or never attempt a com~lete
instead we describe various im~ortant
aspects of our work, one at a time. Unfortunately, this
leads to a 1ra,mented picture in whieh the true eontext
of our work -- a whole-8~ltem approach -- tendS to
become attenuated.

ex~lanat1onJ

110

Section III
APPLICATIONS AND EXPERIENOE

problema ot Organization and Technique
Practically nobody likes to write reports. What 1.
worse, very few people are capable of writinl gOOd
reports on difficult topic. without very great
expenditure. of time and energy. At ARC, we have
re'ponded to these problems in several way ••
(1) We have developed an elaborate system of
computer a1ds for writing (al well &s other
purposes).
(2) We have negotiated our contracts in such a way
a8 to require a minimum number of report ••

()
we have used live demonstrations and films to
supplement the communication lunction of reports.
(4) We have experimented continually with different
ways of organizing a report-writing team to function
within our culture.

Some commentary on these responses may
illuminate the problems.

serv~

With regard to the first item, the computer aidS are
magnificent (&1 described above).
Reducing the total number of report. required ia
debatable; 1t can be argued that it would be ealier
and more effective to produce small reports at more
frequent intervalS, thu. making final reports much
leS8 critical and easier to write, lince they could
lean upon the information contained 1n recent short
reports.
It is prObablY true that films and live ~resentations
are more communicative of what we are dolng than any
wrltten report could be. However, they do not lessen
the ~eman~ tor lood reports and they cannot be stored
on line for computer access.
Experimentation with ways of organlzing the reportlnc
effort will prObably be the mOlt fruitful way of
SOlving the prOblems.
We are It111 only beginninl to develop a lood

III

Section III
APPLICATIONS AND EXPERIENOE

organizational ap~ro&ch to the report ~roblem.
The present report i . being produced under a
rather elaborate ~lan of highly ~istributed
authorship with a lingle individual as p
ner,
coordinator, and "pusher."
At this writinl, our principal difficulties are in
getting all the various authors to finish their
contributions on t1me and in sticking to anyone
scheme tor the organization of the many sections.
Although early analysis may well be miSleading,
the situation luggests that we have concentrated
too hard upon the distribution of respon5i~11ity
for writing sections, thUS neglecting other
equally important requirements for a workable
delegation of authority, better forecasting of the
effort involved in various phases of the work,
better timing, etc.
E.

The Aucmented presentation
1.

General
When & groue of peoPle meets for purposes of discussion,
briefing, Planning, etc., it is often necessary to
communicate & prepared body of information to them for
reView, orientation, or tutorial purposes.
The usual mOde in such a session (Which might be a
meeting, lecture, leminar, or any other sort of
gathering dealing with any sort ot SUbject from poverty
problems to .ales policy to biochemistry) is for one
person at a time to .peak, with various decrees of
preparation, an~ various levelS of sup~ort from
auaio-visual ai~s. Effective use of these &1d5 usually
requires special pre~aration of ~he materials (tapes,
8l1~e8, charts, etc.), or special effort at the time to
write on a blackboard or image-projector 8Uface -although occas1onallythere is an opaque projector or TV
circuit that enables the speaker to integrate lome of
hi. normal working mater1al into his presentation
without Ipeeial preparation.
To any Of us who are sealone~ user. of NLS,
participating in conVentional presentation processes has
become even more painfUl than it Was before we became
accustomed to augmentation. we have grown 80 uaeO to

112

Section III
APPLICATIONS AND EXPERIENCE
the ability to move around ealily wi~hin any of our
informaton base. (~e.1enl, documentation, reference
material) and to Iwitch QUiCklY amone the many u.etul
ways ot viewing the information,that we wish that sort
Of ca~abi11ty were available to the Ipeaker.
If a clo8ed-circu1t TV Iystem 1. available to di.~ribute
the compute~-dlsplay 1macel to a group, then a speaker
with on-line acees. to a computerized information system
can indeed make an "augmented ~resentation."
2.

EarlY Experimentl
In October 1967 we let up a s~ecial conference room, with
TV monitors arranged so that lome twenty peo~le, sitting
around a rectangular table, could watch an augmented
presentation. We inaugurated the facility with a two-day
meeting between our staff and the technical monitors from
the four agencies then sponsoring our work.
At all times durinl the meetinc, the s~eaker sat at the
Nt! control console (a position at the table that had a
keYbOard, keyset, and mouse in a~dit1on to a monitor)
and could instantlY access and display information in
any of our total collection of f11es. Some of the
material was specially prepared reference material for
agenda purpolel, but most of it was our actual working
material -- ~lann1ng, de8i«n, documentation, and
scratch-note files.
A trial acen~a wa. prepare~ ahead Of time 1n an NtS
file~ but from the outset it was subject to ad hoc
review and modification.
To give the partici~antl a better mean. of talking about
the displayed material (i.e., voicing questions,
challenges, or IUlle.tiona), each had access to a Mouse
which coul~ control a second tracking spot on the
sereen. This spot was u.ed as one would u.e a wooden
pointer to draw attention to an item on a blackboard; 1t
was of different shape from the control Ipot used by the
s~eaker, so it was easy to keep traCK of who was
point1nl.
Thil mode of running a project-review meetinc proved
. very rewarding. We subsequently u.ed the setup
frequently ~or special prelentat1on. (mostly for

113

See~ion III
APPLICATIONS AND EXPERIENCE

visitors), also with great succels, anO perhaps a dozen
times for work1ng meetings of our group. In mid-1968 we
dilmantled the setup, since we needed the space tor
expanded shop area and the TV monitors tor more NLS
conSOles.
To let at le&.~ the capability tor a larger audience to
view a display, we have had a flexible arrangement for
attaChing two or more TV monitor. to one NLS eon.ole,
We hola many demonstrations and presentations this way,
for groups up to about 20 people.

Development of Improved Capabilities
By mid-1968 we had acquire~ some special-effect. v1aeo
equipment that cave us the following capabilities:
Video monitoring and switching. An operator monitors
images generated from a number of sources and can select
from these the silnals to be channeled to various
destinations.
Video mixing: TWO lignals can be blended, with
adjustable strengths, to superimpose two images.
Signal fading: A selected signal source can be slowly
diminished or atrengthened to achieve smooth, gradual
tranli.tions between image-compolition state ••
Image splitting: The .ereen image is divided
geometricallY into two parts, each being the
correspondinl trame part from a different image source.
A horiZontal or Vertical dividing line can be set at any
pOltion, or a rectangular inset can be made in one
corner of the frame and it. size adjusted.
We also located a NASA-owned EiOophor Video Projector at
the nearby Ames Research Center and were fortunate enough
to be able to borrow it on several occasions. It projects
our video images onto a large sinlle screen with very high
Quality and is suitable for ~resentations to large
audiences.
As we were
learned of
Films Inc.
image (and

11k

experimentinl with augmented presentationl~ we
a special teChnique developed by W. A. Palmer
of San Francisco for directly t1lminc the video
sound trom & microphone cirCUit) to produce a

Section III
APPLICATIONS AND EXPERIENCE

motion picture. On a number of occasions, we have arrange~
for a camera ana operator tcfilm our presentations.
We also developed special coupling equipment enabling us to
lease voice- and video-,rade transmission channels to a
remote site. From the remote site, we can then use our
computer system to support two regular NtS consoles and any
associa~ed video-control and -projection equipment for
conducting full presentations.
i.

Large-Scale Augmented Presentations
We successfully used the full range of these techniques in
two large-seale presentations -- in December 1968 at the
FJCe in San Francisco, and 1n October 1969 at the annual
ASIS meetin« in San Francisco.
These presentations were set up with the main speaker
seated at the front of the aUditorium, at one of our
relular NLS consOles, to one aide of the large screen
but in full view of the audience. He had a microphone,
and could directly address them as though delivering an
ordinary speecn.
A TV eamera mounted near him caught a full-size face
View, and a "prOduction manaler" for the
presentation, seated at the rear ot the aUditoriUM
with SWitching, mixing, and frame-splitting control,
could put the face view on the screen tor a much more
effective feeling of direct contact between spea~er
and audience.
When the speaker chose to use NLS, and turne~ his
head slightly to see the NLS display screen, the
projeete~ image would be 8witched to snow his
computer-di.play view to the audience.
Frequently, 1maces captured on mObile TV cameras in our
laboratory at SRI were 8witche~ onto the projection
.ereen, 10 that the ~resentation coulQ' include both a
tour of our laboratory and participation from people
located there.
Four different re.earchers at the laboratory worked
during the pre.entation at consoles in our work room
(various shots during the pre.entation verified that
they were there in the backlround, actually using the

115

Section III
APPLICATIONS AND EXPERIENCE

consoles whlle the rest ot the show went on1.
At various times, the full face of one of the four
was brought on screen, dialogue went on between him
and the m&in speaker to introduce him and his topic,
and then he took over and ran a portion ot the
presentation 1n much the same manner as the main
speaker had been doine -- the screen bein, able to
show alternate (or split and/or mixed) images ot him
and his display-screen image.
For both conferences, the complete presentations (each
about one hour and forty minutes in length) were ca~tured
. on l6-mm film (black and white with optical sound). The
ASIS film is the better of the two, and we have made eight
oopies that have been in active loan cirCUlation Since tne
first of the year. It 1s better than any earlier
self-contained form for conveying an overall picture of our
augmentation system. The eopies· have been loan~d to lome
70 organizations, incluOing several in Canada and one in
France, and we hear of many repeat showings put on·bY a
borrowing organization as a reSUlt of the response of the
initial aUdience.
one must see one of the movies to appreCiate the
differenee between the augmented presentation system and
what could almost have been substituted for it .- e.g.,
a ~rev10UslY made set of slides Of all the
display-screen Views, and a very fast·actin, and
large-capacity slide-selection system under control of
the speakers.
For clas.room lectures, for project brief1nls 1n
connection with complex sy.tem-developmment· projects,
for presentation of complex iSlues to a reviewing body
(such a.a conlress), etc., these extensions of our
augmentation system toward an augmented presentation
system seem extremely promising.
We intend to puSh further development of these
techniques for application by smaller groups within a
system-development team -- group meetin«s for
brainstorming, plan and design reView, etc.

Conclusions
Alsuming tn,t technique. similar to ours are bound to

116

Sec~1on III
APPtICATIONS

AN~

EXPERIENCE

evolve for widespread use in inten8eintellectual work both
by individual' and in small crou~l, it 1s Quite obvious
that extenSions to the techniques, ,uch as described above,
for augmenting presentation. tolarcer croups will become
quite important. Although pursuit Of pre.entation
techniques is not our central loal, we woUld like to
encourage a general appreciation ot it. potential.

l17

IV
A.

THE NETWORK INfORMATION CENTER

Overview of the ARPA Network
1.

Basic Description
The A4vanced Research projects Agency (ARPA) of the
Department of Defense has inaugurated a novel experiment,
the purpose of which is to explore the possibility for
fostering effective, real-time cooperation and interaction
be~ween approximately fourteen of its contractors, all of
Which are doing research on the development of advanced
information-processing techniques.
To carry out this experiment, the Agency is in the orocess
of establishing the ARPA NetworK, which is a
data-communication network linking the computer facilities
Of these fourteen research centers.
Each of these centers has a coord1nate~ collection of
resources -- both technological resources such as
computers, storage facilities, input/output devices, ~nd
softWare systems, and human resources such as knowledge,
skills, and methOdologies.
It has been necessarY, in ~ener&l, for these centers to
engage in wasteful duplication of basic resources and to
live with adverse restrictions on tne numDer and quality
of special-purpose resources available to the
researcners at anyone center. But wide-band
connections between centers will bring many -- pernaps
eventually all _. Of any centerls computer resources
within the reaeh of every user in the Network.
Two basic domains of work are involved 1n thiS experiment:
(1) Development of technology tor providing
intercommunication between programs in the different
centers
(2)
Integration of the ~istributed resources of these
centers into new patterns Of support for users of the
Network.
1n~ormation·network technology i8 described in a
set of companion papers presented &t the 1970 Spring Joint
Computer Conference (see Refs. 20 through 24). The
following simplified description is intended as background
for the discussion of the Network Information Oenter
contained in SUbsequent sections.
Det~11ed

119

Section IV
THE

NET~ORK

INFORMATION CENTER

Host-to-Ho.t Communication
Each research center, or Network "nOde," will provide
access to one or more local computers dedicated to research
on information-processing techniques. These local
computers are called "hosts."
As part of ~he Network, ARPA supplies to each participating
center a small, specially programmed computer called an
Interface Message Processor (IMP) which is connected to the
host (or hosts) for that center.
The IMP provides each hOlt computer with a uniform
functional interface into & network consisting of
SO-kilobaud transmission lines leased trom telephone
companies.
Each IMP con~rol' traffic to and from its host or hosts,
as well a. traffic along the Network channell. AS far
as each host i. concerned, the Network may be treated as
a mUlti-port black bOX with IMPS serving as the ports.
Very much like voice-path connections between users of a
telephone system, one-way message paths called "links" may
be set up between specified hosts by the IMPs.
For example, "Link AD3" might de.ignate a path from HOlt
A to Ho.t D difterentiate~ from other Possible links
from A to D by the label "3."
Special Network-monitor programs reSident in each
computer activate such links an~ negotiate among
themselves to allocate them to s~ecifie
communications-path purposes.

nos~

The "0" links are reserved for control messages directlY
between the monitors.

program-to-program Communication
Program A in HOlt A may aSK for a communication link to be
establiShed from it to Program B in Hoat B. As currently
Planned, the following chain Of operations wOUld occur:
program A SUbmits the request to Monitor A.
Monitor A uses ControlL1nk ABO to necotiate this with

120

Sec~ion

THE NETWORK INFORMATION CENTER

Monitor B. After Monitor B ascertains that Program B is
available for such communication, the two monitors
together assign one of the AHn links to this
communication purpose (for example, Link ABh).
Monitor A verifies to Program A that its request has
been fille~, and that Link AB4 is now connected to
Program B.
Program A is now linked to Program B bY what appears to
the two programs asa private communication channel
between them; any data Bent out by Program A via Link
AB4 is delivered directly to Program B.
Any sort of information that could be sent between two
programs within the same computer may be lent along such a
channel.
For examgle, Program A might sen~ control information to
Program B asking it to set up & reverse link, and to
transmit along that link the results of processing a
File B that resides within Host B. or conceivably,
Program B could be asked to linK to HOlt C to get an~
process File C.
Program A could be an interactive preprocessor serving a
User A Who i8 connected directly and locally to Host A
and for whom most ot the service i. being supplied by a
Program B. Program B could be & soPhilticated user
5ubsystem such as Mathlab at MIT, the Culler-Fried
system at UCSB, or our NLS.
In any of the more SOPhist1cate~, display-oriented
Subsystems, User A'S hardware could be different from the
hardware used at Program B'. home site.
program A might provide an adaptation for the partiCUlar
terminal hardware being used by User A.
It procably would also provide some of the local
interactive feedbaCk such as character echoing at a
full-duplex terminal.

121

Section IV
THE NETWORK INFORMATION CENTER

Some of Our
1.

pros~ect~ve

Ules for the Network

Basic Processes
A variety of program A that 1s likely to be established
early at each host is a process that allows a typewriter
terminal at that host to link to the timelharing executive
in Host B.

Such a process woU10 enable User A to log into the Host S's
timesharing system and work as though he were a local user
at Site B, using any of the typewriter-oriented SUbsystems
that may exist in the B system.
2.

Bootstrapped System-Transfer
For our first experiment in Network usage we have
established an interface to the University of Utah"
Network host, a PDP-10 computer, so that a programmer at
one of our consoles can use the editor and loader-oeougger
at Utah to develop and check out programs to be run for our
special use.
This is the first step in a sequence of experimental
uses of the Network that promisel to nelp us
significantly in preparing to transier our software
systems onto a new PDP-10 computer system next Fall.
In carrying out this experiment, we will be coordinating
a very large collection of technological and
methOdological resources 1n a novel way.
We are prOducing mOdified versions of all our
language compilers. These new versions will still be
run on our XDS9~O system but will produce object code
for the PDP-10.
Our programmers will compose, modif~J study, and
compile the software being written for the PDP-10
using onlY the resources of our own Oenter,
principally NLS ano the speCial compilers.
Then, when there is need ~o test ·a piece of the new
SOftware, they will activate Network link. to put
them in communication with Utah's PDP-10 executive
system. The compiled code will be Ihipped over the
Network to Utah. where it will be loaded and

122

Section IV
THE NETWORK INFORMATION CENTER

execute~.

Still working at our on-line consoles, our
programmers will be able to debug the object code
using the PDP-10's debugging facilities and, then,
rapidly switch back to NLS to correct the source code
as well.

In this way we plan to bootstrap the development of &
PDP-10 version of Nt! so that we can be up and running
very quicklY when our own PDP-10 is installed. We ho~e
NtS will have been entirely written and mostly debu~ged
by then.
The entire power of NLS will have been used
during cyclic Itages of converting/rewriting, debugging,
source-code upaating, and documentation.
It is interesting to note that another PDP-10, which could
be used for program checkout via magnetic tapes carried
back and forth, is located just down the hall from our
present computer. However, it promises to be significantly
more convenient for us to use Utah'. PDP-10 connected
directly to our computer via the Network.
~e can communicate our ~rolram8 to it mucn more
convenientlY; and, while sitting at our own consoles to
·debug the programs, we can quiCklY switch to local Nt!
to inspect or modify the source-cooe files or to enter
no~es and documentation.

centralized File Archiving
Another straightforward way we can benefit from the basic
Network is by ~sing the file-storage system at the
University of California at Santa Barbara as our
file-arChive resource.
Besides providing service to the local ARPA project, UCSB's
host IBM 360/75 is the central resource of the University'S
Computation Center.
IBM 23lk disc-file transports, program. to store and
retrieve files, on-duty operators to run back-up dumps
onto magnetic tape, and aceounting and billing
procedures to nandle serviee to miscellaneous users are
all part of this resource~

We consider using their file-storage sf.tem as our

123

Section IV
THE NETWORK INFORMATION CENTER

file-archive resource.
We woula interface this archive .ystem to our On-Line
Sy.tem se that the response to a call for some service
in storing or retrieving an archive file could function
exactlY as though we were .toring anO managing the file
locally.
other Network user. could also u.e this file-archive
system either by interfacing to it directly or by
interfacing to it through us.
This begins to sugges~ lome of the ~ower inherent in
the network concept, since the number of subsystems
available to each network participant can "pyramid"
on the basis of a relatively small number of
interfacing tasks.
We COUld gain con.1derable economic advantage from .being
able to share with many other users the capitalization and
operat1ng-aecount1ng expenses involved in providing a basic
disc-file archive system.
Installing and operating such a service ourselves would
be a distraction from how we want to u.e our manpower -but we have to have ihi. capability.
Being able to use the Network to share this resource
could be an important benefit to us.

Data-Sase Management service
We a180 hope to utilize one of the big-compu~er host. with
large discs and an operating staff, to help install ~
commercial data-base management system tor use by us and
the rest of the Network.
Again, the interface procesl WOUld resiae in our hOlt and
give our users a data-base management service that ~ney can
interact with &8 it it were a local service. None ot the
protocolrequ1red to fire up the remote system, pro~erlY
format service requests, an~ specify delivery ot it.
product. need involve our ulers.
To pre.ent our users with uniform conventions over all
of our ~ifferent service functions, we would want to be
able to compose service requests in an NLS file using

124

Section IV
THE NETWORK INFORMATION CENTER

our own particular syntax.
In addition, to take advantage of NLS power in stUdy and
we would want to have Query results
,converted into NLS-file form so that they can be
integrated d1rectly into our regular working files.
mo~if1cat1on,

Need for a

~etwork

Information Center

To pursue such relatively straightforward uses of the Network,
a user will need to know answers to such questions as:
What resources are available within the Network?
What conditions are associated with the use of a particular
resource at a given no~e?
What interfacing 1s required to couple to this resource?
WhO should be contacted to arrange for this?

More generally. each site will also neeo answers to questions
about other nOdes and about the Network such as the followinl:
What are the hardware and software resources?
What are the research activities?
What are the operating instructions for a given resource?
When will a prospective resource become available?
Who 1s interested in new display systems?
Who went to a particular conference?
WhO else was interested in NIC Memo 7721?
The whole Network experiment will consist Of negotiating,
implementing, and operating many such arrangements. To carry
out these negotiations effectivelY and to aocument the results
of Network experiments, Network participants need access to
information of the k1nds mentioned above al well as a medium
for reeord1nl their experiences; it is the role of the Network
Information Center (NIC) to service tnese needs.

125

Section IV
THE NETWORK INFORMATION CENTER

NIC
1.

Develo~ment

Activity

Backgroun~

our involvement in the ~evelopment of the Network
Information Center belan shortlY atter the official
announcement of Plans to proeeed with the development of
the Network itself.
Realizing the importance of this information center to
the success of the Network experiment. we volunteered to
undertake the task of designing. implementing, and
o~erating the NIC.
Since then, we have been graduallY evolving and
implementing plans for providing a coordinated and usetul
collection of services to Network participants. This has
proved to be a far more difficult task than we originally
envisioned tor several reason ••
The Network will provide a completely unfamiliar work1n«
enVironment, and it is tar from Obvious just what kind
of information services will be most conducive to
effective action within that enVironment. our contracts
have contained no speCific guidelines as to What form
NIC services shOUld take, and other Network participants
have been equally value and often contradictory in
voicing their expectations with regard to the NIC.
We also have had no previous experience in prOViding
information services to users outside our own center,
and have learned the hard way that this kind Of
operation require. a kind of organizational structure
an~ management different from that Which had been
appro~r1&te 1n the early year, of our research
activities.
In designing the NIC, we were conscious of the fact that
more was needed than just cood library facilities.
The technical sophistication of the tools we ha~
available and of the users we would be servin,
~emanded that we seek to make it POSSible for this
community to derive significant adv,ntage8 from the
Network in term. of increaseO communication of iOeas,
deSigns, criticiSMS, an~ comments on needS and
possibilities.

126

Section IV
THE NETWORK INFORMATION CENTER

we recognized the challenge involved in fostering an
environment that would encourage increased
collaboration among individuals and groups at
different nodes, and felt that the NIC would bear
much of the responsibility for setting the direction
of efforts to meet this challenge.
And 1n designing the NIC we were aware that it would not
be SUfficient merely to provide cood technical features,
but that the design must reflect the Kind of coor~inated
user-system I aervice-system interface that we have felt
is so im~ortant in the bootstrapping approach to the
development of our own augmentation aids.
2.

orientation
In order to gain perspective into what was expected or
desired in the way of service from the NIC, we talKed with
a number of Network Site managers a. well as with library
science specialists.
MOlt of the managers were uncertain about the nature and
extent of their probable participation in the Network
and did not know What they wanted from the NIC.
What expectations we were able to uncover frequently
showed extreme differences from person to Derson.
Some thought that there was little need for a NIC,
while other. thought that the NIC should supply
initiative and lea~ership in the development of
overall Network conventions and methodololies.
Some thought that the NIC was going to serve &s a
intermediary for handling working communication
between hosts, providin« tele~ype bUffering and
spooling operations, or that it WOuld be responSible
for specifying protocols for ~ommun1cat1on between
different types of terminal ~evices.
The types of service to be provided, in terms of
media for storage of dOCUments and metho~s of
enqUiry, were perceive~ at pOints all along the
continuum from Qompletely off-line to eom~letelY
on-line.
And the types of retrieval capabilities envisioned

127

Sec~ion

THE NBTWORK INFORMATION CENTER

ranle~

from fUlly automatic to fully manual.

However, one reasonably consistent picture ~1~ emergel
almost all the managers contacted ex~ressed & concern
for the ~oor state of documentation within tneir
projects and a hope thai the NIe would be able to helP
them not onlY with Network-oriented documentation but
with their in-house needs &s well.

The need for improved documentation was seen not only in
the area of "formal" documentation, such as user manuals
and reference cuides, but also 1n the realm of the
"folklore" that evolves around every system and that is
an absolute necessity for making effective use of a
system.
Some managers expressed the opinion that a remotely
located documentation-aid system might receive
heavier use than one at their own site because there
would not be the usual conflict between u.1ng the
local facility's resources for Qocumentat1on as
opposed to us1ng them for programming or other work,
the latter always receiving higher ~riority in most
researchers' mindS.
Part of the "folklore," or informal documentation,
would play the role of elearing house for
communic&~ion on defect., bugl, neecs, possioilities,
etc., and would help to provi~e feedback on the
statuI and accecptability of existing or needed
procrams and formal documentation.
The outcome of these diSCUSSions, and of analYsys of the
several tentative NIC designs that resultec, has been to
take the pOSition that we shoulC initially prov1de Network
users with a few relatively basic services and let the
development of the "optimum" NIC evolve in a natural way as
u,ale experience builOs up.
ThUS, we are planning to help Network users gradually to
apPly our concepts, conventions, tools, and teChniques
to relevant aspects of their own working enVironments,
While at the same time providing them with a reasonable
initial corpus of reference material.
We will m.ke every attempt to encourage and facilitate
feedback from these users 80 that we can expand NIe

128

Section IV
THE NETWORK INFORMATION OENTER

services to meet their
exchange.
E.

nee~s

for information access and

Ourrent NIC Plans
l.

Introduction
We aim to be prepared to provide certain basic types ot
services through the NIe, each of which will be expan~ed or
elaborated 18 neeaed. This approach il our way of
accommodat1ng the uncertainty about the user-population's
information activity descriced above. This section
outlines the measures we have taken to accommOdate these
basic serviee needs.

Basic Library Services

The foundation of NIC operation must be a flexiole library
service, the development of Which requires us to:
Accumulate a physical colle~tion of information items,in
various sizes and media, and then store them in a secure
and orderly manner.
Provide a catalog in which the descriptions of these
items are maintained, and from which can be Obtained the
keys (clues), necessary to locate the physical item ••
Provide indices and associated query procedures to aid
users in finding catalog items of interest.
provide direct me&ns for a user to obtain access to
documents for which he possesses keys, ana enable
"browsing" where possible.
PrOvide direct reference help via two-way dialogue
an expert.

wi~h

We will initially provide this basie library service. in
ways not too dissimilar to those used by other special
inform&t1on centers ana clearing houses.

That 1s, we expect to be interacting with users through
mail and voice-telephone channell, to be distriDuting
hard-copy indices &nd catalogs, and to be mailing
s~ecial query-response listings and references.

129

Seetion IV
THE NETWORK INFORMATION CENTER

On-Line Services
We are also seeking to harness com~uter. ~isplay. microform
and communication technologies to elevate what a "library"
represents to its community towar~ new levels of
"augmenting the intellectual ~roces.es of communication and
collaboration."
To this end we are taking special measures toward "the
way we do our librar~ work here" -- the nature of the
collection, the form of catalog an~ indices, the
procedures tor developing and maintaining them, ete.
Ana we are investigating ways of improving s~eeial
aspects of the user's interfaee to the NIC -- his query
and browsing techniques, his means for doing
bibliographic work, his means for publishing communiques
to the community, hil means for staying 1n touch with
current aetivities, ete.
As the technology and methOdology of Network utilization
develop, there will be a rapidly increasing number of
widely distributed terminals througn which a person ean
gain on-line aece.s to the NIC, and we are taking very
strong measures to be able to serve them.
Be.idee developing the services ~eser1bed below, we have
inve.ted a creat deal of effort ~owar~ increaSing our
service capacity with special system studies and the
installation of a bank of external core and three
high-speed SWapping drums; and this £&11 we will be
shifting to a new computer (see Section II).
We are prepared to supply some on-line query service as
soon as the Network can support host-to-host full-duplex
typewriter transactions ~- the simplest kind of general
Network usage. Continual development of the variety and
sophistication of the service will follow lines discussed
in the re.t of this leetion~
During the next year mOlt remote on-line users will be
served by TODAS, i typewriter-oriented version Of our
On-Line system (NLS).
Initially, both access to our SUbsystems and the number
of Network users that we can aceommodate will be quite
restricted, but we plan for steady improvement in both

130

Section IV
THE NETWORK INFORMATION CENTER

interactive quality and amount of the .erv1ce available
to Network ulers.
We feel ready to.support three Network TODAS users nowJ
when installation Of the new drum. an~ external core is
completed late this .ummer, we might be able to increase
this to fiveJ and, depending upon the response possible
using our new computer, we may be able to support as
many as fifteen by the end of the year.
ThOle sites having Oisplay terminals that can emulate
typewriters with high transmission rates will be able to
get fast-response from our typewriter-oriented system -service that is really quite respectable even without
direct screen-selection means such as a mouse or tablet.
We are currently mooifying an Imlae diSPlay console for
remote use on our system, and we hope that it will become
fully operational by early fall.
It will eventually have full NLS capabilities inclUding
our stan~ard mouse and key.et input device., and any
other Network user possessing such a terminal could
quicklY avail himself of similar service.
As soon as we have tran.ferre~ our present systems onto the
new PDP-10 computer an~ have achieved rea'onable stability
1n system reliability an~ rel~onle, we intend to
concentrate upon developing tecnniques to permit general
use of our NLS capabilities on a wide variety of remote
di.p1ay terminal., and we anticipate having a growing
Network load of this ty~e bY next summer.

131

V CONOLUSIONS, RECOMMENDATIONS, AND PLANS

In~roQuction

Our experience in Oeveloping and using augmentation systems,
lome of Which was Oelcribed in Section III, gives us
confidence in the validity of our long-term Roals and approach
to augmentation re.earch. We are beginning to have strong
feelings tha~ our efforts, still proceeding unOer ~he ,u10ance
of our bootstrapping strategy, are on the threshold of
yielding significant payotfs.
The concept of augmentation systems is no longer in question
-- such system. are bound to come. The only uncertainties
involve the rate and direction of development and ~hat can be
~one to improve both, so as to foster more efficient evolution
and ensure the earliest possible application of these systems
to solving real problems facin, societ,.
This section summarizes the conclusions we have ~rawn from our
research program and outlines some of our plans for future
activities.
B. Conclusions Relevant to other AUlment&tion-System
1.

Oevelo~er8

General Comments
The experience we have had in setting up the Augmentation
Research Center facility may not be directly apPlicable to
other system Oevelopers, but there .till may be something
to be learne~ from our accomplishments and disapPointments
in implementing some of the components ot our system.
In this section, therefore, we will take a look at our
facility, evaluating some of its unique aspects and
discussing some of the major prOblems that have been
encountereO in it. eVOlution.
This facility is described briefly in Section II-B, and
a more complete description is contained in Ref. 18.

Accomplishments
a.

Display System
(1)

General
our display system uses centrallY locate~
display-generating eQu1~ment and a closed-circuit
television .,stem to distribute images to individual
consoles.

133

Sec\ion V
CONOLUSIONS, RECOMMENDATIONS, AND PLANS

Tnis approach to

di'~lay-.~.~em desiln was chosen
on the basis of COlt an~ flexibility, and a
~etailed description of the system and of
conli~erat1on. that went into it. desien is given
in an earlier report (Ref. 11).

After con.iderable experience operating this system,
we are still plea.ed with the basic approach.
(2)

Usale Advantages
The closed-circuit television system offers several
distinct advantages over other mean. of producing
displays at a user console.
Since only a television monitor and a vi~eo line are
required to present the diSPlay at each NLS console,
the desien and location of consoles is flexible
enough to facilitate experimentat10n with different
types and to permit moving them about with a minimum
of cabl!n, prOblems.
The video s1cnal can be inverted to provide a
dark-on-light display, which is usable 1n higher
ambient light conditions than the more common
light-on-dark presentation and which makes flicker in
the di.play 1male less noticeable to the user.
A significant storage time can be obtained on the
vicicon surface bY proper aajustment of the
television camera. ThiS reduces tne flicker effect
that 1s present in the original CRT ~isPl&Y, and with
this system we find it possible to produce
satiSfactory imales with a regeneration rate of about
twenty per second.

(3)

M&intenance Feature.
Since the diSPlay equipment a~ each NtS console is
simply a telev1.1on monitor, it can be replaced by a
spare for maintenance without taking the console out
of service.
The location ot the diSPlay-generating eQuipment in
the computer room, where complex maintenance and
repairs are more convenient, make. pOSSible an
uncluttered oftice environment in the user's working

134

Section V
CONCLUSIONS, RECOMMENDATIONS. AND PLANS

area.
Hav1nc two identical d1.plaY Iystems, from display
eontroller through aetual monitors, is a major factor
in maintaining up-time in spite of the high level of
maintenance that has been required on the.e systems.
Since there is not a fixed one-to-one relationShip
between ~1splay-generat1ng equipment and NLS
consoles, users may select consoles freely on the
basis of current nee41 even when part of the
display .ystem is out of service.
(4)

Potentials for Extending Capabilities
Since a great variety of commercially aVailable
equipment i. compatible with our vi6eo system, there
are many potentials for innovative use of our system
that would be mueh harder to realize with
conventional Cisplay-01stribution techniques.
For example, we have used high-quality projection
television al part of our presentations at the
1968 Fall Joint computer Oonference and at the
ASIS Conferenee in 1969 (see Section III-E).
It is pOSSible to use multiple TV monitors or
intermediate-size prOjection equipment tor smaller
croups, an4 experimentaion witn these techniques
will be a major element Of the team-augmentation
work to be carried out unoer our next contract.
The video capability ofters aaoitional flexibility in
the images th&t may be presented on the screen.
For example, in the conference. mentioned above,
live television pictures of the people and
equipmen~ involved were freely used, ooth alone
and after being mixed with computer-generated
images.
ThiS, also, will be a Significant factor in team
collaboration at a distance where pictures of the
people involved can be used, either mixed with or
inserted alongside of the computer-generated
images.

135

Section V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

Another potential use of the
microform ~ocument8.

vi~eo

is the viewing of

Many systems are now aVailable that use
close~·circuit television for the storage,
retrieval, an~ viewing of microform documents, and
we expect thi' kind of system to become more
prevalent in the tuture.
we already have plana for experimenting with
various SWitching techniques in our
diaplay-di8tribution system, and the inclulion of
provisions for microform viewing woul~ require
very little additional effort.
b.

NLS Conlole,
(1)

Console Design
As mentioned above, the use of video for displa~s
allows considerable flexibility 1n console design.
We have experimented with many arrangements over the
past few years and are now using the three basic
designs shown in Figure. V-l, V-2, and V-].

(2)

KeYboards
The keyboarOs in use have gone through several stages
of del1gn with special attention to touch and layout.
They now have a key force of 80 crams and a good
"feel." They are well accepteo, an~ we tinc1 that new
user. rapidly accommoaate to the locations of special
keys .uch al command accept and backspace.

())

Moule
We fin~ that the mouse is still the most convenient
locating device for our purposes. It 1s aescribed in
Ref. 7, alonl with some experiments in the use of
various selection devices. Available commercially,
it is now u.ed on other systems a8 well al our own.

(4)

KeYlets
The keysetl in use were desilned with special
attention to "teel." Tolerances on the movinl parts
are very close to give .mooth, po.itive action. Key

136

FIGURE V-l

"HERMAN MI LLER" CONSOLE. This console, designed in cooperation with
Herman Miller Research, was first used for the Fall Joint Computer Conference
in 1968. The keyboard-keyset-mouse unit is attached to a swivel chair, with
the TV monitor on a separate stand. It is a little confining to many people
and the limited space for operating the mouse is an annoyance. However, it
is reasonably comfortable and is useful for meetings and demonstrations because
the user can turn and be part of a group while working.

137

FIGURE V-2

138

ON E-PI ECE CONSOLE. This console, designed about two years ago, basically
a table on wheels with the TV monitor mounted at a suitable angle for
viewing. Both sides of the table have pUll-out shelves for mouse, key set, and
working papers. This console now seems too rigid to most users. The TV
monitor is too close for some, and th ere is not enough extra working space
for notebooks and papers.

FIGURE V -3

CURRENT CONSOLE DESIGN. This console consists of a small table with
integral keyboard. Connectors for the mouse and keyset are immediately behind
the keyboard. The TV monitor is on a separate stand . The table stands low,
placing the keys at a convenient level for typing, and other tables can be placed
on either side for additional working space. This arrangement is very flexible
and allows plenty of working space as needed. I t is particularly good for
group collaboration, since the monitors may be turned for better group viewing,
and entire consol es are quickly moved into different working arrangements as
needed.

139

Sec~ion V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

spacing
c.

&n~

size

&P~roximate

those of a piano.

Printer
We value a high-qUality line printer that ~roduces
upper-- and lower-case alphabetic. an~ a full complement
of ASCII symbols. The one now in ule is a Data Products
mo~el M600-11A, wh1eh hal been very reliable and
maintain, hilh~quality output.
We normally use specially perforated paper alone with
our output-formatiin, programs to prOduce hardcopy,
complete with ~re-punehe~ hole., Which is re&~y to be
in'erte~ into a standard 8.Sxll three-ring hinder.
ThiS
feature has been enthu8iastically accepted and is of
partiCUlar value 1n the prOduction of reports anO other
documentation.

Software Architecture
The overall architecture of our SOftWare systems is
described brieflY in Section II.
The use of a compiler-compiler to augment the
development ot a ver.aiile set of spec1al-~urpose
language I hal proved quite valuable in facilitating
debugging, rapid modification of existing feature8 and
addition of new features, ana or1entation Of new
programmers.
our effort. to use higher-level l&ngua~es Wherever
pOSSible shOUld result in adQit10nal payoffs when we
transfer our software to a new computer this fall.

The On-Line System
Nt! hal been evolving for many years and has prove~ itl
value both a8 a tool for-bootstrapping its own evolution
and as a flexible laboratory for developin~ experimental
working methOdologies (see, for example, Se~tion III).

problems
The major problems we have encountered in developing our
system stem from four basic diffieulties:
(1)

140

Trying to fit a very large operational system into

Section V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

har~ware

(2)

too .mall to support it

Uling an available time.har1ng 'Yltem that hal
inadequate to~ our purpo.e.

~rove~

()) Developine too Much special hardware with the
as.ociated probleml ot unreliability and mi8.e~
schedule.
(k)

Unreliability ot lome components of the facility,
file .torace device ••

~articularlY

Hardware Lim1tations
Limitation. imposed by both the hardware configuration
an~ the timesharing service system have resulted both in
worse response and in the ability to handle a smaller
number ot on-line users than we had expected.
Moreover, this h&sre,ulte~ 1n the necelsity tor
expendinl mere relource. on ~rOlr&mminl the service
system than we had originally anticipated, and our
planne~ work on evolving the user system has suffered
acCordingly.
We originally had hoped to be able to .erv1ee ten
on-11ne NtS console. at a t1me, but we now find that
only five can be operated with reasonable response to
the users. The primary factors affecting this response
time are .wapp1ng (core-drum transfers) an~ file 110
(core-di.c transfers).
stUdies that mea.ured and recorded the time required
for a prolram to be activated trom the lowe.t
priority queue under various .ystem 10a4s SUII.st
that an external core tor display bUffers will
provide improved respon,e bY treeinc a maximum amount
of memory for u.e in swapping (Ret. l6).
To analyze tactor.affectinl ~he re'pon.e of the
timesharing system, we developed a highly
parameterized, discrete simulation model of the
'Yltem (Ret. 18).
This was used to evaluate the impact ot changes in
the hardware configuration, such as faster drum.
or larger core memory, a. well a. the effect ot

lil

Sect-ion V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

various mixes Of user demands.
Changes in the scheduling an~ swapping algorithms
were also tested in the simulation, with the
relultl being sUbjected 8ubsequently to
experimental verification.
The major hardware limitations of the facility are the
maximum core aVailable (the 940 can accommo~ate only
6~,OOO word.), and the limited address space aVailable
(a program can address only 16,000 woros).
Maximum core limitation results in the swapping
bottleneck mentioned above.
Limited address space requires an overlay structure
inordinatelY complex for a program the size of NLS.
This means that programmers must expend a grea
deal of enercy de.lgning overlay structure. and
are constantly running into problems of full
overlays as the system is expanded.
This factor alone probably increased the cost of
programming tne system bY ten to twenty percent.
In retrolpeet, we recognize the error in the fOllowing
de.ian decisions:
The deciSion to refresh displays from main core
memory was a ba~ one. Memory bandwidth is no
problem, but ty1n, up the memory with ~isPl&Y images
(Which reQuire "fro~en" pages of core) re~uce. the
space available for programs and makes the swapping
bottleneek even worse.
With the present system design, providing feedback to
a user requires that a program unique to each user be
swapped in for every character of input. A different
approach m11ht have eonsolida'ttec1 lome of the
interactive !ee~back. thus re~ucing the swapping
requirement ••
b.

Timesharing System Defects
The tlmeaharinl system obtained for use on our computer
hal been another significant facility limitation.

142

Sect-lon V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

timelharinl .y.~em wal one of ~he mo.t
available .at the time we acquired1t, it
hal proved 1t.elfinadequat,e· to provide ·the service
wh1ch we mu.t have.
Al~hoUghth1.
,ophiltlca~ed

Partly thilis becau.e the de.icner. of the .ystem ~ld
not anticipate aceommoda~1nc prolram. as laree as NL!.
We are constantlY runnlnl into .1ze 11mit&~ions built
.into tbe a •• embler, loader, and debuller.
Another prOblem i . that we are ~be only people uling
this tim'.sharing system tor an apJ)lication 11ke Nt! an~,
therefore, have ha~ to carryon alone its maintenance
and evolution.
.
There. still are many bu,s 1n the Iystem that would be
totally unacceptable if we were not a
releareh-oriented organization with few naive ulers
dependent on the system for .ervice.
Some of the,e bUll have been known about for two
years or more, but hie her-priority ~emand' on our
procrammera' time have alway' prevented us from
locating them. witb tran.fer to & new computer now
imminent, we plan to live wl~hthem a little longer
ratber than wasting valuable enercy trying to fix
them at thi. time.
c.

problem. with Custom-Built Hardware
MUCh of the hardware in our

sy8~em has been custom built
to our .pecitication.~ either bY our own .taff or under
contract.

We have badly underestimated the resources needed for
constructing some of thil hardWare, there,ults beinc
mil.ed schedUles, failure to meet specifications (tor
the diSPlay .y.tern in particular), and hieh maintenance
co.ts.
In putting together an exper1men~al facility tor
aUlmentation re.earch, we now lee the de.lrabi11ty of
re,tricting .peclal hardware development to tho.e areal
mOlt directly as.ociatedwlth user feature. -- e.I"
uler-con.ole d.slln.
Wherever po.alble, use ,hou14 be made of commercially

143

Section V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

available computers, interface devices,
d1.play-ceneration equipment, etc.
d.

File-Storace Device Unreliability
File unreliabilitynal allo relulted in considerable
;lols of time to both prolrammerl and other users.
Althouchthe disc-tile .ystem we are using is Quite
COO~ when compared with other. in.the COMPuter field,
&deq~ate tile backup features were not incorporated
into the .y.tem design.
This means that ulers must either 10 through
elaborate procec1ures to keep .everal coples of
1mportantflles or occasionally sutter Significant
lost time when a file goes bad.
Until file storage devices are much more reliable than
those now available, sO~histic&ted automatic backup
facilities should be designed into any system.

Maintenance Experience
a.

General
General reliab1lity of the faci11ty hal been gOod.
Computer up-time hal been hieh, although the reliability
ot the di.c-file .y.tem hal been only fair.
We had a period of several months of above-normal
error rate, with five days down While cloCk track.
were rewritten.
The chain printer we orilinallY bought had marginal
print QUality, was unreliable. and we had ~ifticUlty
getting .ati.taetory maintenance service.
consequentlJ,
products drum
per line with
print quality
so far it hal

we have replaced the unit with a Data
printer that hal 96 printing characters
upper- and lower-ca.e alphabet. The
1a excellent (witne.s thil report), and
been fairly re11able.

Display System
We have spent more effort on maintenance of the c11.play

Section V
CONCLUSIONS,

RICOMMENDA~IONS,

AND PLANS

'Yltem than on any other part ot the taei11t¥. lince our
cSi.play .y.tem 1. lomewhat unu'U&l, we will di,cusl lome
01 the problem. encountered in .0 far a. they reflect
con.1der,t1on. relevant to the de.1ln of other aimilar
sYlteml.
(1) one basic If,tem ,limitation hal been the 1nab111t¥
of the display-cenerator CRTs to produce adequate light
for the Vidicon p1ckupa. Thi. mean. that many element.
ot the display .y.tem are operatinl at marl1nal levels,
The dilplay-cenerator ORT' mu.t be run at SUCh high
intenlit¥ that their11te i. relativelY short.
Th1, hiCh intenlity a1.0 caul •• ditf1eulties in
maintaining good focul over the entire image.
To operate with the.e low light levels, tbe vidicon'
must be quite .en.itive, since sens1tiv1t, drop. off
with age, they, al.o, have a relatively .hort uletul
life.
(2) Becaule tbe writing speed ot the d1.play generators
is lowerth,n we had speCified, we have a flicker
prOblem when III 8ix screens on the Iystem in use are
rea.onably full of text.
We can compenlate to .ome extent tor this flicker bY
careful adjultment of the v1dicon beam current and
target, but thi. &~justmen~ n.e~1 trequen~ attent1on.
We have conlidered ul1nc lonler-per.iltance phol~hor.
on the TV monitor. an~ w111 exper1ment withthi. in
the near future,
(3) In addition to the •• difficulties there are lome
ba.ic weakne.ses in both the display generators and the
televi.1on Iy.tem Which could be corrected 1n future
de.1ens bY more careLul attention to component quality
control and the inclusion of circuit-desien and layout
feature. which would facilitate maintenance.

145

See~1on

CONCLUSIONS, RECOMMENDATIONS, AND PtANS

Our General orientation Toward. Future Research
Over the years we have frequentlY been face~ with the ~rOblem
ot attempting to explain to people outli~e of ARC just what
our on-Line System (NLS) is.
It il usuallY tairlyea.y to let across the idea of
aUlmentat10n in the ab.traet, but it il much more difficult
to convey to people who have not made extensive use of NLS
just how powerful it is as an augmentation tool -- it is
very ea.y to get trapped into looking at NL! as just a nice
text-editinl sy.tem without 8eeinl all the power that
resiOel behind that particular a.peet of its surface
appearenee.
Recently we have ~eveloped a way of looking at NLS which helps
to convey lome of the power that we know i5 present. and that
is to view NLS a8 & worker's on-line "office" .- that is, his
normal, dailY, local working enVironment. The analogy follows
from the observation that to a naive v1s1tor an office can
look like just another "room," but to the person who uses that
office it serves as an interface to many of the capab1lities
of an entire organization.
The office serves as a ~lace where a person can work at
organizing his ideas, studying correspondence, repor~s6
etc., and formatting hil own written materials. The Office
has a'lociated with it communication linkS suCh as mail and
tele~hone as well as access to secretarial and clerical
services tnat are used on a daily basis.
This lame sort of picture oan be app11e~ to NLS, for it 1&
u.eo on a daily basis to help with organizing, stUdying,
formatting, etc., and provides now, or soon will provide,
many of the other communication and clerical services
normally associated with "office work."
NLS also has many similarities to an office in the way that
both act as interfaces to extensive external capabilities.
Just as one would not expect to find complete PUblication,
laboratory, library, and filing facilities in the average
Office, one 8houl~ at present not expee~ any single
augmentation facility such al NLS to provide all the
computational facilities that a person might wish to call
upon. But, in the same sense that a person snould expect
to be able to access extensive organizational resources

146

Sec~ion

CONCLUSIONS, REOOMMINDATIONS, AND PLANS

from hil,oftice, he Ihould be able to aceels extensive
computational resources from an NLS-like facility.
For example, NtS provi~es all the capabilities needed for
conatructinc, stuay1ng, and editing prolram. 1n any ot
several.lanluac," however, the faci11tiel tor printing,
compl1inc. archivlnl, etc. are not conlidered to be
integral parts of Nt! and must be activated al "external
proce.sor." by the Nt! u.er.
Similarly, we have plana for implementing various mes.ale
transmission and information-retrieval sy.tema as external
processors, so that all the formattinl of input to these
system.
well
the .tudyinc of the output from them can
be done uling the powerfUl Nt! mechani.ms, While tne actual
proce.sing can be carried out by independent programs
running as background jObs on our timesharing system _. or
even by program. operating on computers at remote sites.

.1 .1

This otfice picture 18 very important to understanding how a
research center such as ARO can make the most effective u.e of
the resources of a netWork of interconnected com~u~ers such as
the ARPA Network delcribed in Section IV.
We antiCipate that Whenever we plan to make extenaive use
of the re.ou~ee. Of a particular nede of the Ne~work, we
will add facilities to NLS 10 that it· can be u.ed &1 an
interactive intertace with those re.ource ••

For eXample, if we were planning \0 use an
information-retrieval system at 80me other Site, we would
make provisions for the followinCI
(1)

using

Permittinl the retrieVal requests to be formulated
re~ular NLS technique.

(2) Translating the request from our syntax to tnat
required by the remote system an~ transmitting the
reformatted reque.t out over the Network
(3) Receiving the response trom the remote .ite and,
finally, translating this output into a properly
formatted NtS file so that it can be viewed and
manipulated Using tools alrea~y familiar to the ARC
Itlff.

Thil approach appeals taus becaUle it promises to permit a

147

Section V
CONOLUSIONS, RECOMMENDATIONS. AND PLANS

member ot our researcn community to use IUbsysteml runninl
at wiCely ~iltr1butea computer facilitie. without learning
a new set ot convention. and u.er techniques for each
different system. We believe that thiS way of viewing the
role to be played bY an organization's local computational
facility will become more widelY accepted as computer
utilities and network. proliferate.
When organ1zations become able to acee., a powerful and varied
collection of re.ources merely by interfacing their local
facilities to a network, it will become more generally
recolnized how wasteful it is for each local facility to
de.ign and implement all the computational capabilities it
needs.
It is likely that various computer "utilities" will evolve
to serve the need. ot large communities of users for
specialized on-line services that cannot be provided
economicallY at the local level.
By taking advantage of the load-levelinl that results from
serving a large number of customers, utilities could
develOp service facilities to fill ~he needs for large
high-.peed calCUlations, archival file storage, searches
over large 4ata b&sel, etc •• with very good average
respon.e times and at relatively low COlt.
Bringing ~he dilpenling of .pec1alized computation services
into the "market Place" provided by resource distribution
networkS could foster competition that would both
accelerate development of this kind of .erv1ce and make
posliblesignificant redUctions in the COlt of
computational service. in general.
In the context of th1s kind of development, individual
relearch centers such as ours will be relieved of much of the
chore of implementing and maintaining the ba.ic service
capabilities necessary for daily operation ••
Thi. chore, now dup11cated from center to center, con.umes
an excessive portion of our collective re.ources.
Effeet1ve computer networkS should permit computer science
researcherl to reduce this du~lic&tton Of effort so a. to
increase the rate of progress possible w1~h aVailable
prote"ional manpower and com~utational resources.
The.e research croups will then be able to focus more

148

Sect,lon V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

energy on the proClem8 that they are particularly
well~equi~ped to handle.

In our ca •• this might involve basic researeh to find
the mOlt .atisfying ways to lrtterface & specific
commun1ty ot u.ers to a network providing general
ca~abl1lties, while other croups could apply their
talents to areas of interelt such as mathematical
Manipulation, computer Ira~h1c8, and 80 on.
This.con.ideration becomes particularlY important when one
realiles, as we are coming to realize to an ever greater
extent, that the tools and techniques needed to constitute
a "complete" augmentation system are far beyond the
development capabilitie. of anyone research center such as
ours.
In comin~ year., we believe that significant
deVelopments 1n the com~uter sciences will come about
more and more as a result of the cooperative efforts of
many research centers, each working on particular
aspects of augmentation.
The preceding comment. shOUld convey .ome feeling tor the
power that we feel i . inherent 1n a network ot
relearch-oriented eom~uter centers and provide a background
for understanding our enthUsiasm for participating in the ARPA
Network. We believe that being a part of the ARPA Network
will be valuable to us in aCh1eving the goal. of augmentat10n
research for .everal reasons.
(1) It will live u. ex~erieneein workinc with a community
of relearchers more varied and widely distributed than our
own team of staff members.
This will permit UI to lain adOitlonal inslght into the
validity of our approaches to augmentation research by
ob.erving how and to What extent our facilities can be
ot service to computer users who are not captive members
ot our local researoh community.
(2) Network participation will provide impetus for our
efforts in the direction of team augmentation bY creating a
community of researcher. who are workinc on different
aspects of a common problem at widely distributed
geographical location. ana Who need new toola and
technique8 ior communication and cooperation to succelfully

149

Sec~ion V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

achieve their common loals.
BY working with such an extended community, we will be
able to let ~oals an~ priorities in our relearcn program
more knowledleably than we would be able to ~o it we
were limited to augmenting onlY team. working in our own
Center.
(3) As mentioned above, we at ARC have come to realize
that attaining the goall of augmentation research on a
'rea.onable time scale il a task far beyond the capabilities
of anyone small research center such as ours, and we are
very optimistic about the possibility of achieving a
significant acceleration in the procress of augmentation
research through network p&rtic1pat10n with other research
centers having similar loall.

D. Overview of Current Augmentation Research Center Plans
1.

General
a.

Introduction
The preVious section ShoUld give the reader some feeling
tor the forces that have been .hapin, our plans for
future research. Internal force. have combined wi~h
those generated by our Network partici~at1on to produce
a shift in our reaearch em~hasis in the direction of two
general activities:
(1)

Research on team augmentation

(2)

Development of a system design discipline.

In addition, increased awareness ot our need to
communicate and interact with the outside world is
leading us into the develo~ment of a new area of
.~ecific concern~ discussed below under "Transfer of
Results."
b.

Team

Au~mentation

Whereas in the pa.~ we gave most of our attention to
augmenting the individual worker, we are now focusing on
the augmentation of a team of collaborating worker.,
each of whom i . individually augmente~.

150

Section V
OONCLUSIONS, RECOMMENDATIONS, AND PLANS

The high mObility and mani~ulative e&~ability ot a
skilled "augmented individual" has a unique potential
which can be most fully realised when & number of
aUlmented inOiv1duals join to form a collaborative team.
Not only can each in~1vi~ual move very rapidly
through joint working fil.. to stUdY them, enter new
information, and U~d&te old material, but the group
~roce.ses of intercommunication and ooordination oan
be facilitated by special com~uter aids, conventions,
and techniques.
The contemplateO efforts in "team augmentation" involve
the development of several facets:
(1) oonventions and procedures for organizing the
working records of our plans, designs, Objectives,
design principles, and schedules to give members of a
team effective mutual "task orientation" Oy making
all information related to the team's Objective
optimally accessible.
(2) A "Dialogue support System" to facil~tate rapid
eVOlution of these working recordS throu~n dialogue
among members of the des1gn team.
()) Techniques to facilitate simultaneous
collaboration among peo~le at physically remote
on-line terminals by giving them direct communication
with one another, independent of their current
in~1v1dual work interactions with the com~uter.
ThiS
inclu~es prov1s1on 6 where feasible, for the
following:
(a)

Video and/or voice

1n~ercomMunication

(b) Easy an~ flexible control of mean. for
dU~11cating, at any terminal, all or part of
type-out or d1lpla~ from another terminal

the

(c) Rea4y transfer of con~rol of one terminal's
computer interaction to another terminal's in~ut
cevice ••
Special management and system-building
techniques for use by an aUlmented team, and
provision of app11cable technical intelligence and
(4)

151

Sec~1on

OONOLUSIONS,

RECOMMENDA~IONS,

AND PLANS

user training eapab111ties.
These techniques are expected to evolve within ARC under
eon~1tions of use in our own coordinated
Iy.tem·developmen~ work, and to be applied over a wide
ranee of eallaborative actions, from simple
question-answerine facilities to complex design work
involving intense mutual participation by team members.
AS applicable tecnnique, become effective within ARC, we
will explore their value for ~he following:
(1) Support of Network Information Center (Nle)
services such as teachine, question-answering and
some types ot query servicinc
(2) workinl collaboration between ARC staff
personnel at other Network sites

an~

(3) Work1nc collaboration between people at remote
Network Sites, independent of ARC staff.

c. Development of User- ana service-System Desiln
Disciplines
The functional features of the "user system" -- the
collection ot computer aids available to an ARC worker
-- have evolved with some ingenuity, a great deal Of
cut-And-try experimentation in actual-usage conditions,
an~ a certain .pec1al orientation offereO by our over&ll
researCh framework. Until now, however, there na. been
a significant lack of Objective, me~hodical engineering
~e8iln in the development of the overall user system.
A user-system design discipline is definitely needed,
and we intend to devote an increasing amount of
effort toward developing such a diSCipline.
Like the user 8ystem, the "service system" -- the
hardware and software unaerlying the features for
augmenting ulers -- hal evolved in an ad hoc fashion.
Here there 18 also a .iln1ticant need for a
.~stem-de.icn discipline.
Such IYI'em.~e.ign discipline. would have communicable,
teachable, and generallY applic&ble frameworks,

152

Sec~1on

CONCLUSIONS, RECOMMENDATIONS, AND PLANS

.upport1nc coordinated set, of concept., term1noloCiel,
principles, methoOologiel, and special tooll.
d.

Transfer ot R&sults
Behind these basic a.pects of our work in the ARO (team
and design d1.ciplines) 11es an essential
feature of our lona-term stratelf, namely, the loal of
producinc re.ults that will be of direct value to other
croups of .Yltem ~evelo~ers -. in particular, to those
who will be developing augmentation systems,
aUlmenta~ion

This is in contrast with beinc of direct value to
customers wbo want systems tor their own direct use
-- e.I., to augment a manager, a de.igner, an editor,
or a scientist.
Display ~ermlnals, communication channels, and computer
service are de.tined to become both chea~ and ~lentiful,
and it is certain that a very large number of
organizations will want to use them. They must rely
upon system developers who should be capable of the
followinll
(1)

Analysis of .ystem-usace &nvironment.

(2) Desiln and implementation of a smooth, powerful,
and coordinated system of user al~s, eonvention., and
metho~1

(3) Training and "edueation" of users unfamiliar
with the potential of this new technology
(4) Subsequent monitorinl Of user performance 80 al
to implement the chance. nece.laryto track ~he
evolution of users' att1tudea, concepti. 'kills,
usage habita, and wants.

Although it is important for us to stimulate the
eventual customers for augmentation sy.terns by making
them aware of the potential for these .ystem. 1n their
work, we feel that our results ahould be directed
~r1marilY towards helpin, .ystem developers.
We plan to
do th1s bY pursuing the fOllowing long-term 10al'l
(1) Making viSible an advanced, ln~ecrated Bystem,
operating in a heavy-usage environment, that can

lS3

Section V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

orient system dev.lo~erl .to the available
cOlt/benef1t tradeoff.
(2) Developinl an effective .ystem-desi«n di.cipline
to a14 in develo~ing aUlmentat10n sy.tems, whether or
not ~hese systems resemble ours
(3) Maintaining thoroulh, h11hlY current,
comprehen.1ve documentation, desilne~ for qu1ck
location of relevant material
(4) E.~abll.h1nl wide-band communication channels
over whicba dynamic interchange of information can
take plaee, 80 that the maximum amount ot our
knowledge can be quickly available 1n useful torm

(S) Offering a complete prototype design of an
aUlmentation system especially desilned for
augmenting Iystem development,

This system would be compatible with the
sy.tem-deaign discipline' described above, and
would includetecnnique8 for planning, analyzing,
delilnin" pro«ramm1ng, debugging, documenting,
an4 teachinl.
our current approach to implementing the transfer of
re.u1t. 4iseussed above 18 to Plan tor What we call the
Syst~m Developer Interface Activity (SYDIA).
We expect
to approach representative candi~ate8 during 1970 with
proposal. for multi~le sponlorship. The initial purpo.e
of the SYDIA will be to ~evelop the following:
(1) A facility for an effective interehan«e of
information and skillibetween ARC an~ the eXisting
and ~otentia1 community of augmentation-system
developers
(2) The ab~lity to a.s1st other Iroup. in
transferrinc our system, or part. ot it, directly
into other hardware and user environment ••

Later, with .pecific individual fUnding arrangements, we
expect ~o beein developing close1nterchange
relation.h1~. with various system-development croups who
could adapt our aUlmented teChniques to their own
.y.tem·~eve10pment work.

154

Section V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

Team Augmentation Re.earch Plans

Introduction
We have already discussed the evolution that has been
taking place in the goall of our research program.
Havinl ma~e significant progress ~owara, realizlnl
the objective ot aUlmenting ~ne individual
intellectual worker, we find that the greatest
augmentation need evidenced within our own Center at
the present is for developing tools that will
facilitate collaboration among members of a
project-oriented or problem-.olving team of augmented
in~1v1duals.

It il no~ that we have already accomplished our
original objective, and feel that we can now turn
our attention elsewhere, but that team
augmentation •• seen in the light of our
bootstrapping stratelY .- offers the greatest
promise of hastening the eventual realization ot
these loal',
We view the "augmented team" al a group of workers
Iharing a eommon bale ot werking files and uling the
mechanical element. of their augmentation syatem
both
a medium for goal-related commUnications and a
laboratory for carrying out relevant experiments.

At present we are mOlt interested in exploring the
pOlsibilitiel for augmenting the activities Of teams
who.e purpose 18 the ~evelopment Of a~vanee~ computer
systems such a. our own.

We feel that this is a

~rotitable way of inve.tine
the resources with Which we are entrusted, not only
from the stan~point ot our bootstrapping orientation,
but also because augmenting this ty~e of team now is
most likelY to have the create~t paYOffs 1n the lone
run for 80ciety al a Whole.

Over the pa.t year we have identified a set Of bal1c
capabilities ~n&t.eem to meet the major needs of the
augmented sy.tem-development ·team.
The

t~llowing

description of these basic capabilities

lSS

V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

Sec~ion

can

be viewe~ a8 represen~inl a framework for ~he
.y.tem·~evelopment activity that must take Place in
the process of de.igninc and 1mplementin~ systems to
realize the.e ca~ab1litie ••

It al.o

ind1ca~el, 1n~irectlY, the nature of other
activities that will be concerned with
integrating these capabilitie8 into our working
methodology, applying them directly to the operation
of our Center, and analyzing their effectiveness so
as to provide direction to subsequent developments.
rela~ed

'aat Editinc and Publication

our already fait computer editing techniQues will
naturally continue to evolve, and we are in the early
stages of developing a powerful "Output processor"
capability.
The Output Processor is envisioned as a coordinated set
of techniques for prOducing hard copy through a variety
of media, SUCh as microform an~ direct publication on
paper, ~Iing conventions that are compatible with those
bY Which the a.sociated file material can be studied and
manipulated on line.
We plan to concentrate early upon automatic production,
from our on-line files, of hard copy in whlch one can
very flexiblY ,pecifY the eompositlon of text, diagrams,
table" eqUations, footnotes, ln~1ces, etc.
Dur1ngthe production process, such operatlons as
convertlnl intratlle links to page references and
lnterfile links to footnote~ would be pertormec
automatically, with associated conversion table.
beinc .• aved for future ule.
one of our goal. for the next few year. i8 to develop a
,y.tem eouplinl a typewriter-like computer terminal with
a microform reader that can be pos1tioneo to any page
within its "library" upon direction from the central
computer,
This system would use conversion tables generated by
the Output Processor durlne pUblication of tne
micrOform library to ~rive the reader in response to
directions from the user. Th1s would give the user

156

Section V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

much ot the power for studying large bodies of
1nterreferenced documents tbat currently can be
obtained only thrculh the u.e of & ~1Iplay·oriented
.ystem like NtS.

Plexdoc.

A team tack11nl a complex Iystem-development ~roject
MUlt provide itself with the highest possible viSibility
over its work1nl environment •• 1.e., over the
followingl
Planningl plans, contingency alternative., resource
commitments, status, cr1ticisMS
Designing: deSigns, delien princiPles, constraints,
est1mate8, analyses, .upportive data, relevant need.
and po.sibilities
Operating: role., talk definitiona, assicnment.,
pOlicies, operational procedures and conventions.
We currently have quite powerfUl technique. tor aiding
an individual or small report-writing team in prOducing
document. of the usual reaearch-report size and
complexity. But in our approaCh to team augmentation,
we consider it e'sential to exp&nd upon these techniques
10 as to facilitate .the development and pro~uction of
very large, very complex documen~. containing many
deta1l' that are highly cross·dependent.
We u.e the term ~plexdoc" to denote the concept of
SUch a complex ~ocument, whieh WOUld, in fact, be
composed of a p08.1bly quite larle eollection ot NL!
file., crosl-linked in complicated ways.
the stem "plex" comes from the Latin "plexus,"
Which means woven or intertwined, and .upports the
image of a body ot informAtion that haa been woven
into a coherent fabric bY a group of peOPle
through the use of .pecial indices, footnotes.
reader-contributed eomm.n~., specific
crols-references, etc.
We intend t~ develop and keep up to date a large,
detailed, highlY crols-reterence4 and well-indexed
"~lexdoe" that contains a description of our own

157

Section V
CONOLUSIONS, RECOMMENDATIONS, AND ;LANS

~roject·team activity fulfilling the nee~s 118te~ above.
Our techniques to facilitate it. mo~±fication an~
re~ublicat1on will be under constant evolutionary
preslure.

Dialogue Between On-Line Collaborators
(1)

The

Dialolue·Su~por\

system

On-line access by collaborators to each other's
files, as provided by a number of tOday" timesharing
systems, leaves much to be de.ired 1n supporting
effective d1alolue.
In this context, we ule "~ialOlue"
incremental building up ot a group
ideal on any given IUbject through
"comments" to lome set of relevant

to refer to the
expression of
the addition of
file ••

We are attempting to meet the need for more
fleXible and powerful mean. offacilitatinl sucn
dialogue through the development of a
"dialogue-support s,stem," Which we consider an
es.ential element of any team augmentation system.
The dialogue-support sYstem must function smoothly in
conjunction with the plexdoc conventions to provide
capabilitiea such as are de.cribed below.
(2)

Comment1nl
Any team member working at a display console mu.~ he
able swiftlY ~o access tor stUdy any portion ot a
plexdoc's atruc~ured files, and he must be able
conven1entlf to add his contributions to the on-going
dialolue tha~ 1s contained 1n these files.
Whenever he wi.hes, he shoUld be able to introduce
comments that are treely sprinkled with explicit
references ~o any Ipecit1citem (Character, word,
8~atement, line, curve. boX, expre.llon, etc.)
w1~hin any prier entrf .- a. though he were
pencil-marking a ~aper draft with marginal
comment., underlines, encircled ~&ssagel, arrows,
and the like.
When creating a comment entry, he needS flexible

158

Section V
CONCLUSIONS, RBCOMMENDATIONS, AND PLANS

ai~.

and

me~hodl

for the fOllowing:

Arrancinc display of ~ne various ~a,s&les he ia
referencing relative to ~he content of the
comment he i. creatine
Designating the explicit entities he wishes to
reference
Having the current comment-creation state
preserved temporarily while he checkS on aome
related material.
This must be managed by the compu~er so that it does
not matter if other people are concurrently scanning
the lame material or affixing comment references to
the lame items.
(3)

StUdy
His stUdy techniques shoUld enable him flexibly to
select which comments will be displayed for him and
which one. will. remain invi8ible (or whose presence
will be made known to him without appearing in their
entirety). For exam~le, he may wish to be aware of
onlY those comments that reference a given citation
in a text, term in an equation, or label in a
diacram.
He qu1te likelY does not want ~o see reference
indicators for all such prior comments, so he
needs flexible mechani8m' for .pecifying which are
to be vi.ible _. e.g., by author, creation time
(relative or absolute), specific content,
prior-assigned comment-set memberShip,
author-affixed category ~e.ilnationl, etc.
Al.o, whenever he sees indication that an
interesting type of eomment 1s associated with
some item in the stuOied passage, he needs
considerable flexibility for designating how he
will be shown such seleeted commen\. relative to
the referenced material _. for eXample, in one ot
the following way.:
With & split screen (original reference text on
the left an~ comment. on the r1ght)

159

Seetion v
CONCLUSIONS, RECOMMENDATIONS, AND PtANS

comment. enelo.ed within bOX.. and the boxe.
embedded within the original text
Ability to "flip" between views of the
reference material and views of the comments,
etc.
(4)

Notification
provilion. nee~ to be' developed to enable setting up
"annunciator call'" to varioul people, or sets of
people, to request their spec1al attention (at some
level of priority) to a given comment. This might
call for actions such al the following:
(1) An approval signo!! to recor~ the fact that
the comment has been noted by the party or parties
to which it was a~dressed
(2) Some kind of speCial vote, automatically
tallied and recorded on the annunciator
specification in that comment

()) A need to observe & "pOint ot order" in the
special method010I~ the team has adopted .- e.g.:

"I protest ·this decision and call fer a review,
citing Policy X, relative to BUdget Item Y and
Design Principle Z."
(5)

Retrieval
All aialolue entries immediately become part Of the
plexdoc containinc the complete working recorOs (and
much of the history) of the augmented team. Since
comment. and other working record entitie' can refer
to each other in indefinite extenSion, it will be
po. sible to buil~ up a very complex network of
relatlonsh1~s among tnele comments and the
sUbstantive records about which the dialolue is
swirling.
AlthQugh these relation'hip, need never be ambiguous,
it will be Ciff1cult tor even a knowledgeable team
member to kee~ traCk of them in such a wav tnat he
can effectively "navigate" through the plexdoe to
tollow all the relevant developments that may be

160

Section V
CONCLUSIONS, RECOMMENDAtIONS. AND PLANS

takinl place concurrently.

Thi. 11 about the toUCh.at central challenge in
effectivelY aucmentinc a team •• that ot
developing computer ai~l, workinl m.tno~s, ete. to
allow & akille4 person to be highly effective in
diceltinl the content and 1mplica~1ons of luch &
ree~r~, and to develop a lubstantive next-.tage
desien or plan that integrates the dialogue
contribution._
issentiallY 11milar techn1~ues are require~ to
augment any individualts central intellec~ual
capability for synthesizinc the next stale of
development in plan or design •• an~ to the extent
that we are successtul with this, we shoUld be
able to offer strong guidanee for capability
augmentation over wide ranges of individual and
team activities.
our initial activities in response to this prOblem
will be in the ~irect1on of providing powerful
retrieval tools that will enable a user flexibly to
specifY, by content, which elements of the Plexdoc
are of createst interest ~o him at any moment.
We also nave ~lanl fer developinc techniques that
will ~ermit a user to construct .~ecif1c 1n~ice.
an~ catalogues over a given plexdoc &n~ to create
and manipulate arbitrary "lets" of entities that
are of imme~iate interest.
Many of the tools ~evelope~to fulfill these needS
will also receive extensive uBein o~h.r ARC
activities such as the Network Information center.

Dl.tr1bute~

D1alocue

We cons1~er it important tor people other than the
central, highlY trained. ~i"Play·e'Quipf.'ed team to
participate al well &S pO.'ibl' in ~ialogue of the type
di.cus.ec1 above.
We .eek to ~rov1de capabilities that function
effectivelY over the Widest pos.ible rang. in
lophilt1eation of computer, communication, and
terminal facilities and in level of experience and

l61

Section V
CONOLUSIONS, RECOMMENDATIONS, AND PLANS

training of the individual userl -- and with &s much
independence a8 ~0881ble of geographical location.
As a first step we intenO to worK on the problem of
developing organization and formatting conventions for
presenting plexdocs tor study on devices other than our
centrally located .elective-view d1sPlays.
We assume that for silnlficant participation via any
type of couplinc with a low information-transfer rate
(such as a Teletype), the user will need to have on
hand comprehensively indexed hard-copy reference
material that is repu~lished relatively often (e.g.,
weekly or even daily).
We are already workinl on mechanisms for producing
high-Quality hard eopy 1n both paper and microform
(as described abOVe under "Fait Editin, and
PUblication").
Our loal is to be able automatically to publish
reference material (probably in microfiche) in
SUch a way al to make feasible a
frequent-republication operation servicing a
mOderate number of remote participants.
We have also begun to inve.tigate many different
kindS of remote printing devices and are
particularly excited about the high-speed,
high-quality, .ean-~riven hard-copy devices now
ap~earing on the market.
We allo are investigating techniques for allowing a
remote affiliate, such as a P&rticl~ant &~ one of the
other ARPA Network Site., to use a manual micrOform
reader (or even a volume Of paper printouts) in
conjunction with a typewriter-like computer terminal
through which we could ~rovide computer alds for
locating items of interest and following the various
kinds of cross-reference links.
A next step (nearing operational status) is t6 provide
facilities for direct, on-line, ~1alolue participation
using TODAS (our Typewriter-Oriented Documentation-Aid
Sy.tem). We are givins ~hl. speCial emphasis so al to
provide for early access to Network Informat1on Center
files.

162

Section V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

We are actively pursuing an extremely promising
~o.sibil1ty as.ociate~ with an emerCinc line of
microfiche readers that can be oper~ted under direct
computer control and Which permit jumping to any frame
ot a fiche 1n a fraction of a .econd.
MOlt of thele readers a180 allow jumping ~o any fiche
within a cartr1dle, or even to any cartri~ge within a
larcer store, 1n time. comparable to those we
currently experience in stUdying files on line usinl
our display system.
Such a reader, loaded with updated cartridges from
us, Where the reader and a typewriter terminal both
connect thrOUgh the Network to our computer, can
provide a perlon with very powerful hel~ in his
plexQoc studying.
He would be able to follow linkS, jump to an in~ex
and from there to .elected points, jump
.uccessively to the candidate .elections produced
by a retrieval query, indicate where he want' to
direct a comment reference (via typewriter entry
of his comment) -- all via quiCk directions on the
typewriter, abbreviated by cues (Which the
computer knows about) that he sees on the screen
of the microfiche rea~er.
In some applications a frame·jum~ing microfiche
reader/typewriter terminal system could be quite
competitive with our high-response, on-line
~1,play console system, an~ we are very interested
in ~eveloping experimental versions Of such a
system for exploratory use in the Network
Information Center.
f.

Conference Dialogue
The team augmentation techniques we have discussed so
far are all ~ireeted at aiding te&m member. workinc at
indivi4u&1 computer terminals.
There are times, however, when such a team will wi.h
to convene as a whole to review some new proposal,
debate a pressing issue, or collaborate activelY in
lome ~articular phase ot their work.

Section V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

The "complete" team augmentation system must provide
mechanisms for facilitating this kin~ of con1erence
~1alolue activity.
We alreadY have experimentea with using NLS as a
IO~hi8tieated "blackboard" where one person can Make &
presentation to a group .eate~ Within viewing range of
one of our regular NLS con.ole.. This gives new power
for' presenting material and answering ~uest1ons &$ well
as providing a very flexible me~ium within Which the
record 01 the ~iscussion can evolve.
In caaes where there are more viewers than can be
comfortablY accommodated around the "chairman's"
console, our display transmission mechanisms make it
trivial for us to hook up a~d1tional "slave" ~onitors
at convenient locations.
At two of our major conference presentations (see
Sect10n III-E) we have ule~ vi~eo ~rojeetion
equipment to allow us to give live demonstrations of
our on-line system to large aUdiences, and we are
planning to purchase similar equipment for use in
conference augmentation experiments at our own
Center.
.
The next step along this avenue of research is the
Oevelopment of techniques for allowing several users,
each working at his own terminal, to COllaborate in
real-time work on a common set of worKing files.
We have experimente~ a little in allowing
mUlti-console simultaneous access to a single file in
Which one user (the "chairman") has full control
while the other users are res~ricteO to merely
positioning a personal Dug-mark on the ~1IPlay, each
using his own mouse.
With the evolution ot multiple viewing win~ows, a
flexible voice intercom system, and other techniques
will come opportunities for more SoPh1st1cate~ forms
of interaction) and we are optimi.tic about the
pos.ibility of aehievin, ailn1ficant increases in
team effectiveness throUlh advances in real-time
~i&loIUe augmentation.
Further down the

164

roa~,

we lee a real need for developing

Section V
CONCLUSIONS, RECOMMENDATIONI. AND PLANS

that, without requiring an extensive training
period, will extend the ability to participate
effectively 1n augmented conferences to individuals with
little experience 1n using the complex set of
coordinated skills needed to competently operate our
present on-line system. One possibility we envision is
to give them a "chauffeur" to operate their on-11ne
vehicle.
te~hniQuel

Voice Dialogue
We hope to begln experiments 1n the near future using
teChniques for the dlcltizat10n of normal speech
'trines, developed by Glenn Culler While he was at the
Unlversity of Oalifornia, Santa Barbara. our plans are
to modifY Nt!
that a "statement" can contain not only
the present text andlor graphic material but also a
dilital representation of a speech string.

Then, with ~nlY .inor changes to NLS, we Would be
able to provide techniques for breaking long 8peech
strings into shorter ones, hierarChically organizing
them, an~ providing cross-reference links between
voice strings and normal text.

These capabilities will permit
to integrate a.ctual
·,poken dialogue into the dialogue meehanisms previouslY
discussed, providing an extremelY powerful add~tion to
our repertory of team-augmentation technique ••
They woul~ be of great help to re~ote dialogue
part1cipant. -. or even to our ownataft wh~n away
frOm the office -- since Phoned-in comment. could be
integrated 1n·to an" on-going dialogUe record, and they
open new doors 1n the tealm ~1 conferertce ~
augmentation a8 well.
Moreover, the anticipated gra~ual eVolution of
speech-processing techniques will provide
increasinglY powerfUl benefit. from this voice
dialogue approach.
h.

Technical Intelligence
To sat1fy our own needs as a research~eam, we have been
a~cumulat1ng for many year. a .ilni!1eant corpus ot
"intelllienee" (bibliolraphic) data about aetlv1t1e. and

165

Section V
CONOLUSIONS,RECOMMENDATIONS, AND PLANS

~rOduct8 of orlanization. out81oe our own that are
involved 1n related work, and we have committed
ourselves to shaping u~ thls collect1on in order to
provide It lealt parts of it (properly catalogued and
indexe~) to other croups, particularly NIe users.

In add1tion to maintaining an up-to-date collection of
standard bibliolra~hic items, we ~lan to expand into new
areas that are specifically rela~ed to the need. of
system-development team.. We ln~end to belin seeking
out and coll.ctinc data auch aa the followinl:
(1) Characteristics of, and user experience with.
various eommercially available and cUstom-made .ystem
elements
(2) Reference material ana user commentar1es on
externally develo~ed sy.tem8 and techniques
()) Intellilence on the statu. and result. of related
work by other groupl.
We have begun development of a flexible let ot
information-retrieval tool. tbat will be used
ext&nsivelY in the maintenance and interrogation of our
1ntelligence collection a8 well a8 in the management of
our complex working recor~1 (al ~ileusle~ above).
i.

U.er Training
With any user-oriented system as complex and versatile
as ourl, there is a continuous prOblem in helpinc new
users to attain competence in operating the system so as
to obtain the maximum benefits from it. This prOblem is
m&ln1t1ed many time. when user. can work frommanv
widely aeparated litel, making i~impollible tor them to
receive personal help from experienced staff on a
minute-te-minute basis.
With a system evolving as rapidly al ours, it 1s
difficult to kee~ even the central Itaff informe~ of
all new system features and Ipecial methoQololies.
We are Making lome prolres. 1n the preparation of
training and reference materials for our user system,
but there remains much to be done, not only 1n actually
providing such materials, but 1n discovering what forms

166

Sect,ion V
OONCLUSIONS,

RECOMMENDA~IONS,

AND PLANS

Of indoctrination material. (films, video ta~e,
introductory manuals, reference manuals, brief reference
guides, etc.) are most useful.
.
j.

Special Management Techniques
The m&nale~ent of a technicallY lophisticated
problem-selvina team requires the use ot some
methodologieal technique. that are eommon to the
manalement of any organized croup, a. well aa many
others of a more specialized na~ure.
There needs to be an accepted methodology for managing
the files containing the team" workinl recordS 10 aa to
ensure the most effective u.e of these files.
Effective procedures need to be worked out for
developing Plans for the future activities of the team,
for negotiating and reviewing talk de.ignation. and
individual rOle~. and for allocating and accounting for
the resource. possessed by the team.
Finally, there must be well-understood an~ accepted ways
of defining, repre.entinl. and monitoring operational
proee~ure8 and of relolvinl conflict. between elements
of the team regarding the allocation of resources among
the act.ivities of the team that must eomJ'ete tor them.

Special System-Building Techniques
In addition to the capabilities oescribed above, which
are relevant to the needs of all problem-oriented teams,
there are some considerations that are uniquely
a~plieable to a team whose domain is system ~evelopment.
The system-development team need. to have a consistent,
it not complete, .et of ~rinciplel for ~esi~ning the
overall SOftware-architecture Of interactive systems.
It must develop an understan~ing of the principles
underlying the design and analysis of interactive
systems from the standpoint of user services.
It must have effective technique. tor training new users
of the systems it hal implemented and tor generating
useful reference materials for these systems,

167

Section V
CONOLUSIONS. RECOMMENDATIONS, AND PLANS

It must have flexible methods for obtaininc
anllyzinc performance ~a\a on a .ystem.

an~

It should have powerful way. for simulating significant
parts of an existine sy.tem an~ tor limulating newly
conceived or modif1e~ sYltems in order to ~1&gno.e
existing bug., predict luture performance under varioul
con~itionl, and com~are the performance of proposed
sYltem ccnfiluratons with that of the existing one.
FinallY, it must nave highlY aucmente~ techniques for
creatine. compiling, and ~ebugging the huge collection
ot progr&ms used in the implementation Of a large
software system.

Development of System Design Disciplines
I.

Analysis

an~

Desi,n principles for on-Line User Systems

Designing a Whole augmentation system involves,
balanced conSideration of many factor., all Of which are
SUbject to reevaluation an4 chance in response to
increased understanding gaine~ through experience. The
following are examples of SUCh factorsl
(1)

Ways in Which users conceptualize their workini

talKS
(2)

MethodS for representing and recording these

conce~t5

(3) procedures for developing the concepts and
prooucts as.oc1ated with & given talk
(4) Forml of computer aids and utilization
methOdOlogies needed to obtain maximum help in
carrying out such working procedures

(5) User techniques for negotiating service
transactions with the system in various contexts.

At pre8en~ there is no desien discipline encompaSsing
thi8 ranle of interdependent sfltem factors, but one
really must evolve if anYlarle·.cale benefit is ever to
be derived trom the computer service. that we clearly
lee coming over the horizon.

168

Sect.icn V
OONCLUSIONS, RECOMMENDATIONS, AND PtANS

By a "design disciPline" we mean a cOherent,
communicable, generally applicable framework
comprising a coordinated set of conce~ts.
terminologies, principles, methodologies, and special
tools.
Thi. ~e.iln discipline must proviae a common ground
for analyzing the needs of a community of users,
formulating easilY communicable designs for systems
to meet these needS, and providing adequate controls
over the implementation process.
These capabilities should make it possible to offer
clients accurate cost/benefit pictures prior to any
extensive commitment of resources and Should make the
design and implementation processes more effiCient.
Consider the predictable tremendous increase' in speed,
capacity, and economic availability ot computational
resource., and then realize how the Quality of service
represented by these resources can be enhanced through
the application of ever more powerfUl artifictal
intelligence techniques.
We con.1der it desirable to avert the ~o8s1bi11ty of all
this power being harnessed in ways that leave these
mechanical helper. remote and unlnvolved trom our
minute-by-minuie human activity.
We need to learn how to design luch systems and how
to a~&pt our thinking an~ working methOdologies so
that Quick little bits ot service can be harnesled on
our own terms.
A lignificant challenge is involved in finding ways
for matching these computer services to human
perceptual, cognitive, anomotor mechanisms so as to
optimize workinl capabilities and provide a natural
and satiSfying extension of human capacities.
Design Of the repertoire of user services to be provided
by a com~uter/communic:at1on/terminal fac11·ity 1. a
procell requiring the kind of coherent deSign discipline
aSlociated with any complex sy'tem desien proces., and
we conSider the development ot SUCh a discipline for
augmentation-system design to be a vital component ot
our next phase of research.

169

Section V
OONCLUSIONS, RECOMMENDATIONS, AND PLANS

b. SOftware Architecture principle. for Interactive SYstem
De8ign
(1)

Overview
JU8t aa important to us as the development of a
d1.cipline dealinc with the analy.iJ and desiln of
user .ervices 1- the development Of a companion
di8c1~11n. Oea11nl with the design of sottware
architecture for interactive systems offering these
services,

Theae two discipline. are actually just opposite
faces of the same coin and must be interfaced so
as to form a single overall di.c1Pline that
provides a unified approach for going from user
needs Itraight through to integrated operational
systems satiSfying those needs.
To erganize the conceptualization Of such a system
desiln into appropriate level I and areal, and to
develop effective repre.entations of the des1gn
specifications and principles at each such level,
seems neces.ary if we are ever to transform
interactive system de.iln from an art into a
profession.
Our present software architecture approaCh
Itresses the.e things and promises to make useful
headway in evolving eonventions, proceaures, and
ai~s that coUl~ hel~ other people ap~roach an~
operate on the architecture ot com~lex computer
IYltems.
We ~elcr1De below lome of the approaches that have
evolveO in our work and Which we feel otter the
foundations tor a aelign discipline of the type we
are seeking.
(2)

oompiler-Oompiler TeChniques
Almost all our programming is done in some member of
a whOle family of lanluAges based on our Tree Meta
syntax-directed compiler (see Section II-6-2-b and
Ref. 18).
Thi. teChnique provides us with great flexibility in

170

Section V
CONOLUSIONS, RECOMMENDATIONS. AND PLANS

fit\inc each programminl talk in~o a language
particularlY appropriate to the requirements Of that
ta.k, yielding more efficient ule of vital programmer
time al well as code that i. SUfficiently
self-documenting to aid conliderably both 1n the
debUlcing of our .ystem and in the orientation of new
prolrammer ••
(3)

Format conventionl for

Source-Co~e

Language Filea

A very1mportant feature Of these speCial language.
1s that their format and structurinl convention. have
been designed so as to fit particularly well into our
augmentation-system usage enVironment. This provides
a very rewarding and powerful degree of fac11i~y for
composing, stUdying. and modifying source code.
The Plexdoc approach described previously has evolved
from a belief that all levels of de.ign and analys1.
thinkinc and data should be integrated into one
compatible Iystem of files over which the deSigners
and supervi.ors, and later ma1ntenance personnel~
colleagues, etc., can roam freely and adroitlY.
ThiS approach haa been applied to lome extent in
our present collection of system-program files.
This collec~ion torml a pleXdOC by vir~ue of the
fact that intertile link' can be used as the
argument. of ~rocedure calls; the internal system
documentation is also linked into this plexdoc.
Dialogue-support techniques have an important
contribution to make at every level of this
process in providing an integrated approach to
recording, documentation, and monitoring.
(4)

System Architecture principles lostering
Development by an Augmented Team

Evolu~1onary

we have begun to apply various modularization
concepts to our working and thinking methOdologies .0
al to foster the ability Of individual members Of our
research/development team to work effectively on
specific aspects of our project with the least
POI sible chance of de.tructively interfering with
other activities.

171

section V
CONCLUSIONS, RECOMMENDATIONS, AND PLANS

These concep~. are also 1mpor~ant to the way in
which we view part1eipa~10n in the ARPA Ne~work.
in that we are seeking flexible ways of
interfacing various modules of our own operating
system. to computa~ion component. available at
other site. through the Network.
We allo seek to exploit the properties of
modularization to promo~e delign clarity and
facilitate tran.ier of ~rograml and technique. to
other systems and croupl.
The extensive attention to conceptual partitioning
through use of a variety of apecial-purpose
programming languages is one example of this.

172

Appendix A
USER FEATURES or NtS AND rODAS
I

The on-tine
A.

SY8~em

(Nt!)

In~roduet1on

NtS, al currently implemented, 11 e.sent1ally a hilhly
sophiltieated text-manipulation system oriente~ primarily
toward on-line use; i.e., it 18 not pr1mar1ly oriented
toward production of hard copy, altnoulh fairly
sophisticated har~-copy tormatting and output are included
1n the system.
Nt! is intended to be used on a regular, more or leIS
tull-time basis in a time-sharin, enVironment, by users who
are not necessarily com~uter prOfessional.. The users are,
however, aSlumed to be "trained" as opposed to "naive."
ThUS the sYstem is not designed for extreme simplicity. nor
for self-explanatory features, nor for compatib1lity with
"normal" working procedures •

. Rather, it il assumed that the u,er has spent
considerable time 1n learning the operation" Of the
Iy.tem, that he uses it for a major portion ot his work,
and that he consequently is willing to adapt his working
procedures to eXPloit the ~ossioi11tie. of fUll-time,
interactive computer assistance.
ThUs the practice. and technique. develope~ by users for
NtS are as much a SUbject ot research
aa the development of Nt! itself.

eX~lo1t1nc
interea~

NLS is supplementeo by
called TODAS, Which is
appendix. Section III
for ~roducing flexiblY
files.

a typewriter-oriented counterpart
diseusleo in Section II of this
describes the NLS/TODAS capabi11ties
formatted hard copy from on-line

Section IV of this appendix is & glossary ot special
NLS/TODAS terminology.
B.

NLS Console
The user lits at a console whose main element. are a
di.play .creen, a typewriter keYboard, & curlor device
called the "moule," and a let of tive kef' operated by the
left hand, ealledthe "keyset."
The screen 11 used tor diaplayinl text, in variou.
formats. The top portion of the screen (approximately

173

Appendix A
NLS/TODAS USER FEATURES

lIS ot

i8 reserved for feedback
kinds: the name of the user
in effect, a "regilter" area uaed
for various kindS ot textual/numerical feedback, an
"echo reel-ter" Which display. the last elx Charac'erl
typed by the u.er, and other items that are eXPlained
below.
~be to~al area)
lntorma~ion of various
comman~ mode currently

The keyboard closely resembles a conventional typewriter
keyboard, with a few extra key. tor special characters

and control functions. It is used for typinl text as
content for a tile and for specifying commands, Which
are given as two- or three-character mnemonics.

is a roughly box-shaped object, about four
itl longest Side, Which is moved bY the right
il mounted on wheel. anO rolls on any flat
The Wheels drive potentiometers that are read
converter, and the .,stem caUses a tracking
8~ot ("bug") to move on the screen in corresponOence to
the motion of the mouse.

The mouae
inchel on
hand. It
surface.
by an A/D

The user specifie.location' in the diSPlayed text by
pointing with the moule/bug combination, Thi.
eliminates the need for specifying & location bY
entering a code of some k1nd. use of the mouse is
very easily learned and soon becomes unconscious.
on top of the mouse are three special contrOl
but~ons, whose uses are described below.

The keyset has one key for each finger of the left hand.

The keys are strUck in combinations called "Chor~s," and
each coord corresponds to a character or combination of
characters from the keyboard. There are 31 ~68sible
chOrds} beyond thiS, two of the buttons on the mouse
may be used to control the "cale" of the key.et, livinl
<erna~lve meanine' to each chord.
There are four
po.sible cases, for a total of 124 pos.1ble
comb1na~ion ••

A simple binary cOde is useO and ha. proved
remarkably easy to learn. TwO or three hour.'
practice is usually sufficient to learn tne most
commonly used chordS and develop reasonable speed.
The keyset wa. developed to increase the user's speed

174

Appendix A
NtS/TODAS USER FEATURES

and smoothness in operating NLS. It wal found that
users normallY keep the rilht haneS on the mou.e,
because the great majority of command operation.
involve a pointinc action) efficient use of the
keyboard. however, requires the use of both handS,
and Shifting the right hand (and the user's
attention) to the keYboard 18 d1stractinc and
annoying if it mu.t be done for each two- or
three-letter command mnemonic.
Use of the keyset perm1ts the user to keep his
right·hand on the mouse and his left on the
keyset,reverting to the keYboard only for entry
of lone strings of text (typically five or more
characters).
Originally, the keyset exactly duplicated the
keyboard in functionJ in the ~evelopment of NLS,
however, certain control functions have been made
two-stroke operations from the keyset where they
would be three- or four-stroke operation. from the
keyboard. Nevertheless, it i . still possible to
operate all of the features of NtS without using the
keyset; thus the beginner may defer learning the
keyset cOOe unt1l he haa lained some degree o~
mastery over the rest of the system.

structured Text
"Text" is used here as a very general term. A "file" of
text (corresponding very roughly to a Udoeument" in hard
copy) may cons1st of English or 80me other natural
lanlu&ge, numerical data, computer-program statements, or
any thine else that can be expressed as a structure of
Character strines, Simple line drawings can also be
included in a file.
All text handled by NLS is in "structured-statement" form.
This ~pecial format is SimplY a hierarchical arrangement of
"statements," resembling a conventional "outline" form.
Each statement in & file may be conSidered to .possesl a
"statement number," which shows its pOlition and level
in the structure. Thus the first statement 1n a t1le 1.
Statement 11 its f1rst 8ubstatement is la, and 1ts next
.ubstatement i . lbl the next statement at the same level
as the first 1. Statement 2; and 10 forth. statement

175

A
NLS/TODAS USER fEATURES

Appen~1x

number. have been .uppre.leO in printing out most Of
this Oocument but are printed out for tbe remainOer of
this section as an example.
2c2al Every statement also bears a "signature" that
may be ~ilplayea an command. The s11nature 11 a line
of text giving the initials at the uler who create~
the statement (or modified it most recently) an~ the
time and date when this was done.
2c2b A statement il simplY a string of ~ext. of any
length; this serves as the basic unit in the
construction of the hierarChY. In English text,
statements are normally equivalent to paragraphs,
section and subsection headings, or items in a list.
other ty~es of text, statements may be data items,
program statements, etc.

2c2bl Eaeh paragraph and heading in this document is
an NLS statement. Each statement is indented
according to its "level" in the hierarchy) this
paragraph il a substatement of the one above, which
is in turn & substatement of another statement. A
statement may have any number of lubstatementl, an~
the overall structure may have any number of levels.
2c3 Note that when a user creates a file, he may let all of
his statements be firat-level one., i.e., 1, 2, 3, etc. In
thi. cal. he will not have to consider a hierarchical
structure but simply a linear list, as 1s found in
conventional text.
2c3a However, many of the features of NLS are oriented
to make use of hierarchy. and the benetits of these
feature. are lost. if hierarcny i8 not exploited.
2e)b This is an example of an NLS feature to which the
user mU8~ accommodate his methode; however, the
experience of users has been that hierarchical structure
very rapidly becomes a completelY "natural" way of
orlanizing text. Many automatic features of Nt! make
the structure easy tousel for ex&m~le. statement
number. are create~ automaticallY at· all times and the
user need not even be aware of them. It is IUfficient,
when the user creates a statement, to specifY its level
relative to the preceding Itatement.

176

Appendix A
NLS/TODAS USER FEATURES

Ule Of the System

Text manipulation is con8i~ered to involve three basic
types.ot activity by the user, composition, study, an~
modification. In practice, the three activities are 10
intermingled as to be lndistlncui.b&ble.
1.

Compo.itlon
Composition is SimplY the creation of new text material
as content for a file.
In the simplest ca.e, the user gives the commana "Insert
Statement" by typing "il". He then pOints (with the
mouse) to an existing statementJ the system displays a
new statement number which is the logical successor, at
the same level, as the statement pointed to. The user
may change the level of this number upwara bY typing &
"u" or downward by typing a "dUe
NOTE: If no previous statement hal been create6, the
system displays a "dummy" statement at the top of the
text-~isplay area, and the user points to this dummy
in order to insert his first statement.
The user then types the text of the new statement from
the keyboard. on the sereen, the top part of the
text-display area is cleared and charaeters are
displayed here a. they are typed. When the .tatement is
finishe~, the user hits a CA (eommand .cce~t) button on
the keyboar~ or mouse, and the system re-creates the
di.pl&~ with tne new statement following the one that
wa, pointed to.
New material may also be added to existing statement. by
means of commands such as In.ert Word, Insert Text, and
others. ProperlY speaking, these operations are
modification rather than compo.ition, and are discussed
below.
Simple line drawings may be composed and added to the
file by means of the "vector package." This is
di.cussed in another section of thiS report.

Study
The stUdy capabilities of NtS con8titute itl most

l77

Appendix A
NLS/TODAS USER fEATURES

poweriul and unu8ual te&~urel. The follow1nc 1. onlY a
briet, condensed descri~tion of ~he operations that are
pOlsible.
a.

Jumping
NtS files may, ot courle, con\ain & Kraat deal more
text than can be displayed on the screen, just &1 &
document may contain more than one pace of text. An
NLS file is thoulht ot al a lone "scroll." The
procell of moving trom one point in the scroll to
another, which cerre.pond. to turning pacel in hard
copy, is called "jumping." There il a very large
family of Jump commands.
The baSic Jump command il Jump to Item. The user
specifies it bY entering "ji" and then points to
some statement with the mouse. The .electe~
statement is moved to the top of the screen, as it
the scroll had been rolled forward.
MOlt of the Jump commandS reference the
hierarchical structure of \he text. Thus Jump to
Successor brines to the top of the a1sPlay the
next statement at the 8ame level al the selected
statement; Jump to Predece'Bor does the reverseJ
Jump to UP starts the dilplay with the statement
of Which the .elected .tatement is a sUbstatement,
and 10 forth.
The Jump to Name command u.es a different way of
addres.ing statement.. If the fir It word of any
statement i. enclosed in parentheses, the sy.tem
will recognize it a8 the "name" of the Itatement.
Then, if this word a~pe&rs somewhere else in the
text, the user may jump to the namea statement by
pointing to the occurrence of the name, or bY
typin« the name.
This provides & cross-referencing e,~ability
that 1. very SMooth and flexibleJ the command
Jump to Return will alway. restore the previous
dis~lay, 10 that tbe u•• r may follow name
reterence. without losing h1. place.
It il allo pOSSible to jump to & statement bY
typing it. ,tatement number.

178

Appendix A
NLS/TODAS USER FEATURES

View Control
If a file 11 lone, it may be impo8sible for the user
to orient himself to its content and structure or to
find specific sections by jumping through it. The
principal solution to this problem is provided by
level control &n~ line truncation.
Level control permits the user to s~ecifY 80me number
of levels) the system will then display only
Itatements Of the specified level or higher. Thus if
three level. are specified, only first-, second-, and
thira-level statements are 01.played.
Line truncation permits specification of how many
lines of eaCh statement are to be displayed. Thus it
one 11ne i8 specified, only the first line of each
statement will be displayed.
Common usage 1s to use the first two or three levels
in a file al headings describing the material
contained under each heading in the form of
BUb8tatements. Thus the u.er may start by lOOking at
a display showing onlY the first-level statements 1n
the file, one line of each. This amounts to a table
of content ••
He may tnen select one of these atatements and
JUMP to it, specifying one more level. He will
then see more details of the content of that part
of the tile. This process of "expanding the view"
may be repeated until the user has found what he
is looking for, at which pOint he may specifY a
full display ot the text.
Users loon Qevelop a habit of structuring files in
such a way that ~h1s procels will work well. A.
it happens, such a structure is usually a IOOd,
lOCical arrangement of the material, reflecting
the relationships inherent in the content.
The level and truncat10n controls are destIned 10
that the necessary specifications may be made with
only ene or two stroke. of ~he keYbOard or keyset.
These controls are only the most 1mportan~ Of a large
set of view-control parameters called "VIEWSPECS."
Other VIEWSFECS control a number of special NLS

l79

Ap~.n~ix- A
NtS/TODAS USER FEATURES

fea~urel

aftectinl

~he

display format.

An example of the use of VIEWSPECS i. liven below
in Sectien I-D-2-e of ~hi8 appendix,
c.

Content Analy.is
The Nt! eon~ent analyzer permits au~omatic learchinc
of a file fer statement. satilty1nl some content
pattern .pecified by ~he user. The pattern 1s
written in a .pecial lanlu&ce &1 part at the tile
text.
Conten~ pattern. may be .1m~1., specifyin. the
occurrence of lome word, for example. They may allo
be highlY complex, Ipecifying the order ot occurrence
of two or more .trines, the absence of .ome text
con8truct, conditional .pecification., etc. Simple
patternl are extremely eaay ~o wrlteJ complex onel
are correspcndincly more difficult.

"Ke,word" System
A "keyword .tatement" i. an_mad .tatement that
references other Itatementa 1n the tile bY name, in a
Ipecial format. The naMe of the keyword .tatement -i.
then under.tood to be a "keyword" a~~l'inl to the
Itatement. refereneed by the keyword .t't.men'~
Suppo.e that a file contains a lls~ ot keyword
Itatements. The u.er may .tudy this lilt and
select several keywordS wi~h the Ke,wor~ 8eleet
command (pc1ntlne to the keywor~. with the moule).
He may specify a we1cht from 1 to 10 for each
ke,wordJ it no we1lhtl. specified, a weight of
1

1.&slume~.

When the user cive. the Keyword Execute command. a
.earehinl/.corine procesl 1s executec. EaCh of
the lelected keyword statement. is Icanned for the
name. of statementlthat it reterence.. Each
referenced statement recetvee a "acore- equal to
the we1ln~ of the ke¥wcrd~ It a statement 1.
retereneed in more than one keyword Itatement, the
Icores add.

180

A
NLS/TODAS USER FEATURES

A~pend1x

When this process is completed; NLS constructs a
display picture showing only the statements that
have received nonzero scores, 1n or~er of
decreasing scores.
In other wordS, each keyword is the name Of a
statement that defines lome arbitrary category of
statements in the tile. When a user selects an~
weichts keywor~s, he 1s ex~re.sini his interest in
certain of these categories. NLS then ~isplays all
of the statements in these categories, beginning with
the "most interesting."
Because the relationshi~8 use~ in this sy.tem are set
up ex~lie1tlY when a user writes keyword statements,
the system 1s very flexible although not highly
automated. It may ~e regarded as a generalized
method of reordering some of the .tatements in a file
on the basis of user-selected criteria chosen from a
supplied lilt (the keyword statements).
Note that this reor~ering is on the display, not
in the file proper. The file proper is not
affected in any way, except that the list of
selected keywords and weights is saved in the
tile.
This list may be ~1splayed on command.
Indiv1dU&1 keywords may be deleted from the
li~t or tneir weights changed, or the whole
list can be deleted on command.
e.

Link Jumping
A "link" is a string of text, occurring in an
ordinary file statement, that indicates a
cross-referenee of some kin~. It may refer to
another statement in the file, or to a statement in
Bome other file, pOSsiblY belonging to another NLS
user. The text of the link ia both human-readable
and machine-readable, and the command Jump to Link
permits the user to point to the link with tne mouse
and immediately see the material referred to.

An example of a link is (Smith, Plans,

Loncrance:ebgtn).

181

A
NLS/TODAS USIR FEATURES

Appen~ix

~he

first item in the link ind1cate. that the
reterenced tile belongs to a user named Smith; the
seeond i . the name of the li1eJ the third il the
name of a atatement in the tlle (a statement
number ma~ a180 be uled)J and tne .trinl of
charaeterltollowinc the colon control' the
VIEWSPECS to set up a particular view Of the
material.

The Jump to Link

eomm&n~, exeeuted b~ po1nt1nc
to this link, would caUl. Smith'. tile "Plansto be automat1cally loaded &n~ the display,
Itart .et to the .tatement Whose name 1.
"Lon,ra~le."
VIEWSPECS would be au\omatlcall~
set al follOWS,

The "en causes the number of levels
di.played to be,set equal to the level of
the di.play-.tart .tatement.

The "b" incrementa this by one.

The "I" speeifies that the diSPlay il to be
limited to the "branch" defined b~ the
di.plaY-ltart .tatement •• 1.e., onlY that
statement,itl sUbstatementa, their
IUbltatementl, etc.
The "t" .pecifie. d1'Pl&~ ot onl~ the fir.t
line of each d1sPl&~ed Itatement.

The Un" .pecifies ~h't statement numbers are
to be luppre.sed trom the ~18play.
Thus the net result 11 to displaY the fir.t
lines ot statement "toncrance" and its
hilhes~·level ,ubl~atement., without
.t&tement numbers,
'Tbe use of1ntert1le link' permits the
conltruction of laree linked Itructure. made up ot
many filel, an~ stUdy oi these tiles a. if they
were all sections ot a .incle aocument. The Jump
~o File Return cau.e. the iile previou.1Y viewed
~o be reloaded and diSPlayed, with the lame
ai.pl&~ .tart and VIEWSPECS that were in eltect
ju,t before the l1nk jumpJ' thu. the user ml~

182

Appen~ix A
NLS/TODAS USER FEATURES

execute link jumps freelY without 10ling track of
nil orig1nal location.

Modification
A larle repertoire of editing commands is provided for
modification of files. The basic functions are Insert,
Delete, Move, and OOpY.
These function. operate upon various kinds of text
entities. Within statements, they may operate upon
.1ngle characters, words, and arbitrary strings of text
defined by pOinting to the first and last characters.
This set of commands 1s not restricted to operation
within one statement at a time; for example, a word
may oe movea or copied from one statement to another.
The editing functions also operate at the structural
level, taking statements or sets of statements as
operandS. A number of s~eeial entities have been
defined for this purpose: for example, a "branch"
consists of some specified statement, Plus all of its
.ubstatementl, plus allot their sUbltatements, ete. A
branch can be ~eleted, moved to & new ~osit1on in the
.tructure, etc.
As note~ above, tne modification activity ten~s to
merge, in practice, with stUdy and com~os1tion.

Summary
It must oe noted that NtS 1s not a system designed for
general usage, but a I~ecialized tool designed lor a ~roup
of people working on the developmen~ of computer aida to
human intellectual proeesses. It i . for this reason, tor
example, that NLS is not really a text-editing system
oriented toward hard-copy prOduction, but rather somethinl
s1multaneou.1Y more general and more specialized.
It il in the process of manipulating a f11e .- stUdying it,
makinc mod1fic&tions, addin, new material aa an intelrated
procell lasting for minutes or hours at a time and having a
continuity extenaing tor days, weekS, or even years -- that
the real benefit of NLS appears.
An NLS file tendS to become an evolv1n, entity, subject

183

Appen~ix
NtS/T~DA8

A
USIR FIATURIS
to eon.\ant mo~ificat10n, upda~1nl, andreevaluatlon.
It. deyelopmen~ ma, have no clearlydellned .ndP01n~.
It may ca •• e· to ex1.t a. a fl1e by beinl incorpora'.dln
ano~herfl1e, or lt may eventually be abandoned or
.uper.e4edJ however, 1n mo.\ ca~e. it will never be
-finished" in the usual .enle of ·the word.
continuous u.e of NtSto ~tore ~deal, .tudy them, rel.ate
them .trueturallY,and croll-reference them re,ul~' .1n a
.uperior orlanlla~1on o~ ideal' and & creater' abl1i~y to
man1pulateth •• further for .peci&l purpo.... a. 'be
need ari.e. .- whe\her the "1dea'" are expre •• ed a.
natural lancuale,a.data, a. procramminc, or &1 Iraphlc
information.

The Typewriter-oriented Documentation-Aid System (TODAS)
TODAS 11 a text-handline .y.tem de.llned a. a "typewritercounterpart to Nt!. In principle, 'TODAS can be opera\ed from
a Teletype or any other .ort ~t:hard-cOPY 'erm~nal. ,includinl
'ermlnal' .11nkedto ·\he 9kO throulh aCQu.tic, COUPler. and
ordinarytelePbone l1ne. (as opposed to NLS, Which require •
• plclal ~ran.ml •• lon arranlement.).
Tbe pre.en\ i.pl•• en~ltlon .1low. lor·the u.', 01 Te1e~1pe
Medel' 3'~ "S, and ",Termlnlt and I~ecuport ~.rmlnal'
(the litter beinc portable, with a built-in' acou.tlc
COUPler), and Nt8 d11Play con.ole'.
lachel the.e terminal. h'. i~. own ehar&ete~~ •• t, no two
let.beinlexactlY tbe.ame except Teletype MOdel." and
35.
a relult, .peclal·c~&rac\er a •• llnmen\.are
device-dependent. A TODAS fe&tur';ll~ow. tbei u.erto
red,tine charac~er. at will to .u1~hi.lmmedla'. purp~ ••••

An important u.e ot TODAS1. tor ace ••• , within theAR"
Oo.pu~.r Ne~work,to the Network Information Oenter (HIe)
operated by ARC. TODAS will etve: Network, u.er. Icae •• to
111e. of information creatld eitherw1th TODAS or with ~LS,
.inee flle. created with tbe two Iy.tem. are ldent1cal. in
Itructurland format.
TODAS hal many ot the .ame capabil1tie. a. NtS t~r the
:aanlpulation ottext, it dltters from NLS al required b~ the
UI, 01 a "typewriter" ~eviceinltead 01 a d1.play. The
important d~tference. arla. fromtbe fact that TODAS ha,'no
analol curlor device to carre.pond to the NtS meule and trcm

Appendix A
NLS/TODAS USERrEATURIS

~he

leneral1~

.lower operation 01 TODAS.

For this realon, editinl of text wi~h1n a ItateMent cannot
be done b~ means resembling those ot NLS, since all of the
NtS edltlnl operandS are indicated by the user with the
mouse, TODAS u.el two alternative method'.

One 1. the TODAS "alter" command, which operate. very
much like the "mOdifY" command of the QED line-editing
.y.tem developed by Pro~ec\ GENIE at UC. "Alter"
create. a new statement to replace the orilinal one, bY
loinl throUCh the original from beglnninl to en~J under
u.er control, characters are (1) copied from the old
.tatement to the new, (2) Skipped over, or (3) inserted
into the new .tatement from the keyboard.
The other 1s the TODAS "SUbstitute" command, which
allow. the u.er to specity that a certain string ot
characters 1n the Itatement 18 to be found by TODAI and
replaced with another .pecified" .tring.
At the structural level (where the user wiShes to
man1~ulate Itatement. and set. of statements as units), NtS
permiilthe u.er to identity .tatements bY pOinting with
the mou.e) TODA! requires that statementa be identified
from the keyboard. Con.iderable tlex1bilit~ i. provided in
th1. operation.
Tbe u.er may identity a statemen~ directly bY typing it •
• tatement number or its name; he may alao i~entifY it
indirectlY b~ .pecifying its structural relation'hip to
lome other statement whose number or name he knows
ofl·han~.

Indirect .pecification correspond. to the use ot NLS
commands .uch AI "jump to head," "jump to lucce •• or,"
etc., but w1th ~he added feature that relation. hip.
may be concatenated _. thus the user may, in a linl1e
operation, .pecit¥ a complex relationShip such as the
succelsor of the first SUb8t&~ement of the
predece.sor of & liven .tatement.
A .pec1al TODAS capability (not yet implemented in NtS) 1.
"execu~able text."
A TODAS .tatement may con.1at ot the .tring of
characters that a user would type from the keyboar~ to

18S

AppenClx A
NLS/TODAS USIR FEATURES

perform lome •• quence of opera~ion8. Thll .~atemen~ may
then be execute~ w1th a Ipecial comman~,&nd the re.ult
will be .xaetl~ a. if the user had actually typed these
characterl, cau81n'the .e~uence to be carried out.
The lequence m&Y#in principle, be arbitrari1r CO~PlexJ
an executable .tatement micht, tor example, contain the
tol1ow1nc .equence.

(1) Load a fl1e who.e name 11 .pecified ellewhere in
the current file
(2) SearCh thl. lile with the content analyzer,

fin~1nl

content

It&~ementl

with a specified pattern ot

(3) Write the.e statementl out in , temporary
"bufter" tile
(4) Reload the original file
(5) COpy the .tatement. lnthe "buffer" tile into a
Ipecified location in the workin, tl1e.

A Ipeclal. "lw1tch" character may be uled 1n the
executable text. When the Iwitch character 1.
encountered, execution at the text i l interrupted and
control revert. to the keYboard. The uler then enter.
part of the control .equence manually) when be type. tbe
Iwitch character' from the ke~board, execution otthe
executable Itatoment resumes at ~he polnt where it left
otf. This fe&~ur. alfords creat flexibility, sine. it
allows·part ot the sequence to be ,~ecitied ahead 01
time and ~art at "execution tlme."
·8e.idel it,primary purpo.e a. a Ne\work u'er'. in~ert&ce to
t~e NIe, TODAS 1. u.ed w1th1n ARC a. a .upplemental tool' to
Nt8.
TODAS can be u.ed conveniently tor many talkl that ~o not
require the rapid dilplay response ot Nt!, and haathe
advantale 01 creatina Illnlf1cantly lei. load on the
overall. tlae.har1nl .,a~em. We currently have one clerical
worker, who i. not an Nt! u.er, operating TODAS routinelY
tor entry ot information anc for lome limite~ retrieval

work.

186

Appendix A
NLS/TODAS USER rEATURES

Additionally, we tind TODAS u.eful tor remote acce •• lnl ot
our 'Vltem. We have made TODAS available to .elected
con.ultan~., who use bome terminal- witb acou.tlc couplers,
and regular ARO per.onnel occasionallY do work from their
home. bf \he .ame means.
The prototfpe ver.ionof TODAI went in~o service 1n September
1969) a .econd ver.ion, wlth creatlf expande~ capabil1tle.,
became operational early ln 1970.
III

Output Facility
and TODAS both Ule the same facilities for producing
formatted hard-copy output from NLS/TODAS tile ••

NL!

The devices in orOinary u.e at ARC for hard-copy output are a
11ne printer that prOduces upper/lower-caae ~rlnt ot adequate
quality for local us., and apaper-tape-driven automatic
typewriter u.ed for tinal output of reproducible copy tor
report., propo.als, etc.

The output processor (previou.ly known a. "PASS4") can be
controlled bf the u.er to a conSiderable extent. This 1. done
bY mean. of "directlves" embedded 1n the tile text. The
directives can be used to re.et page parameters, eon~rol pale
numberinl, anoturn varlou. format t.a~ure. "on" or "oft."

For eXample, directive. can be used to luppre.sinoentation
ot .tatements or Chanle the amount ot indentation, to
create -running header." ~h&t are automatically printeO at
the t~p of each pace, .upprea. at&tement number., etc. one
of thedirectlvel cau.e. all directive. to be .upprel.ed
trom the output.
In addition to the l1ne printer and the automatic typewriter,
the output Procel.or can output a file to malnetic tape,
appropriately formatted to drive CRT-te-film conver.ion
equipment for prOduction ot microfilm.
In all ealel, the user may elect to output an entire tile or
only part 01 the tile. In the latter cale, he may cau.e
output to belln at scme .pecified point in the file in.tead ot
at the beclnning,and be may caule the printout to be limited
by the same kind I ot criteria that may be used on the display
-- 1.e., content analY8il, limited number ot structural
level., etc.

187

Appendix A
NLI/TODAS' USER FEATURES

Gl0 •• ar, of

S~eclal

NLS/TODAS Term1nolol'

BRANCHI A .pecified .tatement, plU. all ot 1~. sUb.'ruc~ure ••
1 •• ~ all 011'. IUb.t,tement., plu. all 01 their
,ub.ta~em.nt., etc.
BRANCH ONLY, A VIEWSPICparameter that re.trict. the text
dl'Pla,ed (Nt') or tfped (TODAS)to a .inCle branch (•• e

VIIWSPICS).

BUG. The cur.or mark on ·the .creen that 1. moved bY the mou.e
an4 that 1s Uled for lelectin, (polntlng to) ent1t1.1 on the
41'Pla,.

When the bUI 1. "active,ui.e., when a .electlon can be
made, lt appear. a.an up-arrowJ When i\ 1. inactive· 1\
appears a. a plu. 111n.
OHARACTBR: Any letter, d111t, punctuation
clrriale returnJ an indivilible entity.

mark~

'pace, tab, or

CHORD. A combination of .key. on the key.et (.ee· XIYSET).
Ct%PPINGI See LEVEt CLIPPING.

INDIThe lalt Itat.ment 1n any branch, .pecified bY .pecityin.
the branch.
rILl. A complete tree Itructure of Itatement. witb a .lnl1e
. root (the orlein Ita\ement).
rILINAMEITh. name of a fil~. I\ appear. I . 'he tir.' word in
the orlein .tatement 01 an exi.'~nl tl1e, andmu.t· be lupplied
bY: the u.er in crea'1nl a new tile.
GAP CHARACTER. Any

.p&ce~

tab, orcarrlace return.

GOHARI Abbrev1atlonfor GAP CHARACTER.
GROUP. A IUb.et at a plex, con.i.tine Of all, branche. from one
.pecitied branch \0 anotber, inclulive,
HIADaThe fir.t .tatement in a .ubli.t.

Tbe head 1. specified bY pointing to any .tatement in the
IUbli.t.

188

Appendix A
NtS/TODAS USER FEATURES

INVISIBLE: Any consecu~1ve strine of lap Ch&rac~er •• bounded
bY (but not 1neludine) print1nl charac~erl or the en~ of a
.tatemen~: see PRINTING CHARACTER, GAP CHARAOTER, STATEMENT.
Specified by pOinting to any character in the ,trine. If &
11nll. pr1nt1nc character lyin« between two invisible. is
pointed to, both invisible, (and the print1nl character)
are selected.
KEYSET: The ~evice at the left-hand side Of the NtS con.ole.
When a combination ot keys (a chora) 1. depre8se~ on the
key.et, the eftect i. the same a. striking a key on the
keyboar~.

KEYWORD. The name of a "keyword

.~atem.nt."

KEYWORD STATEMENT. A .tatement that 11ltl, in a Ipecial
format, the names of all statements 1n the lame file that fall
1nto lome arbitrary catecory.
The "keyword system" of NLS/TODA! commandS, o~eratlnc upon
keyword statement., pertorm. information-retrieval
operation. baled on the set. of atatements defined in
keyword .tatement ••
LABELl A Itring of text placed in a picture
command in the vector package.

means of &

tEVADJ. The .pecitication ot level when a statement, branch,
plex, or group 11 newly created or moved.
tEVEtl The "rank" ot a .~atement (see STATEMENT) in the
hierarchy Of the file (lee FILE).
The level i. equal to the number ot field. of letter I or
dicit. in the statement numberJ thu. statement 3 11 a
firat-level statement, Statement 4&1013 i. a fifth-level
statement, etc. tevel is of great importance in
understanding the hierarchical structure ot an Nt! f11e.
tEVEL CLIPPING. Restrictinl the text displayed (Nt') or
printed (TODAS) to statements no deeper thin a .pacified
level, which 1. set by & VIEWSPEC parameter (aee VIEWSPECS).
tINE TRUNCATION. Reltriet1nl the amount of text di.played
(NtS) or printed (TODAS) to the lir.~ N 11ne. of e&eh
.tatement, where N i . apecit1e~ by aettinc a VIIWSPEC

189

Appendix A
ILS/TODAS USIR fiATURI8
parame~er

C.e.' VIIWSPECS).

Each .~atem.ntt. formatted into l1ne. upon. output tOf'he
di.pla, or printinl ~eviceJ thu. the amount ol.tex~ in a
line depend. upon ~he device and upon other p&r&me'er.~

LINK. A .pec1&11Y_format\~d 'trinl 01 text 1n & .~atemen\~
analolou. ·to & reterence or crol.-reference c1t&\10n 1n a
conventional document.

A link ,pecif1e., u.er, & tile belonc1nl to \h,t u.er, &
location 1n ·the fllt, and VIEWSPICS. A. u.er may "follow" a
link by means ot 'he Jump to Link command (NtS) or In
indirect addrel' CTODAS). In either ca •• , the Iystam
detects the l1nk, interpret. it, laid,' the .pecified !11e,
and di.play. or print. the .pecified portion ot 1t with ~he
.pecitied V%EWSPECp&rameterl.
MOUSEl The device at the right-hand .1de ot the NLS keYboard.
When 1t :1. rolled around on the~abl.t~~, i\ cau.e. the bu,
Ccurlor mark) to move corre.pond1nllY on the 'creen.

HAMil It the fir.t word at a .tatement i . enolo.ed in
par,n\be.e., it 1. \he NAMB ot the ,tatement.
The command Jumpta Name can then be u.ed to pllce ~h •
• ~&~ement &~the ~op ai the ~1'Play. Th1. 1. ~one by
en'.rinl ·'he name trom .'he ~eYbo&rd or ke,.e~, or bY
flndinl an ,occurrlnce ot ·~h.nam •. a. ~.xt on ~b" d1.p1&y
andpolnt1nl ~o 1~ w~~h tbe bUI.

HtS.AcrOnym.tor "On-t1ne S,.tem.-

. ORIGINlthe.':!.r.t, .tatellent 1n a t1l-J it, cont.ain. intormat1on
IbOUt.~hltl11, plU. any o~her ~.xt. tbe u.er1n.er\..
l~ ha.
I level 01 0, and hence ·no .t&~ement number.
OUtPUT PROCISSORI
lor.&tt..dou~put.

Prolr&mu.e~

b, NtS and

TO~A8fol'

produclnl

'AISal Alt.ernat,e nameu.ed far the output 'roce •• or.

PATTIINI A .trin, of Ipecial-lan,ua,e'ext in a .t&tement that
m.v ~., compiled vta ·'be command Ixecu~e Content Analyser.
Whln 00.,11Id, 1t prOduce. a pro,ram that 11 u.ed bY t.he

content,-analv.er tla\ure.

1'0

Appendix A
NLS/TODAS USER FEATURES

peHARI Abbreviation for PRINTING CHARACTER.
PLEXI Another name for a SUBSTRUOTURE, used in command
specifieations.
A plex is specified by pointing to anyone of ita
hilhe.t-level statement ••

POINTBR. A strine of up to three characters that i. attached
to some Character in the' text with the Pointer Fix command.
PREDECESSOR, The statement preceding & specified statement 1n

a SUBLIST.

PRINTING CHARACTER. Any letter, dicit, or punctuation mark.
SOURCE: The statement of which a specified statement1s a
suDstatement.
SIGNATURE: Information stored with a statement (anO displayed
on command) civin~ the initials of the user who created the
statement (or most recentlY modified it) and the time and date
When this occurred.
STATEMENT: The basic structural unit of a file of text 1n NtS.
Formally, it i . a .trine of text and/or pictures that i.
bounded at the beginning bY the end of the previous statement
or the beCinning of the file, and bounded at the end bY the
beginning Of another .tatement or the end of the file.
Statements are arranged 1n a tree structure or hierarchy
and are a.signed "statement numbers" in~icating their
pOlitionsin the .tructure. Each .tatement has a number.
made up of alternating fields of digits &n~ letters; the
number Of field. indicates the "level M ot the s~ateMent
(lee LEVEL).
A statement is specified by pOintinc to any character in
the strine.

SUltIST. The let 01 all lubltatementl of a specified statement
(not inclUding the sUbstatementl ot the IUbstatementl).
8UBSTATEMENTI A Itatement "X" is called a .ubltatement of
another .tatement fly" it it 1. ~eeper 1nthe structure than
"Y," if it follows "Y," and if there i . no lnterven~nl
hl.ber-or4er 8tatement. ny" il calle4 the .ouret of "X." The

191

Appendix A
NL8/TODAS USER FEAT ORiS

.tltemen' number of "X" will be the .ame a. tba\ ~~ My" exeept
that 1t will have one more field at the end. The value of thil
field live. 1t, ordinal pOliticn in a "'Ublilt" of the
.ublt&tement. of "Y."
A ,ub.tatement i. specified bY pointing to the .ource

.tatement.

SUBSTRUCTURE I The .et of all SUb.tatement. ot a .pecified
.tat,ment, plu. all their IUbltatement., etc. until no more
are found. The let of all branche. detined by .tatementa in
'he IUbll.t 0: a given atatement.
SUCCESSOR: The .tatement fOllowing a specified .tatement in a
IUbli.t.
TAlt: The la.t Itatement in a IUblist.
The ta11 11 specified by pointing to any Itatement in the
.ublilt.
TEXT: Any string of characters within a statement, bounded by
(and includ1nl) two .pec1tled characters: lee CHARACTER,
STATEMENT.
TODAS. ACronym
Sy.tem.

to~ T~pewriter·orlented Documen'a~ion·Ald

TRUNCATION: See LINE TRUNCATION.
VBCTOR: A 11ne in a picture.
VIEWSPEOI: V1ew-control parameter. controlllni & number Cf
.peeial NtS 1eaturea attectlngthe diSPlay format. See, tor
example, BRANCH ONLY, ,LEVEL CLIPPING, and LINE TRUNCATION.
VISIBLla Any con.ecu~lv. strinl ot prln~lnl charae'era,
bounded by (but notlncludinl) liP character. or the en4 ot a
.tatement: see PRINTING OHARAOTER, GAP CHARAOTER, STATEMENT.
Specified by poln~lnl to any character in the_.~rinl. Ifa
ain,l. lap character 'between two v1.1bles i. pointed t~,
then both visible. (and the lap charaeter1 are .pecif1ed.
WORD. Any con •• cutlve strine ot letter. andlor d111tl, bounded
by (but not 1ncludinl) any other type I ot characters or the
end of a Itatementl lee STATEMENT.

192

A
NLS/TODAS USIR FEATURES

App.n~1x

Specified by pointing to any charae~er in the 'irine. If a
.inCl. character 11 pOinted to that 18 not a leiter or
dil1t and liel between two worda, then both worde (and the
'1nlle character) are specified.

193

BIBLIOGRAPHY
rhe following 1. a ehronoloc1aal lilt of
the Aucmentation Rele,reh Oenter.

~ocumentl

~ublishe~

D. c. Engelbart, "Special Con.1~er&tion. ot the IndivlCual
a U.er, Generator, an~ Retriever ot Information," Paper
presented at Annual Meeting ot American Documentation In.titute,
Berkeley, California (23-27 october 1960),

2. D. O. Ence1bart, "Aucmentinc Human Intellect. A Oonceptual
'ramework," Summary Report, Oontract AF 49(6)8)-1024, SRI
Project 3578, Stanford Re.earCh Institute, Menlo park, California
(October 1962), AD 289 565.
3. D. O. !ngelbart, "A Conceptual Framework for the
lucmentatlonot Man'l Intellect," in Vi.tas in Information
Kandling, Volume 1,0. W. Howerton and D. C. Weeks, edl., spartan
Books, washington, D.C. (1963).
~.
D. C. Engelbart, "Augmenting Human Intellect: Ex~er1mentl,
Concepti, and POSSibilities," Summary Report, Contract AF
49(638)-1024, SRI Project 3578, Stanford ResearCh Institute,
Menlo Park, Caliterni, (MarCh 1965), AD 640 989.

D. C. Engelbart and B. Huddart, "Relearch on
Computer-Aucmented Information Manacement," Technical Re~ort
ESD-TDR-6S-l68, Oontract Al 19(628)-4088, Stanford Relearch
Inat1tute, Menlo Par~, California (March 1965), AD 622 S20.

6. W. K. Enclish, D. C. Enlelbart. and B. HUddart,
"Computer-Aided Display ContrOl," F1nal Report, Co"tract
NASl-l988, SRI Project 5061, Stanford Research Institute, Menlo
Park, California (July 1965), eFSTI Order No. N'6-1020k.*

w. K. English, D. C. Encelbart, and M. t. Berm&n~
"DiSPlay-Selection Techniques for Text Manipulation," IEEE
Trani. on Human Factors in Electronics, Vol. HFE-B, NO.1, PP.
5-15 (March 1967).
7.

8. D. C. Engelb&rt, W. K. inllilh, and J. r. RUllf.on. "Study
For The Development of Human Intellect Aucmentat10n TechniqUes,"
Interim Procrel. Report, Contract NAS1-S904, SRI project 5890,
Stanford. Relearch Institute, Menlo Park, California (MarCh 1967).
9. J. D. Hopper and t. P. Deut.ch, "COPEI An A•• embl,r and
On-Line-CRT Debulling Sfstem tor the CDC 3100," Technical Repor'
1, Oontract NAB 1-5904, SRI project 5890, Stanford Re.earch
Institute, Menlo Park, California (March 1968).

195

BIBLIOGRAPHY
10. R. I. Hay and J. r. Rullflon, "Mot940: A M&chlne·Or1ente~
ALGOL-Like tancuace tor the SDS 940," Technical Report 2,
Con~r,et NAS 1-5904, SRI Project 5890, Stanford Research
Inltitute, Menlo Park, California (April 1968).
11. D. C. Engelbart, W. K. English, and J. F. Rulifson,
uDevelopment ot a Mu1tidilplay, Time-Shared Computer facility and
Computer-AUcm&nted Manacement-System Re.earch," Final Report,
Contract AF 30(602)4103, SRI Project 5919, stanford Research
Institute, Menlo Park, California (April 1968), AD 843 577.
12. D. C. Ence1bart, "Human Intellect AUlmentat1~n Technique.,"
Final Report, Oontract NAS 1-5904, SRI Project 5890, Stanford
Research Inltitute, Menlo park, Oalifornia (JulY 1968), CrSTI
Order No. N69-16140.*
13. D. O. Engelbart, W. K. Englilh, and D. A. Evanl, "Study tor
the Development ot computer-Augmented Management Technique.,"
QuarterlY progresl Report 1, oontract 130602-68-0-0286, SRI
Project 7101, 'Stanford Research Institute, Menlo Park, Oalifornia
(October 1968).
14. D. C. Engelbart an~ W. K. English, "A Relearch Oenter for
Augmenting Human Intellect," in AlIPS proceedingl, Vol. 33, Part
One, 1968 Fall Joint computer Conference, Pp. 395-410 (Thom~8on
Book Co., Washinlton, D.C., 1968).

lS.

D. O. Engelbart and Statf ot the Augmentea Human Intellect
Research center, "StUdY tor the Development ot Human Intellect
Augmentation Techniques," Semiannual TeChnical tetter Report 1,
Contract NAS 1-7897, SRI Project 7079, Stanfora Relearch
Institute, Menlo park, Oalifornia (February 1969).

16. D. C. Ingelbart, W. K. Inlli.h, and D. A. Evanl, "Stuay tor
the Development ot Computer Augmented Manalement Technique.,"
Interim Technical Repor~ RADC-TR-69-98, Contract
r30602-68-0-0286, SRI project 7101, Stanford Re.earch Institute,
Menlo Park, California (MarCh 1969), AD ass S79.
17. D. C. Engelbart and Staff of the Augmented Human In~el1ect
Reeearch Center, "Stu~y tor the Development ot Human Intellect
Augmentation TeChniquel," Semiannual TeChnical tetter Report 2,
Oontract NAS 1·'897~ SRI Project 7079, St&nfor~ Research
Institute, Menlo Park, Oalifornia (August 1969).

196

BIBLIOGRAPHY
18. 'D. C. Incelbart and Staff of the AUgmented Human Intellect
Research Center, "Computer-Aulmented Manacement-sYltem Re.earch
and Develo~ment of Augmentation Facility," Final Report
RADC-TR-70-82, Contract 130602-68-C-0286, SRI project 7101,
Stanford Re.earch Institute, Menlo Park, California (April 1970).
*Note. Report. with AD numbers are available from Defense
Documentation Center, Building S, Cameron. Station, Alexandria,
Virl1nia 223lk. Item. marked with an asteriSk may be obtained
from erSTI, S111s Building, 5825 port Royal Road, Springfield,
virginia 22151) cost '3.00 per copy or 6S cents for microfilm.
The following i. a li.t of other doeument. cited in this report.
The items are listed in the order in whicb they are cited~
19. "Specification. for the Interconnection ot a HOlt and an
IMP," Report No. 1622, Contract NO. DAHC15-69-0-0179, ARPA Order
No. 1260, Bolt Beranek And Newman Inc., Cambridge, Malsachulett.
(May 1969).
20.

L. Roberts, "Computer Network Development to Achieve

Sharing," .paper pre.ented at 1970 Spring Joint Oomputer
conterence, Atlantic Oi\" New Jerley' (May 1970); ArIPS
conterence Proceeding., Vol. 36, ~. S43 (AFIPS Pres., Montvale,
New Jerley, 1~70).

R~louree

21. F. Heart et al., "The Interface Me.sace Proces.or for the
ARPA Computer Network," paper pre.ented a\ 1970 Sprinc Join~
Computer Conferenc" Atlantic City, New Jer.ey (May 1970). ArIPS
Conference Procee4inCI, Vol. 36, p. 551 (ArIPS Pre •• , Montvale,
New Jerley, 1970),
22. L. Kle1nrock. "Analytic and Simulation MethOds in Computer
Network Desiln,n paper pre.ented at 1970 aprin, Joint Computer
Conference, Atlantic Cit" New Jerley (May 1970), ArIPS
Conterence procee4incs, Vol. 36, P. 569 (ArIPS Presl, Montvale,
New Jerley, 1970).
23. H. Frank, I. rri.ch, an~ W. Chou, "Topological
ConSiderations in the Delien of the ARPA Computer Network," paper
presented at 1970 Sprinl Joint Computer Conference, Atlantic
City, New Jersey (May 1970)J AFIPS Conference proceedingl, Vol.
36, p, S81 (ArIPS Prell, Montvale, New Jersey, 1970).

197

BIBLIOGRAPHY

24.

S. Oarr, S. Crocker, and V. Cert, "HOST-HOST Communica~1on
Pro~ocol 1n the ARPA Ne\work," paperpre.ented at 1970 Sprlnl
Joint Com~u\er Conterence, Atlantic 0ity, New Jersey (May 1970)J

ArIPS Conference proeeedine', Vol. 36, p. 589 (ArIPS Prea.,
Mon~v&le, New Jer.er, 1~70).

1~8

UNCLASSIFIED
Sf'cllritv Classification

DOCUMENT CONTROL DATA· R&D
rSt'('urity cla:,;sification 01 title, body 01 abstract illIJ illd ... xill~! annotation must bt' ~lItl'rt'd
1. ORIGINATING ACTIVITY (Corporate author)

II", UVt'r.,lI rt'fJdrt i., clil,.,Uieu)
CLASSIf-I<:A110r·.

Unclassified

Stanford Research Institute
Menlo Park, California
3. REPORT

1""""

2D, REF'ORT SECURITY

TITLE

Advanced Intellect-Augmentation Techniques
4. DESCRIPTIVE NOTES

(Type 01 report and inclusive dates)

Final Renort
5· AU THOR(S)

(First name, middle initial, last name)

D. C. Engelbart and Staff of

~ugmentation

6· REPORT DATE

7a.

TOTAL NO. OF PAGES

OF REFS

212

July 1970
8 •.

Research Center

CON TRAC T OR GRAN T NO.

9a. ORIGINATOR'S REPORT NUMBER(S)

SRI Project 7079

NASl-7897
b. PROJECT NO.

9b. OTHER REPORT NOIS) (AllY other number:,; tpat nw. /).' t1.>sIRned
this report)

d,
10. DISTRIBUTION STATEMENT

SUPPLEMENTARY NOTES

12. SPONSO.RING

~ILITARY

ACTIVIT,

National Aeronautics and Space Administratipr
Langley Research Center
Langley Station, Mail Stop 126
Hampton. Virginia 23365
13.

"SSTRACT

This report covers a two-year project, at the eleventh year of a growing, multiproject
program that is exploring the value of computer aids to augmenting human intellectual
capabi Ii ty.
OUtlined briefly are the background and the "bootstrapping" nature of the program, its
resources, and the activities it has undertaken in pursuit of its goals.
Advances made during the project were:
(1) Making operational an experimental interactive laboratory comprising an
XDS-940 computer, special interface and display hardware, a modified UCB-GENIE
timesharing system, six NLS consoles and sixteen typewriter terminals, a 96-megabyte
file-storage disk, and a 96-character line printer
(2) Making extensive progress in the development of special-purpose languages and
software architecture to provide for both highly interactive service and flexible
system evolution
(3) Moving our team of system developers into an on-line working mode, and beginning
to learn how to adapt to this environment--with encouraging success, as represented
by our emerging "software-engineering" methodology
(PAGE 1)
SIN 0101.807.6801

UNCLASSIFIED
Security Classification

Continuation of DD Form 1473, Abstract,

Item 13

(4) Establishing a plan, and partially implementing the basic services,
for an information center to serve the experimental ARPA Network.
User experience in applying our augmentation tools and techniques to
various normal working tasks within our Center is described so as to
convey a subjective impression of what it is like to work in an augmented
environment.
It is concluded that working-support, computer-aid systems for augmenting
individuals and teams, of the general sort we have been experimenting
with, are undoubtedly going to be widely developed and used.
A very special role in this development is seen for multi-access computer
networks:
they will become special marketplaces where a new kind of
competitive evolution will take place, not only in hardware, software,
and special services as "bought" from a "utility," but also in roles,
skills, working methods, and employment dynamics for the intellectual
workers at the terminals.

Security Classification
14

L...INK B

L...INK A
KEY

ROL...E

Intellect Augmentation
Man-Machine Communication
On-Line Interaction
ARPA Network
Network Infonnation Center
On-Line System
NLS
TODAS
Documentation
Text Manipulation
Computer Displays

lFNOoR~.. 1473

(P AG~ 2)

L...INK C

WORDS

(BACK)
Security Classification

ROL...E

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
XMP Toolkit                     : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37
Create Date                     : 2011:06:22 11:35:08-08:00
Modify Date                     : 2011:06:22 11:46:38-07:00
Metadata Date                   : 2011:06:22 11:46:38-07:00
Producer                        : Adobe Acrobat 9.43 Paper Capture Plug-in
Format                          : application/pdf
Document ID                     : uuid:68cb08e3-f884-4c32-87d0-17ed40a37bb9
Instance ID                     : uuid:f8740d3e-d963-4256-96b7-31a82f02cdde
Page Layout                     : SinglePage
Page Mode                       : UseNone
Page Count                      : 204

EXIF Metadata provided by EXIF.tools

Advanced_Intellect Augmentation_Techniques_Jul70 Advanced Intellect Augmentation Techniques Jul70

Advanced_Intellect-Augmentation_Techniques_Jul70 Advanced_Intellect-Augmentation_Techniques_Jul70

Navigation menu

Versions of this User Manual:

Views

Navigation