Our Articles ...

On Complex Documentation

  On Personalizing Content

On Complex Documentation

 On Kids' Software

On Home Software

On TV and Video

On Art, Poetry, & Drama

Draft Introduction to special issue of IEEE Transactions on Professional Communication, July 1997. 69-77.

By Jonathan Price

Abstract: To improve the structure of complex information when it is to be presented electronically, technical communicators may turn to ideas taken from object-oriented programming, to clarify and revive the structure of the material in existing documents before mounting them online. But when an organization starts moving information onto the Web, technical communicators may go through a phase transition, as the system becomes so much more complex it exhibits emergent behaviors, and demands new attitudes, concepts, and work from the technical communicator.

Increasingly, technical communicators face unfamiliar problems dealing with the geometric growth in the amount of information we have to manage, and the exponential growth in links spreading through the electronic form of that information. We are facing a transition from a Newtonian world of clearly identified hierarchical structures such as the command reference volume, well-worn processes such as document design, and settled roles (writer, artist, editor) to a new level of complexity, in which we are, at best, facilitating a flow of information coming from sources we do not yet know, and in structures we cannot predict. We are used to conceiving of an online help system, for instance, as a clear hierarchical structure through which the user navigates, following a limited number of paths we have opened up. But now we may be asked to meld that formerly self-contained system into a site that picks up information live from diagnostic or real-time applications, offers links to all other documentation ever created by the organization, and invites email exchanges. W e may be forgiven for feeling a bit dazed by the sheer complexity of the structures we assume we must build.

Building Structures out of Interactive Objects

For most of us, the very idea of structure assumes stasis is possible—a moment at which every brick in the arch comes to rest, and the key brick at the top locks into place. Our everyday idea of structure very usefully postulates a number of bricks, or objects, and a methodical way of arranging those objects for some purpose or function. Now, an architect may point out that each brick is communicating with every other brick, as vectors of force carry the load down to the ground. But we don’t usually perceive those messages, and, if we are just building one isolated arch we probably don’t have to care very much. But once we propose to create an aqueduct or a cathedral, suddenly we have to care very much how the objects interact. What looks to an innocent visitor like a solid, stable thing begins to look to its creator like a temporary network of forces, bound by gravity and the rules of high-school physics. That impression deepens when we enter the realm of electronic information, in which one virtual brick may communicate through links with a dozen other arches, several walls, and one or two virtual brick factories.

One approach to assembling such an enormous pile of information is to break it down into its components, then build various packages out of those elements, always presupposing that we can, in the future, reuse the constituent pieces for some entirely new packages, whose structures we cannot predict.

We can adopt an object orientation, based loosely on the approach used by designers of most new, complicated programs that rely on a graphic user interface, as described by software engineers [1]-[6]. This perspective can help us analyze our existing information, take it apart in useful chunks, and reassemble those into packages that address the needs of our users.

The objects that make up a standard installation guide are familiar to us, because each answers a question we sense that users want to know: What tools do I need to put this thing together? What components should I find in the box? What do I put together first, and how? Over the last century, millions of people have asked those questions, and technical communicators began to develop a standard set of elements to answer each question. From such a virtual conversation, imagined repeatedly, we get a genre, such as the installation guide, with a conventional set of objects (such as a Tools Required section, an exploded parts diagram, and several procedures), in a sequence generally recognized as most useful (prerequisites before procedures, installation before advice about usage). The pattern of the genre, sculpted for a particular organization and its audiences, forms the basis for the book designer’s work; the designer starts by identifying all the components, and understanding the purpose of each, then comes up with a design for each, hoping to suggest its function to the reader [7] – [9]. Most writers, though, are not as methodical as a book designer or editor, in analyzing the components, and the required structure, and format. Writers have traditionally tended to adopt various formatting and structuring strategies on the spur of the moment, or on a chapter-by-chapter basis, so many organizations have ended up today with legacy documents that are inconsistently organized and formatted, within themselves, and from one document to another.

If we want to reuse this material in several forms, creating a CD-ROM, online help, and a Web site from these existing documents, we quickly discover that casual organization, tolerable in books, causes major headaches when we want to extract some elements, and leave others behind, online. The elements have been mingled, merged, overlapped, and interspersed. We encounter an innocent mess.

The first step toward rebuilding, of course, is to ask our users what they now need. But traditional surveys and focus groups, although useful, still leave us with many uncertainties about which topics to include, what areas to emphasize, what material to skip. Hackos, Hammar, and Elser [10] suggest bringing users into a genuine partnership with the documentation team, just as users have been invited to join product design teams. The result is a much stronger sense of what really works, in the current documents, and an acute awareness of what information objects need to be added.

Having revisited our audiences, we look to an object orientation to help us reorganize and, if necessary, rewrite legacy materials to make them reusable in multiple media and different packages. Here, in brief, is the process as I’ve experienced it, working with teams to adapt legacy information for electronic delivery.

1) We list the questions we imagine our users asking in this virtual conversation, in more or less the order they might be asked. We are soon forced to recognize that some questions are high level ("How do I create a budget?"), others middle level ("How do I set up calculations in my spreadsheet?"), and others are low level ("How do I calculate an average for the values in a discontinuous set of cells?"). Generally questions tend to nest within questions, so that one high-level question breeds several middle-level questions, each of which opens up into a whole series of lower level questions.

2) We identify the conventional element we have developed as an answer to each question. For instance, as an answer to the question "How do I?" we have created an element called a procedure. Every element we spot in this way is an object.

3) We consider each type of element as a class of objects. We create a table in which we spell out several characteristics of each type of object.

• Function or responsibility: What general user question does this kind of object answer?

• Components: What smaller objects belong inside of it? How many of each are required? Optional?

• Membership: What objects contain this one, as a component? In those circumstances, is it required, or optional, and how often?

• Messages: To what other objects does this one send a message? For instance, a boldfaced word, if clicked, sends a message to the glossary definition saying, in effect, "Please pop up." And, if this object receives a message, how does it handle it? (By popping up in response to a link being activated, for example).

• Knowledge: What other objects does this one "know" about? It knows about its own constituents, about objects it belongs within, and about objects it sends or receives messages from.

• Attributes: What actual data does this kind of object contain? Who created it? Who modified it? When? What keywords are associated with it?

The result of our analysis and classification is a model of the ideal structure of each type of document we produce. If we are about to use a set of Standard General Markup Language (SGML) tools to facilitate multiple re-use of the same objects, we are now prepared to create the Document Type Description, or DTD [11], [12]. Of course, converting a department or organization to SGML takes much more effort than this, involving purchasing, project management, training, diplomacy, psychology, and incredible stamina, as Madigan, Silver, and Wilson point out [13].

But even if we are not going to convert our documents into that cumbersome but useful language, SGML, we have a model against which we can measure our current materials, and separate out the various objects that have been welded together. Having such a clear picture of the "way things ought to be" helps us analyze any legacy document, and dramatically improve it, because we are clarifying structure rather than massaging style. We look at any section, paragraph, sentence, or word, and ask

• Is this an information object? If so, what kind of object is it?

• Is it achieving its main function, as an object? Does it really answer the question we expect this kind of object to respond to? (If not, we have to wonder whether to add some material, exclude extraneous material, rewrite to clarify, or reconsider what kind of object we are looking at.)

• If we are pretty sure what kind of object this section of the text should be, then does it contain all the required pieces? And does each component show up where it should, according to the model?

• Is this object packaged inside another larger object, as planned?

• Does it send the right messages to other locations? For instance, are the cross references current? Does this heading show up in the table of contents? Is this term in the glossary? (In a paper book, the messages among objects are often quiet, compared to the dramatic click-and-popup available on the computer).

In many legacy documents, such an editorial analysis reveals many structural problems. For instance,

• One object masquerades as another. For instance, Step 5 fails to tell the user what to do after Step 4, and, instead, expands on the results of carrying out Step 4.

• The object fails to function correctly. For instance, the conceptual overview leaves out three key concepts, focussing instead on several cautions and negatives that really belong inside a procedure deeper in the chapter.

• The object lacks required components. For instance, a command reference omits an explanation of key parameters.

• The object includes components that are neither required nor optional. For instance, the installation guide takes off on a hymn to the marvelous algorithms that will control the processing the user will enjoy after installation has been completed.

• The object has ended up inside the wrong package of objects. For example, inside the command reference we find cautions that belong in the installation guide.

Making each object function properly, according to the model, improves the effectiveness of any document, just as developmental editors have been telling us for years, in different terms. Strickland, for instance, shows how many traditional editing strategies must be brought over to an online tutorial even when it is presented on a Web site [14]. (Of course, making an object work correctly takes hard work rethinking, reorganizing, and rewriting the material).

Recognizing and clarifying the object-like nature of each element also makes it easier to reuse the revivified objects. Take graphics, for example. As Harmison indicates, distinguishing a graphic as an object from its related callouts and captions allows a team to reuse the graphic in various situations, attaching different callouts as needed, rather than considering them "part of the graphic" [15]. Lincoln and Monk demonstrate how we can take large complex diagrams and unfold them in various ways, so that users can explore gradually, alternating between larger views and closeups, without getting lost [16].

Goldie demonstrates that taking an object-oriented approach, using the Standard General Markup Language, allows us to make even mathematical equations interactive, revealing additional layers of formulas underneath, at the click of a button [17]. A pure word-processing approach, in which we simply manage to "print" the equation on screen, leaves every variable dead, and makes such interactive exploration difficult, if not impossible, because the user must go to many other locations, find the background material, then return, and visualize the connection. Object orientation allows the equation to come alive.

And Harmison shows that identifying objects that can be updated, live, through supporting software, allows a team to import the latest data and place that where it belongs in the instructions, while modifying the material to show only the specific information relevant to the job at hand [15]. Result: fewer mistakes by users, faster work.

Similarly, the reference material on a command traditionally contains many categories of information, but writers in the past often tended to lump all that information together in one or two huge paragraphs. When we look at one of those paragraphs, and ask ourselves, "What questions from users did the writer try to answer, here?" we begin to see that there were many questions, and as a result, there are many responding objects buried together in the paragraph. By digging these answers out, separating them, and rewriting them to give them some individual significance, we resurrect the individual objects. We may, in this way, divide one paragraph up into a dozen distinct objects, each dealing with a particular category of information such as definition, syntax, parameters, prerequisites, processing notes, status messages, error messages, results, examples, cautions, alternates, and shortcuts. Now that we see how many objects there are, we can reuse them in several ways. For instance, in the book version, we can dedicate a separate paragraph, with its own heading, to each object, so users can skip to the one fact they want, ignoring the material that’s not relevant to their current task. Online, we can offer users a chance to specify which objects they most often want to explore (syntax, parameters, and examples, say), display those in full, and offer icons for all the others, clearing them out of the way until needed.

Surfacing the objects in our information makes repackaging easier, too. From a single source we can spin off a brochure, a book, a CD-ROM, a help system, and a Web site, picking some objects for each, leaving others out. We can begin to explore alternate structures, such as hierarchies, linear sequences, matrices, three-dimensional arrays, multiple overlays, parallel worlds, zoom magnifications and reductions, networks, mazes, and geographical maps, using the objects as an architect would to build an information environment that users would want to move through [9], [18], [19].

Most such package structures come with helpful metaphorical overtones; that is, they remind users of information devices they have used in the past, and thereby suggest how to take advantage of the objects in the current package. As Rauch, Leone, and Gillihan demonstrate, structural metaphors help users get a sense of what kind of information is being offered, and how to move through that information [20]. Rauch, Leone, and Gillihan adopted the metaphor of books in a library to help users find their way through a complicated set of instructional materials.

So taking an object orientation can help us create and refine the arrangement of objects, expanding the number of paths we make available through access mechanisms such as tables of contents, graphic and verbal menus, icon bars, search mechanisms, history lists, bookmarks, and indexes. Each access device links us to a recognized, named object. But below that level we have a labyrinth of connections between objects not all of which are named in an official access mechanism; for instance, clicking one part of an image offers us a zoomed-in display of that quadrant,which is not itself listed in a table of contents, or list of figures (Lincoln and Monk [16]). And because one object calls out to another, as a word yearns for its definition, object orientation facilitates our making many, many links.

But as our organizations begin to drift toward the World WideWeb, which was at first perceived as a simple extension of our online publishing, our information systems must undergo a sea change. An orientation toward objects, though still extremely useful at the local level, begins to give way to broader perspective, in which we see ourselves as active agents in a vast network exchanging information objects—somewhat the way buyers and sellers swap currency, services, and products, as they build an economy.

The Pressures for Change

At some point, as more and more information goes electronic, upper management experiences a primal urge for massification: all the organization’s information, they decide, should be presented on the new CD, on the Web site, and in the customer support site on a commercial provider. Often, technical communicators are called upon to "organize" and "deliver" this vast amount of information, including much that we never created, or knew about.

And of course, once material appears on the Web, users expect it to be up to date. Nothing kills their interest in a Web site faster than seeing last month’s press release on the welcome page. And if users don’t come back on repeated visits, our organization may lose some of the savings anticipated with the Web site, when the users clog the customer support phone line instead. So we have to begin updating more frequently.

And users now take electronic mail for granted. They expect to be able to send us an email message, or post a message on a bulletin board, and get an answer with 24 hours. Who’s going to answer these questions—an engineer who never speaks, or a technical communicator?

Through forms, we may also have to provide users with information from various organizational databases we may never have used. Where do we place these forms? How do we organize the results of queries? How do we make it possible for users to link from the resulting list to detailed information about a topic?

To improve practice, some managers may also want to post internal guidelines, checklists, templates, sample documents for staff to use. How are we going to organize these, and where do we place the "Keep Out" sign to exclude the public?

Management has also begun to recognize that a critical resource, the information each employee has developed to do his or her job, sits out on various personal computers, servers, and hard disks around the company, usually in "unstructured" form, that is, not in a database or spreadsheet, but in some loose form such as a letter, memo, or trip report. To make the useful pieces of that information available to other workers, we may be asked to connect our carefully created information with some form of corporate information system, in which anyone can post a document simply by filling out a form, and placing the document into a server somewhere.

So increasingly technical communicators must respond to the need to publish massive amounts of information (far more than any one person or team could ever read), while being tasked to update it continuously, and some of us are being asked to take over answering email messages about our "special" topics, while creating a way for users to get instant access to corporate databases, and, at the same time, organizing an increasing amount of unstructured internal materials for staffers, not open to the public. As Koch remarks:

Managing the content of a large corporate World Wide Web site is like contending with the jumble of blips on an air traffic control radar screen: It’s complex, crowded, and very time sensitive. [21]

Environments like these may force us to redefine our work, relaxing our grip on individual structures, turning our attention from writing particular documents, and organizing large assemblages of interactive objects, to guiding the flow of an enormous river of information, standardizing access mechanisms, and responding to individual requests, while continuing, at other times, to be authors and organizers.

At a local level, we find, object orientation and the neat modeling of individual packages, or documents as we used to call them, can still improve our work—wherever we ourselves have complete control over the information.

But as we move toward the global Web, we face a phase transition, in which our whole department’s output becomes just one node on our organizational Web site, and our entire corporate information system becomes just another node on the Web. We ourselves must frequently become users poling along in the flow of information, as well as authors, and organizers.

To understand our new position, we must recognize that we are indeed being asked to structure information of an unprecedented degree of complexity. If we multiply the number of documents we are responsible for by W, increasing the number of actual information objects by E, and thereby raising the number of hot spots and targets by B, what formula can calculate the number of potential paths among links in our site? To keep our balance, we may need the advice of thinkers in the emerging discipline of complexity theory, a field that has brought together thinkers from many different disciplines, each trying to explain what happens when a number of small systems, like water molecules, merge together to form something much bigger, such as a river [22]-[31]. The molecules are said to undergo a phase transition, becoming parts of a new, complex, and adaptive system. That new system is so much bigger in scale that we witness emergent properties—liquid behaviors and fluid functions that could never have been foreseen in the earlier phase. As technical communicators we have already been through several phase transitions, and we are experiencing another right now.

Recognizing Phase Transitions

Over the last twenty years, changes have rippled through technical communication in a series of phases. In each phase we like to imagine we are looking at a stable system. But along comes an apparently small event, and, thanks to positive feedback, that tendency intensifies, and gets locked in; we see one path becoming the way many people are going, and almost without our noticing it, the system undergoes a phase transition. What emerges is a much more complex, unpredictable, changeable organism, that seems to organize itself. Think back on a few phases that technical communicators have experienced in the last two decades.

• Phase One: An individual writer puts together information in a traditional structure, described in a styleguide, and modeled in many similar manuals, typing several distinct drafts of a single document, which is eventually printed on paper and distributed. When word processing appears, it offers a way of doing all this work much more efficiently, and in some cases, more elegantly. This new tool is adopted wholesale, but at first, no one recognizes how much our work has changed. Almost without thinking, we are building up an archive of electronic files, throughout the organization, and we are learning how to exchange these files, modify them collaboratively, and recombine them for various purposes. But we still think primarily in terms of individual documents, or groups of documents.

• Transition: Hypertext is born. A small idea, at first, championed by Vannevar Bush [32], Ted Nelson [33], [34], and others, enabled by several obscure programs, publicized by Bill Atkinson’s HyperCard on the Macintosh, hypertext came into its own when new tools made it much easier for technical communicators to create interactive documents, such as online help [35]. From that seed grew a world of electronic documentation. As Prigogine points out, in such circumstances, positive feedback reinforces a tiny tendency, so that an effect that is at first quite small becomes magnified, rather than dissolving, and swells like a mild tropical breeze becoming a hurricane [36]. Monod, reflecting on early DNA discoveries, points out that the same process seems to happen when seeds and embryos transform themselves into living creatures, through positive feedback [37]. As a result of this hypersurge, we have seen an explosion of online documentation, online help, CD-ROMs with all the electronic versions of the books from one company. We have gone through a phase transition, and as the system has reorganized itself, we have discovered emergent properties, that is, functionality that was not there before, or could hardly be imagined. The main new function is, of course, the ability to establish links from one piece of information to another, electronically, so that the user can jump from here to there, following a sequence of jumps we cannot anticipate.

• Phase Two: Now all the writers on the team are busy creating a series of information objects that will link up with each other, to form a single hypertext, online. We still feel that our team controls the entire information system, but we no longer assume a reader begins at the beginning and reads through our documents in order; we plan for links, we enable jumps from one spot to another (individual segments of a path), and although we would like to offer guidance, we cannot constrain the users’ experience, because they put together their own set of segments, making their own paths.

• Transition: Now that every document in the organization is electronic, and an increasing amount of documentation is interactive hypertext, along comes the Web, and management decides to put enormous amounts of information on the Web, just because. Again, emerging from a tiny utility in a laboratory to the current World Wide Web, the pace of acceleration indicates how a small event can be magnified through positive feedback to completely transform a system. As technical communicators are called upon to put everything they have ever created upon the Web, they find they are asked to do much more: to interact directly with customers, to facilitate email exchanges with subject matter experts, to put up pages created in other departments. In effect, the corporate Web site has taken us through another phase transition, and we are beginning to see the emergent properties characteristic of the next phase. The most striking of these properties is the increasing opportunity to interact with dozens, hundreds of other people, to engage more directly than ever before in an electronic conversation.

• Phase Three: Each writer becomes an active participant in a large, complex, interactive system known as the Web, carrying on a conversation with many other people (subject matter experts, customers, casual visitors) by exchanging multiple interactive objects, including email, in an open structure that is constantly growing, evolving, adapting. The writer may still be doing some Phase One work, creating discrete, individual documents, and some Phase Two work, assembling complex hypertexts such as help systems out of hundreds or thousands of individual objects, such as procedures, definitions, screenshots. But increasingly, the writer must pour all that material, and a lot more, onto the Web, transforming a library of books into a true network of information objects, going beyond simply providing links to improving search engines, offering meaningful filters, perfecting personal query mechanisms, pushing selected updates rather than waiting for users to ask for them, and responding promptly to messages. The nature of the rhetorical exchange, too, has been transformed from a distant relationship between producer and user to a rapidfire and constant conversation, in which we are tightly interconnected. In fact, interconnectivity and conversation are two of the system’s most striking emergent properties.

Understanding our role in a complex, emerging, interactive system.

Your organization may be anywhere from Phase One to Phase Three, but given the speed of transformation, you should probably begin pondering how you will structure the interactive information you post on the Web, as a complex system. Whenever a system undergoes a phase transition, new concepts become significant as descriptions, explanations, or metaphors. A leading theorist of complexity, Holland, offers a number of concepts that may help us understand what he calls "complex adaptive systems" [22]

Building Blocks

Originally, we conceived of a passage or chapter as a unit to be written as a coherent whole, a kind of miniature document; we knew it contained individual paragraphs and headings, but saw those as parts of an accumulating whole. Later, as we made the transition to hypertext systems, we transformed these elements into objects that could interact, electronically, with each other; we put together collections of these objects in packages known as help systems, databases, or CD-ROMs. And now as we move all our information onto the Web, we ransack all previous packages for objects to link to other objects, and develop new structures built on a)earlier documents b)the objects themselves c)new packages of those objects, never before imagined.

In essence, the individual products of one phase become building blocks for the next. And once we enter a new phase, we start rearranging its building blocks to adapt to changing environments, other people, cooperative endeavors, and competitive pressure. Just as the brain keeps reenforcing some connections, and abandoning others, for instance, your evolving Web site tends to strengthen the most visited pages, while ignoring, and eventually dropping the least visited pages.

Agents

As a technical communicator, you are an active agent, a participant. Any complex system evolves from the interaction of a great many "agents." For instance, an economy is created by buyers and sellers; nerve cells knit together to create a brain; species jostle together to form an ecology. Other agents in our evolving system include subject matter experts, other folks in your organization, visitors, customers, users; also, the owners of sites, such as departments, whole organizations, entire trade associations, governments. New agents are constantly pouring into the system, and agents who visited earlier come for new reasons, looking for different information. You are cooperating with many other agents, and competing with others.

As an agent, you dwell in an environment defined by your interactions with all these other agents in the system, and because of the shifting population and their changing interactions, the environment itself can never be said to be at rest, or in equilibrium. You are never finished. In the old days, when you sent a book off to be printed, you could look forward to a few months not thinking about that subject, as you turned to other projects. No longer. You post it on the Web in the morning and by the afternoon you have a dozen emails asking follow-up questions.

Dispersed Control

No one is in control. In the brain, for instance, no one neuron orders the others around. As a technical communicator, then, you may have a great deal of control over an individual document you post, and some control over others you must publish, but you have almost no control over a lot of the material on your site. The number of pages grows, and the links between them expand, without your doing much except allowing growth to happen.

Essentially, the control is dispersed. The routines you and others have worked out to allow cooperation shape the way the system functions today; but your efforts to best the competition may change the way the system works. Some changes get locked in and accelerate; from a small beginning, enormous effects emerge.

As a result, the system as a whole seems to organize itself. Yes, there are dozens, thousands, even millions of agents, working at various aspects of your system, but because of the very scale of the operation, even a Webmaster is not in charge. An analogy: in New Mexico we have a Ditch Master who makes sure that every farmer is getting a fair share of the water siphoned off the Rio Grande through ancient ditches; and a River Master, in charge of the river itself; but neither controls the rain, snow, or drought.

Multiple Levels

Any way you look at the evolving system, you see many levels--more than you have ever worked with before. Just as individual writers must work together with others to form a team to create online help, now teams from various departments must coordinate somehow, to assemble a coherent Web site. As they do that, their artifacts--the reports, tables, brochures, and databases--pile up, in more levels than most books or help systems.

Niches

The system offers a variety of niches, each of which can be exploited by an agent who is particularly well adapted to discover, enlarge, and exploit that particular area. The agent may be an individual with a unique idea, or a corporation whose employees have spotted an unusual opportunity.

Anticipating the Future

The system anticipates the future, because it embodies assumptions about what people will need, and want, tomorrow, and as those change, its model of the world evolves. Like an IF-THEN subroutine, the planning embedded in the system anticipates certain circumstances, and, if those occur, responds. But of course the world does not always respond as anticipated. Essentially, the system tests its assumptions, and with varying degrees of sensitivity, reacts by changing its game plan.

Arthur, a complexity theorist {23], [24], who has shown how the economy can be seen as a complex, growing system (rather than a machine that quickly reaches equilibrium, as earlier economists liked to think), asks, as quoted by Waldrop,

What is our relation to a world like that? Well, we are made of the same elemental compositions. So we are a part of this thing that is never changing and always changing. ...If you quietly observe the flow, realizing that you’re part of it, realizing that the flow is ever changing and always leading to new complexities, then every so often you can stick an oar into the river and punt yourself from one eddy to another. [30]

That’s it? Actually, in this environment, that’s a lot. Just observing the system and noting the way the rules are changing takes a lot of sensitivity. Arthur compares the effective move to a blow in the martial arts. "This is a powerful approach that makes use of the natural nonlinear dynamics of the system. You apply available force to the maximum effect. You don’t waste it.... The idea is to observe, to act courageously, and to pick your timing extremely well." [30]

Arthur also cautions against trying to optimize your situation, particularly if that means abandoning some of your options.

You go for viability, something that’s workable, rather than what’s ‘optimal.’ A lot of people say to that, ‘Aren’t you then accepting second best?’ No, you’re not, because optimization isn’t well defined any more. What you’re trying to do is maximize robustness, or survivability, in the face of an ill-defined future. And that, in turn, puts a premium on becoming aware of nonlinear relationships and causal pathways as best we can. You observe the world very, very carefully, and you don’t expect circumstances to last." (Quoted, Waldrop, [30]

At a local level, we may continue to create occasional documents, and to assemble distinct hypertexts out of interactive objects, but increasingly we will be called on to circulate those documents and objects as part of an intense conversation with many other people. As Killingsworth and Rosenberg note in their discussion of icons, our work goes way beyond dialog [38] We set up the conditions for chatting, exchange linked objects, and interact, now as individual authors, then as collaborative organizers, and finally as actively interconnected users.