issues and strategies for online documentation

IEEE TRANSACTIONS ON PROFESSIONAL COMMUNICATION t VOL. PC 30 t NO. 4 t DECEMBER 1987

Communication Issues in Software Engineering

Issues and Strategies for Online Docum~ntation

JANET H. WALKER

235

Abstract-As computers move onto the desks of all kinds of workers, and into all aspects of the work we do, online documentationbecomes increasingly important. Documentation for a computer system or program contains the information that a user needs to knowin order to operate the system or program. Online documentationrefers to the effort to deliver some or all of that documentation usingthe same computer system that the user is learning about. This papersurveys many of the issues involved in designing online documentation: choosing a goal for online documentation, understanding theconstraints on a design, and understanding the implications of a design for writers and users, mostly from the perspective of a designeror project planner concerned with issues in both software development and document development.

GOALS FOR ONLINE DOCUMENTATION

THE first step in designing an online documentationsystem is to determine what problem you are trying to

solve. The possible goals cover a wide range, from vagueto ambitious:

• Just to make the system "more friendly." This is primarily a marketing statement of the goal; you need further work to determine what it means to any particularproduct.

• To fill the customers' information void at minimumcost. The costs under discussion are on the vendor side(the manpower for producing the information; the costof printing it) and on the customer side (the system anddisk storage requirements for accessing it).

• To tell users about recovering from errors. This is atechnical goal with possibly limited application; it focuses on user errors.

• To put "the manual" on line. This is an ambitious goalwith many technical ramifications in the area of software, particularly the user interface for the person reading the manual.

• To provide an integrated range of information services:summary, tutorial, reference, glossary, release notes,

Janet Walker received training as a cognitive psychologist at the University of Illinois, and also did postdoctoral work at Stanford University.Shortly after its founding, she joined the software R&D group of Symbolics, Inc., where she led the project to develop Document Examiner(Symbolics' online delivery system for documentation). (Document Examiner received a Distinguished Technical Communication award fromthe Society for Technical Communication.) At present, she serves in aresearch staff capacity at Symbolics, studying emerging software application areas.

and news items. The most ambitious approach of all,this requires serious research into users' needs for bothinformation and a good interface for reading it.

Behind each of these goals is the most general goal ofmaking information available to users when they need it[1]. From there, a wide variety of approaches is possible.

TOP-LEVEL DESIGN ISSUES

The design issues for online documentation fall into anumber of areas:

• Deciding what level of service to provide• Deciding what level of integration to strive for• Living with hardware constraints• Surviving software constraints• Understanding user constraints

Some research has indicated that people reading onlinedocumentation work more slowly and learn less effectively[2, 3]. The results of such research must be regarded asvery preliminary at this point for several reasons. The research needs to look at online documentation as it couldbe, not as it currently is. In particular, the results couldwell be different for documentation delivered with a flexible user interface, in readable fonts, on high-resolution,black letters on white background screens [4, 5].

Even with good technological support, the work necessaryto produce printed books is a major resource drain for adocumentation department. Customers, marketing, andtraining still demand printed documentation, however; atthis point in the development of the computer industry itisn't yet feasible to stop producing printed documentationproducts altogether. In the next few years, with improvements in design and interfaces, online delivery of documents could become competitive with paper delivery.Level of ServiceOne set of design choices concerns what level of service toprovide to your users. Do you want the whole documentset on line or will you provide simple error recovery service? Will users be able to initiate requests for information?How will users find information of interest to them? Howdoes all this affect your project?

In the area commonly known as online help, the emphasisis primarily on recovering from errors. Typically the useris assumed to have entered an erroneous command line and

0361-1434/87/1200-0235$01.00 © 1987 IEEE

236 IEEE TRANSACTIONS ON PROFESSIONAL COMMUNICATION, VOL. PC 30, NO.4, DECEMBER 1987

to need help with determining why the command arguments were not accepted by the system. The general orientation of such help is toward fast fixes to syntactic problems. At the other end of the same dimension, you wouldfind an online encyclopedia [6, 7]. The goal would be information retrieval, with no necessity that what users arelooking for has anything to do with their current workingenvironment or even with computers at all.

Online help and online documentation are really on a continuum of information delivery systems [8]. They differprimarily in emphasis. Help systems are oriented towarderrors and context-sensitive aids; documentation systemsare oriented toward information finding (searching andbrowsing).

The more modest your goal here, the easier the answers tothe rest of the design issues. Unfortunately for designers,the user community is outgrowing low-service solutions tothe need for information.

Integration QuestionsOnline documentation is not an end in itself. Documentation is always "about" something. In an online system,the documentation resides on the very machine that theuser is trying to learn about. Not surprisingly, you have tomake important decisions about how to integrate the onlinedocumentation with the rest of the system [9].

Relationship Between Paper and Online Documentation-One important integration issue to consider is therelationship between the online documentation and theprinted documentation. Some documentation departmentshave set a goal of complete online document delivery (nomore paper manuals), to increase flexibility and decreasecosts. This decision solves the integration question veryeasily!

Other solutions are possible. Projects under way at variouslarge computer companies include the following:

• Feasibility studies of delivering all documentation online and a small subset, consisting of installation and error diagnostic material, as paper documents

• Feasibility studies of delivering all documentation onlineand a small subset, consisting of installation and errordiagnostic material, as paper documents

• One experience where a manual was delivered on lineonly, with no printed version and no facility for makinga hard copy. This was not entirely intentional on thepart of the vendor, and the users were very vocally upset for a while. However, within the year before thenext release, most had adjusted to using the manual online. When the facility for making a hard copy did become available, only the training department and a fewcustomers used it.

• One experience where complete documentation was delivered both on line and on paper. An informal surveyfound that a number of system software developers hadnot taken the paper document sets out of the box, butthey did use the online documentation.

Assume for the moment that documents are to be deliveredboth on paper and on line. What are the possible relationships between paper and online information?

• Independent. The paper and online documentation areseparately created and maintained. The online documentation is usually done after the paper documentation. Ittends to be shorter than the paper version, either because it covers fewer topics or because it covers all topics more concisely.

The independent approach entails high costs, since twodifferent versions are prepared. It also has high costsfrom the readers' point of view in terms of inconsistentterminology and coverage between paper and screen information.

• Page facsimile. The online documentation displays actual pages from the printed documentation. This approach is good from the writers' point of view: theywork on the paper manual only and the online versioncomes along "for free." From the readers' point ofview, these systems often have serious readability andcommunication problems.

• Shared source or data base. The online and printeddocumentation are produced from the same source information. The material is organized with the needs ofboth kinds of delivery in mind. This approach benefitsboth writer and reader. The online information and theprinted document are identical in structure and contentbut differ in details of appearance. For writers, this approach requires roughly the same amount of work aswriting for paper delivery alone. Readers can choosepaper or online depending on their preferences or task,confident that they will be able to find and read allavailable information in either form.

Relationship of Help and Other Software-One fundamental design decision involves integration between onlinehelp and the rest of the system software. The choice madehere influences many subsequent decisions about datastructures, interaction styIe, and resources. Several possibilities are common (help command and context-sensitivehelp) and one is clearly desirable (integrated help).

• A help command. In this style, the least demandingfrom an implementation point of view, asking for help isan operating-system-Ievel command [10]. In many implementations of this, the command takes arguments thatspecify and refine what it is that you are asking for help

WALKER: ONLINE DOCUMENTATION

about and what kind of help you are asking to see. Forexample, the following command requests help with theparameters to the ASSIGN command.

$ HELP ASSIGN PARAMETERS

• Context-sensitive help. In this style, you can requestinformation about current command arguments when youare typing a command to the operating system or someapplication [11, 12]. Usually this is syntactic help andtakes the form of a list of the possible ways of continuing to type. For example:

Command: Show Directory(files [default Q:)jwalker)papers) *. * .newest]) HELP

Pathname: whose directory to showType of input expected: the pathnames of one or more filesUse c-? or c-I for a list of possibilities.

• An integrated help utility. A help utility manages alldocumentation requests, whether directly from users orvia application programs. When users need to refer tosomething, they can interact with a separate help application that assists in finding information and managestheir interaction with it. In addition, all application programs can offer context-sensitive help by calling thehelp utility's internal program interface [13].

In this kind of system, users benefit by not losing thecontext of what they are doing when they are using thehelp utility. The application program and the help utilitycan both offer the same text.

CONSTRAINTS

The designer of an online documentation system choosesboth the kind of capability and the style of user interactionto offer. These choices are not made in a vacuum; they areconstrained by many uncontrollable real-world factors, likebudget, schedules, and compatibility. It is instructive,however, to be explicitly aware of the development constraints imposed by hardware and software aspects of aproduct. In this way, the designer can question and sometimes change constraints that would otherwise limit thedesign.

Hardware ConstraintsThe real world of hardware places some hard limits on theimagination:

• Terminal. The terminal is the most seriously constraining factor in most designs. Some common terminal contraints:

-Screen size is typically limited to 24 lines of 40 or 80characters.

-Few function keys are available and none are reservedspecifically for documentation uses.

237

-One fixed-width character font is available, sometimeswith the capability for highlighting areas of text.

-Redisplaying the whole screen can take from 1.5 to 10seconds.

Some companies find they must remain compatible withvery old terminal products that are incapable even ofaddressing a particular character on the screen. Theyshould seriously consider not designing online documentation for lowest-common-denominator hardware. Optimizing the design for more modern hardware will aidsignificantly more customers. For the inadequate hardware, then, the decision is either to not offer the documentation online at all or to offer only the very simplestaspects of it.Large-screen bitmap terminals are the delivery hardwareof choice for online documentation. It is possible, however, to design good online documentation systems withconvenient controls and flexibility in spite of constraintsimposed by the terminal. For example, arrow keys ortabbing keys can be used for positioning on a help menuor on a highlighted item of interest [14, 15].

• Memory space. On machines with no virtual memory orwith otherwise limited memory, you need to designaround the limitation, for example:

-Keep the size of your help system very small so that itall fits in memory along with the other applicationsthat need to run.

-Design the system so that part of it is in memory atany time and the rest is available from the disk asneeded. This is a difficult solution, especially for systems lacking virtual memory, but is ultimately moreflexible if your help system might need to grow.

• Disks. Keeping information on disk instead of entirelyin memory is practical only when disk speeds are fastenough to ensure adequate performance. Particularly forsmall machines, the issue of disk storage resources is

. very important. People are not surprisingly reluctant todevote a major proportion of their disk space to the filesfor a help system. Address this by designing the mostcompact file format possible, for example:

-Some kind of binary precompiled representation of thetext for use by a display program is more compactthan a fully formatted word processor file. (Keep inmind that a 250-page book, small by computer systemmanual standards, might require 1 megabyte of storage if kept in word-processor format.)

-If processor cycles are not at a premium, you couldconsider some scheme like run-length encoding tocompress the files and reduce the file storage burden.


The disk storage aspect of online documentation is anextremely important one. Companies that are seriousabout online documentation must be prepared to ensurethat the disks available on the products are adequate inboth size and performance.

Software ConstraintsDesign of the interaction styIe for an online documentationsystem is limited by the complexity of surrounding systemsoftware. In what system context does the help applicationlie? A full function help utility with intricately crafted controls is inappropriate for a menu-driven word processorwith nine commands; a series of file-based help screens isequally inappropriate for an expert's operating system witha fully programmable macro command language.

Designing an online documentation system is far easier andproduces better results if the software environment inwhich it will run has the following facilities:

• Windowing. Operating systems with window managercapability accommodate a documentation viewing window and the application side by side, or alternate use ofthese windows.

• Multiprocessing. For online documentation, it is particularly important for the user to be able to have a numberof applications running at the same time. Because documentation is usually about what users are doing, theyneed to switch between documentation and the primaryapplication without losing their working context in eithercase.

• Networking. Some online documentation systems address the disk space problem with a server approach. Allthe computers involved are on a network and one machine with large disks is designated as the server fordocumentation. The documentation files reside there; theonline documentation system retrieves them transparently as needed.

• Data management. Some form of data base substratesoftware makes the design of online documentation, thedelivery interfaces in particular, much easier by providing some level of content addressability.

It is best if the help system can be designed as part of theoverall software product. This is the best way to ensure aconceptual fit. However, this opportunity is rare; usuallythe best that can be done is to attempt afterwards to blendthe help system into its environment. For example, itshould use the same kind of command structure, the samestyle of command naming, and the same conventions foroptions or customizing.

User/Audience/Market ConstraintsIn designing interaction style, user sophistication is an important determining factor. A sophisticated audience appre-

ciates an online documentation system that can find answers to complex queries or display detailed internalsinformation on request. For computer neophytes, the ideaof getting information from the machine itself is a newone.

If new users are the target audience for the help facility,the goal is to make it easy for them to find answers to easyquestions. For example, the first question of anyone seeinga help application for the first time is likely to be, "Howdo I use this?" The initial display of the application couldinclude a command summary and instructions on where tolook to learn more.

Since most systems must support users with a broad rangeof sophistication, flexibility is a major factor imposed byuser considerations.

In making interface design choices, it is useful to keep inmind the characteristics of people using online documentation (or any documentation [16]):

• They are in a hurry.

• Their main interest is elsewhere, in the program they aretrying to write or the application they are trying to use.

• They are often in the middle of doing something else. Ingeneral, people don't read documentation until absolutely forced to do so by a situation in which they cannot progress without further information.

• They are often confused, frustrated, or annoyed already,by being forced to stop what they are doing to consultdocumentation.

It is important to remember as wellthe dimensions alongwhich people vary and to reflect those differences in software design choices:

• People differ in their goals in using online documentation. Lookup software needs to support direct questionsas well as task-oriented searching and undirected browsing.

• People differ in the level of expertise they bring to a situation-expertise in the application they are using, in theonline documentation system, and in the general area ofcomputer knowledge.

• People differ in styIe of use and learning. Some like tofollow instructions exactly and learn a little at a time ina controlled fashion; others like to explore in all directions at once with no constraints at all.

• People differ in their preferences about "cosmetic" aspects of a system. These differences, though not directlyrelated to software functions, define the feel of the soft-


ware to the person using it and thus the person's overallsatisfaction with it. Subjective reactions are as importantin design as are sophisticated features.

USER INTERACTION DESIGN ISSUES

During design of an online documentation system, manyusability questions arise. This section discusses some ofthe most important issues that must be considered explicitly in designing any system for presenting information tousers.

Is It "Help" or Information Finding?As noted, there are two major strategies for providing online information:

• HELP systems• Online documentation

Of course, the distinction is primarily a difference in emphasis; however, it is informative to consider where thatdifference leads.

Online Help-People who characterize their work as online help consider their design in terms of users recoveringfrom errors. Their system is invoked when a user hasmade an error and is confused.

These systems typically concentrate on issues of contextsensitivity. How can the helping software find out enoughabout what the user was doing and what went wrong toexplain the problem in the appropriate terms and offer advice about how to correct it?

Consider a problem in a program running in a typical operating system. Users might or might not get any notification about what was wrong, depending on whether it was aproblem that the application had anticipated. They typeHELP or press a help key. The help program, a separateapplication, then tries to figure out what to give help with.

Depending on the operating system, the help program hasmore or less information to work with, ranging' from somerepresentation of the state or history of the running program to whatever the last command input was. It requiressubstantial work in this kind of execution environment forthe application program to have left enough hints aboutwhat it was doing that the help program can make informed guesses about what to tell the user. A number ofresearchers have experimented with this kind of help system [17]. Most commercial operating systems limit themselves to providing a limited amount of "canned" help,based on the command that the user was trying to execute.

Some operating systems provide sophisticated error-handling facilities that application programs 'can use to giveboth information about problems and, when possible, waysto recover from the problem and continue processing. For

239

example, consider the following kind of error (user typingshown in italics):

=> Show Directory

(files [default q:)george) *. * .newest)) q:)oops)

))Error: The directory )oops) does not exist.

For Q:)oops) *. * .newest

Choose an option:

1. Create directory )oops

2. Retry DIRECTORY -LIST of Q:)oops) *. * .newest

3. Return to Lisp Top Level in Lisp Listener 1

In most operating systems, this kind of error (a typo in adirectory name) is simply fatal. In the one portrayed in theexample, the error is signalled to the user along with amenu of options for dealing with the situation [18]. Various layers of application programs can add their own recovery options to the standard ones provided by the operating system.

It is important to realize that you cannot graft this kind ofcapability onto an existing operating system as a separateproject. It requires sophisticated system internal support,common error handling conventions in all system routines,and a large library of predefined classes of errors. This isan example of how adequate system-level support makes iteasier to provide helpful information about error recoverywithout requiring the user to interact with a formal helpsystem.

Online Documentation-People who characterize theirwork as "online documentation" typically have the goal ofmaking reference material available to users on request[19, 13]. They think in terms of someone reading the manual rather than someone groping to recover from an error.

Typically users would be doing something complicated,like using a new operating system facility, or trying to remember some application feature, like how to redistributeelectronic mail. An online documentation system displaysreference materials about these topics as they request it.

Systems vary in what they make available to users. Fromleast to most desirable from the users' point of view:

• Abbreviated in the form of help files, containing all thesyntactic information they need to issue the command,sometimes with a summary of the meanings of the various options

• Text from the system documentation about various commands in the form of a page facsimile manual, displayedon the screen

• A data base of system documentation, containing definitions, conceptual explanations, and reference material


As well as varying in what information they provide tousers, systems vary in how users request this information,for example:

• Direct request about a particular command

• Keyword request about a particular term

Direct requests are typically implemented with an operating system level HELP command, although a help application program should also support direct requests. A directrequest comes about when the user knows the name of thetopic and simply wants information about it.

It is far easier to write software support for direct accesscommands; only limited text material is needed. Unfortunately, they require that the user know the current systemterminology and command set; they are not very useful forconceptual material, in which the names of topics are notconstrained by the names of software modules.

A keyword request would be implemented by a documentation application program that you enter in order to statequeries and read relevant material. The strength of this approach is that you don't have to know much about whatyou need to read in order to find it. The burden for making information findable rests on the writers of the lookupsoftware and on the writers of the documentation itself.

Keyword request commands are the online equivalent of anindex. They require that the index be created, either manually by the writers or with some software assistance. Theyrequire software to interpret the queries and to manage theset of possibilities returned.

It is in this topic that online help meets document retrievalfrom data bases. Researchers in information retrieval arevery concerned with the issues of choosing keywords andclassifying topics so that information can be found by people who either don't know it is there or don't know how toask for it. Information retrieval concepts are an importantsource of insights for people doing online documentation[20].

Locating Information and SearchingIn using online documentation, the user initiates the interaction by some kind of request. So far we have discussedhelp commands and, more vaguely, special-purpose helputilities. A number of different styles of information finding commands have been implemented:

• Direct command systems. The user enters a HELPcommand, which often gives help by default on the topics that it knows about. For example, in VAX/VMS,using the HELP command with no argument displays thelist of possible topics and then prompts you to enter one[10].

• Menu systems. The HELP command calls up a helpmenu with the most general categories of information(top-level table of contents) listed. The user selects anitem, which brings up the next-level table of contents,and so on down to actual screens full of information.After, reading the information, the user returns either tothe last menu seen or to the top-level menu, dependingon the system. Microcomputer and word processor software often use this strategy.

• Tree-structured document readers. These use the samebasic information structure as a menu but encourage theuser to think of the process as tree (or sometimes network) traversal. The user starts at the root of the HELPtree and traverses through its topics with commands likePrevious Node, Next Node, Top of Tree [21]. An individual node of the tree can usually be selected if itsname is known. After browsing around for awhile, usersmay have the uneasy feeling that they don't know wherethey are.

• Index-oriented systems. The user enters a documentation searching command that finds all the topics in adocument that match a particular query [22]. For example, one might ask to see all the topics whose names andkeywords contain words that start with mail and read.This produces a list from which you choose a topic toread. When you are finished, you can select anothertopic from the same list. Unlike the menu systems, control over what to read about is direct and content-oriented.

Control of Pacing and VisibilityThe designer of online documentation systems needs to beparticularly aware of controlling visibility of material. Ideally, users would have control over the following aspectsof an interaction:

• When something appears

• Where it appears

• When it disappears

In the traditional operating system, HELP commands seldom provide control over these aspects of the interface.The most important aspect, however, is control of the disappearance of the information.

One of the minimum requirements for implementing anoperating system HELP command is that the system offer"page processing" capability. This capability probably hasas many names as there are operating systems; in essenceit is the part of the system that puts out a full screenful ofinformation and then automatically stops until the personreading it issues a command to resume displaying. It iscrucial that the readers not have to push keys to preventthe display from zipping past before they can read it.


Newer systems that support windowing have different interface needs for controlling scrolling of material on thewindow.

Operating ConventionsFew programs are more frustrating than a help system thatthe user cannot figure out how to use. A help sysjem requires clear controls. Systems for occasional, neophyteusers should include instructions about controlling the helpsystem on each screen as part of the frame in which information is displayed. Systems for users who will becomehighly skilled should make it easy to discover the operatingconventions, providing, for example, a help button forhelp about using the documentation system.

I~ the ideal case, the conventions for controlling the helpdisplay will be the same as the controls for other applications in the same system.

FlexibilityThe more flexible the possible interactions with the system, the more likely it is to fill people's needs. The onething that all users of a help system have in common isthat they are searching to fill gaps in their own know ledge.Thus, they need to feel free to change their minds or tofollow interesting trails that come up, without losing theirplace.

Ideally, a help system supports users in exploring by offering the following kinds of facilities:

• Moving from one topic to some other topic that is mentioned as a cross-reference or related item of interest

• Remembering the user's position in a partly read topic

• Remembering the items that a user has read in a "history"

• Returning to the context from which a user originallyentered the help system

How Much Do You See?In help systems, it is possible to offer relatively sophisticated controls over how much the user sees about a particular topic. Some of these features are available in commercial systems; others have been investigated in researchsettings:

• User level. Much research in human-computer interaction uses a novice/expert dimension in characterizingpeople's information needs (as in Schneider [23], forexample). The user is classified, by means of a profile,as novice or expert (and possibly several levels in between). Appropriately written help information is thenoffered.

241

The problem with this categorization is that people havediffering levels of expertise in different areas of the system. A wizard in one area can be a complete beginner inanother. Some research systems attempt to categorizeusers "on the fly" by examining the kinds of questionsthey ask and then responding at a level appropriate tothe level of the question.

• Information level. Another possible approach is to categorize the level of the information available rather thanthe level of the users reading it. For example, you couldhave categories like end user, application programmer, system programmer, microcode programmer,and so on. In any search for information, users declarewhat level of information they are interested in. Becausethese categories are related to the kind of the job that theuser is doing, they are more likely to provide a mechanism for supplying information at a level appropriate forits reader.

• Document depth. Some systems have experimentedwith controlling the depth (in the table of contents sense)to which material is supplied. In simple HELP commandsystems, this usually takes the form of a "verboseswitch" that requests full detail about a topic. More sophisticated systems have arranged their help material hierarchically in such a way that users can ask to see thetop level, the top three levels, the top N levels or all theinformation about a particular topic. This presupposes acertain discipline in writing the documentation contentsso that they are comprehensible in this kind of display[24].

• Successive revelations. Some systems have experimented with an approach that successively producesmore information. In a given situation, the first requestfor help produces very brief syntactic reminder information, sufficient to remind a skilled user. The next request for help enlarges on the first, perhaps explainingthe meanings of the options. A further request brings upmore material, perhaps background, task-related information, or definitions. This kind of system has also beencalled a "help me harder" approach.

Impact of Volume on Design ChoicesOne of the major variables in the design of interactiontechniques for a help system is the volume of informationthat the system will be called on to manage.

Simple menu systems are appropriate for managing smallamounts of information, for example, 20 to 75 commands.The limitations are imposed by a number of interactingfactors, including the following:

• Screen size

• The number of items that can appear in a menu before


searching it visually takes too long (around five toseven)

• The number of levels "deep" a menu hierarchy can bebefore people find it clumsy, confusing, or irritating(around three)

Command-driven systems in which users ask directly abouttopics or commands can handle larger amounts of information. They are basically limited either by the users' memories of the command set or by the ability of the file systemto handle many small files.

By improving the technology for allowing users to findcommands of interest, we can offer a greater volume ofdocumentation without adding to the apparent complexityof the document finding program. For example, our onlinedocumentation system manages about 10,000 distinct topics, corresponding to roughly 8000 pages of printed documentation. The document set has tripled in size over 3years while the number of significant words in the indexhas doubled. Online users are mostly unaware of the significant increase in size because they do not have to knowthe names of topics in order to retrieve them.

SOFTWARE ISSUES

This section surveys some of the software design issues inbuilding online documentation systems.

PerformanceThe overriding goals in the design of online documentationsystems are speed and reliability.

Speed-Experience has shown the importance of speed inonline documentation. For example, the Xerox Star workstation [25] received high marks for its user interface ingeneral. Its online help system, however, was painfullyslow, taking several minutes to retrieve a topic the firsttime it was looked up. In practice, this meant that usersdid not use the documentation online.

All other things being equal (for example, a system wherethe online and paper documentation contain the same information), users will use the most convenient means forfinding information. Sometimes they are willing to wait alittle longer for the computer than they think it would takethem to find the information in the paper manuals becauseit is easier to wait than to get up from their chairs to findthe manuals.

Oddly enough, users tend to underestimate how long ittakes them to find something in the paper documentation.Sometimes they believe that they can find something fasteron paper than they really can. It is possible that this is because the manual search is using filled time; the users aremoving their hands and eyes and engaging in cognitivesearching activity. In online documentation lookup, the in-

terval between asking the question and finding the answeris unfilled time; the user sits and waits until somethinghappens.

An acceptable goal for the interval between the request tosee something and its first appearance on the screen appears to be in the range of 2 to 10 seconds (although thefaster it appears the better [26]). It is important to designthe software so that, as the size of the information baseincreases, performance either remains the same or slowsvery little. Degradation in speed that is linear with increasing size isn't good enough; people will stop adding material to the information base and will stop using the lookupfacilities.

Reliability-At one time, I was using a TOPS-20 systemin which the command

@HELP HELP

yielded the answer

There is no help available for HELP.

At least it admitted the fact cleanly and gracefully withoutcausing any user perception of software error.

Help systems must be completely reliable for people to usethem with confidence:

• They must produce a helpful message about the absenceof the topic rather than doing nothing or reporting anerror. For example, the system we built at Symbolicstells the user where to look in the paper manual set tofind any information that has been deleted from the online data base. (Customers do delete your online documents!)

• Designers must test the documentation rigorously tomake sure that the right text displays when the user asksfor information and that the text displays correctly.

• In keyword systems, it is important that queries find asmany relevant topics as possible. When users discover acase in which the system didn't find something that theyhappened to know was in the information base, they stoptrusting the search mechanisms.

File StructuresOne of the most important software design decisions to bemade concerns the file structures for the documentationinformation. There are three possibilities:

• One big file. For example:

-A word processor file in which the material for eachcommand is marked with some special flag or sequence so that the displayer software can search the


file for topics

-An indexed sequential file, in which the file systemprovides content addressability

• Multiple files or a hierarchy oj files. Each commandor topic is documented by the material in a single file;the file is named by the command that it contains [27,10]. For example, you have a root directory namedHELP; documentation for each command is contained ina file within that directory named according to simpleconventions. For example, the file for the ASSIGN command would be called ASSIGN.HLP.

This convention makes it very easy to document newtopics. You create a new file, using the right namingconvention, and add it to the directory. Presto, yourHELP system has been updated. Some operating systems, however, have inherent limitations on the numberof files that a directory can contain, the number of characters in a file name, or other performance reasons thatrule out using legions of small files whose names arebased on content. VAX/VMS implements this style ofhelp by using "text libraries" which can be searched fortopics faster than directories.

In this approach, the software cannot have any knowledge about what topics are "supposed" to be documented. If the file exists, the topic is documented; otherwise, it isn't. A more elaborate design is needed to helpusers find information that isn't clear from the filenames.

• A data base of documentation information. You create a data base indexed by topic name, by keywords,and perhaps by other characteristics like contents or release number [28, 22]. The data base software maintainsthe indexing information and provides a well-definedsoftware interface to support functions like searching orquerying the data base.

For help applications that need to handle large volumes ofinformation or information other than command namehelp, the data base approach is the most flexible and easiest to generalize. A data base approach can be implemented without using data base software [5, 29, 30].

To some extent, the filestructure decision might have already been made by the software environment that is offered on the designer's development system. However, thedata base and indexed sequential file approaches are themost flexible and powerful. It is worth considering thebenefits that can be obtained from the data base approachbefore automatically choosing the help file and directoryapproach.

Formatting Control and FlexibilityA very difficult software choice concerns the kind of control that the system offers over the appearance of the on-

243

line documentation. The issues are difficult, affected tosome extent by hardware as well as software. Again, arange of solutions is possible:

• Manual arrangement ofplain text. A plain ASCII fileis prepared using any text editor, or a special wordprocessor file is prepared using the facilities of the locally available word processor program. The file contains characters in a fixed-width font, prepared to fit astandard screen width. The notion of a "page" corresponds to the expected number of lines on a screen.

Microcomputer workers are familiar with the effects ofthis kind of effort; files assume 24 X 40 size screens toaccommodate the lowest common denominator terminal.Fortunately, most modern terminals seem to offer onekind of highlighting which the documentation can usealong with capitalization to differentiate classes of information.

• Page-oriented formatter. A formatter source file is prepared for a batch formatter that can prepare files forseveral different kinds of devices, like typesetters andtypewriters. To prepare online documentation files, theformatter is run in "typewriter" mode and the documentation so obtained is displayed on the screen-pagebreaks, page numbers, running heads, and all [27].

• Generic formatter. A formatter source file is preparedthat formats text flexibly according to the characteristicsof its display environment. For paper documentation, theformatter places the text according to a book design fora typesetter. For output to the screen, the formatter usescurrent window parameters in placing line breaks andmaking other formatting decisions. For screen display,the notion of page does not apply; pages that match thesize of pages in the' paper world are not appropriate display units. With appropriate positioning commandsavailable, a screen is more similar to a galley or scrollof infinite length [22].

Using a generic formatter language allows writers to concentrate on the content of the text rather than some one ofmany possible final appearances [31].

Hard CopyThe ease of creating printed paper copies of documentationis closely related to the issues in formatting the information. The most important decision to make is whether thescreen is a page facsimile, the page is a screen facsimile,or screen and paper displays are both optimized independently for the medium on which they appear.

Because of the differences in size, fonts, and potential resolution between screen displays and conventional printing,the facsimile approach to hard copy is always unsatisfactoryfor one or the other medium. Screen displays should not besaddled with vestiges of paper formatting (like top and bot-


tom margins and running heads). Paper displays should notbe constrained by the number of fixed width characters andlines that fit on a screen, nor by the limited selection offonts and highlighting conventions that are available onscreens.

Even if print and screen resolutions were equivalent, it isunlikely that making the screen a facsimile of the printedpage would be the correct choice [9]. In printed material,10-point type seems generous and readable. On a screen,with its different contrast, luminance, viewing distance,and viewing angle, 10-point type seems too small for manyusers.

The effort that is most successful for the largest number ofpurposes is to have a generic formatter that can produce adisplay formatted appropriately and independently for eachmedium. Of course, reasonably priced, high-resolutionprinting technology is also required.

Effects of Volume on Design and ImplementationIn choosing the design for the help information base, thedesigner must think about the future. Few computer documentation sets are static; most need revision quickly andconstantly. What aspects of the design does this affect?

• Storage structure. The larger the base of informationthat you anticipate offering, the more careful you needto be in choosing file structures, data structures, andsearch algorithms. You cannot grow incrementally froma small online documentation system (say 100 commandsor 150,000 characters) to a much larger (say 2 millioncharacters) system, all based on a single word processing file, without serious loss of performance and reliability.

• Extensibility. Different products require different levelsof extensibility. It is clear that in large operating systemenvironments, independent modular files have great advantages in allowing the user community to add documentation for their own programs or procedures withlittle learning overhead.

• Maintenance. The more information that must be maintained, the more care is needed in choosing a flexibledata structure. As systems grow or change and the information must be updated, smaller files with generic formatting control information will prove to be more maintainable. Hand-formatted files are the most difficult tomaintain, causing tremendous difficulties when new information (or the need for translation) causes a carefullysized topic to suddenly require more than one screen fordisplay.

AIDS FOR DOCUMENT AUTHORS

In the design of an online documentation system, seriousconsideration should be given to the jobs of the people

who write and maintain the contents of the documentation.Design choices should be made, as much as possible, toreduce "overhead" activities of documentation writers.Another way of saying this is that the power of the computers involved should be dedicated to making the jobs ofthe writers easier, as well as to improving the lot of theend users [32, 33].

It simply is not cost effective to put the documentation online to save printing costs, without also providing computer support tools to make the writers of that documentation more effective and productive.

The following are some areas where software design canbe applied to making the writer's job easier:

• Locating information. Writers should not have tomemorize file names and use search commands withinlengthy files in order to locate source information thatneeds editing.

• Formatting. Generic code formatting systems make thewriter's job easier by reducing the amount of hand tuning and fiddling required to produce simple documenteffects, like numbered lists and tables [31]. It is a disadvantage for the readers as well as the writers if the difficulty of the formatting software discourages writersfrom using important informational devices like tables,lists, and figures.

• Standards. The system should support the local set ofdocumentation standards transparently. Writers shouldnot have to specify standard details about appearance.

• Cross-references. Online documentation software withknowledge of the structure of the documentation can beused to facilitate the otherwise tedious tasks of findingand validating cross-references.

• Multiple use of information. Writers should not beprevented from using the same information in two placesby nightmares about maintenance. The software shouldsupport redundancy in the displayed documentation without duplication in the sources.

• Patching. Particularly for large online documentationsystems, the software should support incremental updating of the documents.

WRITING FOR USE ON LINE

Few technical writers have yet had much experience in thearea of writing documentation specifically for online use.In fact, our experience indicates that the basic communication issues in technical writing are the same, regardless ofthe delivery medium. Still, I have observed some areaswhere attention to detail pays off in higher perceived quality of online documentation and, presumably, better overallcommunication.


The following realistic example presents, first, an originalpiece of online documentation (Before) and then the sameinformation (After) rewritten according to some basicprinciples:

BeforeSelects the most recently selected window. With an argument,selects the nth previously selected window and rotates the topn windows. (Default arg is 2). With an arg of 1, rotatesthrough all the windows. With a negative arg, rotates in theother direction. With an argument of 0, selects a window thatrequires attention, e.g. to report an error.

AfterSelects a window from a usage history stack.

Argument Selects

none Most recently selected windowo Window requiring attention, e.g. to report an

error1 Next window on the stackN Nth most recently selected window

- N Nth least recently selected window

The presence of a nonzero argument (N) causes the stack origin

to rotate by N.

Because of fuzzy terminology in the original, I'm not surewhether I have preserved the intended message. In anycase, the main point to consider is the relative ease of selecting the relevant information from the two displays. Inthe tabular form, it is easier to find the possible argumentvalues and, once one has been chosen, easier to find andread the associated explanation. The ease comes. from theregular physical structure of the table; the eye movementsrequired to find something are smaller and more predictable than they are in the paragraph form of the information.

Writing StyleGood writing style has the same parameters, independentof the delivery medium for the text. In writing helpscreens, where the main criterion is conciseness, a fewwriting issues become more important than usual:

• Terminology. Well-chosen, consistently applied terminology is always important. In a short help frame, youhave few words in which to get your message across.The right term, used consistently, helps convey the message more clearly.

• Conciseness. Much written language is redundant, witha few content words bundled up in a reassuring sentenceframework. On small screens, the main goal is to get themessage across unambiguously in as few words as possible. One excellent strategy for this is the use of tables.Occasionally tables take more space than the sentencesthey are replacing (for example, when the original sentences didn't really contain all the information theyseemed to) but the gain in accessibility of the information makes this worthwhile.

245

• Short paragraphs, pacing. For some reason, peopleseem more daunted by large blocks of text when readinginformation on a screen. Try to identify short, meaningful topics and treat them in separate paragraphs. Someonline help systems carry this to a somewhat ridiculousextreme, putting about three lines of useful informationon each screen, forcing the user to work continuously,pressing continuation keys in order to see more information. Although it is true that limiting the size of thechunk of information presented at one time helps comprehension, it is also hard to get any sense of continuityabout a subject that is being leaked to you in very smalldrops.

FormattingThe arrangement of documentation on the screen is veryimportant. With most conventional terminals, crowding isa dominant concern in the effort to make some topic's information fit on a single screen. The goal is to place asmuch information on the screen as makes sense for the application while still maintaining an overall impression oflegibility [4, 34].

Large project teams should include a graphic designer, atleast as a consultant, for making the actual design decisions. (Conventional book designers are not necessarilyqualified to make design decisions for online documentation.)

The following notes are general guidelines to the importantissues:

• Functional white space. A common error in online documentation systems is using the same white space forscreen displays as for the paper manuals. White spacethat is esthetically pleasing for paper book design nearlyalways looks excessive on a screen, particularly on a 24line display. For example, l-inch top and bottom margins not are necessary for readability on a 24-linescreen. A single line of white space is sufficient.

It is important to keep in mind that optimum white spacedoes not mean no white space:

-Use a left margin to avoid a cramped feeling.

-Use reasonable length lines and consider using doublecolumns (but only if software technology makes it feasible to maintain).

-Use tables to break up horizontal area.

• Ragged right. Especially with conventional fixed-widthcharacter terminals, documents should be prepared withragged right margins rather than right justified (aligned)margins. Right justification was an accident of the development of printing press technology and need not bepreserved in new display technologies. Right justified


text on computer screens tends to introduce areas ofnonfunctional white space that the reader has to work toignore. The reader's eye jumps into the white space andthen looks subconsciously for its significance; there isn'tany.

• Tabular layout. The importance of tables cannot beoveremphasized. They tend to be more compact thansentences with equivalent information and they introducewhite space into what would otherwise be solid blocksof characters. The importance of the white space is notjust fewer words or less dense appearance; it actuallyshows readers where to look and how to move their eyesin order to extract necessary information.

• Conventions. In early days of online help systems, theonly "differentiator" available to the writer was case.People tended to put command names in upper-case andthe rest in mixed case. Large areas of upper-case material are more difficult to read than mixed case material;the advent of modern terminals that offer at least onestyle of highlighting and sometimes color is a blessing inthat upper-case text is no longer needed.

These features can be a mixed blessing, however, if theyresult in an indiscriminate mix of upper- and lower-caseconventions with color with underlining, bright, and reverse video. Case and font conventions should have toprove their usefulness. It isn't necessary to put the command names in double bright underlined blinking inversevideo; one of those highlighting conventions would suffice and convey the same information to the reader withless possibility for distraction.

OrganizationReaders always appreciate well-organized documentation.For online use, organization is even more important thanusual: screens are smaller than pages and moving aroundin almost all help systems is harder to control than pageturning. Readers benefit greatly from being able to moveto the area of the help display that they know will containthe information they need, without close visual search andtime-consuming interaction with the controls.

The following organization techniques are suggested:

• Alphabetizing. Commands with many options shouldalphabetize the options in tables rather than placingthem, for example, in most-to-least common order.

• Parallel information structure, consistent level oftreatment. Similar sections of the online documentationneed similar treatment. If you use the same organizationfor every command you describe, readers will find itfaster to search for information-for example:

SummaryExample

Command optionsFull meaningRelated topicsKnown problems

.• Related information. The online analog of quick page

flipping is hard to provide. It is important to use crossreferences heavily to provide information to readersabout related topics. You can't depend on the vaguestructure of "nearby" to clue the reader in to relatedmaterial. In a sense, this is no different from writing forpaper manuals. Explicit cross-referencing improves theusability of paper manuals as well; it is sometimes easier, however, to explain to writers the difficulties causedby poor explicit cross-referencing by using the exampleof online documents.

ModularityThose who have attempted to design a documentation setfor online use have wrestled with the concept of modularity in documentation. One simple way of explaining it isthat one topic in an online document should describe onefact. Given that, how do you put all the facts together?How do you write sections that can be read out·of context?

Perhaps the most critical difference between online andprinted documentation is that in online documentation, thetopics are very clearly designed to be read out of context.The user interface is designed expressly so that a user canask to see some particular topic without having read anything of what came before it in the paper version of thedocument.

The notion of direct access makes technical writers verynervous at first. They seem to forget that readers are verygood at picking up a paper manual, opening it to the pagethat they want to see, reading one paragraph, and shuttingthe book. Although the problems of writing self-containedmaterial are not unique to online documentation, failures inmodular writing are much more obvious to the reader ofonline documentation.

The simplest form of modularity failure is to assume someserial order of reading topics. This leads to errors likestarting modules with sentences like "This means that. ... "Further obvious cases are phrases like "as we saw before"and "the above examples show" (when the referents are ina different module).

Breaking the habit of assuming serial order takes somepractice. One good strategy is to concentrate on writingclear topic sentences. Another good strategy is to actuallyuse the online documentation as an end user would, tryingto find topics and understand the information from them.Most writers find this to be a very illuminating experience.We have found that writers can fairly quickly develop agood sense for writing material that can be understood"stand alone."


One strategy for decreasing dependence on context is to bemore repetitive or redundant, to say the same thing in morethan one place so that the reader doesn't have to chase allover to find the context. Repetition of large sections cancause maintenance nightmares if used carelessly; it shouldbe avoided unless the software allows reuse of source material in more than one place in the documentation.

Another very useful strategy for reducing context problemsis to provide "related information" fields with each helptopic. Providing a list of the topics related to the currenttopic gives readers the ability to find the relevant parts ofthe context directly. In fact, this approach is more powerful in some ways than the context provided by some partially accidental serial ordering of topics in a printed manual.

SUMMARY AND CONCLUSION

The test of an online document system of any kind iswhether people use it and whether they use it for its intended purpose. If it was designed as an online referencemanual, do they read it or use it mainly to check syntacticcorrectness of function calls or commands? If it was designed to help people with errors, do they use it or do theyignore the availability of help and simply start over again?These questions are not simply rhetorical!

If the resources are available, designers should considermonitoring the effectiveness of their online documentationsystem-survey people at users' group meetings, have thesales people collect comments, or build monitoring capability into the software. One major use for the informationis in campaigning for further resources, for either maintaining, improving, or extending the system.

This paper has concentrated on characteristics of existingonline documentation systems raising issues that come upin the design of such systems and discussing what choicesto make. The possibilities it presents are all realizable nowby small-sized but big-thinking development groups.

For the most part, I have not talked about "pie in the sky"features or strictly research environment systems. Muchexciting research and advanced development work is goingon with experimental hardware and software support. Thefollowing are just a few examples:

• Artificial intelligence systems that understand the kind ofhelp needed [35]

• Automatic explainers, including natural language explanation generators [36, 37, 38]

• Mixed media presentations of information [39, 40]• Hypertext document browsers [41,42]

REFERENCES1. Girill, T. R., and Luk, C. H., "DOCUMENT: A Interactive, On

Line Solution to Four Documentation Problems," Comm. ACM26, 5, 1983, pp. 328-337.

247

2. Gould, J. D., and Grischkowsky, N., "Doing the Same Work WithHard Copy and With Cathode-Ray (CRT) Computer Terminals,"Human Factors 26, 3, 1984, pp. 323-337.

3. Kruk, R. S., and Muter, P., "Reading Continuous Text on VideoScreens," Human Factors 26, 3, 1984, pp. 339-345.

4. Gould, J. D., Alfaro, L., Finn, R., Haupt, B., Minuto, A., andSalaun, J., "Why Reading Was Slower From CRT Displays ThanFrom Paper," Proc. CHI + GI '87 Human Factors in Computing Systems and Graphics Interface, SIGCHI Bulletin, April1987, pp. 7-11.

5. Rubenstein, R., Digital Typography: A Primer, Addison-Wesley,Reading, MA, 1987.

6. Weyer, S. A., and Borning, A. H., "A Prototype Electronic Encyclopedia," ACM Transactions on Office Information Systems 3,1, January, 1985, pp. 63-88.

7. Shneiderman, B., and Morariu, J., "The Interactive EncyclopediaSystem (TIES)," Technical report, Department of Computer Science, University of Maryland, June 1986.

8. Shriver, K. A., Hayes, J. R., Danley, C. C., Wulff, W. W., Davies, L., Ceroni, K., Graham, D., Flood, E., and Bond, E., Designing Computer Documentation: A Review of the RelevantLiterature, Communications Design Center, Carnegie Mellon University, Pittsburgh, PA 15213, 1986.

9. Borenstein, N. S., The Design and Evaluation of Online Help,PhD dissertation, Carnegie Mellon University, April 1985.

10. Digital Equipment Corporation, VAX/VMS Command LanguageUser's Guide, Maynard, MA, 1983.

11. Digital Equipment Corporation, DECSYSTEM-20 User's Guide,Maynard, MA, 1977.

12. Symbolics Inc., User's Guide to Symbolics Computers, Release7.0 ed., Cambridge, MA, 1986.

13. Walker, J. H., "Symbolics Document Examiner," SIGGRAPHVideo Review, Vol. 19, 1985.

14. Online tutorial for Lotus "Symphony" product.15. Ewing, J., Mehrabanzad, S., Sheck, S., Ostroff, D., and Shneider

man, B., "An Experimental Comparison of a Mouse and ArrowKeys for an Interactive Encyclopedia," Technical report CS-TR1475, .Department of Computer Science, University of Maryland,February 1985.

16. Carroll, J. M., "Minimalist Training," Datamation, November 1,1984, pp. 125-136.

17. Fenchel, R. S., and Estrin, G., "Self-Describing Systems UsingIntegral Help," IEEE Transactions on Systems, Man, and Cybernetics 12, 2, 1982.

18. Symbolics Inc., Symbolics Common Lisp: Language Concepts,Release 7.0 ed., Cambridge, MA, 1986.

19. Orwick, P., Jaynes, J. T., Barstow, T. R., and Bohn, L. S., "DOMAIN/DELPHI: Retrieving Documents Online," Proc. CHI '86Human Factors in Computing Systems, SIGCHI Bulletin, April1986, pp. 114-121.

20. Salton, G., and McGill, M. J., Introduction to Modern Information Retrieval, McGraw-Hill, New York, 1983.

21. Robertson, G., McCracken, D., and Newell, A., "The ZOG Approach to Man-Machine Communication," International Journalof Man-Machine Studies 14, 1981, pp. 461-488.

22. Walker, J. H., "Document Examiner: Delivery Interface for Hypertext Documents," Manuscript submitted to Hypertext 87 Workshop.

23. Schneider, M. L., "Models for the Design of Static Software UserAssistance," in Directions in Human Computer Interaction, A.Badre and B. Shneiderman, ed., Ablex Publishing Company, Norwood, NJ, 1982.

24. Watt, J. H., and Senk, M. I., "Information Transfer vs. Level ofAbstraction in Structured Communications," Proceedings of the1986 International Conference on Systems, Man, and Cybernetics, IEEE, 1986, pp. 605-610.

25. Seybold, J., "Xerox's 'Star,'" The Seybold Report 10,6, 1981.26. Shneiderman, B., "Response Time and Display Rate in Human

Performance with Computers," Computing Surveys 16, 3, 1984.27. AT&T Bell Laboratories, The UNIX Programmer's Manual,

1978.28. James, G., Document Databases, van Nostrand Reinhold, New

York, 1985.29. Kehler, T. P., and Barnes, M., "Interfacing to Text Using

HELPME, " SIGSOC Bulletin: Joint Conference on Easier andMore Productive User of Computing Systems, Ann Arbor, MI,ACM SIGSOC, 1981.


30. Witten, I. H., and Bramwell, B., "A System for Interactive Viewing of Structured Documents," Communications of the ACM 28,3, 1985, pp. 280-288.

31. Reid, B. K., Scribe: A Document Specification Language and itsCompiler, PhD dissertation, Carnegie Mellon University, December 1980.

32. Engelbart, D. E., "Authorship Provisions in AUGMENT," Intellectual Leverage: The Driving Technologies, IEEE SpringCompcon84, 1984, pp. 465-472.

33. Walker, J. H., "Symbolics Sage: A Documentation Support Systern," Intellectual Leverage: The Driving Technologies, IEEESpring Compcon84, 1984, pp. 478-483.

34. Rubens, P., "Online Information, Traditional Page Design, andReader Expectation," IEEE Transactions on Professional Communication PC-29, 4, 1986, pp. 75-80.

35. Fischer, G., Lemke, A., and Schwab, T., "Knowledge-Based HelpSystems," Proc. CHI '85 Human Factors in Computing Systems, SIGCHI Bulletin, April 1985, pp. 161-167.

36. Cullingford, R. E., Krueger, M. W., Selfridge, M., andBienkowski, M. A., "Automated Explanations as a Component of aComputer-Aided Design System," IEEE Transactions on Systems, Man, and Cybernetics 12, 2, 1982.

37. Hayes, P. J., and Glasner, I. D., "Automatic Construction of Ex-

planation Networks for a Cooperative User Interface," SIGSOCBulletin: Joint Conference on Easier and More Productive Userof Computing Systems, Ann Arbor, MI, ACM SIGSOC, 1981,pp. 6-14.

38. Rich, E. A., and Morgan, H. L., "Programs as Data for TheirHelp Systems," AFIPS Conference Proceedings Vol. 51. 1982National Computer Conference, Houston, TX, AFIPS Press,1982, pp. 481-485.

39. Christodoulakis, S., Theodoridou, F., Ho, F., Papa, M., andPathria , A., "Multimedia Document Presentation, Information Extraction, and Document Formation in MINOS: A Model and a System," ACM Transactions on Office Information Systems 4, 4,1986, pp. 345-383.

40. Yankelovich, N., Meyrowitz, N., and van Dam, A., "Reading andWriting the Electronic Book," IEEE Computer 18, 10, October,1985, pp. 15-30.

41. Conklin, J., "Hypertext: An Introduction and Survey," IEEEComputer 20,9, September 1987, pp. 17-41.

42. Halasz, F. G., Moran, T. P., and Trigg, R. H., "NoteCards in aNutshell," Proc. CHI + GI '87 Human Factors in ComputingSystems and Graphics Interface, SIGCHI Bulletin, April 1987,pp.45-52.

TWO CommuGuide BOOKLETS NOW AVAILABLE

PCS's CommuGuide Booklets contain practical, step-by-step guidance, written in understandable layman's language, ready for easy application to your individual communicationsneeds. Two booklets now available for purchase are:

HOW TO PUBLISH AN ANTHOLOGY-Booklet No.1 (TH0148-7)

HOW TO WRITE AN INVENTION DISCLOSURE-Booklet No.2 (TH0149-5)

Additional titles will be published each year. You may purchase CommuGuide Booklets at$5.00 per copy, including postage and handling. Maryland residents should add 25 cents for5% MD sales tax; New Jersey residents, 30 cents for 6% New Jersey sales tax. Mail yourorders, accompanied by check, made payable to IEEE PCS, to:

Lois K. MoorePresident, IEEE PCSThe Johns Hopkins UniversityLaurel, Maryland 20707

or IEEE Service CenterCash Processing Dept.445 Hoes LanePiscataway, New Jersey 08854-4150