A Project of
|Guidelines||Rants||Patterns||Poems||Services||Classes||Press||Blog||Resources||About Us||Site Map|
Structuring complex interactive information
Introduction to special issue of IEEE Transactions on Professional Communication, July 1997. 69-77.
To improve the structure of complex information when it is to be presented electronically, we 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, we 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 writers, editors, and managers of all that content.
Increasingly, 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.
We may be forgiven for feeling a bit dazed by the sheer complexity of the structures we assume we must build.
For most of us, the very idea of structure assumes stasis is possiblea 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 dont usually perceive those messages, and, if we are just building one isolated arch we probably dont 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 -. 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 designers 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  . 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  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 Ive experienced it, working with teams to adapt legacy information for electronic delivery.
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 , . 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 .
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
In many legacy documents, such an editorial analysis reveals many structural problems. For instance,
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 . (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" . 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 .
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 . 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 . 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 thats 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 , , .
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 . 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 ). 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 objectssomewhat the way buyers and sellers swap currency, services, and products, as they build an economy.
At some point, as more and more information goes electronic, upper management experiences a primal urge for massification: all the organizations 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 months press release on the welcome page. And if users dont 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. Whos going to answer these questionsan 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:
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 workwherever 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 departments 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 -. 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 propertiesliquid 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.
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.
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" 
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  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.
 J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice Hall, 1991.
 J. Martin and J. J. Odell, Object-Oriented Analysis and Design. Englewood Cliffs, NJ: Prentice, 1992.
 D. Taylor, Object-Oriented Information Systems: Planning and Implementation. New York: Wiley, 1992.
 E. Yourdon, Object-Oriented Systems Design: An Integrated Approach. Englewood Cliffs, NJ: Prentice, 1994.
 B. Webster, Pitfalls of Object-Oriented Development. New York: Holt, 1995.
 E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995.
 J. V. White, Great Pages. El Segundo, CA: Xerox Serif, 1990.
 R. C. Parker, One-Minute Designer. Indianapolis, IN: Que, 1993.
 K. H. Woolsey, S. Kim, G. Curtis, VizAbility. Boston: PWS, 1996.
 J.T. Hackos, M. Hammar, and A. Elser, "Customer partnering: Data gathering for complex online documentation," " IEEE Transactions on Professional Communication, vol. 40, No x, pp.xxxx
 B. Travis and D. Waldt, The SGML Implementation Guide: A Blueprint for SGML Migration.Berlin: Springer-Verlag, 1995.
 R. C. Turner, T.A.Douglass, and A. J. Turner, Readme.1st: SGML for Writers and Editors. Upper Saddle River, NJ: Prentice Hall, 1996.
 C. Madigan, M. Silver, and S. Wilson, "Lessons learned prototyping an SGML-based computerized document management system," " IEEE Transactions on Professional Communication, vol. 40, No x, pp.xxxx
C. Strickland, "New media publishing: Editing in convergence," " IEEE Transactions on Professional Communication, vol. 40, No x, pp.xxxx
 M. Harmison, "Creating electronic documents that interact with diagnostic software for on-site service," " IEEE Transactions on Professional Communication, vol. 40, No x, pp.xxxx
 J. Lincoln and D. L. Monk, "Displaying scientific graphics on computer, " IEEE Transactions on Professional Communication, vol. 40, No x, pp.xxxx
 P. Goldie, "Using SGML to create complex interactive documents for electronic publishing," " IEEE Transactions on Professional Communication, vol. 40, No x, pp.xxxx
 C. Mok, Designing Business: Multiple Media, Multiple Disciplines. San Jose, CA: Adobe, 1996.
 R.S. Wurman, Information Architects. Zurich, Switzerland: Graphis Press, 1996.
 T. Rauch, P. Leone, and D. Gillihan, "Enabling the book metaphor for the World Wide Web: Disseminating online information as dynamic Web documents," " IEEE Transactions on Professional Communication, vol. 40, No x, pp.xxxx
 C. Koch, "Authors, authors, everywhere," WebMaster, vol. 1, no.7 (January), pp. 36-40, 1997.
 J. H. Holland. Adaptation in Natural and Artificial Systems. Ann Arbor: University of Michigan Press, 1975.
 W.B. Arthur, "Competing Technologies, Increasing Returns, and Lock-In by Historical Events." The Economic Journal 99, pp. 116-131, 1989.
 W.B. Arthur. "Positive Feedbacks in the Economy," Scientific American (February), pp. 92-99. 1990.
 S.A. Kauffman. "Antichaos and Adaptation." Scientific American (August), pp. 78-84, 1991.
 S.A. Kauffman, Origins of Order: Self-Organization and Selection in Evolution. Oxford: Oxford University Press, 1992.
 S.A. Kauffman, At Home in the Universe: The Search for the Laws of Self-Organization and Complexity. New York: Oxford, 1995.
 P.W. Anderson, K. J. Arrow, and D. Pines, Eds., The Economy as an Evolving Complex System. Santa Fe Institute Studies in the Sciences of Complexity, vol. 5. Redwood City, CA: Addison Wesley, 1988.
 R. Lewin, Complexity: Life at the Edge of Chaos. New York: Macmillan, 1992.
 M. M. Waldrop, Complexity: The Emerging Science at the Edge of Order and Chaos. New York: Simon and Schuster, 1992.
 J. L. Casti, Complexification: Explaining a Paradoxical World Through the Science of Surprise. New York: Harper, 1995.
 V. Bush, "As we may think," Atlantic Monthly, July 1945; Reprinted in Literary Machines, Palo Alto, California: Project Xanadu, pp. 1/39-1/54, 1987.
 T.H. Nelson, Literary Machines. Palo Alto, CA: Project Xanadu, 1987.
 T. H. Nelson, Computer Lib/Dream Machines, Revised edition. Redmond, WA: Microsoft Press, 1987.
 J. Nielsen, Hypertext and Hypermedia. Boston: Academic Press, 1990.
 I. Prigogine, From Being to Becoming: Time and Complexity in the Physical Sciences. San Francisco, CA: Freeman, 1980.
 J. Monod. Chance and Necessity. New York: Knopf, 1971.
 M.J.Killingsworth and M.E. Rosenberg, "The icon as a problem in cognition and social construction: Complexity and consensual domains in technical rhetoric," IEEE Transactions on Professional Communication, vol. 38, no. 4, pp. 216-227, 1996.
Writing that Works!