- -, 3 i.?
NASACONTRACTOR NASA REPORT C.1
LOAN COPY RETURN TO AFWL (DOWL) KIRTUND AFB, N. M,
ADVANCED INTELLECT-AUGMENTATION TECHNIQUES by D. C. Engelburt und Staff of Augmegztution Reseurch Center
Prepared by STANFORD RESEARCH INSTITUTE Menlo Park, Calif. 94025 .for LangZey Research Center - .~ - .. - - . . . - - "_ - -- 1. ReportNo. I 2. Government Accession No. 73.Recipient's Catalog No.
NASA CR-1827 """ ~~~ ~~ 1 .~ ~~~ I 4. Title and Subtitle 5. Report Date February 1972 ADVANCED INTELLECT-AUGMENTATION TECHNIQUES 6. Performing Organization Code
__~___. .___ I 7. Author(s) 8. Performing Organization Report No. D. C. Engelbart and Staff of Augmentation Research Center SRI Project 7079
. -~ . - ~ 10. Work Unit No. 9. Performing Organization Name and Address
Stanford Research Institute 11. Contract orGrant No. MenloPark, California 94025 I NAS1-7897 13. Type of Report and Period Covered -~ ~ ~ 12. Sponsoring Agency Name and Address Contractor Report
National Aeronautics and Space Administration 14. Sponsoring Agency Code Washington, D.C.20546
__~__-~ 15. Supplementary Notes This report covers the extension of research previously reported in NASA CR-1270.
~ "- 16. Abstract 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 capability.
Outlined briefly are the background and the "bootstrapping" nature of the program, its resources, ai the activities it has undertaken in pursuit of its goals.
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, 'I but also in roles, skills, working methods, and employment dynamics for the intellectual workers at the terminals.
~____.." ~- -... 17. Key Words(Suggested byAuthor(s)) 18. Distribution Statement Intellect augmentation Man-Machine communication Unclassified - Unlimited On-line interaction ARPA network Text manipulation Computer displays .~ -. .. - -
19. Security Classif. (of this report) 20. Security Classif. (of this page) 21. No. of Pages ' 22. Price' Unclassified Unclassified 201 $3.00
- - ""~ . "" ~ ____
For sale by the National Technical InformationService, Springfield, Virginia 22151 I PREFACE
Theresearch described in this report represents conceptual, design,and development work by a largenumber of people; the programhas been active as a coordinatedteam effort since 1963. Theresearch reported here was a cooperativeteam effort involvingthe entire ARC staff.The following is an alphabetical listingof the current ARC staff:
Geoffrey H. Ball,Walter L. Bass,Vernon R. Baughman, Mary G. Caldwell,Roberta A. Carillon,David Casseres, Mary S. Church, William S. Duvall,Douglas C. Engelbart, William K. English, AnnR. Geoffrion, Martin L. Hardy,Jared M. Harris, J. David Hopper,Charles H. Irby, L. StephenLeonard, John T. Melvin, N. DeanMeyer, James C. Norton, Bruce L. Parsley,William H. Paxton,Jake Ratliff, Barbara E. Row,Martha E. Trundy,Edward K. Vande Riet, John M. Yarborough.
Thefollowing former ARC staffmembers also contributed to the research:
Donald I. Andrews,Roger D. Bates,David A. Evans, Stephen R. L,evine, Stephen H. Paavola,Helen H. Prince,Jons F. Rulifson, Elmer B. Shapiro, F. K. Tomlin.
CONTENTS
PREFACE ...... iii LIST OF ILLUSTRATIONS ...... vi I INTRODUCTION ...... 1 A . General ...... 1 B . ResearchApproach and Strategy ...... 1 C . PrincipalConcerns During the Contract Period...... 2 . D. Structureof This Report ...... 3 I1 RESOURCESAND ACTIVITES ...... 5 A . Introduction...... 5 B . Resources ...... 5 C . Activities ...... 19 111 APPLICATIONSAND EXPERIENCE ...... 23 A . Introduction...... 23 B . TheAugmented Software Engineer ...... 29 C . TheAugmented Manager ...... 63 D . TheAugmented Report-Writing Team ...... 103 E . TheAugmented Presentation ...... 112 IV THENETWORK INFORMATION CENTER ...... 119 A . Overviewof the ARPA Network ...... 119 B . Someof Our Prospective Uses for theNetwork ...... 122 C . Needfor a NetworkInformation Center ...... 125 D . NICDevelopment Activity ...... 126 E . CurrentNIC Plans ...... 129 V CONCLUSIONS.RECOMMENDATIONS. AND PLANS ...... 133 A . introduction...... 133 B . ConclusionsRelevant to Other Augmentation-System Developers ...... 133 C . OurGeneral Orientation Towards Future Research ...... 146 D . Overvewof Current Augmentation Research Center Plans ...... 150 AppendixA: User Features of NLS andTODAS ...... 173 BIBLIOGRAPHY ...... 195
V
I- . ILLUSTRATIONS
Figure 11-1: XDS940 COMPUTER FACILITY ...... 6
Figure 11-2:SPECIAL DEVICES CHANNEL ...... 7
Figures 111-1 through 111-28: PHOTOGRAPHSSHOWING NLSDISPLAY IN USE BY A SOFTWARE ENGINEER ...... 35-62
Figures 111-29through 111-56: PHOTOGRAPHSSHOWING NLSDISPLAY OF MANAGEMENT INFORMATION FILES ...... 75-102
Figure V-1: "HERMAN MILLER" CONSOLE ...... 137
Figure V-2: ONE-PIECE CONSOLE ...... 138
Figure V-3: CURRENTCONSOLE DESIGN ...... 139
vi I INTRODUCTION
A. General
TheAugmentation Research Center (ARC) is a community of researchers,supported by several contract sponsors. It is dedicatedto exploring the possibilities for augmentingthe intellectualactivities of people working in complex problem-solvingsituations.
By"augmentation" we mean increasing the capability of a personor organization to approach complex situations and identifyproblems present there, to gain comprehension of thenature and context of these problems, and to derive solutionssatisfying given constraints.
Suchincreased capability may be r.eflected in anyof the followingways: faster and better.comprehension, the possibilityof gaining a usefuldegree of comprehension in situationsthat were previously too complex, faster and bettersolutions, and the possibility of finding solutions toproblems that previously seemed insolu.ble.
B. ResearchApproach and Strategy
ARC'Sorientation is based on the fact that modern man is confrontedwith problems of increasing complexity and urgency, andthe assumption that in attacking these problems the best long-termpayoffs will morelikely come through the developmentof more powerful p.roblem-solving tools of a generalnature than through direct, piecemeal attacks on specificproblems of immediate urgency.
Thisorientation was spelled out in 1962 in a planning document(Ref. 2) thatprovided the conceptualframework under which ARChas been evolving. (Note: keference numbers are not consecutivein this report, but refer to the chronological bibliography.)Our approach to augmentation research has two essentialaspects: the externalization of intellectual structures in symbolicform, making use of highlyinteractive computersystems, and the application of a bootstrapping strategyin the research program for developing augmentation systems.
Thepurpose of externalization via computer systems is to make it possiblefor people to work with intellectual structures(such as computer programs or highly interconnectedbodies of textual information) of much greatersize and complexity than can be effectually handled with traditionaltechniques. The aim in designingthe computersystems has been to provide people with
1
I_ . . - Section I INTRODUCTION
increasinglyflexible and powerful ways of using structures ofsymbols to represent intellectual structures and of viewingand manipulating these symbolic structures.
Thebootstrapping strategy has been used in orderto ensure thetightest possible feedback in theprocess of developing augmentationaids and in orderto catalyze the research programby bringing higher and higher levels of augmentationto the researchers themselves. All augmentationaids designed by ARC areintended for actual, practicaluse in ARC itself,and once implemented they are, for themost part, used heavily on a day-to-daybasis.
C. PrincipalConcerns During the Contract Period
Duringthe period covered by this contract,three ongoing processesreflected the principal concernsof ARC: the followingsections describe these processes.
1. NLS Development
Atthe end of theprevious contract period (see Ref. 12). themulti-user On-Line System, NLS (whichhad been developedfrom previous singie-user systems), had been carriedfrom the early design stages through almost completeimplementation. During the subsequent two years, NLS hasdeveloped into an experimental operational system thatis now in heavyroutine use bythe ARC staff.
ARC resourceshave been heavily committed to increasingthe operationalspeed and reliability of the many components of thesystem, improving the interaction of these components within thetotal system, and improving and extending the userfeatures of the system.
2. Evolutionof Goals
Oneusage trend that has become evident during this period is a tendencyfor staff members who are working on a common problem to gatheraround an NLS console so asto have on-lineaccess as a groupto the working files that they areusing in common. Even when working individually, group membersfrequently sit at neighboring consoles so asto be able to converseabout related tasks in progress.
Thistrend has been reflected, through bootstrapping, as an
2 Section I INTRODUCTION
evolutionof ARCgoals from the augmentation of individuals tothe augmentation of task-oriented teams.
Muchthought has been put into deciding which areas of researchseem to offer the greatest promise for improving theability of augmented individuals to cooperate on a commonproblem, and during the next few years one of the majoractivities at ARC will bethe development of team-augmentationfacilities and techniques. Some of the developmentscurrently being considered are discussed in Section U.
3. ARPAComputer. Network Participation
Duringthe contract period we completed plans for connectinaARC'S computer facility into the experimental ARPANetwork, which eventually will linkthe computer facilities of about 14 computer-scienceresearch centers. We feelthat the Network is a significantstep in the evolutionof augmentation fechnology, and we are working withthe other Network participants in order to ensure the successof this experiment.
We haveagreed to provide a NetworkInformation Center (NIC)for the Network, and over the past two years we have beencommitting an increasing portion of ourresources to theplanning and development of NIC services. We expect thatthe success of the Network experiment will be signLficantlyaffected by the quality of servicesthat the NICcan provide.
D. Structureof This Report
Theremainder of this report is divided into four major ~ sectionsand a supportingappendix. We haveattempted to describewhat we have done and learned during the past two years,without elaborating either on the technical details of ourhardware/sottware system or onthe past history of our researchprogram.
Theselatter topics arecovered in thereferences cited in theBibliography of thisreport. In particular, the followingmay be of interest:
The 1962 planningdocument (Ref. 2) providesthe conceptualbackground for our approach to augmentation research,
3, I
Section I INTRODUCTION
The 1968 FJCCpaper (Ref. 14) givesan overview of our AugmentationResearch Center,
The 1970 finalreport for another sponsor (Ref. 171 discussesmany technical details of our system implementation.
Section I1 ofthis report describ.es the resources -- human, organizational,hardware, and software -- that ARChas availablefor its research and discusses ARC'S ongoing activities.This material is supplemented by AppendixA, whichbriefly describes several of theprimary elements of our augmentationsystem.
Section 111 is a coIIe.ctionof subjective descriptions of our experienceas augmented workers in several of ARC'S central activities.Two of thedescriptions (for software engineering andmanagement research) are supported by illustrated scenariosshowing actual work in progress.
Section IV contains a description of theARPA Network from a user'sstandpoint and a discussionof some probable, early usesof the Network. We pointout some of the services that Networkparticipants will need in order to make effective use ofthe Network and indicate how we are attempting to satisfy thoseneeds through the Network Information Center.
In Section V we discusssome of the conclusions drawn from our researchand indicate the directions in which we plan to developour research in thefuture.
4 I1 RESOURCESAND ACTIVITIES
A. Introduction
In this sectionwe describe the resources that have been availableto us duringthe past two years and the activities wehave undertaken to apply these resources to the pursuit of ouraugmentation goals.
We usethe term"resources" in the broad sense toinclude all theassets wepossess as a team,including the following:
(1) Hardwarefacilities
(2) Systemsoftware
(3) Usersystems
(4) Personnel(human resources)
(5) Organizationalrelationships.
Ourmajor organizational relationships are to SRI andto the ARPANetwork.
TheAugmentation Research Ceiiter operates at the group levelwithin the SRI Information Sciences Laboratory and, consequently,has access to the extensive and varied resourcesavailable through a large,diversified research organizationsuch as SRI.
As aninitial participant in the ARPANetwork, we will have access to allservices that eventually become available throughthe Network. The implications of thisare explored inSections IV and V of thisreport.
Ourother resources are discussed in somedetail below, along withbrief descriptions of ourmajor on-goingactivities.
B. Resources
1. TheComputer Facility
At thebeg;ning of thecon~ract period the current ARC computerfacility was almost complete, and the basic configurationhas been relatively stable over thepast two years.This Section briefly describes this facility (diagram.medin Figures 11-1 and 11-21 anddiscusses some of thechanges and additions made during the contract period.
5
f I I CTE-11 ' CONSOLE - MAGNETIC I TTY TAPE I I MAGNETIC MAGNETIC I TAPE - TAPE I CENTRAL CONTROL - PROCESSOR I COMMUNICATION W ITH TIME- TMCC TIME- WITH I I EQUIPMENT - SHARING MAGNETIC I HARDWARE TAPE I PAPER I - TAPE I I STATION I 16Teletypes I 1 I I I 16 K 16 K 16 K CORE CORE CORE I I I I I M A M MAM MAM MAM MAM
(I
T TY CTE-11 TTY
SPECIAL CONTROL I RAD DEVICES CHANNEL
TA-5919-3R
FIGURE 11-1 XOS940 COMPUTER FACILITY Mouse T.V. Monitor DISC DISC - - 5” C.R.T. T.V. Camera m CONTROL FILE
I dL-1 -I DISPLAY DISPLAY I - CONTROL - GENERATOR -- I 1 I 1 -1 I -1 -1 DISP LAY DISPLAY DISPLAY I - CONTROL - GENERATOR “ I 2 2 -I EXECUTIVE -! CONTROL
NETWORK ARPANetwork INTERFACE l7-Y I 1 INPUT t DEVICES f CONTROL
PRINTER PRINTER CONTROL TA-7101-3
FIGURE 11-2 SPECIAL DEVICES CHANNEL Section I1 RESOURCESAND ACTIVITIES
Themost siyinificant additionshave been the ARPA Networkinterface and anexternal core system.
a.The Leased Computer
Figure 11-1 is a blockdiagram of the facility as leased from XDS.
A centralprocessor with timesharing hardware operates from a 64K memoryin four banks with 24-bit words and a cycletime of 1.8 microseconds.
Onchannels sharing memory access with the CPU are three magnetic-tapedrives, a paper-tapestation, and communicationequipment for sixteentypewriter terminals.
A secondmemory buss provides direct access to memory for the RADS (RapidAccess Devices -- e.g.,drums) and thenon-XDS portion of thefacility, designated "Special DevicesChannel" in Figure 11-1.
Thereare three drums on the system, operating from a commoncontroller and accessing memory through an XOS devicecalled a DirectAccess Commmunications Channel (DACC).Each drum has a capacity of 500,000 29-bit words, a transferrate of 120,000 wordsper second, andan average latency of 17 milliseconds.
b.Special Devices Channel
Figure 11-2 is a blockdiagram of the portion of the facilitythat has been put together by ARC. The followingsections describe the major components.
(1) ExecutiveControl
Theexecutive control provides an interface to the 990 throughthe Memory Interface Connection (MIC). It actsas a mult.iplexerthat allows asynchronous access to coreby any of the six devices connected to it.
It includesextensive debugging and monitoring aids,
8 Section I1 RESOURCES AND ACTIVITIES
allowing the monitoring-of data and addresses for any 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, 1968. It consists of a Bryant Model 4061 disc file and associated controller. The system has a capacity of 32 million words, an average access time of 185 milliseconds, and a data transfer rate of r3.000 words per second. The disc controller was designed and built by Bryant to interface with the executive control. Specifications for the controller were developed jointly by Bryant, Project GENIE at UC Berkeley, and ARC. (3) DisplaySystem The display system consists of two identical subsystems, each with a display controller, a display generator, and six high-resolution 5-inch CRTs. A closed-circuit television system carries display images from the CRTs to television monitors in the working area. The display controllers were designed and built by ARC. They access and process "command tables'' that are resident in 940 core.
A command is roughly associated with a user and points to a "display list" in the user's core space. The display list in turn points to buffers containing actual display instructions (commands to the display generator to produce images). The display controller handles all core accessing, including memory mapping for the user's core space. It passes the display instructions along to the display generator. The display generators and CRTs were purchased from TaskerInstruments to ARC'S specifications. They have general character and vector capabilities.
9 Section I1 RESOURCES AND ACTIVITIES
Presentationsfor each of the six CRTs are generatedsequentially, and unblank signals from thedisplay co.ntroIIers select one or more of the CRTsat a giventime.
A high-resolution(875-fine) closed-circuit televisionsystem transmits display pictures from eachCRT to a televisionmonitor at a corresponding NLS console.
(Lt) InputDevice Control
Inaddition to thetelevision monitor, each console has a keyboard, a binarykeyset, and a mouse. Appendix A describesthe use of these devices.
Thestate of these input devices is read by the input devicecontroller at a presetinterval (about 30 milliseconds)and written into a fixedtable in 940 core.
Bitsare added to informationfrom the keyboards, keysets,and mouse switches to indicate when a new characterhas been received or when a switchhas changedstate during the sample period. A new character or switchchange causes an interrupt to beissued at the end of the sample period.
Mousecoordinates are digitized by an AID converterand formatted by the input device controlleras beam-position instructions to the displaygenerator. A userprogram may include the mousecoordinates, as written by the input device controller,as part of a displaylist. This allowsthe mouse position to be continually displayedwith no attention from theCPU and no perceptibledelay to the user.
(5) LinePrinter
Theline printer is a 96-characterdrum printer leased from DataProducts Corporation (Model M600-11AI. Withthe 96 characters,printing speed is 340 linesper minute.
Theline printer controller processes print buffers of arbitrarylength that have been set up in core by
10 Section I1 RESOURCESAND ACTIVITIES
a controllingprogram (single-line buffers are normallyused).
(6) NetworkInterface
Thenetwork interface provides communication between the 940 andan Interface Message Processor (IMP) on theARPA Computer Network. The interface operates from messagebuffers in 940 core.Messages to the Networkare read by the interface from these buffers andtransmitted to the IMP. Similarly, messages receivedfrom the IMP are written into buffer space in 940 core.Instructions from the 940 enablethe systemfor receiving messages and control the sending ofmessages. A "Iinked-buffer"scheme permits flexiblememory allocation.
Theinterface message processor and its communicationsprotocol are discussed in detail in Ref. 18.
c. TypewriterTerminals
Atthe begining of theproject the only terminals in use (otherthan the display consoles) were Model 33 Teletypes.Since then we havebeen experimenting with differenttypes of terminals,looking for improvements inspeed, print quality, and portability.
Thenewer terminalsnow in use, andsome of their features, arebriefly described in thissection.
It shouldbe remembered that the only terminals we haveconsidered are those with upper-and lower-case printand full-duplex operation.
(1) TheModel 37 Teletype wasone ofthe first terminalsadded, and three arenow inuse.
It operatesat 15 charactersper second (as compared to 10 charactersper second for the Model 33) andhas excellentprint quality and reliability.
It has a highnoise level and is large and heavy.
(2) We havefour GE Terminet-300terminals in use. Section I1 RESOURCES AND ACTIVITIES
Thesehave switch-selectable rates of 10, 15, and 30 charactersper second. They have a chainprinting mechanismthat is relatively quiet and have good printquality when in adjustment.
Theseterminals seem to require more frequent maintenancethan any others in use, but wehave early modelsand they may improve in later production.
(3) Thebest terminal we havefound for portability is theExecuport, manufactured by Computer Transceiver Systems.
Theseterminals are used by our staff for remote operations,usually in a staffmember's own home, and comein a portablecase complete with acoustic couplerand weighing only 26 pounds.They have switch-selectablerates of 10, 15, and 30 characters persecond.
Thethermal print mechanism is very quiet in operationbut print quality is poor; characters are madefrom a 5 x 7 dotmatrix.
d.Modifications inProgress
Twomodifications to the facility that will provide significantimprovement in service are now being implemented.These are an external core system and fasterdrums. In addition, an accurate clock system is beingadded.
(1) ExternalCore System
Anexternal core system has been completed and will beintegrated into the facility in the near future, It currentlyconsists of a single32,000-word bank withaccess switching to allowaccess by up to eight devices.Provisions are included in the design for expansion to 16 devicesand two core banks of 6L1,OOO wordseach. The core cycle time is 1.5 microseconds andthe word length is 24 bits.
Theprimary purpose of this core systemis to provide storagefor display buffers, the network interface, andthe line printer. These are the devices that needconstant buffers for relativelylong periods of
12 Section I1 RESOURCES AND AC'IIVITIES
timeand therefore require "frozen pages" when operatingfrom 940 core -- a significantfactor in limitingsystem response, since thay take up space thatcould otherwise be used for swapping.
(2) Faster Drums
Fromsystem response studies (Ref. 17) it is apparent that a primaryfactor in response is theswapping bandwidth. To improveresponse (and add more users), we are in theprocess of replacing the XDS drums with Univac FH-Lt32 drums.
Thesedrums rotate at 7200 RPM, giving a transfer rateof 365,000 wordsper second (as compared to 120,000 forthe present drums) and an average accesstime of about 4 milliseconds.
Inaddition, weare formatting the new drums in a waythat will allow a pagetransfer to begin at anyposition on the drum. Since a 2048-wordpage fills two-thirdsof a band,this will givean averagepage transfer time ofabout 8 milliseconds.
Theinterface for the drums will bedesigned and builtby ARC. It will connectto the 940 through a secondMemory Interface Connection (MIC), replacing thecurrent RAD-DACC combinationshown in Figure 11-1.
(3) ClockSystem
Anaccurate clock system is being added to assist us insystem measurements.
Thisclock system provides two types of time information -- absoluteand relative -- thatare writteninto fixed locations in 940 coreat regular intervals.The long-term drift on the clock will be lessthan 1 secondin 250 days.
2. SoftwareSystems
Thecentral focus of softwareactivity at ARC isthe evolutionarydevelopment of the On-Line System (NLS). This takesplace within a richenvironment of software systems, Section JJ RESOURCESAND ACTIVITIES
manyof which were created specifically to aid in its development.The following is a briefdescription of the majorsy.stemr.
a.The Timesharing System (TSS)
Mostbasic to the operation of NLS, aswell as all our othersoftware systems, is the timesharing system (TSS) runningon the XDS940.
TSS wasoriginally developed by Project GENIE at UC Berkeley,but responsibility for maintenanceof the ARC versioncurrently lies with the Center itself. NLS runs as a subsystemunder TSS, and users also have access to othersubsystems such as the NARP assembler, KDF file storagesystem, and DDT debuggingsystem.
Thesupport of new hardware and improved response to the NLS userare the major areas of improvementin TSS over thepast two years.
b.Software Architecture
(1) Introduction
Thedevelopment of NLS has beenfacilitated greatly throughthe use of a powerfulcomplement of languages andcompilers, most of which were designed at ARC.
Thelanguages used range in generality from theNARP assemblylanguage through a collectionof special-purposeIan’guages (SPLs) unique to NLS implementation.Their major features are discussed brieflybelow.
(2) NARP
A fewparts of NLS canbe most conveniently coded in assemblylanguage (e.g., the data page and the display-buffers),and for these the NARP assembly languageis used.
Also, forhistorical reasons, the timesharing system (TSSI andmost of its subsystems(e.g., KDF andDDT) arecoded in NARP.
14 Section I1 RESOURCES AND ACTIVITIES
(31 MOL940 MOL940 (or simply MOL) is a machine-oriented language for the XDS940 and was created by ARC to aid in the programming of NLS.
MOL combines the flexibility of assembly language with the algorithmic clarity of higher-level procedure-orientedlanguages.. Much of NLS is coded in MOL.
During the contract period MOL has been substantially rewritten to improve its performance and provide new programming features. The current MOL compiler was produced using the new version of Tree Meta (d.escribed below); consequently, the MOL compiler now generates binary machine code directly rather than producing assembly-language code as an intermediary.
(4) Special-PurposeLanguages (SPLs)
Many of the higher-level operations of NLS are carried out by programs written in one of a set of special-purposelanguages (SPLs). Eachof these languages is 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 NLS, 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, the content-analysis language, and the string-constructionlanguage.
Detailed descriptions of the SPLs will be found in Appendix D of Ref. 17. Although extensive changes in the SPLs are planned for the near future, no basic conceptual changes were made during the contract period. Section I1 RESOURCES AND ACTIVITIES
(5) TreeMeta
Tree Meta is 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. 17 contains a brief overview of the current version of Tree Meta; a more detailed description is in preparation for release as a separate report.
c. NUTILITY
To aid our software engineers in maintaining the approximately 150 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.
3. UserSystems
This section briefly describes our principal on-line user subsystems; more complete descriptions are contained in Appendix A.
a.On-Line System (NLS) The On-Line System, NLS, as currently implemented, is a highly sophisticated system oriented toward the on-line construction, editing, and viewing of files.
NLS 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 mostfrequently used portions. The source languages used are NARP, MOL940, and the SPLs. A complete description of NLS, including program documentation, is in Ref. 17.
16 Sect ion II RESOURCESAND ACTIVITIES
b. Typewriter-OrientedDocumentation-Aid System (TODAS)
In responseto growing pressures to make access to our on-linefiles available to Network participants, as well a5to members of our own staff working at remote locations,we developed a newsubsystem called TODAS (Typewriter-OrientedDocumentation-Aid System).
TODASuses the same structure for working tiles as NLS andprovides most of the same editing and view-specificationcapabilities, along with a few specialfeatures of its own. Thus, users can freely movefrom one type of terminal to another without losing accessto any of their on-line working records.
TODAS offersour on-line users the possibility of tradingoff speed of operationfor freedom of location. It alsomakes it possiblefor us to increase the number ofon-line users that can be serviced simultaneously, since a TODASuser places less heavy demands on our computationalrcsources than does an NLS user.
c.Output Processor (PASS41
TheOutput Processor (also called "PASSLt" for historical reasons)is a programfor formatting on-line text files for outputthrough a variety of devicesincluding line printers.paper-tape-driven typewr.iter5, and computer outputto microform (COM) devices.
4. Personnel
Thefinal, critical element of ARC'S resourcesis its staff of professionalresearchers and support personnel. The experimentalnature of ourwork requires high-caliber individualswho can function effectively in our team, learn quicklyto work with our systems and methodologies, and progresscreatively along with the rest of theteam and its products.
Ourstaff members need to be able to adapt to the rapidlychanging ARCenvironment and to persevere throughvery disturbing periods of systemservice level fluctuation.
Ourselection of people for specific tasks is influenced Section I1 RESOURCES AND ACTIVITIES
notonly by skills already developed, but also by potentialsfor further development.
Effectiveutilization of our human resources requires a carefulbalance between selecting those people most likelyto get critical tasks done well and those whose developedcapabilities will bestrained by the tasks theyundertake (and hopefully extended in the process).
In ARC'S earlieryears our primary need was for individuals skilledin tool building, with only secondary importance assignedto methodology development skills. Thus, most of ourearlier researchers were system-oriented software and hardwareengineers.
As thesystems developed became more generally useful, providingaids and service levels beyond the system engineers'basic needs, we entered a maturingphase of facingthe challenge to use the system for a broaderrange cf tasks.
People,have recently been added whose interests focus on thestudy of the user system itself, on use of the systemfor management purposes, and on its role in supportingthe Network Information Center.
Thesepeople have brought different needs and perspectivesinto the group, directly aiding the design ofmany system improvements. Interaction atthe day-to-daysystem development level has provided a rich learningexperience for most people, particularly in technicalareas they might not otherwise have learned muchabout.
Thisdiffusion of knowledge in areas such as system design,system building, system analysis, and management addsnew perspective to eachperson's approach to problems in hisown areas of specialization.
18 Section I1 RESOURCES AND ACTIVITIES
At present we have a full-time staff of 25, constituted as follows: Professional ...... 18 Supervisory ..... 1 Software ...... 11
Hardware ...... Lt Other ...... 2 Non-professional ...... 7 Technical ...... 3
Clerical ...... 4 C. Activities
1. Introduction This section outlines the nature and purposes of the major activities carried on during the past two years of our project. It was the pursuit of these activities that produced the developments, experiences, and conclusions discussed in the other sections of this report. The greatest portion of our resources were allocated to the basic ARC bootstrapping pursuit, which consists of these major activities:
(1) Development end operation of our service system (2) Development of methodologies for harnessing the user features offered .by the service system
(3) Application of these augmentation tools and techniques to the pursuit of all our activities
(4) Assessment of our overall augmentation system to guide its further evolution. Section I1 RESOURCESAND ACTIVITIES
Twoother major activities received considerable attention andresources:
(5) Connectionof our Center into the ARPA Network
(6) Developmentof an Information Center for the Network.
2. Developmentand Operation of Our Service System
Thecoordinated development of hardware and software aspectsof our augmentation system, which has been under waysince 1963, wascontinued with particular emphasis on activitiesaimed at preparing us for our role in the ARPA Network.
We havecommitted a substantialportion of our resources to improvingthe reliability and capacity of the service systemand will continue to do so, a majormilestone being ourplanned transfer to a PDP-10 computerthis fall.
Anothermajor effort has been preparation for expanded remote-workercapabilities, both to facilitate use of our systemby other Network participants and to continue our effortsto increase the flexibility of working arrangements for membersof our own research community.
Thereis already one member of our team (a software engineer)who works remotely from his home in Sonoma County(about 100 milesfrom our Center), and we have plansto extend this capability to other members as conditionspermit.
3. Developmentof Methodologies for Harnessing the User FeaturesOffered by the Service System
It haslong been part of our plans to apply toward this activityresources comparable to those for the service systemdevelopment activity, but unforeseen difficulties in thelatter area have forced us to divert more of our energiesto it thanwas originally envisioned.
However,many methodological developments have been evolvingmore or less naturally as individuals adapt the featuresof the service system to their particular needs. Thestrongest such evolution has taken place within the
20 Section I1 RESOURCESAND ACTIVITIES
areaof software engineering, which is the focus of consistentlyheavy activity by many ofour people.
In onespecific area -- managementsystems -- wehave engaged in anexplicit effort to develop improved methodology.This has been funded separately by a contract withthe Rome Air Development Center, which has enabled us toapply one or twofull-time people toward this Management SystemsResearch activity for the past two years.
4. Applicationof Augmentation Tools andTechniques to the Pursuit ofAll Our Activities
Ouraugmentation system is in dailyuse by most members of ourstaff. Detailed discussions of severalexamples of this useare given in Section 111.
5. Assessmentof Our Overall Augmentation System to Guide Its FurtherEvolution
Oneof the basic requirements for carrying out a bootstrappingoperation is to maintain constant awareness ofthe status of thatoperation 50 asto be able to make rationaldecisions about what developments should be undertakennext.
We havemade some attempts to quantify this process through thetaking of system performance measurements and the simulation of variousexisting and proposed system configurations.However, most of our workin this area stillhas a veryintuitive character, and wehave been hampered in ourefforts to improve on this by the necessity forcommitting so muchof our resources to basic service-systemdevelopment activities.
6. Connectionof our Center into theARPA Network
Tomake it possiblefor ARC to participatein the ARPA Network(see Section IV), wehad to design, build, and install a deviceto interface our computer facility to a NetworkInterface Message Processor (IMP). This Network interfaceis described in SectionII-B-1-f.
7. Developmentof a NetworkInformation Center (NIC)
In preparingto fill ourrole as Information Center for the ARPANetwork, we havebeen involved in developing the tools
21 Section I1 RESOURCES AND ACTIVITIES
and methodologies that we will need in order to provide an increasingly on-line, special-purpose library for a widely distributed clientele. The high technological base of this Network experiment demands that we try to harness as much as possible of this technology for the Network Information Center so 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 so 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 there we would be able to expand our user-carrying capacity rapidly. This led to a number of major efforts:
(1) A seriesof significant architectural and compiler changes within our software systems
(2) Severalrather intensive trial designs for alternate expanded-capacity system configurations
(31 A concerted effort in developing computer aids for analyzing performance characteristics of proposed systems.
These efforts culminated in a decision to move our systems onto a PDP-10 c6mputer late this fall, and we are currently involved in the leasing, purchasing, contracting, engineering, fabricating, and programming activities necessary to accomplish this transfer.
22 I11 APPLICATIONSAND EXPERIENCE
A . IntroductionA.
Thissection consists of relatively informal accounts describingthe application of our,augmentation systems to severalareas of our own work while attempting to convey some feelingfor what it is liketo work within an augmented total system.
Section III-B waswritten by Charles H. Irby,an ARC software engineer. It describesin considerable detail the ways in whichan augmented software engineer can exploit our computer systemsto help him inthe continuing development of these samesystems.
Inaddition, Section III-B servesas an introduction to our On-LineSystem, NLS. It issystematically illustrated with photographsof an NLS display,showing actual sequences of displaysthat the software engineer would see as he worked. (Readerswho are not familiar with NLS will find a descriptionof its user features in AppendixA, which includes a glossaryof special NLS terminology.)
SectionIII-C deals w.ith "augmented management" and was writtenby James C. Norton, who heads our Management Systems ResearchActivity and is also involved with carrying out much ofour operational project management.
Thissection, illustrated with display photographs like thoseof Section III-B, showshow some of the most sophisticatedfeatures of NLS canbe put to use in a field outside of softwareengineering. Specific applications to projectcost accounting, cost estimation, work planning, andother areas are covered.
Thediscussion develops a total-systemconcept of the meaningsof "management" and "management augmentation" and revealshow augmentation interacts with variousaspects of ARC.
Section III-D describesour use of augmentation systems in writing,editing, and producing reports. The author of this section,David Casseres, is ARC'S technical writer and has beencentrally involved in ARC reportwriting since the inception of thiscontract.
Herewe see the use of augmentation systems in a field where it isdifficult to apply them, because the problems oftechnical writing are so manyand so dependenton individuals. Section I11 APPLICATIONSAND EXPERIENCE
It appearsthat although the benefits of augmentation in writing,editing, and producing reports are considerable, themost significant benefits come from the use of a very closeteam-collaboration method, which would be virtually impossiblewithout augmentation.
Section 111-E waswritten by Douglas C. Engelbart and covers the augmentation of communicationbetween a speakerand his audience.
Thiskind of communication, which we have used for explainingaspects of ourwork to audiences ranging from a singleperson to thousands, is potentially one of the most excitingareas of application for augmentationtechnology.
B. TheAugmented Software Engineer
Oneof the central objects of our augmentation research has been to developspecial tools and working methods for augmentingthe design and implementation of our system software.
Section 111-B-I belowoutlines the general augmentation needs of a softwareengineer and the aids provided at ARC to meetthese needs.
Section 111-B-2 describesthe ways in which our software engineersactually use the systems we have been developing intheir daily work.
We payparticular attention to the use of the system-guidefile, SYSGD, which is central to the software-engineeringaugmentation system.
Theuse of SYSGD is illustrated with photographs of an ARC interactivedisplay, showing the views seen by the softwareengineer as he works to implement a new NLS feature,using SYSGD as a reference.
1. GeneralConsiderations
Theaugmented software engineer needs the following minimal capabilities:
(1) Theability to rapidly access, understand, and manipulatethe source code
24 Section 111 APPLICATIONSAND EXPERIENCE
(2) Theability to easily compile the source code
(3) Easyaccess to appropriate loading and debugging capabilities.
The NLS, TODAS,NUTILTY, DDT, anddisc archive subsystems together with theSYSGD source-'code file directory p.rovide the ARCsoftware.engineet-s w.ith these capabilities.
To the ARC softwareengineers, the aspects of NLS thatare perhaps of mostimportance are the ability to find a particularplace in the code or documentationquickly and thento change it easily.Our code and documentation files arenormal NLS textfiles, and the languages that we use havebeen specially developed to be compatible with the NLS system.
Theselanguages are all string-based, and translation is independentof the hierarchical statement structure. Thispermits the programmer to use structural conventionsto make his source-code text easier to understandand manipulate.
Theyalso allow NLS linksto be used for identifiers, thuspermitting one to use the "jump" commands to follow subroutinecalls in the source code. In addition, level clipping,line truncation, and so forthmay be used to controlthe depth of detail of thecode and associated documentationthat one sees. These are very important factorsin quickly finding a specificlocation (or seriesof locations) in a file.
Content-analysisfiltering is often used to locate references to variablesor subroutines or tolocate a particularpiece of code (for example, code containing a syntaxerror reported by the compiler). The content analyzeris also used to locate changes that have been madeto a fileby a specificprogrammer or during a specifiedperiod of timeby scanning the automatically maintained"Statement signatures." These signatures containthe date of most recent modification for each statementand the initials of the user who made the modificationand may also be used without the content analyzerto see who wrote (or lastmodified) each statementof code or documentationand when he did it.
Whenviewing a segmentof a file,the software engineer Section I11 APPLICATIONS AND EXPERIENCE
must be able to easily modify the text of thefile. The extensive editing power of NLS makes this possible. The ability to easily effect changes to various textual and structural entities and to make multiple string substitutions over structural entities while controlling the selection of statements for the substitution via level clipping, content analysis, keyword reordering, and so forth gives one great flexibility and power while editing.
In addition to being able to modify the code and associated documentation quickly, the software engineer may compile (or cross-reference) his code files directly from NLS. Once again, he may use the statement-selection mechanisms of NLS to control what the compiler gets as input. This might be done, for example, to limit the compilation to just one branch of a file (one specified statement and all its substatements), thus making it possible to have in a single file source code written in several 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 changes to the code files. Although DDT works at the assembly-language level, it is a powerful debugger with such features as multiple breakpoints, symbolic addressing, single-instruction execution, conditional breakpoints, and so forth.
To aid the software engineers in maintaining their approximately one-hundred-fifty or so symbolic and binary files, a special subsystem called NUTILITY was developed. This subsystem is able to archive, or retrieve from archive, any of the files, to compile or produce listings for any of the 5ource files, and to load the entire system, requiring human intervention only in case of errors.
Central to our collection of source-code files is an on-line file called SYSGD. It contains the following:
(1) A schematic diagram of the overlay structure of the NLS system. The overlays represent (as far as practicable) functional areas of the system, e.g., parameter specification, structure manipulation, and so forth.
26 I ..
Section 111 APPLICATIONSAND EXPERIENCE
(2) Linksto other files that describe the architecture andlogic of the system.
(3) Anoverlay index listing all overlays, with the followinginformation about each overlay:
(a) A linkto the file containing the source code forthe overlay.
'(b)Information about where it runs in core,how large it is, andwhere it is in thearchive.
(c) A listof all the procedures in the overlay, withone-line functional descriptions and with links tothe code and documentation in the source-code f i le.
(4) A procedureindex with a categoricallisting of proceduresaccording to function. The NLS keyword systemcan be used on this indexto retrieve a listof procedures(with links to the source code and documentation)when a setof categories has been selected.
(5) A sectionwhere one may document bugs found in the system.
(6) A sectionwhere one may record ideas for improving thesystem.
Becauseof present file-space problems, it isnot possible to keepthe SYSGD file,the associated documentation files, andthe source-code files on line at all times (they are generallykept in a discarchive). This situation renders the SYSGD fileless useful than it wouldbe if thefiles werealways readily accessible.
Thecombination of the capabilities discussed above gives the ARC softwareengineer the ability to easily manipulate the NLS systemto fit theneeds of ARC experimentation, thusgreatly increasing his own abilities as a software engineer.These capabilities would be greatly enhanced by theaddition to NLS ofan interactive incremental language. Thiswould eliminate the time now spent on compiling parts of theentire system and loading then in order to test changesmade in the source code of the system, and would Section 111 APPLICATIONSAND EXPERIENCE
allowone to debug at the source-code level.
2. TheAugmented Software Engineer in Action
a . Introductiona.
Thissection is in the form of a scenario,describing how a softwareengineer works to implement a new NLS featureby manipulating files of text (both documentationand actual code). The reader is encouragedto pay special attention to the following:
(1) Theease with which one can move within and amongfiles
(2) Thelanguages that have been developed for particularpurposes and the way in which they fit intothe NLS framework
(3) Theease with which one can locate desired code andmodify it
(4) Thedesign of the NLS system-guidefile and the waysin which it canhelp the software engineer
(5) Theuse of theNUTILITY subsystem to automaticallyarchive, compile, print, and cross-referencefiles as well as to load new versions ofthe system
(6) Theuse of the DDT debuggingprogram to test and debugadditions to thesystem at the machine-language level.
Pleasenote also that one moves within and among files bymeans of "Jump" commands. At certain times when jumping,the user has an opportunity to changethe parameters ("VIEWSPECS") thatcontrol the selection of informationto be displayed on the screen. For example, inthe jump that occurs between Figures 111-3 and III-LI below, a "branch-on!y"parameter is set and the level-clippingand Iine-truncation parameters are set to "ALL" .
Onemay jump to a selectedstatement, to a statement thatis structurally related to the selected statement,to a statementhaving a givenname, or to
28 Section 111 APPLICATIONSAND EXPERIENCE
a statementspecified by a "link"(a textual constructthat symbolically points to a particular statement within thefile or within anotherfile).
In addition,stacks of display-start statement identifiersand VIEWSPECS are maintained for the last sevarallocations viewed within thefile and for the lastseveral files accessed, and jumps may be made relativeto these stacks so asto restore a previous view.
b.Notes on Illustrations
In describingthe display views and the processes they reflect, we assumethat the reader is familiarwith the userfeatures of NLS to theextent that they are explainedin Appendix A.
Appendix A alsocontains a glossary of special NLS terminology.
Inexamining the photographs, notethat the name of an NLS commandappears at the top of thedisplay; thisis the command currently specifiedby the user.
Immediately to theleft of this "command teedback line"is a smal I block of textcalled the "VIEWSPEC area,"where VIEWSPEC parameters are displayed on two I ines.
Whenthe VIEWSPECS are displayed in small characters,they are currently in effect; when theyare enlarged, it meansthat the user has just setthem and they will gointo effect when the displayis next re-created.
Theupper line shows the current level-clipping andIine-truncation parameters (see Appendix A for explanation).The lower line inthe VIEWSPEC area showscode letters indicating the status of variousdisplay features that are controlled by VIEWSPECS.
c. Scenarioand Illustrations
Note: Theillustrations for thisscenario are grouped together,beginning on page 35. Section 111 APPLICATIONSAND EXPERIENCE
We loginto the timesharing system, increase our drum allocation,and enter the NNLS (New NLS) subsystem giving a setof initials and a username (see Figure 111-1). The NLS displaycomes up (see Figure 111-21, andwe load the NLS system-guidefile, SYSGD, withlevel andline truncation set to one and with blanklines displayedbetween statements (see Figure 111-3).
Themajor sections of the SYSGD file (see Figure 111-3) areas follows:
(1) ProgramOverlay Structure
A diagramshowing the overlay structure used in thecurrent implementation of NLS (seeFigure 111-7 below).
(2) GlobalDocumentation
Linksto other files that describe the file structure,design philosophy, system architecture, andcommonly used terminology of the NLS system (seeFigures 111-4 and 111-5).
(3) OverlayIndex
A listof all of the overlays in the system (each overlayrepresents a functionalarea of the system) with pertinentdata about each overlay (.seeFigures 111-8, 111-9, 111-24, 111-25, and 111-26 below).
(4) Categoriesfor Procedures
Categoricallist of procedures,by function, to be usedwith the keyword retrieval system.
(5) Listof Known Bugs
A placewhere bugs may be recorded.
(6) MapofSymbols
A map ofsymbols to be used with theDDT debugging system. Section I11 APPLICATIONSAND EXPERIENCE
(7) Thoughtsfor Improvements
A placewhere ideas about the further development of NLS, TODAS,and NUTILITY may be recorded (see Figure 111-6).
Theinitials of thecreator (or lastmodifier) and the dateand time of creation (or modification)are stored internallyas the "signature" of each statement. Since statementsignatures are available for display upon request,one can easily determine who made or last commentedupon a givenstatement (see Figure 111-6).
The SYSGD fileis basically a directoryfile with a sufficientamount of descriptive material so thatone canuse the various retrieval tools of NLS tolocate any desiredprocedure or documentation.
Toillustrate how the SYSGD file is used', we go through thesteps necessary for a programmer to implement a new command in NLS. Thenew command will becalled "transpose"and will interchangetwo textual entities. Thecommand language for using this new command will be modeledafter that of the "move" command.
Letus begin (Figure 111-7) withthe diagram of the NLS overlaystructure. From the global documentation ofthe system we know that the main-control (mnctrl) overlayconsists of thecode that implements the commandlanguage for NLS commands. We thereforeuse the"Jump to Vectorlabel" command to goto the branch withinthe overlay index branch that contains informationabout the mnctrl overlay.
Thisinformation includes the following (see Figure I 11-81 :
(1) A linkto the source-code file for this over I ay
(2) A listof all of the procedures within the over I ay
(3) Briefdocumentation as to the functions of eachprocedure
(4) Linkstoeach procedure's source code. See Section 111 APPLICATIONSAND EXPERIENCE
Figure III-9; whereasFigure III-8 showson-ly the firstline of each statement, Figure 111-9 shows alllines -- otherwisethe two displays are the same.
If wetake the link to the "WC~procedure (Figure 111-101,we see the top-level code for the NLS commandlanguage, written in oneof the Special-PurposeLanguages (see Section II-B-1) designed for thisus'e. Jumping to the "move" command code(Figure 111-11) and increasing the level-clippingparameter by one, wesee the top-level command-languagecode for the"move" command. Since thisis to serve as a model for ourproposed "transpose"command, we will copythe branch and make thenecessary changes to it.
Thenecessary changes are substituting the string "Transpose"for the string "Move", "qt" for "qm", and "tr" for "m" (seeFigure 111-12).
If we look atthe code for the "move" command (Figure 111-131,we see that it makescalls on routines in theparameter-specification (prmspc) overlay to allow theuser to make selections on the screen, and to routines in thetext-editing (txtedt) overlay to implementthe algorithms for thecommands.
Sincethe syntax for a procedurecall permits an entirelink to be used in place of a procedurename, wecan use the "jump to link" command to see what theseroutines in txtedtactually do.
If wejump "up" from theprocedure pointed to by the link(Figure 111-141, we see that once again this codecan act as a modelsince it onlyimplements the delimitingof the selected entities and goes to anotherroutine, movetx, to actually move the text. We thereforecopy this branch also and make the necessarychanges for the"transpose" command (see bottom of Figure111-14; Figure 111-15 is the same as Figure111-14 except that all lines are shown).
Thenecessary modifications are changing the procedurenames to correspond to our code in the mnctrloverlay and changing the name of the
32
. ." ...... Section I11 APPLICATIONS AND EXPERIENCE
routine that is called to actually do the transposition.
The "jump to name" command takes us to the movetx routine (Figure 111-161, which again serves as a model for our new routine, trantx. After outputting the file we do "Jump File Return" twice to get back to the SYSGD file.
Thus our new command has been implemented into the source code for NLS. We must now compile the main-control an*d text-editing overlays and reload the system. Rather than do the compilation from NLS, we will use the NUTILITY subsystem to both compile 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). InFigures 111-19 and 111-20, the new command is successfully tested.
Let us now continue our examination of the SYSGD file (for a review, see Figure 111-3). As shown above, the SYSGD file can be used to help one examine and modify the source code. There are also ways in which it can help one locate procedures of a given functional type, The use of the keyword system with the "index" branch ana the use of the content analyzer on the "ovlind" branch are two examples of this aid.
The "index" branch contains categorical listings of the procedures in the system by function. Using the keyword retrieval system, one can select and weight categories and have the named entries (links to procedures in this case) presented in order of decreasing relevance, according to the user's weighting and order of selection. One may then take the links and examine the documentation and code for each procedure (see Figures 111-21, 111-22, and I 11-23].
The "ovlind" branch of the SYSGD file contains information about each overlay in the system, including lists of all of the procedures, organized on an overlay basis, with one-line explanations of functions (see Figures 111-24 and 111-251.
Since a brief description of each procedure's function is associated with its name, we can use the
33 Section 111 APPLICATIONS AND EXPERIENCE
content analyzer to help us ,find procedures of a -giventype. For example, we'can insert a content-analysis pattern to search for statements containing the string "display" (see Figure 111-26).
We compile the pattern (see Figure 111-27) and re-create the display with the content-analysis filteringin effect. Now only statements containing the string "display" will be shown (see Figure I 11-28].
The result of this content filtering on this branch of the file is a list of procedures that in some way deal with the display. This is a useful way to retrieve up-to-date lists of procedures of a given functionaltype.
34 .Losou r IREY. DELETESCRArCH FILES. rInE USED o:o:o IN o:a:17 TOTALTIME USED 12:15:1l IN 212:11:46 07/23/70 1107:03 ARC 1.96 11-91 IS UP
.ENTER NLS. PASSWORD - OK 07/23/70 1107:lO -CHANGE DRUM AS6 TO 300. NEW D. A. = 300 our OF loa aNNLS. Inltlals Please: CHI User: IREY A
TA-7079-11
FIGURE 111-1 LOGGING IN TOTIMESHARING SYSTEM AND ENTERING NLS SUBSYSTEM TA-7079-12
FIGURE 111-2 NLS DISPLAYBEFORE A FILE IS LOADED OR CREATED. A "Load File" command has beenspecified but not executed. I map) HAP OF SYMBOLSANDBINARIES I It hought e) THOUGHTSFOR IWPROVEWENTS
TA-7079-13
FIGURE 111-3 MAJORSECTIONS OF THE NLS SYSTEM-DIRECTORYFILE, SYSGD. The command specified in Figure 111-2 has just been executed: a "Jump"command to displaythe "Global Documentation" branch has beenspecified butnot executed.
37 TA-7079-14
FIGURE 111-4 "GLOBALDOCUMENTATION" BRANCH OF SYSGD WITH"BRANCH-ONLY" FEATURE IN EFFECT. The user is about tofollow a linkwhich will cause the file-structuredocumentation to be displayed. 1 ALL ALL JUHP ro IrEH HJLV
:SYSGD. 07/23/70 0946:37 CHI ;
t over1 ay) PROGRAM OVERLAY SrRUcrURE
I doc) GLOBAL DOCUHENrATION
lovllnd] OVERLAY INDEX 1 DEBUG INFORHAlION
[Index)CArEGORIES FOR NLS PROCEDURES
IEugsI Llsr OF BUS
I map1 HAP OF SYMBOLS AWD BXWARIES
[thought 810 rHOU6HlS FOR IHPROVEWCNlS 1
TA-7079-15
FIGURE 111-5 The userhas nowreturned to the same viewshown in Figure 111-3 (severalsteps havebeen omittedfrom thesequence). A "Jump"command to display the "Thoughts for Improvements"branch has beenspecified butnot executed.
39 H3iVALL ALL JUHP YO HAHE FIRSr OVERLAY
It houghIISI rHOU6WTS FOR IHPROVEHENrS (WI 7Om3/K) 11@:23 t ral Is UP 69/11/25 1951:23 rral I returnscan be done through a push down stack.Every tlme theseq-gen makes a frat I branch It puoheothe ps\d on a stack. rheuser may deflne a trallreturn oynt ax. Ifhe has one. and If Is found In a staternent. the etack 10 popedand the poped psld Jsed to et art theseq-gen out agaln. W OlIl/25 1951:24 contentanalyzer W 69/11/25 1951:24 Coroutlnesalso seem to bethe mower to thecontent analyzer caseproblem. A set of dandardcorout [nee could be select [vel y Invokedto modlfy the text onthe way to the rsr and CV tests.
Invokedand dls-Invoked Independent of theparen structure of t he pattern. a ladlreci I one. W 69/11/25 1951:26 Don'thave the sequence gen. set the content flags In thering
TA-7079-16
FIGURE 111-6 The "Thoughts for Improvements"branch serves as a repository for ideas about what could be done to improve thesystem. A "Jump to Name" command hdS been specified to display a statement named "overlay"-"the user has rpwified this name bytyping it in. TA-7079-17
FIGURE 111-7 FIRSTBRANCH OF SYSGD FILE:DIAGRAM OF OVERLAY STRUCTURE USEDBY NLS SYSTEM 1 I mnct r I I mal n coni roI over I ay llnk to flleInls. mnctrl. : jxbblhnzltkdf ERICKSONI st art 1 ng I ocat I on: orgmcf =Z)OOO page 5 cellaused: 27150 procedureoIn f he NNCrRL overlay Iwcl what character , Iwali 1 walt for WnCrRL lcaqml command accept.quad Ion mark Idmanlldlnplay. then go to maln 1 sei dum1 set up duuy drtement 1 cmdrst I command reset lm dlspe cl kludge for kludge lmdlspecl 'met. I lmalnlread a character I
TA-7079-18
FIGURE 111-8 ABRANCH GIVING SUPPORTIVE INFORMATION FOR MAIN-CONTROL (MNCTRL) OVERLAY. Display shows onlythe first line of each statement. A "Jump to Link" command hasbeen partially specified-no selection has beenmade.
42 lrnnctrl)maln control overlay llnk to IIleInle. mnctrl. : lxbblhnzllkdf ERICKSOfdl otartlnglocatton: orgmct=24000 page 5 celloueed: 27450 proceduree In the MNCTRL overlay 1 wc) what character OINLS.WNCTRL. wc : IgebJl t
I wait I malt for llucrRL INLS. WNCTRL. malt : 1gwJI I I csqrnl command accrpt.qued Ion mark INLS.WNCTRL. Caq8 : 1g.J)
Idman[)dleplry. then go to mrln INLS.WNCTRL. dm!n:lgwJI 1
I Getdum) net up dummy et dement INLS.MNCTRL. oetdum : 1g.J) A
~~~ TA-7079-19
FIGURE 111-9 SAMEAS FIGURE 111-8, EXCEPT THATDISPLAY SHOWS ALL LINES OFEACH STATEMENT. The link in the statement named "wc" hasbeen selected; this link specified another statement named "wc" in a file called "MNCTRL" under User"NLS" (the characters "jgebJ" in the link are VIEWSPECcodes).
43 I ALL JUHP ro XrEH GJLV
Iucl bp zapan CASE =.a: 6ROUP:edltSrArE:xa.edlt DSPl*c Append Statement) ='b: 6ROUP:edltSrdrE:bo.edlt DSPlce Break Statement] ='c: 6ROUP:edltDSPlcCopy 1RESRl . CASE ='d: 6ROUP:edltDSPlcDelete tRESR1 . CASE =.e: DSPlcExecute I1 . CASE =.f: 6ROUP:epecDSPIc Freeze1Ststementl . CASE ='g: DSPlc6oto 1 Program). . CASE =. I: 6ROUP:edltDSPlcInrrrf tRESRl . CASE =- I: cdesoy * 0: -cvCrEDr. Impsgn'm I ='k: cdeasy + 0: -cKEYWD. kmsln). =. I: cdesoy a: 6010 cxocn. qlq,.
+ 0z.m: 6ROUP:edltDSPIcMove TRESRI . CASE =.o: cdesoy * 0: 6010 cIOCrL.qoq~m ='p: 6ROUP:specDSPlcPolnter tFlx1 . CASE =.r: 6ROUP:edltDSPlcReplace TRESRI . CASE ='e: DSPlcSubotltute 1 Statement1 . CASE =.vi DSPIcVleuSet11 +cPRMSPC. 1topec,m ='X: 60ro cvcrEDr. oetcontrol). =SP: REPEAT I..) A
TA-7079-20
FIGURE 111-10 RESULT OF "JUMPING" ON THE LINK SELECTED IN FIGURE 111-9 (from Index in SYSGD File to SourceCode for "wc"Procedure in Main-Control Overlay). A "Jump" command has been specified to display a particularbranch of this code.
44 4 1 BRANCH COPY CJLV 1 1
TA-7079-21
FIGURE 111-11 CODE DESCRIBINGCOMMAND LANGUAGE FOR "MOVE" COMMANDS, IN A SPECIAL-PURPOSE LANGUAGE.A "Copy Branch" command has been specified to create a duplicatecopy ofthis command-languagecode. TA-7079-22
FIGURE 111-12 By executing the "copy branch" command, thensubstituting "Transpose" for "Move," "qt" for "qm,"and "tr"for "m,"we produce the command- language code for the "transpose" command. A "Jump to Predecessor" command hasbeen specified to redisplay the unaltered command-language code for "Move."
46 TA-7079-23
FIGURE 111-13 COMMAND-LANGUAGE CODE FOR "MOVE"COMMANDS, WITH ALL LEVELS SHOWING. We now"Jump" on a link to a routine named "qmc" in the "TXTEDT" overlay filewhich implements the "Move Character" command (thelink in this case is a subroutine call in the "Move" command- language code-photo shows displayjust before "Jump" command is executed).
47 I :> END. I 1~2.1~5ro I IEND. I 1ez.1~5 ro I
83.
. 8P 5 ro I) ro
FIGURE 111-14 We have executed the "Jump toLink" command from the previous view, and then executed a "Jump toUp" command (omittedfrom sequence of photos) to display the source statement of "qmc." We see that the code which implements the "move" commands canbe used as a model for the "transpose" command. Again, "Copy Branch" is used to make a duplicate copy ofthis code, and the copy is altered to produce code for the "Transpose" command (bottom ofphoto).
48 HOVE rx
qmnl*cudr +cddllm)
qmll +cldr
TA-7079-25
FIGURE 111-15 SAME DISPLAY AS FIGURE 111-14 BUT WITH ALL LINES SHOWING. We now follow a "GOTO" instruction by usingthe "Jump to Name" command (photo shows displayjust before "Jump" command is executed)
45 ALL ALL JUWP FILE RETURN : WNC rR L r HILI 1
sr 81 + SFIEII PZ. *ixr*. ~5 PL. p4 sEIa1): ST 82 SFIE21P7. PI SEI821 END: re! !It 60TO crecred) END. It rani x1 PROCEDURE I bugl. bug?): REF bugl. bug?: +tPRWSPC.~rns~~~IsP1.sP?l DELPrRlPIP2l DELPTRIPS Ptl :C I F SFlbugll IF = SFlbugZ) THEN I IF bug1 t bug2 rHEN ST bugl + SFlbugl) PI.P5 P6. Pi P7. PI P2. PI SEtbugl1 ELSE ST bug! + SFlbugll P7.PIP?. PIPI. P5 P6. Pi SElbug~) 1 ELSE BE6IN ST bug1 + SFlbugl) PI.P5 P6. P4 SEIbugI): A
TA-7079-26
FIGURE 111-16 The "movetx" code hasbeen copied and altered to produce the "trantx" code for the new command. We nowreturn to the previous fileby using the "Jump FileReturn" command (photo shows display just before "Jump" command is executed). sed tty o 1.96 13-9
ER HLS. WORD- OK 3/70 1128
TA-7079-27 advleed tty open = :I ARC 1.96 13-31 IS LIP
.ENTER NLS. PASSWORD- ON 07/23/10 1121:53 oExEcurIvxry -I.
.RESET.
MeadBlnarleo. *Load 111s . EFI le. ctl IIle AII Itlee. *6 0
TA-7079-28
FIGURE 111-18 Once the changedcode hasbeen compiled, NUTlLlTY canbe used to automatically load a new version of the system. TA-7079-29
FIGURE 111-19 Under DDT we run the new experimental NLS and build a dummy statement to test the new"transpose" command. In thisphoto the command hasbeen specified and two words selected.
53 TA-7079-30
FIGURE 111-20 Here the"transpose" command hasbeen executed.
54 111 111111 KEYWORD SELECT FILE10 #JlV t
[Index) CATEGORIES FOR PROCEDURESNLS
![lehandllng
0) RAND0W FILE IIO Iodrlb) Irdhdr)
pyl FILE cop![ 11
IfIlre!lFILE BLOCK REFERENCINS R flodrov)Ilodrrbl [lodrdb)
TA-7079-31
FIGURE 111-21 Anotherbranch of the SYSGD file allows One to select procedures according tofunction with the"Keyword" commands. In this photo the userhas selected the word"fileio" as a keyword; we see that the Statementnamed "fileio" contains two other names, "lodrfb" and "rdhdr," in a special format.
55
" .
TA-7079-32
FIGURE 111-22 DISPLAYPRODUCED BY KEYWORD SYSTEM. When the selected proceduresare presented, one can "Jump," via the associated links, andexamine thedocumentation andcode forthe procedure. TA-7079-33
FIGURE 111-23 DOCUMENTATION OF LODRFB PROCEDURE.The ”Jump to Link“ command specified in Figure 111-22 hasbeen executed,and the user has set up a “Jump FileReturn” to displaythe SYSGD file again.
57 TA-7079-34
FIGURE 111-24 Theoverlay index branch of the SYSGD file contains informationabout each overlay in the system. A "Jump" hasbeen specified to displaythe branch onthe utility package.The VIEWSPEC code "R+2" appearing at theupper left corner of the screenshows thatin executingthe "Jump," two additional structural levels oftext are to be displayed. JUMP ro LINK
lutlltyl utlllty package , @Inkto flleINLS.uilliy.l:~geb~~I lkdf PARSLEY1 st art Ing I ocat I on: orgut y=r 4000 page 1 cellsused: 17715 locallon for temporarler: uti preflx for generatedIabelr: uil proceduree In the UrILrT overlay lutgd) UrILry generaldeclaratlonr tpueh) purh b-regonto grnrrrl rtack 1pop1pop general riack onto b-reg Irellltl releare Ilteral reglrier I 1 get Ilteral regtder I I get rrglder addrerr I appendcharacter a-rirlnglo I append a-rirlng to andher I loadcharacter from a-rtrlng copyone a-rtrlng Into another 1 move a-rirlng io buffer Imvbfbfl move buffer lup In corel Imvdoml move bufferIdom 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 substaternent in thisbranch contains a linkwhich the user is about tofollow. 1 lOvlInd, OVERLAY INOEX I OEBU6 INFORHArION [hdtsplay'l: 1 auxcodlforks andfork dart In9 I Ilnk to fI le 1nlo.AUXCOD. : 1gwJl Ikdf ERICKSONI start1ng locatlon: I orgaux=24000page 5 I cel Is used: I 26234 locattonfor temporarlee: I altt preflxfor generated labels: 1 ax1 procedures In the AUXCOO overlay Iqkflfreeze statement 11115. AUXCOO. qkf : jgwJI
lqkalreleree frozen dateaent INLS. AUXCOO. PKA : lgwJ1
TA-7079-36
60 IOvlInd) OVERLAY IHDEX L DEBU6 IHFORHArIOH O['dlsplay'I: 1 lauxcod)dartlngforkforksand * IInk to flle Inls.AUXCOD.:19wJl lkdf ERICKSONI st art Ing locat Ion: I orgaux=24000page 5 cel Is used: I 26234 locatlon for temporarlee: 1 axt preflx for generatedlabelo: 1 ax1 procedure0 In the AUXCOD overlay 1 qkf freeze ot at eaent INLS. AUXCOD. qkf : lgwJI I I qkal re1 eaee frozen d at ement INLS. AUXCOD. alcA : 19.~1 I Iqpls~lpolnter ohow 1 IHLS. AUXCOD. qplol : 1g.J)
lqpm~lpolnter delete A L
TA-7079-37
FIGURE 111-27 Thepattern iscompiled with command"Content Analyzer." The display is not yetaffected-the content-analysis code compiled from the pattern will be run whenthe user changes a VIEWSPEC.
61 I
~~ ~ TA-7079-38
FIGURE 111-28 RESULT OF CONTENT ANALYSIS: a list of procedures thatin some way deal with the display (since they contain the word "display")
62 Section 111 APPLICATIONSAND EXPERIENCE
C. TheAugmented Manager
1. Introduction
a.General Considerations
Mostpeople need to play the role of "manager" at varioustimes, whether that role is their primary functionor simply a necessaryelement for the accomplishment of theirother work.
We will usethe terms "manager" and "management" in thisexpanded sense, applying them to an individual's managementof his own time, resources, and skills as wellas to individual and collective management of thework of other individuals and groups.
Ourexperience with augmented management can be describedbest in terms of the augmentation tools we havedeveloped and the methods we have evolved for exploitingthese tools in thetask of management.
Once a toolgoes into use, methodology becomes as complexand critical a concernas the design and developmentof the tool itself, and our research in thearea of augmenting management has been con.cerned principallywith the development of special methodologiesfor using our basic augmentation tools withonly secondary emphasis on the development of newspecial-purpose tools.
We haveidentified the following as some of themajor needsrelevant to fulfilling the role of manager in our augmentedcommun7ty.
(1) Fastand flexible means for accessing and studyingmanagement working files and other group workingfiles
(2) Techniques for locatingspecific pieces of informationin a complexfile or collectionof files
(3) Efficientmethods for entering, updating, and storingmanagement information
(4) Techniquesfor interacting with other group Section 111 APPLICATIONS AND EXPERIENCE
members to verify and comment on information within the group's working records
(5) Facilitiesfor rapid and flexible composition, modification, and publication of management documentation
(6) Specialtools for the processing of management information(e.g., the NLS calculator facility). Some of the specific tools and methods developed in response to the needs outlined above are described briefly below.
Our collection of on-line files now contains considerable management information of various kinds, and we have pursued our investigation of management-information operations by using NLS and TODAS to provide and develop aids for management of the ARC on-line community.
There are many areas of potential application for on-line aids, and we have chosen those which appear to be most useful operationally for the purposes o'f experimentation and development.
b.Cost-Accounting Files
While still under continuous development, special cost-accounting files (described in detail in Section III-C-2 below) are now in routine use. These files are extremely useful in terms of getting work done, and our experience with developing and using them has constituted some of our most fruitful research on the intensive exploitation of the overall on-line system.
The files have an intricate structure, designed for maximum mobility in accessing information and for maximum efficiency in interfacing with the NLS calculatorfacility. Intelligent use of these files includes the entry of new information and the occasional restructuring of the information to take advantage of new possibilities in the system and to meet newly discoveredneeds. While fundamentally simple, this kind of usage requires the coordinated operation of the most advanced features of NLS; thus the cost-accounting files
64 Section 111 APPLICATIONS AND EXPERJENCE
are a leading edge of our research on highly interactive information structures.
c. Work-PlanningFiles
We have begun experiments in using NLS files for the planning and monitoring of tasks within our project activities. Our firstexperiment involved the management of the TODAS development activity, for which we created a file called UPLAN to use in formulating specifications for TODAS and in planning for the implementation of the specified features.
This file contains a branch for each identified task with the following information organized for easy study and retrieval:
(1) Description of the task, with links to other working files used in its development
(2) Comments on the relationship of the task to other ARC tasks (3) Estimates of implementation costs (mainly manpower) and schedule of work and implementation stages
(4) Comments on the current status of planning and implementation.
We also created a separate file called UMEET containing agendas and notes for the TODAS development activity meetings.
We made use of a research assistant working on-line to take notes during these meetings. The research assistant worked from an agenda composed before the meeting so as to have a convenient framework for note-taking, and was also available for finding on-line information as needed during the meetings. Successive meeting agendas and minutes were kept in a single file so as to make it easy for us to search for records of all discussion related to any given topic.
On a less formal basis, we have used various other files for work planning throughout the project's history. Section 111 APPLICATIONS AND EXPERIENCE
This has ranged from the construction of lists of tasks in such a way as to reflect their interdependencies. to the maintenance by individuals of files listing their personal tasks on hand along with plans for completing these tasks.
d.Personnel Files
Some of our personnel information is now kept in on-line files. Features in the timesharing system permit us to restrict access to some of these files, while letting others remain "public." Even though our personnel roster is relatively small, we find it advantageous to have the ability to specify automatic searches on the personnel files, especially for such tasks as cost estimation.
e.Documentation
All of our documentation, from large final reports to the brief circulars distributed at conferences, is comp-osed,stored, and updated in on-line files. Our flexible composition and editing capabilities and fast publication technology (from on-line file to formatted hardcopy in a few seconds per page) give management controls over the documentation process that are not possible without augmentation.
f. On-LineDialogue
We use the term "dialogue" to indicate the process of formal communication via interactions with a common information base. This kind of dialogue plays an important role in the formulation and monitoring of plans for proj-ect activities, and while we are still using informal experimental methods to achieve this, we are in the process of formulating the initial plans for a long-term investigation of advanced techniques for augmenting dialogue processes.
Subsequent sections offer detailed descriptions of several management applications that have been developed using NLS and TODAS, illustrated with photographs taken from NLS display screens to show sequences of information-manipulationoperations. A familiaritywith the basics of NLS (to the extent that they are explajned in Appendix A) is assumed.
66
I1 Section I11 APPLICATIONSAND EXPERIENCE
In followingthe descrip.tions, it shouldbe kept in mind thatthe speed with which NLS serves its users is an importantpart of its utility.The photographs indicate transitionsthat take only one or two seconds under good conditions. This speedlends great power and flexibilityto the relatively simple service functions performedby NLS.
2. ProjectCost Records
In ourroutine operations, weneed frequent and rapid accessto summary data on project costs, with little referenceto lower-level details except when the costs are first checkedfor reasonableness and accuracy. Therefore wedecided to start by putting summary data on-line at ARC. Asneeded in the future, we can add more levels of detail.
We firstconstructed a cost-historyfile for 1968-1969 costson SRI projects ESU 7101(RADC Contract F30602-68-C-0286)and ESU 7079 (NASAContract NAS 1-7897). Thisfile is called HISCO.
Theelements of HISCO included the following for each of thetwo projects, on the basis of 4-week accounting periods(as used by SRI's accounting system):
(1)Salary
(2) Burden
(3) Overhead
(4) Totalcost
(5) Fee
(6)Total charges.
SeeFigures 111-29,111-30, and 111-31 (illustrations forthis section are grouped together, beginning on page 75). Eachof these three figures shows a displayof one branch of the file, containing the informationfor a specificproject and year.
We alsoneeded a sectionshowing combined salary .' costsand combined total charges for all of our projects(see Figures 111-32 and 111-33). We put Section 111 APPLICATIONSAND EXPERIENCE
thesecosts in separate branches of the file. The lastbranch shows total costs for both projects combined. We retroactivelystudied existing records forall 1968 dataand kept %up th-e 1969 costsevery weeks,entering the new data by hand.
Theusual w.ay ofaccessing HISCO was via pre-established linksfrom other working files whenever the user had a questionabout recent costs. The VIENSPECS inthe link usuallycaused HISCO to bebrought in with only high-levelstatements on display, showing only the headingsfor project name, combined salary, total charges,and total ARC costs(see Figure 111-34).
Theuser could then select the project he was interested in (bythe command Jump to Item), open up anadditional level for viewing,and see column headingsand numerical data (Figures 111-29, 111-30, and 111-31).
Thenhe couldjump downthrough the accounting periods tothe one hewas looking for.
If hewas making a calculation(perhaps already startedin the file hewas working in before he loaded HISCO), hecould then call the calculator andadd, s~btract, multiply or divideby any of thenumbers in HISCO. Hisprevious calculations in theprevious file would remain intact.
If finishedwith HISCO, hecould then return to theprevious file (by the command Jump File Return)and continue with thecalculation, having foundin HISCO theinput number or numbershe was lookingfor.
As anarena for experimentation, HISCO provedvaluable. Operationally, it wasuseful from time to time but revealed a needfor more frequent updating of the summary data. Our experiencewith HISCO led to thedevelopment of a redesignedcost-history file called COSTS whichis updated weekly,with Lt-week and cumulative summaries.
Thecost elements in this file are:
(1) Salarycosts Section I11 APPLICATIONSAND EXPERIENCE
(2) Totalpersonnel costs
(3) Non-laborcosts
(4) Totalcosts
(5) Totalcharges with fee
(6)Balance remaining.
SeeFigures 111-35, 111-36, and 111-37. Figures 111-35 and 111-36 showthe same branch of the file withdifferent VIEWSPECS; Figure 111-36 displaysone morelevel than Figure 111-35, andthis level shows theweekly data. Figure 111-37 showsthe weekly data foranother project.
We alsoincluded funding information showing current totals,unfunded totals, and total contract amounts inthe "cost," "fee," and "total" categories.
We useseparate branches for eachproject and for total ARC projectcosts (Figure 111-38). Theskeleton format forthe file was set up in advance for the entlre year of 1970.
Beforeentering any actual data, we copiedthe first top-levelbranch (containing some 70 statements) withinthe file at the same level four or fivetimes so as to createblank format branches. Then we simplyinserted the project name headings for each projectinto a correspondingblank branch. We keep oneblank format branch in the file in case any new projectsshould arrive.
LikeHISCO, COSTS is usually reached through a linkfrom someother working file, perhapswhile a studyof near-futurecosts is in progress, or from a proposal costestimate under development. Again the file is usuallyentered with only the top-level statements or projectheadings showing (see Figure 111-39).
If a particularproject is of interest, the correspondingbranch is selected and another level openedfor view. Thesecond level shows period-by-periodsubtotals in each cost category. If weeklydata are desired, another level is opened by Section 111 APPLICATIONS AND EXPERIENCE
changingthe VIEWSPECS and a particularweek is selectedby the command Jump to Item.
Thestatement for each week has the week-ending date asits name. The reason for using this form of name constructionis not only so thatthe statement for a particularweek can be accessed by the Jump to Name commandusing the ending date, but also so thatthe datemay optionally be suppressed from the display. (NLS hasthe capability of suppressing all statement namesfrom the display.)
Thenormal way of viewing these particular files is with namessuppressed; thus the dates do not clutter thedisplay. However, a userwho needs to know the endingdate for a particularweek can see it by executing a singlecommand.
Toaccess the information for another project within COSTS, oneexecutes Jump to Return twice to see the top-levelstatements again (Figure 111-39).
Onecan move very quickly and accurately through a file thatis set up in this fashion, even without any familiarity with theinformation it contains.
Theprimary function of COSTS isto show a consistent week-by-weekprogression, by category, of costs for each project.The file can also be used for study purposes, throughthe use of content-analyzerpatterns, some of whichare stored in the origin statement (see Figure 111-40, whichis the same as Figure 111-39 but with different VIEWSPECS). Anyother patterns can be created asneeded.
Thisallows a user to extractspecia! categories of informationfrom the file very quickly. For example, a usermay easily create a displayshowing all projectcosts for the eighth week of 1970, foreach ARC project. It isalso possible to output such a “filtered”display via a lineprinter, thus obtaining hardcopy of a special-purposeextract from thetotal f i le.
Thecontent analyzer is helpfulwhen using the calculatoron all the data for one week, project by project, to findtotal ARC chargesby category. Section 111 APPLICATIONS AND EXPERIENCE
When only one week's data are displayed (Figure 111-411, one can add items down each column and insert the answer in the "ARC total" space. One can then clear the accumulator, and add down the next column. This is done very rapidly through bug selection of input numbers and keyset entry of commands -- Add, Add, Add, Add, Insert, Clear, Add, Add, Add, Add, Insert, CI.ear, and so forth. The COSTS file is now operationally useful to us, and we expect it to, be useful for future experimentation with automatic processing techniques.
3. Estimatesfor Proposals
a.Personnel Costs
An estimator working on a proposal can select from an on-line file, by labor category, representative people who may be involved with the proposed work; as he selects them, he can transfer their names and relevant information about them to a file where he is building up his estimate.
The estimator loads a special file, maintained by himself, which is a directory to all of his other files and perhaps to a few files belonging to other people. Figures 111-92 and 112-43 are two displays of a user's filedirectory. In Figure 111-42, onlyfirst-level statements are shown; these are used for establishing categories.In Figure III-Ll3, anotherlevel is shown, containing the actual directory listings in each category.
This "file directory" contains links to each of the filesthat it lists. In the present case the files probably would be cost histories, personnel listings, previous special studies of costs, and other administrative information.
He loads a previous cost estimate, makes a working copy of it, changes the heading to reflect the name of the new proposal estimate, and eliminates the amounts from the old estimate.
Thisproduces a blankcost-estimate format. If any items from the old estimate are inappropriate, they Section I11 APPLICATIONSAND EXPERIENCE
areeasily deleted; new items are easily added as separatestatements. When the format is ready, it is outputas a newfile.
Hecan then load a filethat lists names of people in thegroup and some projection of expected additions. Figures 111-44, 111-45, and III-L16 showportions of such a file.
Usingthis personnel-listing file, he obtains informationabout labor categories. A branch containingcontent-analyzer patterns is kept in the file.These can be easily reached by jumping to a linkthat causes all the patterns to be displayed (Figure 111-47).
Eachpattern will selectsome particular category of statements from thefile. For example,the estimator will need to knowwhich people have the statusof Senior Professional.
He selectsthe appropriate pattern with the commandExecute Content Analyzer, and then jumps on a linkthat turns on the content analyzer,starting the search at the beginning of thebranch containing personnel listings and restrictingthe search to that branch.
Thisproduces a displayshowing only the listingof senior professionals in thegroup. Thisset of statementscan then be transferred tothe new proposal cost-estimate file.
Otherpatterns can be used to extract sets of statementsaccording to other criteria -- for example,all the hardware or softwarepeople in thegroup (Figures III-L18 and 111-491.
Thusthe estimator can select, by labor category, representativepeople who may be involved with the proposal;as he selects them, he can transfer their namesand the information that goes with them to the filewhere he is building up his estimate.
Thepayroll burden and overhead rates are checked for currencyand inserted into the estimate, using the calctilatorto apply them to the direct labor. At this Section 111 APPLICATIONS AND EXPERIENCE
point the labor portion of the estimate is completed.
b.Non-Labor Costs
A typical estimate will involve some travel costs, some consultantcosts, and some report cos-ts. Data supporting the c-ost of consultants may be checked by reviewing current consultants' costs by project and by consultant. These are kept in a separate file and reached through a link for review. The data .may be copied into the estimate if desired.
Report-production costs are estimated using current Institute schedules, which are based primarily on the number of pages expected in the end product. These computations can be made using the calculator and the existing cost factors from the last proposal (checked for current applicability).
In addition, the proposal may contain plans to add equipment.In this case, the estimator will usean equipment study written in another file by the people involved in hardware design.
The equipment costs contained in the special study are summarized in total and reached by a link.The special study can be viewed and updated as appropriate and can be copied to go with the proposal as an appendix or used later for backup.
In this fashion, various information is gathered from various files and transferred into the developing cost estimate.Figures 111-50, 111-51, and 111-52 show portions of a completed on-line cost estimate actually used for a recent ARC proposal.
4. Purchase-OrderProcessing
In making estimates of costs for new equipment being constructed at ARC, reference to previous cost information is veryuseful. We constructed a purchase-order/requisition processing file that contains a separate statement for each item purchased for the past few years. Figure 111-53 shows a portion of this file.
All outstanding orders are contained at a second level within a single branch (see Figure 111-541; therefore the
73 Section I11 APPLICATIONS AND EXPERIENCE
distinctionbetween outstanding and completed orders is easyto see by reference to level. To reduce clerical error,we consider an order completed when the comp pattern isinserted and the statement is moved to its alphabetical positionon the top level.
Thisfile can be searched using the content analyzer in someinteresting ways. If wewonder what we purchased on PR A08927, thequestion can be answered simply by executing a content-analyzerpattern specifying the number. We can quicklysee all outstanding orders charged to a particular project.Figure 111-55 shows a content-analyzerpattern thathas been temporarily written into the file, for findingany entries pertaining to orders for relays under Project 7101. Figure 111-56 shows a viewgenerated by usingthis pattern.
Thisfile is kept up-to-date by the secretary of the hardwaregroup, who is most involved with requisitioning. Shedoes this updating entirely with TODAS.
74 r
0 vhd Nonlabr rottost Fee rotthge
2 3 676 121 771 21062 24639 719 25378 4 1010 205 1234 l1Obl 20580 617 21198 5 1016 193 1160 21176 2b245 717 27032 6 1167 221 1334 29b55 32177 971 31341 7 474 2499 2154 24414 30261 907 3110 8 2522 47f 2881 25003 30885 f26 31811 9 3092 587 3532 296b1 16874 I 106 37980 10 4787 909 5466 25971 37142 1114 31257 11 2736 520 3126 40161 46550 1196 47946 12 2309 438 2616 1712 141b7 425 14592 13 4466 141 5102 67147 77563 2126 79890
TA-7079-39
FIGURE 111-29 A BRANCH OF FILE HISCO
75 f
Ovhd Fee
8462 1107 966 30 1 20037 280 10981 2086 1254 781 2b399 686 11891 2260 I359 3083 30831 9 TO 10350 1966 I 112 4069 28208 802 12394 2355 1416 1271 30186 928 12888 12523 38835 2481 10325 2650 23730 1516 10820 1264 23155 1492 12146 1025 30041 1920 11521 6003 29525 1886 11176 8338 32380 2069
TA-7079-40
FIGURE 111-30 A BRANCH OF FILE HISCO Period Salary 1 4083 2 7296 1386 8335 3521 20538 1312 21851 3 9538 5111 I7958 10113 42180 2133 45514 4 9157 2193 11330 3111 26371 1685 28062 5 IOlll 2379 12238 6812 31100 2015 33615 b 8541 2050 10591 1533 28115 1835 30549 1 6463 1562 8129 2215 18369 1180 19549 8 73b4 I767 9131 4632 22984 1462 24356 9 3211 772 3989 4133 12113 812 13525 IO 2749 660 3408 1429 8244 521 8770 I1 2348 5b3 2912 613 6431 411 6849 12 3601 I64 1466 I442 11815 6b2 11035 13 3115 162 3931 1949 9823 628 10451 pro lcum 193413 42884 233242 86130556269 35541 59l810
TA-7079-41
FIGURE 111-31 A BRANCH OFFILE HlSCO
77 CoablnedProlect Salary 19bI t Pertodo 7101 6 7079 = rota1 1 2 3 b 7b 14b 9131 4 1010 1091 12Obl 5 101b 1119 12913 b 11b7 1035 11517 7 2499 1239 1403 I 2522 1121 13183 I 9 3092 9831 12130 10 1472 4717 14zu 11 2736 11157 13193 I2 2309 I2 10015 12394 I 13 44bb 1477410301 .RES;
TA-7079-42
FIGURE 111-32 A BRANCH OF FILE HlSCO 7101 + 7019 = rota1 51212 11159 61091 21650 21151 43501 71249 45314 111761 52901 21062 10965 65059 31615 91674 23166 18549 55915 109129 19549 121671 114289 24156 111565 58255 11525 61711 18442 1770 19212 111611 6149 120412 74257 11015 15292 74071 10451 14529 .RES:
TA-7079-43
FIGURE 111-33 A BRANCH OF FILE HISCO
79 I 1 JUMP ro LINK @ItV t
:HIScO. 02/27/70 1441:55 JCN :.DSH=I:.~~J=O:.LSP=O:.SCR=I:.HEO;LIRC ARC PROJECr COSI HISTORV 1966.1969 Seea1 so I funds. costhl story: zwgnl By Pro lect: 7101 IRLOGl cosrs 1968 7101 IRAOCl COSrS 1969 1019 INASAI COSrS 1966 t 7079 INASAI COSrS 1969 ByItem: CornblnedProject Salary 1961 ComblnedProlect Salary. 1969 Comblnedrotal Project Charges I961 comblnedrotal Project Charges 1919
TA-7079-44
FIGURE 111-34 INITIAL VIEW OF FILE HISCO UPON ENTRYVIA LINK
80 PROJECr 7101 IRADC-old) cost F ea rotal Fundlng: Currenttotal: ,I 1459564 I 55651 I 1515222 Unfundedtotal:] 01 01 0 rotal contract:^ 1459564 I 55651 I 1515222 uk-per Salary Percoet NonLabrTotCoet rotchgoBalance Total I 14121 35216 4bIf4 82110 15230111351 rotal z 11306 21225 23917 5214253724 127634 rotal 3 rota1 4 rot al 5 rotal 6 rot 81 7 rotal I rotal 9 rota110 I rota111 rotal~z rota113 A
TA-7079-45
FIGURE 111-35 ABRANCH OF FILE COSTS SHOWING ENTRIES FOR 4-WEEK ACCOUNTING PERIODS I 1 JUMP ro xrEm 8JLV 1
PROJECr 7101 IRAOC-old1 rota1 Fundlng: , Cod Fee Currenttotri: s 1459564 S 55651 S 1515222 Unlundedtot a I : s os os 0 Totalcontract:s 1459564 s 55651 s 1515222 1 Uk-PerSalary Percod MonLabr rotcodrotchgr Oalanco 1-1 Icomblned mlth ueck 2 on PSI') 2-1 (660 1b617 10902 27519 21565 231021 1 -1 36461-1 9067 5556 14621 15171 222145 4 -1 31154-1 9512 30416 39961 41417 111151 rota! 1 14121 15216 46194 12110 15210 111151 5-2 2713 6771 509 7212 7559 171799 6-2 2174 7114 1495 15679 16275 157524 7-2 3465 1647 9571 11225 11917 131607 1-2 2254 5621 5135 10956 10971 127634 rotor 2 11306 21225 23917 52142 53724 127b14 9 -3 10-3 11-3 12-1
TA-7079-46
FIGURE 111-36 SAMEAS FIGURE 111-35 BUTEXPANDED TO SHOWWEEKLY ENTRIES
82 PROJECr 7079 lWASAl Fundlng: F Cod ee rota1 t Current total: a 617917 a 19500 I 657417 I Unfunded total:^ OI 01 0 rota1contract:a 617917 a 19500 I 657417 . Uk-I 1- 1 2- 1 1411 3711 1495 5211 5547 60011 3- 1 410 1025 21 1053 1120 51199 4- 1 1147 4611 1121 6441 6151 52045 rotal12707 11146 9161 3745 IISZO 52045 5-2 2314 5717 2 5719 6159 4506 6-2 2300 5741 27 5775 6145 39741 1 7-2 1141 1372 12 1404 3621 16120 1-2 1701 4251 19 1 4642 4940 11110 rotal z 7661 19151 19610452 15925 31110 9-3 10-3 11-3 12-1 A
TA-7079-47
FIGURE 111-37 SAMEAS FIGURE 111-36 BUT FOR A DIFFERENTBRANCH OF FILE COSTS SHOWING DATA FOR A DIFFERENT PROJECT JUMP ro ITEW 1 t
ARC rorAL PROJECTS Fundlng: f cod rota1 F ce C u rre nt total: Current 8 210659 U nfu n de d total: Unfunded 8 0 Total contract:S 4412116 8 202717 S 4615121 . Yk-PerSalary Percod Nonlabr rdCort rotchgo Balance 1-1 fcomblned with Week 2 on PSR'I I 2 -1 I141 2-1 20135 12197 12712 14112 291041 3- 1 4056 3-1 10092 5514 15676 16291 211744 4-1 7662 14150 12259 2134014114046409 rota1 1 17166 44577 50240 94117 91750 211401 5-2 5027 12560 511 11512 11121961511 6-2 5174 12912 1522 21454 224 20 197265 7-2 (113 12019 9610 21629 225I1 174727 1-2 5207 1-2 13081 5765 11761 192 412567549 I rota1 2 ZOZZI 50514 24401 256754975431 779 17 9 -3 10-3 1 11-3 12-3 A
TA-7079-48
FIGURE 111-38 ABRANCH OF FILE COSTS SHOWING COMBINED DATA FOR ALL ARC PROJECTS
84 TA-7079-49
FIGURE 111-39 INITIAL VIEWOF FILE COSTS UPON ENTRYVIA LINK
L ALL ALL JUHP ro LINK MJLV t 1 :cosrs. 02/27/70 1534:27 JCN : t [' 3-1 ']OR['PROJECI']OR[ 'b Ukh]: [ 'Current ']OR[ 'PROJECT']OR[ 'Fundlng : '1: [ 'Current ']OR[ L~nfundedLlOR[ 'rota1 cont']OR[ 'PROJEC~"]OR[ 'Fundlng : '3: [ 'Unfunded'lOR[ 'PROJEC~']OR[ 'Fundlng :'I; ['Total contract:']OR['PROJECT~~oRILFu~dlng:'I: ['Cufn']OR['bUk']OR['PROJECT']: nocharges .OSN~I:.RIJ~O:.LSP~O:.OLS~O:.SCR~l:.HED~'A~CPROJECT COST HISTORY 1970
:.NSY=O:.OPR=O: ["l:lheadlngl:zxbbrDln~l .RES: ARC 1970 PROJECr COSTS:
I * Yk-PerSalaryPerCosfNontabr rotcost rotchgs Balance
PROJECT 7101 IRAOC-old) Fundlng: cost Fee rot a1 Currenttotal: I 1459564 I 55158 1 1515222 Unfunded tot a1 :I 01 01 0 rota1 contract:l 1459564 I 55158 I 1515222 A
TA-7079-50
FIGURE 111-40 SAME AS FIGURE 111-39 BUTWITH DIFFERENT VIEWSPECS TO SHOW CONTENT-ANALYZERPATTERNS STORED IN FIRST STATEMENT OF FILE
86 1 ALL ALL JUMP ro Iru U1LV t
ARC 1970 PROJECTCOSTS:
Z Yk-PerSalary Pertost Nontabr ro+cod rotchge Balance
PROJECT 7101 IRADC-old1 3-1 1646 9067 5556 14621 22284515171 PROJECT 7079 INASA) 3-1 410 1025 28 1051 1120 58199 PROJECT8457 IRADC-new) 3-1 PROJECT XXXX IONRl 3-1
TA-7079-51
FIGURE 111-41 VIEWOF FILE COSTS WITHCONTENT ANALYZER IN OPERATION, SHOWINGDATA FOR A SINGLE WEEK ONLY. This is done by using the first pattern appearing in squarebrackets in Figure 111-40. TA-7079-52
FIGURE 111-42 VIEW OF A USER’S FILE DIRECTORY, SHOWING FIRST-LEVEL STATEMENTS ONLY
88 JCW dallyworklng worES . 1p I an. : zxon) t Flnanclal and SrArISrICAL drtr . funds. : zxonl Spcclaloperot~onrl cod Sruom. I study. : zxon) Current 1970 prolect COST SUHHARIES . I coet e. : zxnO 1 SrArEHEYr of YORK ARC ProJrctr I et at e. : zxCnl CodESrIHArE: ESU 69-188 RAOC 11/14/69 . I newer. :zxbbnl Schedulr~: ESU 69-188 RAOC 11/14/69 . I schdr. : zxbbgn) cod EsrmrE: ESU 6 10/26/69 . I onrert. : zxbbgnl Scheduleo: ESU 69- ~126169 . 1 ohdon. : zxbbgnl ARC: HSR demondrrtl A
TA-7079-53
FIGURE 111-43 SAMEAS FIGURE 111-42 BUT WITH ALL LEVELSDISPLAYED *JLV t
ARC PERSONNEL t Preoent 12/5/70) ...... 27 people Borrowed ...... I+ people New ...... z people I rota1 ...... %_. 30 people +3 more durung 1970 ?
TA-7079-54
FIGURE 111-44 PARTOF AFILE CONTAINING INFORMATION ON ARC PERSONNEL. (Not all levels are shown.) TA-7079-55
FIGURE 111-45 AVIEW OBTAINED BY JUMPINGTO ONE OF THESTATEMENTS SHOWN IN FIGURE 111-44 AND OPENING ANADDITIONAL LEVEL TA-7079-56
FIGURE 111-46 A VIEWOBTAINED BY JUMPING TO THE LAST STATEMENTSHOWN INFIGURE 111-45
92 TA-7079-57
FIGURE 111-47 CONTENT-ANALYZERPATTERNS STORED IN THE PERSONNEL- INFORMATIONFILE. Eachset of square bracketscontains one pattern, used to search for hidden "tags" in statements inthe file.
93 JUMP ro LINK
Hardware: Baughman. V.A. t I Engllsh. Y.K. Hardy.W.E. Weyer. N.D. Railllf. J. ROW. B.E. VanOe Alei. E.K rarborcugh. J.W.
TA-7079-58
FIGURE 111-48 VIEWOBTAINED BY USING CONTENT ANALYZER TO SELECT ENTRIESIN PERSONNEL-INFORMATION FILE THAT ARE TAGGEDFOR "HARDWARE"
94 4 1 JUMP ro LINK 1 n1Lv t
Software: Baoo. Y.L. t eoech. F. VanDen church. W.S. Duval I. W.S. Englloh. Y.K. Geoffrlon. 1.1. Harrls. J.M. Hopper. J.O. Irby. C.H. Leonard. 1.S. Melvln. J.L. I Parsley. B.1. I Paxton. Y.H 1
TA-7079-59
FIGURE ,111-49 VIEWOBTAINED BY USINGCONTENT ANALYZER TO SELECTENTRIES INPERSONNEL-INFORMATION FILE THAT ARE TAGGED FOR “SOFTWARE”
95 Ifor the two year plod drrtlng2/#/70I Personnel code I 1.213.500 rec t Cod0 I rect e 1.093.179 TotalEdlmrted cod Flxed Fee rotrl Eetlmrtedcod rlue Flxed Fee I t See attachedScheduler
Personnelrrrumed:
TA-7079-60
FIGURE 111-50 PARTOF AN ON-LINE COST ESTIMATE FOR USE IN A PROPOSAL t rrave I 7.210 Faclllty f 1.044.072 Coneu It ant r 40.000 ReportCost r rot a1 Olrect cortr 1.091.179 cortr Olrect rota1 ro ta1 Est [mated Est rota1 cod 2.106.679 F lxe d Fee Flxed 115.334 rota1Estlmrted cod Plum Flxed Fee a 2.422.013 f Seeattached Scheduler
TA-7079-61
FIGURE 111-51 PART OF AN ON-LINE COST ESTIMATEFOR USE IN APROPOSAL
97 I 1.041.072
153.072
Lease tooi I 121.572 Walntenanceand operailon 31.500
Ani I cIpat ed Iaproveaeni e 19I.000
InieracilveExternal Core 12.000 Confersnclng Facl llty 15.200 Consoleswrichlng FacIIIiy 43. I00 unlvac drum Interface 12.000 sryanfdl sc expano! on 21.000 DlscInterface IXDS 72421 10.000
TA-7079-62
FIGURE 111-52 PART OF ANON-LINE COST ESTIMATEFOR USE IN A PROPOSAL ALL ALLALL JUMP r0 ITEM
6 Acceeeory.Overvoltage Protection. LW-OV-2.Lambda. 1 at 130.00. 8457-20. PO 167969. AprlI 10.1970. ekv.icompr t 7 Adapter.Rack. LRA-1. Lambda. 1 at (35.00.1457-20. PO Ab7766. March 31. 1970. ekv.rcompt
I Augat. 1042-101 thru 1042-1510. Davld H. Roaa Co.. 10 of eachcalor at 11.10.7101-23. PO 167475. rkv. rcompn
9 AmpIlfIer. vldcoDlrtrlbuilon. C901. Crrrr ValleyGroup thru Yard-oavlr. 3 at 8115.00. PO A67119. 7101-21. January 269. 1970. ekv. Iccompr
10 Ampllfler.Puler Dletrtbutlon. C910. Craaa Valley Group thru Ward-Davlr. 1 11 1115.00. PO 167119.7101-21. JInUary 26. 1970. ekv. Iccompr
11 AugatAdaptor Plug8 Illugr). 1116-2996. Sterling. Electranlcs. 30 at 81.64. PO A67111. 7101-21. February 9. 1970. ekv.rcompr
TA-7079-63
FIGURE 111-53 VIEW OF A PORTIONOF THE PURCHASE-ORDER PROCESSING FILE, SHOWING CONTENTS OFINDIVIDUAL STATEMENTS
99 .. .
3 PArTERNS usefulfor eearchlng [link hlddenl 3A Out st andlngrequlelt lone . . . nopurchaoe order yet . I : I :[ 'PR ']AND -['PO ']AND -[&E']: I 38 Outstandlngrequlrltlonr WIih a purchaeeorder . I : I :[ 'PO ']AND -[ LEcompth]:l 3c completedorderr . r 1 : I :[ 'RCOmpR']: 30 Recenichangee io ihlr IIIc: .SINCE 170/03/06 0I:OOl: 4 0UTSrAND:NG ORDERSEACH ON A SECOND LEVEL 4A Cabinet.Storage rypc. 1000. ShclcorInc.. 1 at 195.90. 30140-710. PR A17501. Way . 1970. ckv. 48 To Regm CRr'r. 5CEP-I. SunbrlieElecironlce. 6 ai 195.00. 8457-20. PO A61777. JUIY15. 1970. meh. IC 8lndere.Nylon Pod Hanger. 9-14lNBL. UIleon JOneS. 10 at 12.17. 8457-20. PR A25012. daic.och. 4D Card. 2 Input nand 611~s.502. Datarech. 5 at 127.00. 1457-20. PR A25006. ber. 4~ Assembly. 4 Prongrable Leg. 726. Ued Coastthrough Palo Alto OfflceEqulpment. 10 at 136.00 Iwlth 25 percent dlocountl. 1457-20. 4F Markers.Cable. PUC-PK-3. 1' x 3'. UH Brady Co.. IO packs at A
TA-7079-64
FIGURE 111-54 VIEWOF APORTION OF THE PURCHASE-ORDER PROCESSING FILE, SHOWINGOUTSTANDING ORDERS LOCATED IN ASEPARATE BRANCH. Upperpart of screenshows a branchcontaining Content-Analyzer patterns. TA-7079-65
FIGURE 111-55 ALONTENT-ANALYZER PATTERN FOR SEARCHING IN THE PURCHASE-ORDER FILE
101 TA-7079-66
FIGURE 111-56 VIEWGENERATED BY A SEARCHON THEPATTERN SHOWN IN FIGURE 111-55 Section 111 APPLICATIONSAND EXPERIENCE
D. TheAugmented Report-Writing Team
1. Introduction
It shouldbe noted that much of this discussion is applicableto proposals and other types of documents,as wellas reports.
2. TeamApproach
Asin many other research groups, none of our major reports arewritten by a singleindividual.
Becauseof the broad scope of activities reported -- ranging from managementsystems research to the detailed designof software implementations -- weuse a team approach,involving one or twoindividuals who coordinatethe effort and numerous others who contribute sectionsof material covering their particular specialties.
Thepresent report contains material written by at least sixpeople -- theexact number is hard to determine becausesome material is adapted from previous documents,using archived files saved for this purpose.
Alsoinvolved in the process are individuals who must formallyapprove sections as theyare written, the principalinvestigator, who must approve the overall report atvarious stages of completion, and a technical writer/editor.
Typicaily, thesepersons as well as thecoordinators are alsomajor contributorsto the text ofthe report.
This list excludesother SRI personneloutside of ARC -- editors,illustrators, officers who must approve the report,etc. Part of the report-writing team's job is toconduct liaison with these people.
103 Section 111 APPLICATIONSAND EXPERIENCE
Augmentationbears upon all aspects of this teameffort. Becauseof the flexibility of the tools (principally NLS), thevarious individuals involved use the system in various individualisticways.
To some, NLS issimply a super-typewriter;to others, it is a high-poweredstudy aid for searching existing materialand extracting information needed in the currentreport.
Somepeople prefer to do certain types of work with hardcopy rather than at a console.These people use NLS forrapid production of hard copy of latest versionsof parts of the report; after working on the hardcopy, they use NLS forrapid incorporation of theirchanges and additions into the master files on I ine.
Tothe coordinators, augmentation means the ability to createan outline of topics to be covered in thereport, withnotations indicating persons responsible for writing particularsections, comments as to desired amounts of materialand depth of coverage, deadlines for successive drafts,etc.
Suchan outline can be continually updated by changing thebasic plan of the report, adding or deleting sections,altering deadlines and assignments, etc.; thus theoutline becomes a continuingstatus report of considerablecomplexity, yet with allinformation readilyaccessible because of NLS featuressuch as the contentanalyzer.
As sectionsof the report begin to take shape as NLS files,links to these files can be inserted at the appropriatelocations in theoutline. Now the coordinators,examining the status of the report effort, canjump instantaneously from a planningdescription of partof the report to a viewof the actual work in progress;conversely, authors working on report sections canexamine and reexamine the outline as they work.
It isdifficult to make a meaningfulcomparison between report-writingat ARC andelsewhere, because the process alwaysdepends heavily on the individuals involved and the organization'sgeneral philosophy about reports, as well as thefacilities available. However, we can safely say that Section I11 APPLICATIONS AND EXPERIENCE
this kind of close teamwork would be quite impossible for us without the augmentation aids that support it. To collaborate as tightly as we do without augmentation, we would need an immense amount of time and a staff of full-time coordinators, clerks, and typists.
3. Advantages
a. NLS
As a tool for coping with the mechanical problems of report writing -- input of material, assembly of material into a report structure, organization within the structure, text editing, and final output -- NLS has proven to be superb. For some operations, such as automatic searching of thousands of words of text for particular words or phrases, NLS is several orders of magnitude more efficient than paper-and-pencil technology.
To illustrate the advantages of NLS, let us briefly consider a few specific examples.
For entering text, NLS becomes a super-typewriter. This is probably the simplest possible use of NLS. The advantages of NLS over a typewriter come from severalfactors:
(1) Backspace-characterand backrpace-word keys, which cause immediate deletion of the last input character or word.
(2) The user's knowledge that further corrections can easily be made later.
(3) The availability of NLS's study capabilities. This is the most critical advantage, since it allows the writer to go back rapidly over what he has already written and reorient himself as he moves from one topic to another.
As a tool for assembling, organizing, and reorganizing material from diverse sources (recent input, existing files, etc.) NLS replaces such technology as the loose-leaf binder, the blackboard full of notes, the extra information written on small
.. .. -. . . . - .. Section 111 APPLICATIONSAND EXPERIENCE
slipsof paper and clipped to pages in thelooseleaf binder,etc.
In ourpresent state of evolution, this replacement is necessarilyincomplete -- theolder methodsare used in coordination with NLS. However, NLS dominatesthe overall technology for organizingmaterial and to this extent it greatly increasesefficiency.
Themaster copy of a reportin progress is a set of NLS files.The insertion of newmaterial as it becomesavailable is accomplished quickly and smoothly,and the working material is completely legibleat all stages.
Thedifference between working with a formatted NLS displayand working with a binderof cut, stapled,pas-ted, and pencil-marked typewriter copymust be experienced to beappreciated. Moreover, a complete,fresh, fully formatted printout of theexisting draft can generally be obtainedin a fewminutes, at any stage of the job.
Theterm "editing" is used here to mean the task of goingthrough a draft or a sectionof a draftand correctingerrors of spelling,grammar, style, and (withinlimits) content.
Ourreports generally receive twoediting passes: oneby ARC'S technical writer, using NLS, and a secondby one of the SRI editingstaff using pencil-and-papermethods.
NLS permitsthe augmented editor to work a great dealfaster than he could with paper and pencil. Of course,he works with theknowledge that anothereditor will go over the draft and habituallyleaves many decisions up to him.
Theadvantages of NLS for editingstem from two basicfactors -- sheerspeed, and the power of automaticsearching.
Thespeed is justbrute force in action: it is quicker,for example, to specify thecommand
106 Section 111 APPLICATIONSAND EXPERIENCE
"ReplaceWord," point to a location,type the newword, and hit the "command accept" button than it isto make the equivalent marks on hard copy.Using "Jump" commands tolocate cross-referencedlocations in thetext is faster,by orders of magnitude, than flipping pages in a binder.
Automaticsearching for specified strings of textpermits operations that are virtually impossiblefor the unaugmented editor.
For example,many writers consistently misspellcertain words. The augmented editorcan execute a "Substitute"command that will correctall ocurrences of several differentconsistent misspellings, throughout a file, in a singleoperation.
Foranother example, suppose that halfway through a lengthydraft, the editor suddenly findssomething that makes him uneasy about theway a particular term isbeing used -- a termused many times in the early portions ofthe draft.
Theunaugmented editor would be faced withthe prospect of reexamining many pages of text, lookingclosely enough to findall occurrences of the suspect term. Thissituation is one that editors encounterquite frequently, and the work involvedis both lengthy and fatiguing.
With NLS, theproblem disappears; the editoruses the content analyzer to find alloccurrences of theterm automatically. If hethen decides that a differentword should be used, he can use a "Substitute"command to make the change throughoutthe file or inspecified portionsof the file.
b. A Noteon Structured Text
Ouruse of "structured text" -- i.e., a formatthat reflectshierarchical relationships among "statements" Section I11 APPLICATIONSAND EXPERIENCE
or paragraphs -- issomewhat controversial with some of ourreaders.
Manyof NLS's mostvaluable features depend upon structuredtext. Moreover, structured text has advantagesof its own.The special formatting carries informationthat is notin the text itself, thus increasingthe overall "bandwidth" and permitting greatereconomy in writing.
Structuredtext is a directconsequence of the use of thecomputer as a writingmedium, just as standardized punctuationresulted from the introduction of movable typeas the medium for publishing. Hopefully, structuredtext will turnout to be only the first step in thedevelopment of newways to show, by formatting andother nonverbal means, various relationships among theunits of information that make up a document.
c. AssemblyofReports
Asnoted above, NLS isused to put together material fromvarious sources to produce a completedraft. This raisesthe possibility of keeping on hand a large collection of materialthat describes our work in its variousaspects, frequently updated so thatat any time wecan extract what is needed for a report. This material,ideally, would make up a verysizable part of eachreport and would require only simple rewriting, thusgreatly reducing the labor of report-writing.
Thisidea has been with us for years, and we have made someprogress inimplementing it. Tothe extent that it actuallyhappens, it isvery worthwhile; however, only a verysmall part of a typicalreport is actually done this way.
Inthe present report, for example, only the preface, thebibliography, and the appendix are taken directly from existingmaterial. Larger portions are derived fromexisting material, but with complex and extensiverewriting to suitthe needs of this report.
4. Problems
Theproblems of augmentedreport-writing fall into several categories,described in the following sections.
108 Section 111 APPLICATIONSAND EXPERIENCE
To someextent, the problems are not merely, rep.ort-writingproblems but augmentation problems, i.e., problemscreated by side-effects of augmentation upon thetotal ARC system.
a . Technicala. Problems
Thesimplest problems are technical in origin. For the mostpart, they seem not to relate to gaps in technical capability -- i.e.,“missing features” -- butrather to inadequateperformance of the technical systems on which wehave come to depend.
Asnoted elsewhere in thisreport, system response is degradedwhen several users are working simultaneously; becauseof our team approach to report-writing, this degradationtends to be worst at the worst possible time ” justwhen several people are trying to complete their contributionsto the report.
A morecritical problem arises from technical limitationson file storage. Two storage media, disc andtape, are available for report purposes.
Tape, in thecurrent system configuration, is inconvenientand can only be used for long-term backupcopies.
In thelast few months regular procedures have beenestablished for tape archiving; so far, however,relatively few files have been saved on tape in such a wayas to be reasonably accessible.
Discstorage space is severely limited. Reports take up a greatdeal of space compared to other types of filesin use by ARC, whileat the same time they are lessuseful in day-to-daywork by ARC personnel.
Work on a reportgenerally involves considerable shufflingof files in order to obtain space for thenew report files; files not related to the reportare moved into out-of-the-way locations, andwe sometimes lose track of them in this process.Duplicate copies are destroyed to make moreroom, and here there is a chance of inadvertentlydestroying the last copy of a file. Furthermore. if onlyone copy of a fileis kept we Section 111 APPLICATIONS AND EXPERIENCE
facethe possibility that a systemerror will destroy it.
Theactual loss of a filehas become a relativelyrare occurrence, as users have becomeaware of the problems and developed habitsand procedures to safeguard their files. However,we expend a greatdeal of time and energy on thesesafeguarding measures, and this seriouslyslows our report-writing efforts as wellas all of our other on-line work.
Whenwork on a reportis finished (or temporarily halted) a reverseprocess takes place: the report filesare hidden away, with a risk of losingthem.
b.Problems of Explainingthe "Augmentation Culture"
NLS andour other ,augmentation systems are part of an exceedinglycomplex t-otal system that includes all of ourset procedures for doing things, our management methods,our goals, and our strategies and priorities fordoing research. This total system is the tangible partof the "augmentation culture"; the intangible part consistsof personalities, emotional interactions, intellectualorientations. etc.
It is a tinyand incomplete culture with a briefhistory -- a laborat'orymodel. Nevertheless, like most cultures it isincompletely understood by the people inside it. Thelong-term side-effects of any innovation are unpredictable,and occasion'ally such side-effects give riseto problems.
Theproblems of the augmentation culture affect all of ouractivities to varying degrees; with reports, however,these problems are multiplied, because the centraltask is (in principle) to explain this same culture to a readerwho has no direct experience of it.
Inpractice, we rarelyor never attempt a complete explanation;instead we describevarious important aspectsof our work, one at a time.Unfortunately, this leadsto a fragmentedpicture in which the true context ofour work -- a whole-systemapproach -- tendsto becomeattenuated.
110 Section 111 APPLICATIONSAND EXPERIENCE
c.Problems of Organization and Technique
Practicallynobody likes to write reports. What is worse,very few people are capable of writing good reportson difficult topics without very great expendituresof time and energy. At ARC,we have respondedto these problems in several ways:
(1) We havedeveloped an elaborate system of computeraids for writing (as well as other purposes).
(2) We havenegotiated our contracts in such a way asto require a minimumnumber of reports.
(3) We haveused live demonstrations and films to supplementthe communication function of reports.
(41 We haveexperimented continually with different ways of organizing a report-writingteam to function withinour culture.
Somecommentary on these responses may serve to illuminatethe problems.
Withregard to the first item, the computer aids are magnificent(as described above).
Reducingthe total number of reports required is debatable; it canbe argued that it wouldbe easier andmore effective to produce small reports at more frequentintervals, thus making final reports much lesscritical and easier to .write, sincethey could leanupon the information contained in recent short reports.
It is probablytrue that films and live presentations aremore communicative of what we are doing than any writtenreport could be. However, they do not lessen thedemand for good reports and they cannot be stored online for computer access.
Experimentationwith ways of organizing the reporting effort will probablybe the most fruitful way of solvingthe problems.
We arestill only beginning to develop a good
111 Section 111 APPLICATIONSAND EXPERIENCE
organi.z,ationalapproach to the report problem. Thepresent report is being produced under a ratherelaborate plan of highly distributed authorshipwith a singleindividual as planner. coordinator,and Ilpusher."
Atthis writing, our principal difficulties are in gettingall the various authors to finish their contributionson time and in stickingto any one schemefor the organization of the many sections. Althoughearly analysis may well be misleading, thesituation suggests that we have concentrated toohard upon the distribution of responsibility forwriting sections, thus neglectingother equallyimportant requirements for a workable delegationof authority, better forecasting of the effortinvolved in various phases of the work, bettertiming, etc.
E. TheAugmented Presentation
1. General
When a groupof people meets for purposes of discussion, briefing,planning, etc., it isoften necessary to communicate a preparedbody of inform'ation to them for review,orientation, or tutorialpurposes.
Theusual mode in such a session(which might be a meeting,lecture, seminar, or anyother sort of gatheringdealing with any sort of subjectfrom poverty problemsto sales policy to biochemistry) is for one personat a time to speak, with variousdegrees of preparation,and various levels of support from audio-visualaids. Effective use of these aids usually requiresspecial preparation of the materials [tapes, slides,charts, etc.), or specialeffort at the time to writeon a blackboard or image-projectorsuface -- althoughoccasionally there is an opaque projector or TV circuitthat enables the speaker to integrate some of hisnormal working material into his presentation withoutspec.ial preparation.
To anyof us who are seasoned users of NLS, participatingin conventional presentation processes has becomeeven more painfu! than it wasbefore webecame accustomedto augmentation. We havegrown so usedto
112 Section I11 APPLICATIONS AND EXPERIENCE
theability to move around easily within any of our informatonbases (designs, documentation, reference material)and to switch quickly among the many useful waysof viewing the information, that we wish that sort ofcapability were available to the speaker.
If a closed-circuit TV system is availableto distribute thecomputer-display images to a group,then a speaker withon-tine access to a computerizedinformation system canindeed make an "augmented presentatton."
2. EarlyExperiments
In October 1967 weset up a specialconference room, with TV monitorsarranged so thatsome twenty people, sitting around a rectangulartable, could watch an augmented presentation. We inauguratedthe facility with a two-day meetingbetween our staff and the technical monitors from thefour agencies then sponsoring our work.
Atall times during the meeting, the speaker sat at the NLS controlconsole (a position at the table that had a keyboard,keyset, and mouse in additionto a monitor) andcould instantly access and display information in anyof our total collection of files.Some of the materialwas specially prepared reference material for agendapurposes, but most of it wasour actual working material -- planning,design, documentation, and scratch-notefiles.
A trialagenda was prepared ahead of time in an NLS file,but from the outset it wassubject to ad hoc reviewand modification.
Togive the participants a bettermeans of talking about thedisplayed material (i.e., voicing questions. challenges, or suggestions),each had access to a mouse whichcould control a secondtracking spot on the screen.This spot was used as one would use a wooden pointerto draw attention to an item on a blackboard; it wasof different shape from the control spot used by the speaker, so it waseasy to keep track of who was pointing.
Thismode of running a project-reviewmeeting proved veryrewarding. We subsequentlyused the setup frequentlyfor special presentations (mostly for Section I11 APPLICATIONSAND EXPERIENCE
visitors),also with greatsuccess, and perhaps a dozen times for workingmeetings of ourgroup. In mid-1968 we dismantledthe setup, since we needed the space for expandedshop area and the TV monitors for more NLS conso I es.
To getat least the capability for a largeraudience to view a display,we have had a flexiblearrangement for attachingtwo or moreTV monitors to one NLS console, We holdmany demonstrations and presentations this way, forgroups up to about 20 people.
3. Development of ImprovedCapabilities
Bymid-1968 we hadacquired some special-effects video equipmentthat gaveus the following capabilities:
Videomonitoring and switching: An operator monitors imagesgenerated from a numberof sources and can select from thesethe signals to be channeled to various destinations.
Videomixing: Two signals can be blended, with adjustablestrengths, to superimpose two images.
Signalfading: A selectedsignal source can be slowly diminished or strengthenedto achieve smooth, gradual transistionsbetween image-composition states.
Imagesplitting: The screen image is divided geometricallyinto two parts, each being the correspondingframe part from a differentimage source. A horizontal or verticaldividi'ng line can be set at any . postion, or a rectangularinset can be made in one cornerof the frame and its size adjusted.
We alsolocated a NASA-ownedEidophor Video Projector at thenearby Ames Research Center and were fortunate enough tobe able to borrow it onseveral occasions. It projects ourvideo images onto a largesingle screen with very high qualityand is suitable for presentations to large audiences.
Aswe were experimenting with augmented presentations, we learnedof a specialtechnique developed by W. A.Palmer FilmsInc. of SanFrancisco for directly filming the video image(and sound from a microphonecircuit) to produce a Section 111 APPLICATIONSAND EXPERIENCE
motionpicture. On a number of occasions,we have arranged for a cameraand operatorto film ourpresentations.
We alsodeveloped special coupling equipment enabling us to leasevoice- and video-grade transmission channels to a remotesite. From the remote site, we can then use our computersystem to s'upport two regular NLS consolesand any associatedvideo-control and -projection equipment for conducting full presentations.
4. Large-ScaleAugmented Presentations
We successfullyused the full rangeof these techniques in twolarge-scale presentations -- inDecember 1968 atthe FJCCin San Francisco, and in October 1969 atthe annual ASISmeeting in SanFrancisco.
Thesepresentations were set up with the main speaker seatedat the front of the auditorium, at one of our regular NLS consoles,to one side of thelarge screen butin full view of theaudience. He had a microphone, andcould directly address them as though delivering an ordinaryspeech.
A TVcamera mounted near him caught a full-sizeface view,and a "productionmanager" for the presentation,seated at the rear of theauditorium withswitching, mixing, and frame-splitting control, couldput the face view on the screen for a muchmore effectivefeeling of direct contact between speaker andaudience.
Whenthe speaker chose to use NLS, andturned his headslightly to see the NLS displayscreen, the projectedimage would be switched to show his computer-displayview to the audience.
Frequently,images captured on mobile TV camerasin our laboratoryat SRI wereswitched onto the projection screen, so thatthe presentation could include both a tour of ourlaboratory and participation from people locatedthere.
Fourdifferent researchers at the laboratory worked duringthe presentation at consoles in our work room (variousshots during the presentation verified that theywere there in the background, actually using the Section I11 APPLICATIONSAND EXPERIENCE
consoleswhile the rest of the show went on).
Atvarious times, the full faceof one of the four wasbrought on screen, dialogue went on between him andthe main speaker to introduce him and his topic. andthen he took over and ran a portionof the presentation in muchthe same manner as the main speakerhad been doing -- thescreen being able to showalternate (or split and/or mixed) images of him andhis display-screen image.
For bothconferences, the complete presentations (each aboutone hour and forty minutes in length) were captured on 16-mm film (blackand white with opticalsound). The ASIS film isthe better of the two, and we have made eight copiesthat have been in active loan circulation since the firstof the year. It is betterthan any earlier self-containedform for conveying an overall picture of our augmentationsystem. The copies have been loaned to some 70 organizations,including several in Canadaand one in France,and we hear of many repeat showings put on by a borrowingorganization as a resultof the response of the initialaudience.
Onemust see one of the movies to appreciate the differencebetween the augmented presentation system and whatcould almost have been substituted for it -- e.g. , a previouslymade set of slides of all the display-screenviews, and a veryfast-acting and large-capacityslide-selection system under control of thespeakers.
Forclassroom lectures, for project briefings in connectionwith complex system-developmment projects, forpresentation of complex issues to a reviewingbody (suchas a congress),etc., these extensions of our augmentationsystem toward an augmented presentation systemseem extremely promising.
We intendto push further development of these techniquesfor application by smaller groups within a system-developmentteam -- groupmeetings for brainstorming,plan and design review, etc.
5. Conclusions
Assumingthat techniques similar to ours are bound to
116 Section 111 APPLICATIONSAND EXPERIENCE
evolve for widespreaduse in intenseintellectual work both byindividuals and in smallgroups, it isquite obvious thatextensions to thetechniques, such as described above, for augmentingpresentations to largergroups will become quiteimportant. Although pursuit of presentation techniquesis not our central goal, wewould like to encourage a generalappreciation of itspotential.
IV THE NETWORK INFORMATION CENTER
A. Overview of the ARPA Network
1. BasicDescription
The Advanced 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 between 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 process of establishing the ARPA Network, which is a data-communication network linking the comFuter facilities of these fourteen research centers.
Each of these centers has a coordinated collection of resources -- both technological resources such as computers, storage facilities, input/output devices, and software systems, and human resources such as knowledge, skills, and methodolog-ies.
It has been necessary, in general, for these centers to engage in wasteful duplication of basic resources and to live with adverse restrictions on th.e number and quality of special-purpose resources available to the researchersat any one center. But wide-band connections between centers will bring many -- perhaps eventually all -- of any center's computer resources within the reach of every user in the Network.
Two basic domains of work are involved in this experiment:
(1) Developmentof technology for providing intercommunication between programs in the different centers
(2) Integration of the distributed resources of these centers into new patterns of support for users of the Network.
Detailed information-network technology is described in a set of companion papers presented at the 1970 Spring Joint Computer Conference (see Refs. 19.through 231. The following simplified description is intended as background for the discussion of the Network Information Center contained in subsequent sections. Sect ion IV THENETWORK INFORMATION CENTER
2. Host-to-HostCommunication
Eachresearch center, or Network''node," will provide accessto one or morelocal computers dedicated to research oninformation-processing techniques. These local computersare called "hosts."
Aspart of theNetwork, ARPA supplies to each participating center a small,specially programmed computer called an InterfaceMessage Processor (IMP) which is connectedto the host (or hosts)for that center.
TheIMP provides each host computer with a uniform functionalinterface into a networkconsisting of 50-kilobaudtransmission lines leased from telephone companies.
EachIMP controls traffic to and from its host or hosts, aswell as traffic along the Network channels. As far aseach host is concerned, the Network may be treated as a multi-portblack box with IMPs serving as theports.
Verymuch like voice-path connections between users of a telephonesystem, one-way message paths called "links" may beset up between specified hosts by the IMPs.
For example,"Link AD3" might designate a path from Host A toHost D differentiatedfrom other possible links from A to D bythe label "3."
SpecialNetwork-monitor programs resident in eachhost computeractivate such links and negotiate among themselvesto allocate them to specific communications-pathpurposes.
The "0" linksare reserved for control messages directly betweenthe monitors.
3. Program-to-ProgramCommunication
Program A in Host A mayask for a communicationlink to be establishedfrom it toProgram B inHost B. Ascurrently planned,the following chain of operationswould occur:
Program A submitsthe request to Monitor A.
Monitor A usesControl Link AB0 to negotiatethis with
120 Section IV THENETWORK INFORMATION CENTER
Monitor B. AfterMonitor 8 ascertainsthat Program B is availablefor such communication, the two monitors togetherassign one of the ABn links to this communicationpurpose (for example, Link AB4).
Monitor A verifiesto Program A that its request has beenfilled, and that Link AB4is now connected to Program B.
Program A isnow linked to Program B bywhat appears to thetwo programs as a privatecommunication channel betweenthem; any dat.a sent out by Program A via Link ABLt is delivereddirectly to Program 8.
Anysort of information that could be sent between two programswithin the same computer may be sent along such a channe I.
For example.Program A mightsend control information to Program B asking it toset up a reverselink, and to transmitalong that link the results of processing a File B thatresides within Host B. Or conceivably, Program B couldbe asked to link to Host C toget and processFile C.
Program A couldbe an interactive preprocessor serving a User A who is connecteddirectly and locally to Host A andfor whom most of the service is being supplied by a Program B. Program B couldbe a. sophisticateduser subsystemsuch as Mathlab at MIT, the Culler-Fried systemat UCSB, or our NLS.
In anyof the more sophisticated, display-oriented subsystems,User A's hardwarecould be different from the hardwareused at Program B's homesite.
Program A mightprovide an adaptation for theparticular terminalhardware being used by User A.
It probablywould also provide some of thelocal interactivefeedback such as character echoing at a full-duplexterminal. SectionIV THE NETWORKINFORMATION CENTER
B. Someof Our Prospective Uses for theNetwork
1. BasicProcesses
A variety of Program A thatis likely to be established earlyat each host is a processthat allows a typewriter terminalat that host to link to the timesharing executive in Host B.
Such a processwould enable User A tolog into the Host B's timesharingsystem and work as though he were a localuser atSite B, usingany of the typewriter-oriented subsystems thatmay exist in the B system.
2. BootstrappedSystem-Transfer
Forour first experiment in Network usage wehave establishedan interface to theUniversity of Utah's Networkhost, a PDP-10 computer, so that a programmerat one of ourconsoles can use the editor and loader-debugger atUtah to developand check out programs to be run for our specialuse.
Thisis the first step in a sequenceof experimental uses of theNetwork that promises to help us significantlyin preparing to transfer our software systemsonto a newPDP-10 computer system next Fall.
Incarrying out this experiment, we will becoordinating a verylarge collection of technologicaland methodologicalresources in a novelway.
We areproducing modified versions of all our languagecompilers. These new versions will stilibe runon our XDS940 systembut will produceobject code for the PDP-IO.
Ourprogrammers will compose,modify, study, and compilethe software being written for the PDP-IO usingonly the resources of our own Center, principally NLS andthe special compilers.
Then,when there is need to test a pieceof the new software,they will activateNetwork links to put themin communication with Utah's PDP-10 executive system.The compiled code will beshipped over the
122 Section IV THENETWORK INFORMATION CENTER
Networkto Utah, where it willbe loaded and executed.
Still workingat our on-line consoles, our programmers will beable to debug the object code using thePDP-lo's debugging facilities and, then, rapidlyswitch back to NLS tocorrect the source code aswe1 I.
In this waywe plan to bootstrap the development of a PDP-10version of NLS so thatwe can be up and running veryquickly when our own PDP-1'0 isinstalled. We hope NLS will havebeen entirely written and mostly debugged bythen. The entire power of NLS will havebeen used duringcyclic stages of converting/rewriting,debugging, source-codeupdating, and documentation.
It is interestingto note that another PDP-.IO, whichcould beused for program checkout via magnetic tapes carried backand forth, is located just down the hall from our presentcomputer. Howe.ver, it promisesto be significantly moreconvenient for US touse Utah's PDP-IO connected directlyto our computer via ths Network.
We cancommunicate our programs to it muchmore conveniently;and, while sitting at our ownconsoles to debugthe programs, we can quickly switch to locai NLS toinspect or modifythe source-code files or toenter notesand docurnentation.
3. CentralizedFile Archiving
Anotherstraightforward way we can benefit from the basic Networkis by using the file-storage system at the Universityof California at Santa Barbara as our file-archiveresource.
Besidesproviding service to the local ARPA project, UCSB's hostIBM 360175 isthe central re.source of the University's ComputationCenter.
IBM 2314 disc-filetransports, programs to store and retrievefiles, on-duty operators to run back-up dumps ontomagnetic tape, and accounting and billing proceduresto handle service to miscellaneous users are allpart of this resource. Sect ion IV THENETWORK INFORMATION CENTER
We considerusing their file-storage system as our file-archiveresource.
We wouldinterface this archive system to our On-Line System so thatthe response to a callfor some service in storing or retrievingan archive file could function exactlyas though we were storing and managing the file locally.
OtherNetwork users could also use this file-archive systemeither by interfacing to it directly or by interfacingto it through us.
Thisbegins to suggest some of thepower inherent in thenetwork concept, since the number of subsystems available to eachnetwork participant can "pyramid" on thebasis of a relativelysmall number of interfacingtasks.
We couldgain considerable economic advantage from being ableto share with many other users the capitalization and operating-accountingexpenses involved in providing a basic disc-filearchive system.
Installingand operating such a serviceourselves would be a distractionfrom how we want to use our manpower -- but wehave to have this capability.
Beingable to use the Network to share this resource couldbe an important benefit to us.
4. Data-BaseManagement Service
We alsohope to utilize one of the big-computer hosts with largediscs and an operating staff, to help install a commercialdata-base management system for use by US and therest of the Network.
Again,the interface process would reside in our host and giveour users a data-basemanagement service that they can interactwith as if it were a localservice. None of the protocolrequired to fire up the remote system, properly formatservice requests, and specify delivery of its productsneed involve our users.
To presentour users with uniform conventions over all ofour different service functions, we wouldwant to be SectionIV THENETWORK INFORMATION CENTER
ableto compose service requests in an NLS file using ourown particular syntax.
Inaddition, to take advantage of NLS power in studyand modification,we would want to have query results convertedinto NLS-file form so that they can be integrateddirectly into our regular working files.
C. Needfor a NetworkInformation Center
Topursue such relatively straightforward uses of the Network, a user will needto know answers to such questions as:
Whatresources are available within theNetwork?
Whatconditions are associated with the use of a particular resourceat a givennode?
Whatinterfacing is required to couple to this resource?
Who shouldbe contacted to arrange for this?
Moregenerally, each site will alsoneed answers to questions aboutother nodes and about the Network such as the following:
Whatare the hardware and software resources?
Whatare the research activities?
Whatare the operating instructions for a givenresource?
When will a prospectiveresource become available?
Who isinterested in new display systems?
Who wentto a particularconference?
Who elsewas interested in NIC Memo 7721?
Thewhole Network experiment will consistof negotiating, implementing,and operating many such arrangements. To carry outthese negotiations effectively and to document the results ofNetwork experiments, Network participant-s need access to informationof the kinds mentioned above as well as a medium forrecording their experiences; it isthe role of theNetwork InformationCenter (NIC) to service these needs. Section IV THE NETWORK INFORMATION CENTER
D. NIC DevelopmentActivity
1. Background
Our involvement in the development of the Network Information Center began shortly after the official announcement of plans to proceed 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 operating the NIC.
Since then, we have been gradually evolving and implementing plans for providing a coordinated and useful collection of services to Network participants. This has proved to be a far more difficult task than we originally envisioned for several reasons.
The Network will provide a completely unfamiliar working environment, and it is far 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 vague 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 requires a kind of organizational structure and management different from that which had been appropriate in the early years of our research activities.
In designing the NIC, we were conscious of the fact that more was needed than just good library facilities.
The technical sophistication of the tools we had available and of the users we would be serving demanded that we seek to make it possible for this community to derive significant advantages from the Network in terms of increased communication of ideas, designs, criticisms, and comments on needs and possibilities. Sect ion IV THENETWORK INFORMATION CENTER
We recognizedthe challenge involved in fostering an environmentthat would encourage increased collaborationamong individuals and groups at differentnodes, and felt t'hat the NIC would bear muchof the responsibility for setting the direction ofefforts to meet this challenge.
And in designingthe NIC we were aware that it wouldnot besufficient merely to pro.vide good technical features, butthat the design must reflect the kind of coordinated user-system / service-systeminterface that we have felt is so important in thebootstrapping approach to the developmentof our ownaugmentation aids.
2. Orientation
In orderto gain perspective into what was expected or desired in theway of service from the NIC, we talkedwith a numberof Network site managers as well as with library sciencespecialists.
Mostof the managers were uncertain about the nature and extentof their probable partic,ipation in theNetwork anddid not know what they wanted from the NIC.
Whatexpectations we were able to uncover frequently showedextreme differences from person to person.
Somethought that there was little need for a NIC, whi.leothers thought that the NIC should supply initiativeand leadership in thedevelopment of overallNetwork conventions and methodologies.
Somethought that the NIC was going to serve as a intermediaryfor handling working communication betweenhosts, providing teletype buffering and spoolingoperations, or that it wouldbe responsible forspecifying protocols for .communication between differenttypes of terminal devices.
Thetypes of service to be provided, in termsof mediafor storage of documents and methods of enquiry,were perceived at points all along the continuumfrom completely off-line to completely on- I i ne. Section IV THENETWORK INFORMATION CENTER
Andthe types of retrieval capabilities envisioned rangedfrom fully automatic to fully manual.
However,one reasonably consistent picture did emerge: almostall the managers contacted expressed a concern forthe poor state of documentation within their projectsand a hopethat the NIC would be able to help themnot only with Network-orienteddocumentation but with theirin-house needs as well.
Theneed for improved documentation was seen not only in thearea of "formal" documentation, such as user manuals andreference guides, but also in the realm of the "folklore"that evolves around every system and that is anabsolute necessity for making effective use of a system.
Somemanagers expressed the opinion that a remotely locateddocumentation-aid system might receive heavieruse than one at their own site because there wouldnot be the usual conflict between using the localfacil.ity's resources for documentation as opposedto using them for programming or other work, thelatter always receiving higher priority in most researchers' minds.
Part of the"folklore," or informal documentation, wouldplay the role of clearing house for communicationon defects, bugs, needs, possibilities, etc.,and would help to provide feedback on the statusand accecptability of existing or needed programsand formal documentation.
Theoutcome of these discussions, and of analysys of the severaltentative NIC designs that resulted, has been to takethe position that we shouldinitially provide Network userswith a fewrelatively basic services and let the developmentof the "optimum" NIC evolve in a naturalway as usageexperience builds up.
Thus,we are planning to help Network users gradually to applyour concepts, conventions, tools, and techniques torelevant aspects of their own working environments, whileat the same time providing them with a reasonable initialcorpus of reference material.
We will makeevery attempt to encourage and facilitate
128 Sect ion IV THENETWORK INFORMATION CENTER
feedbackfrom these users so thatwe can expand NIC servicesto meet their needs for informationaccess and exchange.
E. Current NIC Plans
1. Introduction
We aimto be prepared to provide certain basic types of servicesthrough the NIC, each of which will beexpanded or elaboratedas needed. This approach isour way of accommodatingthe uncertatnty about the user-population's informationactivity described above. This section outlinesthe measures we have taken to accommodate these basicservice needs.
2. BasicLibrary Services
Thefoundation of NIC operationmust be a flexiblelibrary service,the development of whichrequires us to:
Accumulate a physicalcollection of information items,in varioussizes and media, and then store them in a secure andorderly manner.
Provide a catalogin which the descriptions of these itemsare maintained, and from which can be obtained the keys(clues) necessary to locatethe physical items.
Provideindices and associated query procedures to aid users in findingcatalog items of interest.
Providedirect means for a userto obtain access to documentsfor which he possesses keys, and enable "browsing"where possible.
Providedirect reference help via two-way dialogue with anexpert.
We will initiallyprovide this basic library service in waysnot too dissimilar to those used by other special informationcenters and clearing houses.
That is, weexpect to be interacting with users through mail and.voice-telephone channels, to be distributing hard-copyindices and catalogs, and to be malting specialquery-response listings and references. Section IV THE NETWORKINFORMATION CENTER
3. On-LineServices
We arealso seeking to harness computer, display, microform andcommunication technologies to elevate what a "library" representsto its community toward new levels of "augmentingthe intellectual processes of communication and collaboration."
To thisend we aretaking special measures toward "the waywe do our library work here" -- thenature of the collection,the form of catalog and indices, the proceduresfor developing and maintaining them, etc.
Andwe are investigating ways of improving special aspectsof the user's interface to the NIC -- his query andbrowsing techniques, his means for doing bibliographicwork, his means for publishing communiques tothe community, his means for staying in touch with currentactivities, etc.
As thetechnology and methodology of Network utilization develop,there will be a rapidlyincreasing number of widelydistributed. terminals through which a personcan gainon-line acce.ss to the NIC, and we are taking very strongmeasures to be able to serve them.
Besidesdeveloping the services .described b.elow, we have invested a greatdeal of effort toward increasing our servicecapacity with special system studies and the installationof a bankof external core and three high-speedswapping drums; and this fall we will be shiftingto a newcomputer (see Section 11).
We areprepared to supply some on-line query service as soonas the Network can support host-to-host full-duplex typewritertransactions -- thesimplest kind of general Networkusage. Continual development of thevariety and sophisticationof the service will followlines discussed in therest of this section.
Duringthe next year most remote on-line users will be servedby TODAS, a typewriter-orientedversion of our On-LineSystem (NLS).
Initially,both access to our subsystems and the number ofNetwork users that we can accommodate will bequite restricted,but we planfor steady improvement in both Sect ion IV THE NETWORK INFORMATION CENTER
interactive quality and amount of the service available to Network users.
We feel ready to support three Network TODAS users now; when installation of the new drums and external core is completed late this summer, we might be able to increase this to five; 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.
Those sites having display 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 modifying an Imlac 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 standard mouse and keyset input devices, and any other Network user possessing such a terminal could quickly avail himself of similar service.
As soon as we have transferred our present systems onto the new PDP-IO computer and have achieved reasonable stability in system reliability and response, we intend to concentrate upon developing techniques to permit general use of our NLS capabilities on a wide variety of remote display terminals, and we anticipate haying a growing Network load of this type by next summer.
V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
A. Introduction
Ourexperience in developing and using augmentation systems, someof which was described in Section 111, gives us confidence in thevalidity of our long-term goals and approach toaugmentation research. We arebeginning to have strong feelingsthat our efforts, still proceeding under the guidance of ourbootstrapping strategy, are on the threshold of yieldingsignificant payoffs.
Theconcept of augmentation systems is no longer in question
" suchsystems are bound to come. The only uncertainties involvethe rate and direction of development and what can be doneto improve both, so asto foster more efficient evolution andensure the earliest possible application of these systems tosolving real problems facing society.
Thissection summarizes the conclusions we have drawn from our researchprogram and outlines some of our plansfor future activities.
B. ConclusionsRelevant to OtherAugmentation-System Developers
1. GeneralComments
Theexperience wehave had in setting up the Augmentation ResearchCenter facility may not be directly applicable to othersystem developers, but there still may be something tobe learned from ouraccomplishments and disappointments in implementingsome of thecomponents of oursystem.
Inthis section, therefore, we will take a look atour facility,evaluating some of itsunique aspects and discussingsome of themajor problems that have been encounteredin its evolution.
Thisfacility is described briefly in Section 11-B, and a morecomplete description is contained in Ref. 17.
2. Accomplishments
a.Display System
(1) General
Ourdisplay system uses centrally located display-generatingequipment and a closed-circuit televisionsystem to distribute images to individual conso I es.
133 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
This approach to display-system design was chosen on the basis of cost and flexibility, and a detailed description of the system and of considerations that went into its design is given in an earlier report (Ref. 11).
After considerable experience operating this system, we are still pleased with the basic approach.
(2) UsageAdvantages
The closed-circuit television system offers several distinct advantages over other means of producing displays at a user console.
Since only a television monitor and a video line are required to present the display at each NLS console. the design and location of consoles is flexible enough to facilitate experimentation with different types and to permit moving them about with a minimum of cabling problems.
The video signal can be inverted to provide a dark-on-light display, which is usable in higher ambient light conditions than the more common light-on-dark presentation and which makes flicker in the display image less noticeable to the user.
A significant storage time can be obtained on the vidicon surface by proper adjustment of the televisioncamera. This reduces the flicker effect that is presen-t in the original CRT display, and with this system we find it possible to produce satisfactory images with a regeneration rate of about twenty per second.
(3) MaintenanceFeatures
Since the display equipment at each NLS console is simply a television monitor, it can be replaced by a spare for maintenance without taking the console out of service.
The location of the display-generating equipment in the computer room, where complex maintenance and repairs are more c'onvenient, makes pos~ible an
134 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
uncluttered office environment in the user's working area.
Having two identical display systems, from display controller through actual monitors, is a major factor in maintaining up-time i.n spite of the high level of maintenance that has been required on these systems.
Since there is not a fixed one-to-one relationship between display-generating equipment and NLS consoles, users may select consoles freely on the basis of current needs even when part of the display system is out of service.
(4) Potentials for Extending Capabilities
Since a great variety of commercially available equipment is compatible with our video system, there are many potentials for innovative use of our system that would be much harder to realize with conventional display-distribution techniques.
For example, we have used high-quality projection television as part of our presentations at the 1968 Fall Joint Computer Conference and at the ASIS Conference in 1969 (see Section 111-E).
It is possible to use multiple TV monitors or intermediate-size projection equipment for smaller groups, and experimentaion with these techniques will be a major element of the team-augmentation work to be carried out under our next contract.
The video capability offers additional flexibility in the images that may be presented on the screen.
For example, in the conferences mentioned above, live television pictures of the people and equipment involved were freely used, both alone and after being mixed with computer-generated images.
This, also, will b-e 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. Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
Another potential use of the video is the viewing of microform documents.
Many systems are now available that use closed-circuit television far the storage, retrieval, and viewing of microform documents., and we expect this kind of system to become more prevalent in the future.
We already have plans for experimenting with various switching techniques in our display-distribution system, and the inclusion of provisions for microform viewing would require very little additional effort.
b. NLS Consoles
(11 ConsoleDesign As mentioned above, the use of video for displays allows considerable flexibility in console design. We have experimented with many arrangements over the past few years and are now using the three basic designs shown in Figures V-l, V-2, and V-3.
(2) Keyboards
The keyboards in use have gone through several stages of design with special attention to touch and layout. They now have a key force of 80 grams and a good "feel." They are well accepted, and we find that new users rapidly accommodate to the locations of special keys such as command accept and backspace.
(3) Mouse
We find that the mouse is still the most convenient locating device for our purposes. It is describedin Ref. 7, along with some experiments in the use of variousselection devlces. Available commercially, it is now used on other systems as well as our own.
(4) Keysets
The keysets in use were designed with special attention to "feel." Tolerances on the moving parts aro very close to give smooth, positive action. Key FIGURE V-1 "HERMAN MILLER" CONSOLE. This console,designed in cooperation with Herman Miller Research,was first used for theFall Joint Computer Conference in 1968. The keyboard-keyset-mouse unit is attached to a swivel chair, with the TVmonitor on a separatestand. It is a littleconfining to many people and the limited space for operatingthe mouse is an annoyance.However, it is reasonably comfortable and is useful for meetingsand demonstrations because the usercan turn and be partof a groupwhile working. FIGURE V-2 ONE-PIECE CONSOLE. This console,designed abouttwo years ago, basically a table on wheels with the TV monitormounred at a suitable angle for viewing. Both sides of the table have pull-out shelves for mouse,keyset, and working papers. This console now seems toorigid to most users.The TV monitor is too close for some,and there is not enough extraworking space fornotebooks andpapers. FIGURE V-3 CURRENT CONSOLE DESIGN.This consoleconsists of a small table with integral keyboard. Connectors for the mouseand keyset are immediatelybehind the keyboard. The TVmonitor is on a separate stand. The table stands low, placing the keys at a convenient level fortyping, and other tables can be placed on either side for additionalworking space. This arrangement is very flexible and allowsplenty of working space as needed. It is particularly good for groupcollaboration, since themonitors maybe turnedfor better group viewing, and entire consoles are quickly moved intodifferent working arrangements as needed.
139 Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
spacingand size approximate those of a piano.
c . Printerc.
We value a high-qualityline printer that produces upper-and lower-case alphabetics and a full complement ofASCII symbols. The one now in use is a DataProducts modelM600-llA. which has been very reliable and maintainshigh-quality output.
We normallyuse specially perforated paper along with ouroutput-formatting programs to produce hardcopy, completewith pre-punched holes, which is ready to be insertedinto a standard8.5~11 three-ring binder. This featurehas been enthusiastically accepted and is of particularvalue in the production of reports and other documentation.
d.Software Architecture
Theoverall architecture of oursoftware systems is describedbriefly in Section 11.
Theuse of a compiler-compilerto augment the development of a versatileset of special-purpose languageshas proved quite valuable in facilitating debugging,rapid modification of existing features and additionof new features, and orientation of new programmers.
Ourefforts to use higher-level languages wherever possibleshould result in additional payoffs when we transferour software to a newcomputer this fall.
e.The On-Line System
NLS hasbeen evolving for manyyears and has proved its valueboth as a toolfor bootstrapping its own evolution andas a flexiblelaboratory for developingexperimental workingmethodologies (see, for example, Section 111).
3. Problems
Themajor problems we haveencountered in developing our systemstem from four basic difficulties: Sect ion V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
(1) Tryingto fit a verylarge operational system into hardwaretoo small to support it
(2) Usingan available timesharing system that has provedinadequate for our purposes
(3) Developingtoo much special hardware with the associatedproblems of unreliability and missed schedu I es
(4) Unreliability of somecomponents of the facility, particularlyfile storage devices.
a.Hardware Limitations
Limitationsimposed by both the hardware configuration andthe timesharing service system have resulted both in worseresponse and in the ability to handle a smaller numberof on-line users than we had expected.
Moreover,this has resulted in the necessity for expendingmore resources on programming the service systemthan we had originally anticipated, and our plannedwork on evolving the user system has suffered accordingly.
We originallyhad hoped to be able to serviceten on-line NLS consolesat a time, but wenow findthat onlyfive can be operated with reasonable response to theusers. The primary factors affecting this response timeare swapping (core-drum transfers) and file 110 (core-disctransfers).
Toanalyze tactors affecting the response of the timesharingsystem, we developed a highly parameterized,discrete simulation model of the system(Ref. 17).
Thiswas used to evaluate the impactof changes in thehardware configuration, such as faster drums Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
or largercore memory, as well as the effect of variousmixes of user demands.
Changesin the scheduling and swapp.ing algorithms werealso tested in thesimulation, with the resultsbeing subjected subsequently to experimentalverification.
Themajor hardware limitations of the facility are the maximumcore available (the 940 canaccommodate only 64,000 words),and the limited address space available (aprogram can address only 16,000 words).
Maximumcore limitation results in the swapping bottleneckmentioned above.
Limitedaddress space requires an overlay structure inordinatelycomplex for a programthe size of NLS.
Thismeans that programmers must expend a great dealof energy designing overlay structures and areconstantly running into problems of full overlaysas the system is expanded.
This factoralone probably increased the cost of programmingthe system by ten to twenty percent.
In retrospect, we recognizethe error in the following designdecisions:
Thedecision to refresh displays from main core memorywas a badone. Memory bandwidth isno problem,but tying up the memory with displayimages (whichrequire "frozen" pages of core) reduces the spaceavailable for 'programs and makes the swapping bottleneckeven worse.
Withthe present system design, providing feedback to a userrequires that a programunique to each user be swappedin for every character of input. A different approachmight have consolidated some of the interactivefeed'back, thus reducing the swapping requirements.
b.Timesharing System Defects
Thetimesharing system obtained for use on our computer Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
hasbeen another significant facility limitation. Although this timesharingsystem was one of the most sophisticatedavailable at the time we acquired it, it hasproved itself inadequate to provide the service whichwe must have.
Partly this is becausethe designers of the system did notanticipate accommodating programs as large as NLS. We areconstantly running into size limitations built intothe assembler, loader, and debugger.
Anotherproblem is that weare the only people using this timesharingsystem for an application like NLS and, therefore,have had to carry on alone its maintenance andevolution.
Therestill are many bugs in thesystem that would be totallyunacceptable if wewere not a research-orientedorganization with f-ewnaive users dependenton the system for service.
Someof these bugs have been known about for two years or more,but higher-priority demands on our programmers'time have always prevented us from locatingthem. With transferto a newcomputer now imminent,we plan to live with them a littlelonger ratherthan wasting valuable energy trying to fix themat this time.
c.Problems with Custom-BuiltHardware
Muchof the hardware in oursystem has been custom built toour specifications, either by our own staff or under contract.
We havebadly underestimated the resources needed for constructingsome of this hardware, the results being missedschedules,, failure to meet specifications (for thedisplay system in particular),and high maintenance costs.
Inputting together an experimental facility for augmentationresearch, we now see the desirability of restrictingspecial hardware development to those areas mostdirectly associated with userfeatures -- e.g. user-consoledesign. Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
Whereverpossible, use should be made of commercially availablecomputers, interface devices, display-generationequipment. etc.
d.File-Storage Device Unreliability
Fileunreliability has also resulted inconsiderable loss oftime to both programmers and otherusers.
Althoughthe disc-file system we are using is quite goodwhen compared with others in the computer field, adequate file backupfeatures were not incorporated intothe system design.
Thismeans that users must either go through elaborateprocedures to keep several copies of importantfiles 3r occasionallysuffer significant lost time when a filegoes bad.
Until file storagedevices are much more reliable than thosenow available, sophisticated automatic backup facilitiesshould be designed into any system.
4. MaintenanceExperience
a.Genera I
Generalreliability of thefacility has been good. Computerup-time has been high, although the reliability of thedisc-file system has been only fair.
We had a period of severalmonths of above-normal errorrate, with five days down while clock tracks were rewritten.
Thechain printer we originallybought had marginal printquality, was unreliable, and wehad difficulty gettingsatisfactory maintenance service.
Consequently, we havereplaced the unit with a Data Productsdrum printer that has 96 printingcharacters perline with upper- and lower-case alphabet. The printquality is excellent (witness this report), and so far it hasbeen fairly reliable. Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
b.Display System
We havespent more effort on maintenance of the display systemthan on any other part of the facility. Since our displaysystem is somewhat unusual, we will discusssome ofthe problems encountered in SO faras they reflect considerationsrelevant to the design of other similar systems.
(1) Onebasic system limitation has been the inability of thedisplay-generator CRTs to produce adequate light forthe vidicon pickups. This means that many elements ofthe display system are operating at marginal levels.
Thedisplay-generator CRTs must be run at such high intensitythat their life is relatively short.
Thishigh intensity also causes difficultiesin maintaininggood focus over the entireimage.
To operatewith these low light levels, the vidicons mustbe quite sensitive; since sensitivity drops off withage, they, also, have a relativelyshort useful I ife.
(2) Becausethe writing speed of thedisplay generators islower than we had specified, wehave a flicker problemwhen all six screens on the system in use are reasonablyfull of text.
We cancompensate to some extent for this flicker by carefuladjustment of the vidicon beam current and target,but this adjustment needs frequent attention.
We haveconsidered using longer-persistance phosphors onthe TV monitors and will experiment with this in thenear future.
(3) In additionto these difficulties there are some basicweaknesses in boththe display generators and the televisionsystem which could be corrected in future designsby more careful attention to component quality controland the inclusion of circuit-design and layout featureswhich would facilitate maintenance. Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
C. Our GeneralOrientation Towards Future Research
Overthe years we have frequently been faced with the problem ofattempting to explain to people outside of ARC justwhat ourOn-Line System (NLS) is.
It is usuallyfairly easy to get across the idea of augmentationin the abstract, but it ismuch more difficult to conveyto people who have not made extensive use of NLS justhow powerful it isas an augmentation tool -- it is veryeasy to get trapped into looking at NLS as just a nice text-editingsystem without seeing all the power that residesbehind that particular aspect of its surface appearence.
Recentlywe have developed a wayof looking at NLS whichhelps to conveysome of thepower that we know is present, and that is to view NLS as a worker'son-line "office" -- that is, his normal,daily, local working environment. The analogy follows fromthe observati.on that to a naivevisitor an office can looklike just anoth.er "room," butto the person who uses that office it servesas an interface to many of the capabilities ofan entire organization.
Theoffice serves as a placewhere a personcan work at organizinghis ideas, studying correspondence, reports, etc.,and formatting his own written materials. The office hasassociated with it communicationlinks such as mail and telephoneas well as acce5.s to secretarial and clerical servicesthat are used on a dailybasis.
Thissame sort of picture can be applied to NLS, for it is usedon a dailybasis to help with organizing, studying, formatting,etc., and provides now, or soon will provide, manyof the other communication and clerical services normallyassociated with "office work."
NLS alsohas many similarities to an office in theway that bothact as interfaces to extensive external capabilities.
Justas one would not expect to find complete publication, laboratory,library, and filing facilities in theaverage office,one should at present not expect any single augmentationfacility such as NLS toprovide all the computationalfacilities that a personmight wish to call upon.But, in the 5am.e sensethat a personshould expect tobe able to access extensive organizational resources
146 Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
from his office,he should be able to access extensive computationalresources from an NLS-like facility.
For example, NLS providesall the capabilities needed for constructing,studying, and editing programs in any of severallanguages; however, the facilities for printing, compiling,archiving, etc. are not considered to be integralparts of NLS andmust be activated as "external processors"by the. NLS user.
Similarly, wehave plans for implementing vari.ous message transmissionand information-retrieval systems as external processors, so thatall the formatting of input to these systemsas well as the studying of the output from them can bedone using the powerful NLS mechanisms,while the actual processingcan be carried out by independent programs runningas background jobs on our timesharing system -- or evenby programs operating on computers at remote sites.
Thisoffice picture is very important to unde.rstanding how a researchcenter such as ARC can make the most effective use of theresources of a networkof interconnected computers such as theARPA Network described in SectionIV.
We anticipateth.at whenever we plan to make extensive use ofthe resources of a particularnode of theNetwork, we will addfacilities to NLS so that it canbe used as an interactiveinterface with thoseresources.
For example, if wewere planning to use an information-retrievalsystem at some other site, we would makeprovisions for the following:
(1) Permittingthe retrieval requests to be formulated usingregular NLS techniques
(21 Translatingthe request from our syntax to that requiredby the remote system and transmitting the reformattedrequest out over the Network
(31 Receivingthe response from the remote site and, finally,translating this output into a properly formatted NLS file so that it canbe viewed and manipulatedusing tools already familiar to the ARC staff.
Thisapproach appeals to us because it promisesto permit a Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
member of ourresearch community to use subsystems running atwidely distributed computer facilities without learning a newset of conventionsand user techniques for each differentsystem. We believethat this way of viewing the roleto be played by an organization's local computational facility will becomemore widely accepted as computer utilitiesand networks proliferate.
Whenorganizations become able to access a powerfuland varied collectionof resources merely by interfacing their local facilitiesto a network, it will becomemore generally recognizedhow wasteful it isfor each local facility to designand implement all the computational capabilities it needs.
It islikely that various computer "utilities" will evolve to servethe needs of large communities of users for specializedon-line services that cannot be provided economicallyat the local level.
Bytaking advantage of the load-leveling that results from serving a largenumber of customers, utilities could developservice facilities to fill theneeds for large high-speedcalculations, archival fi!e storage, searches overlarge data bases, etc., with very good average responsetimes and at relatively low cost.
Bringingthe dispensing of specialized computation services intothe "market place" provided by resource distribution networkscould foster competition that would both acceleratedevelopment of thiskind of serviceand make possiblesignificant reductions in the cost of computationalservices in general.
Inthe context of thiskind of development, individual researchcenters such as ours will berelieved of much of the chore of implementingand maintaining the basic service capabilitiesnecessary for daily operations.
Thischore, now duplicated from center to center,consumes anexcessive portion of our collective resources. Effectivecomputer networks should permit computer science researchersto reduce this duplication of effort so asto increasethe rate of progresspossible with available professionalmanpower and computational resources.
Theseresearch groups will thenbe able to focus more
14-8 Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
energyon the problems that they are particularly well-equippedto handle.
Inour case this might involve basic research to find themost satisfying ways to interface a specific communityof user.s to a networkproviding general capabilities,while other groups could apply their talentsto areas of interest such as mathematical manipulation,computer graphics, and so on.
Thisconsideration becomes particularly important when one realizes,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 developmentcapabilities of any one research center such as ours.
Incoming years, we believe that significant developmentsin the computer sciences will comeabout moreand more as a resultof the cooperative efforts of manyresearch centers, each working on particular aspectsof augmentation.
Thepreceding comments should convey some feeling for the powerthat we feel is inherent in a networkof research-orientedcomputer centers and provide a background for understandingour enthusiasm for participating in the ARPA Network. We believethat being a partof the ARPANetwork will bevaluable to us in achieving the goals of augmentation researchfor several reasons.
(1) It will giveus experience in working with a community ofresearchers more varied and widely distributed than our ownteam of staff members.
This will permitus to gain additional insight into the validity of ourapproaches to augmentation research by observinghow and to what extent our facilities can be of service to computerusers who are not captive members ofour local research community.
(2) Networkparticipation will provideimpetus for our efforts in thedirection of team augmentation by creating a communityof researchers who are working on different aspectsof a commonproblem at widely distributed geographicallocations and who need new tools and Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
techniques for communication and cooperation to succesfully achieve their common goals.
By working with such an extended community, we will be able to set goals and priorities in our research program more knowledgeably than we would be able to do if we were limited to augmenting only teams working in our own Center.
(3) As mentioned above, we at ARC have come to realize that attaining the goals of augmentation research on a reasonable time scale is a task far beyond the capabilities of any one small research center such as ours, and we are very optimistic about the possibility of achieving a significant acceleration in the progre'ss of augmentation research through network participation with other research centers having similar goals.
D. Overview of Current Augmentation Research Center Plans
1. General
a . Introductiona.
The previous section should give the reader some feeling for the forces that have been shaping our plans for futureresearch. Internal forces have comb,ined with those generated by our Network participation to produce a shift in our research emphasis in the direction of two generalactivities:
(1) Researchon team augmentation
(2) Development of a system design discipline.
In addition, increased awareness of our need to communicate and interact with the outside world is leading us into the development of a new area of specific concern, discussed below under "Transfer of Results."
b.Team Augmentation
Whereas in the past we gave most of our attention to augmenting the individual worker, we are now focusing on the augmentation of a team of collaborating workers, each of whom is individually augmented. Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
Thehigh mobility and manipulative capability of a skilled"augmented individual" has a uniquepotential whichcan be most fully realized when a number of augmentedindividuals join to form a collaborativeteam.
Notonly can each individual move very rapidly throughjoint working files to study them, enter new information,and update old material, but the group processes of intercommunicationand coordination can befacilitated by special computer aids, conventions. andtechniques.
Thecontemplated efforts in "teamaugmentation" involve thedevelopment of several facets:
(1) Conventionsand procedures for organizing the workingrecords of our plans, designs, objectives. designprinciples, and schedules to give members of a teameffective mutual "task orientation" by making allinformation related to the team's objective optimallyaccessible.
(2) A "DialogueSupport System" to facilitate rapid evolutionof these working records through dialogue amongmembers of the design team.
(3) Techniquesto facilitate simultaneous collaborationamong people at physically remote on-lineterminals by giving them direct communication with oneanother, independent of their current individualwork interactions with the computer. This includesprovision, where feasible, for the following:
(a)Video and/or voice intercommunication
(b)Easy and flexible control of means for duplicating,at any terminal, all or part of the type-out or display-fromanother terminal
(c)Ready transfer of control of one terminal's computerinteraction to anotherterminal's input devices.
(4) Specialmanagement and system-building techniquesfor use by an augmented team, and
I Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
provisionof applicable technical intelligence and usertraining capabilities.
Thesetechniques are expected to evolve within ARC under conditionsof use in our owncoordinated system-developmentwork, and to be applied over a wide rangeof collaborative actions, from simple question-answeringfacilities to complexdesign work involvingintense mutual participation by team members.
As applicabletechniques become effective within 4RC, we will exploretheir value for thefollowing:
(1) Supportof Network Information Center (NIC) servicessuch as teaching, question-answering and sometypes of query servicing
(2) Workingcollaboration between ARC staffand personnelat other Network sites
(31 Workingcollaboration between people at remote Networksites, independent of ARC staff.
c.Development of User- and Service-System Design Disciplines
Thefunctional features of the"user system" -- the collection of computeraids available to an ARC worker -- haveevolved with some ingenuity, a greatdeal of cut-and-tryexperimentation in actual-usage conditions, and a certainspecial orientation offered by our overall researchframework. Until now, however, there has been a significantlack of objective,methodical eng.ineering design in thedevelopment of theoverall user system.
A user-systemdesign discipline is definitely needed, andwe intend to devote an increasing amount of efforttoward developing such a discipline.
Likethe user system, the "service system" -- the hardwareand software underlying the features for augmentingusers -- hasevolved in an ad hoc fashion.
Herethere is also a significantneed for a system-designdiscipline.
Suchsystem-design disciplines would have communicable, Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
teachable, and generally applicable frameworks, supporting coordinated sets of concepts, terminologies, principles, methodologies, and special tools.
d. Transferof Results
Behind these basic aspects of our work in the ARC (team augmentation and design disciplines) lies an essential feature of our long-term strategy, namely, the goal of producing results that wilt be of direct value to other groups of system developers -- in particular, to those who will be developing augmentation systems.
This is in contrast with being of direct value to customers who want systems for their own direct use " e.g., to augment a manager, a designer, an editor, or a scientist.
Display terminals, communication channels, and computer service are destined to become both cheap and plentiful, and it is certai.n that a very large number of organizations will want to use them. They must rely upon system developers who should be capable of the following:
(1) Analysisof system-usage environments
(2) Designand implementation of a smooth,powerful, and coordinated system of user aids, conventions, and methods
(3) Trainingand "education" of users unfamiliar with the potential of this new technology
(Lf) Subsequent monitoring of user performance so as to implement the changes necessary to track the evolution of users' attitudes, concepts, skills, usage habits, and wants.
Although it is important for us to stimulate the eventual customers for augmentation systems by making them aware of the potential for these systems in their work, we feel that our results should be directed primarily towards helping system developers. We plan to do this by pursuing the following long-term goals:
(1) Makingvisible an advanced, integrated system, Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
operating in a heavy-usage environment, that can orient system developers to the available costlbenefit tradeoffs
(2) Developing an effective system-design discipline to aid in developing augmentation systems, whether or not these systems resemble ours
(31 Maintainingthorough, highly current, comprehensive documentation, designed for quick location of relevant material
(Lt) Establishing wide-band communication channels over which a dynamic interchange of information can take place, so that the maximum amount of our knowledge can be quickly available in useful form
(5) Offering a complete prototype design of an augmentation system especially designed for augmenting system development.
This system would be compatible with the system-design disciplines described above, and would include techniques for planning, analyzing, designing, programming, debugging, documenting, and teaching.
Our current approach to implementing the transfer of results discussed above is to plan for what we call the System Developer Interface Activity (SYDIA). We expect to approach representative candidates during 1970 with proposals fo.r multiplesponsorship. The initial purpose of the SYDIA will be to develop the following:
(1) A facility for an effective interchange of information and skills between ARC and the existing and potential community of augmentation-system developers
(2) The ability to assist other groups in transferring our system, or parts of it, directly into other hardware and user environments.
Later, with specific individual funding arrangements, we expect to begin developing close interchange relationships with various system-development groups who Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
couldadapt our augmented techniqucs to their own system-developmentwork.
2. TeamAugmentation Research Plans
a . Introductiona.
We havealready discussed theevolution that has been takingplace in thegoals ofour research program.
Havingmade significant progress towards realizing theobjective of augmenting the individual intellectualworker, we find that the greatest augmentationneed evidenced within our own Center at thepresent is for developing tools that will facilitatecollaboration among members of a project-oriented or problem-solvingteam of augmented individuals.
It isnot that we havealready accomplished our originalobjectives and feel that we can now turn ourattention elsewhere, but that team augmentation -- seen in thelight of our bootstrappingstrategy -- offersthe greatest promiseof hastening the eventual realization of thesegoals.
We viewthe "augmented team" as a groupof workers sharing a commonbase of working files and using the mechanicalelements of theiraugmentation system as both a mediumfor goal-related communications and a laboratoryfor carrying out relevant experiments.
Atpresent we are most interested in exploring the possibilitiesfor augmenting the activities of teams whosepurpose is the development of advanced computer systemssuch as our own.
We feefthat this is a profitableway of investing theresources with which we areentrusted, not only fromthe standpoint of our bootstrapping orientation, butatso because augmentin.g this type of team now is mostlikely to have the greatest payoffs in thelong runfor society as a whole.
Overthe past year wehave identified a set of basic Section V CONCLUSIONS,RECOMMENDATIONSl AND PLANS
capabilitiesthat seem to meet the major needs of the augmentedsystem-development team.
Thefollowing description of these basic capabilities canbe viewed as representing a frameworkfor the system-developmentactivity that must takeplace in theprocess of designing and implementing systems to realizethese capabilities.
It alsoindicates, indirectly, the nature of other relatedactivities that will beconcerned with integratingthese capabilities into our working methodology,applying them directly to the operation ofour Center, and analyzing their effectiveness so asto provide direction to subsequent developments.
b.Fast Editing and Publication
Ouralready fast computer editing techniques will naturallycontinue to evolve, and we are in theearly stagesof developing .a powerful"Output Processor" capability.
TheOutput Processor is envisionedas a coordinatedset oftechniques for producing hard copy through a variety ofmedia, such as microfo.rm and direct publication on paper,using conventions that are compatible with those bywhich the associated file material can be studied and manipulatedon I ine.
We planto concentrate early upon automatic production, fromour on-line files, of hard copy in which one can veryflexibly cpecify the composition of text,diagrams, tables,equations, footnotes, indices, etc.
Duringthe production process, such operations as convertingintrafile links to page references and interfilelinks to footnotes would be performed automatically,with associated conversion tables beingsaved for future use.
Oneof our goals for thenext few years is to develop a systemcoupling a typewriter-likecomputer terminal with a microformreader that can be positioned to any page withinits "library" upon direction from the central computer. Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
This systemwould use conversion tables generated by theOutput Processor during publication of the microformlibrary to drive the reader in responseto directionsfrom the user. This wouldgive the user much of thepower for studying large bodies of interreferenceddocuments that currently can be obtainedonly through the use of a display-oriented systemlike NLS.
c. Plexdocsc.
A teamtackling a complexsystem-development project mustprovide itself with the highest possible visibility overits working environment -- i.e., over the following:
Planning:plans, contingency alternatives, resource commitments,status, criticisms
Designing:designs, design principles, constraints, estimates,analyses, supportive data, relevant needs andpossibilities
Operating:roles, task definitions, assignments, policies,operational procedures and conventions.
We currentlyhave quite powerful techniques for aiding anindividual or smallreport-writing team in producing documentsof the usual research-report size and complexity.But in our approach to team augmentation, we consider it essentialto expand upon these techniques so asto facilitate the development and production of verylarge, very complex documents containing many detailsthat are highly cross-dependent.
We usethe term "plexdoc" to denote the concept of such a complexdocument, which would, in fact,be composedof a possiblyquite large collection of NLS files,cross-linked in complicated ways.
Thestem "plex" comes from theLatin "plexus," whichmeans woven or intertwined, and supports the image of a bodyof information that has been woven into a coherentfabric by a groupof people throughthe use of specfal indices, footnotes, reader-contributedcomments, specific cross-references,etc. Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
We intendto develop and keep up to date a large, detailed,highly cross-referenced and well-indexed "plexdoc"that contains a descriptionof our own project-teamactivity fulfilling the needs listed above. Ourtechniques to facilitate its modification and republication will beunder constant evolutionary pressure.
d.Dialogue Between On-Line Collaborators
(1) TheDialogue-Support System
On-lineaccess by collaborators to each other's files,as provided by a number of today'stimesharing systems,leaves much to be desired in supporting effectivedialogue.
In thiscontext, weuse "dialogue" torefer to the incrementalbuilding up of a group expressionof ideason any given subject through theaddition of "comments"to some set of relevant files.
We areattempting to meet the needfor more flexibleand powerful means of facilitatingsuch dialoguethrough the development of a "dialogue-supportsystem," which we consider an essentialelement of anyteam augmentation system.
Thedialogue-support systemmust function smoothly in conjunction with the plexdocconventions to provide capabilitiessuch as aredescribed below.
(21 Commenting
Anyteam member working at a displayconsole must be ableswiftly to access for studyany portion of a plexdoc'sstructured files, and he must be able conveniently to addhis contributions to the on-going dialoguethat is contained in these files.
Wheneverhe wishes, he should be able to introduce commentsthat are freely sprinkled with explicit referencesto any specific item (character, word, statement,line, curve, box., expression, etc.) within anyprior entry -- asthough he were pencil-marking a paperdraft with marginal Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
comments,underlines, encircled passages, arrows, andthe like.
Whencreating a commententry, he needs flexible aidsand methods for thefollowing:
Arrangingdisplay of the various passages he is referencingrelative to the content of the commenthe is creating
Designatingthe explicit entities he wishes to reference
Havingthe current comment-creation state preservedtemporarily while he checks on some relatedmaterial.
Thismust be managed by the computer so that it does notmatter if otherpeople are concurrently scanning thesame material or affixingcomment references to thesame items.
Hisstudy techniques should enable him flexibly to selectwhich comments. will be displayed for him and whichones will remaininvisible (or whose presence will bemade known to him without appearing in their entirety). For example,he may wish to be aware of onlythose comments that reference a givencitation in a text,term in anequation, or labelin a diagram.
Hequite likely does not want to see reference indicators for allsuch prior comments, so he needsflexible mechanisms for specifying which are tobe visible -- e.g.,by author, creation time (relative or absolute),specific content, prior-assignedcomment-set membership, author-affixedcategory designations, etc.
Also,whenever he sees indication that an interestingtype of comment is associated with someitem in thestudied passage, he needs considerableflexibility for designating how he will beshown such select.ed comments relative to Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
thereferenced material -- forexample, in oneof thefollowing ways:
With a splitscreen (original reference text on theleft and comments on the right)
Commentsenclosed within boxes and the boxes embedded within theoriginal text
Abilityto "flip" between views of the referencematerial and views of the comments, etc.
(4) Notification
Provisionsneed to be developed to enable setting up "annunciatorcalls" to various people, or setsof people,to request their special attention (at some levelof priority) to a givencomment. This might callfor actions such as the following:
(1) Anapproval signoffto record the fact that thecomment has beennoted by the party or parties towhich it was addressed
(2) Somekind of special vote, automatically talliedand recorded on the annunciator specificationin that comment
(3) A needto observe a "pointof order" in the specialmethodology the teamhas adopted -- e,g.:
"I protestthis decision and call for a review, citingPolicy X, relativeto Budget Item Y and DesignPrinciple Z."
(5) Retrieval
Alldialogue entries immediately become part of the plexdoccontaining the complete working records (and muchof the history) of theaugmented team. Since commentsand other working record entities can refer toeach other in indefinite extension, it will be possibleto build up a verycomplex network of relationshipsamong these comments and the substantiverecords about which the dialogue is swirling.
160 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
Although these relationships need never be ambiguous, it will be difficult for even a knowledgeable team member to keep track of them in such a way that he can effectively' "navigate" through the plexdoc to follow all the relevant developments that may be taking place concurrently.
This is about the toughest central challenge in effectively augmenting a team -- that of developing computer aids, working methods, etc. to allow a skilled person to be highly effective in digesting the content and implications of such a record, and to develop a substantive next-stage design or plan that integrates the dialogue contributions.
Essentially similar techniques are required to augment any individual's central intellectual capability for synthesizing the next stage of development in plan or design -- and to the extent that we are successful with this, we should be able to offer strong guidance for capability augmentation over wide ranges of individual and team activities.
Our initial activities in response to this problem will be in the direction of providing powerful retrieval tools that will enable a user flexibly to specify, by content, which elements of the plexdoc are of greatest interest to him at any moment.
We also have plans for developing techniques that will permit a user to construct specific indices and catalogues over a given plexdoc and to create and manipulate arbitrary "sets" of entities that are of immediate interest.
Many of the tools developed to fulfill these rteeds will also receive extensive use in other ARC activities such as the Network Information Center.
e.Distributed Dialogue
We consider it important for people other than the central, highly trained, display-equipped team to participate 3s well as possible in dialogue of the type discussed above.
161 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
We seek to provide capabilities that function effectively over the widest possible range in sophistication of computer, communication, and terminal facilities and in level of experience and training of the individual users -- and with as much independence as possible of geographical location.
As a first step we intend to work on the problem of developing organization and formatting conventions for presenting plexdocs for study on devices other than our centrally located selective-view displays.
We assume that for significant participation via any type of coupling 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 republished relatively often (e.g., weekly or even daily).
We are already working on mechanisms for producing high-quality hard copy in both paper and microform (as described above under "Fast Editing and Publication").
Our goal is to be able automatically to publish reference material (probably in microfiche) in such a way as to make feasible a frequent-republication operation servicing a moderate number of remote participants.
We have also begun to investigate many different kinds of remote printing devices and are particularly excited about the high-speed, high-quality, scan-driven hard-copy devices now appearing on the market.
Ne also are investigating techniques for allcwing a remote affiliate, such as a participant at one of the other ARPA Network sites, 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 provide computer aids for locating items of interest and following the various kinds of cross-reference links.
A next step (nearing operational status) is to provide facilities for direct, on-line, dialogue participation
162 Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
usingTODAS (our Typewriter-Oriented Documentation-Aid System). We aregiving this specialemphasis so asto providefor early access to Network Information Center files.
We areactively pursuing an extremely promising possibilityassociated with an emerging line of microfichereaders that can be operated under direct computercontrol and which permit jumping to any frame of a fichein a fractionof a second.
Mostof these readers also allow jumping to anyfiche within a cartridge, or evento any cartridge within a largerstore, in times comparable to those we currentlyexperience in studying files on line using our d i sp I ay system.
Such a reader,loaded with updated cartridges from us,where the reader and a typewriterterminal both connectthrough the Network to ourcomputer, can provide a personwith very powerful help in his plexdocstudying.
Hewould be able to follow links, jump to an index andfrom there to selected points, jump successivelyto the candidate selections produced by a retrievalquery, indicate where he wants to direct a commentreference (via typewriter entry ofhis comment) -- allvia quick directions on the typewriter,abbreviated by cues (which the computerknows about) that he sees on the screen ofthe microfiche reader.
In someapplications a frame-jumpingmicrofiche reader/typewriterterminal system could be quite competitivewith our high-response, on-line displayconsole system, and we are very interested in developingexperimental versions of such a systemfor exploratory use in theNetwork InformationCenter.
f. ConferenceDialogue
Theteam augmentation techniques we have discussed so farare all directed at aiding team members working at individualcomputer terminals. Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
There are times, however, when such a team will wish to convene as a whole to review some new proposal, debate a pressing issue, or collaborate actively in some particular phase of their work.
The "complete" team augmentation system must provide mechanisms for facilitating this kind of conference dialogue activity.
We already have experimented with using NLS as a sophisticated "blackboard" where one person can make a presentation io a group seated within viewing range of one of our regular NLS consoles. This gives new power for presenting material and answering questions as well as providing a very flexib-le medium within which the record of the discussion can evolve.
In cases 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 additional "slave" monitors at convenient locations.
At two of bur major conference presentations (see Section 111-E) we have used video projection equipment to allow us to give live demonstrations of our on-line system.to large audiences, and we are planning to purchase slmilar equipment for use in conference augmentation experiments at our own Center.
The next step along this avenue of research is the development 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 experimented 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 restricted to merely positioning a personal bug-mark on the display, each using his own mouse.
With the evolution of multiple viewing windows, a flexible voice intercom system, and other techniques will come opportunities for more sophisticated forms of interaction; and we are optimistic about the
164 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
possibility of achieving significant increases in team effectiveness through advances in real-time dialogue augmentation.
Further down the road, we see a real need for developing techniques that, without requiring an extensive training period, will extend the ability to participate effectively in augmented conferences to individuals with little experience in 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-line vehicle.
g.Voice Dialogue
We hope to begin experiments in the near future using techniques for the digitization of normal speech strings, developed by Glenn Culler while he was at the University of California, Santa Barbara. Our plans are to modify NLS so that a "statement" can contain not only the present text and/or graphic material but also a digital representation of a speech string.
Then, with only minor changes to NLS, we would be able to provide techniques for breaking long speech strings into shorter ones, hierarchically organizing them, and providing cross-reference links between voice strings and normal text.
These capabilities will permit US to integrate actual spoken dialogue into the dialogue mechanisms previously discussed, providing an extremely powerful addition to our repertory of team-augmentation techniques.
They would be of great help to remote dialogue participants -- or even to our own staff when away from the office -- since phoned-in comments could be integrated into an on-going dialogue record, and they open new doors in the realm of conference augmentation as well.
Moreover, the anticipated gradual evolution of speech-processing techniques will provide increasingly powerful benefits from this voice dialogue approach. Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
h. TechnicalIntelligence
Tosatify our own needs as a researchteam, we have been accumulatingfor many years a significantcorpus of ”intelligence”(bibliographic) data about activities and productsof organizations outside our own that are involved in relatedwork, and we have committed ourselvesto shaping up this collection in orderto provideat least parts of it (properlycatalogued and indexed)to other groups, particularly NIC users.
In additionto maintaining an up-to-date collection of standardbibliographic items, we plan to expand into new areasthat are specifically related to the needs of system-developmentteams. We intendto begin seeking outand co1Iectin.g data such as the following:
(1) Characteristicsof, and user experience with, variouscommercially available and custom-made system e I ements
(2) Referencematerial and’user commentaries on externallydeveloped systems and techniques
(31 Intelligenceon the status and results of related workby other groups.
We havebegun development of a flexibleset of information-retrievaltools that will beused extensively in themaintenance and interrogation of our intelligencecollection as well as in the management of ourcomplex working records (as discussed above).
i. UserTraining
With anyuser-oriented system as complex and versatile asours, there is a continuousproblem in helpingnew usersto attain competence in operating the system so as toobtain the maximum benefits from it. Thisproblem is magnifiedmany times when users can work from many widelyseparated sites, making it impossiblefor them to receivepersonal help from experienced staff on a minute-to-minutebasis.
With a systemevolving as rapidly as ours, it is difficultto keep even the central staff informed of allnew system features and special methodologies.
166 Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
We aremaking some progress in thepreparation of trainingand reference materials for our user system, butthere remains much to be done, not only in actually providingsuch materials, but in discoveringwhat forms ofindoctrination materials (films, video tape, introductorymanuals, reference manuals, brief reference guides,etc.) are most useful.
j. SpecialManagement Techniques
Themanagement of a technicallysophisticated problem-solvingteam requires the use of some methodologicaltechniques that are common to the managementof any organized group, as well as many othersof a morespecialized nature.
Thereneeds to be an accepted methodology for managing thefiles containing the team's working records so asto ensurethe most effective use of these files.
Effectiveprocedures need to be worked out for developingplans for the future activities of the team, fornegotiating and reviewing task designations and individualroles, and for allocating and accounting for theresources possessed by the team.
Finally,there must. be well-understood and accepted ways ofdefining, representing, and monitoring operational proceduresand of resolving conflicts between elements ofthe team regarding the allocation of resourcesamong theactivities of the team that must compete for them.
k.Special System-Building Techniques
In addition to thecapabilities described above, which arerelevant to the needs of all problem-oriented teams, thereare some considerations that are uniquely applicableto a teamwhose domain is system development.
Thesystem-development team needs to have a consistent, if notcomplete, set of principlesfor designing the overallsoftware-architecture of interactivesystems.
It must developan understanding of the principles underlyingthe design and analysis of interactive systemsfrom the standpoint of userservices. Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
It must have effective techniques for training new users of the systems it has implemented and for generating useful reference materials for these systems.
It must have flexible methods for obtaining and analyzing performance data on a system. It should have powerful ways for simulating significant parts of an existing system and for simulating newly conceived or modified systems in order to diagnose existing bugs, predict future performance under various conditions, and compare the performance of proposed system configuratons with that of the existing one.
Finally, it must have highly augmented techniques for creating, compiling, and debugging the huge collection of programs used in the implementation of a large software system.
3. Development of System Design Disciplines
a. Analysis and Design Principles for On-Line User Systems
Designing a whole augmentation system involves a balanced consideration of many factors, all of which are subject to reevaluation and change in response to increasedunderstanding gained through experience. The following are examples of such factors:
(1) Ways in which users conceptualize their working tasks
(2) Methods for representing and recording these concepts
(3) Procedures for developing the concepts and products associated with a given task (4) Forms of computer aids and utilization methodologies needed to obtain maximum help in carrying out such working procedures
(5) Usertechniques for negotiating service transactions with the system in various contexts.
At present there is no design discipline encompassing this range of interdependent system factors, but one
168 Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
really must evolve if anylarge-scale benefit is ever to bederived from the computer services that we clearly seecoming over the horizon.
By a "designdiscipline" we mean a coherent, communicable,generally applicable framework comprising a coordinatedset of concepts, terminologies,principles, methodologies, and special tools.
This designdiscipline must provide a commonground foranalyzing the needs of a communityof users, formulatingeasily communicable designs for systems tomeet these needs, and providing adequate controls overthe implementation process.
Thesecapabilities should make it possibleto offer clientsaccurate costlbenefit pictures prior to any extensivecommitment of resourcesand should make the designand implementation processes more efficient.
Considerthe predictable tremendous increases in speed, capacity,and economic availability of computational resources,and then realize how the quality of service representedby these resources can be enhanced through theapplication of ever more powerful artificial intelligencetechniques.
We consider it desirableto avert the possibility of all thispower being harnessed in waysthat leave these mechanicalhelpers remote and uninvolved from our minute-by-minutehuman activity.
We needto learn how to design such systems and how toadapt our thinking and working methodologies so thatquick little bits of service can be harnessed on ourown terms.
A significantchallenge is involved in findingways formatching these computer services to human perceptual,cognitive, and motor mechanisms so asto optimizeworking capabilities and provide a natural andsatisfying extension of human capacities.
Designof the repertoire of user services to be provided by a computer/communication/terminal facilityis a processrequiring the kind of coherent design discipline
I Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
associatedwith any complex system de.sign process, and weconsider the development of such a disciplinefor augmentation-systemdesign to be a vitalcomponent of our nextphase of research.
b.Software Architecture Principles for Interactive System Des i gn
(1) Overview
Justas important to us asthe development of a disciplinedealing with theanalysis and design of userservices is the development of a companion disciplinedealing with thedesign of software architecturefor interactive systems offering these serv ices.
Thesetwo disciplines are actually just opposite facesof the same coin and must be interfaced so asto form a singleoverall discipline that provides a unifiedapproach for going from user needsstraight through to integrated operational systemssatisfying those needs.
To organizethe conceptualization of such a system designinto appropriate levels and areas, and to developeffective representations of the design specificationsand principles at each such level, seemsnecessary if weare ever to transform interactivesystem design from an art into a profession.
Ourpresent software architecture approach stressesthese things and promises to make useful headwayin evolving conventions, procedures, and aidsthat could help other people approach and operateon the architecture of complexcomputer systems.
We describebelow some of the approaches that have evolvedin our work and which we feeloffer the foundationsfor a designdiscipline of the type we areseeking.
(21 Compiler-CompilerTechniques
Almostall our programming is done in some member of Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS
a whole family of languages based on our Tree Meta syntax-directed compiler (see Section 11-B-2-b and Ref. 17).
T'his technique provides us with great flexibility in f itting each programming task into a language P articularly appropriate to the requirements of that task, yielding more efficient use of vital programmer time as well as code that is sufficiently self-documenting to aid considerably both in the debugging of our system and in the orientation of new programmers.
(3) Format Conventions for Source-Code Language Files
A very important feature of these special languages is that their format and structuring conventions have been designed so as to fit particularly well into our augmentation-systemusage environment. This provides a very rewarding and powerful degree of facility for composing, studying, and modifying source code.
The plexdoc approach described previously has evolved from a belief that all levels of design and analysis thinking and data should be integrated into one compatible system of files over which the designers and supervisors, and later maintenance personnel, colleagues, etc., can roam freely and adroitly.
This approach has been applied to some extent in our present collection of system-program files. This collection forms a plexdoc by virtue of the fact that interfile links can be used as the arguments of procedure 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) SystemArchitecture Principles Fostering Evolutionary Development by an Augmented Team
We have begun to apply various modularization concepts to our working and thinking methodologies so as to foster the ability of individual members of our Section V CONCLUSIONS,RECOMMENDATIONS, AND PLANS
research/devalopmentteam to work effectively on specificaspects of our project with theleast possiblechance of destructively interfering with otheractivities.
Theseconcepts are also important to the way in which weview participation in the ARPANetwork. inthat weare seeking flexible ways of interfacingvarious modules of our own operating systems to computationcomponents available at othersites through the Network.
We alsoseek to exploit the properties of modularization to promotedesign clarity and facilitatetransfer of programs and techniques to othersystems and groups.
Theextensive attention to conceptual partitioning throughuse of a varietyof special-purpose programminglanguages is one example of this. Appendix A USER FEATURES OF NLS ANDTODAS
I TheOn-Line System (NLS)
A. Introduction
NLS, ascurrently implemented, is essentially a highly sophisticatedtext-manipulation system oriented primarily towardon-line use; i.e., it isnot primarily oriented towardproduction of hardcopy, although fairly sophisticatedhard-copy formatting and output are included in thesystem.
NLS is intendedto be used on a regular,more or less full-timebasis in a time-sharingenvironment, by users who arenot necessarily computer professionals. The users are, however,assumed to be "trained" as opposed to "naive." Thusthe system is notdesigned for extreme simplicity, nor forself-explanatory features, nor for compatibility with "normal"working procedures.
Rather, it isassumed that the user has spent considerabletime in learning the operation of the system,that he uses it for a majorportion of his work, andthat he consequently is willingto adapt his working proceduresto exploit the possibilities of full-time, interactivecomputer assistance.
Thusthe practices and techniques developed by users for exploiting NLS areas much a subjectof research interestas the development of NLS itself.
NLS issupplemented by a typewriter-orientedcounterpart called TODAS,which is discussed in Section I1 ofthis appendix.Section I11 describesthe NLS/TODAS capabilities forproducing flexibly formatted hard copy from on-line files.
Section IV ofthis appendix is a glossaryof special NLSITODASterminology.
B. NLS Console
Theuser sits at a consolewhose main elements are a displayscreen, a typewriterkeyboard. a cursordevice calledthe "mouse," and a setof five keys operated by the lefthand, called the "keyset."
Thescreen is usedfor displaying text, in various formats.The topportion of the screen (approximately Append i x A NLSITODAS USER FEATURES
1/5 ofthe total area) is reservedfor feedback informationof various kinds: the name of theuser commandmode currently in effect, a "register"area used for variouskinds of textual/numerical feedback, an "echoregister" which displays the last six characters typedby the user, and other items that are explained be I ow.
Thekeyboard closely resembles a conventionaltypewriter keyboard,with a fewextra keys for special characters andcontrol functions. It isused for typingtext as contentfor a fileand for specifying commands, which aregiven as two- or three-charactermnemonics.
Themouse is a roughlybox-shaped object, about four incheson its longest side, which is moved by the right hand. It ismounted on wheels and rolls on any flat surface,The wheels drive potentiometers that are read byan A/D converter, and the systemcauses a tracking spot("bug") to move on the screen in correspondence to themotion of the mouse.
Theuser specifies locations in the displayed text by pointing with them.ouse/bug combination. This eliminatesthe need for specifying a locationby entering a codeof some kind. Use of the mouse is veryeasily learned and soon becomes unconscious.
Ontop of the mouse arethree special control buttons,whose uses aredescribed below.
Thekeyset has one key for each finger of the left hand. Thekeys are struck in combinations called "chords," and eachchord corresponds to a character or combination of charactersfrom the keyboard. There are 31 possible chords;beyond this, two of the buttons on the mouse maybe used to controlthe "case" of the keyset, giving alternativemeanings to each chord. There are four possiblecases, for a total of 124 possible combinations.
A simplebinary code is used and has proved remarkablyeasy tolearn. Two or threehours' practiceis usually sufficient to learn the most commonlyused chords and develop reasonable speed.
Thekeyset was developed to increase the user's speed Append i x A NLSITODASUSER FEATURES
andsmoothness in operating NLS. It wasfound that U-sersnormally keep the right hand on the mouse, becausethe great majority of command operations involve a pointingaction; efficient use of the keyboard,however, requires the use of both hands, andshifting the right hand (and the user's attention)to the keyboard is distractingand annoying if it mustbe done for each two- or three-lettercommand mnemonic.
Useof the keyset permits the user to keep his righthand on the mouse and his left on the keyset,reverting to the keyboard only for entry of longstrings of text (typically five or more characters).
Originally,the keyset exactly duplicated the keyboardin function; in the development of NLS, however,certain control functions have been made two-strokeoperations from the keyset where they wouldbe three- or four-stroke operations from the keyboard.Nevertheless, it isstill possible to operateall of thefeatures of NLS withoutusing the keyset;thus the beginner may defer learning the keysetcode until he has gained some degree of masteryover the rest of thesystem.
C. StructuredText
"Text"is used here as a verygeneral term. A "file" of text (correspondingvery roughly to a "document"in hard copy)may consist of English or someother natural language,numerical data, computer-program statements, or anythingelse that can be expressed as a structureof characterstrings. Simple line drawings can also be includedin a file.
Alltext handled by NLS isin "structured-statement" form. Thisspecial format is simply a hierarchicalarrangement of "statements,"resembling a conventional"out1 ine" form.
Eachstatement in a file maybe considered to possess a "statementnumber," which shows its position and level inthe structure. Thus the first statement in a fileis Statement 1; itsfirst substatement is la, and its next substatementis Ib; the next statement at the same level asthe first is Statement 2; and so forth.Statement
75 Appendix A NLSITODAS USER FEATURES
numbershave been suppressed in printing 0u.t most of this documentbut are printed out for the remainder of thissection as an example. .DSN=O;
Everystatement also bears a "signature"that may be displayedon command. The signature is a line of text givingthe initials of the user who created the statement(or modified it mostrecently) and the time anddate when this was done.
A statementis simply a string of text,of any length; thisserves as the basic unit in the construction of the hierarchy. In Englishtext, statements are normally equivalentto paragraphs, section and subsection headings, or itemsin a list.In other types of text, statementsmay be data items, program statements, etc.
Eachparagraph and heading in this document is an NLS statement.Each statement is indented according to its"level" in thehierarchy; this paragraph is a substatementof the one above, which is in turn a substatement of anotherstatement. A statementmay haveany number of substatements,and the overall structuremay have any number of levels.
Notethat when a usercreates a file,he may let all of his statementsbe first-level ones, i.e., 1, 2, 3, etc. In thiscase he will nothave to consider a hierarchical structurebut simply a linearlist, as is found in conventionaltext.
However,many of thefeatures of NLS areor.iented to makeuse of hierarchy,and the benefits of these featuresare lost if hierarchyis not exploited.
Thisis an example of an NLS featureto which the user mustaccommodate his methods; however, the experience of usershas been that hierarchical structure very rapidly becomes a completely"natural" way of organizing text. Manyautomatic features of NLS makethe structure easy to use: for example,statement numbers are created automaticallyat all times and the user need not even be awareofthem. It issufficient, when the user creates a statement, to specifyits level relative to the precedingstatement. .DSN=l; Append i x A NLSITODASUSER FEATURES
D. Useof the System
Textmaniputation is considered to involve three basic typesof activity by the user: composition, study, and modification. In practice,the three activities are 50 intermingledas to be indistinguishable.
1. Composition
Compositionis simply the creation of new text material ascontent for a file.
Inthe simplest case, the user gives the command "Insert Statement"by typing "is". He then points (with the mouse)to an existing statement; the system displays a newstatement number which is the logical successor, at thesame level, asthe statement pointed to. The user maychange the level of thisnumber upward by typing a "u"or downward by typing a "d".
NOTE: If noprevious statement has been created, the systemdisplays a "dummy"statement at the top of the text-displayarea, and the user points to this dummy inorder to inserthis first statement.
Theuser then types the text of thenew statement from thekeyboard. On the screen, the top part of the text-displayarea is cleared and characters are displayedhere as they are typed. When the statement is finished,the user hits a CA (commandaccept) button on thekeyboard or mouse, and the system re-creates the displaywith the new statement following the one that waspointed to.
New materialmay also be added to existingstatements by meansof commands such as Insert Word, Insert Text, and others.Properly speaking, these operations are modificationrather than composition, and are discussed below.
Simpleline drawings maybe composed and added to the fileby means of the "vectorpackage." This is discussedin another section of thisreport.
2. Study
Thestudy capabilities of NLS constituteit.s most Appendix A NLS/TODASUSER FEATURES
powerfuland unusual features, The following is only a brief,condensed description of the operations that are poss i b I e.
a.Jump i ng
NLS filesmay, of course,contain a greatdeal more text thancan be displayed on the screen, just as a documentmay contain more than one page of text. An NLS fileis thought of as a long"scrol I ." The processof moving from onepoint in the scroll to another,which corresponds to turningpages in hard
COPY 9 iscalled "jumping." There is a verylarge familyof Jump commands.
Thebasic Jump command is Jump to Item. The user specifies it byentering "ji" andthen points to somestatement with the mouse. The selected statementis moved to thetop of thescreen, as if thescroll had been rolled forward.
Mostof ,the Jump commands reference the hierarchicalstructure of thetext. Thus Jump to Successorbrings to thetop of thedisplay the nextstatement at the same level as theselected statement;Jump to Predecessor does the reverse; Jumpto Up starts the display with the statement of whichthe selected statement is a substatement, and so forth.
TheJump to Namecommand uses a differentway of addressingstatements. If thefirst word of any statementis enclosed in parentheses, the system will recognize it asthe "name" of thestatement. Then, if thisword appears somewhere else in the text,the user may jump to the named statement by pointing to theoccurrence of thename, or by typingthe name.
Thisprovides a cross-referencingcapability thatis very smooth and flexible; the command Jump toReturn will alwaysrestore the previous display, so thatthe user may follow name referenceswithout losing his place. It isalso possible to jumpto a statementby I typingits statement number. 1 Append i x A NLS/TODAS USER FEATURES
b. ViewControl
If a file is long, it may be impossible for the user to orient himsejf 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 and line truncation.
Level control permits the user to specify some number of levels; the system will then display only statementsof the specified level or higher.Thus if three levels are specified, only first-, second-, and third-level statements are displayed.
Line truncation permits specification of how many lines of each statement are to be displayed. Thus if one line is specified, only the first line of each statement will be displayed.
Common usage is to use the first two or three levels in a file as headings describing the material contained under each heading in the form of substatements. Thus the user may start by looking at a display showing only the first-level statements in the file, one line of each. This amounts to a table of contents.
He may then select one of these statements and jumpto it, specifying one more level. He will then see more details of the content of that part of the file. 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 fuli display of the text.
Users soon develop a habit of structuring files in such a way that this process will work well. As it happens, such a structure is usually a good, logical arrangement of the material, reflecting the relationships inherent in the content.
The level and truncation controls are designed so that the necessary specifications may be made with only one or two strokes -of the keyboard or keyset. These controls are on,ly th.e most important of a large set of view-control parameters called "VIEWSPECS." Append i x A NLSITODAS USERFEATURES
OtherVIEWSPECS control a numberof special NLS featuresaffecting the display format.
Anexample of the use of VIEWSPECS is givenbelow in SectionI-D-2-e of this appendix.
c.Content Analysis
The NLS contentanalyzer permits automatic searching of a filefor statements satisfying some content patternspecified by the user. The pattern is written in a speciallanguage as part of the file text.
Contentpatterns may be simple, specifying the occurrenceof some word, for example. They may also behighly complex, specifying the order of occurrence oftwo or more strings, the absence of some text construct,conditional specifications, etc. Simple patternsare extremely easy to write; complex ones arecorrespondingly more difficult.
d. "Keyword"d. System
A "keywordstatement" is a namedstatement that referencesother statements in the file by name, in a specialformat. The name of the keyword statement is thenunderstood to be a "keyword"applying to the statementsreferenced by the keyword statement.
Supposethat a filecontains a listof keyword statements.The user may study this list and selectseveral keywords with theKeyword Select command(pointing to thekeywords with the mouse).
Hemay specify a weightfrom 1 to 10 foreach keyword; if noweight is specified, a weightof 1 isassumed.
Whenthe user gives the Keyword Execute command, a searching/scoringprocess is executed. Each of theselected keyword statements is scanned for the namesofstatements that it references.Each referencedstatement receives a "score"equal to theweight of thekeyword. If a statementis referencedin more than one keyword statement, the scoresadd.
180 I Append i x A NLSITODASUSER FEATURES
Whenthis process is completed, NLS constructs a displaypicture showing only the statements that havereceived nonzero scores, in order of decreasing scores.
In otherwords, each keyword is the name of a statementthat defines some arbitrary category of statementsin the file. When a userselects and weightskeywords, he is expressing his interest in certainof these categories. NLS thendisplays all ofthe statements in these categories, beginning with the"most interestlng."
Becausethe relat,ionships used in thissystem are set upexplicitly when a userwrites keyword statements, thesystem is very flexible although not highly automated. It maybe regarded as a generalized methodof reordering some of thestatements in a file onthe basis of user-selected criteria chosen from a suppliedlist (the keyword statements).
Notethat this reordering is on the display, not inthe file proper. The file proper is not affectedin any way, except that the list of selectedkeywords and weights is saved in the f i le.
Thislist maybe displayed on command. Individualkeywords may be deleted from the list or theirweights changed, or thewhole listcan be deleted on command.
e.Link Jumping
A "link"is a stringof text, occurring in an ordinary file statement,that indicates a cross-referenceof some kind. It mayrefer to anotherstatement in the file, or to a statement in someother file, possibly belonging to another NLS user.The text of the link is both human-readable andmachine-readable, and the command Jump to Link permitsthe user to point to the link with the mouse anaimmediately see the material referred to.
Anexample of a linkis (Smith. Plans. Longrange:ebgtn).
181
I Append i x A NLSITODAS USER FEATURES
Thefirst item in the link indicatesthat the referencedfile belongs to a usernamed Smith; the second is thename of the file; the third is the nameof a statement in thefile (a statement numbermay also be used); and the string of charactersfollowing the colon controls the VIEWSPECSto set up a particularview of the material.
TheJump to Link command, executed by pointing tothis link, would cause Smith's file"Plans" tobe automatically loaded and the display startset to the statement whose name is "Longrange." VIEWSPECS wouldbe automatically setas follows:
The "e" causesthe number of leve!s displayedto be 'set equal to the level of thedisplay-start statement.
The"b" increments this byone.
The "g" specifiesthat the display is to be I imitedto the "branch" defined by the display-startstatement -- i.e.,only that statement,its substatements, their substatements.etc.
The "t" specifiesdisplay of only the first line of eachdisplayed statement.
The"n" specifies that statement numbers are tobe suppressed from the display.
Thusthe net result is to display the first I inesof statement "Longrange" and its highest-levelsubstatements, without statementnumbers.
Theuse of interfile links permits the construction of largelinked structures made up of manyfiles, and study of these files as if they were allsections of a singledocument. The Jump to FileReturn causes the file previously viewed tobe reloaded and displayed, with the same displaystart and VIEWSPECS thatwere in effect justbefore the link jump; thus the user may
182 Append i x A NLSITODAS USER FEATURES
execute link jumps freely without losing track of his original location. 3. Modification A large repertoire of editing commands is provided for modification of files. The basic functions are Insert, Delete, Move, and Copy.
These functions operate upon various kinds of text entities. Within statements, they may operate upon single characters, words, and arbitrary strings of text defined by pointing to the first and last characters. This set of commands is not restricted to operation within one statement at a time; for example, a word may be moved 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 special entities have been defined for this purpose: for example, a "branch" consists of some specified statement, plus all of its substatements,plus all of their substatements, etc. A branch can be deleted, moved to a new position in the structure, etc.
As noted above, the modification activity tends to merge, in practice, with study and composition. E. Summary It must be noted that NLS is not a system designed fol general usage, but a specialized tool designed for a group of people working on t.he development of computer aids to humanintellectual processes. It is for thisreason, for example, that NLS is not really a text-editing system oriented toward hard-copy production, but rather something simultaneously more general and more specialized.
It is in the process of manipulating a file -- studying it, making modifications, adding new material as an integrated process lasting for minutes or hours at a time and having a continuity extending for days, weeks, or even years -- that the real benefit of NLS appears. Appendix A NLS/TODAS USER FEATURES
toconstant modification, updating, and reevaluation. Itsdevelopment may have no clearly defined endpoint. It maycease to exist as a fileby being incorporated in anotherfile, or it mayeventually be abandoned or superseded;however, in mostcases it will neverbe "finished" in theusual sense of- the word.
Continuoususe of NLS tostore ideas, study them, relate themstructurally, and cross-reference them results in a superiororganization of ideas and a greaterability to manipulatethem further for special purposes, as the needarises -- whether the "ideas"are expressed as naturallanguage, as data, as programming, or asgraphic information.
I1 TheTypewriter-Oriented Documentation-Aid System (TOOAS)
TODAS is a text-handlingsystem designed as a "typewriter" counterpartto NLS. Inprinciple, TODAScan be operated from a Teletype or anyother sort of hard-copy terminal, including terminalslinked to the 940 throughacoustic couplers and ordinarytelephone lines (as opposed to NLS, whichrequires specialtransmission arrangements).
Thepresent implementation allows for the use of Teletype Models 33, 35, and 37, Terminetand Execuport terminals (thelatter being portable, with a built-inacoustic coupler),and NLS displayconsoles.
Each of theseterminals has its own character set, no two setsbeing exactly the same except Teletype Models 33 and 35. As a result,special-character assignments are device-dependent. A TODAS featureallows the user to redefinecharacters at will tosuit his immediate purposes.
Animportant use of TODAS is for access, within the ARPA ComputerNetwork, to the Network Information Center (NIC) operatedby ARC. TODAS will giveNetwork users access to filesof information created either with TODASor with NLS, sincefiles created with the two systems are identical in structureand format.
TODAS hasmany of the samecapabilities as NLS for the manipulationof text; it differs from NLS asrequired by the useof a "typewriter" deviceinstead of a display.The importantdifferences arise from thefact that TODAS has no
184 Appendix A NLS/TODAS USER FEATURES
analogcursor device to correspond to the NLS mouseand from thegenerally slower operation of TODAS.
For this reason,editing of textwithin a statementcannot bedone by means resembling those of NLS, sinceall of the NLS editingoperands are indicated by the user with the mouse. TODAS usestwo alt-ernative methods.
One is theTODAS "alter" command, which operates very muchlike the "modify" command of the QED line-editing systemdeveloped by Project GENIE at UC. "Alter" creates a newstatement to replace the original one, by goingthrough the original from beginning to end; under usercontrol, characters are (1) copiedfrom the old statementto the new, (2) skippedover, or (3) inserted intothe new statement from the keyboard.
Theother is the TODAS "substitute" command, which allowsthe user to specify that a certainstring of charactersin t.he statement is to be found by TODAS and replacedwith another specified string.
Atthe structural level (where the user wishes to manipulatestatements and sets of statements as units), NLS permitsthe user to identify statements by pointing with themouse; TODAS requires that statements be identified fromthe keyboard. Considerable flexibility is provided in thisoperation.
Theuser may identify a statementdirectly by typing its statementnumber or itsname; he may also identify it indirectlyby specifying its structural relationship to someother statement whose number or namehe knows of f-hand.
Indirectspecification corresponds to the use of NLS commandssuch as "jump to head," "jump to successor," etc.,but with the added feature that relationships maybe concatenated -- thusthe user may, in a single operation,specify a complexrelationship such as the successor of thefirst substatement of the predecessorof a givenstatement.
A TODASstatement may consist of the string of Appendix A NLSITODAS USER FEATURES
charactersthat a userwould type from the keyboard to performsome sequence of operations. This statementmay thenbe executed with a specialcommand, and the result will beexactly as if theuser had actually typed these characters,causing the sequence to be carried out.
Thesequence may, in principle, be arbitrarily complex; anexecutable statement might, for example, contain the followingsequence:
(1) Load a filewhose name is specified elsewhere in thecurrent file
(2) Searchthis file with the content analyzer, findingstatements with a specifiedpattern of content
(3) Writethese statements out in a temporary "buffer" f i I e
(Lt) Reloadthe original file
(5) Copythe statements in the "buffer" file into a specifiedlocation in theworking file.
A special"switch" character may be used in the executabletext. When the switch character is encountered,execution of the text isinterrupted and controlreverts to the keyboard. The user then enters part of thecontrol sequence manually; when he types the switchcharacter from the keyboard, execution of the executablestatement resumes at t'he point where it left off. Thisfeature affords great flexibility, since it allowspart of the sequence to be specified ahead of time andpart at "execution time."
Besidesits primary purpose a5 a Networkuser's interface to theNIC, TODAS is used within ARC as a supplementaltool to NLS.
TODAScan be used conveniently for many tasks that do not requirethe rapid display response of NLS, andhas the advantage of creatingsignificantly less load on the overalltimesharing system. We currentlyhave one clerical worker,who is not an NLS user,operating TODAS routinely forentry of information and for some limited retrieval work.
186 Append i x A NLSITODAS USERFEATURES
Additionally, we find TODASuseful for remote accessing of oursystem. We havemade TODAS available to selected consultants,who use home terminals with acousticcouplers, andregular ARC personnel occasionally do work from their homesby the same means.
Theprototype version of TODASwent into service in September 1969; a secondversion, with greatlyexpanded capabilities, becameoperational early in 1970.
I11 OutputFacility
NLS andTODAS both use the samefacilities for producing formattedhard-copy output fromNLSITODAS files.
Thedevices in ordinary use at ARC forhard-copy output are a lineprinter that produces upper/lower-case print of adequate qualityfor local ~ise, and a paper-tape-drivenautomatic typewriterused for final output of reproducible copy for reports,proposals, etc.
TheOutput Processor (previously known as "PASSq") can be controlledby the user to a considerableextent. This is done bymeans of "directives" embedded in the file text. The directivescan be used to reset page parameters, control page numbering,and turn various format features "on" or "off."
Forexample, directives can be used to suppress indentation ofstatements or changethe amount of indentation, to create"running headers" that are automatically printed at thetop of eachpage, suppress statement numbers, etc. One ofthe directives causes all directives to be suppressed fromthe output.
In additionto the line printer and the automatic typewriter, theOutput Processor can output a fileto magnetic tape, appropriatelyformatted to drive CRT-to-film conversion equipmentfor production of microfilm.
Inall cases, the user may elect to output an entire file or onlypart of the file. In the latter case, he may cause outputto begin at some specified point in the file instead of atthe beginning, and he may cause the printout to be limited bythe same kinds of criteria that may be used on the display
" ;.e.,content analysis, limited number of structural levels,etc. Appendix A NLSITODAS USER FEATURES
IVGlossary of Special NLS/TODAS Terminology
BRANCH: A specifiedstatement, plus all of its substructure -- i.e.all of itssubstatements, plus all of their substatements,etc.
BRANCHONLY: A VIEWSPECparameter that restricts the text displayed (NLS) ortyped (TODAS) to a singlebranch (see VIEWSPECS).
BUG:The cursor mark on the screen that is moved by the mouse andthat is used for selecting (pointing to) entities on the display.
Whenthe bug is "active," i.e., when a selectioncan be made, it appearsas an up-arrow; when it is inactive it appearsas a plussign.
CHARACTER:Any letter, digit, punctuation mark, space, tab, or carriagereturn; an indivisible entity.
CHORD: A combinationof keys on thekeyset (see KEYSET).
CLIPPING:See LEVEL CLIPPING.
END: Thelast statement in any branch; specified by specifying thebranch.
FILE: A completetree structure of statements with a single root (theorigin statement).
FILENAME:The name of a file. It appearsas the first word in theorigin statement of an existing file, andmust be supplied bythe user in creating a newfile.
GAPCHARACTER: Any space, tab, or carriagereturn.
GCHAR: Abbreviationfor GAP CHARACTER.
GROUP: A subsetof a plex,consisting of allbranches from one specifiedbranch to another,inclusive.
HEAD:The first statement in a sublist.
Thehead is specified by pointing to anystatement in the sub1 ist. Appendix A NLS/TODAS USER FEATURES
INVISIBLE:Any consecutive string of gap characters, bounded by(but not including) printing characters or the end of a statement:see PRINTING CHARACTER, GAP CHARACTER, STATEMENT.
Specifiedby pointing to any character in thestring. If a singleprinting character lying between two invisibles is pointedto, both invisibles (and the printing character) areselected.
KEYSET:The device at the left-hand side of the NLS console. When a combinationof keys (a chord) is depressedon the keyset,the effect is the same as striking a keyon the keyboard.
KEYWORD: Thename of a "keywordstatement."
KEYWORDSTATEMENT: A statementthat lists, in a special format,the names of all statements in the same file thatfall intosome arbitrary category.
The"keyword system" of NLSITODAScommands, operating upon keywordstatements, performs information-retrieval operationsbased on the sets of statements defined in keywordstatements.
LABEL: A stringof text placed in a pictureby means of a command in thevector package.
LEVEL:The "rank" of a statement(see STATEMENT) in the hierarchyof the file (.see FILE).
Thelevel is equal to the number of fields of letters or digits in thestatement number; thus Statement 3 is a first-levelstatement, Statement 4a1093 is a fifth-level statement,etc. Level isof great importance in understandingthe hierarchical structure of an NLS file.
LEVELCLIPPING: Restricting the text displayed (NLS) or printed(TODAS) to statements no deeper than a specified level,which is setby a VIEWSPECparameter (see VIEWSPECS).
LINE TRUNCATION: Restrictingthe amount oftext displayed (NLS) or printed (TODAS)to the first N linesof each Append i x A NLSITODAS USER FEATURES
statement,where N is specifiedby setting a VIEWSPEC parameter(see VIEWSPECS).
Eachstatement is formatted into linesupon outputto the display or printingdevice; thus theamount oftext in a I.inedepends upon the device and uponother parameters.
LINK: A speciallyformatted string of text in a statement, analogousto a referenceor cross-reference citation in a conventionaldocument.
A linkspecifies a user, a file belongingto that user, a locationin the file, and VIEWSPECS. A usermay "follow" a linkby means of theJump to Linkcommand (NLS) or an indirectaddress (TODAS). Ineither case, the system detectsthe link, interprets it, loadsthe specified file, anddisplays or printsthe specified portion of it with the specifiedVIEWSPEC parameters.
MOUSE:The device at the right-hand side of the NLS keyboard. Ahen it isrolled around on the tabletop, it causesthe bug (cursormark) to move correspondingly on the screen.
NAME: If the first word of a statementis enclosed in parentheses, it is the NAME of thestatement.
Thecommand Jump to Name can then be used to place the statementat the top of thedisplay. This is done by enteringthe name from the keyboard or keyset, or by findingan occurrence of the name as text onthe display andpointing to it withthe bug.
NLS: Acronym for "On-LineSystem."
ORIGIN:The first statement in a file; it containsinformation aboutthe file, plus any other text the userinserts. It has a levelof 0, andhence no statement number.
OUTPUTPROCESSOR: Program used by NLS andTODAS for producing formattedoutput.
PASS4:Alternate name used for the Output Processor.
PATTERN: A string of special-language text in a statementthat maybe compiled via the command Execute Content Analyzer. Whencompiled, it produces a programthat is used by the content-analyzerfeature. Appendix A NLSITODAS USER FEATURES
PCHAR:Abbreviation for PRINTING CHARACTER.
PLEX:Another name for a SUBSTRUCTURE,used in command specifications.
A plex is specifiedby pointing to any one of its highest-levelstatements.
POINTER: A string ofup to three characters that is attached tosome character in thetext with thePointer Fix command.
PREDECESSOR:The statement preceding a specifiedstatement in a SUBL I ST.
SOURCE:The statement of which a specifiedstatement is a substatement.
SIGNATURE:Information stored with a statement(and displayed oncommand) giving the initials of theuser who created the statement(or most recently modified it) andthe time and date whenthis occurred.
STATEMENT:The basic structural unit of a fileof text in NLS. Formally, it is a stringof text and/or pictures that is boundedat the beginning by the end of theprevious statement orthe beginning of the file, andbounded at theend by the beginning of anotherstatement or the end of the file.
Statementsare arranged in a treestructure or hierarchy andare assigned "statement numbers" indicating their positionsin the structure. Each statement has a number, madeup of alternating fields of digits and letters; the numberof fields indicates the "level" of thestatement (seeLEVEL).
A statementis specified by pointing to anycharacter in thestring.
SUBLIST:The set of all substatements of a specifiedstatement (notincluding the substatements of thesubstatements).
SUBSTATEMENT: A statement "X" iscalled a substatement of anotherstatement "Y" if it isdeeper in the structure than "Y," if it follows "Y," and if thereis no intervening higher-orderstatement. "Y" iscalled the source of "X." The Appendix A NLS/TODAS USER FEATURES
statementnumber of "X" willbe the same as that of "Y" except that it will haveone more field at the end. The value of this fieldgives its ordinalposition in a "sublist" of the substatements of "Y."
A substatementis specified by pointing to the source statement.
SUBSTRUCTURE:The set of all substatements of a specified statement,plus all their substatements, etc. until nomore arefound. The set of all branches defined by statements in thesublist of a givenstatement.
SUCCESSOR: The statementfol'lowing a specifiedstatement in a sub1 ist.
TAIL:The last statement in a sublist.
Thetail is specified by pointing to any statement in the sub1 ist.
TEXT:Any string of characterswithin a statement,bounded by (andincluding) two specified characters: see CHARACTER, STATEMENT.
TODAS:Acronym for Typewriter-OrientedDocumentation-Aid System.
TRUNCATION:See LINE TRUNCATION.
VECTOR: A line in a picture.
VIEWSPECS:View-control parameters controlling a numberof special NLS featuresaffecting the display format. See, for example,BRANCH ONLY, LEVEL CLIPPING, and LINE TRUNCATION.
VISIBLE:Any consecutive string of printingcharacters, boundedby (but not including) gap cha'racters or theend of a statement:see PRINTING CHARACTER, GAPCHARACTER, STATEMENT.
Specifiedby pointing to any character in thestring. If a singlegap character between two visibles is pointed to, thenboth visibles (and the gap character) are specified.
WORD: Anyconsecutive string of letters and/or digits, bounded by(but not including) any other types of characters or the endof a statement:see STATEMENT. Appendix A NLSITODAS USER FEATURES
Specified by pointingto any character in thestring. If a singlecharacter is pointed to that is not a letter or digitand lies between two words,then both words (and the singlecharacter) are specified.
I
BIBLIOGRAPHY
The following is a chronological list of documents published by the Augmentation Research Center. 1. D. C. Engelbart, "Special Considerations of the Individual AS a User, Generator, and Retriever OF Information," Paper presented at Annual Meeting of American Documentation Institute, Berkeley, California (23-27 October 1960). 2. D. C. Engelbart, "Augmenting Human Intellect: A Conceptual Framework," Summary Report, Contract AF W(638)-1024, SRI Project 3578, Stanford Research Institute, Menlo Park, California (October 19621, AD 289 565. 3. D. C. Engelbart, "A ConceptualFramework for the Augmentation of Man's Intellect," in Vistas in Information Handling, Volume 1, D. W. Howerton and D. C. Weeks, eds., Spartan Books, Washington, O.C. (1963). 4. D. C. Engelbart,"Augmenting Human Intellect: Experiments, Concepts, and Possibilities," Summary Report, Contract AF 49(638)-1024,SRI Project 3578, Stanford Research Institute, Menlo Park, California (March 19651, AD 640 989. 5. D. C. Engelbart and 8. Huddart, "Research on Computer-Augmented Information Management," Technical Report ESD-TDR-65-168, Contract AF 19(628)-4088,Stanford Research Institute, Menlo Park, California (March 19651, AD 622 520.
6. W. K. English, D. C. Engelbart, and B. Huddart, "Computer-Aided Display Control," Final Report, Contract NAS1-3988, SRI Project 5061, Stanford Research Institute, Menlo Park, California (July 19651, CFSTI Order No. N66-30204.*
7. W. K. English, D. C. Engelbart, and M. L. Berman, "Display-Selection Techniques for Text Manipulation," IEEE Trans. on Human Factors in Electronics, Vol. HFE-8, No. 1, pp. 5-15 (March 1967).
8. 0. C. Engelbart, W. K. English, and J. F. Rulifson, "Study For The Development of Human Intellect Augmentation Techniques," Interim Progress Report, Contract NAS1-5904, SRI Project 5890, Stanford Research Institute, Menlo Park, California (March 1967). 9. J. D. Hopper and L. P. Deutsch, "COPE: An Assembler and On-Line-CRT Debugging System for the CDC 3100," Technical Report 1, Contract NAS 1-5904, SRI Project 5890, Stanford Research Institute, Menlo Park, California (March 1968).
. .. BIBLIOGRAPHY
10. R. E. Hayand J. F. Rulifson,"MOL940: A Machine-Oriented ALGOL-LikeLanguage for the SDS 940," TechnicalReport 2, ContractNAS 1-5904, SRI Project 5890, StanfordResearch Institute,Menlo Park, California (April 1968).
11. 0. C.Engelbart, W. K. English,and J. F. Rulifson, "Developmentof a Multidisplay,Time-shared Computer Facility and Computer-AugmentedManagement-System Research," Final Report, ContractAF 30(602)4103, SRI Project 5919, Stanford Research Institute,Menlo Park, California (April 19681, AD 843 577.
12. D. C. Engelbart,"Human Intellect Augmentation Techniques," FinalReport, Contract NAS 1-5904, SRI Project 5890, Stanford ResearchInstitute, Menlo Park, California (July 19681, CFSTI Order No. N69-161'tO.*
13. D. C.Engelbart, W. K. English,and D. A.Evans, "Study for theDevelopment of Computer-Augmented Management Techniques," QuarterlyProgress Report 1, Contract F30602-68-C-0286, SRI Project7101, Stanford Research Institute, Menlo Park, California (October1968).
14. D. C.Engelbart and W. K. English, ".A ResearchCenter for AugmentingHuman Intellect," in AFIPS Proceedings, Vol. 33, Part One,1968 Fall Joint Computer Conference, pp. 395-410 (Thompson Book Co.,Washington, D.C., 1968).
15. D. C.Engelbart and Staff of the Augmented Human Intellect ResearchCenter, "Study for theDevelopment of Human Intellect AugmentationTechniques," Semiannual Technical Letter Report 1, ContractNAS 1-7897, SRI Project 7079, StanfordResearch Institute,Menlo Park, California (February 1969).
16. D. C.Engelbart and Staff of the Augmented Human Intellect ResearchCenter, "Study for the Development of Human Intellect AugmentationTechniques," Semiannual Technical Letter Report 2, ContractNAS 1-7897, SRI Project 7079, StanfordResearch Institute,Menlo Park, California (August 19691.
17. D. C.Engelbart and Staff of the Augmented Human Intellect ResearchCenter, "Computer-Augmented Management-System Research andDevelopment of Augmentation Facility," Final Report RADC-TR-70-92,Contract F30602-68-C-0286, SRI Project 7101, StanfordResearch Institute, Menlo Park, California (April 1970).
196 ". .~ -
BIBLIOGRAPHY
*Note:Reports with ADnumbers are available from Defense DocumentationCenter, Building 5, CameronStation, Alexandria, Virginia 22314. Itemsmarked with an asterisk may be obtained fromCFSTI, Sills Building, 5825 PortRoyal Road, Springfield, Virginia 22151; cost $3.00 percopy or 65 centsfor microfilm.
Thefollowing is a list ofother documents cited in this report. Theitems are listed in theorder 'in which theyare cited.
18. "Specificationsfor the Interconnection of a Host andan IMP,"Report No. 1822. ContractNo. OAHC15-69-C-0179, ARPAOrder No. 1260, BoltBeranek and Newman Inc., Cambridge, Massachusetts (May 1969).
19. L. Roberts,"Computer Network Development to Achieve ResourceSharing," paper presented at 1970 SpringJoint Computer Conference,Atlantic City, New Jersey (May 1970); AFIPS ConferenceProceedings. Vol. 36, p. 543 (AFIPSPress, Montvale, NewJersey, 1970).
20. F. Heartet al., "The Interface Message Processor for the ARPAComputer Network," paper presented at 1970 SpringJoint ComputerConference, Atlantic City, New Jersey (May 1970); AFIPS ConferenceProceedings. Vol. 36, p. 551 (AFIPSPress, Montvale, NewJersey, 1970).
21. L. Kleinrock,"Analytic and Simulation Methods in Computer NetworkDesign," paper presented at 1970 SpringJoint Computer Conference,Atlantic City, New Jersey (May 1970); AFIPS ConferenceProceedings, Vol. 36, p. 569 (AFIPSPress, Montvale, NewJersey, 1970).
22. H. Frank, I. Frisch,and W. Chou,"Topological Considerationsin the Design of the ARPA Computer Network," paper presentedat 1970 SpringJoint Computer Conference, Atlantic City,New Jersey (May 1970); AFIPSConference Proceedings, Vol. 36, p. 581 (AFIPSPress, Montvale, New Jersey, 1970).
23. S. Carr. S. Crocker,and V. Cerf, "HOST-HOST Communication Protocol in theARPA Network," paper presented at 1970 Spring JointComputer Conference, Atlantic City, New Jersey (May 1970); AFIPSConference Proceedings, Vol. 36, p. 589 (AFIPSPress, Montvale,New Jersey, 1970).