Advanced_Intellect Augmentation_Techniques_Jul70 Advanced Intellect Augmentation Techniques Jul70
Advanced_Intellect-Augmentation_Techniques_Jul70 Advanced_Intellect-Augmentation_Techniques_Jul70
User Manual: Advanced_Intellect-Augmentation_Techniques_Jul70
Open the PDF directly: View PDF .
Page Count: 204
Download | ![]() |
Open PDF In Browser | View PDF |
Final Report ADVANCED INTELLECT-AUGMENTATION TECHNIQUES By: D. C. ENGELBART and STAFF OF AUGMENTATION RESEARCH CENTER Prepared for: NATIONAL AERONAUTICS AND SPACE ADMINISTRATION LANGLEY RESEARCH CENTER LANGLEY STATION, MAIL STOP 126 HAMPTON, VI RGINIA 23365 CONTRACT NAS1-7897 STANFORD RESEARCH INSTITUTE Menlo Park, California 94025 • U.S.A. Final Report July 1970 ADVANCED INTELLECT-AUGMENTATION TECHNIQUES By: D. C. ENGELBART and STAFF OF AUGMENTATION RESEARCH CENTER Prepared for: NATIONAL AERONAUTICS AND SPACE ADMINISTRATION LANGLEY RESEARCH CENTER LANGLEY STATION, MAIL STOP 126 HAMPTON, VIRGINIA 23365 CONTRACT NASl-7897 SR I Project 7079 Approved by: DAVID R. BROWN, Director Information Science Laboratorv BONNAR COX, Executive Director Information Science and Engineering Division .CO~y No. 41...... . ABSTRACT This report cover. a two-year project, at the eleventh year of a growing, multiproject program that is exploring the value of computer ai~s to augmenting human intellectual capability. Outlined brieflY are the baCkground and the "bootsttapplng" nature of the procram, its resources, and the activities it has undertaken in pursuit of its goals. Advances ma4e during the project were: (1) Making operational an experimental interactive laboratory comprising an XDS-940 computer, special interface and dilplay hardware, a mOdified UCB-GENIE timesharing system, six NLS consoles and lixteen typewriter terminals, a 96-megabyte file-storace diSk, and a 96-character line printer (2) Making extensive progress in the develo~ment of special-purpose languages and softWare architecture to provide for both highly interactive service and flexible system evolution (3) Moving our team of Iystem developers into an on-line working mode, and beiinnin~ to learn how to adapt to thi' environment -- with encouraging success, as represented oy our emerging "software-engineering" methodOlogy (4) Establishing a plan, and partiallY implementing the basic services, for an information center to serve the experimental ARPA Network. User experience in applying our augmentation tools and techniques to various normal working tasks within our center is described so as to convey a SUbjective im~ress1on of What it i5 like to work in an augmented enviroment. It is conclu~ed that workinl-8up~ort, computer-aid systems for augmenting individuals and teams, ot the general sort we have been experimenting With, are undOUbtedly loing to be widelY developed and used. A very special rOle in this development il seen for multi-access computer networks: they will become special market~l&ces where a new kind of competitive evolution will take place, not only in hardware, SOftware, and special services &1 "bought" from a "utility," but &110 in roles, skills, working methods, and employment ~yn&micl for the intellectual workers at the terminalS. iii PREFAOE The re.earch de.cribed in tni. report represent. conceptual, de.iln, and develo~ment work bY a laree number of people) the ~rolram has been active as & coordinated team effort lince 1963. The research reported here was a cooperative team effort involving the entire ARC staff. The followinc is an alPhabetical listing of the current ARC staffl Geoffrey H. 8all, Walter L. Ba.s, Vernon R. Baughman, Mary G. Caldwell, Roberta A. Carillon, David Cassere., Mary S. Church, William S. Duvall, DOuglas C. Enlelb&rt, William K. Enllilh, Ann R. GeOffrion, Martin L. Hardy, Jared M. Harril, J. D&vi~ Ho~~er, Charle. H. Irby, L. stephen Leonaro, John T. Melvin, N. Dean Meyer, James C. Norton, Bruce L. Parlley, William H. Paxton, Jake Ratliff, Barbara E. Row, Martha E. Trun~y, Edwar~ K. Van de Riet, John M. Yarborough. The following former ARC staff members also contributed to the researehl Donald I. Andrews, Rocer D. Bates, David A. Evan., Stephen R. LeVine, Stephen H. paavola, Helen H. Prince, Jon. F. Ru11tson, Elmer B. Shapiro, F. K. Tomlin. v CONTENTS ABSTRACT ••••••••••••••••••••••••••••••••••••••••••••••••••••• 1i1 PREFACE •••••••••••••••••••••••••••••••••••••••••••••••••••••••• v LIST OF ILLUSTRATIONS ••••••••••••••••••••••••••••••••••••••••• ix I INTRODUCTION •••••••••••••••••••••••••••••••••••••••••••••••• 1 A. General ••••••••••••••••••••••••••••••••••••••••••••••••• 1 B. Relearch A~proach and Strategy •••••••••••••••••••••••••• l C. principal Ooncerns During the Contract period ••••••••••• 2 D. structure of This Report •••••••••••••••••••••••••••••••• ) II RESOURCES AND ACTIVITIES ••••••••••••••••••••••••••••••••••• S A. Introduc~1on •••••••••••••••••••••••••••••••••••••••••• •• S B. Re.aureel ••••••••••••••••••••••••••••••••••••••••••••••• S C. AC~1vitie8 ••••••••••••••••••••••••••••••••••••••••••••• 19 III APPLICATIONS AND EXPERIENCE •••••••••••••••••••••••••••••• 2) A. IntrOduction ••••••••••••••••••••••••••••••••••••••••••• 23 B. The Augmented Software Eng1neer •••••••••••••••••••••••• 24 C. The Augmented Manager •••••••••••••••••••••••••••••••••• 63 D. The Augmented Report-Writing Team ••••••••••••••••••••• 10) E. The Augmented Presentation •••••••••••••••••••••••••••• 112 IV THE NETWORK INFORMATION CENTEW ••••••••••••••••••••••••••• 119 A. Overview of the ARPA Network •••••••••••••••••••••••••• 119 B. Some ot Our Pro8peetive Uses for the Network •••••••••• 122 C. Need for a Network Information Center ••••••••••••••••• 12S D. NIC Development Activity •••••••••••••••••••••••••••••• 126 E. current NIC Plan •••••••••••••••••••••••••••••••••••••• 129 V CONCLUSIONS. RECOMMENDATIONS, AND PLANS ••••••••••••••••••• l)) A. Introduction •••••••••••••••••••••••••••••••••••••••••• 133 B. Conclu8ions Relevant to Other Augmentation-System Deve1opers •••••••••••••••••••••••• 13) C. our General orientation Towards Future Research ••••••• 146 D. Overview of Current Augmentation Research Oenter Plan ••••••••••••••••••••• 1S0 Appendix AI User Features of NLS ana TODAS •••••••••••••••••• 17) BIBLIOGRAPHy ••••••••••••••••••••••••••••••••••••••••••••••••• 195 DD FORM 1473 ••••••••••••••••••••••••••••••••••••••••••••••••• 199 vii ILLUSTRATIONS Figure 11-11 XDS940 COMPUTER FACILITY ••••••••••••••••••••••• 6 Figure II-21 SPECIAL DEVICES CHANNEL •••••••••••••••••••••••• 7 Figures 111-1 through 111-281 PHOTOGRAPHS SHOWING NtS DISPLAY IN USE BY A SOFTWARE ENGINEER •••••••••••••• 3S-62 Figures 111-29 through III-56. PHOTOGRAPHS SHOWING NtS DISPLAY 01 MANAGEMENT INFORMATION FILES ••••••••••• 7S-102 Figure V-11 "HERMAN MILLER" CONSOLE ••••••••••••••••••••••• 137 Figure V-21 ONE-PIECE CONSOLE ••••••••••••••••••••••••••••• 138 Figure V-3. CURRENT CONSOLE DESIGN •••••••••••••••••••••••• 139 1x I A. INTRODUOTION General The AUlmentatlon Res.arch Center (ARC) is a community ot relearChers, lupported by .everal contract .ponlor.. It 1. 4edicatedto explor1nl the pOI.ibi11tie. tor aUlmentinl the intellectual activitiel ot people working in complex problem-.olvinl .ituationa. By "augmentation" we mean increalinl the capability ot a per.on or orcanilation to approach complex situation. and identity problem. pre.ent there, to lain comprehenlion ot the nature and context ot the.e problem., and to derive .olution. latiltyinl liven constraints. Such increaled capability may be retlected in any ot the tollowinc way', falter and better com~rehen.len. the pOI.lbi11ty ot IIin1nl a u.eful decree ot comprehenlion in lituationa that were previou'ly too complex. talter and better lolution., and the po •• ibl11ty of tindinl solution. to probleml that previou.ly .eemed insoluble. B, Relearch APproach and stratelY ARC" orientationil baled on the tact that modern man 1. contronted with problem. ~t increaainc complexity and urleney, and the allumption tbat in att~cklnc the.e problem. the be.t lenl-term paYOff. will more likely come throulh the development ot more powerful problem-,olvin, tool. ot a ceneral nature thanthroulh direct, piecemeal attack' on .pecific proble•• ot immediate urleney, Thil orientation wa. Ipelled out in 1962 1n a Plann1nl document (Ref, 2) ~h&t provide~ ~he concep~u.l framework under WhiCh ARC ha. been evolvln,. (Note. reterence number. are no~ conlecutive 1n thi. report, but reter to ~b. Chronolollc&l bibl1olraphy.) our approach to aUlmentation re.earch ha. two e •• ential a.pect •• ~be ext.rnllll&~ion ot lntellec~u&l .tructur.sln .ymbollc torm, makine UI. ot hi,h1Y interactive computer ly.te.l, and the apPlication ot a boot.trapp1nl _ .tra\ecy in there.earch prolram tor developine aUlmentatlon .y.tem •• The ~urpo.e ot externalilation via computer IYlteml 11 to makelt po •• ible lor people to work with intellectual structure. (.uah al computer prOlram. or hilhly int.rconnec~ed bodie. of textual information) of much creater .1ze and complexity than can be ettec~uall~ handled with traditional ~echn1que., The a1m 1n de.1lninl the computer .y.~em. hal -been to provide people with the 1 I INTRODUOTION Sec~lon lncrea.incly flexible and powerful way' of usinl .tructure. Of .ymbol'~o repre.ent intellectual structures and 01 viewinl and mani~Ula~inl ~hese symbolic .tructure •• The boot. trapping .tratelY hal been used in order to enlure the tightelt PO"1blef.edbac~ 1n the procels of developlnl aUlmentat1onaid. and in order to catalyze the re.earch prolram by brincinc higher and hie her level. of aUlmentation to the researchers them.elvel. All aUlmentatlon aid. designed by ARC are~ntended for actual, ~ractical ule in ARClt.elf,and once implemented they are, tor the mOlt part, uled heavily on a day-to-day balls, C. Prlncipal Concerns Durinl the Contract Period DUrinl the period COYered bY thi. contract, three onloinl procelle. reflected ~he principal concerns of ARC. the fOllowinc lection. de.cribe the.e procelse •• 1. NLSDevelo~ment At the end ot the previoul contract period (lee Ref. 12), the multi-u.er On-Line SYltem, NLS (whiCh had been developed from prlviou •• inlle-u.er .y.teml), had been carried trom the earlY dell In stale. throulh almo.t complete implementation. Durinl the .ub.equent two yearl, NL~ha. developed into an experimental operational Iy.tem that 11 now in heavy routine u.e by the ARC .tatf. ARO re.ources have been heavilY committed to lncrea.inl the operational .peed and reliability 01 the many component. of the .,.tem, improvinl the interaction otthe.e components within the total .ystem, and improvinc and extend in I the u.er features at the .y.tem. 2. Evolution of Goal_ One u.ale trend that hal become evident durinl this periOd 1. a tendency tor .taft member. who are workinl on a common proble.to cather around an NLS con.ole 10 a. to have on~line acce.. I I a croup to the working 111e. that they are u.inl in common. Even When working individUallY, croup member. trequentlf .it at neilhborlnc con,ole •• 0 as to be ablato converle about related ta.k. in prOlres •• Thi. trend hal been reflected, throUlh boot.tr,pplnc, I I an evolution ot ARO loal. trom the augmentation ot individuals 2 Seotion I INTRODUCTION to the augmentation of task-oriented teams. MUCh thought has been put into deciding which areas of research seem to offer the greatest promise for improving the ability of aUlmente~ individuals to cooperate on a common problem, ano during the next few years one of the major activities at ARC will be the development of team-augmentation facilities and techniques. Some of the developments currently being eonsidered are discussed in Section v. 3. ARPA Computer Network Participation During the contract period we completed plans for connecting ARC's computer facility into the ex~erimental ARPA Network, which eventually will link the computer facilities of about 14 computer-science research centers. We feel that the Network is a significant step in the evolution of augmentation technology, and we are working with the other Network participants in orOer to ensure the success of this experiment. We have a&reed to provide a Network Information Center (NIC) for the Network, and over the past two years we have been committing an increasing portion of our resources to the ~lanninl and development of NIC services. We expect that ~he success of ~he Network experiment will be significantly affected by the quality of services that the NIe can provide. D. Structure of This Report The remainder of thiS report is divided into four major sections and a supporting appendix. We have attempted to describe What we have done and learned during the palt two years, without elaborating either on the technical details of our hardware/software system or on the past history of our re.earch program. These latter topics are covered in the references cited in the Bibliography of thiS report. In particular, the following may be Of interest: The 1962 planning document (Ref. 2) provides the conceptual background for our approach to aUlmentation research, 3 I INTRODUCTION Sec~ion The 1968 FJCO paper (Ret. 14) eives an overview of our Augmen~ation Research Center, The 1970 final report for another spon.or (Ret. 18) di.culsel many technical details ot our s,ltem implementation. Seetlon II of th1s report describes the resources _. human, orlanlzat1onal, har~ware, and sottware _. ~hat ARC hal available tor its re.earch and discusses ARC's ong01nl activities. This material is .upplementea bY APpendix A, Which briefly describes several of the primary elements ot our aUlmentatlon system. Seetlon III is a colleetlon ot sUbjec~1ve descrlptions ot our experience augmented worker. 1n several ot ARC" central activities. Two of the de.eriptlons (tor software encineerinc and man&lement reaearch) are supported by illustra~ed scenario. showine actual work in progress. &. Section IV contains a description of the ARPA Network from a u'er's standpOint and a discus.1on of some prObable, early uS.S ot the Network. We point out lome of the service. that Network participants will need in order to make effec~iv. ule ot the Network and lndicate how we are attempting to .atilty those needS through the Network Informatlon Center. In Section V we discuss lome ot the conclu.1ons drawn trom our relearch and indicate the directions 1n which we plan to develop our re.earch 1n the fu~ure. II RESOURCES AND ACTIVITIES A. Introduction In this lection we describe the resources th&t have been available to us during the past two years and the activities we have undertaken to appl~ these resources to the pursuit of our augmentation goals. We use the term "resources" in tne broad sense to include all the assets we possess as a team, including the followingl (1) Hardware facilities (2) System software ()) User systems (4) Personnel (human resources) (5) organ1zat1onal relationships. Our major organizational relationships are to SRI and to the ARPA Network. The Augmentation Research Center operates at the grou~ level within the SRI Information Sciences Laboratory and, consequently, has access to the extensive and varied reaources available through a larie. diversifieC re8e&rch organization such as SRI. As an initial participant in the ARPA Network. we will have access to all services that eventually become available through the Network. The implications of this are explored in Sections IVana V of this report. Our other resources are ~i8cusse~ in some detail below, along with brief descriptions of our major on-goin, activities. B. Resources 1. The Computer Facility At the begining of tne contraet periOd the current ARO computer facility was almost complete, and the basic coniiluration has been relatively stable over the past two Years. This Section briefly describes this facility (diagrammed in Figures 11-1 and II-2) and discusses some of the changes and additions made during tne contract period. The most sig1n1ficant additions have been the ARPA 5 CONSOLE TTY COMMUNICATION EQUIPMENT MAGNETIC TAPE MAGNETIC TAPE CONTROL CENTRAL PROCESSOR WITH TIMESHARING HARDWARE ~""'---4 MAGNETIC r- TAPE MAGNETIC TAPE PAPER TAPE STATION 16 Te etypes I I I 16 K CORE I CONTROL: RAD 16 K CORE 16 K CORE 16 K CORE SPECIAL DEVICES CHANNEL TA-5919-3R FIGURE 11-1 XDS940 COMPUTER FACI LlTY T.V. Monitor DISC CONTROL DISPLAY CONTROL DISC FILE 5"C.R.T. T.V. Camera o Keyset Keyboard DISPLAY GENERATOR 12 NLS Consoles To MIC DISPLAY CONTROL DISPLAY GENERATOR 2 2 EXECUTIVE CONTROL NETWORK INTERFACE o ARPA Network INPUT DEVICES CONTROL LINE PRINTER CONTROL LINE PRINTER TA-7101-3 FIGURE 11-2 SPECIAL DEVICES CHANNEL Seetion II RESOURCES AND ACTIVITIES Network interface and an external core system. A more complete description of the facility 11 contained in Refs. 11 an~ 18. a. The Leased computer Figure 11-1 is a block diacram of the facility as lea.ed trom XDS. A central processor with timesharing hardware operates trom a 6hK memory in four bank. with 24-bit wordS and a cycle tiMe of 1.8 microseconas. On channels Sharing memory access with the CPU are three magnetic-taDe arives, a paper-tape station, and eommunication equipment for Sixteen typewriter terminals. A second memory bUSI provides ~1rect access to memory for the RiDs (Rapid Acce.! Devices -- e.g., drums) and the non-XDS portion of the facility, designated "Special Devices Channel" in Figure 11-1. There are three drums on the system, operat1nl trom a common controller and aecesainl memory through an XDS device called a Direct Accels commmunieation8 Ohannel (DACO). EaCh drum has a capacity of 500,000 24-bit wordS, a transfer rate of 120,000 words per .eeond, and an average latency of 17 m1111seeon~s. b. Special Devices Channel Figure 11-2 is a block diagram of the ~ortion of the facility that has been put together bY ARC. The following sections describe the major component •• (1) Executive Control The executive control prov10es an interface to the 940 through the Memory Interface connection (HIe). It acts as a multiplexer that allows asynChronous access to core by any ot the six aevices connected to it. It includes extensive debugging and monitorinl &108, allowing the monitoring of data and addresses tor any 8 Section II RESOURCES AND ACTIVITIES selected device and permitting "off-line" operation of any of the devices. (2) Disc File System The disc file system was put in operation in August, 1966. It consists of a Bryant Mo~el 4061 disc file and alsociated controller. The system hal a capacity of 32 million words, an average access time of 18S milliseconds, and a data transfer rate of 43,000 words per second. The disc controller was designed and built by Bryant to interface with the executive control. Specifications for the controller were develope~ jointlY by Bryant, Project GENIE at UC Berkeley, and ARC. (3) Display system The diSPlay system consist. of two identical SUbsYlteml, each with a diSPlay controller, a display generator, and .ix high-resolution S-inch CRTI. A closed-circuit television system carries display 1mage. trom the CRTs to television monitors in tne working area. The display controllers were desilned and built by ARO. They access an~ procels "command tables" that are resident in 9kO core. A command is roughly assoc1ate~ with a user and pOints to a "~isplay list" in the user's core space. The display list in turn pOints to buffers containing actual display instruetions (commands to the display generator to prOduce imltes). ~i.play controller han~les all core accelainl. inclUding memory mapping for tne user"core apace. xt pa.ses the display in.tructions along The to the display generator. The display lenerator. and CRTs were purchased from Ta8ker Instruments to ARC's specifications. They have general character and vector capabilities. Presentations for each of the six ORTs are 9 Section II RESOURCES AND ACTIVITIES generate~ sequentiallY, ~he display controllers CRTs at a liven time. ana unblank sienall from select one or more of the A h1gh-re801ut1on (87S-1ine) closed-circuit television Iystern transmits ~1splay pictures trom each CRT to a television monitor at a correapond1nl NLS console. (4) Input Dev1ce control In addition to ~he television monitor, each con.ole has a keyboard, a binary keyset, and a mouse. Appendix A Cescribes the use of these devices. The state of these input devices is read by the 1n~ut device controller at a preset interval (about )0 milliseconds) and written into a fixed table in 940 core. Bits are added to information from the keYboards, keysets, and mouse switches to indicate When & new ch&raeter hal been received or When a Iwitch haa cbanle~ state during the sample periOd. A new ch&raeter or switch change causes an interrupt to be issued at the end of the sample period. Mouse coordinates are dilitized by an AID converter an~ formatted by the input ~ev1ae controller as beam-position instructions to the display generator. A user procr&m may include the mouse coordinates, as wr1tten by the input ~ev1ce controller, al part of a ~1spl&Y list. Tnis allows the mouse ~olition to be continually di.played with no attention from the CPU and no perce~tible delay to tne u.er. (5) Line Printer The line printer 1s a 96-character drum ~rinter leased from Data Pro~ucts Oorporation (Model M600-11Al. With the 96 characters, printing Ipee~ il 340 lines per minute. The line ~r1nter controller proceases print butters Of arbitrary length that have been let up in core by a controlling program (lingle-line buffer. are 10 Section II RESOURCES AND ACTIVITIES normally used). (6) Network Interface The network interface provides communication between the 940 and an Interface Message Processor (IMP) on the ARPA Computer Network. The int.erface operates from message buffers in 940 core. Messages to the Network are read by the interface from these butfers and transmittea to the IMP. Similarly, messages received trom the IMP are written 1nto buffer space in 940 core. Instruetions from the 940 enable the system for receiving messages and control the sending of messages. A "linked-buffer" scheme permit.s flexible memory allocation. The interface message processor and its commu"ications protocol are discussed in detail in Ref. 19. c. Typewriter Terminals At the beginin, Of the project the onlY terminals in use (other than the display consoles) were Model 33 Teletypes. Since then we have been experimentinc with ~ifferent type. of terminals. lOOking for improvements in speeo, print quality, and portability. The newer terminals now in use, and some Qf their features, are briefly Oescribed in this section. It ShoUld be remembered that tbe only terminals we have considered are those with upper- ano lower-case print and fUll-~uplex o~eration. (11 The Model 37 Teletype was one of the first terminals added. and three are now in use. It operates at 15 characters per seeond (as compared to 10 eharacters per second for the MOdel 33) and has excellent print quality and rei1ability. It hal a high noise level and is laree and heavy. (2) We have four GE Terminet-300 terminals in use. These have .wi~ch-seleetab1e rates Of 10, lS, and 30 11 Sec:t.ion II RESOURCES AND ACTIVITIES characters per second. The~ nave a cha1npr1ntinl mechanism that is relativel~ Quiet and have good print quality when in adjustment. These terminals seem to require more freQUent maintenance than any others in use, but we have early models and the~ may improve in later produc:tion. (3) The best terminal we have found for portability is the Execuport, manUfactured by Computer Transceiver Systems. These terminals are used by our staff for remote operations, usually in a staff member's own home, and come in a portable case complete with acoustic: coupler and weighing only 26 pounds. They have switch-selectable rates of 10, 15, and 30 characters per second. The thermal print mechanism is very quiet in operation but print quality is poor; characters are made from a S x 7 dot matriX. d. MOdifications in Progress mo~1ficat.ions to the facility that will provide significant improvement in service are now heing implemented. These are an external core syst.em and faster drums. In addition, an accurate clock system is being added. TWO (1) External Core system An external core system has been completed and will be integrated into the facility in the near future. It currently consists of a lingle 32,OOO-word bank with access switching to allow access by u~ to eight devices. provisions are inclUded in tne design for expansion to 16 devices and two core banks of 64,000 worC1s eacn. The core cycle tim-e is 1. S microseconds and the word length 15 24 bits. The primary purpose of this core system il to provide storace for display buffers, the network interface, and the line printer. These are tne devices that need constant buffers for relativelY long periods of time and therefore require "frozen pages" when 12 Section II RESOURCES AND ACTIVITIES operating from 940 core -- a 'ign1ficant factor in limiting system response, since tbay take up space that could otherwise be used for swapping. (2) Faster Drums From system response stUdies (Ref. 18) it is apparent that a primary factor in re8ponse is the swapping ban~w1dth. TO improve response (an~ add More users), we are in the process of replacing the XDS drums with Univac FH-432 drums. These drums rotate at 7200 RPM, ~1ving a transfer rate of 365,000 words per second (as compared to 120,000 for the present drums) and an average access time of about 4 milliseconds. In addition, we are formatting the new drums in a way that will allow a page transfer to begin at any position on the drum. Since a 20h8-word page fills two-thirds of a band, this will give an average page transfer time of about 8 milliseconds. The interface for the drums will be deSigned and built by ARC. It will connect to the 940 through a second Memory Interface Connection (MIC). replacing the current RAD-DACC combination shown in Figure 11-1. ()) Clock System An accurate clock system is being added to assist us in system measurements. This eloek Iystem provides two type, of time information -- absolute and relative -- that are written into fixed location. in 940 core at regular intervals. The long-term drift on the clock will be less than 1 second in 250 days. 2. Software Systems The central foeus of software aetivity at ARO i. tne evolutionary development of the On-tine SYstem (NtS). This takes place within a rich environment of .oftware systems. many of which were created .pacificallV to aid in its 13 Section II RESOURCES AND ACTIVITIES development. The major 8ys~ems. a. f~llow1ng i. a brief ~elcript1on of the The Timesharing System (TSS) MOlt basic to the o~eration of NtS. as well as all our other software systems, is the timesharing system (TSS) running on the XDS940. TSB was originally developed by Project GENIE at UO Berkeley, but responsibility for maintenance of the ARC version currently lies with the Center itself. Nt! runs as a sUDsystem un~er TSS, ana users allo have accels to other subsystems such as the NARP assembler, KDF file storage Iystem, and DDT debugging system. The 8u~port of new har~ware and improved res~onse to the NtS user are the major areas of improvement in TSS over the past two years. b. Software Architecture (1) Intro~uctlon The development of NLS has been facilitated greatly through the use of a powerful complement of lanluagel and compilers, mOlt of which were designed at ARC. The languages used range in generality from the NARP assembly language through a collection of special-purpose languages (SPts) unique to NLS implementation. Their major features are discussed brieflY below. (2) NARP A few parts of NtS can be most conveniently COde~ in assembly language (e.g., the data page an4 tne diSPlaY-buffers), and tor these the NARP assembly language is used. Also, tor historical reason., the timeSharing system (TSS) and most ot its SUbsystems (e.g., KDF and DDT) are coded in NARP. Section II RESOURCES AND ACTIVITIES ()) MOL940 MOL940 (or .imply MOL) is a machine-oriented language for tne XDS940 and wal created by ARC to a1d in the programming of NtS. MOL combine. the flexibility of assemblY language with the algorithmic clarity ot higher-level procedure-oriented languages. MuCh of NL! 1s coded in ~OL. During the contract period MOL has been SUbstantiallY rewritten to improve its pertormance and provide new programming features. The current MOL compiler was produeed Using the new version of Tree Meta (described below); consequently. the MOL compiler now generates binary machine code directly rather than producing assembly-language code as an intermediary. (4) Special-purpose Languages (SPLs) Many of the higher-level operations ot NtS are carried out by programs written in one of a set of special-purpose languages (8Pts). Each of these languages 11 translated into machine COde by a custom-made compiler produced with the Tree Meta system. Each SPL represents an attemPt to formalize a particular function of NLS, aiming at a syntax appropriate to the data base and operations required for NtS, while at the same time embOdying the potential and peCUliarities of the XDS940 computer. The four SPLs currently in use are the input-feedback langUage, the structure-manipulation langUage, tne content-analysis language. and the strine-construction language. Detailed ~elcr1ption8 ot the SPLS will be found in Appendix D of Ref. 18. AlthOUgh extensive chanles in the SPLs are planned for the near future, no basic conceptual change. were made during the contract periOd. 15 Section II RESOURCES AND ACTIVITIES (5) Tree Meta Tree Meta i5 a compiler-compiler developed at ARC; it is used to produce compilers for MOL, for all the special-purpose languages, and for itself as well. Section IV-C-2 of Ref. 18 con~ains a brief overview of the current version of Tree Metaj a more detailed description is in preparation for release as a separate report. c. NUTILITY TO aid our software engineers in maintaining the aoproximately lS0 symbolic and binary files that make UP NLS, a special subsystem called NUTILITY has been developed. This SUbsystem can archive or retrieve any of these files. compile or produce listings for any of the source-code files, and load the entire NLS system or any part of it, requiring programmer interVention only in the event of errors that NUTILITY cannot handle itself. 3. User Systems This section brieflY describes our principal on-line user subsystems; more complete deseript10ns are contained in Appendix A. a. On-Line System (NLS) The On-Line System, NLS, as currently implemented, is & highly SOPhisticated system oriented toward the on-line construction. editing, and viewing of files. NtS is a SUbsystem of the timeSharing system described above. Its size is currently about thirty thousand machine instructions, of which about half make up the mOlt frequently used portions. The source languages used are NARP, MOL940. and the SPLs. A complete description of NLS, incluOing program Oocumentat1on, is in Ref. 18. 16 Section II RESOURCES AND ACTIVITIES b. Typewriter-oriented Documentation-Aid System (TODAS) In response to growing pressures to make access to our on-line files available to Network participants, as well as to members of our own staff working at remote locations, we develo~ed a new SUbsystem called TODAS (Typewriter-Oriented Documentation-Aid System). TODAS uses the same structure for working files as NLS and provides most of the same editing and view-specification capabilities, along with a few special features of its own. Thus, users can freely move from one type of terminal to another without losing access to any of tneir on-line WOrking records. TODAS offers our on-line users the possibility of trading off speed of operation for freedom of location. It also makes 1tpossible for us to increase the number Of on-line users that can be serviced simultaneously, since a TODAS user places less heavy demands on our computational resources than does an NLS user. c. output Processor (PASS4) The output Processor (alSO called "PASS4" for historical reasons) i8 a program for formatting on-line text files for output through a variety of devices inclUding line printers, paper-tape-driven typewriters, and computer output to microform (COM) devices. 4. Personnel The linal, critical element of ARC's resources is its staff of prOfessional researchers and support personnel. The experimental nature of our work requires high-caliber individuals who can function effectively in our team. learn quickly to work with our systems &n~ methOdologies, and progress creatively along with the rest of the team and its products. our staff members need to be able to a~apt to the rapidlY changing ARC environment and to persevere through very disturbing periOdS Of system service level fluctuation. Our selection of people for specific taskS is influenced not only bY skill. already developed. but also by , 17 Section II RESOURCES AND ACTIVITIES potentials for further develonmeni. Effective utilization of our human resources requires a careful balance between select1nc those people most likely to get critical tasks ~one well and tnose whose ~eveloped capabilities will be straine~ by the tasks they undertake (and hopefully extended in the process). In ARC's earlier years our primary need was for individuals skilled in tool buil~ing~ with only secondary importance assigned to methOdology development skills. ThU8, most of our ~ar11er researchers were system-oriented software an~ har~ware engineers. As the systems developed became more generally usetul, providing aids and service levels beyond the system engineers' basic needS, we entered a maturing phase of facing the challenge to use the system for a broader range of tasks. PeOPle nave recently been adae~ whose interests focus on the stuay of tne user system itself~ on use of the system for management purposes, an~ on its role in supporting the Network Information Oenter. These people have brought different needs an~ perspectives into the grou~, directly aiding the ttesign of many system improvements. Interaction at the day-to-day system development level has provided & rich learning exper1ence tor most people, particularlY in technical area. they might not otherwise have learned mUCh about. This diffusion of knowle~ge in areas SUch as system design, system builOinl, system analysis, and management adds new perspective to each perlon's approaCh to prOblems in hi. own area. of specialization. 18 II RESOURCES AND. AOTIVITIES Sec~icn At present we have a full-time Itaff of 25, constituted AI follows: Prcfesl10nal ••••••••••••••• l8 Supervisory..... 1 Softwlre •••••••• 11 Hardware • • • • • • • • 4 Other ••••••••••• 2 Non-professional........... Technical....... 7 3 Clerical • • • • • • • • c. ActiVities 1. IntroQuction Tbis .ection outline. the nature and purposes of the major activ1tiea carrieO on durinl the pa.~ two years of our project. It was the pursuit of theae activities that produced tne developments, experiences, and conelusions disculsed in the other sections of this report. The greate.t portion of our resources were allocated to the basic ARC bootstrapping pursuit, which consists of, these major activities: (1) Development and operation 01 our .erv1ce s,.tem (2) D.evelopment of methodologiel for harnes.ing the user features offered by the service s,stem (3) APplication of the •• aUlmentation tools ana to the pursuit Of all our activ1tles ~echniQu.1 (4) A.sessm.n~ Of our overall augmentation ay.tem to guide it. further evolution. 19 Section II RESOURCES AND ACTIVITIES other major activities received considerable attention and resources: TWO (5) Oonnection of our Oenter into tne (6) Develo~ment Network. 2. Develo~ment and ARPA Network of an Information Center for the operat~n of Our service system The coordinated develo~ment of hardware and software aspects of our augmentation system. which has been under way since 196), was continue~ w1th particular em~ha.11 on activities aimed at preparing us for our role in the ARPA Network. We have committed a sUbstantial portion of our resources to improving the reliability and capacity of the service system and will continue to do 80, a major milestone beinc our ~lanne~ transfer to a PDP-10 computer this fall. Another major effort hal been preparation for expanded remote-worker eapabilities. both to fac1litate use ot our system by other Network participants and to continue our efforts to increase the flexibility of workinl arrangements for member. of our own research commun1ty. There 18 alreadY one member of our team (a software encineer) who work. remotelY from hi. home in sonoma county (about 100 miles from our Center), and we bave plans to exten~ this capability to other members a8 conditions permit. 3. Development of Methodologies for Harne.sing the User Features Offered by tne Service System It hal lone been part of our ~lans to apply toward this activity relourcel com~arable to thOle for the .erv1ce system development activity, but unloreseen difficulties 1n the latter area have force~ UI to divert more of our energies to it than was oricinally anvi8 ed. H6wever. many methodolocical developments have ~een evolving more or less naturally al individuals adapt the features of the service system to their particular needs. The stronlest ,uch evolution has taken place within the area of software engineering, which 1s the focus of 20 Section II RESOURCES AND ACTIVITIES consistently heavy activity by many of our people. In one specific area _. management system ••• we have enga~ed in an explicit effort to develop improved methodology. Th11 hal been tunde4 separately bY a contract with the Rome Air Development Center, Which has enabled UI to ap~lY one or two fUll-time people towar~ this Management Systems Research activity for the past two years. 4. APplication of AUgmentation ToolS and Techniques to the Pursuit of All our Activities Our augmentation system is in daily use by most members of our staff. Detailed discussions of several exam~lel of this use are given in Section III. S. Assessment of Our Overall Augmentation System to Guide Its Further Evolution One of the basic requirements for carrying out a bootstrapping o~erat1on is to maintain constant awareness of the status of that operation so as to be able to make rational decisions about what developments Should be undertaken next. We have made some attempts to quantify this process through the taking of system performance measurements and the Simulation of various existing and proposed system configurations. However. most of our work in this area still has a very intuitive character, and we have oeen hampered in our efforts to improve on this bY the necessity for committing so much of our resources to basic service-system development activities. 6. Connection of our Center into the ARPA Network To make it pOSSible for ARC to participate in the ARPA Network (8ee Section IV). we had to design. build. and install a device to interface our computer facility to a Network Interlace Mesaage Processor (IMP). Thi. Network interface is described in section II-8-1-f. 7. Development of a Network Information Center (NIC) In ~reparinc to f111 our role as Information Center for the ARPA Network. we have been involved in developing the tools and methOdologies that we will need in order to provi~e an 21 Section II RESOORCES AND ACTIVITIES increasingly on-line, special-purpo.e library for a widelY distributed clientele. The high technological base of this Network experiment demands that we try to harness a8 much as possible of th1s teehnolog~ for the Network Information Center 10 that this service will be likely to enrich the whole experiment. In addition to investing our resources in special-purpose capabilities for the NIC, we have felt compelled to increase our investment of resources in basic service-system development 10 as to be able to supply a better level of service to Network participants, We had to get our system architecture, our compiler languages, our documentation, and our hardware configuration into a state where we woulO be able to expan~ our user-carrying capacity rapidly. This led to a number of major efforts: (1) A series of significant architectural and compiler changes within our software systems (2) Several rather intensive trial designs for alternate expanded-capacity system configurations (3) A concerted effort in developing computer aidS for analyzing performance characteristics of proposed s~stems. These efforts culminated in a decision to move our systems onto a PDP-10 computer late tnis fall, and we are currently involved in the leaSing, purchasing, contracting, engineering, fabricating, and programming activities necessary to accomplish thi. tran.fer. 22 III A. APPLIOATIONS AND EXPERIENCE Introduction This section consists of relatively informal accounts deleribing the apPlication of our augmentation systems to several areas of our own work While attempting to convey some feeling for what it is like to work within an augmented total system. Section 111-6 was written by Charles H. Irby, an ARC software engineer. It describes in considerable detail the waYI in Which an augmented software engineer can exploit our com~uter 'Yltem. to help him in the continuing development of the.e same systems. In addition, Section 1II-B serves as an introduction to our On-Line system, NLS. It is systematicallY illustrated with ~hotographl of an NLS display, showing actual sequences of displays that the software encineer WOUld see a. he worked. (Readers who are not familiar with NLS will find a description of its user features in Appendix A, which inclUdes a glossary of .pec1al NLS terminology.) Section 111-0 deals with "augmented management" and wa. written by James C. Norton, who headS our Management Systems Re.earch Activity and is also involved with carrying out much of our o~erational project management. This section, illustrated with display photograPhs like those of Section III-B, shoWS how lome of the mOlt sophisticated features of NLS can be put to ule in a field outside Of softWare engineering. SpecifiC applications to project eost accounting, eo.t estimation, work Planning, and other areas are covered. The discussion develops a total-system concept of the meanings of "management" and "management augmentation" and reveals how augmentation interact. with various a.pects of ARC. Section III-D describes our use of augmentation sYltem. in writing, editing, and prOducing report.. The author of this section, David Casseres, il ARO" technical writer and has been centrally involved in ARC report writing since the inception of this contract. Here we lee the u.e of augmentat10n systems 1n & field Where it is difficult to applY them, becau.e the ~roblems of technical writing are 80 many and so dependent on individuals, 23 Section III APPLICATIONS AND EXPERIENCE It appears that although the benefits ot augmentation in writing, editing, ana producing reports are con.iderable, the most sicnificant benefits come from the u.e of a very close team-collaboration method, which would be virtuallY impossible without augmentation. Section II1-E was written by Douglas C. Encelbart and covers the augmentation of communication between a speaker and his audience. Thi. kind of communication, Which we have used for explaining aspects of our work to audiences rancing from a single person to thousands, 1s potentially one of the most exciting areas of application for augmentation technology. B. The Augmented Software Engineer One of the central objects of our augmentation research has been to develop special tools and working methodS tor augmenting the design and implementation Of our system software. Section III-B-l belOW outlines the general augmentation needs of a 80ftware engineer and the aids provided at ARC to meet these neeOs. Section II1-B-2 describes the ways in which our software engineers actually use the systems we have been developinl in their daily work. We pay particular attention to the use of the system-guide file, SYSGD, which 1s central to the software-engineering augmentation sy.tem. The use of SYSGD i . illultrateO with photographs of an ARC interactive Oisplay. Ihowing the views seen by the software engineer as he works to implement a new NtS feature, uBing SYSGD as & reference. l. General Considerations The augmented software engineer nee4s tne following minimal eapab1litie., (1) The ability to rapidly accels, manipulate the source code 24 un~erstand. and Section III APPLICATIONS AND EXPERIENCE (2) The ability to easily compile the source co~e (3) Easy acce.8 to appropriate loading and debUlging capabilitie •• The NtS, TODAS, NUTILTY, DDT, and di.c archive .ub8Y8~em. together with the SYSGD source-code file directory provide the ARC software engineers wi~h the,e capabilities. To the ARC lottware engineers, the aspects of Nt! that are perhaps of most importance are the ability to find a particular place1n the code or documentation Quickly an~ then to change it easilY. Our co~e ana documentation tiles are normal NtS text files, and the languages that we use have been specially developed to be compatible with the NLS system. These language, are all 8tring·base~, and translation is independent of the hierarchical .tatement structure. This permits the programmer to u.e structural conventions to make his source-code text easier to understand and manipUlate. They allo allOW NLS link. to be Uled for identifier., thUS permittinl one to u.e the "jump" commands to follow lubroutine calls in the source cOde. In addition, level clippinl, line truncation, and so forth may be u.ed to control the depth ot detail Of the cOQe and as,sociated documentation that one seel. These are very important factor. in quiCkly finding a specific location (or .eries ot loca~1on.) in a file. content-analysis filterinli8 often used to locate references to variables or SUbroutines or to locate a partiCUlar piece of COde (tor example, code containing a syntax error reporte~ by the compiler). The content analyzer il al.o used to locate chanle. that have been made to a file by a .pecific prorrammer or dUring & .pecif1ed per1o~ of time by scanning the automaticallY maintained "statement signatures." These .icnatures contain the date of most recent modification for each statement and the1nitials of the user who made the modification anO may al.o be used without the content analyzer to .ee Who wrote (or la.t modified) each .tatement ot code or documentation and When he did it. When viewing a secment of a tile, the softWare engineer as Sec~ion III APPLIOATIONS AND EXPERIENCE must be able to easilY mOdify the text of the file. exten.ive editing ~ower of Nt! make. this possible. The The ability to easilY effect changes to various textual and structural entities and to make multiple s~rinl sUbstitution. over structural entities While controlling the selection of statements tor the substitution via level clipping, content analysiS, keyword reordering. and 10 forth gives one great flexibility and power while editing. In addition to being able to modify the code and as.ociated documentation quiCkly, the softWare engineer may compile (or cross-reference) hi. code files directly from NtS. Once again, he may use the statement-selection meChaniSMs of NtS to control what the compiler get. as input. This might be done, for example, to limit the compilation to ~u.t one branch of a tile (one specified Itatement and all itl sUbstatements), thu. making it pOSSible to have in a sinl1e file source code written 1n .everal different languages. We also have available as another SUbsystem the project GENIE on-line loader and symbOlic debugger, DDT, for testing and debugging the results of our ehange. to the code files. Although DDT works at the as.embly-language level, it is a powerfUl ~ebugler with such features a. multi~le breakpoints, symbolic ad~reslinl, single-instruction execution, conditional breakPointl, and 10 forth. To aid the software engineers in maintaining their a~~roximatelY one-hunOred-fifty or 10 symbOlic and binary files, a special .ubsys~em called NUTILITY was developed. Thi • • ubsY8tem is able to archive, or retrieve from arChive, any of the files, to compile or produce lilting_ for any of the ,ource tiles, and to load the entire system, requiring human intervention only 1n case ot errors. Central to our collection of source-code tiles is an on-line file called SYSGD. It containl the followin,. (1) A schematic diacram Of the overlay Itrue~ure of the Nt! system. The overlay. represent (al tar &s ~ract1cable) functional areas of the system, e.I., parameter specification, structure manipulation, and 10 forth. 26 Section III APPLIOATIONS AND EXPERIENCE (2) Links to other f11e8 that describe the architecture and logic of the system. (3) An overlay index li.t1nc all overlays, with the following information about each overlay: (a) A link to the file conta1ninc the lource code for the overlay. (b) Information about where it runs in core, how large it is, and where it i8 in the archive. (c) A list of all the ~roeedure8 in the overlay, with one-line functional descriptions and with links to the code and documentation in the source-code file. A procedure index with a categorical listing of according to function. The NtS keyword system can be used on this index to retrieve a list of ~rocedures (with links to the source COde and documentation) when a set of categorie. has been .elected. (4) ~rocedures (5) A system. section where one may document bugs found in the (6) A section where one may record ideas tor improving. the sYltem. Because of ~re8ent file-space problems, it is not pos.ible to keep the SYSGD file, the a.lociated documentation tiles, and the source-COde files on line at all time. (they are generally kept in a disc archive). This Situation renders the SYSGD file leiS useful than it would be it ~he tiles were alway. readily accessible. The combina~ion of the capabilities discu.sed above gives the ARC software engineer the ability to easily manipUla~e the NtS system to fit the needs ot ARC experimentation, thUS creatly increasing his own abilities as a loftware engineer. These capabilities would be creatly enhanced by the addition to NtS of an interactive incrementallanluage. Thi. would eliminate the time now spent on com~111nl ~art. Of the entire system and loading them in order to test Changes ma~e in the lource code of the system, and would allow one to debul at the source-COde level. 27 Section III APPLICATIONS AND EXPERIENCE 2. The Aucmented Software Engineer 1n Action a. Introduction This section i. in the torm of a Icenario, delcribinl how a loftware engineer works to 1m~lement a new NtS feature by manipulating files of text (both ~ocumentation and actual code). The reader is encouraged to pay 8~ecial attent10n to the following: (1) ~he eale with which one can move within and among tile 1 (2) The languale. that have been developed for particular purposes and the way in Which they fit into the NLS framework () The eale with which one can locate and modify it ~esired cOde (4) The delign of the NLS .y.tem-guide tile and the way. in which it can help the software engineer (5) The use of the NUTILITY SUbsystem to automatically archive. compile, print, and cross-reterence files a. well as to load new versions of the system (6) The use of the DDT debugcing program to te.t and debug additions to the system at the machine-language level. Pleale note al.o that one movea within and among files by means of "Jump" command.. At certain times when jumping, the u.er hal an opportunity to chanle the parameterl ("VIEWSPECS") that control the selection of information to be di.played on the acreen. For example, in the jump that occurs between Figure, 111-3 an~ 111-4 below. a "branch-onlY" parameter i8 set and the level-clipping and line-truncation parameters are let to "ALL". one may jump to a selected statement, to a statement that is structurallY related to the selected statement, to a statement having a eiven name, or to a statement speCified by a "link" (a textual con.truct that .ymbo11cally point. to a particular 28 Section III APPLICATIONS AND EXPERIENCE statement within the file or within another file). In a~dition, stacks ot display-start statement identifier. and VIEWSPECS are maintained for the last sevaral locations viewed within the file an~ tor the last several files aece.se~, &n~ jumps may be m&~e relative to these stacks so to restore a previous view. &. b. Notes on Illustrations In ~elcribinl the ~i.play views and the processes theY reflect, we aSlume that the reader is familiar with the user feature. of NLS to the extent that they are ex~la1ned in Appen~ix A. Appendix A also contains a glossary of soecial terminology, Nt! In examining the photograPhs, note that the name of an NLS comman~ appear. at the top of the display; this is the comman~ currently specified bY the user. ImmediatelY to the left of this "comman~ feedback line" is a small block of text called the "VIEWSPEC area," where VIEWSPEC parameters are di,playe~ on two lines, When the VIEWSPECS are ~isPlayed in small . characters, they are currently 1n effect; when they are enlarged, it mean. that the user has just let them and they will co into effect when the display is next re-created, The upper line shows ~he current level-clipping and line-truncation parameters (.ee Appendix A tor eX~lanat1on). The lower line in the VIEWSPEC area .hows code letters indicating the status ot various display features that are controlle~ by VIEWSPECS. c. Scenario and lllu8tration. Notec The illustrations for this scenario are grouped together, beginning on page 35. We log into the t1melharinc system, increase our drum 29 Sec~ion III APPLIOATIONS AND EXPERIENCE allocation, and en~er the NNLS (New NLS) IUb.ys~em eiving a set of initial. and & u.er name (lee Fieure III-l). The NLS display comes u~ (aee Fieure 111-2), and we load the NLS system-guide file, SYSGD, with level anC 11ne truncation let to one and with blank 11ne. dilplayed between statements (see Fieure 111-3). The major sections of the SYSGD tile (lee Fieure 111-3) are as follows. Program Overlay Structure (1) A diagram showing the overlay structure used in the current implementation of NLS (see Figure 111-7 below). Global Documentation (2) Links to other files that describe the tile structure, a.sign PhilOSOPhY, system architecture, and commonly u.e~ terminology of the Nt! system (lee rieures 1I1-~ and 111-5). overlay Index (3) A list of all Of the overlays in the system (each overlay represents & funct10nal area olthe Iystem) with pertinent data about each overlay (lee rigures 111-8, 111-9, II1-24, 111-25, and 11%-26 below). Catecoriel tor Procedures (4) Catecorical lilt of procedures, by function, to be used with the keyword retrieval .Yltem. tist of Known BUI' (5) A (6) ~lace where bUll may be recorded. Map of Symbols A map of symbols to be u.ed with the DDT deouI11nl .y.tem. 30 Section III APPLICATIONS AND EXPERIENCE Thoughts for (7) Im~rovements A ~lace where idea. about the further aevelopment of NtS, TODAS, and NUTILITY may be recor~e~ (see Figure II1-6). The initials ot the creator (or last modifier) an~ the date and time of creation (or mo~ification) are stored internally as the "signature" of each Itatement. Since statement signatures are available for dis~l&Y upon request, one can easily determine who made or last commented upon a given statement (see Figure 111-6). TheSYSGD file is basically a directory file with a sufficient amount of descriptive material so that one can use the various retrieval tools of NLS to locate any ~e.ireQ procedure or documentation. To illustrate how the SYSGD f11e is used, we go through the steps necessary for a programmer to implement a new command in NtS. The new command will be called "transpose" and will interchange two textual entities. The command language for u.ing this new command will be modeled atter that of the "move" command. Let UI begin (Figure 1II-7) with the diagram of the Nt! overlay structure. From the Ilobal dOCUmentation of the system we know that the main-control (mnctrl) overlay consist. of the code that implements the commanC2 language for NL! commands. We therefore use the "Jump to Vectorlabel" command to 10 to the branch within the overlay index branch that contains information about the mnctrl overlay. This in~orm&tion inclUdes the following (lee Figure 111-8)1 (1) A link to the source-code file for this overlay (2) A list ot all Of the procedures within the overlay (3) Brief documentation a. to the functions of each procedure (4) Links to each procedure's source code. See 31 Sec~ion III APPLICATIONS AND EXPERIENCE Figure 111-9; whereas Figure 111-8 shows only the first line of each statement, Figure 1II-9 shows all line. -. otherwise the two displays are the same. If we take the link to the "we" proce~ure (Figure 111-10), we see the top-level code for the NLS command language, written in one of the Special-Purpose Languages (see section II-S-l) designed for this use. Jumping to the "move" command code (Figure 111-11) an~ increasing the level-clipping parame~er by one, we see the top-level command-language code for the "move" command. Since this is to serve as a model for our proposed "trans~ose" command, we will copy the branch and make the necessary changes to it. The necessary changes are SUbstituting the string "Transpose" for the string "Move", "qt" for "qm", an~ "tr" for "m" (see Ficure 1I1-12). If we look at the code for the "move" command (Figure 111-13), we see that it makes calls on routines in the parameter-specification (prmspc) overlay to allow the user ~o make selections on the screen. and to routines in the text-editing (txtedt) overlay to implement the algorithms for the commands. Since the syntax for a procedure call permits an entire link to be used in place of & procedure name, we can use the "jump to link" command to see What these routines in txtedt actually do. If we jump "up" from the procedure pOinted to bY the link (Figure 111-14), we see that once again this code can act as a model since it only implements the delimiting of the selecte~ entities and goes to another routine, movetx,to actually move the text. We therefore copy this branch also and ma~e the necessary changes for the "transpose" command (lee bottom of Figure II1-14J Figure 111-15 is the lame as Filure 111-14 except that all lines are shown). The necessary modification. are changing the procedure names to correspond to our code in the mnctrl overlay and changing the name of the routine tha~il called to actually dO the 32 Section III APPLICATIONS AND EXPERIENCE tranl~oI1tion. The "jump to name" comman~ takes us to the movetx routine (Figure 111-16), which again serves as a mOdel tor our new routine, trantx. After out~uttinl the file we do "Jump rile Return u twice to let back to the SYSGD file. Thus our new command hal been implemented into the source code for NtS. We must now compile the main-control and text-editing overlays &n~ reload the system. Rather than do the compilation trom NtS, we will use the NUTltITY SUbsystem to both com~11e the files and load a new version of the system, which can then be run experimentallY under DDT (see Figures 111-17, 111-18, and 111-19). In Figures 1II-19 and 111-20, the new command is successfully tested. Let us now eontinue our examination of the SYSGD tile (for a reView, see Figure 111-)). AI shown above, the SYSGD file can be used to help one examine and mOdify the source code. There are al'o ways in which it can help one locate procedures of a liven functional type. The use ot the keyword system with the "index" branch and the use of the content analyzer on the "ovlind" branch are two examples of this aid. The "index" branch containa categorical listings ot the procedures in the system by funetion. U8inl the keyword retrieval system, one can select and weight categories and have the named entries (links to ~roceduresin thil case) presented in order of deereasing relevance, according to the user's weichting and order ot lelect10n. One may then take the links and examine the documentation and code tor each ~rocedure (see Figures I11-21, 111-22, and 111-23). The "ov11n~" branch ot the SYSGD tile contains information about each overlay in the system, inclUding lists of all of the procedurel, organized on an overlay basiS, with one-line explanationl of functions (see Fieure. 111-24 an~ 111-25). Since a brief description of each procedure'. function is associated with its name, we can use the content analyzer to help us find procedures of a 33 Sec~1on III APPLIOATIONS AND EXPERIENCE given type. For example. we can 1n.ert a content-analysis pattern to search tor atatements containinc ~he .tring "display" (Ieericure 111-26). We compile the pattern (.ee Fieure 111-27) and re-create the di.play with the content-analysis filterinc in effect. Now onlY statements containinl the strine "di.play" will be ,hown (see Figure 111-28). The result Of this content filtering on this branch of the file i- a list ot procedures that in 80me way deal with the display. Thi. ia & u.etul way to retrieve up-to-date 11sts ot procedure. of a liven functional type. _LOGOUT IRBY. DELETE SCRATCH FILES. TIME USED 0:0:0 IN 0:0:17 rOTAL TIME USED 12:15:11 IN 212:11:46 07/23/70 1107:03 ARC [3-') IS UP 1." -ENTER NLS. PASSWORD- OJ( 07/23170 1107:10 -CHANGE DRUM ASS ro 300. NEW D. A. = 300 OUT OF 300 _NNLS. Inltlals please: CHI User: lRBY TA-7079-11 FIGURE 111-1 LOGGING IN TO TIMESHARING SYSTEM AND ENTERING NlS SUBSYSTEM 35 1 1 HJLV :SYS6D LOAD FILE DUMMy r TA-7079-12 FIGURE 111-2 36 NLS DISPLAY BEFORE A FILE IS LOADED OR CREATED. command has been specified but not executed. A "Load File" ALL ALL GJLV JUMP ro I rEM :SYSGD. 07/23/70 0'.':37 C~I : (overlay) PROGRAM OVERLAY SrRuCrURE (doc) GlOBAL DOCUMENrArION 0 + (Ovllnd) OVERLAY INDEX & DEBUG INFORMArION (Index) CAtEGORIES FOR NLS PROCEDURES (Bugs) llsr OF BUGS (map) MAP OF SyMBOLS AND BINARIES (thoughts) r~OUG~rs FOR IMPROVEMENrs TA-7079-13 FIGURE 111-3 MAJOR SECTIONS OF THE NLS SYSTEM-DIRECTORY FILE, SYSGD. The command specified in Figure 111-2 has just been executed: a "Jump" command to display the "Global Documentation" branch has been specified but not executed. 37 ALL ALL JlJMP ro LINK :FILEsrRUCrlJRE 8JlY (doel GLOBAL DOClJMENrArrON fol" doeumeniailon on fIle sil"ueiure seeO(fllesirueiure.tl f f or do eumeni ai Ion on s pee I a I prob I ellis see (n I sdocument ai I on. t I foT' document ail on on data forlllS see (dataforlllS. t I TA-7079-14 FIGURE 111-4 38 "GLOBAL DOCUMENTATION" BRANCH OF SYSGD WITH "BRANCH-ONLY" FEATURE IN EFFECT. The user is about to follow a link which will cause the file-structure documentation to be displayed. ALL ALL JUMP TO ITEM HJLV :SYSGD. 07/23/70 0'.':37 CHI: loverlay) PROGRAM OVERLAY STRUCTURE I doc) GLOBAL DOCUMENTATION IOvlInd) OVERLAY INDEX , DEBUG INFORMA nON IIndex) CA TEGOlllES FOR NLS PROCEDURES I Bugs) LIST OF BUGS I map) MAP OF SYMBOLS AND BINARIES It hought s) 0 THOUGH TS FOR IMPROVE MEN TS + TA-7079-15 FIGURE 111-5 The user has now returned to the same view shown in Figure 111-3 (several steps have been omitted from the sequence). A "Jump" command to display the "Thoughts for I mprovements" branch has been specified but not executed. 39 ALL ALL HJLV [thoughts) JUMP ro NAME FIRSr OVERLAY THOUGIHS FOR IMPROVEMENrS 0« 70103/20 WI' '''tt/25 1'51: 23 tt~: 23 traIls TraIl returns can be done through a ~ush down stack. Every tIme the seq-gen lIIakes a tratl branch It ~ushes the ~sld on a stack. The user lIIay deftne a tratl return syntax. If he has one. and It ts found tn a statelllent. the stack ts ~o~ed and the ~o~ed ~sld used to start the seq-gen out agatn. WI' "/11125 1n1:24 WI' "/tt/25 1n1:24 cont ent ana I yzer Coroutlnes also seelll to be the answer to the content analyzer case ~roblelll. A set of standard coroutlnes could be selectIvely tnvoked to 1II0dtfy the text on the way to the rsr and CV tests. rheJ would convert cases. skt~ ~unctlon. etc. rhey could be Invoked and dts-tnvoked tnde~endent of the ~aren structure of the pattern. a la dtrectlons. WI' "/11125 1n1:2' Don' t have t he sequence gen. set the cont ent flags In the r I n9 TA-7079-16 FIG U,R E III -6 The "Th oughts for I mprovements" branch serves as a repository for ideas about what could be done to improve the system. A "Jump to Name" command has been specified to display a statement named overlay"-the user has specified this name by typing it in. II 40 R+ 2 1 GJLV loverlay) JUMP ro VECrORLABEL MNcrRL PROGRAM OVERLAY srRucrURE I oct I prlllSpc IIlAct r I vctedt -vctrl t odls t odprn calc key.d dlsbuf -lnpfbk • - d at I - dl ddl ut I It Y seqgen CdSPIY sdblllnp - CICIllP I f st rlllnp clnup - rec I nt - auxcod txt edt - I nk sub TA-7079-17 FIGURE 111-7 FI RST BRANCH OF SYSGD FI LE: USED BY NLS SYSTEM DIAGRAM OF OVERLAY STRUCTURE 41 ) JUMP TO LINK 'HY Inmctrl) lIlaln control overlay link to file Inls. IIlnctrl. : JxbbJhnz) Ikdf ERICKSON) starttnglocatton: orglllct=24000 page 5 cells used: 21450 procedures In the MNCTRl overlay 1wc) what charact er , Iwalt) walt for MNCTRl Icaqlll) command accept. questIon mark Idmanl) dIsplay. then go to maIn I set dUIll) set up dummy st at ement 1cmdrtt) command reset IlIldtspec) kludge for 'set' imatn) read a character TA-7079-18 FIGURE 111-8 A BRANCH GIVING SUPPORTIVE INFORMATION FOR MAIN-CONTROL (MNCTRL) OVERLAY. Display shows only the first line of each statement. A Jump to Link" comma"nd has been partially specified-no selection has been made. II 42 ALL JUMP TO LINK :MNCTRl t I"LY (mnctrll maIn control overlay I Ink to fIle (nls. mnctrl. : JxbbJhnzl Ikdf ERICKSON) st art I ng I ocatl on: orglllct=24000 page 5 cells used: 27450 procedures In the MNCTRl overlay Iwc) what character tOINlS. MNCTRl. wc : JgebJI I walt) walt for MNCTRl (NlS. MNCTRl. walt: J9WJ) (caqlll) cOlllmand accept. quest Ion lIIark (NlS. MNCTRl. caqlll : J9wJI (dlllenll dIsplay. then go to lIIaln INlS. MNCTRl. dllla!n : J9WJ) ( set dum) set up dUlllllly st at ement INlS. MNCTRl. setdulII : J9wJI TA-7079-19 FIGURE 111-9 SAME AS FIGURE 111-8, EXCEPT THAT DISPLAY SHOWS ALL LINES OF EACH STATEMENT. The link in the statement named "we" has been selected; this link specified another statement named "we" in a file called "MNCTR L" under User "N LS" (the characters "jgebJ" in the link are VIEWSPEC codes). 43 4 ALL GJLV Iwe) bp :::'a: :::'b: :::' e: :::'d: :::'e: :::'f: :::'g: :::' I: :::' J: :::'k: :::' I: .. 0:::'111: :::'0: :::'p: :::'r: :::'8: :::'v: =' x: =SP: JUMP ro I rEM an zap CASE 6ROUP:edlt SrArE:xa.edlt OSPI"< Append Statement) 6ROUP:edlt SrArE:b8.edlt OSPI"< Break Statement) 6R0 UP: ed It 0 SP I. ftEPEA r l·.) TA-7079-20 FIGURE 111-10 44 RESULT OF "JUMPING" ON THE LINK SELECTED IN FIGURE 111-9 (from Index in SYSGD File to Source Code for "wc" Procedure in Main-Control Overlay), A "Jump" command has been specified to display a particular branch of this code, II Jl y + COpy t BRANC~ Q='m: GROUP:edlt DSPlcMove hESJ) . ='c: SrATE:mc.edlt DSPI~ c Move ='W: srATE:mw.edlt DSPI~ c Move =' n: srATE:mn. edit DSPI~ c Move ='V: SrArE:mv.edlt DSPI~ c Move ='d: cdeasy ~ 0: -cvcrEDr. qllld>. ='1: srATE:IIlt.edlt DSPI~ c MO'le ='1: srATE:lIll.edtt DSPI~ c Move ='t: srATE:mt.edtt DSPI~ c Move ='s: SrATE:lIls.edtt DSPI~ c Move ='b: SrATE:lIlb.edlt DSPI~ c Move :'p: SrATE:lIlp.edlt DSPI~ c Move ='9: srATE:1Il9· edtt DSPI~ ( Move =CA: REPEAT I JECJ) ENDCASE Goro ccaqlll> CASE Character) HJ=c.Character Word) JEJ=w.Word Number) JEJ=n.Number VIsIble) JEJ=V.Vlslble Invlstble) JEII-=l.Invtstble LInk) JEJ=I.L1nk rext) JEJ=t. rext Statelllent) HJ=s.Statement Branch) JEJ=b.Branch plex) JEJ=p.Plex Group) HJ=9· Grou P TA-7079-21 FIGURE 111-11 CODE DESeRI BING COMMAND LANGUAGE FOR "MOVE" COMMANDS, IN A SPECIAL-PURPOSE LANGUAGE. A "Copy Branch" command has been specified to create a duplicate copy of this command-language code. 45 ALL ALL GJLV + 0.:=' t: JUMP fO PREDECESSOR SROUP: edl t DSP [ ( franspose f IfESlfl CASE .:=' c: SfArE:trc.edlt DSP[H rranspose Charact er I .:=' W: SfArE:trw.edlt DSPI"( rranspose Word) IfU.:=w,Word .:=' n: SfArE:trn.edlt DSPI"( rranspose Number) IfEIf:n. Nunlber .:=' v: S rArE:t rv. edIt DSPI"( franspose VIsIble) .:='1: SfArE:trl.edlt DSP["( franspose InvIsIble) .:='1: S rArE :t r I • e d I t DSP("( rranspose lInk) If Elf: I,ll nk .:=' t: SrArE:trt.edlt DSP("( franspose fext) HIf:t, rext .:='s: SfArE:trs.edlt .:=·b: SrArE:trb.edlt DSP(" ( rranspose Branch) .:=' p: S fA rE :t r p. e d It DSP(" ( rranspose plex) H*:p.Plex ':='9: SrArE:tr9·edlt DSP(" ( franspose Group) IfE*':=9' Group .:=CA: REPEAr (.EC.) ENDCASE soro (caqm> TA-7079-22 FIGURE 111-12 46 By executing the "copy branch" command, then substituting "Transpose" for "Move," "qt" for "qm," and "tr" for "m," we produce the commandlanguage code for the "transpose" command. A" Jump to Predecessor" command has been specified to redisplay the unaltered command-language code for "Move." ALL JUMP TO LlNIC ALL : THED T • JL Y :: m: GROUP: edtt DSP' e ::' d: cdeal," 0: • . TA-7079-23 FIGURE 111-13 COMMAND-LANGUAGE CODE FOR "MOVE" COIYIMANDS, WITH ALL LEVELS SHOWING, We now "Jump" on a link to a routine named "qmc" in the "TXTEDT" overlay file which implements the "Move Character" command (the link in this case is a subroutine call in the "Move" commandlanguage code-photo shows display just before "Jump" command is executed), 47 ALL COpy BRANCH MHY t t % move % [ qmcl + [IB1.IPl TO 41 + [IB2.IP5 TO I I SO TO END. [ qmwl +< wdr> [IB 1.IP 1 TO 41 + [IB2.IP5 TO I I + [IP7.IPII SOTO <1110 vet x> END. [ qmnl + IIB1.IPl TO 4) + IIB2 .IP5 TO II + [IP7.IP1) SOTO END. I qml) + IIB1.IPl TO 4) + IIB2.IP5 TO II SO TO END. \ qlllvl + \IB1.IPl TO 41 +< vdr) IIB2 .IP5 TO I) + END. I qlllt) + lIB 1.IB2) : END. I qtw) + IIB1.IPl TO 4) + ISB1.SPt ro 41 SOro END . MOVErx + lsB2.sP~ ro 81 .. Iqmwl + ISBt.SPt ro 41 + ISB2.SP~ ro II + ISP7.SPII sora END. Iqlllnl + lsBt.sPt ro 41 + ISB2.sP~ ro II + IIP7.IPII soro END. Iqlllll + IIB1.IPt ro 41 + IIB2.IP~ ro II sora END. Iqlllvl + IIBt.IPt ro 41 + IIB2.IP~ ro II + IIP7.IPII soro END. I qllll I + IIBt.SPt ro 41 + IIB2.sP~ ro II + IIP7.SPII soro END. Iqmtl + IIBt.IPt ro 41 +(tdr>ISB2.IBJ.SP~ ro II TA-7079-25 FIGURE 1II-15 SAME DISPLAY AS FIGURE 1II-14 BUT WITH ALL LINES SHOWING. We now follow a "GOTO" instruction by using the "Jump to Name" command (photo shows display just before "Jump" command is executed). 49 All All JUMP F1L E RETURN :MNCTRL t MJlY I movef xl f :C IF SFIBll :: SFIB2} THEN !F B1 < B2 THEN ST B1 .. SFIB!l P2. ~LlT~. P5 PL P4 P7. pa SEIB!! ELSE ST B1 .. SFIB1} P7.pa P2. Hln. P5 P6. P4 SEIB1} ELSE BEGIN ST B1 .. SFIB1} P2, ~Lln. P5 P6. P4 SEIB1}; ST B2 .. SFIB2} P7. pa SEIB2} END: r-e II U GO TO END. If r-anf x} PROCEDURE I bug1. bug21 ; REF bugl. bug2; + eIIPl.IP2} OELPTRIPl P2} OELPTRIP5 P6} :C IF SFlbug!} :: SFlbug2} THEN IF bug! ( bug2 THEN ST bugl .. SFlbugll Pl. P5 P6. P4 P7. P! P2. pa SElbugtl ELSE ST bug! .. SFlbugll P7. P! P2. pa Pl. P5 P6. P4 SElbugll ELSE BEGIN sr bug! .. SFlbug!) Pl. P5 P'. P4 SElbug!}; TA-7079-26 FIGURE 1II-16 50 The "movetx" code has been copied and altered to produce the "trantx" code for the new command. We now return to the previous file by using the "Jump File Return" command (photo shows display just before "Jump" command is executed). advised tty open; :8 ARC 1.76 (3-') IS UP .ENTER NlS. PASSWORO- OK 07/23/70 1128:01 .ExECUrrVITY -1. • • • -RESET . • lI-F II e. ct I f I Ie rext; MNCTRl rxrEor • lI-Wr-lt e . lI-Cornpl Ie . lI-Wr-t{ e B I nar-l es. lI-Abor-t lI-60 TA-7079-27 FIGURE 111-17 The NUTI L1TYsubsystem allows one to automatically archive, retrieve from archive, compile, print, and cross-reference files (display is now running in Teletype-simulation mode, as it was before N LS was started up in Figure 111-1). 51 eMU rIL TV . advIsed tty open: :1 ARC 1." (3-') IS UP .ENrER NlS. PASSWORD- 01( 07/23170 1121:53 .EXECunVITV -1. • • • -RESEr. • .R e ad BIn ar I e s . • load NlS . • F II e. ct I file All files. J.60 TA-7079-28 FIGURE 111-18 52 Once the changed code has been compiled, NUTI LlTY can be used to automatically load a new version of the system. AL l AL l fRANSPOSE WORD MJlY . DUMMy rh4 sis a sf a' emenL + TA-7079-29 FIGURE 111-19 Under DDT we run the new experimental N LS and build a dummy statement to test the new "transpose" command. In this photo the command has been specified and two words selected. 53 ALL rRANSPOSE WORD ALL M JL Y . DUMMy : st at ement f I s a rhls. TA-7079-30 FIGURE 111-20 54 Here the "transpose" command has been executed. ALL ALL KEYWORD SELECr FIlElO t IHY 11ndexI CArEGORIES FOR NLS PROCEDURES fIle handlIng l'llelol RANDOM FILE I/O +. Ilodrfbl Irdhdr) Ifllco~y) • FILE COPYING 1co~f III 1get .ka) Ifllref) FILE BLOCK REFERENCING • 1 lodrsv) 1lodrfb) I lodsdb) 1fllcontrol) FILE CONrROL • lo~nffk) Ilodrfb) Ibrt"x) Irdhdr) TA-7079-31 FIGURE III-21 Another branch of the SYSGD file allows one to select procedures according to function with the "Keyword" commands. I n this photo the user has selected the word "fileio" as a keyword; we see that the statement named "fileio" contains two other names, "Iodrfb" and "rdhdr," in a special format. 55 ALL ALL JUMP TO llNIC IHY :UTlLTY t llod ... fb) load ... andolll fIle block OINLS. UTlLTY. lod ... fb : IgWJ) t l ... dhd ... ) ... ead heade ... block of fl Ie INLS. IOCTL .... dhd ... :gWJ) TA-7079-32 FIGURE 111-22 56 DISPLAY PRODUCED BY KEYWORD SYSTEM. When the selected procedures are presented, one can "Jump," via the associated links, and examine the documentation. and code for the procedure. ALL ALL JUMP FILE REruRN :SYSGO • J LV ( I 0 dr f b ) IT his 1st he PRO CEO UREt hat eve r yon e c a I 1st 0 h a ve a ran d0 m f I I e b I 0 c k loa de dint 0 cor e . AIso. ItIs po s sIb let 0 obtaIn a block of core whIch Is empty and not assocIated wIth the ~lle. For example. a long lIteral regIster Is created In thIs way. rhere are several tIC blocks In core. some of whIch may be 'frozen'. whIch means that they may not be moved or used for anythIng else. LOORFB loads the desIred fIle block Into one of these core blocks. On entry. the A contans the random fIle block nUlllber. and the B contaIns the block type. or - t 1F no f I I e b I0 ck 1st 0 be rea dint 0 that cor e b I 0 c k . rhe algorltnlll Is apporxllIlately as follows: First. a block Is chosen. A quick scan Is made to fInd an unused block. If all are In use. rWEN a circular counter (NACP) Is used to find the 'next' core block that Is not frozen. If a II are frozen. RERROR Is ca II ed. RERROR Is called IF the desired clock does not exist. If the newly found core block contlans a fl Ie block. then TA-7079-33 FIGURE 111-23 DOCUMENTATION OF LODRFB PROCEDURE. The "Jump to Link" command specified in Figure 111-22 has been executed, and the user has set up a "Jump File Return" to display the SYSGD file again. 57 R+2 JUMP TO ITEM HJLV ( (OvlIndl OVERLAY INDEX' DEBUG INFORMATION ( auxcodl 10rks and 10rk ri art I ng (rec I nt I recovery and Initializing (dat al dat a page (utlltylO utility package • ( I np1bkl Input 1eedback (mnctrll main control overlay IprmspCI parallleter specification overlay I vct edt I spec I a I charact ers and vect or II be I vct r II vect or package TA-7079-34 FIGURE 111-24 58 The overlay index branch of the SYSGD file contains overlay in the system. A "Jump" has been specified on the utility package. The VI EWSPEC code "R+2" left corner of the screen shows that in executing the structural levels of text are to be displayed. information about each to display the branch appearing at the upper "Jump," two additional JUMP TO LINJ( :UTlLTY MJlY [utt It y) utt lit y package t Oink to file [NlS.utllty.1:lgebjJ) (kdf PARSLEY) st artt ng I ocat Ion: orgut y=14000 page J cells used: 17715 locatton for telllporarles: uH prefix for generated labels: utI procedures In the UTILTV overlay [utgd) UTllTY general declaratIon. [push) push b-reg onto general ttack [ pop I pop genera I tt ack ont 0 b- reg [reillt) release lIteral regltter [getllt) get lIteral reglrter [regadrl get regl rt er addre .. [apchrl append character to a-rtrlng [apsrl append a-rtrlng to another [Idchrl load character frOIl a-rtrlng [cpysrl copy one a-ttrlng Into another [asrbufl lIlove a-ttrlng to buffer [lIlvbfbfl lIlove buffer lup tn corel [lIlvdownl lIlove buffer (down In core) TA-7079-35 FIGURE 111-25 INFORMATION ON THE "UTILITY" OVERLAY, Including Part of the List of Procedures in the Overlay. The first substatement in this branch contains a link which the user is about to follow. 59 ALL ALL INSERT CHARACTER MJLY (OvlIndl OVERLAY INDEX' DEBUG INFORMATION [.dlsplay.]; (auxcodl forks and fork startlng r lInk to fIle (nls.AuxCOD. : IgwJI Ikdf ERICKSON I st art I ng I ocat Ion: I orgauX::24000 page 5 ce II s used: I 26234 locatlon for telllporarles: I ad prefIX for generated labels:J axl procedures In the AUXCOD overlay (qkfl freeze natelllent I NL S. AUXCOO. qkf : JgWJ I (qkal re I ease frozen nat elllent (NLS. AUXCOO. QKA : IgwJI Iqplsll poInter show iNLS. AUXCOO. qplsl : IgwJI Iqpmll poInter delete (tH S. AUXCOD. qpllll : IgWJ I TA-7079-36 FIGURE 111-26 60 Here the user is back to the SYSGD file (several steps have been omitted from the sequence). In the first line of text on the display he has inserted a content-analyzer pattern for finding procedures containing the string "display." ALL AL L CONrENr ANALYZER MJLY (Ovllnd) OVERLAY INDEX' DEaUG INFORMArION O[·dlsplay·]: (auxcod) forks and fork start Ing + lInk to fIle Inls.AUxCOD. : IgWJ) (kdf ERICKSON) startIng locatIon: i orgaux=24000 page 5 ce II s used: J UHf locatIon for telllporarles: I axt prefIx for generated labels: I axl procedures In the AUXCOD overlay (qkf) freeze statelllent (NLS. AUXCOO. qkf : IgWJ) (qka) re I ease frozen st at elllent INLS. AUXCOD. QKA : IgWJ) Iqpls1t poInter show INLS. AUXCOO. qplS1 : IgWJ) Iqpmll poInter delete INLS. AUXCOD. qplll1 : IgWJ) TA-7079-37 FIGURE III-27 The pattern is compiled with command "Content Analyzer." The display is not yet affected-the content-analysis code compiled from the pattern will be run when the user changes a VI EWSPEC. 61 ALL ALL JUMP TO LINt< :RECINT MIL Y (OvlInd) OVERLAY INDEX' DEBUG INFORMATION (setdls) set up display O(NLS. RECINr. 8etdls : IgWJ) [·dlsplay·]; r Idlsmes) display mes8age INLS. UTILrY. dlslles : IgWJ) Itxt) create a new dIsplay pop INLS. UTILrY. txt : IgWJ) Iclrdpy) clear dIsplay INLS. UTlLrY. clrdpy : IgWJ) Iresdpy) reset dIsplay INLS. UTILrY. resdpy : IgwJI Iclralll clear entire display INLS. UTILrY. elrall : IgwJI Inulldpyl nUllber dl8play TA-7079-38 FIGURE 111-28 62 RESULT OF CONTENT ANALYSIS: a list of procedures that in some way deal with the display (since they contain the word "display") Sec~ion III APPLIOATIONS AND EXPERIENCE o. The Augmented Manager 1. In~rOduetlon a. General Considerations Mo.t people need ~o play the role of "manaler" at varioul times, whether tha~ role i8 their primary function or simply a nece.aary element for the accomplishment of their other work. We will u.e the terms "manlier" and "man'lement" in this expanded len.e, applying them to an individual'. management of hi. own time, resource., and .Kill. as well &1 to individual and COllec~lve mana cement of the work of other individuals and groupl. Our experience with augmented management can be de.cr1bed beat 1n ~erm8 of the augmentation tOOl' we have developed an4 the methOdS we have evolved for eXPloiting th.letool. in ~het&lk ot man&lement~ once a tool loeainto u.e. methOdology bec6me. as com~lex and critical a concern a8 the de.len and development of the tool it.elf, and our research in the area of &ugmentinl management ha. been concerned principally with the development of .pecial methOdOlogies tor usinc our ba.ic aUlmen~&tion tool' with onlY .econdary empha.i. on the development of new .~eclal·purpo.etool'. We have identified the follow1nc a. lome of the major need. relevant to fulfilling the role of manaler 1n our auemented communi~y. (1) Fa.t and flexible mean. for aec •• sine and .tudylnemanaiement working file. and other croup working file. (2) Technique. for leeatine .pecific piece. of intormatlon1n & complex tile or collection of f11e. (3) EffiCient method' for entering, uPd&tlnl, and storing manalement inform&ti6n (4) Technique. forinteraoting with other croup members to verify and comment on information Within 63 Sec~ion III APP~ICATIONS AND EXPERIENCE the group'. working recoros (S) Facilities for rapid and flexible com~osit1on, mOdification, and pUblication Of management Oocumentation (6) special tool' for the processing of manacement information (e.I., the Nt! calculator faci11ty). Some of the Ipecific tools and methods developed in re.ponse to the needs outlined above are described brieflY below. Our collection of on-11ne files now contains considerable manalement information Of various kinas, and we have pursued our investigation of managemen~-1nformation operations by using NL! and TODAS to provide and develop aids for management ot the ARC on-line community. There are many areas of potential apPlicat10n for on-line aidl, and we have cholen those ch appear to be most useful operationallY for the purposes of experimentation and development. b. Cost-Accounting Files While still under continuous development, special cOlt-accounting file. (described 1n detail in Section 111-0-2 below) are now in routine use. These file. are extremely usefUl in terms of letting work done, and our experience with developing and using them hal constituted lome of our mo.t fruitful research on the intensive eX~loitation of the overall on-line system. The files have an intricate structure, desilned for maximum mObility in accessinl information and for maximum efficiency in interfacing with the NtS calCUlator facility. Intelligent use Of these files include. the entry of new intorm&~ion and the occasional re.tructuring Of the information to take advantage ot new ~os8ibilit1e8 1n the system and to meet neWlY discovered needs. While fundamentally Simple, this kind of usage requires the coordinated operation of the mOlt advanced feature. of NL!) thus the cost-accounting file. are a leading edge of our research on highly interactive information .tructure •• Sec~ion III APPLICATIONS AND EXPERIENCE c. work-Planning Files We have begun experiment. in u.inl NtS tile. tor the ~lanning and moni~oring of ~a8k. within our project aetivi~iel. our first experlmen~involved the management ot the TODA! development activity, for Which we created a f11e called UPLAN to use in formulating .~ecificat1on8 for TODA! and in planning for the implementation of the specified featUres. This tile contain. a branch for each identif1ed talk with the followiniintormation organized tor ealY study and retrieval: (1) Description of the ta'k, with link. to other working tiles used in ita development (2) Comments on the relationship ot the talk to other ARC taSKS (3) Estimatel ot im~lementat10n cost. (mainlY manpower) and .chedule ot work and implementation Itages (4) comment. on the current status ot Planning and implementation. We allo created a separate file called UMEET containing agendal and notes for the TODA! development activity meeting •• We made u.e ot a researCh a •• i.tant working on-line to take notes during the.e meetings. The research as.istant worked from an agenda composed betore the meeting 80 &S to have a convenient framework for no~e-taking, and was a1.0 available for tinding on-line information a. nee~ed durinl the mee~ings. Succe.sive meetine alenda. and minutes were kept in a sincle file 80 as to make it ealY fer u. ~o search for record. of all diSCUSsion related ~o any liven topic. On a lea. formal basis, we have used various.other file. tor work planning throulhou~ the project'sh1story, This has ranle~ from the construction of lists of task. in such & way as to reflect their interdepen4encie., to the main~enance by individuals Of file. listing their 65 Section III APPLICATIONS AND EXPERIENCE perlonal tasks on hand along with plana for completing theae tasks. d. Perlannel Files SOMe of our ~er80nnel information i. now kept in on~line files. Features 1n the timesharing .ystem ~erm1t UI to rel~rict aceesl to some ot the.e files, while letting others remain "pUblic." Even though our personnel ro.ter 1s relatively small, we find it advantageous to have the ability to .pecify automatic searches on the personnel filel, e.~ecially for .uch taSks as cost estimation. e. DOCUmentation All of our documentation, from large final re~orts to the brief circulars distribute~ at conferences, is compo8e~, stored, and uPdatea in on-line files. our flexible compolition and editing capab1l1tiel and fast pUblication technology (from on-line file to formatted hardcopy in a few seconds per pace) live management control. over the documentation procesl that are not pOSSible without augmentation. f. On-Line Dialolue We use the term "dialogue" to indicate the process of formal communication via interactions with a common information ba.e. This kind of dialolue plays an important role in the formulation ana monitoring of plan. for project activities, an4 while we are still using informal experimental methoOs to achieve ihi., we are in the procesl of formulating the initial Plans for & long-term investigation of aOvanceO techniques for &ulment1nl ~ialogue procesles. SubleQuent lections offer detai1e~ descri~tions of several man&lement application. that have been Oeveloped using NtS ana TODAS, illultrate~ with Photograph' taKen from Nt! ~1'Play Icreens to show sequences ot information-manipulation operations. A familiarity with the basici of NtS (to the extent that they are eXPlained in Appendix A) il aSlumed. tn following the descriptions, it should be kept in mind that the speed with Which NLS serve. its users is an 66 Sect.ion III APPLICATIONS AND EXPERIENCE important part of its utility. The Photographs in~1cate t.ransitions that take only one or two second. under lood conditions. This speed lendS great power and flexibility to the relativelY simple service functions performed by NLS. 2. project COlt Records In our routine operations, we need frequent and rapid acceSI to summary data on project costs, with little reference to lower-level details except when the COltl are first checked for reasonableness and accuracy. Therefore we decided to start by putting summary data on-line at ARC. As needed in the future, we can add more levels of detail. We first constrUcted a cost-history file for 1968-1969 costs on SRI projects ESU 7101 (RADO Contract F30602-68-0-0286) and ESU 7079 (NASA Contract NAS 1-7897). This tile il called HISCO. The elements of RISOO included the following for each Of the two projects, on the basi. of 4-week accountinl periodS (as used by SRI's accounting system). (1) Salary (2) Burden (3) Overhead (4) Total cost (5) Fee (6) Total charges. See Fieures 111-29, III-30, and 111-31 (illustrations for this section are grouped together, bel1nn1nl on pale 75). Each ot thes. three ligures shOwS & display of one branch of the file, containing the information for a specific project and year. We &110 needed a .ection showing combined salary costs and combined total charles for all of our projects (see Figures 111-32 and 111-33). We put the8e cost. in separate branches Of the file. The last branch shows total costs for both projects 67 Section III APPLICATIONS AND EXPERIENCE combined. We retroactively studied eXisting records fer all 1968 d&\a and kept up the 1969 COlts every 4 weeki, entering the new data by hand. The usual way ot accessing HISCO was via pre·es~&blished links from other workinl tiles whenever the user had & question about recent coat,. The VIEWSPECS in the link usually caused HISOO to be brought in with only hieh-level statements on display, showing only the headincs for project name, combined salary, total charles, and total ARC costs (see Figure 111-34). The user COUld then select the project he was interested in (bY the command Jump to Item), open up an additional level for viewing, and see column headings and numerical data (rigures III-29, III-30, and I11-31). Then he COUld jump down through the accounting periods to the one he was lookinl for. If he waa making a calculation (perhaps already .tarted in the f11e he was working 1n before he loaded 81SCO), he could then call the calculator and add, SUbtract, multiply or divide by any of the numbers 1n HISOO. His previous caleulations 1n the previous tile woulO remain intact. If finiShed with HISCO. he eould then return to the previous tile (by the command Jump File Return) and continue with the calculation, havinl found in H1SCO the input number or numbers he was look1nl for. A. an arena for experimentation, HISCO proved valuable. OperationallY, it wa. u.eful from time to time but revealed & nee~ tor ~ore frequent updating of the .ummary data. our experience with HISCO led to the development of a rede.ilned cost-history tile ealled COSTS Which il up~ated weeklY, w1th 4-week and eumulat1ve Iummaries. The co.t elementl in thi. file are: ll) Salary costa (2) Total personnel costs 68 Sec~ion III APPLICATIONS AND EXPERliNCE (3) Non-labor costs (4) Total costs (5) Total charges with fee (6) Balance remaining. See Figures 1II-3S, 111-36, and 111-37. Figures 111-35 and 111-36 show the lame branch of the file with different VIEWSPECSJ Figure 111-36 displays one more level ~hanFigure 111-35, and this level .hows the weekly data. Figure 111-37 .hows the weeklY data for another project. We also included fundinl information showing current totall, unfunded totals, and total contract amount. in the "cost," "fee," and "total" categor1es. We use separate branches tor each project and for total ARO project co.ts (Figure 1II-38). The skeleton format for the file was set up in advance for the entire year of 1970. Before enter1nc any actual aa~a, we copieQ the first top-level branch (containinl .ome 70 statements) within the tile at the .ame level four or five time. so a8 to create blank format branches. Then we simply inserted the project name headine. tor each project into a corresponding blank branch. we keep one blank format branch in the file in cale any new projects 'hould arrive. Like HISCO, COSTS is usually reached throUlh a link trom lome o~her working file, perhaps while a stUdY of near-fu~ure COlts is in ~rogrels, or from a ~ropos&l co.t estimate ~nder developmen~. Alain the tile 1. usually entered with only the top-level .ta~ement. or project head1n,s Showing (see rieure 1II-39). If a partieular project i8 of interest, the corre.pending branch is selected and another level opened tor view. The second level Show. per1od-by-period .ubteta18 in each ce.t catecorf. It weekly data are deSired, another level il opened,bY changing the VIEWSPEOSand a partiCUlar week is selected by the command Jump to Item. 69 Sec~1on III APPLIOATIONS AND EXPERIENCE The statement for each week has the week-ending date &. it' name. The realon tor usinl thi orm of name construction is not only 80 that the statement for a particular week can be accessed by the Jump to Name command u.1ng the ending date, but also 10 that the date may optionallY be suppressed from the display. (NLS has the capability ot suppressing all statement namel from the display.) The normal way of viewinc thele particular files is with names suppressed; thus the dates do not clutter the display. However, a uler who needs to know the end1nl date tor a ~artieular week can see it by executing a single command. TO accels the information for another project within COSTS, one executes Jump to Return twice to see the top-level statements again (Figure 1I1-39). One can move very quickly and accurately through a tile that i8 let up 1n this fashlon, even without any familiarity with the information it contains. The primary function of COSTS is to ShOW a consiltent week-by-week progres.ion, by category, ot COlts for each project. The tile can also be used tor 8tu~y purposes, throuch the use Of content-analyzer patterns, SOMe of which are stored in the oriCin statement (.ee Figure 111-40, which is ~he same as Figure 111-39 but w1~h different VIEWSPEOS). Any other pa~~erns can be crea~ed as needed. Thi. allowl a user to extract speCial categories ot information trom the file very quiCklf. ror example, a user may ealily create a di.play .howinc all project CO'~8 for the eighth week of 1970, for each ARC project. It is also p08sible to output such a "filtered" display Via aline printer, thus obtaining hard copy of a special-purpose extract trom the total file. The content analyzer is helPful when using the calculator on all the data for one week, project by project, to find total ARC charges by catelory. When only one week's data are di.played (Figure 111-41), one can add items down each column and 70 Section III APPLICATIONS AND EXPERIENCE insert the answer in the "ARC total" space. One can then elear the accumulator, and a~d down the next column. Th1. 11 done very rapidlY through bUg selection of input numbers and keyset entry of command. -- Add, Add, Add, Add, Insert, Clear, Add, Add, Add, Add, Insert, Olear, and so forth. The COSTS file is now operationally useful to us, and we expect it to be useful tor future experimentation with automatic proces.ing techniques. 3. Estimate. for proposal. a. personnel costs An estimator working on a propo.al can select from an on-line file, by labor category, repre.entat1ve people who may be involved with the proposed work; as he selects them, he can transfer tb names ana relevant information about them to a file Where he 11 building up hi. estimate. The estimator loads a special file, maintained by him.elt, Which is a directory to all of his other file. an4 perhaps to a few files belonlinc to other people. rieures II1-,2 and 1II-43 are two display. of a user's filedlreetory. In Figure III-~2, only first-level .tatement. are shownJ these are used for establiShing catelories. InF11ure III-,3, another level i . shown, containing the actual directory listin«s in each category. This "fl1e directory" contain. links to each ot the file. that it listl. In the present cas. the tile. prObablY would be cost histories, personnel listinc-, previous .pec1al studie. of costl, and other admini.trativeinformat1on. He load. a previous cost e.tlma~., makes a workin, copy ot it, change. the headine to reflect the name of the new proposal e.tim&te, and eliminate. the amount. trom the old e8tima~e. Thil produce. a blank cOlt-e.timate format. It any items from the old estimate &reinappropr1ate. they are easily deleted; new item. are eaaily added IS separate .tatement.. When the format il ready, it is 71 Section III APPLIOATIONS AND EXPER1iNCE output al a new file. He can then load a file that lists names ot people in the croup and lome projection Of expected addition •• Fieurel 111-44, 111-45, and 111-46 snow portions ot such a tile. Usinl this personnel-listing file, he obtains information about labor categories. A branch containing content-analyzer patterns is kept in the file. Thele can be easily reached by jumping to a link that causes all the patterns to be ~isPlayed (Fieure 111-47). Each ~attern will select some particular category of statements from the tile. For example, the estimator will need to know which people have the statuI of Senior professional. He .elects the appropriate pattern with the command Execute Oontent Analyzer, and then jumps on a link that turns on the content analyzer, starting the .earch at the beginnlne ot the branch containing personnel liltinls and restricting tne seareh to that branch. Thi. prOduces a diSPlay showing onlY the listing of senior profe.sionals in the croup. This let of statement. can tnen be tran.ferred to the new propolal cost-estimate file. other patterns can be used to extract let. ot statements according to other criteria -- for example, all the hardware or softWare peo~le 1n the group (Figures 111-,8 and 111-49). ThUs the estimator can select, by labor category, re~re.entat1ve people Who may be involve~ with the ~roposalJ as he selects them, he can transfer their namel and the lnform&t1~nthat goel with them to the file where he il building up hi. eltimate. The payroll burden and oVerheadratel are cheeked for currency and inserted 1nto the estimate, uling the calculator to apPlY them to the ~irect labor. At this point the labor portion of the e.timate 1s completed. 72 Sec~ion III APPLICATIONS AND EXPERIENCE b. Non-Labor Coats A typical e.timate will involve lome travel COS~8, some consultant eosts, and some report co.t.. Data lupporting the cost Of eon.ultant8 may be checked by reviewinc current consul~ant.~ costs bY project and bY consultant. These are kept in a separate tile and reached through a link for review. The data may be copied 1nto the estimate if de.ired. Report-production COlts are estimated uaing current Institute schedules, which are based primarily on the number of page. expected in the end prOduct. These computations can be made u.ing tne calculator and the existln& cost factor. from the last proposal (cheeked for current applicability). In addition, the proposal may contain Plans to add equipment. In this cale, the estimator will use an equipment stud, written 1n another file bY the people 1nvolvea in hardware des1ln. The equipment costs contained in the special stUdy are lummariled in total and reached by a link. The speCial stUdy can be viewed and updated a. appropriate and can be copied to 10 with the proposal a. an appendix or used later for baCkup. In thi. fashion, varioul informa~ion i. lathered from variou. tiles and transferred into the developinl coat estimate. Fleure. III-SO, Ill-51, and III-52 .hOW port1on. of a completed on-11ne COlt e.timate actually used for & recent ARC proposal. 4. purchase-Order Proces.lnl In makinl elt1matea ot eo.tl for new equi~ment beinl ARC, reterence to previous co.t1ntormation i. very useful. We con.tructed & purchal.-order/requi.ition proceal1n( file that contain. a .eparate .tatement for each item purchased for the pa.t few ,ear.. Filure Ill-53 .hows a portion ot this file. conltruc~edat All outstandinl order. are contained at a .econd level within a 11nlle branch (8ee rieure III-54)) therefore the di.tinct1on between out.tanding and completed order. 1ea.¥to lee by reterenee to level. To reduce clerical 73 Section III APPLICATIONS AND EXPERIENCE error, we consider an or~er completed when the Qom~ pattern 18 inaerted and the .tatement 18 moved to it. alphabetical ~o.ition on the top level. Thi. tile can be .earched u.inc the content analyzer in some inter •• tine way.. If we wonder what we purchased on PR A08927, the queltion can be an.wered simplY by executine & content-analYZer pattern Ipecifying the number. We can quiCkly lee all out'tanding order a chareed to a particular project. Fieure III-55 .hoWI a content-analyzer pattern that hal been temporarily written into the f11e, tor finding any entries pertain1nl to order. tor relays under Project 7101. Fieure III-56 ahow. a view ceneratea by using th1. pattern. This file i,kept up-to-date bY the .eeretary of the hardware group, WhO is mOlt involved with reQui.itioning. She doel this updatinc entirelY with TODAS. JUMP TO ITEM 'HY (RADCI COSTS 1968 PerIod Salary Burden 7101 ovhd Nonlabr Tot Cost Fee Totch98 1 2 10 11 t2 13 676 1080 1016 1167 2499 2522 3092 4187 2736 2309 4466 128 205 193 221 414 479 587 909 520 438 848 773 1234 1 160 1334 2854 2881 3532 5468 3126 2638 5102 23062 18061 23876 296 55 24434 B003 296 6 3 25978 40 t 68 8782 67 t 47 24639 20580 26245 3237 7 30261 30885 36874 37142 46 550 14 t 6 7 77563 739 617 787 971 907 926 1106 1114 1396 425 2326 25378 21198 27032 33348 31169 31811 37980 38257 47946 14 592 79 89 0 TA-7079-39 FIGURE III-29 A BRANCH OF FI LE HISCO 75 JlJMP ro SlJCCESSOR IHY (NASA) cosrs Perlod Salary 7079 1 2 3 4 8 9 10 11 12 13 1968 8462 10981 11897 10350 12394 11281 9038 94 72 1 1 157 10085 10308 Burden 1607 2086 2260 1966 2355 2143 1717 17" 2 1 19 1916 19 58 Ovhd Nonlabr rot Cost 9667 12545 13591 118 2 3 14160 12888 10325 10820 1 2746 11521 1171 6 301 787, 3083 4069 1271 12523 2650 1264 4025 6003 8338 20037 26399 30831 28208 30186 38835 23730 23355 30041 2H25 32380 Fee 1280 1686 1970 1802 19 28 2481 1516 1492 19 20 1886 2069 rotchgs 21317 280U 32801 30010 32114 41316 25246 24841 3" 6 7 31411 34449 TA-7079-40 FIGURE 111-30 76 A BRANCH OF FI LE HISCO JUMP ro SUCCESSOR IHV (NASA) COS rs PerIod Sa I ar y 7079 1 2 8 9 10 11 12 13 ~rojcum 4083 7296 9538 9 157 10171 8541 6463 7364 3217 2749 2348 3601 3175 193413 1969 Burden Ovhd 715 1386 5171 219 3 2379 2050 1562 1767 772 660 563 864 762 42884 466 4 833 5 17958 11330 12238 105' 1 8129 9131 HU 3408 2912 4466 HJ7 233242 NonLabr rot Cost 16 25 3521 10113 3717 6812 7533 2215 4632 4133 1429 613 1442 1949 86 730 11141 20538 42780 26377 31600 28715 1836' 22984 12713 8244 6 4J 7 11815 98 2 3 556269 Fee 712 1312 2733 16 85 2015 1835 1180 1462 812 527 411 662 628 35541 rot Chg8 1 taH 21851 45514 28062 33615 30549 19549 2 4J 56 13525 8770 6849 11035 10451 591810 TA-7079-41 FIGURE 111-31 A BRANCH OF FI LE HISCO 77 JUMP ro ITEM IHY "U rotal combtned Project Salary Pertods 71 0 1 + 70n t :: 1 2 1 67' 1462 4 to 10 tou toUl 11.,7 1167 tonO , 7 ,• 5 10 11 12 13 24" 2522 lOU 4117 2736 .." U., t Ull 'UI U061 lUU 11517 141U nl03 1 t 157 10015 10301 lUU nlu lU,. 14774 lU,. un ,.72 uuo .RES: TA-7079-42 FIGURE 111-32 78 A BRANCH OF FI LE HISeO TA-7079-43 FIGURE III-33 A BRANCH OF FI LE HISCO 79 JlJMP ro LINK IHY :I-IISCO. 02127/10 14U:SS JCN :.DSN=l:.RrJ=O:.LSP=O:.SCR=l:.HED=·ARC ARC PROJEcr cosr HISrORy 1~68'1969 See a Iso {f un ds . cost h { st 0 r y : ZW9n I By Pro ject : 7101 {RADCI COS rs 1 ~ 68 7101 {RADCI COS rs U 6~ 70H {NASAl COS rs 1968 t 70H {NASAl COS rs 1 ~ 69 By It em: combIned Project Salary 1'68 Combl ned Pro Ject Sal ary un combIned rotal Pro ject 'charges 1968 CombIned rotal Project charges U6~ TA-7079-44 FIGURE 111-34 80 INITIAL VI EW OF FI LE HISCO UPON ENTRY VIA LINK JUMP ro 1 rEM , JLV PROJEcr 7101 (RADC-old) Tot a I Fee Fund I ng: t Cost s 1515222 55658 Current tot a I: s 145HH 0 0 s Unfunded total:s 0 s 1515222 S 55658 rotal contract:s 145HH . wk-p er Sa I ary Percost NonLabr Tot Cost Tot Cngs 85230 12110 UU4 rotal 1 14121 3521' 53724 2U 17 52142 r ot a I 2 1 13 06 21 2 2 5 rot a I 3 roial 4 rot a I 5 rot al , Tot a I 7 Tot a I a Tot a I , rot a 11 0 rot a 111 Tot a 112 Tot a 113 Balance 18t358 127634 TA-7079-45 FIGURE 111-35 A BRANCH OF FILE COSTS SHOWING ENTRIES FOR 4-WEEK· ACCOUNTING PERIODS 81 TA-7079-46 FIGURE 1II-36 82 SAME AS FIGURE 1II-35 BUT EXPANDED TO SHOW WEEKLY ENTRIES JUMP TO ITEM IHY PROJECT 707' INASA) FundIng: Total C08t Fee 657437 Current tot a I :' , 617H7 U500 0 0 Unfunded tot a I:, 0 657437 Total contract:' '17H7 U500 wk-Per Salary Percost NonLabr Tot Cost TotChg8 Ico.blned wIth Week 2 on PSR') 1- 1 , , 2 -1 3-1 4 -1 Total 1 5-2 '-2 7-2 1-2 Tot a I 2 1411 410 1847 3145 2114 2100 1J4I 1701 7"3 3711 1025 U1I H'1 5717 5741 U72 4251 U151 14H 21 1121 UU 2 27 J2 Ul 452 , , 521J 1051 '441 12707 57., 5775 H04 4'42 1"10 5547 1120 '151 1J520 , 15' , 145 1621 U40 15J25 Balance 60011 511" 52045 52045 HI" U141 16120 31110 31110 '-3 10-3 11-3 12-3 TA-7079-47 FIGURE III-37 SAME AS FIGURE 1II-36 BUT FOR A DIFFERENT BRANCH OF FILE COSTS SHOWING DATA FOR A DIFFERENT PROJECT 83 JUMP TO 1 TEM May , ARC TOTAL PROJECrS Fundlng: Total Cost Fee Current tot a I: 218UU Unfunded total: 0 , 202717 Total contract:' 4U2lU 4U5123 wk-Per Salary Percost NonLabr TotCon rotchgs 1- 1 Ico.blned wlth Week 2 on PSR') , 2-1 3- 1 4 -I Total 1 5-2 ,- 2 7-2 • -2 Tot a I 2 1141 4056 5"2 171" 5027 5114 UU 5207 20221 lOU5 100H 14150 44577 lun lUU 120n lJOU 50514 12U7 5514 U2U 50240 511 1522 " 10 SUS 24401 U7U 15676 4Un "117 lJ512 21454 2UU 18761 75413 Balance Hl12 UIGH UUI 211744 UHO 2lHOJ ,.750 2U4OJ U718 21"15 22420 n7U5 22nl 174727 n241 25675., 77'17 25675., , -3 10-3 11-3 12-3 TA-7079-48 FIGURE 111-38 84 A BRANCH OF FI LE COSTS SHOWING COMBINED DATA FOR ALL ARC PROJECTS JUMP ro LINK M JLV :cosrs. 02127170 1534:27 JCN ARC 1970 PROJECr cosrs: PROJECr 7101 (RADC-old) PROJECr 7079 (NASA) PROJECT 8457 (RADC-new) PROJECT xxxx (ONR) PROJECT 8444 (Phlll~s) ARC TorAL PROJECTS TA-7079-49 FIGURE III-39 INITIAL VIEW OF FILE COSTS UPON ENTRY VIA LINK 85 ALL ALL JUMP ro LINK MHY :cosrs. 02/27/70 1~34:27 JCN : t [. 3-1 ·]OR[ ·PRoJEcr·]OR[·~ wk·]: [ • Cur rent • ] 0 R[ • PRO J Ecr· ] 0 R[ • Fun dIn 9 :.]: [ • Cur rent • ] 0 R[ • Un fun d e d·] 0 R[ • rota I co nt • ] 0 R[ • PRO JE cr· ] 0 R[ • Fun dIn 9 :.]: [·Unfunded·]OR[ ·PRoJEcr·]OR[ ·Fundlng : .]: [·rotal contract: ·]OR[ ·PROJEcr·]OR[ ·Fundlng : .]: [·Cum·]OR[·~ Wk·]OR[ ·PRoJEcr·]: no charges .OSN.:::1:.RrJ.:::0:.LSP.::0:.OLS.::0:.SCR.::1:.HED.:::·ARC PROjEcr cosr HIsrORY "70 ·:.NSW.:::O:.OPR.::O: [H]:lheadlng1:zxbbrDlnK) ARC 1970 PROJEcr cosrs: II- Wk - Per S a I a r y Per Cost PROJEcr 7101 lRADC-old) Fun dIn 9 : Cost Cur rent t ot a I: S 14~ ~ S6 4 Un fun d edt ota I : s 0 rot a I cont ract: S 14SH64 r ote 0 st r ote h9sea I an c e Non Lab r rot a I Fee ~S6 .RES: 58 o ~~H8 S 1~1~222 o S 1~1~222 TA-7079-50 FIGURE IlI-40 86 SAME AS FIGURE IlI-39 BUT WITH DIFFERENT VIEWSPECS TO SHOW CONTENT-ANALYZER PATTERNS STORED IN FIRST STATEMENT OF FI LE AL L ALL MlL JUMP ro HEM v ARC JC. lno wk-Pel" PROJEcr cosrs: Sa I aI" y Pel" cost PROJEcr 7101 (RADC-old) H67 J-1 3646 PROJEcr 7079 (NASA) 410 J-1 1025 PROJEcr 8457 (RADC-new) 3- 1 PROJEcr xxxx (ONR) 3- 1 PROJEcr 8444 (ph I II ps) 3- 1 ARC ro rA L PRoJECrS 4056 J-1 100'2 NonL abl" rot cost rot c h9s Balance 5556 146 2 3 1517 8 222845 28 1053 1120 5889 ~ 5584 15676 162H 281744 TA-7079-51 FIGURE 111-41 VIEW OF FI LE COSTS WITH CONTENT ANALYZER IN OPERATION, SHOWING DATA FOR A SINGLE WEEK ONLY. This' is done by using the first pattern appearing in square brackets in Figure 111-40. 87 JUMP TO ITEM lolL , f JCN Scratch File. 02/27/70 0.5.:30 JCN other Peopl,". file. Specl a I 1I nk. Vie-change Iinel , TA-7079-52 FIGURE 111-42 88 VIEW OF A USER'S FILE DIRECTORY, SHOWING FIRST-LEVEL STATEMENTS ONLY ALL ALL MHY JUMP TO ITEM t JCN scratch Flies 02127170 OU8:JO JCN JCN dally worklng NOTES. (Jplan.:zxOn) , Flnanclal and STATISTICAL data. (fund8. : zxOn) SpeCial operattonal COlt STUDIES. (study.: zxOn) Current 1'70 project COST SUMMARIES • (cost 8. : zxnO) STATEMENT of WORK ARC Project. ( st at e. : zxCn) Cost ESTIMATE: ESU "·1" RADC 11/14/" • (newe8.:zxbbn) Schedules: ESU RADC 11/14/" ( schd •• : zxbbgn) Cost ESTINA TE: ESU "·1 U ONR 10/U/". (onre8t. : zxbbgn) Schedules: ESU "·11' ONR 'shdon.:zxbbgnJ ARC: MSR deaonstratton OUTLINE. "·1.' 1"2"" . TA-7079-53 FIGURE 111-43 SAME AS FIGURE 111-42 BUT WITH ALL LEVELS DISPLAYED 89 JUMP TO LINJ( tHY AR C PER SONNEl t Present people people New ........................... 2 people Total .................. ; ..... 30 people +3 more durung t,70 (2/5/70) ....•.•••.•••• 27 Borro.ed.~ ..................... t+ TA-7079-54 FIGURE III-44 PART OF A FILE CONTAINING INFORMATION ON ARC PERSONNEL. (Not all levels are shown.) 90 JUMP TO LINK Present 12/5/701 •••••••••••••• 27 Ball. S .I.f. Bass. W.L. Baughman. V.R. Bosch. F. Van Den caldwell. M.6. Carliion. R.A. Caneres. 0.6. Church. M.S. Duvall. W.S. Engelbart. D.C. Engllsh. W.K. Geo11rlon. A.R. Hardy. M.E. Harrls. J.M. Ho~~er. J.D. lrby. C.H. leonard. loS. Melvln. J.lo Meyer. N.D. ~eople TA-7079-55 FIGURE I11-45 A VIEW OBTAINED BY JUMPING TO ONE OF THE STATEMENTS SHOWN IN FIGURE 111-44 AND OPENING AN ADDITIONAL LEVEL 91 JUMP TO ITEM MJlY Meyer. N.D. Nort on. J. C. O·Connell. D.F. Parsley. B.l. Paxton. W.H. Rat II f f. J. Ro •• B.E. Trundy. M.E. Van 0 e RI et. E. K. Borro.ed ...•.••....•....•••..•. 1+ peopl. Bro.n. D.R. 111201 Lelo. B. (11201 Yarborough. J.M. Ne •..........•..••.•..•.••...• 2 peop I e S yst ems Programmer .•..•••.•.•....... June 1HO Research Englneer.(Hard.arel ..•.... Aprll 1'70~ Total ........................ 30 people FUNC nONS TA-7079-56 FIGURE 111-46 92 A VIEW OBTAINED BY JUMPING TO THE LAST STATEMENT SHOWN IN FIGURE 111-45 ALL AL L CONTENT ANALYZER 8JLV ['*-secy']: ['*-SUPV']: ['Jsrpro1']: [ '*-pro1']: [ 'Jtech']: [ 'Jresasst']: *-hardware']: [, Jso1tware']: ..[,P' *-support']: [' JUSersys']: [, *-managementsys'J: ['Jprogrammlng']: [ 'Jnet work In 10'] : LINK .... I per sonne I: zxbbbhpi n) TA-7079-57 FIGURE 1II-47 CONTENT-ANALYZER PATTERNS STORED IN THE PERSONNELINFORMATION FI LE. Each set of square brackets contains one pattern, used to search for hidden "tags" in statements in the file. 93 JUMP TO L!Nf( I.f ardware: Baughman. v.R. Engltsh. W.k. r I.fardy. M.E. Meyer. N.D. Rat It r r. J. Row. B.E. Van De Rtet. E.K. Yarborough. J.M. TA-7079-58 FIGURE III-48 94 VIEW OBTAINED BY USING CONTENT ANALYZER TO SELECT ENTRIES IN PERSONNEL-INFORMATION FILE THAT ARE TAGGED FOR "HARDWARE" JUMP TO LINK Software: Bass. W.L. Bosch. F. Van Den church. M.S. Duvall. W.S. En91lsh. W.K. Geoffrion. A.ft. Harris. J .M. Hopper. J.D. lrby. C.H. leonard. L. S. Melvin. J.L. Parsley. B.L. Paxton. W.H. TA-7079-59 FIGURE 1II-49 VIEW OBTAINED BY USING CONTENT ANALYZER TO SELECT ENTRIES IN PERSONNEL-INFORMATION FILE THAT ARE TAGGED FOR "SOFTWARE" 95 JUMP TO LINK MHY 03/17/70 1525:26 JCN :.OLS=O:.RTJ=O:.DPR=O:.HEO=' SRI Il nks: (funds. annua I: zxbOn) (8chda. 1: zxbOnh) :NEWES. Pro~osal f (for the P ersonne I Colt s Dlrect Costs rotal Estlilated Flxed Fee rotal Esttllated • See attached cosr ESTlMA rE two year perlod It art lng 211/70) 1. 213.500 1.QU.1H Colt 2.106.U' 115.114 Colt plu. Flxed Fee I 2.422.013 schedule. Personnel a88ulled: TA-7079-60 FIGURE III-50 96 PART OF AN ON-LINE COST ESTIMATE FOR USE IN A PROPOSAL JUMP ro I rEM 01 r'ect Cost s rr'8vel Faclltty JConsu It ant s Re~or't Cost s rotal Dlr'ect rotal Esttlllated F t xed Fee rotal Esttlllated J- See attached , Costs Cost cost plus Ftxed Fee' Schedules 1.ULI7, 7.280 1.044.072 40.000 1. a2 7 1.0U.IH 2.306.'H 115.334 2.422.013 TA-7079-61 FIGURE III-51 PART OF AN ON-LINE COST ESTIMATE FOR USE IN A PROPOSAL 97 JUMP TO 1 TEM FACILITY COSTS Total FacIlIty Costs: C.OI\l~ut 1.044.072 er F ac I II t Y Su ~~ort l ease Cost MaIntenance and Ant I cl ~at ed O~eratlon 853.072 121.572 31.500 IIIl~rovelllent S Interactive External Core Conferenclng FaCility Console SWitching Facility Univac drUIll Interface Bryant disc ex~anslon Dtsc tnterface [XDS 7242) U 1. 000 12.000 15.200 n.lOo 12.000 21.000 10.000 TA-7079-62 FIGURE III-52 98 PART OF AN ON-LINE COST ESTIMATE FOR USE IN A PROPOSAL ALL ALL JUMP TO ITEM MHY , Accessory. Overvoltage Protection. lM·OV-2. lambda. t at 1]0.00. 8457-20. PO A'7"'. April 10. lHO. ekv. Jcomp .. , 7 Ad a pt e r . Ra c k. l RA -3. l a.b da. 1 at U 5 • 00. 8457 - 20. PO U 77". Mar c h 31. 1HO. ekv. JCOIDP" a Augat. 1042-10t thru 1042-1S1O. David 14. Rote Co .• 10 of each color at S1.10. 7101-23. PO U7475. ekv. JCo.p" , Amplifier. Video DistrIbutIon. -U1. Srate Valley Sroup thru Ward-Davis. 3 at 1115.00. PO U71U. 7101-21. January 2". 1HO. ekv . .. comp .. 10 Amplifier. Pul .. DistributIon. -'10. Srate Valley Sroup thru Ward-DIVIS. 1 at 1115.00. PO U71U. 7101-21. January 26. 1HO. ekv. '"comp .. 11 Augat Adaptor Plug, IlClug.). 81U-Ug'. Sterling. Electronics. at 11.'4. PO AU31!. 7101-21. February" tHO. ekv. JCOIDP" 30 TA-7079-63 FIGURE III-53 VIEW OF A PORTION OF THE PURCHASE-ORDER PROCESSING FILE, SHOWING CONTENTS OF INDIVIDUAL STATEMENTS 99 JUMP ro HEM HJLY PArrERNS useful for- sear-chIng (lInk hlddenl 3A outstandIng requIsItions ... no pur-chase or-der yet ( : I : ['PR ']AND -[ 'po ']AND -[ 'IP]:) 18 OutstandIng r-equlsltlons with a pur-chase order(: 1:[ 'po ']AND -[ '''COIllPIP]: 1 1C completed or-der-s (: 1:[ '''comp''']: 10 Recent changes to thIs fIle: .SINCE (70/03106 01:001: OUTSrANDING ORDERS EACH ~N J SECOND LEVEL fA CabInet. Stor-age rype. 1000. Shelcor Inc .• 1 at "5.'0. 10140-710. PR A17SOI. May • U70. ekv. 48 ro Regun CRr·s. 5CEP-" Sunbrlte ElectronIcs. , at "5.00. 8457-20. PO AU777. July 15. U70. lIleh. 4C 8Inder-s. Nylon Post Hanger-. '-HINBl. WIlson Jones. 10 at 12.17. 8457-20. PR A250t2. date. lIleh. 40 Car-d. 2 Input Nand Gate's. 502. Data rech. 5 at 127.00.8457-20. PR A25006. ber-. 4E Asselllbly. 4 Pr-ong Table Leg. 126. West Coast thr-ough Palo Alto OffIce Equlplllent. 10 at 136.00 (with 25 per cent dIscount). 8457-20. 4F Mar-ker-s.Cable. PWC-PK-1. l' x P. WH Br-ady Co .• to packs at TA-7079-64 FIGURE III-54 100 VIEW OF A PORTION OF THE PURCHASE-ORDER PROCESSING FI LE, SHOWING OUTSTANDING ORDERS LOCATED IN A SEPARATE BRANCH. Upper part of screen shows a branch containing Content-Analyzer patterns. All All CONrENr ANALYZER 6JlY 3E P·Relay·]ANO[qtot·]; + TA-7079-65 FIGURE III-55 A CONTENT-ANALYZER PATTERN FOR SEARCHING IN THE PURCHASE-ORDER FI LE 101 All All JUMP ro HEM IllY 3E ['Relay']AND['71QP]: S48 Relay. Phillips. Advance. 670SK-2CL Kler-ulff Electr-onlcs. , at 13.70. PO 65148. 7101-22. Apr-II 20. U". lIleh. TA-7079-66 FIGURE III-56 102 VIEW GENERATED BY A SEARCH ON THE PATTERN SHOWN IN FIGURE III-55 Sec~ion III APPLIOATIONS AND EXPERIENOE D. The Augmented 1. Repor~·Wr1tinl Team Introduction Thi. lection discusses the ceneration of large, contractually required report., since theae teat our capab11itiel mOlt thorOughly. Smaller, less formal repor~s involve a creat deal le.s effort) the advantage. dilcussed below are equally pre.ent, but the problems are in.1gnif1cant in comparison to the ones that arise with, tor example, a final re~ort. It Ihould be noted that much of this discussion is applicable to proposals and other types ot documents, as well as reports. a. Team Approach As in many other research groupa, none of our major reports are written by a .1ngle individual~ Secaule of the broad scope of activities re~orted _. ranging from management Iy.tems research to the detailed delien of software implementations •• we U8e a team approach, involving one or two individuals who coordinate the effort and numerous other. WhO contribute sections of material coverin, their particular I~ecialties. The present report contaln. material written by at least six peOPle •• the exact number i. hard to determine because lome material 1s adapted from ~reviou. document., using archived file 1 .aved for this purpose. Allo involved in the proces. are individuals whO mu.t formally ap~rove sections a. ~hey are written, the principal inve.tigator, who must ap~rove the overall report at various staces of completion, and a technical writer/editor. TY~icall" these perlons a. well &s the coordinators are al.o major contributors to the text of the report. This list exclUdes other SRI personnel out.ide of ARC •• editor., illustrators, officers Who mu.t approve the report, etc. Part ot the report-writing team'. jOb i. to conduct 11alson with theae people. 103 Section III APPLICATIONS AND EXPERIENCE Augmentation bears upon all a.pec~. of this team eftort. Becau.e of the flexibility of the tools (principallY NLS), the various in~iv1duall involved use the system in various individualistic ways. To 8ome, Nt! i • • imply a super-typewriter; to others, it il a high-powered stUdy ai~ for searching extstine material and extracting information needed in the current report. Some people prefer to do certain types of work with hard copy rather than at a console. These people use NLS for rapid production of hard copy of latest versions 01 parts of the report; after working on the hard copy, they use NtS for rap1d 1ncorporation of their changes and additions into the master files on line. To the coordinators, augmentation means the ability to create an outline of topics to be covered in the report, with notations indicating persons responsible for writing particUlar sections, comments as to desired aMounts of material and depth of coverage, deadlines for successive drafta, etc. Such an outline can be continually updated by changing the baSic plan of the report, adding or deleting sections, altering deadlines an~ assignments~ etc.; thUS the outline becomes a continuing statuI report of considerable complexity, yet with all information rea~ilY accessible because of NtS features such as the content analyzer. As sections of the report belin to take sha~e as NLS files, links to these files can be inserted at the appro~r1ate locations in the outline. Now the coor~in&tors, examining the status of the report effort, can jum~ instantaneously from a planning description of part of the report to a view of the actual work in progress; converselY, authors workinl on report sections can examine and reexamine the outline as they work. It is difficUlt to make a meaningful comparison between report-writing at ARC and elseWhere, because the process always depends heavily on tne 1n~1viduals involved and the organization'. general philOSOPhy about reports, as well as the facilities available. However, we can safely s.y that lO~ 8ec~1on III APPLICATIONS AND EXPERIENOE this kin~ ot close teamwork woul~ be quite im~o.s1blefor UI without the aucmentation aids that support it. To collaborate al tiChtlY as we do without augmentation, we woul~ need an immense amount Of time and a staff of full-time coor~in&tors, clerkl, and typists. J. Advantages a. Nt! As a tool for coping with the mechanical problems of report writing •• input ot material, a.semblY of material into a report structure, organization within the structure, text e~it1nc, an4 final output •• NtS has proven to be superb. For .ome operations, such as automatic searcning of thousands of words of text tor particular words or phrases, NLS is several orders of magnitu~e moreetfic1ent than paper-And-pencil technology. To illustrate the advantages of NLS, let u. briefly consider a few specific examples. For entering text, NLS become. a super-typewriter. This is ~robably the Simplest possible use of NLS. The advanta,es of NLS over a typewriter come from several factors. (l) Backspace-character and backspace·wor~ keYI, which caule immediate deletion of the last input character or word. (2) The user" knowled,. that further correetionl can ealily be made later. (3) The availability Of NLS" stUdY eapabilities. This i. ~he most eritical advantage, since it allows the writer to 10 back rapidly over What he hal alreadY written and reorient himself a8 he moves from one topic to another. As a tool for assembling, organizing, and reorganizing ma~erial trom diverse .ourcel (recent input, ex18~inl file8, etc.) NtS replaces 8uCh technology as the loole-leaf binder, the blackboard full of notes, the extra information writ~en on small Ilips of paper and clipped to palel in the looleleaf lOS Section III APPLICATIONS AND EXPERIBNCE binder, etc. In our present state Of evolution, this is neee.aarily incomplete •• the older metho~. are used in coordination with NtS, However, NtS dominates the overall tecnnololY for orlanizine material and to this extent it greatly increase, efficiency. re~laeement The master copy ot a report in progress is a set of Nt! files. The insertion of new mater1al as it becomes available is accompli8he~ quicklY and SMoothly, and the working material i8 completelY legible at all Itagel. The difference between workin, with a formatte~ NtS display and working with a binder of cut, stapled, paated, and pencil·marke~ typewriter co~y must be experienced to be appreciated. Moreover, a complete, fresh,. fUlly formatted printout of the eXisting draft can generally be obtained 1n a few minutes, at any stage Of tne job. The term "editing" 18 u.e~ here to mean the task of going throuCh a draft or a section of a draft and correcting errors of spelling, grammar, style, and (within limits) content. our reports cenerally receive two editing passes: one by ARO's technic&l writer, using NtS, an~ a second by one of the SRI editing staff using pencil·an~·paper metho~s. NLS permit. the augmented e~1tor to work a grea~ deal taster than he could with paper and pencil. Of course, he works with the knowle~ge that another e~itor will 10 over the draft and habitually leave. many ~ec1s1ons up to him. The advantage. of NtS for ed1tinl stem from two balic factors •• sheer speed, and the power Of automatic searching. The speed is just brute force in aetion: it is qUicker, for exam~le, to specify the command "Replace Word," point to a location, type the 106 Seetion III APPLICATIONS AND EXPERIENCE new word, and hit the "command accept" button than it il to make the equivalent marks on hard co~y. Using "Jump" commands to locate cross-referenced locations in the text is faster, by orders of magnitude, than flip~ing pages in a binder. AutoMatic searching for specified strings of text permits operations that are virtuallY impossible for the unaUlmented editor. For exam~le, many writers consistently m1.spell"certain words. The augmented editor can exeeute & "Substitute" command that will correct all ocurrences of several different consistent misspellings, throughout a file, in a single operation. For another example, suppose that halfway through a lengthy draft, the editor suddenly findS something that makes him uneasy about the way a particular term is being used -- a term used many times in the early portions of the draft. The unaugmented editor would be faced with the prospect of reexamining many pages of text, looking closely enough to find all occurrences of the suspect term. This situation is one that e~1tors encounter quite frequently, an~ the work involved is both lengthy and fatiguing. With NLS, the problem disappears; the editor uses the content analyzer to find all occurrences el the term automaticallY. If he then decides that a different word Should be used, he can use a "Substitute" command to make the change throughout the tile or in specified portions of the file. b. A Note on Structured Text our use of ".tructured text" -- i.e., a format that reflect. hierarchical relationShips among "statements" or paragraphs _. is somewhat controverSial with lome of ~07 Sec~ion III APPLICATIONS AND EXPERIENCE our re&~ers. Many of NLS'. Most valuable features depend upon structured text. Moreover, structured text has advantages of 1ts own. The special formatting carries information that i. not 1n the text 1tself, thus increaSing the overall "bandwlCth" and perm1tting greater economy in writing. structured text is a direct consequence of the use of the computer a. a writinl meaium, just as standardized punctuation re.ulte~ from the introdUction of movable type as 'he medium tor pUbliShing. Ho~efullY. structured text will turn out ~o be only the first step in the development ot new ways to show, by formatting and other nonverbal means, various relationships among the unit' of information that make up a document. c. A.sembly ot Reports As noted above, NLS 1s used to put together material from various sources to prOduce & complete draft. This raises the ~os8ib1litY of keepinl on hand a large collection ot material that de.cribes our work in its various ,specta, frequently updated 10 that at any time we can extract what 18 needed for a report. Thi. material, ideallY, would make up a very sizable part of eaCh report and woUld require only simple rewriting, thUS greatly reduc1ng the labor of report-writing. This idea has been with Us for years, and we have made lome progress in im~lement1nl it. TO the extent that it actually happens, it is very worthwhile; however, only a very small part of a typical report is actually done this way, In the present report, tor example, only the preface, the bibliograPhY, and the appendix are taken directlY from existing material. Larger portions are derived trom existing material, but with complex and extensive rewriting to luit the needs of this report. 4. problems The problem, of aUgmented report-writing tall into several categories, descr1bedin the following section •• 108 Section III APPLICATIONS AND EXPERIENCE To some extent, th~ problems are not merely report-writing problems but aUlmentatlon problems, l.e., problems ereateO by aide-effects of augmentation u~on the total ARO .ystem. a. Technical Problems The simplest problems are technical in origin. For the mOlt part, they seem not to relate to gaps in technical capability -- i.e •• "missing features" -- but rather to inadequate performance of the technical systems on which we have come to depend. As noted elsewhere in thiS report, system response is degraded when several users are working simultaneously; because of our team approach to report-writing, this degradation tends to be wors~ at the worst possible time -- just when several people are trying to complete their contributions to the report. A more critical prOblem arises from technical limitations on file storage. Two storage media, disc and tape, are available for report purposes. Tape, in the current .ystem confiluration, ia inconvenient &nO ean only be used tor lone-term backUp copies. In the last few months regUlar procedures have been established for tape archiving; so far, however, relativelY lew files have been saved on tape in such a way &. to be reasonably accessible. Disc .torag8 8~aceil severely limited. Reports take up a rreat deal of space compared to other types of tiles 1n use by ARC, while at the same time they are less usetu11n day-to-day work by ARC personnel. Work on a report generally inVOlves considerable Shuftling of files in order to obtain space for the new report files) tile. not related to the report are moved into out-of-the-way locations, and we sometimes lose track of them in this process. Duplicate copies are destroyed to make more room. and here there is a chanc~ of inadvertently destroying the last copy of a file. FUrthermore, if only one copy of a file ia kept we 109 Sec~ion III APPLICATIONS AND EXPERIENCE face the pos8ibility that a system error will destroy it. The actual 108s of a file has become a relativelY rare occurrence, as users have become aware of the problems and develo~ed habits and ~roeedures to safecuard their tiles. However, we expend a great deal of time and energy on these safeguarding measures, and this .eriously slows our report-writing efforts as well as all of our other on-line work. When work on a report is finished (or ~emporarilY halted) a reverse process takes ~lace: the report file. are hidden away, with a risk of 10.1ng them. b. prOblema of Explaining the HAUgmentation Culture" NL! and our other augmentation systems are part of an exceedingly complex total system that includes all of our set procedures for dOing things, our management methods, our goals, and our strategies and priorities tor doin, research. This total system is the tangible part of the "augmentation culture"; the intangible part consists of personalities, emotional interactions, intellectual orientations, etc. It is a tiny and incomplete culture with a brief history -- a laooratory model. Nevertheless, like most cultures it is 1neompletely understooa by the people inside it. The long-term aide-effects of any innovation are unpredictable, and occasionallY such side-effeets give rile to ~roblem8. The prOblems of the augmentation culture affect allot our activities to varying Oegree.; with reports, however, these problems are multiplied, because the central task i. (in princi~le) to eXPlain th1s same culture to a reader Who hal no d1rect experience of it. In practice, we rarely or never attempt a com~lete instead we describe various im~ortant aspects of our work, one at a time. Unfortunately, this leads to a 1ra,mented picture in whieh the true eontext of our work -- a whole-8~ltem approach -- tendS to become attenuated. ex~lanat1onJ 110 Section III APPLICATIONS AND EXPERIENOE c. problema ot Organization and Technique Practically nobody likes to write reports. What 1. worse, very few people are capable of writinl gOOd reports on difficult topic. without very great expenditure. of time and energy. At ARC, we have re'ponded to these problems in several way •• (1) We have developed an elaborate system of computer a1ds for writing (al well &s other purposes). (2) We have negotiated our contracts in such a way a8 to require a minimum number of report •• () we have used live demonstrations and films to supplement the communication lunction of reports. (4) We have experimented continually with different ways of organizing a report-writing team to function within our culture. Some commentary on these responses may illuminate the problems. serv~ to With regard to the first item, the computer aidS are magnificent (&1 described above). Reducing the total number of report. required ia debatable; 1t can be argued that it would be ealier and more effective to produce small reports at more frequent intervalS, thu. making final reports much leS8 critical and easier to write, lince they could lean upon the information contained 1n recent short reports. It is prObablY true that films and live ~resentations are more communicative of what we are dolng than any wrltten report could be. However, they do not lessen the ~eman~ tor lood reports and they cannot be stored on line for computer access. Experimentation with ways of organlzing the reportlnc effort will prObably be the mOlt fruitful way of SOlving the prOblems. We are It111 only beginninl to develop a lood III Section III APPLICATIONS AND EXPERIENOE organizational ap~ro&ch to the report ~roblem. The present report i . being produced under a rather elaborate ~lan of highly ~istributed authorship with a lingle individual as p ner, coordinator, and "pusher." At this writinl, our principal difficulties are in getting all the various authors to finish their contributions on t1me and in sticking to anyone scheme tor the organization of the many sections. Although early analysis may well be miSleading, the situation luggests that we have concentrated too hard upon the distribution of respon5i~11ity for writing sections, thUS neglecting other equally important requirements for a workable delegation of authority, better forecasting of the effort involved in various phases of the work, better timing, etc. E. The Aucmented presentation 1. General When & groue of peoPle meets for purposes of discussion, briefing, Planning, etc., it is often necessary to communicate & prepared body of information to them for reView, orientation, or tutorial purposes. The usual mOde in such a session (Which might be a meeting, lecture, leminar, or any other sort of gathering dealing with any sort ot SUbject from poverty problems to .ales policy to biochemistry) is for one person at a time to .peak, with various decrees of preparation, an~ various levelS of sup~ort from auaio-visual ai~s. Effective use of these &1d5 usually requires special pre~aration of ~he materials (tapes, 8l1~e8, charts, etc.), or special effort at the time to write on a blackboard or image-projector 8Uface -although occas1onallythere is an opaque projector or TV circuit that enables the speaker to integrate lome of hi. normal working mater1al into his presentation without Ipeeial preparation. To any Of us who are sealone~ user. of NLS, participating in conVentional presentation processes has become even more painfUl than it Was before we became accustomed to augmentation. we have grown 80 uaeO to 112 Section III APPLICATIONS AND EXPERIENCE the ability to move around ealily wi~hin any of our informaton base. (~e.1enl, documentation, reference material) and to Iwitch QUiCklY amone the many u.etul ways ot viewing the information,that we wish that sort Of ca~abi11ty were available to the Ipeaker. If a clo8ed-circu1t TV Iystem 1. available to di.~ribute the compute~-dlsplay 1macel to a group, then a speaker with on-line acees. to a computerized information system can indeed make an "augmented ~resentation." 2. EarlY Experimentl In October 1967 we let up a s~ecial conference room, with TV monitors arranged so that lome twenty peo~le, sitting around a rectangular table, could watch an augmented presentation. We inaugurated the facility with a two-day meeting between our staff and the technical monitors from the four agencies then sponsoring our work. At all times durinl the meetinc, the s~eaker sat at the Nt! control console (a position at the table that had a keYbOard, keyset, and mouse in a~dit1on to a monitor) and could instantlY access and display information in any of our total collection of f11es. Some of the material was specially prepared reference material for agenda purpolel, but most of it was our actual working material -- ~lann1ng, de8i«n, documentation, and scratch-note files. A trial acen~a wa. prepare~ ahead Of time 1n an NtS file~ but from the outset it was subject to ad hoc review and modification. To give the partici~antl a better mean. of talking about the displayed material (i.e., voicing questions, challenges, or IUlle.tiona), each had access to a Mouse which coul~ control a second tracking spot on the sereen. This spot was u.ed as one would u.e a wooden pointer to draw attention to an item on a blackboard; 1t was of different shape from the control Ipot used by the s~eaker, so it was easy to keep traCK of who was point1nl. Thil mode of running a project-review meetinc proved . very rewarding. We subsequently u.ed the setup frequently ~or special prelentat1on. (mostly for 113 See~ion III APPLICATIONS AND EXPERIENCE visitors), also with great succels, anO perhaps a dozen times for work1ng meetings of our group. In mid-1968 we dilmantled the setup, since we needed the space tor expanded shop area and the TV monitors tor more NLS conSOles. To let at le&.~ the capability tor a larger audience to view a display, we have had a flexible arrangement for attaChing two or more TV monitor. to one NLS eon.ole, We hola many demonstrations and presentations this way, for groups up to about 20 people. 3. Development of Improved Capabilities By mid-1968 we had acquire~ some special-effect. v1aeo equipment that cave us the following capabilities: Video monitoring and switching. An operator monitors images generated from a number of sources and can select from these the silnals to be channeled to various destinations. Video mixing: TWO lignals can be blended, with adjustable strengths, to superimpose two images. Signal fading: A selected signal source can be slowly diminished or atrengthened to achieve smooth, gradual tranli.tions between image-compolition state •• Image splitting: The .ereen image is divided geometricallY into two parts, each being the correspondinl trame part from a different image source. A horiZontal or Vertical dividing line can be set at any pOltion, or a rectangular inset can be made in one corner of the frame and it. size adjusted. We also located a NASA-owned EiOophor Video Projector at the nearby Ames Research Center and were fortunate enough to be able to borrow it on several occasions. It projects our video images onto a large sinlle screen with very high Quality and is suitable for ~resentations to large audiences. As we were learned of Films Inc. image (and 11k experimentinl with augmented presentationl~ we a special teChnique developed by W. A. Palmer of San Francisco for directly t1lminc the video sound trom & microphone cirCUit) to produce a Section III APPLICATIONS AND EXPERIENCE motion picture. On a number of occasions, we have arrange~ for a camera ana operator tcfilm our presentations. We also developed special coupling equipment enabling us to lease voice- and video-,rade transmission channels to a remote site. From the remote site, we can then use our computer system to support two regular NtS consoles and any associa~ed video-control and -projection equipment for conducting full presentations. i. Large-Scale Augmented Presentations We successfully used the full range of these techniques in two large-seale presentations -- in December 1968 at the FJCe in San Francisco, and 1n October 1969 at the annual ASIS meetin« in San Francisco. These presentations were set up with the main speaker seated at the front of the aUditorium, at one of our relular NLS consOles, to one aide of the large screen but in full view of the audience. He had a microphone, and could directly address them as though delivering an ordinary speecn. A TV eamera mounted near him caught a full-size face View, and a "prOduction manaler" for the presentation, seated at the rear ot the aUditoriUM with SWitching, mixing, and frame-splitting control, could put the face view on the screen tor a much more effective feeling of direct contact between spea~er and audience. When the speaker chose to use NLS, and turne~ his head slightly to see the NLS display screen, the projeete~ image would be 8witched to snow his computer-di.play view to the audience. Frequently, 1maces captured on mObile TV cameras in our laboratory at SRI were 8witche~ onto the projection .ereen, 10 that the ~resentation coulQ' include both a tour of our laboratory and participation from people located there. Four different re.earchers at the laboratory worked during the pre.entation at consoles in our work room (various shots during the pre.entation verified that they were there in the backlround, actually using the 115 Section III APPLICATIONS AND EXPERIENCE consoles whlle the rest ot the show went on1. At various times, the full face of one of the four was brought on screen, dialogue went on between him and the m&in speaker to introduce him and his topic, and then he took over and ran a portion ot the presentation 1n much the same manner as the main speaker had been doine -- the screen bein, able to show alternate (or split and/or mixed) images ot him and his display-screen image. For both conferences, the complete presentations (each about one hour and forty minutes in length) were ca~tured . on l6-mm film (black and white with optical sound). The ASIS film is the better of the two, and we have made eight oopies that have been in active loan cirCUlation Since tne first of the year. It 1s better than any earlier self-contained form for conveying an overall picture of our augmentation system. The eopies· have been loan~d to lome 70 organizations, incluOing several in Canada and one in France, and we hear of many repeat showings put on·bY a borrowing organization as a reSUlt of the response of the initial aUdience. one must see one of the movies to appreCiate the differenee between the augmented presentation system and what could almost have been substituted for it .- e.g., a ~rev10UslY made set of slides Of all the display-screen Views, and a very fast·actin, and large-capacity slide-selection system under control of the speakers. For clas.room lectures, for project brief1nls 1n connection with complex sy.tem-developmment· projects, for presentation of complex iSlues to a reviewing body (such a.a conlress), etc., these extensions of our augmentation system toward an augmented presentation system seem extremely promising. We intend to puSh further development of these techniques for application by smaller groups within a system-development team -- group meetin«s for brainstorming, plan and design reView, etc. S. Conclusions Alsuming tn,t technique. similar to ours are bound to 116 Sec~1on III APPtICATIONS AN~ EXPERIENCE evolve for widespread use in inten8eintellectual work both by individual' and in small crou~l, it 1s Quite obvious that extenSions to the techniques, ,uch as described above, for augmenting presentation. tolarcer croups will become quite important. Although pursuit Of pre.entation techniques is not our central loal, we woUld like to encourage a general appreciation ot it. potential. l17 IV A. THE NETWORK INfORMATION CENTER Overview of the ARPA Network 1. Basic Description The A4vanced Research projects Agency (ARPA) of the Department of Defense has inaugurated a novel experiment, the purpose of which is to explore the possibility for fostering effective, real-time cooperation and interaction be~ween approximately fourteen of its contractors, all of Which are doing research on the development of advanced information-processing techniques. To carry out this experiment, the Agency is in the orocess of establishing the ARPA NetworK, which is a data-communication network linking the computer facilities Of these fourteen research centers. Each of these centers has a coord1nate~ collection of resources -- both technological resources such as computers, storage facilities, input/output devices, ~nd softWare systems, and human resources such as knowledge, skills, and methOdologies. It has been necessarY, in ~ener&l, for these centers to engage in wasteful duplication of basic resources and to live with adverse restrictions on tne numDer and quality of special-purpose resources available to the researcners at anyone center. But wide-band connections between centers will bring many -- pernaps eventually all _. Of any centerls computer resources within the reaeh of every user in the Network. Two basic domains of work are involved 1n thiS experiment: (1) Development of technology tor providing intercommunication between programs in the different centers (2) Integration of the ~istributed resources of these centers into new patterns Of support for users of the Network. 1n~ormation·network technology i8 described in a set of companion papers presented &t the 1970 Spring Joint Computer Conference (see Refs. 20 through 24). The following simplified description is intended as background for the discussion of the Network Information Oenter contained in SUbsequent sections. Det~11ed 119 Section IV THE NET~ORK 2. INFORMATION CENTER Host-to-Ho.t Communication Each research center, or Network "nOde," will provide access to one or more local computers dedicated to research on information-processing techniques. These local computers are called "hosts." As part of ~he Network, ARPA supplies to each participating center a small, specially programmed computer called an Interface Message Processor (IMP) which is connected to the host (or hosts) for that center. The IMP provides each hOlt computer with a uniform functional interface into & network consisting of SO-kilobaud transmission lines leased trom telephone companies. Each IMP con~rol' traffic to and from its host or hosts, as well a. traffic along the Network channell. AS far as each host i. concerned, the Network may be treated as a mUlti-port black bOX with IMPS serving as the ports. Very much like voice-path connections between users of a telephone system, one-way message paths called "links" may be set up between specified hosts by the IMPs. For example, "Link AD3" might de.ignate a path from HOlt A to Ho.t D difterentiate~ from other Possible links from A to D by the label "3." Special Network-monitor programs reSident in each computer activate such links an~ negotiate among themselves to allocate them to s~ecifie communications-path purposes. nos~ The "0" links are reserved for control messages directlY between the monitors. 3. program-to-program Communication Program A in HOlt A may aSK for a communication link to be establiShed from it to Program B in Hoat B. As currently Planned, the following chain Of operations wOUld occur: program A SUbmits the request to Monitor A. Monitor A uses ControlL1nk ABO to necotiate this with 120 Sec~ion IV THE NETWORK INFORMATION CENTER Monitor B. After Monitor B ascertains that Program B is available for such communication, the two monitors together assign one of the AHn links to this communication purpose (for example, Link ABh). Monitor A verifies to Program A that its request has been fille~, and that Link AB4 is now connected to Program B. Program A is now linked to Program B bY what appears to the two programs asa private communication channel between them; any data Bent out by Program A via Link AB4 is delivered directly to Program B. Any sort of information that could be sent between two programs within the same computer may be lent along such a channel. For examgle, Program A might sen~ control information to Program B asking it to set up & reverse link, and to transmit along that link the results of processing a File B that resides within Host B. or conceivably, Program B could be asked to linK to HOlt C to get an~ process File C. Program A could be an interactive preprocessor serving a User A Who i8 connected directly and locally to Host A and for whom most ot the service i. being supplied by a Program B. Program B could be & soPhilticated user 5ubsystem such as Mathlab at MIT, the Culler-Fried system at UCSB, or our NLS. In any of the more SOPhist1cate~, display-oriented Subsystems, User A'S hardware could be different from the hardware used at Program B'. home site. program A might provide an adaptation for the partiCUlar terminal hardware being used by User A. It procably would also provide some of the local interactive feedbaCk such as character echoing at a full-duplex terminal. 121 Section IV THE NETWORK INFORMATION CENTER B. Some of Our 1. pros~ect~ve Ules for the Network Basic Processes A variety of program A that 1s likely to be established early at each host is a process that allows a typewriter terminal at that host to link to the timelharing executive in Host B. Such a process woU10 enable User A to log into the Host S's timesharing system and work as though he were a local user at Site B, using any of the typewriter-oriented SUbsystems that may exist in the B system. 2. Bootstrapped System-Transfer For our first experiment in Network usage we have established an interface to the University of Utah" Network host, a PDP-10 computer, so that a programmer at one of our consoles can use the editor and loader-oeougger at Utah to develop and check out programs to be run for our special use. This is the first step in a sequence of experimental uses of the Network that promisel to nelp us significantly in preparing to transier our software systems onto a new PDP-10 computer system next Fall. In carrying out this experiment, we will be coordinating a very large collection of technological and methOdological resources 1n a novel way. We are prOducing mOdified versions of all our language compilers. These new versions will still be run on our XDS9~O system but will produce object code for the PDP-10. Our programmers will compose, modif~J study, and compile the software being written for the PDP-10 using onlY the resources of our own Oenter, principally NLS ano the speCial compilers. Then, when there is need ~o test ·a piece of the new SOftware, they will activate Network link. to put them in communication with Utah's PDP-10 executive system. The compiled code will be Ihipped over the Network to Utah. where it will be loaded and 122 Section IV THE NETWORK INFORMATION CENTER execute~. Still working at our on-line consoles, our programmers will be able to debug the object code using the PDP-10's debugging facilities and, then, rapidly switch back to NLS to correct the source code as well. In this way we plan to bootstrap the development of & PDP-10 version of Nt! so that we can be up and running very quicklY when our own PDP-10 is installed. We ho~e NtS will have been entirely written and mostly debu~ged by then. The entire power of NLS will have been used during cyclic Itages of converting/rewriting, debugging, source-code upaating, and documentation. It is interesting to note that another PDP-10, which could be used for program checkout via magnetic tapes carried back and forth, is located just down the hall from our present computer. However, it promises to be significantly more convenient for us to use Utah'. PDP-10 connected directly to our computer via the Network. ~e can communicate our ~rolram8 to it mucn more convenientlY; and, while sitting at our own consoles to ·debug the programs, we can quiCklY switch to local Nt! to inspect or modify the source-cooe files or to enter no~es and documentation. 3. centralized File Archiving Another straightforward way we can benefit from the basic Network is by ~sing the file-storage system at the University of California at Santa Barbara as our file-arChive resource. Besides providing service to the local ARPA project, UCSB's host IBM 360/75 is the central resource of the University'S Computation Center. IBM 23lk disc-file transports, program. to store and retrieve files, on-duty operators to run back-up dumps onto magnetic tape, and aceounting and billing procedures to nandle serviee to miscellaneous users are all part of this resource~ We consider using their file-storage sf.tem as our 123 Section IV THE NETWORK INFORMATION CENTER file-archive resource. We woula interface this archive .ystem to our On-Line Sy.tem se that the response to a call for some service in storing or retrieving an archive file could function exactlY as though we were .toring anO managing the file locally. other Network user. could also u.e this file-archive system either by interfacing to it directly or by interfacing to it through us. This begins to sugges~ lome of the ~ower inherent in the network concept, since the number of subsystems available to each network participant can "pyramid" on the basis of a relatively small number of interfacing tasks. We COUld gain con.1derable economic advantage from .being able to share with many other users the capitalization and operat1ng-aecount1ng expenses involved in providing a basic disc-file archive system. Installing and operating such a service ourselves would be a distraction from how we want to u.e our manpower -but we have to have ihi. capability. Being able to use the Network to share this resource could be an important benefit to us. 4. Data-Sase Management service We a180 hope to utilize one of the big-compu~er host. with large discs and an operating staff, to help install ~ commercial data-base management system tor use by us and the rest of the Network. Again, the interface procesl WOUld resiae in our hOlt and give our users a data-base management service that ~ney can interact with &8 it it were a local service. None ot the protocolrequ1red to fire up the remote system, pro~erlY format service requests, an~ specify delivery ot it. product. need involve our ulers. To pre.ent our users with uniform conventions over all of our ~ifferent service functions, we would want to be able to compose service requests in an NLS file using 124 Section IV THE NETWORK INFORMATION CENTER our own particular syntax. In addition, to take advantage of NLS power in stUdy and we would want to have Query results ,converted into NLS-file form so that they can be integrated d1rectly into our regular working files. mo~if1cat1on, C. Need for a . ~etwork Information Center To pursue such relatively straightforward uses of the Network, a user will need to know answers to such questions as: What resources are available within the Network? What conditions are associated with the use of a particular resource at a given no~e? What interfacing 1s required to couple to this resource? WhO should be contacted to arrange for this? More generally. each site will also neeo answers to questions about other nOdes and about the Network such as the followinl: What are the hardware and software resources? What are the research activities? What are the operating instructions for a given resource? When will a prospective resource become available? Who 1s interested in new display systems? Who went to a particular conference? WhO else was interested in NIC Memo 7721? The whole Network experiment will consist Of negotiating, implementing, and operating many such arrangements. To carry out these negotiations effectivelY and to aocument the results of Network experiments, Network participants need access to information of the k1nds mentioned above al well as a medium for reeord1nl their experiences; it is the role of the Network Information Center (NIC) to service tnese needs. 125 Section IV THE NETWORK INFORMATION CENTER D. NIC 1. Develo~ment Activity Backgroun~ our involvement in the ~evelopment of the Network Information Center belan shortlY atter the official announcement of Plans to proeeed with the development of the Network itself. Realizing the importance of this information center to the success of the Network experiment. we volunteered to undertake the task of designing. implementing, and o~erating the NIC. Since then, we have been graduallY evolving and implementing plans for providing a coordinated and usetul collection of services to Network participants. This has proved to be a far more difficult task than we originally envisioned tor several reason •• The Network will provide a completely unfamiliar work1n« enVironment, and it is tar from Obvious just what kind of information services will be most conducive to effective action within that enVironment. our contracts have contained no speCific guidelines as to What form NIC services shOUld take, and other Network participants have been equally value and often contradictory in voicing their expectations with regard to the NIC. We also have had no previous experience in prOViding information services to users outside our own center, and have learned the hard way that this kind Of operation require. a kind of organizational structure an~ management different from that Which had been appro~r1&te 1n the early year, of our research activities. In designing the NIC, we were conscious of the fact that more was needed than just cood library facilities. The technical sophistication of the tools we ha~ available and of the users we would be servin, ~emanded that we seek to make it POSSible for this community to derive significant adv,ntage8 from the Network in term. of increaseO communication of iOeas, deSigns, criticiSMS, an~ comments on needS and possibilities. 126 Section IV THE NETWORK INFORMATION CENTER we recognized the challenge involved in fostering an environment that would encourage increased collaboration among individuals and groups at different nodes, and felt that the NIC would bear much of the responsibility for setting the direction of efforts to meet this challenge. And 1n designing the NIC we were aware that it would not be SUfficient merely to provide cood technical features, but that the design must reflect the Kind of coor~inated user-system I aervice-system interface that we have felt is so im~ortant in the bootstrapping approach to the development of our own augmentation aids. 2. orientation In order to gain perspective into what was expected or desired in the way of service from the NIC, we talKed with a number of Network Site managers a. well as with library science specialists. MOlt of the managers were uncertain about the nature and extent of their probable participation in the Network and did not know What they wanted from the NIC. What expectations we were able to uncover frequently showed extreme differences from person to Derson. Some thought that there was little need for a NIC, while other. thought that the NIC should supply initiative and lea~ership in the development of overall Network conventions and methodololies. Some thought that the NIC was going to serve &s a intermediary for handling working communication between hosts, providin« tele~ype bUffering and spooling operations, or that it WOuld be responSible for specifying protocols for ~ommun1cat1on between different types of terminal ~evices. The types of service to be provided, in terms of media for storage of dOCUments and metho~s of enqUiry, were perceive~ at pOints all along the continuum from Qompletely off-line to eom~letelY on-line. And the types of retrieval capabilities envisioned 127 Sec~ion IV THE NBTWORK INFORMATION CENTER ranle~ from fUlly automatic to fully manual. However, one reasonably consistent picture ~1~ emergel almost all the managers contacted ex~ressed & concern for the ~oor state of documentation within tneir projects and a hope thai the NIe would be able to helP them not onlY with Network-oriented documentation but with their in-house needs &s well. The need for improved documentation was seen not only in the area of "formal" documentation, such as user manuals and reference cuides, but also 1n the realm of the "folklore" that evolves around every system and that is an absolute necessity for making effective use of a system. Some managers expressed the opinion that a remotely located documentation-aid system might receive heavier use than one at their own site because there would not be the usual conflict between u.1ng the local facility's resources for Qocumentat1on as opposed to us1ng them for programming or other work, the latter always receiving higher ~riority in most researchers' mindS. Part of the "folklore," or informal documentation, would play the role of elearing house for communic&~ion on defect., bugl, neecs, possioilities, etc., and would help to provi~e feedback on the statuI and accecptability of existing or needed procrams and formal documentation. The outcome of these diSCUSSions, and of analYsys of the several tentative NIC designs that resultec, has been to take the pOSition that we shoulC initially prov1de Network users with a few relatively basic services and let the development of the "optimum" NIC evolve in a natural way as u,ale experience builOs up. ThUS, we are planning to help Network users gradually to apPly our concepts, conventions, tools, and teChniques to relevant aspects of their own working enVironments, While at the same time providing them with a reasonable initial corpus of reference material. We will m.ke every attempt to encourage and facilitate feedback from these users 80 that we can expand NIe 128 Section IV THE NETWORK INFORMATION OENTER services to meet their exchange. E. nee~s for information access and Ourrent NIC Plans l. Introduction We aim to be prepared to provide certain basic types ot services through the NIe, each of which will be expan~ed or elaborated 18 neeaed. This approach il our way of accommodat1ng the uncertainty about the user-population's information activity descriced above. This section outlines the measures we have taken to accommOdate these basic serviee needs. 2. Basic Library Services The foundation of NIC operation must be a flexiole library service, the development of Which requires us to: Accumulate a physical colle~tion of information items,in various sizes and media, and then store them in a secure and orderly manner. Provide a catalog in which the descriptions of these items are maintained, and from which can be Obtained the keys (clues), necessary to locate the physical item •• Provide indices and associated query procedures to aid users in finding catalog items of interest. provide direct me&ns for a user to obtain access to documents for which he possesses keys, ana enable "browsing" where possible. PrOvide direct reference help via two-way dialogue an expert. wi~h We will initially provide this basie library service. in ways not too dissimilar to those used by other special inform&t1on centers ana clearing houses. That 1s, we expect to be interacting with users through mail and voice-telephone channell, to be distriDuting hard-copy indices &nd catalogs, and to be mailing s~ecial query-response listings and references. 129 Seetion IV THE NETWORK INFORMATION CENTER 3. On-Line Services We are also seeking to harness com~uter. ~isplay. microform and communication technologies to elevate what a "library" represents to its community towar~ new levels of "augmenting the intellectual ~roces.es of communication and collaboration." To this end we are taking special measures toward "the way we do our librar~ work here" -- the nature of the collection, the form of catalog an~ indices, the procedures tor developing and maintaining them, ete. Ana we are investigating ways of improving s~eeial aspects of the user's interfaee to the NIC -- his query and browsing techniques, his means for doing bibliographic work, his means for publishing communiques to the community, hil means for staying 1n touch with current aetivities, ete. As the technology and methOdology of Network utilization develop, there will be a rapidly increasing number of widely distributed terminals througn which a person ean gain on-line aece.s to the NIC, and we are taking very strong measures to be able to serve them. Be.idee developing the services ~eser1bed below, we have inve.ted a creat deal of effort ~owar~ increaSing our service capacity with special system studies and the installation of a bank of external core and three high-speed SWapping drums; and this £&11 we will be shifting to a new computer (see Section II). We are prepared to supply some on-line query service as soon as the Network can support host-to-host full-duplex typewriter transactions ~- the simplest kind of general Network usage. Continual development of the variety and sophistication of the service will follow lines discussed in the re.t of this leetion~ During the next year mOlt remote on-line users will be served by TODAS, i typewriter-oriented version Of our On-Line system (NLS). Initially, both access to our SUbsystems and the number of Network users that we can aceommodate will be quite restricted, but we plan for steady improvement in both 130 Section IV THE NETWORK INFORMATION CENTER interactive quality and amount of the .erv1ce available to Network ulers. We feel ready to.support three Network TODAS users nowJ when installation Of the new drum. an~ external core is completed late this .ummer, we might be able to increase this to fiveJ and, depending upon the response possible using our new computer, we may be able to support as many as fifteen by the end of the year. ThOle sites having Oisplay terminals that can emulate typewriters with high transmission rates will be able to get fast-response from our typewriter-oriented system -service that is really quite respectable even without direct screen-selection means such as a mouse or tablet. We are currently mooifying an Imlae diSPlay console for remote use on our system, and we hope that it will become fully operational by early fall. It will eventually have full NLS capabilities inclUding our stan~ard mouse and key.et input device., and any other Network user possessing such a terminal could quicklY avail himself of similar service. As soon as we have tran.ferre~ our present systems onto the new PDP-10 computer an~ have achieved rea'onable stability 1n system reliability an~ rel~onle, we intend to concentrate upon developing tecnniques to permit general use of our NLS capabilities on a wide variety of remote di.p1ay terminal., and we anticipate having a growing Network load of this ty~e bY next summer. 131 V CONOLUSIONS, RECOMMENDATIONS, AND PLANS A. In~roQuction Our experience in Oeveloping and using augmentation systems, lome of Which was Oelcribed in Section III, gives us confidence in the validity of our long-term Roals and approach to augmentation re.earch. We are beginning to have strong feelings tha~ our efforts, still proceeding unOer ~he ,u10ance of our bootstrapping strategy, are on the threshold of yielding significant payotfs. The concept of augmentation systems is no longer in question -- such system. are bound to come. The only uncertainties involve the rate and direction of development and ~hat can be ~one to improve both, so as to foster more efficient evolution and ensure the earliest possible application of these systems to solving real problems facin, societ,. This section summarizes the conclusions we have ~rawn from our research program and outlines some of our plans for future activities. B. Conclusions Relevant to other AUlment&tion-System 1. Oevelo~er8 General Comments The experience we have had in setting up the Augmentation Research Center facility may not be directly apPlicable to other system Oevelopers, but there .till may be something to be learne~ from our accomplishments and disapPointments in implementing some of the components ot our system. In this section, therefore, we will take a look at our facility, evaluating some of its unique aspects and discussing some of the major prOblems that have been encountereO in it. eVOlution. This facility is described briefly in Section II-B, and a more complete description is contained in Ref. 18. 2. Accomplishments a. Display System (1) General our display system uses centrallY locate~ display-generating eQu1~ment and a closed-circuit television .,stem to distribute images to individual consoles. 133 Sec\ion V CONOLUSIONS, RECOMMENDATIONS, AND PLANS Tnis approach to di'~lay-.~.~em desiln was chosen on the basis of COlt an~ flexibility, and a ~etailed description of the system and of conli~erat1on. that went into it. desien is given in an earlier report (Ref. 11). After con.iderable experience operating this system, we are still plea.ed with the basic approach. (2) Usale Advantages The closed-circuit television system offers several distinct advantages over other mean. of producing displays at a user console. Since only a television monitor and a vi~eo line are required to present the diSPlay at each NLS console, the desien and location of consoles is flexible enough to facilitate experimentat10n with different types and to permit moving them about with a minimum of cabl!n, prOblems. The video s1cnal can be inverted to provide a dark-on-light display, which is usable 1n higher ambient light conditions than the more common light-on-dark presentation and which makes flicker in the di.play 1male less noticeable to the user. A significant storage time can be obtained on the vicicon surface bY proper aajustment of the television camera. ThiS reduces tne flicker effect that 1s present in the original CRT ~isPl&Y, and with this system we find it possible to produce satiSfactory imales with a regeneration rate of about twenty per second. (3) M&intenance Feature. Since the diSPlay equipment a~ each NtS console is simply a telev1.1on monitor, it can be replaced by a spare for maintenance without taking the console out of service. The location ot the diSPlay-generating eQuipment in the computer room, where complex maintenance and repairs are more convenient, make. pOSSible an uncluttered oftice environment in the user's working 134 Section V CONCLUSIONS, RECOMMENDATIONS. AND PLANS area. Hav1nc two identical d1.plaY Iystems, from display eontroller through aetual monitors, is a major factor in maintaining up-time in spite of the high level of maintenance that has been required on the.e systems. Since there is not a fixed one-to-one relationShip between ~1splay-generat1ng equipment and NLS consoles, users may select consoles freely on the basis of current nee41 even when part of the display .ystem is out of service. (4) Potentials for Extending Capabilities Since a great variety of commercially aVailable equipment i. compatible with our vi6eo system, there are many potentials for innovative use of our system that would be mueh harder to realize with conventional Cisplay-01stribution techniques. For example, we have used high-quality projection television al part of our presentations at the 1968 Fall Joint computer Oonference and at the ASIS Conferenee in 1969 (see Section III-E). It is pOSSible to use multiple TV monitors or intermediate-size prOjection equipment tor smaller croups, an4 experimentaion witn these techniques will be a major element Of the team-augmentation work to be carried out unoer our next contract. The video capability ofters aaoitional flexibility in the images th&t may be presented on the screen. For example, in the conference. mentioned above, live television pictures of the people and equipmen~ involved were freely used, ooth alone and after being mixed with computer-generated images. ThiS, also, will be a Significant factor in team collaboration at a distance where pictures of the people involved can be used, either mixed with or inserted alongside of the computer-generated images. 135 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS Another potential use of the microform ~ocument8. vi~eo is the viewing of Many systems are now aVailable that use close~·circuit television for the storage, retrieval, an~ viewing of microform documents, and we expect thi' kind of system to become more prevalent in the tuture. we already have plana for experimenting with various SWitching techniques in our diaplay-di8tribution system, and the inclulion of provisions for microform viewing woul~ require very little additional effort. b. NLS Conlole, (1) Console Design As mentioned above, the use of video for displa~s allows considerable flexibility 1n console design. We have experimented with many arrangements over the past few years and are now using the three basic designs shown in Figure. V-l, V-2, and V-]. (2) KeYboards The keyboarOs in use have gone through several stages of del1gn with special attention to touch and layout. They now have a key force of 80 crams and a good "feel." They are well accepteo, an~ we tinc1 that new user. rapidly accommoaate to the locations of special keys .uch al command accept and backspace. ()) Moule We fin~ that the mouse is still the most convenient locating device for our purposes. It 1s aescribed in Ref. 7, alonl with some experiments in the use of various selection devices. Available commercially, it is now u.ed on other systems a8 well al our own. (4) KeYlets The keysetl in use were desilned with special attention to "teel." Tolerances on the movinl parts are very close to give .mooth, po.itive action. Key 136 FIGURE V-l "HERMAN MI LLER" CONSOLE. This console, designed in cooperation with Herman Miller Research, was first used for the Fall Joint Computer Conference in 1968. The keyboard-keyset-mouse unit is attached to a swivel chair, with the TV monitor on a separate stand. It is a little confining to many people and the limited space for operating the mouse is an annoyance. However, it is reasonably comfortable and is useful for meetings and demonstrations because the user can turn and be part of a group while working. 137 FIGURE V-2 138 ON E-PI ECE CONSOLE. This console, designed about two years ago, basically a table on wheels with the TV monitor mounted at a suitable angle for viewing. Both sides of the table have pUll-out shelves for mouse, key set, and working papers. This console now seems too rigid to most users. The TV monitor is too close for some, and th ere is not enough extra working space for notebooks and papers. FIGURE V -3 CURRENT CONSOLE DESIGN. This console consists of a small table with integral keyboard. Connectors for the mouse and keyset are immediately behind the keyboard. The TV monitor is on a separate stand . The table stands low, placing the keys at a convenient level for typing, and other tables can be placed on either side for additional working space. This arrangement is very flexible and allows plenty of working space as needed. I t is particularly good for group collaboration, since the monitors may be turned for better group viewing, and entire consol es are quickly moved into different working arrangements as needed. 139 Sec~ion V CONCLUSIONS, RECOMMENDATIONS, AND PLANS spacing c. &n~ size &P~roximate those of a piano. Printer We value a high-qUality line printer that ~roduces upper-- and lower-case alphabetic. an~ a full complement of ASCII symbols. The one now in ule is a Data Products mo~el M600-11A, wh1eh hal been very reliable and maintain, hilh~quality output. We normally use specially perforated paper alone with our output-formatiin, programs to prOduce hardcopy, complete with ~re-punehe~ hole., Which is re&~y to be in'erte~ into a standard 8.Sxll three-ring hinder. ThiS feature has been enthu8iastically accepted and is of partiCUlar value 1n the prOduction of reports anO other documentation. d. Software Architecture The overall architecture of our SOftWare systems is described brieflY in Section II. The use of a compiler-compiler to augment the development ot a ver.aiile set of spec1al-~urpose language I hal proved quite valuable in facilitating debugging, rapid modification of existing feature8 and addition of new features, ana or1entation Of new programmers. our effort. to use higher-level l&ngua~es Wherever pOSSible shOUld result in adQit10nal payoffs when we transfer our software to a new computer this fall. e. The On-Line System Nt! hal been evolving for many years and has prove~ itl value both a8 a tool for-bootstrapping its own evolution and as a flexible laboratory for developin~ experimental working methOdologies (see, for example, Se~tion III). 3. problems The major problems we have encountered in developing our system stem from four basic diffieulties: (1) 140 Trying to fit a very large operational system into Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS har~ware (2) too .mall to support it Uling an available time.har1ng 'Yltem that hal inadequate to~ our purpo.e. ~rove~ ()) Developine too Much special hardware with the as.ociated probleml ot unreliability and mi8.e~ schedule. (k) Unreliability ot lome components of the facility, file .torace device •• ~articularlY a. Hardware Lim1tations Limitation. imposed by both the hardware configuration an~ the timesharing service system have resulted both in worse response and in the ability to handle a smaller number ot on-line users than we had expected. Moreover, this h&sre,ulte~ 1n the necelsity tor expendinl mere relource. on ~rOlr&mminl the service system than we had originally anticipated, and our planne~ work on evolving the user system has suffered acCordingly. We originally had hoped to be able to .erv1ee ten on-11ne NtS console. at a t1me, but we now find that only five can be operated with reasonable response to the users. The primary factors affecting this response time are .wapp1ng (core-drum transfers) an~ file 110 (core-di.c transfers). stUdies that mea.ured and recorded the time required for a prolram to be activated trom the lowe.t priority queue under various .ystem 10a4s SUII.st that an external core tor display bUffers will provide improved respon,e bY treeinc a maximum amount of memory for u.e in swapping (Ret. l6). To analyze tactor.affectinl ~he re'pon.e of the timesharing system, we developed a highly parameterized, discrete simulation model of the 'Yltem (Ret. 18). This was used to evaluate the impact ot changes in the hardware configuration, such as faster drum. or larger core memory, a. well a. the effect ot lil Sect-ion V CONCLUSIONS, RECOMMENDATIONS, AND PLANS various mixes Of user demands. Changes in the scheduling an~ swapping algorithms were also tested in the simulation, with the relultl being sUbjected 8ubsequently to experimental verification. The major hardware limitations of the facility are the maximum core aVailable (the 940 can accommo~ate only 6~,OOO word.), and the limited address space aVailable (a program can address only 16,000 woros). Maximum core limitation results in the swapping bottleneck mentioned above. Limited address space requires an overlay structure inordinatelY complex for a program the size of NLS. This means that programmers must expend a grea deal of enercy de.lgning overlay structure. and are constantly running into problems of full overlays as the system is expanded. This factor alone probably increased the cost of programming tne system bY ten to twenty percent. In retrolpeet, we recognize the error in the fOllowing de.ian decisions: The deciSion to refresh displays from main core memory was a ba~ one. Memory bandwidth is no problem, but ty1n, up the memory with ~isPl&Y images (Which reQuire "fro~en" pages of core) re~uce. the space available for programs and makes the swapping bottleneek even worse. With the present system design, providing feedback to a user requires that a program unique to each user be swapped in for every character of input. A different approach m11ht have eonsolida'ttec1 lome of the interactive !ee~back. thus re~ucing the swapping requirement •• b. Timesharing System Defects The tlmeaharinl system obtained for use on our computer hal been another significant facility limitation. 142 Sect-lon V CONCLUSIONS, RECOMMENDATIONS, AND PLANS timelharinl .y.~em wal one of ~he mo.t available .at the time we acquired1t, it hal proved 1t.elfinadequat,e· to provide ·the service wh1ch we mu.t have. Al~hoUghth1. ,ophiltlca~ed Partly thilis becau.e the de.icner. of the .ystem ~ld not anticipate aceommoda~1nc prolram. as laree as NL!. We are constantlY runnlnl into .1ze 11mit&~ions built .into tbe a •• embler, loader, and debuller. Another prOblem i . that we are ~be only people uling this tim'.sharing system tor an apJ)lication 11ke Nt! an~, therefore, have ha~ to carryon alone its maintenance and evolution. . There. still are many bu,s 1n the Iystem that would be totally unacceptable if we were not a releareh-oriented organization with few naive ulers dependent on the system for .ervice. Some of the,e bUll have been known about for two years or more, but hie her-priority ~emand' on our procrammera' time have alway' prevented us from locating them. witb tran.fer to & new computer now imminent, we plan to live wl~hthem a little longer ratber than wasting valuable enercy trying to fix them at thi. time. c. problem. with Custom-Built Hardware MUCh of the hardware in our sy8~em has been custom built to our .pecitication.~ either bY our own .taff or under contract. We have badly underestimated the resources needed for constructing some of thil hardWare, there,ults beinc mil.ed schedUles, failure to meet specifications (tor the diSPlay .y.tern in particular), and hieh maintenance co.ts. In putting together an exper1men~al facility tor aUlmentation re.earch, we now lee the de.lrabi11ty of re,tricting .peclal hardware development to tho.e areal mOlt directly as.ociatedwlth user feature. -- e.I" uler-con.ole d.slln. Wherever po.alble, use ,hou14 be made of commercially 143 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS available computers, interface devices, d1.play-ceneration equipment, etc. d. File-Storace Device Unreliability File unreliabilitynal allo relulted in considerable ;lols of time to both prolrammerl and other users. Althouchthe disc-tile .ystem we are using is Quite COO~ when compared with other. in.the COMPuter field, &deq~ate tile backup features were not incorporated into the .y.tem design. This means that ulers must either 10 through elaborate procec1ures to keep .everal coples of 1mportantflles or occasionally sutter Significant lost time when a file goes bad. Until file storage devices are much more reliable than those now available, sO~histic&ted automatic backup facilities should be designed into any system. 4. Maintenance Experience a. General General reliab1lity of the faci11ty hal been gOod. Computer up-time hal been hieh, although the reliability ot the di.c-file .y.tem hal been only fair. We had a period of several months of above-normal error rate, with five days down While cloCk track. were rewritten. The chain printer we orilinallY bought had marginal print QUality, was unreliable. and we had ~ifticUlty getting .ati.taetory maintenance service. consequentlJ, products drum per line with print quality so far it hal b. we have replaced the unit with a Data printer that hal 96 printing characters upper- and lower-ca.e alphabet. The 1a excellent (witne.s thil report), and been fairly re11able. Display System We have spent more effort on maintenance of the c11.play Section V CONCLUSIONS, RICOMMENDA~IONS, AND PLANS 'Yltem than on any other part ot the taei11t¥. lince our cSi.play .y.tem 1. lomewhat unu'U&l, we will di,cusl lome 01 the problem. encountered in .0 far a. they reflect con.1der,t1on. relevant to the de.1ln of other aimilar sYlteml. (1) one basic If,tem ,limitation hal been the 1nab111t¥ of the display-cenerator CRTs to produce adequate light for the Vidicon p1ckupa. Thi. mean. that many element. ot the display .y.tem are operatinl at marl1nal levels, The dilplay-cenerator ORT' mu.t be run at SUCh high intenlit¥ that their11te i. relativelY short. Th1, hiCh intenlity a1.0 caul •• ditf1eulties in maintaining good focul over the entire image. To operate with the.e low light levels, tbe vidicon' must be quite .en.itive, since sens1tiv1t, drop. off with age, they, al.o, have a relatively .hort uletul life. (2) Becaule tbe writing speed ot the d1.play generators is lowerth,n we had speCified, we have a flicker prOblem when III 8ix screens on the Iystem in use are rea.onably full of text. We can compenlate to .ome extent tor this flicker bY careful adjultment of the v1dicon beam current and target, but thi. &~justmen~ n.e~1 trequen~ attent1on. We have conlidered ul1nc lonler-per.iltance phol~hor. on the TV monitor. an~ w111 exper1ment withthi. in the near future, (3) In addition to the •• difficulties there are lome ba.ic weakne.ses in both the display generators and the televi.1on Iy.tem Which could be corrected 1n future de.1ens bY more careLul attention to component quality control and the inclusion of circuit-desien and layout feature. which would facilitate maintenance. 145 See~1on V CONCLUSIONS, RECOMMENDATIONS, AND PtANS c. Our General orientation Toward. Future Research Over the years we have frequentlY been face~ with the ~rOblem ot attempting to explain to people outli~e of ARC just what our on-Line System (NLS) is. It il usuallY tairlyea.y to let across the idea of aUlmentat10n in the ab.traet, but it il much more difficult to convey to people who have not made extensive use of NLS just how powerful it is as an augmentation tool -- it is very ea.y to get trapped into looking at NL! as just a nice text-editinl sy.tem without 8eeinl all the power that resiOel behind that particular a.peet of its surface appearenee. Recently we have ~eveloped a way of looking at NLS which helps to convey lome of the power that we know i5 present. and that is to view NLS a8 & worker's on-line "office" .- that is, his normal, dailY, local working enVironment. The analogy follows from the observation that to a naive v1s1tor an office can look like just another "room," but to the person who uses that office it serves as an interface to many of the capab1lities of an entire organization. The office serves as a ~lace where a person can work at organizing his ideas, studying correspondence, repor~s6 etc., and formatting hil own written materials. The Office has a'lociated with it communication linkS suCh as mail and tele~hone as well as access to secretarial and clerical services tnat are used on a daily basis. This lame sort of picture oan be app11e~ to NLS, for it 1& u.eo on a daily basis to help with organizing, stUdying, formatting, etc., and provides now, or soon will provide, many of the other communication and clerical services normally associated with "office work." NLS also has many similarities to an office in the way that both act as interfaces to extensive external capabilities. Just as one would not expect to find complete PUblication, laboratory, library, and filing facilities in the average Office, one 8houl~ at present not expee~ any single augmentation facility such al NLS to provide all the computational facilities that a person might wish to call upon. But, in the same sense that a person snould expect to be able to access extensive organizational resources 146 Sec~ion V CONCLUSIONS, REOOMMINDATIONS, AND PLANS from hil,oftice, he Ihould be able to aceels extensive computational resources from an NLS-like facility. For example, NtS provi~es all the capabilities needed for conatructinc, stuay1ng, and editing prolram. 1n any ot several.lanluac," however, the faci11tiel tor printing, compl1inc. archivlnl, etc. are not conlidered to be integral parts of Nt! and must be activated al "external proce.sor." by the Nt! u.er. Similarly, we have plana for implementing various mes.ale transmission and information-retrieval sy.tema as external processors, so that all the formattinl of input to these system. well the .tudyinc of the output from them can be done uling the powerfUl Nt! mechani.ms, While tne actual proce.sing can be carried out by independent programs running as background jObs on our timesharing system _. or even by program. operating on computers at remote sites. .1 .1 This otfice picture 18 very important to understanding how a research center such as ARO can make the most effective u.e of the resources of a netWork of interconnected com~u~ers such as the ARPA Network delcribed in Section IV. We antiCipate that Whenever we plan to make extenaive use of the re.ou~ee. Of a particular nede of the Ne~work, we will add facilities to NLS 10 that it· can be u.ed &1 an interactive intertace with those re.ource •• For eXample, if we were planning \0 use an information-retrieval system at 80me other Site, we would make provisions for the followinCI (1) using Permittinl the retrieVal requests to be formulated re~ular NLS technique. (2) Translating the request from our syntax to tnat required by the remote system an~ transmitting the reformatted reque.t out over the Network (3) Receiving the response trom the remote .ite and, finally, translating this output into a properly formatted NtS file so that it can be viewed and manipulated Using tools alrea~y familiar to the ARC Itlff. Thil approach appeals taus becaUle it promises to permit a 147 Section V CONOLUSIONS, RECOMMENDATIONS. AND PLANS member ot our researcn community to use IUbsysteml runninl at wiCely ~iltr1butea computer facilitie. without learning a new set ot convention. and u.er techniques for each different system. We believe that thiS way of viewing the role to be played bY an organization's local computational facility will become more widelY accepted as computer utilities and network. proliferate. When organ1zations become able to acee., a powerful and varied collection of re.ources merely by interfacing their local facilities to a network, it will become more generally recolnized how wasteful it is for each local facility to de.ign and implement all the computational capabilities it needs. It is likely that various computer "utilities" will evolve to serve the need. ot large communities of users for specialized on-line services that cannot be provided economicallY at the local level. By taking advantage of the load-levelinl that results from serving a large number of customers, utilities could develOp service facilities to fill ~he needs for large high-.peed calCUlations, archival file storage, searches over large 4ata b&sel, etc •• with very good average respon.e times and at relatively low COlt. Bringing ~he dilpenling of .pec1alized computation services into the "market Place" provided by resource distribution networkS could foster competition that would both accelerate development of this kind of .erv1ce and make posliblesignificant redUctions in the COlt of computational service. in general. In the context of th1s kind of development, individual relearch centers such as ours will be relieved of much of the chore of implementing and maintaining the ba.ic service capabilities necessary for daily operation •• Thi. chore, now dup11cated from center to center, con.umes an excessive portion of our collective re.ources. Effeet1ve computer networkS should permit computer science researcherl to reduce this du~lic&tton Of effort so a. to increase the rate of progress possible w1~h aVailable prote"ional manpower and com~utational resources. The.e research croups will then be able to focus more 148 Sect,lon V CONCLUSIONS, RECOMMENDATIONS, AND PLANS energy on the proClem8 that they are particularly well~equi~ped to handle. In our ca •• this might involve basic researeh to find the mOlt .atisfying ways to lrtterface & specific commun1ty ot u.ers to a network providing general ca~abl1lties, while other croups could apply their talents to areas of interelt such as mathematical Manipulation, computer Ira~h1c8, and 80 on. This.con.ideration becomes particularlY important when one realiles, as we are coming to realize to an ever greater extent, that the tools and techniques needed to constitute a "complete" augmentation system are far beyond the development capabilitie. of anyone research center such as ours. In comin~ year., we believe that significant deVelopments 1n the com~uter sciences will come about more and more as a result of the cooperative efforts of many research centers, each working on particular aspects of augmentation. The preceding comment. shOUld convey .ome feeling tor the power that we feel i . inherent 1n a network ot relearch-oriented eom~uter centers and provide a background for understanding our enthUsiasm for participating in the ARPA Network. We believe that being a part of the ARPA Network will be valuable to us in aCh1eving the goal. of augmentat10n research for .everal reasons. (1) It will live u. ex~erieneein workinc with a community of relearchers more varied and widely distributed than our own team of staff members. This will permit UI to lain adOitlonal inslght into the validity of our approaches to augmentation research by ob.erving how and to What extent our facilities can be ot service to computer users who are not captive members ot our local researoh community. (2) Network participation will provide impetus for our efforts in the direction of team augmentation bY creating a community of researcher. who are workinc on different aspects of a common problem at widely distributed geographical location. ana Who need new toola and technique8 ior communication and cooperation to succelfully 149 Sec~ion V CONCLUSIONS, RECOMMENDATIONS, AND PLANS achieve their common loals. BY working with such an extended community, we will be able to let ~oals an~ priorities in our relearcn program more knowledleably than we would be able to ~o it we were limited to augmenting onlY team. working in our own Center. (3) As mentioned above, we at ARC have come to realize that attaining the goall of augmentation research on a 'rea.onable time scale il a task far beyond the capabilities of anyone small research center such as ours, and we are very optimistic about the possibility of achieving a significant acceleration in the procress of augmentation research through network p&rtic1pat10n with other research centers having similar loall. D. Overview of Current Augmentation Research Center Plans 1. General a. Introduction The preVious section ShoUld give the reader some feeling tor the forces that have been .hapin, our plans for future research. Internal force. have combined wi~h those generated by our Network partici~at1on to produce a shift in our reaearch em~hasis in the direction of two general activities: (1) Research on team augmentation (2) Development of a system design discipline. In addition, increased awareness ot our need to communicate and interact with the outside world is leading us into the develo~ment of a new area of .~ecific concern~ discussed below under "Transfer of Results." b. Team Au~mentation Whereas in the pa.~ we gave most of our attention to augmenting the individual worker, we are now focusing on the augmentation of a team of collaborating worker., each of whom i . individually augmente~. 150 Section V OONCLUSIONS, RECOMMENDATIONS, AND PLANS The high mObility and mani~ulative e&~ability ot a skilled "augmented individual" has a unique potential which can be most fully realised when & number of aUlmented inOiv1duals join to form a collaborative team. Not only can each in~1vi~ual move very rapidly through joint working fil.. to stUdY them, enter new information, and U~d&te old material, but the group ~roce.ses of intercommunication and ooordination oan be facilitated by special com~uter aids, conventions, and techniques. The contemplateO efforts in "team augmentation" involve the development of several facets: (1) oonventions and procedures for organizing the working records of our plans, designs, Objectives, design principles, and schedules to give members of a team effective mutual "task orientation" Oy making all information related to the team's Objective optimally accessible. (2) A "Dialogue support System" to facil~tate rapid eVOlution of these working recordS throu~n dialogue among members of the des1gn team. ()) Techniques to facilitate simultaneous collaboration among peo~le at physically remote on-line terminals by giving them direct communication with one another, independent of their current in~1v1dual work interactions with the com~uter. ThiS inclu~es prov1s1on 6 where feasible, for the following: (a) Video and/or voice 1n~ercomMunication (b) Easy an~ flexible control of mean. for dU~11cating, at any terminal, all or part of type-out or d1lpla~ from another terminal the (c) Rea4y transfer of con~rol of one terminal's computer interaction to another terminal's in~ut cevice •• Special management and system-building techniques for use by an aUlmented team, and provision of app11cable technical intelligence and (4) 151 Sec~1on V OONOLUSIONS, RECOMMENDA~IONS, AND PLANS user training eapab111ties. These techniques are expected to evolve within ARC under eon~1tions of use in our own coordinated Iy.tem·developmen~ work, and to be applied over a wide ranee of eallaborative actions, from simple question-answerine facilities to complex design work involving intense mutual participation by team members. AS applicable tecnnique, become effective within ARC, we will explore their value for ~he following: (1) Support of Network Information Center (Nle) services such as teachine, question-answering and some types ot query servicinc (2) workinl collaboration between ARC staff personnel at other Network sites an~ (3) Work1nc collaboration between people at remote Network Sites, independent of ARC staff. c. Development of User- ana service-System Desiln Disciplines The functional features of the "user system" -- the collection ot computer aids available to an ARC worker -- have evolved with some ingenuity, a great deal Of cut-And-try experimentation in actual-usage conditions, an~ a certain .pec1al orientation offereO by our over&ll researCh framework. Until now, however, there na. been a significant lack of Objective, me~hodical engineering ~e8iln in the development of the overall user system. A user-system design discipline is definitely needed, and we intend to devote an increasing amount of effort toward developing such a diSCipline. Like the user 8ystem, the "service system" -- the hardware and software unaerlying the features for augmenting ulers -- hal evolved in an ad hoc fashion. Here there 18 also a .iln1ticant need for a .~stem-de.icn discipline. Such IYI'em.~e.ign discipline. would have communicable, teachable, and generallY applic&ble frameworks, 152 Sec~1on v CONCLUSIONS, RECOMMENDATIONS, AND PLANS .upport1nc coordinated set, of concept., term1noloCiel, principles, methoOologiel, and special tooll. d. Transfer ot R&sults Behind these basic a.pects of our work in the ARO (team and design d1.ciplines) 11es an essential feature of our lona-term stratelf, namely, the loal of producinc re.ults that will be of direct value to other croups of .Yltem ~evelo~ers -. in particular, to those who will be developing augmentation systems, aUlmenta~ion This is in contrast with beinc of direct value to customers wbo want systems tor their own direct use -- e.I., to augment a manager, a de.igner, an editor, or a scientist. Display ~ermlnals, communication channels, and computer service are de.tined to become both chea~ and ~lentiful, and it is certain that a very large number of organizations will want to use them. They must rely upon system developers who should be capable of the followinll (1) Analysis of .ystem-usace &nvironment. (2) Desiln and implementation of a smooth, powerful, and coordinated system of user al~s, eonvention., and metho~1 (3) Training and "edueation" of users unfamiliar with the potential of this new technology (4) Subsequent monitorinl Of user performance 80 al to implement the chance. nece.laryto track ~he evolution of users' att1tudea, concepti. 'kills, usage habita, and wants. Although it is important for us to stimulate the eventual customers for augmentation sy.terns by making them aware of the potential for these .ystem. 1n their work, we feel that our results ahould be directed ~r1marilY towards helpin, .ystem developers. We plan to do th1s bY pursuing the fOllowing long-term 10al'l (1) Making viSible an advanced, ln~ecrated Bystem, operating in a heavy-usage environment, that can lS3 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS orient system dev.lo~erl .to the available cOlt/benef1t tradeoff. (2) Developinl an effective .ystem-desi«n di.cipline to a14 in develo~ing aUlmentat10n sy.tems, whether or not ~hese systems resemble ours (3) Maintaining thoroulh, h11hlY current, comprehen.1ve documentation, desilne~ for qu1ck location of relevant material (4) E.~abll.h1nl wide-band communication channels over whicba dynamic interchange of information can take plaee, 80 that the maximum amount ot our knowledge can be quickly available 1n useful torm (S) Offering a complete prototype design of an aUlmentation system especially desilned for augmenting Iystem development, This system would be compatible with the sy.tem-deaign discipline' described above, and would includetecnnique8 for planning, analyzing, delilnin" pro«ramm1ng, debugging, documenting, an4 teachinl. our current approach to implementing the transfer of re.u1t. 4iseussed above 18 to Plan tor What we call the Syst~m Developer Interface Activity (SYDIA). We expect to approach representative candi~ate8 during 1970 with proposal. for multi~le sponlorship. The initial purpo.e of the SYDIA will be to ~evelop the following: (1) A facility for an effective interehan«e of information and skillibetween ARC an~ the eXisting and ~otentia1 community of augmentation-system developers (2) The ab~lity to a.s1st other Iroup. in transferrinc our system, or part. ot it, directly into other hardware and user environment •• Later, with .pecific individual fUnding arrangements, we expect ~o beein developing close1nterchange relation.h1~. with various system-development croups who could adapt our aUlmented teChniques to their own .y.tem·~eve10pment work. 154 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS 2. Team Augmentation Re.earch Plans a. Introduction We have already discussed the evolution that has been taking place in the goall of our research program. Havinl ma~e significant progress ~owara, realizlnl the objective ot aUlmenting ~ne individual intellectual worker, we find that the greatest augmentation need evidenced within our own Center at the present is for developing tools that will facilitate collaboration among members of a project-oriented or problem-.olving team of augmented in~1v1duals. It il no~ that we have already accomplished our original objective, and feel that we can now turn our attention elsewhere, but that team augmentation •• seen in the light of our bootstrapping stratelY .- offers the greatest promise of hastening the eventual realization ot these loal', We view the "augmented team" al a group of workers Iharing a eommon bale ot werking files and uling the mechanical element. of their augmentation syatem both a medium for goal-related commUnications and a laboratory for carrying out relevant experiments. a. At present we are mOlt interested in exploring the pOlsibilitiel for augmenting the activities Of teams who.e purpose 18 the ~evelopment Of a~vanee~ computer systems such a. our own. We feel that this is a ~rotitable way of inve.tine the resources with Which we are entrusted, not only from the stan~point ot our bootstrapping orientation, but also because augmenting this ty~e of team now is most likelY to have the create~t paYOffs 1n the lone run for 80ciety al a Whole. Over the pa.t year we have identified a set Of bal1c capabilities ~n&t.eem to meet the major needs of the augmented sy.tem-development ·team. The t~llowing description of these basic capabilities lSS V CONCLUSIONS, RECOMMENDATIONS, AND PLANS Sec~ion can be viewe~ a8 represen~inl a framework for ~he .y.tem·~evelopment activity that must take Place in the process of de.igninc and 1mplementin~ systems to realize the.e ca~ab1litie •• It al.o ind1ca~el, 1n~irectlY, the nature of other activities that will be concerned with integrating these capabilitie8 into our working methodology, applying them directly to the operation of our Center, and analyzing their effectiveness so as to provide direction to subsequent developments. rela~ed b. 'aat Editinc and Publication our already fait computer editing techniQues will naturally continue to evolve, and we are in the early stages of developing a powerful "Output processor" capability. The Output Processor is envisioned as a coordinated set of techniques for prOducing hard copy through a variety of media, SUCh as microform an~ direct publication on paper, ~Iing conventions that are compatible with those bY Which the a.sociated file material can be studied and manipulated on line. We plan to concentrate early upon automatic production, from our on-line files, of hard copy in whlch one can very flexiblY ,pecifY the eompositlon of text, diagrams, table" eqUations, footnotes, ln~1ces, etc. Dur1ngthe production process, such operatlons as convertlnl intratlle links to page references and lnterfile links to footnote~ would be pertormec automatically, with associated conversion table. beinc .• aved for future ule. one of our goal. for the next few year. i8 to develop a ,y.tem eouplinl a typewriter-like computer terminal with a microform reader that can be pos1tioneo to any page within its "library" upon direction from the central computer, This system would use conversion tables generated by the Output Processor durlne pUblication of tne micrOform library to ~rive the reader in response to directions from the user. Th1s would give the user 156 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS much ot the power for studying large bodies of 1nterreferenced documents tbat currently can be obtained only thrculh the u.e of & ~1Iplay·oriented .ystem like NtS. e. Plexdoc. A team tack11nl a complex Iystem-development ~roject MUlt provide itself with the highest possible viSibility over its work1nl environment •• 1.e., over the followingl Planningl plans, contingency alternative., resource commitments, status, cr1ticisMS Designing: deSigns, delien princiPles, constraints, est1mate8, analyses, .upportive data, relevant need. and po.sibilities Operating: role., talk definitiona, assicnment., pOlicies, operational procedures and conventions. We currently have quite powerfUl technique. tor aiding an individual or small report-writing team in prOducing document. of the usual reaearch-report size and complexity. But in our approaCh to team augmentation, we consider it e'sential to exp&nd upon these techniques 10 as to facilitate .the development and pro~uction of very large, very complex documen~. containing many deta1l' that are highly cross·dependent. We u.e the term ~plexdoc" to denote the concept of SUch a complex ~ocument, whieh WOUld, in fact, be composed of a p08.1bly quite larle eollection ot NL! file., crosl-linked in complicated ways. the stem "plex" comes from the Latin "plexus," Which means woven or intertwined, and .upports the image of a body ot informAtion that haa been woven into a coherent fabric bY a group of peOPle through the use of .pecial indices, footnotes. reader-contributed eomm.n~., specific crols-references, etc. We intend t~ develop and keep up to date a large, detailed, highlY crols-reterence4 and well-indexed "~lexdoe" that contains a description of our own 157 Section V CONOLUSIONS, RECOMMENDATIONS, AND ;LANS ~roject·team activity fulfilling the nee~s 118te~ above. Our techniques to facilitate it. mo~±fication an~ re~ublicat1on will be under constant evolutionary preslure. ~. Dialogue Between On-Line Collaborators (1) The Dialolue·Su~por\ system On-line access by collaborators to each other's files, as provided by a number of tOday" timesharing systems, leaves much to be de.ired 1n supporting effective d1alolue. In this context, we ule "~ialOlue" incremental building up ot a group ideal on any given IUbject through "comments" to lome set of relevant to refer to the expression of the addition of file •• We are attempting to meet the need for more fleXible and powerful mean. offacilitatinl sucn dialogue through the development of a "dialogue-support s,stem," Which we consider an es.ential element of any team augmentation system. The dialogue-support sYstem must function smoothly in conjunction with the plexdoc conventions to provide capabilitiea such as are de.cribed below. (2) Comment1nl Any team member working at a display console mu.~ he able swiftlY ~o access tor stUdy any portion ot a plexdoc's atruc~ured files, and he must be able conven1entlf to add his contributions to the on-going dialolue tha~ 1s contained 1n these files. Whenever he wi.hes, he shoUld be able to introduce comments that are treely sprinkled with explicit references ~o any Ipecit1citem (Character, word, 8~atement, line, curve. boX, expre.llon, etc.) w1~hin any prier entrf .- a. though he were pencil-marking a ~aper draft with marginal comment., underlines, encircled ~&ssagel, arrows, and the like. When creating a comment entry, he needS flexible 158 Section V CONCLUSIONS, RBCOMMENDATIONS, AND PLANS ai~. and me~hodl for the fOllowing: Arrancinc display of ~ne various ~a,s&les he ia referencing relative to ~he content of the comment he i. creatine Designating the explicit entities he wishes to reference Having the current comment-creation state preserved temporarily while he checkS on aome related material. This must be managed by the compu~er so that it does not matter if other people are concurrently scanning the lame material or affixing comment references to the lame items. (3) StUdy His stUdy techniques shoUld enable him flexibly to select which comments will be displayed for him and which one. will. remain invi8ible (or whose presence will be made known to him without appearing in their entirety). For exam~le, he may wish to be aware of onlY those comments that reference a given citation in a text, term in an equation, or label in a diacram. He qu1te likelY does not want ~o see reference indicators for all such prior comments, so he needs flexible mechani8m' for .pecifying which are to be vi.ible _. e.g., by author, creation time (relative or absolute), specific content, prior-assigned comment-set memberShip, author-affixed category ~e.ilnationl, etc. Al.o, whenever he sees indication that an interesting type of eomment 1s associated with some item in the stuOied passage, he needs considerable flexibility for designating how he will be shown such seleeted commen\. relative to the referenced material _. for eXample, in one ot the following way.: With & split screen (original reference text on the left an~ comment. on the r1ght) 159 Seetion v CONCLUSIONS, RECOMMENDATIONS, AND PtANS comment. enelo.ed within bOX.. and the boxe. embedded within the original text Ability to "flip" between views of the reference material and views of the comments, etc. (4) Notification provilion. nee~ to be' developed to enable setting up "annunciator call'" to varioul people, or sets of people, to request their spec1al attention (at some level of priority) to a given comment. This might call for actions such al the following: (1) An approval signo!! to recor~ the fact that the comment has been noted by the party or parties to which it was a~dressed (2) Some kind of speCial vote, automatically tallied and recorded on the annunciator specification in that comment ()) A need to observe & "pOint ot order" in the special method010I~ the team has adopted .- e.g.: "I protest ·this decision and call fer a review, citing Policy X, relative to BUdget Item Y and Design Principle Z." (5) Retrieval All aialolue entries immediately become part Of the plexdoc containinc the complete working recorOs (and much of the history) of the augmented team. Since comment. and other working record entitie' can refer to each other in indefinite extenSion, it will be po. sible to buil~ up a very complex network of relatlonsh1~s among tnele comments and the sUbstantive records about which the dialolue is swirling. AlthQugh these relation'hip, need never be ambiguous, it will be Ciff1cult tor even a knowledgeable team member to kee~ traCk of them in such a wav tnat he can effectively "navigate" through the plexdoe to tollow all the relevant developments that may be 160 Section V CONCLUSIONS, RECOMMENDAtIONS. AND PLANS takinl place concurrently. Thi. 11 about the toUCh.at central challenge in effectivelY aucmentinc a team •• that ot developing computer ai~l, workinl m.tno~s, ete. to allow & akille4 person to be highly effective in diceltinl the content and 1mplica~1ons of luch & ree~r~, and to develop a lubstantive next-.tage desien or plan that integrates the dialogue contribution._ issentiallY 11milar techn1~ues are require~ to augment any individualts central intellec~ual capability for synthesizinc the next stale of development in plan or design •• an~ to the extent that we are successtul with this, we shoUld be able to offer strong guidanee for capability augmentation over wide ranges of individual and team activities. our initial activities in response to this prOblem will be in the ~irect1on of providing powerful retrieval tools that will enable a user flexibly to specifY, by content, which elements of the Plexdoc are of createst interest ~o him at any moment. We also nave ~lanl fer developinc techniques that will ~ermit a user to construct .~ecif1c 1n~ice. an~ catalogues over a given plexdoc &n~ to create and manipulate arbitrary "lets" of entities that are of imme~iate interest. Many of the tools ~evelope~to fulfill these needS will also receive extensive uBein o~h.r ARC activities such as the Network Information center. e. Dl.tr1bute~ D1alocue We cons1~er it important tor people other than the central, highlY trained. ~i"Play·e'Quipf.'ed team to participate al well &S pO.'ibl' in ~ialogue of the type di.cus.ec1 above. We .eek to ~rov1de capabilities that function effectivelY over the Widest pos.ible rang. in lophilt1eation of computer, communication, and terminal facilities and in level of experience and l61 Section V CONOLUSIONS, RECOMMENDATIONS, AND PLANS training of the individual userl -- and with &s much independence a8 ~0881ble of geographical location. As a first step we intenO to worK on the problem of developing organization and formatting conventions for presenting plexdocs tor study on devices other than our centrally located .elective-view d1sPlays. We assume that for silnlficant participation via any type of couplinc with a low information-transfer rate (such as a Teletype), the user will need to have on hand comprehensively indexed hard-copy reference material that is repu~lished relatively often (e.g., weekly or even daily). We are already workinl on mechanisms for producing high-Quality hard eopy 1n both paper and microform (as described abOVe under "Fait Editin, and PUblication"). Our loal is to be able automatically to publish reference material (probably in microfiche) in SUch a way al to make feasible a frequent-republication operation servicing a mOderate number of remote participants. We have also begun to inve.tigate many different kindS of remote printing devices and are particularly excited about the high-speed, high-quality, .ean-~riven hard-copy devices now ap~earing on the market. We allo are investigating techniques for allowing a remote affiliate, such as a P&rticl~ant &~ one of the other ARPA Network Site., to use a manual micrOform reader (or even a volume Of paper printouts) in conjunction with a typewriter-like computer terminal through which we could ~rovide computer alds for locating items of interest and following the various kinds of cross-reference links. A next step (nearing operational status) is t6 provide facilities for direct, on-line, ~1alolue participation using TODAS (our Typewriter-Oriented Documentation-Aid Sy.tem). We are givins ~hl. speCial emphasis so al to provide for early access to Network Informat1on Center files. 162 Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS We are actively pursuing an extremely promising ~o.sibil1ty as.ociate~ with an emerCinc line of microfiche readers that can be oper~ted under direct computer control and Which permit jumping to any frame ot a fiche 1n a fraction of a .econd. MOlt of thele readers a180 allow jumping ~o any fiche within a cartr1dle, or even to any cartri~ge within a larcer store, 1n time. comparable to those we currently experience in stUdying files on line usinl our display system. Such a reader, loaded with updated cartridges from us, Where the reader and a typewriter terminal both connect thrOUgh the Network to our computer, can provide a perlon with very powerful hel~ in his plexQoc studying. He would be able to follow linkS, jump to an in~ex and from there to .elected points, jump .uccessively to the candidate .elections produced by a retrieval query, indicate where he want' to direct a comment reference (via typewriter entry of his comment) -- all via quiCk directions on the typewriter, abbreviated by cues (Which the computer knows about) that he sees on the screen of the microfiche rea~er. In some applications a frame·jum~ing microfiche reader/typewriter terminal system could be quite competitive with our high-response, on-line ~1,play console system, an~ we are very interested in ~eveloping experimental versions Of such a system for exploratory use in the Network Information Center. f. Conference Dialogue The team augmentation techniques we have discussed so far are all ~ireeted at aiding te&m member. workinc at indivi4u&1 computer terminals. There are times, however, when such a team will wi.h to convene as a whole to review some new proposal, debate a pressing issue, or collaborate activelY in lome ~articular phase ot their work. Section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS The "complete" team augmentation system must provide mechanisms for facilitating this kin~ of con1erence ~1alolue activity. We alreadY have experimentea with using NLS as a IO~hi8tieated "blackboard" where one person can Make & presentation to a group .eate~ Within viewing range of one of our regular NLS con.ole.. This gives new power for' presenting material and answering ~uest1ons &$ well as providing a very flexible me~ium within Which the record 01 the ~iscussion can evolve. In caaes where there are more viewers than can be comfortablY accommodated around the "chairman's" console, our display transmission mechanisms make it trivial for us to hook up a~d1tional "slave" ~onitors at convenient locations. At two of our major conference presentations (see Sect10n III-E) we have ule~ vi~eo ~rojeetion equipment to allow us to give live demonstrations of our on-line system to large aUdiences, and we are planning to purchase similar equipment for use in conference augmentation experiments at our own Center. . The next step along this avenue of research is the Oevelopment of techniques for allowing several users, each working at his own terminal, to COllaborate in real-time work on a common set of worKing files. We have experimente~ a little in allowing mUlti-console simultaneous access to a single file in Which one user (the "chairman") has full control while the other users are res~ricteO to merely positioning a personal Dug-mark on the ~1IPlay, each using his own mouse. With the evolution ot multiple viewing win~ows, a flexible voice intercom system, and other techniques will come opportunities for more SoPh1st1cate~ forms of interaction) and we are optimi.tic about the pos.ibility of aehievin, ailn1ficant increases in team effectiveness throUlh advances in real-time ~i&loIUe augmentation. Further down the 164 roa~, we lee a real need for developing Section V CONCLUSIONS, RECOMMENDATIONI. AND PLANS . I. that, without requiring an extensive training period, will extend the ability to participate effectively 1n augmented conferences to individuals with little experience 1n using the complex set of coordinated skills needed to competently operate our present on-line system. One possibility we envision is to give them a "chauffeur" to operate their on-11ne vehicle. te~hniQuel Voice Dialogue We hope to begln experiments 1n the near future using teChniques for the dlcltizat10n of normal speech 'trines, developed by Glenn Culler While he was at the Unlversity of Oalifornia, Santa Barbara. our plans are to modifY Nt! that a "statement" can contain not only the present text andlor graphic material but also a dilital representation of a speech string. '0 Then, with ~nlY .inor changes to NLS, we Would be able to provide techniques for breaking long 8peech strings into shorter ones, hierarChically organizing them, an~ providing cross-reference links between voice strings and normal text. u. These capabilities will permit to integrate a.ctual ·,poken dialogue into the dialogue meehanisms previouslY discussed, providing an extremelY powerful add~tion to our repertory of team-augmentation technique •• They woul~ be of great help to re~ote dialogue part1cipant. -. or even to our ownataft wh~n away frOm the office -- since Phoned-in comment. could be integrated 1n·to an" on-going dialogUe record, and they open new doors 1n the tealm ~1 conferertce ~ augmentation a8 well. Moreover, the anticipated gra~ual eVolution of speech-processing techniques will provide increasinglY powerfUl benefit. from this voice dialogue approach. h. Technical Intelligence To sat1fy our own needs as a research~eam, we have been a~cumulat1ng for many year. a .ilni!1eant corpus ot "intelllienee" (bibliolraphic) data about aetlv1t1e. and 165 Section V CONOLUSIONS,RECOMMENDATIONS, AND PLANS ~rOduct8 of orlanization. out81oe our own that are involved 1n related work, and we have committed ourselves to shaping u~ thls collect1on in order to provide It lealt parts of it (properly catalogued and indexe~) to other croups, particularly NIe users. In add1tion to maintaining an up-to-date collection of standard bibliolra~hic items, we ~lan to expand into new areas that are specifically rela~ed to the need. of system-development team.. We ln~end to belin seeking out and coll.ctinc data auch aa the followinl: (1) Characteristics of, and user experience with. various eommercially available and cUstom-made .ystem elements (2) Reference material ana user commentar1es on externally develo~ed sy.tem8 and techniques ()) Intellilence on the statu. and result. of related work by other groupl. We have begun development of a flexible let ot information-retrieval tool. tbat will be used ext&nsivelY in the maintenance and interrogation of our 1ntelligence collection a8 well a8 in the management of our complex working recor~1 (al ~ileusle~ above). i. U.er Training With any user-oriented system as complex and versatile as ourl, there is a continuous prOblem in helpinc new users to attain competence in operating the system so as to obtain the maximum benefits from it. This prOblem is m&ln1t1ed many time. when user. can work frommanv widely aeparated litel, making i~impollible tor them to receive personal help from experienced staff on a minute-te-minute basis. With a system evolving as rapidly al ours, it 1s difficult to kee~ even the central Itaff informe~ of all new system features and Ipecial methoQololies. We are Making lome prolres. 1n the preparation of training and reference materials for our user system, but there remains much to be done, not only 1n actually providing such materials, but 1n discovering what forms 166 Sect,ion V OONCLUSIONS, RECOMMENDA~IONS, AND PLANS Of indoctrination material. (films, video ta~e, introductory manuals, reference manuals, brief reference guides, etc.) are most useful. . j. Special Management Techniques The m&nale~ent of a technicallY lophisticated problem-selvina team requires the use ot some methodologieal technique. that are eommon to the manalement of any organized croup, a. well aa many others of a more specialized na~ure. There needs to be an accepted methodology for managing the files containing the team" workinl recordS 10 aa to ensure the most effective u.e of these files. Effective procedures need to be worked out for developing Plans for the future activities of the team, for negotiating and reviewing talk de.ignation. and individual rOle~. and for allocating and accounting for the resource. possessed by the team. Finally, there must be well-understood an~ accepted ways of defining, repre.entinl. and monitoring operational proee~ure8 and of relolvinl conflict. between elements of the team regarding the allocation of resources among the act.ivities of the team that must eomJ'ete tor them. k. Special System-Building Techniques In addition to the capabilities oescribed above, which are relevant to the needs of all problem-oriented teams, there are some considerations that are uniquely a~plieable to a team whose domain is system ~evelopment. The system-development team need. to have a consistent, it not complete, .et of ~rinciplel for ~esi~ning the overall SOftware-architecture Of interactive systems. It must develop an understan~ing of the principles underlying the design and analysis of interactive systems from the standpoint of user services. It must have effective technique. tor training new users of the systems it hal implemented and tor generating useful reference materials for these systems, 167 Section V CONOLUSIONS. RECOMMENDATIONS, AND PLANS It must have flexible methods for obtaininc anllyzinc performance ~a\a on a .ystem. an~ It should have powerful way. for simulating significant parts of an existine sy.tem an~ tor limulating newly conceived or modif1e~ sYltems in order to ~1&gno.e existing bug., predict luture performance under varioul con~itionl, and com~are the performance of proposed sYltem ccnfiluratons with that of the existing one. FinallY, it must nave highlY aucmente~ techniques for creatine. compiling, and ~ebugging the huge collection ot progr&ms used in the implementation Of a large software system. 3. Development of System Design Disciplines I. Analysis an~ Desi,n principles for on-Line User Systems Designing a Whole augmentation system involves, balanced conSideration of many factor., all Of which are SUbject to reevaluation an4 chance in response to increased understanding gaine~ through experience. The following are examples of SUCh factorsl (1) Ways in Which users conceptualize their workini talKS (2) MethodS for representing and recording these conce~t5 (3) procedures for developing the concepts and prooucts as.oc1ated with & given talk (4) Forml of computer aids and utilization methOdOlogies needed to obtain maximum help in carrying out such working procedures (5) User techniques for negotiating service transactions with the system in various contexts. At pre8en~ there is no desien discipline encompaSsing thi8 ranle of interdependent sfltem factors, but one really must evolve if anYlarle·.cale benefit is ever to be derived trom the computer service. that we clearly lee coming over the horizon. 168 Sect.icn V OONCLUSIONS, RECOMMENDATIONS, AND PtANS By a "design disciPline" we mean a cOherent, communicable, generally applicable framework comprising a coordinated set of conce~ts. terminologies, principles, methodologies, and special tools. Thi. ~e.iln discipline must proviae a common ground for analyzing the needs of a community of users, formulating easilY communicable designs for systems to meet these needS, and providing adequate controls over the implementation process. These capabilities should make it possible to offer clients accurate cost/benefit pictures prior to any extensive commitment of resources and Should make the design and implementation processes more effiCient. Consider the predictable tremendous increase' in speed, capacity, and economic availability ot computational resource., and then realize how the Quality of service represented by these resources can be enhanced through the application of ever more powerfUl artifictal intelligence techniques. We con.1der it desirable to avert the ~o8s1bi11ty of all this power being harnessed in ways that leave these mechanical helper. remote and unlnvolved trom our minute-by-minuie human activity. We need to learn how to design luch systems and how to a~&pt our thinking an~ working methOdologies so that Quick little bits ot service can be harnesled on our own terms. A lignificant challenge is involved in finding ways for matching these computer services to human perceptual, cognitive, anomotor mechanisms so as to optimize workinl capabilities and provide a natural and satiSfying extension of human capacities. Design Of the repertoire of user services to be provided by a com~uter/communic:at1on/terminal fac11·ity 1. a procell requiring the kind of coherent deSign discipline aSlociated with any complex sy'tem desien proces., and we conSider the development ot SUCh a discipline for augmentation-system design to be a vital component ot our next phase of research. 169 Section V OONCLUSIONS, RECOMMENDATIONS, AND PLANS b. SOftware Architecture principle. for Interactive SYstem De8ign (1) Overview JU8t aa important to us as the development of a d1.cipline dealinc with the analy.iJ and desiln of user .ervices 1- the development Of a companion di8c1~11n. Oea11nl with the design of sottware architecture for interactive systems offering these services, Theae two discipline. are actually just opposite faces of the same coin and must be interfaced so as to form a single overall di.c1Pline that provides a unified approach for going from user needs Itraight through to integrated operational systems satiSfying those needs. To erganize the conceptualization Of such a system desiln into appropriate level I and areal, and to develop effective repre.entations of the des1gn specifications and principles at each such level, seems neces.ary if we are ever to transform interactive system de.iln from an art into a profession. Our present software architecture approaCh Itresses the.e things and promises to make useful headway in evolving eonventions, proceaures, and ai~s that coUl~ hel~ other people ap~roach an~ operate on the architecture ot com~lex computer IYltems. We ~elcr1De below lome of the approaches that have evolveO in our work and Which we feel otter the foundations tor a aelign discipline of the type we are seeking. (2) oompiler-Oompiler TeChniques Almost all our programming is done in some member of a whOle family of lanluAges based on our Tree Meta syntax-directed compiler (see Section II-6-2-b and Ref. 18). Thi. teChnique provides us with great flexibility in 170 Section V CONOLUSIONS, RECOMMENDATIONS. AND PLANS fit\inc each programminl talk in~o a language particularlY appropriate to the requirements Of that ta.k, yielding more efficient ule of vital programmer time al well as code that i. SUfficiently self-documenting to aid conliderably both 1n the debUlcing of our .ystem and in the orientation of new prolrammer •• (3) Format conventionl for Source-Co~e Language Filea A very1mportant feature Of these speCial language. 1s that their format and structurinl convention. have been designed so as to fit particularly well into our augmentation-system usage enVironment. This provides a very rewarding and powerful degree of fac11i~y for composing, stUdying. and modifying source code. The Plexdoc approach described previously has evolved from a belief that all levels of de.ign and analys1. thinkinc and data should be integrated into one compatible Iystem of files over which the deSigners and supervi.ors, and later ma1ntenance personnel~ colleagues, etc., can roam freely and adroitlY. ThiS approach haa been applied to lome extent in our present collection of system-program files. This collec~ion torml a pleXdOC by vir~ue of the fact that intertile link' can be used as the argument. of ~rocedure calls; the internal system documentation is also linked into this plexdoc. Dialogue-support techniques have an important contribution to make at every level of this process in providing an integrated approach to recording, documentation, and monitoring. (4) System Architecture principles lostering Development by an Augmented Team Evolu~1onary we have begun to apply various modularization concepts to our working and thinking methOdologies .0 al to foster the ability Of individual members Of our research/development team to work effectively on specific aspects of our project with the least POI sible chance of de.tructively interfering with other activities. 171 section V CONCLUSIONS, RECOMMENDATIONS, AND PLANS These concep~. are also 1mpor~ant to the way in which we view part1eipa~10n in the ARPA Ne~work. in that we are seeking flexible ways of interfacing various modules of our own operating system. to computa~ion component. available at other site. through the Network. We allo seek to exploit the properties of modularization to promo~e delign clarity and facilitate tran.ier of ~rograml and technique. to other systems and croupl. The extensive attention to conceptual partitioning through use of a variety of apecial-purpose programming languages is one example of this. 172 Appendix A USER FEATURES or NtS AND rODAS I The on-tine A. SY8~em (Nt!) In~roduet1on NtS, al currently implemented, 11 e.sent1ally a hilhly sophiltieated text-manipulation system oriente~ primarily toward on-line use; i.e., it 18 not pr1mar1ly oriented toward production of hard copy, altnoulh fairly sophisticated har~-copy tormatting and output are included 1n the system. Nt! is intended to be used on a regular, more or leIS tull-time basis in a time-sharin, enVironment, by users who are not necessarily com~uter prOfessional.. The users are, however, aSlumed to be "trained" as opposed to "naive." ThUS the sYstem is not designed for extreme simplicity. nor for self-explanatory features, nor for compatib1lity with "normal" working procedures • . Rather, it il assumed that the u,er has spent considerable time 1n learning the operation" Of the Iy.tem, that he uses it for a major portion ot his work, and that he consequently is willing to adapt his working procedures to eXPloit the ~ossioi11tie. of fUll-time, interactive computer assistance. ThUs the practice. and technique. develope~ by users for NtS are as much a SUbject ot research aa the development of Nt! itself. eX~lo1t1nc interea~ NLS is supplementeo by called TODAS, Which is appendix. Section III for ~roducing flexiblY files. a typewriter-oriented counterpart diseusleo in Section II of this describes the NLS/TODAS capabi11ties formatted hard copy from on-line Section IV of this appendix is & glossary ot special NLS/TODAS terminology. B. NLS Console The user lits at a console whose main element. are a di.play .creen, a typewriter keYboard, & curlor device called the "moule," and a let of tive kef' operated by the left hand, ealledthe "keyset." The screen 11 used tor diaplayinl text, in variou. formats. The top portion of the screen (approximately 173 Appendix A NLS/TODAS USER FEATURES lIS ot i8 reserved for feedback kinds: the name of the user in effect, a "regilter" area uaed for various kindS ot textual/numerical feedback, an "echo reel-ter" Which display. the last elx Charac'erl typed by the u.er, and other items that are eXPlained below. ~be to~al area) lntorma~ion of various comman~ mode currently The keyboard closely resembles a conventional typewriter keyboard, with a few extra key. tor special characters and control functions. It is used for typinl text as content for a tile and for specifying commands, Which are given as two- or three-character mnemonics. is a roughly box-shaped object, about four itl longest Side, Which is moved bY the right il mounted on wheel. anO rolls on any flat The Wheels drive potentiometers that are read converter, and the .,stem caUses a tracking 8~ot ("bug") to move on the screen in corresponOence to the motion of the mouse. The mouae inchel on hand. It surface. by an A/D The user specifie.location' in the diSPlayed text by pointing with the moule/bug combination, Thi. eliminates the need for specifying & location bY entering a code of some k1nd. use of the mouse is very easily learned and soon becomes unconscious. on top of the mouse are three special contrOl but~ons, whose uses are described below. The keyset has one key for each finger of the left hand. The keys are strUck in combinations called "Chor~s," and each coord corresponds to a character or combination of characters from the keyboard. There are 31 ~68sible chOrds} beyond thiS, two of the buttons on the mouse may be used to control the "cale" of the key.et, livinl <erna~lve meanine' to each chord. There are four po.sible cases, for a total of 124 pos.1ble comb1na~ion •• A simple binary cOde is useO and ha. proved remarkably easy to learn. TwO or three hour.' practice is usually sufficient to learn tne most commonly used chordS and develop reasonable speed. The keyset wa. developed to increase the user's speed 174 Appendix A NtS/TODAS USER FEATURES and smoothness in operating NLS. It wal found that users normallY keep the rilht haneS on the mou.e, because the great majority of command operation. involve a pointinc action) efficient use of the keyboard. however, requires the use of both handS, and Shifting the right hand (and the user's attention) to the keYboard 18 d1stractinc and annoying if it mu.t be done for each two- or three-letter command mnemonic. Use of the keyset perm1ts the user to keep his right·hand on the mouse and his left on the keyset,reverting to the keYboard only for entry of lone strings of text (typically five or more characters). Originally, the keyset exactly duplicated the keyboard in functionJ in the ~evelopment of NLS, however, certain control functions have been made two-stroke operations from the keyset where they would be three- or four-stroke operation. from the keyboard. Nevertheless, it i . still possible to operate all of the features of NtS without using the keyset; thus the beginner may defer learning the keyset cOOe unt1l he haa lained some degree o~ mastery over the rest of the system. C. structured Text "Text" is used here as a very general term. A "file" of text (corresponding very roughly to a Udoeument" in hard copy) may cons1st of English or 80me other natural lanlu&ge, numerical data, computer-program statements, or any thine else that can be expressed as a structure of Character strines, Simple line drawings can also be included in a file. All text handled by NLS is in "structured-statement" form. This ~pecial format is SimplY a hierarchical arrangement of "statements," resembling a conventional "outline" form. Each statement in & file may be conSidered to .possesl a "statement number," which shows its pOlition and level in the structure. Thus the first statement 1n a t1le 1. Statement 11 its f1rst 8ubstatement is la, and 1ts next .ubstatement i . lbl the next statement at the same level as the first 1. Statement 2; and 10 forth. statement 175 A NLS/TODAS USER fEATURES Appen~1x number. have been .uppre.leO in printing out most Of this Oocument but are printed out for tbe remainOer of this section as an example. 2c2al Every statement also bears a "signature" that may be ~ilplayea an command. The s11nature 11 a line of text giving the initials at the uler who create~ the statement (or modified it most recently) an~ the time and date when this was done. 2c2b A statement il simplY a string of ~ext. of any length; this serves as the basic unit in the construction of the hierarChY. In English text, statements are normally equivalent to paragraphs, section and subsection headings, or items in a list. other ty~es of text, statements may be data items, program statements, etc. In 2c2bl Eaeh paragraph and heading in this document is an NLS statement. Each statement is indented according to its "level" in the hierarchy) this paragraph il a substatement of the one above, which is in turn & substatement of another statement. A statement may have any number of lubstatementl, an~ the overall structure may have any number of levels. 2c3 Note that when a user creates a file, he may let all of his statements be firat-level one., i.e., 1, 2, 3, etc. In thi. cal. he will not have to consider a hierarchical structure but simply a linear list, as 1s found in conventional text. 2c3a However, many of the features of NLS are oriented to make use of hierarchy. and the benetits of these feature. are lost. if hierarcny i8 not exploited. 2e)b This is an example of an NLS feature to which the user mU8~ accommodate his methode; however, the experience of users has been that hierarchical structure very rapidly becomes a completelY "natural" way of orlanizing text. Many automatic features of Nt! make the structure easy tousel for ex&m~le. statement number. are create~ automaticallY at· all times and the user need not even be aware of them. It is IUfficient, when the user creates a statement, to specifY its level relative to the preceding Itatement. 176 Appendix A NLS/TODAS USER FEATURES D. Ule Of the System Text manipulation is con8i~ered to involve three basic types.ot activity by the user, composition, study, an~ modification. In practice, the three activities are 10 intermingled as to be lndistlncui.b&ble. 1. Compo.itlon Composition is SimplY the creation of new text material as content for a file. In the simplest ca.e, the user gives the commana "Insert Statement" by typing "il". He then pOints (with the mouse) to an existing statementJ the system displays a new statement number which is the logical successor, at the same level, as the statement pointed to. The user may change the level of this number upwara bY typing & "u" or downward by typing a "dUe NOTE: If no previous statement hal been create6, the system displays a "dummy" statement at the top of the text-~isplay area, and the user points to this dummy in order to insert his first statement. The user then types the text of the new statement from the keyboard. on the sereen, the top part of the text-display area is cleared and charaeters are displayed here a. they are typed. When the .tatement is finishe~, the user hits a CA (eommand .cce~t) button on the keyboar~ or mouse, and the system re-creates the di.pl&~ with tne new statement following the one that wa, pointed to. New material may also be added to existing statement. by means of commands such as In.ert Word, Insert Text, and others. ProperlY speaking, these operations are modification rather than compo.ition, and are discussed below. Simple line drawings may be composed and added to the file by means of the "vector package." This is di.cussed in another section of thiS report. 2. Study The stUdy capabilities of NtS con8titute itl most l77 Appendix A NLS/TODAS USER fEATURES poweriul and unu8ual te&~urel. The follow1nc 1. onlY a briet, condensed descri~tion of ~he operations that are pOlsible. a. Jumping NtS files may, ot courle, con\ain & Kraat deal more text than can be displayed on the screen, just &1 & document may contain more than one pace of text. An NLS file is thoulht ot al a lone "scroll." The procell of moving trom one point in the scroll to another, which cerre.pond. to turning pacel in hard copy, is called "jumping." There il a very large family of Jump commands. The baSic Jump command il Jump to Item. The user specifies it bY entering "ji" and then points to some statement with the mouse. The .electe~ statement is moved to the top of the screen, as it the scroll had been rolled forward. MOlt of the Jump commandS reference the hierarchical structure of \he text. Thus Jump to Successor brines to the top of the a1sPlay the next statement at the 8ame level al the selected statement; Jump to Predece'Bor does the reverseJ Jump to UP starts the dilplay with the statement of Which the .elected .tatement is a sUbstatement, and 10 forth. The Jump to Name command u.es a different way of addres.ing statement.. If the fir It word of any statement i. enclosed in parentheses, the sy.tem will recognize it a8 the "name" of the Itatement. Then, if this word a~pe&rs somewhere else in the text, the user may jump to the namea statement by pointing to the occurrence of the name, or bY typin« the name. This provides & cross-referencing e,~ability that 1. very SMooth and flexibleJ the command Jump to Return will alway. restore the previous dis~lay, 10 that tbe u•• r may follow name reterence. without losing h1. place. It il allo pOSSible to jump to & statement bY typing it. ,tatement number. 178 Appendix A NLS/TODAS USER FEATURES b. View Control If a file 11 lone, it may be impo8sible for the user to orient himself to its content and structure or to find specific sections by jumping through it. The principal solution to this problem is provided by level control &n~ line truncation. Level control permits the user to s~ecifY 80me number of levels) the system will then display only Itatements Of the specified level or higher. Thus if three level. are specified, only first-, second-, and thira-level statements are 01.played. Line truncation permits specification of how many lines of eaCh statement are to be displayed. Thus it one 11ne i8 specified, only the first line of each statement will be displayed. Common usage 1s to use the first two or three levels in a file al headings describing the material contained under each heading in the form of BUb8tatements. Thus the u.er may start by lOOking at a display showing onlY the first-level statements 1n the file, one line of each. This amounts to a table of content •• He may tnen select one of these atatements and JUMP to it, specifying one more level. He will then see more details of the content of that part of the tile. This process of "expanding the view" may be repeated until the user has found what he is looking for, at which pOint he may specifY a full display ot the text. Users loon Qevelop a habit of structuring files in such a way that ~h1s procels will work well. A. it happens, such a structure is usually a IOOd, lOCical arrangement of the material, reflecting the relationships inherent in the content. The level and truncat10n controls are destIned 10 that the necessary specifications may be made with only ene or two stroke. of ~he keYbOard or keyset. These controls are only the most 1mportan~ Of a large set of view-control parameters called "VIEWSPECS." Other VIEWSFECS control a number of special NLS l79 Ap~.n~ix- A NtS/TODAS USER FEATURES fea~urel aftectinl ~he display format. An example of the use of VIEWSPECS i. liven below in Sectien I-D-2-e of ~hi8 appendix, c. Content Analy.is The Nt! eon~ent analyzer permits au~omatic learchinc of a file fer statement. satilty1nl some content pattern .pecified by ~he user. The pattern 1s written in a .pecial lanlu&ce &1 part at the tile text. Conten~ pattern. may be .1m~1., specifyin. the occurrence of lome word, for example. They may allo be highlY complex, Ipecifying the order ot occurrence of two or more .trines, the absence of .ome text con8truct, conditional .pecification., etc. Simple patternl are extremely eaay ~o wrlteJ complex onel are correspcndincly more difficult. d. "Ke,word" System A "keyword .tatement" i. an_mad .tatement that references other Itatementa 1n the tile bY name, in a Ipecial format. The naMe of the keyword .tatement -i. then under.tood to be a "keyword" a~~l'inl to the Itatement. refereneed by the keyword .t't.men'~ Suppo.e that a file contains a lls~ ot keyword Itatements. The u.er may .tudy this lilt and select several keywordS wi~h the Ke,wor~ 8eleet command (pc1ntlne to the keywor~. with the moule). He may specify a we1cht from 1 to 10 for each ke,wordJ it no we1lhtl. specified, a weight of 1 1.&slume~. When the user cive. the Keyword Execute command. a .earehinl/.corine procesl 1s executec. EaCh of the lelected keyword statement. is Icanned for the name. of statementlthat it reterence.. Each referenced statement recetvee a "acore- equal to the we1ln~ of the ke¥wcrd~ It a statement 1. retereneed in more than one keyword Itatement, the Icores add. 180 A NLS/TODAS USER FEATURES A~pend1x When this process is completed; NLS constructs a display picture showing only the statements that have received nonzero scores, 1n or~er of decreasing scores. In other wordS, each keyword is the name Of a statement that defines lome arbitrary category of statements in the tile. When a user selects an~ weichts keywor~s, he 1s ex~re.sini his interest in certain of these categories. NLS then ~isplays all of the statements in these categories, beginning with the "most interesting." Because the relationshi~8 use~ in this sy.tem are set up ex~lie1tlY when a user writes keyword statements, the system 1s very flexible although not highly automated. It may ~e regarded as a generalized method of reordering some of the .tatements in a file on the basis of user-selected criteria chosen from a supplied lilt (the keyword statements). Note that this reor~ering is on the display, not in the file proper. The file proper is not affected in any way, except that the list of selected keywords and weights is saved in the tile. This list may be ~1splayed on command. Indiv1dU&1 keywords may be deleted from the li~t or tneir weights changed, or the whole list can be deleted on command. e. Link Jumping A "link" is a string of text, occurring in an ordinary file statement, that indicates a cross-referenee of some kin~. It may refer to another statement in the file, or to a statement in Bome other file, pOSsiblY belonging to another NLS user. The text of the link ia both human-readable and machine-readable, and the command Jump to Link permits the user to point to the link with tne mouse and immediately see the material referred to. An example of a link is (Smith, Plans, Loncrance:ebgtn). 181 A NLS/TODAS USIR FEATURES Appen~ix ~he first item in the link ind1cate. that the reterenced tile belongs to a user named Smith; the seeond i . the name of the li1eJ the third il the name of a atatement in the tlle (a statement number ma~ a180 be uled)J and tne .trinl of charaeterltollowinc the colon control' the VIEWSPECS to set up a particular view Of the material. The Jump to Link eomm&n~, exeeuted b~ po1nt1nc to this link, would caUl. Smith'. tile "Plansto be automat1cally loaded &n~ the display, Itart .et to the .tatement Whose name 1. "Lon,ra~le." VIEWSPECS would be au\omatlcall~ set al follOWS, The "en causes the number of levels di.played to be,set equal to the level of the di.play-.tart .tatement. The "b" incrementa this by one. The "I" speeifies that the diSPlay il to be limited to the "branch" defined b~ the di.plaY-ltart .tatement •• 1.e., onlY that statement,itl sUbstatementa, their IUbltatementl, etc. The "t" .pecifie. d1'Pl&~ ot onl~ the fir.t line of each d1sPl&~ed Itatement. The Un" .pecifies ~h't statement numbers are to be luppre.sed trom the ~18play. Thus the net result 11 to displaY the fir.t lines ot statement "toncrance" and its hilhes~·level ,ubl~atement., without .t&tement numbers, 'Tbe use of1ntert1le link' permits the conltruction of laree linked Itructure. made up ot many filel, an~ stUdy oi these tiles a. if they were all sections ot a .incle aocument. The Jump ~o File Return cau.e. the iile previou.1Y viewed ~o be reloaded and diSPlayed, with the lame ai.pl&~ .tart and VIEWSPECS that were in eltect ju,t before the l1nk jumpJ' thu. the user ml~ 182 Appen~ix A NLS/TODAS USER FEATURES execute link jumps freelY without 10ling track of nil orig1nal location. 3. Modification A larle repertoire of editing commands is provided for modification of files. The basic functions are Insert, Delete, Move, and OOpY. These function. operate upon various kinds of text entities. Within statements, they may operate upon .1ngle characters, words, and arbitrary strings of text defined by pOinting to the first and last characters. This set of commands 1s not restricted to operation within one statement at a time; for example, a word may oe movea or copied from one statement to another. The editing functions also operate at the structural level, taking statements or sets of statements as operandS. A number of s~eeial entities have been defined for this purpose: for example, a "branch" consists of some specified statement, Plus all of its .ubstatementl, plus allot their sUbltatements, ete. A branch can be ~eleted, moved to & new ~osit1on in the .tructure, etc. As note~ above, tne modification activity ten~s to merge, in practice, with stUdy and com~os1tion. E. Summary It must oe noted that NtS 1s not a system designed for general usage, but a I~ecialized tool designed lor a ~roup of people working on the developmen~ of computer aida to human intellectual proeesses. It i . for this reason, tor example, that NLS is not really a text-editing system oriented toward hard-copy prOduction, but rather somethinl s1multaneou.1Y more general and more specialized. It il in the process of manipulating a f11e .- stUdying it, makinc mod1fic&tions, addin, new material aa an intelrated procell lasting for minutes or hours at a time and having a continuity extenaing tor days, weekS, or even years -- that the real benefit of NLS appears. An NLS file tendS to become an evolv1n, entity, subject 183 Appen~ix NtS/T~DA8 A USIR FIATURIS to eon.\ant mo~ificat10n, upda~1nl, andreevaluatlon. It. deyelopmen~ ma, have no clearlydellned .ndP01n~. It may ca •• e· to ex1.t a. a fl1e by beinl incorpora'.dln ano~herfl1e, or lt may eventually be abandoned or .uper.e4edJ however, 1n mo.\ ca~e. it will never be -finished" in the usual .enle of ·the word. continuous u.e of NtSto ~tore ~deal, .tudy them, rel.ate them .trueturallY,and croll-reference them re,ul~' .1n a .uperior orlanlla~1on o~ ideal' and & creater' abl1i~y to man1pulateth •• further for .peci&l purpo.... a. 'be need ari.e. .- whe\her the "1dea'" are expre •• ed a. natural lancuale,a.data, a. procramminc, or &1 Iraphlc information. II The Typewriter-oriented Documentation-Aid System (TODAS) TODAS 11 a text-handline .y.tem de.llned a. a "typewritercounterpart to Nt!. In principle, 'TODAS can be opera\ed from a Teletype or any other .ort ~t:hard-cOPY 'erm~nal. ,includinl 'ermlnal' .11nkedto ·\he 9kO throulh aCQu.tic, COUPler. and ordinarytelePbone l1ne. (as opposed to NLS, Which require • • plclal ~ran.ml •• lon arranlement.). Tbe pre.en\ i.pl•• en~ltlon .1low. lor·the u.', 01 Te1e~1pe Medel' 3'~ "S, and ",Termlnlt and I~ecuport ~.rmlnal' (the litter beinc portable, with a built-in' acou.tlc COUPler), and Nt8 d11Play con.ole'. lachel the.e terminal. h'. i~. own ehar&ete~~ •• t, no two let.beinlexactlY tbe.ame except Teletype MOdel." and 35. a relult, .peclal·c~&rac\er a •• llnmen\.are device-dependent. A TODAS fe&tur';ll~ow. tbei u.erto red,tine charac~er. at will to .u1~hi.lmmedla'. purp~ •••• 'I An important u.e ot TODAS1. tor ace ••• , within theAR" Oo.pu~.r Ne~work,to the Network Information Oenter (HIe) operated by ARC. TODAS will etve: Network, u.er. Icae •• to 111e. of information creatld eitherw1th TODAS or with ~LS, .inee flle. created with tbe two Iy.tem. are ldent1cal. in Itructurland format. TODAS hal many ot the .ame capabil1tie. a. NtS t~r the :aanlpulation ottext, it dltters from NLS al required b~ the UI, 01 a "typewriter" ~eviceinltead 01 a d1.play. The important d~tference. arla. fromtbe fact that TODAS ha,'no analol curlor device to carre.pond to the NtS meule and trcm Appendix A NLS/TODAS USERrEATURIS ~he leneral1~ .lower operation 01 TODAS. For this realon, editinl of text wi~h1n a ItateMent cannot be done b~ means resembling those ot NLS, since all of the NtS edltlnl operandS are indicated by the user with the mouse, TODAS u.el two alternative method'. One 1. the TODAS "alter" command, which operate. very much like the "mOdifY" command of the QED line-editing .y.tem developed by Pro~ec\ GENIE at UC. "Alter" create. a new statement to replace the orilinal one, bY loinl throUCh the original from beglnninl to en~J under u.er control, characters are (1) copied from the old .tatement to the new, (2) Skipped over, or (3) inserted into the new .tatement from the keyboard. The other 1s the TODAS "SUbstitute" command, which allow. the u.er to specity that a certain string ot characters 1n the Itatement 18 to be found by TODAI and replaced with another .pecified" .tring. At the structural level (where the user wiShes to man1~ulate Itatement. and set. of statements as units), NtS permiilthe u.er to identity .tatements bY pOinting with the mou.e) TODA! requires that statementa be identified from the keyboard. Con.iderable tlex1bilit~ i. provided in th1. operation. Tbe u.er may identity a statemen~ directly bY typing it • • tatement number or its name; he may alao i~entifY it indirectlY b~ .pecifying its structural relation'hip to lome other statement whose number or name he knows ofl·han~. Indirect .pecification correspond. to the use ot NLS commands .uch AI "jump to head," "jump to lucce •• or," etc., but w1th ~he added feature that relation. hip. may be concatenated _. thus the user may, in a linl1e operation, .pecit¥ a complex relationShip such as the succelsor of the first SUb8t&~ement of the predece.sor of & liven .tatement. A .pec1al TODAS capability (not yet implemented in NtS) 1. "execu~able text." A TODAS .tatement may con.1at ot the .tring of characters that a user would type from the keyboar~ to 18S AppenClx A NLS/TODAS USIR FEATURES perform lome •• quence of opera~ion8. Thll .~atemen~ may then be execute~ w1th a Ipecial comman~,&nd the re.ult will be .xaetl~ a. if the user had actually typed these characterl, cau81n'the .e~uence to be carried out. The lequence m&Y#in principle, be arbitrari1r CO~PlexJ an executable .tatement micht, tor example, contain the tol1ow1nc .equence. (1) Load a fl1e who.e name 11 .pecified ellewhere in the current file (2) SearCh thl. lile with the content analyzer, fin~1nl content It&~ementl with a specified pattern ot (3) Write the.e statementl out in , temporary "bufter" tile (4) Reload the original file (5) COpy the .tatement. lnthe "buffer" tile into a Ipecified location in the workin, tl1e. A Ipeclal. "lw1tch" character may be uled 1n the executable text. When the Iwitch character 1. encountered, execution at the text i l interrupted and control revert. to the keYboard. The uler then enter. part of the control .equence manually) when be type. tbe Iwitch character' from the ke~board, execution otthe executable Itatoment resumes at ~he polnt where it left otf. This fe&~ur. alfords creat flexibility, sine. it allows·part ot the sequence to be ,~ecitied ahead 01 time and ~art at "execution tlme." ·8e.idel it,primary purpo.e a. a Ne\work u'er'. in~ert&ce to t~e NIe, TODAS 1. u.ed w1th1n ARC a. a .upplemental tool' to Nt8. TODAS can be u.ed conveniently tor many talkl that ~o not require the rapid dilplay response ot Nt!, and haathe advantale 01 creatina Illnlf1cantly lei. load on the overall. tlae.har1nl .,a~em. We currently have one clerical worker, who i. not an Nt! u.er, operating TODAS routinelY tor entry ot information anc for lome limite~ retrieval work. 186 Appendix A NLS/TODAS USER rEATURES Additionally, we tind TODAS u.eful tor remote acce •• lnl ot our 'Vltem. We have made TODAS available to .elected con.ultan~., who use bome terminal- witb acou.tlc couplers, and regular ARO per.onnel occasionallY do work from their home. bf \he .ame means. The prototfpe ver.ionof TODAI went in~o service 1n September 1969) a .econd ver.ion, wlth creatlf expande~ capabil1tle., became operational early ln 1970. III Output Facility and TODAS both Ule the same facilities for producing formatted hard-copy output from NLS/TODAS tile •• NL! The devices in orOinary u.e at ARC for hard-copy output are a 11ne printer that prOduces upper/lower-caae ~rlnt ot adequate quality for local us., and apaper-tape-driven automatic typewriter u.ed for tinal output of reproducible copy tor report., propo.als, etc. The output processor (previou.ly known a. "PASS4") can be controlled bf the u.er to a conSiderable extent. This 1. done bY mean. of "directlves" embedded 1n the tile text. The directives can be used to re.et page parameters, eon~rol pale numberinl, anoturn varlou. format t.a~ure. "on" or "oft." For eXample, directive. can be used to luppre.sinoentation ot .tatements or Chanle the amount ot indentation, to create -running header." ~h&t are automatically printeO at the t~p of each pace, .upprea. at&tement number., etc. one of thedirectlvel cau.e. all directive. to be .upprel.ed trom the output. In addition to the l1ne printer and the automatic typewriter, the output Procel.or can output a file to malnetic tape, appropriately formatted to drive CRT-te-film conver.ion equipment for prOduction ot microfilm. In all ealel, the user may elect to output an entire tile or only part 01 the tile. In the latter cale, he may cau.e output to belln at scme .pecified point in the file in.tead ot at the beclnning,and be may caule the printout to be limited by the same kind I ot criteria that may be used on the display -- 1.e., content analY8il, limited number ot structural level., etc. 187 Appendix A NLI/TODAS' USER FEATURES Gl0 •• ar, of IV S~eclal NLS/TODAS Term1nolol' BRANCHI A .pecified .tatement, plU. all ot 1~. sUb.'ruc~ure •• 1 •• ~ all 011'. IUb.t,tement., plu. all 01 their ,ub.ta~em.nt., etc. BRANCH ONLY, A VIEWSPICparameter that re.trict. the text dl'Pla,ed (Nt') or tfped (TODAS)to a .inCle branch (•• e VIIWSPICS). BUG. The cur.or mark on ·the .creen that 1. moved bY the mou.e an4 that 1s Uled for lelectin, (polntlng to) ent1t1.1 on the 41'Pla,. When the bUI 1. "active,ui.e., when a .electlon can be made, lt appear. a.an up-arrowJ When i\ 1. inactive· 1\ appears a. a plu. 111n. OHARACTBR: Any letter, d111t, punctuation clrriale returnJ an indivilible entity. mark~ 'pace, tab, or CHORD. A combination of .key. on the key.et (.ee· XIYSET). Ct%PPINGI See LEVEt CLIPPING. INDIThe lalt Itat.ment 1n any branch, .pecified bY .pecityin. the branch. rILl. A complete tree Itructure of Itatement. witb a .lnl1e . root (the orlein Ita\ement). rILINAMEITh. name of a fil~. I\ appear. I . 'he tir.' word in the orlein .tatement 01 an exi.'~nl tl1e, andmu.t· be lupplied bY: the u.er in crea'1nl a new tile. GAP CHARACTER. Any .p&ce~ tab, orcarrlace return. GOHARI Abbrev1atlonfor GAP CHARACTER. GROUP. A IUb.et at a plex, con.i.tine Of all, branche. from one .pecitied branch \0 anotber, inclulive, HIADaThe fir.t .tatement in a .ubli.t. Tbe head 1. specified bY pointing to any .tatement in the IUbli.t. 188 Appendix A NtS/TODAS USER FEATURES INVISIBLE: Any consecu~1ve strine of lap Ch&rac~er •• bounded bY (but not 1neludine) print1nl charac~erl or the en~ of a .tatemen~: see PRINTING CHARACTER, GAP CHARAOTER, STATEMENT. Specified by pOinting to any character in the ,trine. If & 11nll. pr1nt1nc character lyin« between two invisible. is pointed to, both invisible, (and the print1nl character) are selected. KEYSET: The ~evice at the left-hand side Of the NtS con.ole. When a combination ot keys (a chora) 1. depre8se~ on the key.et, the eftect i. the same a. striking a key on the keyboar~. KEYWORD. The name of a "keyword .~atem.nt." KEYWORD STATEMENT. A .tatement that 11ltl, in a Ipecial format, the names of all statements 1n the lame file that fall 1nto lome arbitrary catecory. The "keyword system" of NLS/TODA! commandS, o~eratlnc upon keyword statement., pertorm. information-retrieval operation. baled on the set. of atatements defined in keyword .tatement •• LABELl A Itring of text placed in a picture command in the vector package. by means of & tEVADJ. The .pecitication ot level when a statement, branch, plex, or group 11 newly created or moved. tEVEtl The "rank" ot a .~atement (see STATEMENT) in the hierarchy Of the file (lee FILE). The level i. equal to the number ot field. of letter I or dicit. in the statement numberJ thu. statement 3 11 a firat-level statement, Statement 4&1013 i. a fifth-level statement, etc. tevel is of great importance in understanding the hierarchical structure ot an Nt! f11e. tEVEL CLIPPING. Restrictinl the text displayed (Nt') or printed (TODAS) to statements no deeper thin a .pacified level, which 1. set by & VIEWSPEC parameter (aee VIEWSPECS). tINE TRUNCATION. Reltriet1nl the amount of text di.played (NtS) or printed (TODAS) to the lir.~ N 11ne. of e&eh .tatement, where N i . apecit1e~ by aettinc a VIIWSPEC 189 Appendix A ILS/TODAS USIR fiATURI8 parame~er C.e.' VIIWSPECS). Each .~atem.ntt. formatted into l1ne. upon. output tOf'he di.pla, or printinl ~eviceJ thu. the amount ol.tex~ in a line depend. upon ~he device and upon other p&r&me'er.~ LINK. A .pec1&11Y_format\~d 'trinl 01 text 1n & .~atemen\~ analolou. ·to & reterence or crol.-reference c1t&\10n 1n a conventional document. A link ,pecif1e., u.er, & tile belonc1nl to \h,t u.er, & location 1n ·the fllt, and VIEWSPICS. A. u.er may "follow" a link by means ot 'he Jump to Link command (NtS) or In indirect addrel' CTODAS). In either ca •• , the Iystam detects the l1nk, interpret. it, laid,' the .pecified !11e, and di.play. or print. the .pecified portion ot 1t with ~he .pecitied V%EWSPECp&rameterl. MOUSEl The device at the right-hand .1de ot the NLS keYboard. When 1t :1. rolled around on the~abl.t~~, i\ cau.e. the bu, Ccurlor mark) to move corre.pond1nllY on the 'creen. HAMil It the fir.t word at a .tatement i . enolo.ed in par,n\be.e., it 1. \he NAMB ot the ,tatement. The command Jumpta Name can then be u.ed to pllce ~h • • ~&~ement &~the ~op ai the ~1'Play. Th1. 1. ~one by en'.rinl ·'he name trom .'he ~eYbo&rd or ke,.e~, or bY flndinl an ,occurrlnce ot ·~h.nam •. a. ~.xt on ~b" d1.p1&y andpolnt1nl ~o 1~ w~~h tbe bUI. HtS.AcrOnym.tor "On-t1ne S,.tem.- . ORIGINlthe.':!.r.t, .tatellent 1n a t1l-J it, cont.ain. intormat1on IbOUt.~hltl11, plU. any o~her ~.xt. tbe u.er1n.er\.. l~ ha. I level 01 0, and hence ·no .t&~ement number. OUtPUT PROCISSORI lor.&tt..dou~put. Prolr&mu.e~ b, NtS and TO~A8fol' produclnl 'AISal Alt.ernat,e nameu.ed far the output 'roce •• or. PATTIINI A .trin, of Ipecial-lan,ua,e'ext in a .t&tement that m.v ~., compiled vta ·'be command Ixecu~e Content Analyser. Whln 00.,11Id, 1t prOduce. a pro,ram that 11 u.ed bY t.he content,-analv.er tla\ure. 1'0 Appendix A NLS/TODAS USER FEATURES peHARI Abbreviation for PRINTING CHARACTER. PLEXI Another name for a SUBSTRUOTURE, used in command specifieations. A plex is specified by pointing to anyone of ita hilhe.t-level statement •• POINTBR. A strine of up to three characters that i. attached to some Character in the' text with the Pointer Fix command. PREDECESSOR, The statement preceding & specified statement 1n a SUBLIST. PRINTING CHARACTER. Any letter, dicit, or punctuation mark. SOURCE: The statement of which a specified statement1s a suDstatement. SIGNATURE: Information stored with a statement (anO displayed on command) civin~ the initials of the user who created the statement (or most recentlY modified it) and the time and date When this occurred. STATEMENT: The basic structural unit of a file of text 1n NtS. Formally, it i . a .trine of text and/or pictures that i. bounded at the beginning bY the end of the previous statement or the beCinning of the file, and bounded at the end bY the beginning Of another .tatement or the end of the file. Statements are arranged 1n a tree structure or hierarchy and are a.signed "statement numbers" in~icating their pOlitionsin the .tructure. Each .tatement has a number. made up of alternating fields of digits &n~ letters; the number Of field. indicates the "level M ot the s~ateMent (lee LEVEL). A statement is specified by pOintinc to any character in the strine. SUltIST. The let 01 all lubltatementl of a specified statement (not inclUding the sUbstatementl ot the IUbstatementl). 8UBSTATEMENTI A Itatement "X" is called a .ubltatement of another .tatement fly" it it 1. ~eeper 1nthe structure than "Y," if it follows "Y," and if there i . no lnterven~nl hl.ber-or4er 8tatement. ny" il calle4 the .ouret of "X." The 191 Appendix A NL8/TODAS USER FEAT ORiS .tltemen' number of "X" will be the .ame a. tba\ ~~ My" exeept that 1t will have one more field at the end. The value of thil field live. 1t, ordinal pOliticn in a "'Ublilt" of the .ublt&tement. of "Y." A ,ub.tatement i. specified bY pointing to the .ource .tatement. SUBSTRUCTURE I The .et of all SUb.tatement. ot a .pecified .tat,ment, plu. all their IUbltatement., etc. until no more are found. The let of all branche. detined by .tatementa in 'he IUbll.t 0: a given atatement. SUCCESSOR: The .tatement fOllowing a specified .tatement in a IUbli.t. TAlt: The la.t Itatement in a IUblist. The ta11 11 specified by pointing to any Itatement in the .ublilt. TEXT: Any string of characters within a statement, bounded by (and includ1nl) two .pec1tled characters: lee CHARACTER, STATEMENT. TODAS. ACronym Sy.tem. to~ T~pewriter·orlented Documen'a~ion·Ald TRUNCATION: See LINE TRUNCATION. VBCTOR: A 11ne in a picture. VIEWSPEOI: V1ew-control parameter. controlllni & number Cf .peeial NtS 1eaturea attectlngthe diSPlay format. See, tor example, BRANCH ONLY, ,LEVEL CLIPPING, and LINE TRUNCATION. VISIBLla Any con.ecu~lv. strinl ot prln~lnl charae'era, bounded by (but notlncludinl) liP character. or the en4 ot a .tatement: see PRINTING OHARAOTER, GAP CHARAOTER, STATEMENT. Specified by poln~lnl to any character in the_.~rinl. Ifa ain,l. lap character 'between two v1.1bles i. pointed t~, then both visible. (and the lap charaeter1 are .pecif1ed. WORD. Any con •• cutlve strine ot letter. andlor d111tl, bounded by (but not 1ncludinl) any other type I ot characters or the end of a Itatementl lee STATEMENT. 192 A NLS/TODAS USIR FEATURES App.n~1x Specified by pointing to any charae~er in the 'irine. If a .inCl. character 11 pOinted to that 18 not a leiter or dil1t and liel between two worda, then both worde (and the '1nlle character) are specified. 193 BIBLIOGRAPHY rhe following 1. a ehronoloc1aal lilt of the Aucmentation Rele,reh Oenter. ~ocumentl ~ublishe~ by 'I D. c. Engelbart, "Special Con.1~er&tion. ot the IndivlCual a U.er, Generator, an~ Retriever ot Information," Paper presented at Annual Meeting ot American Documentation In.titute, Berkeley, California (23-27 october 1960), 1. 2. D. O. Ence1bart, "Aucmentinc Human Intellect. A Oonceptual 'ramework," Summary Report, Oontract AF 49(6)8)-1024, SRI Project 3578, Stanford Re.earCh Institute, Menlo park, California (October 1962), AD 289 565. 3. D. O. !ngelbart, "A Conceptual Framework for the lucmentatlonot Man'l Intellect," in Vi.tas in Information Kandling, Volume 1,0. W. Howerton and D. C. Weeks, edl., spartan Books, washington, D.C. (1963). ~. D. C. Engelbart, "Augmenting Human Intellect: Ex~er1mentl, Concepti, and POSSibilities," Summary Report, Contract AF 49(638)-1024, SRI Project 3578, Stanford ResearCh Institute, Menlo Park, Caliterni, (MarCh 1965), AD 640 989. 5. D. C. Engelbart and B. Huddart, "Relearch on Computer-Aucmented Information Manacement," Technical Re~ort ESD-TDR-6S-l68, Oontract Al 19(628)-4088, Stanford Relearch Inat1tute, Menlo Par~, California (March 1965), AD 622 S20. 6. W. K. Enclish, D. C. Enlelbart. and B. HUddart, "Computer-Aided Display ContrOl," F1nal Report, Co"tract NASl-l988, SRI Project 5061, Stanford Research Institute, Menlo Park, California (July 1965), eFSTI Order No. N'6-1020k.* w. K. English, D. C. Encelbart, and M. t. Berm&n~ "DiSPlay-Selection Techniques for Text Manipulation," IEEE Trani. on Human Factors in Electronics, Vol. HFE-B, NO.1, PP. 5-15 (March 1967). 7. 8. D. C. Engelb&rt, W. K. inllilh, and J. r. RUllf.on. "Study For The Development of Human Intellect Aucmentat10n TechniqUes," Interim Procrel. Report, Contract NAS1-S904, SRI project 5890, Stanford. Relearch Institute, Menlo Park, California (MarCh 1967). 9. J. D. Hopper and t. P. Deut.ch, "COPEI An A•• embl,r and On-Line-CRT Debulling Sfstem tor the CDC 3100," Technical Repor' 1, Oontract NAB 1-5904, SRI project 5890, Stanford Re.earch Institute, Menlo Park, California (March 1968). 195 BIBLIOGRAPHY 10. R. I. Hay and J. r. Rullflon, "Mot940: A M&chlne·Or1ente~ ALGOL-Like tancuace tor the SDS 940," Technical Report 2, Con~r,et NAS 1-5904, SRI Project 5890, Stanford Research Inltitute, Menlo Park, California (April 1968). 11. D. C. Engelbart, W. K. English, and J. F. Rulifson, uDevelopment ot a Mu1tidilplay, Time-Shared Computer facility and Computer-AUcm&nted Manacement-System Re.earch," Final Report, Contract AF 30(602)4103, SRI Project 5919, stanford Research Institute, Menlo Park, California (April 1968), AD 843 577. 12. D. C. Ence1bart, "Human Intellect AUlmentat1~n Technique.," Final Report, Oontract NAS 1-5904, SRI Project 5890, Stanford Research Inltitute, Menlo park, Oalifornia (JulY 1968), CrSTI Order No. N69-16140.* 13. D. O. Engelbart, W. K. Englilh, and D. A. Evanl, "Study tor the Development ot computer-Augmented Management Technique.," QuarterlY progresl Report 1, oontract 130602-68-0-0286, SRI Project 7101, 'Stanford Research Institute, Menlo Park, Oalifornia (October 1968). 14. D. C. Engelbart an~ W. K. English, "A Relearch Oenter for Augmenting Human Intellect," in AlIPS proceedingl, Vol. 33, Part One, 1968 Fall Joint computer Conference, Pp. 395-410 (Thom~8on Book Co., Washinlton, D.C., 1968). lS. D. O. Engelbart and Statf ot the Augmentea Human Intellect Research center, "StUdY tor the Development ot Human Intellect Augmentation Techniques," Semiannual TeChnical tetter Report 1, Contract NAS 1-7897, SRI Project 7079, Stanfora Relearch Institute, Menlo park, Oalifornia (February 1969). 16. D. C. Ingelbart, W. K. Inlli.h, and D. A. Evanl, "Stuay tor the Development ot Computer Augmented Manalement Technique.," Interim Technical Repor~ RADC-TR-69-98, Contract r30602-68-0-0286, SRI project 7101, Stanford Re.earch Institute, Menlo Park, California (MarCh 1969), AD ass S79. 17. D. C. Engelbart and Staff of the Augmented Human In~el1ect Reeearch Center, "Stu~y tor the Development ot Human Intellect Augmentation TeChniquel," Semiannual TeChnical tetter Report 2, Oontract NAS 1·'897~ SRI Project 7079, St&nfor~ Research Institute, Menlo Park, Oalifornia (August 1969). 196 BIBLIOGRAPHY 18. 'D. C. Incelbart and Staff of the AUgmented Human Intellect Research Center, "Computer-Aulmented Manacement-sYltem Re.earch and Develo~ment of Augmentation Facility," Final Report RADC-TR-70-82, Contract 130602-68-C-0286, SRI project 7101, Stanford Re.earch Institute, Menlo Park, California (April 1970). *Note. Report. with AD numbers are available from Defense Documentation Center, Building S, Cameron. Station, Alexandria, Virl1nia 223lk. Item. marked with an asteriSk may be obtained from erSTI, S111s Building, 5825 port Royal Road, Springfield, virginia 22151) cost '3.00 per copy or 6S cents for microfilm. The following i. a li.t of other doeument. cited in this report. The items are listed in the order in whicb they are cited~ 19. "Specification. for the Interconnection ot a HOlt and an IMP," Report No. 1622, Contract NO. DAHC15-69-0-0179, ARPA Order No. 1260, Bolt Beranek And Newman Inc., Cambridge, Malsachulett. (May 1969). 20. L. Roberts, "Computer Network Development to Achieve Sharing," .paper pre.ented at 1970 Spring Joint Oomputer conterence, Atlantic Oi\" New Jerley' (May 1970); ArIPS conterence Proceeding., Vol. 36, ~. S43 (AFIPS Pres., Montvale, New Jerley, 1~70). R~louree 21. F. Heart et al., "The Interface Me.sace Proces.or for the ARPA Computer Network," paper pre.ented a\ 1970 Sprinc Join~ Computer Conferenc" Atlantic City, New Jer.ey (May 1970). ArIPS Conference Procee4inCI, Vol. 36, p. 551 (ArIPS Pre •• , Montvale, New Jerley, 1970), 22. L. Kle1nrock. "Analytic and Simulation MethOds in Computer Network Desiln,n paper pre.ented at 1970 aprin, Joint Computer Conference, Atlantic Cit" New Jerley (May 1970), ArIPS Conterence procee4incs, Vol. 36, P. 569 (ArIPS Presl, Montvale, New Jerley, 1970). 23. H. Frank, I. rri.ch, an~ W. Chou, "Topological ConSiderations in the Delien of the ARPA Computer Network," paper presented at 1970 Sprinl Joint Computer Conference, Atlantic City, New Jersey (May 1970)J AFIPS Conference proceedingl, Vol. 36, p, S81 (ArIPS Prell, Montvale, New Jersey, 1970). 197 BIBLIOGRAPHY 24. S. Oarr, S. Crocker, and V. Cert, "HOST-HOST Communica~1on Pro~ocol 1n the ARPA Ne\work," paperpre.ented at 1970 Sprlnl Joint Com~u\er Conterence, Atlantic 0ity, New Jersey (May 1970)J ArIPS Conference proeeedine', Vol. 36, p. 589 (ArIPS Prea., Mon~v&le, New Jer.er, 1~70). 1~8 UNCLASSIFIED Sf'cllritv Classification DOCUMENT CONTROL DATA· R&D rSt'('urity cla:,;sification 01 title, body 01 abstract illIJ illd ... xill~! annotation must bt' ~lItl'rt'd 1. ORIGINATING ACTIVITY (Corporate author) II", UVt'r.,lI rt'fJdrt i., clil,.,Uieu) CLASSIf-I<:A110r·. Unclassified Stanford Research Institute Menlo Park, California 3. REPORT 1"""" 2D, REF'ORT SECURITY TITLE Advanced Intellect-Augmentation Techniques 4. DESCRIPTIVE NOTES (Type 01 report and inclusive dates) Final Renort 5· AU THOR(S) (First name, middle initial, last name) D. C. Engelbart and Staff of ~ugmentation 6· REPORT DATE 7a. TOTAL NO. OF PAGES OF REFS 212 July 1970 8 •. Research Center CON TRAC T OR GRAN T NO. 9a. ORIGINATOR'S REPORT NUMBER(S) SRI Project 7079 NASl-7897 b. PROJECT NO. c. 9b. OTHER REPORT NOIS) (AllY other number:,; tpat nw. /).' t1.>sIRned this report) d, 10. DISTRIBUTION STATEMENT 11 SUPPLEMENTARY NOTES 12. SPONSO.RING ~ILITARY ACTIVIT, National Aeronautics and Space Administratipr Langley Research Center Langley Station, Mail Stop 126 Hampton. Virginia 23365 13. "SSTRACT This report covers a two-year project, at the eleventh year of a growing, multiproject program that is exploring the value of computer aids to augmenting human intellectual capabi Ii ty. OUtlined briefly are the background and the "bootstrapping" nature of the program, its resources, and the activities it has undertaken in pursuit of its goals. Advances made during the project were: (1) Making operational an experimental interactive laboratory comprising an XDS-940 computer, special interface and display hardware, a modified UCB-GENIE timesharing system, six NLS consoles and sixteen typewriter terminals, a 96-megabyte file-storage disk, and a 96-character line printer (2) Making extensive progress in the development of special-purpose languages and software architecture to provide for both highly interactive service and flexible system evolution (3) Moving our team of system developers into an on-line working mode, and beginning to learn how to adapt to this environment--with encouraging success, as represented by our emerging "software-engineering" methodology (PAGE 1) SIN 0101.807.6801 UNCLASSIFIED Security Classification Continuation of DD Form 1473, Abstract, Item 13 (4) Establishing a plan, and partially implementing the basic services, for an information center to serve the experimental ARPA Network. User experience in applying our augmentation tools and techniques to various normal working tasks within our Center is described so as to convey a subjective impression of what it is like to work in an augmented environment. It is concluded that working-support, computer-aid systems for augmenting individuals and teams, of the general sort we have been experimenting with, are undoubtedly going to be widely developed and used. A very special role in this development is seen for multi-access computer networks: they will become special marketplaces where a new kind of competitive evolution will take place, not only in hardware, software, and special services as "bought" from a "utility," but also in roles, skills, working methods, and employment dynamics for the intellectual workers at the terminals. Security Classification 14 L...INK B L...INK A KEY ROL...E WT ROL...E WT Intellect Augmentation Man-Machine Communication On-Line Interaction ARPA Network Network Infonnation Center On-Line System NLS TODAS Documentation Text Manipulation Computer Displays DD lFNOoR~.. 1473 (P AG~ 2) L...INK C WORDS (BACK) Security Classification ROL...E WT
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37 Create Date : 2011:06:22 11:35:08-08:00 Modify Date : 2011:06:22 11:46:38-07:00 Metadata Date : 2011:06:22 11:46:38-07:00 Producer : Adobe Acrobat 9.43 Paper Capture Plug-in Format : application/pdf Document ID : uuid:68cb08e3-f884-4c32-87d0-17ed40a37bb9 Instance ID : uuid:f8740d3e-d963-4256-96b7-31a82f02cdde Page Layout : SinglePage Page Mode : UseNone Page Count : 204EXIF Metadata provided by EXIF.tools