torus6.gif (1371 bytes)

 

cctext.gif (2384 bytes)

                                        
Services Tips Theory WebPoems Workshops Books Articles Lisa Jonathan

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

Complexity Theory as a Way of Understanding our Role in the World-Wide Web

Speech at 45th Annual Conference of STC, May, 1998.

Proceedings of the 45th Annual Conference. Arlington, VA: Society for Technical Communication. 1998. 207-209.

by Jonathan Price

Complexity theory offers a way of understanding our role within the World Wide Web. Postulating a rhetorical object based on object-oriented analysis and design, we can harness a number of ideas from complexity theory to gain a new perspective on the Web.

This paper reviews a number of complexity ideas that may help technical communicators grapple with the exponential growth in the volume of inter-related and interacting rhetorical objects on the Web, viewing the rhetorical situation as the result of the law of increasing returns, which has brought us through a phase transition to a new environment, with its own emergent properties, creating new roles for writers, and new work for managers.

Agents and Objects

Increasingly, technical communicators are being asked to publish more material on the Web, edit information from other groups, respond to email, chat with users online, and create a process for the delivery of information we have never before been responsible for. We may still be responsible for writing manuals and online help systems, but more and more we are also being asked to create web sites, act as gatekeepers for the information coming from many departments to be published on the web, and perform the roles of host and chief conversationalist for our organization, bringing together subject matter experts and users, facilitating a process rather than creating distinct products such as books and CD-ROMs [1], [2].

In talking with other technical communicators, I hear several interrelated questions coming up with increasing intensity:

  • What are we going to have to do to keep up with our competitors on the Web?
  • Why do Web conventions, tools, and links keep changing so often?
  • How can we hope to organize and control the developing hurricane of material we are asked to put up on our organization’s Web site?
  • Is anyone really in charge of the Web—or our own Web site?

Complexity theory offers some surprising perspectives on this situation. Complexity theory is not yet a single, unified approach, but rather a set of ideas developed in such disparate fields as economics, biology, neurosurgery, anthropology, and artificial life [3]-[9]. Individual researchers in each of these fields have begun developing theories specifically to cope with situations that are too complex to explain by earlier principles. Perhaps complexity theory can help us, as technical communicators, understand the Web world in which we find ourselves.

In this paper, I pinpoint a few key concepts in the evolving theory of complex, interactive systems, showing how I think they may clarify what is happening as we create Web sites, update them, transform them, and link to hundreds of other web sites around the world.

In a complex interactive system, agents perform relatively simple actions for their own purposes. In this scenario, we are agents, creating our corporate or department site, filling it with content, and then constantly changing the interface and content. From these activities, performed by agents like us around the world, the Web evolves.

We assemble the building blocks of our site-what I call rhetorical objects such as pages, image maps, paragraphs, and links. Each of these chunks resembles an object as seen by object-oriented programmers [10]-[15], because each:

  • Is an instance of a general class, inheriting its properties. For instance, following your styleguide, you create each step in a procedure in the same way (starting with a number, then a verb in the imperative voice, and a single action, say). When created according to the rules, then, each step is a member of the class Step. The idea of classes helps us define the pure form of an object, the ideal, we might say, to which each member should aspire. (Knowing the class definition, or standard, helps us revise poorly written documents more efficiently, because we know what should be there).
  • Has a responsibility. As rhetorical objects, the elements we create must answer a particular type of question from the user. For instance, a Step object answers the question, "What do I do next?"
  • Has a unique identity. In our terms, each object has its own content; you cannot arbitrarily substitute one object for another, without making your document a mess.
  • Sends requests to other objects, and receives requests from them. In our world, such requests are often very simple: a highlighted word, when clicked, sends a request to its glossary definition, saying, "Please display yourself."
  • Has attributes, or information about the object itself, such as date of creation, owner, subject or keywords.
  • Performs operations on its own data, such as displaying it when asked.
  • Changes states, as when going from "hidden" to "displayed."
  • Has relationships with other objects, especially when it forms a component of another object, or contains other objects as its components. (This aspect of rhetorical objects is extremely important because it allows us to define exactly what components should go into a standard object, in what order, which are optional and which are required, and in what numbers. For instance, we can define a Procedure object to contain a title (one required), introduction (one, optional), steps (one required, up to 7 optional, no more than 7), explanations (optional, one to five per step). Then, as developmental editors, we can tell when an object is not built correctly, and we know where to make the additions, or subtractions.
  • Can be re-used in a new design, because we know what to expect. If an object has been correctly built, we can collect all objects of that type automatically, and without rereading or rewriting, drop them into a new structure. (Of course, if objects have not been written correctly in the first place, they will not be reusable until revised).

 

The Web Emerges

Complex interactive systems like the Web give evidence of following the law of increasing returns, the tendency in such systems for a trend to accelerate, and dominate the entire system, instead of settling back into a corner, as in traditional economic theory, which predicts gradually decreasing returns [16]-[18]. This accelerating tendency leads to path dependence, that is, an eventual lock-in to a particular technology, approach, or system, even if that is not the most efficient or productive. For example, in creating our Web sites, we may find similar tendencies pressuring us to follow the latest trends in Web design just because so many of our users have gotten used to them.

Phase transitions take place when the objects within a system multiply exponentially, moving the system from one phase to another. Clearly we are witnessing an enormous growth in the number of rhetorical objects on the Web, and that growth has taken us to a new level, in which we see emergent behaviors, that is, behavior we did not see before, when we faced less volume. Examples include building chat systems into our documentation, regarding email as a way to develop new materials for our users, changing our role from sole creator to editor, or facilitator.

Control is dispersed, in such an evolving system. No one person is in charge, no company, no consortium really dictates what appears on the Web. It appears to have a life of its own. It constantly probes the edge of chaos, risking complete anarchy, but, as a result of billions of individual decisions by all of us agents, the Web keeps on adapting to the present, changing in a way that mimics a conscious lifeform growing from cell to tissue to organ to body.

Our Changing Roles

In such an emerging, complex, interactive system, our roles are changing, as we adapt to this new environment:

  • We may still be creating some individual packages of information, but increasingly we will be orchestrating the flow of information, pulling it from many new sources (such as users, subject matter experts, and even our own Information Technology group).
  • Our writing moves toward shorter pieces, created on the spur of the moment, pulling together prepared chunks (reusable objects) for purposes we could not have imagined five years ago, such as running email exchanges with users, hosting newsgroups, adding to databases not documents.
  • Our focus turns away from delivering a product (the document) by a particular date to managing a constant process of updates.
  • When we edit, we may find we are focusing on Level Three editing (larger issues of structure and purpose), less on Level Two (consistency and coherence within the prose), and just skimming for Level One accuracy and correctness [19]-[21].

In turn, managers are going to need to reconsider the way they assign staff to projects, and monitor work. For example, you may need to assign one person to a particular subject area, and make that person responsible not just for updating the information online, but also for communicating with users, subject matter experts, and other staff such as salespeople; the "writer" is now a hub for information about that topic. Similarly, you may have to measure productivity by the number of emails responded to, number of postings to the bulletin board, number of updates, rather than on-time delivery of a particular manual. Time frames shrink from months to weeks.

From the perspective of complexity theory, then, the future looks, well, complex, but not as overwhelming as it would be if we were to imagine that in such a world we would still need to act the way we did before, creating lots of individual documents (both hard copy and electronic), plus doing all the Web stuff as a kind of extra. No, just as we have moved away from paper documentation as our primary mode of delivery, we will move away from a document-centered view to one that sees individual objects as our work focus, and the Web as an extended conversation in which we actively participate.

References

(1) Price, J.R. "Introduction: Special issue on Structuring Complex Information for Electronic Publication," IEEE Transactions in Professional Communication, 40:2 (1997), 1-9.

(2) Price, J. R. "Using Complexity Theory to Understand What’s Happening to Technical Communication," 1997 IEEE International Professional Communication Conference Proceedings, 17-27.

(3) Bak, P. How Nature Works: The Science of Self-Organized Criticality. New York: Springer-Verlag, 1996.

(4) Casti, J. L. Complexification: Explaining a Paradoxical World Through the Science of Surprise. New York: Harper, 1994.

(5) Coveney, P. & Highfield, R. Frontiers of Complexity: The Search for Order in a Chaotic World. New York: Fawcett, 1995.

(6) Cowan, G. A., Pines, D., & Meltzer, D. (Eds.). Complexity: Metaphors, Models, and Reality. Volume XIX in the Santa Fe Institute Studies in the Sciences of Complexity. Reading, MA: Addison -Wesley. 1994.

(7) Holland, J. H. Hidden Order: How Adaptation Builds Complexity. Reading, MA: Addison-Wesley, 1995.

(8) Lewin, R. Complexity: Life at the Edge of Chaos. New York: Macmillan, 1993.

(9) Waldrop, M.M., Complexity: The Emerging Science at the Edge of Order and Chaos. New York: Simon and Schuster, 1992.

(10) Fingar, P. The Blueprint for Business Objects. New York: SIGS, 1996.

(11) Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison Wesley, 1995.

(12) Jacobson, I. The Object Advantage: Business Process Re-Engineering with Object Technology. Reading, MA: Addison-Wesley, 1994.

(13) Martin, J. and Odell, J.J., Object-Oriented Analysis and Design. Englewood Cliffs, NJ: Prentice Hall, 1992.

(14) Taylor, D., Object-Oriented Information Systems: Planning and Implementation. New York: Wiley, 1992.

(15) Yourdon, E., Object-Oriented Systems Design: An Integrated Approach. Englewood Cliffs, NJ: Prentice Hall, 1994.

(16) Arthur, W.B., "Competing Technologies, Increasing Returns, and Lock-in by Historical Events." Economic Journal, 99 (1989), 116-131.

(17) Arthur, W. B. "Positive Feedbacks in the Economy," Scientific American (February, 1990), 92-99.

(18) Arthur, W. B. "Increasing Returns and the Two Worlds of Business." Santa Fe, NM: Santa Fe Institute, 1996. (Reprinted in Harvard Business Review, July 1996).

(19) Buehler, M.F., "Defining terms in technical editing: The levels of edit as a model," Technical Communication, 28: 4 (1981), 10-14, 1981.

(20) Bush, D.W., and Campbell, C.P., How to Edit Technical Documents. Phoenix, AZ: Oryx, 1995.

(21) Anderson, S., Campbell, C.P., Hindle, N., Price, J. R., Scasny, R. "How Editing a Website Differs from Editing a Printed Document." IEEE Transactions on Professional Communication, in press.

 

 

Services/Tips/Theory/WebPoems/Workshops/Books/Articles/Lisa/Jonathan
Copyright 1998-2001 Jonathan and Lisa Price, The Communication Circle
Return to our site at http://www.theprices.com/circle
Email us at JonPrice@AOL.com