This paper is an attempt to explore how reader-response criticism and the overall approach to using rhetoric in technical communication may be impacted by the large amount of technical documentation moving to the Web. The discussion focuses on three main areas: moving from the “reader” to the “user” in online documentation; the value of plain language style in this medium; and how Web delivery seems to be bridging the gap between user interface (UI) text and help documentation. I shall explore these areas in an attempt to clarify whether the publication of technical documentation on the Internet negates the rhetorical approach to technical communication and how or if Web delivery impacts the reader-response view that users play a significant role in creating the meaning of a text.

The presentation of text on a computer screen begs the question: are our readers now users? The audience’s engagement with the material is no longer just a mental one – readers are physically interacting with the content on the screen. Whether through simple navigation, interactive tutorials, answering questions, or performing searches to get them to the desired content, readers are using the computer hardware, software, and even the text to accomplish what they set out to do when they enter a Web site. As we’ve discovered through usability testing and other data-gathering techniques, users are less inclined to actually read text on a computer screen (they tend to skim or scan instead). For this reason, text needs to be as clear and concise as possible, which may give plain language style a renewed importance in technical communication as more and more documentation moves to the Internet. This does not, however, negate the value of rhetorical approaches to online writing. It is my intent to illustrate how plain language style can and should be incorporated with rhetorical approaches to technical writing on the Web. The overall experience of a site plays a major role in its success. On the Web, more than anywhere else, the lines differentiating UI text from help or support documentation are blurring. Authors and designers are finding ways to integrate help content into the actual UI. It is worth discussing what impact this new hybrid may have on general reader-response theory in technical communication.

In the most basic of terms, reader-response theorists assert that the meaning of a text does not lie within the text itself at all. Instead, this meaning is derived from a variety of sources: the reader; the author; the role-play that takes place between the “mock” reader and the text; the role-play that takes place between the mock reader and the author (either the actual author or an author role that is created by the actual author); or an interpretive community of readers who collectively assign meaning to a text. Depending on the theorist, one source or a combination of sources may hold more interpretive value than the others (Ong, Gibson, Coney, Foucault). For the most part, reader-response theorists rely heavily on rhetorical writing technique to ensure the reader is persuaded to engage in this role-play that is so necessary to the derivation of meaning. This technique may include usage of a familiar tone, rhetorical devices such as metaphors, colorful adjectives, expressive and descriptive text, and scenario-based writing (where a scenario considered to be appropriate to the desired role-play is established and the text is written to create and perpetuate that scenario).

In this discussion, “online documentation” refers to two very specific technical communication products:

1. a user manual and/or help documentation for a software product
2. a science or technology report, published to convey research results

Of course many other forms of technical communication exist on the World Wide Web today, but the focus of this discussion is better served by limiting it to two products which we can clearly visualize both in print and online. It is also important to note here that the majority of this discussion pertains to the text in online documentation, and items such as visual design or navigation are referred to only in relation to the use of text.

Readers or Users

In her article “Technical Readers and Their Rhetorical Roles,” Mary B. Coney presents a categorization of readers, ranging from readers as passive vessels, reading only to be informed or educated, to the complete opposite, “readers as makers of meaning” (61). At a point closer to the ‘passive vessel’ end of this spectrum, she defines “readers as users.” This definition is limited to readers who use computer equipment or software and are seeking information or help on those items (59). Coney’s definition is not akin to the “user” I am considering in this document. Though her article provides an insightful discussion of different philosophical approaches to the roles that readers play in technical writing, Coney clarifies that her list of roles is not complete, and that the roles she has presented often overlap, even within the same document (61-2). I would therefore humbly submit one more entry for her taxonomy. Her article is valuable in providing us with a clear roadmap of the different approaches to audience in technical communication, but there is no discussion of readers as users of the text. Users who are seeking information on the Web are, by default, more interactively engaged with the text. Indeed, “the rhetorical principle of role playing is given new vitality as it moves from the printed page to a Web page” (Coney and Steehouder 6). However, whether these users are more engaged than readers of a print document in creating the meaning of that text is not clear. This question will be explored further throughout this paper.

Further evidence that readers of online documentation could be considered users of text is found in Janice C. Redish’s chapter “Understanding Readers” in Techniques for Technical Communication. Though she is referring specifically to workplace documentation, items from this category are well within my limited scope for this discussion: instruction manuals, reports of an experiment, etc. Redish doesn’t limit her definition of users to those reading online text, she asserts that readers of all technical documentation are users: “As a technical communicator, you want readers not just to read the document, but to use it” (4).

Yet another reason why we should place readers of online documentation in the category of users is the value found in empirical evaluation of a Web site and its content. Given the enormous amount of information and seemingly infinite number of Web sites on the Internet today, an empirical evaluation of a Web site’s text and its users grows in significance. If users cannot or will not engage with the content they see presented on a Web site, their inclination to give up or move to a different site is extremely high. This abandonment could have visible financial impact on the publisher of the Web content, either in the form of increased support calls (the user refuses to or cannot help herself), or in the complete loss of a customer. Writers, even as reader-response theorists, must take into consideration an empirical approach to online documentation. It is no longer a simple question of what sort of meaning the reader assigns to the text, or how she interprets it. The real question now, the one that determines the ultimate success of the document as it is published on the Web, is whether or not the reader can use the text.

For the remainder of this discussion, what I view as users of online documentation are referred to interchangeably as both readers and users. As technical communicators writing for the Web, we should approach our content with the understanding that the receivers of this content are users who will either use or reject our work.

The Value of Plain Language

Such freedom on the part of the user makes it even more important for those of us creating content to be mindful of the style and language in which it is ultimately presented. At the time that Merrill Whitburn and his colleagues wrote the article, “The Plain Style in Scientific and Technical Writing,” plain language style was dominant in the field. More than two centuries prior, there had been a backlash against rhetorical devices and ornate style in scientific writing. Scientists and science writers of the post-scientific revolution seventeenth century, who Whitburn terms as “new scientists,” were concerned that the writing style of their time did little to present the facts to readers and they argued in favor of abolishing rhetorical writing from their work. “Nothing was to exist between the mind and its true object; rhetorical devices were not to be an obstruction between observation and description” (351).

As evidenced by the Whitburn article, an argument was now (1979) being made for the return of rhetorical writing in technical communication. Whitburn et al assert that the plain language style touted by and adhered to since the time of the new scientists was insufficient for two primary reasons: the plain style limited audience adaptation in writing (the audience of technical and scientific discourse is frequently not comprised of technical or scientific people); and “the plain style also militates against rhetorical devices that might better enable a writer to communicate his personality” (353).

While current proponents of reader-response theory are not necessarily advocates of flowery language or copious ornamentation, their general approach is rhetorical. Rhetoric’s roots are in the art of persuasion. While some technical documentation is meant to be persuasive, the two types of documentation discussed in this paper generally are not. Yet, even within these two non-persuasive forms of documentation, there is rhetorical quality in how a reader-response critic would approach writing them. Especially for the reasons that Whitburn argues, rhetorical devices should be employed: to allow writing to a specific audience, and to communicate personality through the text. Writers following the tenets of reader-response theory are writing to persuade their users to engage in a role-play, made up of the role presented as the author or speaker, and the role offered to the reader. Depending on the theorist, these roles may or may not be based upon the characteristics of the actual author and the actual reader, they may be fictional roles created purely for the conveyance of ideas or information in a particular text. For a good resource providing a detailed survey of the different reader-response approaches to writing to an audience, see Coney’s 1987 piece “Contemporary Views of an Audience: A Rhetorical Perspective.”

In the years following the publication of Whitburn’s article, the idea of rhetoric in technical communication has progressed and received a great deal of support. Just as Whitburn et al argued to reintroduce some level of rhetorical writing to scientific and technical communication, I would argue that a solid degree of plain language style (inherently non-rhetorical) in conjunction with a rhetorical approach can bring clarity and successful comprehension to text on the Web. The two types of documentation that I call out in this discussion would be well served by the use of non-rhetorical language because they are instrumental in their aims. I would assert that Patrick Moore’s cry for compromise is even more poignant when a technical document’s delivery medium is the Internet:

Some kind of compromise needs to be reached that demonstrates that technical communicators can believe in the existence of and even value of nonrhetorical uses of language without being labeled positivists and without being damned as inhumane or as debasing language and destroying its creativity. (102)

Though Moore does not call out plain language style in his discussion, he does emphasize the value of standardization in instrumental documentation to promote economy, consistency, and accuracy. Standardization requires plain language style. Rhetorical writing, by nature, is difficult if not impossible to standardize: it is inherently creative, expressive, and personal to the writer.

Plain language style in technical communication today has several various definitions, provided both by its critics and its proponents. These variations are too numerous and too detailed to include in this discussion, but Beth Mazur presents a good overview of plain language style, its history, its varying definitions, and its criticisms in her 2000 article “Revisiting Plain Language.” For the purposes of this discussion, the plain language style which I consider valuable to online documentation is defined as follows: language that is clear, concise, and unambiguous, where superfluous words and unnecessary modifiers are omitted, and attention is paid to consistency and accuracy.

Concise language is of significant importance on the Web. If there is anything that usability testing and think-aloud protocols of Web sites and online text has taught us, it is that users generally do not read. They skim and scan, looking for only the pieces of information that interest them directly, help them perform a task, or answer their question. Redish’s statement with respect to all technical documentation holds even more validity on the Web: “Even sophisticated, technical readers of technical documents want to be able to open a document, find what they need quickly, understand it easily, and have the most important information stand out visually on the page or computer screen” (3). Extraneous words and descriptors that have no bearing on the meaning of the document are to the detriment of a Web site. Faced with walls of text, users may simply click away to another site that offers the same information, or give up entirely. In a list of instructions, users want to read as little as possible and simply do what it takes to solve their problem or get them to the next step. In a report of scientific or technical data, the more concisely one can present the results, the more likely the user is to read them thoroughly and therefore understand them. “[Readers] don’t have time to hunt out information that may be hidden under an obscure heading. They don’t have the time to untangle a wordy and convoluted plan” (Redish 3).

Clarity and lack of ambiguity are probably the most important tenets of any plain language writing style. Nowhere is this importance more profound than in instrumental discourse published online. “[When] the purpose of technical communication is rigorously instrumental – to govern, guide, control, and help people execute physical actions – technical writers work hard to make their language unambiguous, unemotional, and strictly denotative” (Moore 108). On the computer screen more than anywhere else, this holds true. Where users are generally skimming or scanning, rather than reading, our obligation to our users is to provide them with language that they can easily and quickly comprehend, whether or not they read the entire contents of document. “Plain language is credited with increased comprehension as well as being preferred by readers” (Mazur 3). Standardization can go a long way in providing this clarity and preventing ambiguity in technical documentation, especially with respect to terminology.

In general, ambiguous use of terms is bad practice in technical documentation. Moore provides examples of where ambiguity in medical documentation has resulted in deaths of patients (110). While I’m sure the same argument could be applied to online documentation (medical, scientific, or otherwise), the more common danger of ambiguity on the Web is specifically related to global acceptance of an online document. Even if the document’s audience is limited to English speakers (which is less frequent as the Web continues to easily cross national and language boundaries), describing an idea, a procedure, or a result without complete clarity and accuracy can have damaging results: the least of which being that the user finds the documentation unusable and never returns to the Web site. Even expressions or colloquialisms that may add personality to a document can be easily misinterpreted by users who do not share the same cultural values and who may not appreciate, or worse yet, be offended by a seemingly harmless analogy or other rhetorical device. Consider the phrase: Leave the entry alone. This is clearly a construction that would be difficult to translate, and difficult to understand for non-native English speakers who do not use the same locution to express this command in their culture.

Consistency in presentation and terminology is also important to users working through instrumental discourse on a Web site. If the user is presented with several different terms in procedural steps for a software program or in the data results of a scientific report, and these terms are used interchangeably to mean the same thing (or worse yet, the same terms mean different things), the user’s comprehension of the work is greatly challenged. Consider the following example[1]:

The inconsistent use of the terms in red not only makes comprehension difficult for native speakers of English, but also increases the complexity (and therefore the cost) of any translation that may be required for this text. Because of the ever-increasing facility of access to online documentation by the global community, authors publishing their content on the Web should be concerned with consistent and unambiguous writing. Implementation of the plain language style and careful application of standardization can help.

However, it is naïve to think that simple application of plain language style to all online documentation will make the material easier to comprehend and more digestible by all users. There is also a danger in misuse or abuse of plain language style, especially when it is not accompanied by some standardization effort and care hasn’t been taken to consider the role of the user and the role of the author vis-à-vis that user. It is not enough simply to make sentences shorter or to eliminate all descriptors just for the sake of economy. According to Redish, in particular readability studies it was found that “shortening sentences and simplifying words in several reading passages led to improved scores on readability formulas but did not make the passages easier to understand” (Duffy and Kabance qtd. in Redish 17). Equally, there is value in taking the time to define the author role and the user role (as encouraged by reader-response theorists Coney and Steehouder) and to be aware of whether these roles are sustained or negated by the text. This is illustrated in Coney and Steehouder’s discussion of “functional relationships.”

[Given] such functional relationships, several aspects of “relationship” have still to be worked out. For instance, if the author persona is defined as a professional and the reader role as a person seeking advice, a strong hierarchy might be established between the roles: the author role being the “higher” one – having authority, taking the initiative; and the visitor role being the “lower” one – dependent, asking, following. But the roles can also be worked out in a more equal way. The expression “sharing what we have learned” suggests that the professional has been as ignorant as the visitor in the past and that both personas are (or were) essentially in the same position. The best relationship, in our opinion, is the one that the real audience will feel comfortable in. (16)

Critics of plain language style or non-rhetorical technical writing fear that using plain language style will result in alienating the audience through a condescending and unfriendly tone. I would argue that this fear is only well-founded in the misuse of plain language style, and that careful implementation of such style along with doing the work to understand the roles (or personas) that must be present in the text will make for a successful document and Web site. Rhetorical writing in online documentation should be used only when necessary to establish and perpetuate the pre-defined user and author personas.[2] The language should be, for the most part, instrumental, especially if the work is meant to limit the different interpretations drawn by readers.

User Interface Text and Documentation

The overall “user experience” of a technical document published on the Web is of primary importance to users successfully receiving, engaging with, and comprehending that document. For our purposes here, I define user experience as the user’s ability to comprehend the layout and navigation of a Web site, to make an insignificant number of mistakes when trying to reach her goal, and to recover immediately if a mistake is made. Ultimately, the user should be able to, with little or no trouble, find what she is looking for and comprehend it fully.

In a software program, such a course of action is guided by user interface (UI) text. If questions come up, or troubleshooting is needed, users refer to Help documentation. Whether this documentation is online, in a printed manual, or in a compiled HTML application that runs along side the software program, it is commonly not a part of the actual UI. In general, UI text is performative, denoting action; whereas documentation is informative.

On a Web site, a large portion of the text presented to the user serves as UI text. That is to say, it is through this particular text that users navigate, make selections, and otherwise interact with the Web site. However, this text is often contained within or in some other way part of text that is not necessarily UI text: it may be informational, procedural, or even ornamental. This is not necessarily effective or even good implementation of text on a Web site, and yet we see it all the time.

Online documentation, when limited to the two types we discuss in this document, can be categorized in one of two ways: linear or parallel. Another way to classify these two categories is “author-driven” or “reader-driven,” respectively.

Linear media is often called author driven because the readers of such documents are restricted to reading forward to the next page or (sometimes) backward to the previous page – constrained to reading the text in the order the author expects. For reader-driven instruction (as it is called in learner control research), we use the terms hypermedia and hypertext. These media are typically called parallel or hyper-based structures because the reader has multiple (parallel) choices on most pages. (Hailey and Hailey 3)

Whether presenting linear or parallel structure in an online document, the author must be sensitive to the needs of the user and the amount of text offered at each point of navigation. The dynamic nature of the Web makes it easier than ever to provide help or supporting documentation in real-time to the user. It is important to note here that this is not the same thing as randomly using informational, ornamental, or procedural text as navigation or interaction elements. Considerate implementation of supporting text alongside or within UI text can go a long way in promoting the user’s success in a given document.

Many mistakes seem to be the result of coordination problems. A typical example is the situation in which users are so busy executing the instructions in a manual that they fail to notice a warning on the screen stating that the computer is still processing an earlier command… Without some support for such coordination problems, the user’s task execution and learning may be at risk. (van der Meij 7)

Providing this immediate access, or “inline” help, can eliminate coordination obstacles that generally plague users who are looking for supplemental or help information that pertains to the UI in which they are working.

If the author and Web designer are able to anticipate where a user might need more information (for example: a glossary definition, explanatory text on a procedural step), technology makes it possible for them to keep this information hidden, so as not to distract from the user’s task or general comprehension, but provide easy access to it through a link, an embedded script, or an on-hover informational tip. Given this reality, authors and Web designers can constrain users to a linear model (to ensure the appropriate or necessary path is followed for comprehension) without limiting the users’ ability to find more information when necessary. Even more possibilities are present if using the parallel or reader-driven model (which is more commonly found in documentation published on the Internet). Users are not only free to choose their direction, but they are able to drill down into as much detail as they, individually, feel is necessary to help them accomplish their task or understand the material.

Sensitive creation of the user and author roles or personas in online documentation is mandatory to the successful integration of UI text and supporting or explanatory text. Without clearly understanding the user or how the user will perceive the author, it is impossible to anticipate where and when the user will need more than just the text that is central to the immediate task. “[In] contrast to most print documents, which are fundamentally linear, hypertexts allow [authors] and users to engage more directly with the content and each other” (Coney and Steehouder 6-7).

Users of online documentation could be, at any point, reading to do, reading to learn, or reading to learn to do (Redish 4-7). The thoughtful process of establishing and writing to the persona of the intended user and author, combined with the technology available on the Web, allows us to create a document where all of these (doing, learning, learning to do) can be accomplished by the user, if necessary. Indeed, referring to G. Fischer’s assessment of a help system, Redish tells us that an intelligent help system would:

• Recognize what the user is doing or wants to do
• Evaluate how the user is trying to achieve a goal
• Construct a model of the individual user
• Decide when and how to interrupt and provide new information (13)

This approach is valuable and applies not to just help documentation or procedural steps, but also to any other form of online documentation.

Concluding Thoughts

Although online delivery of technical documentation does not necessarily negate the overall reader-response approach, it does require a new look at how this approach is implemented. In deciding upon or considering the intended audience, the role is no longer limited to a certain type of reader, but now must include user as well. The physical and mental interaction with an online document goes beyond the simple interpretation of the text.

The tenets of interactive role-playing held by reader-response theorists still can and should be embraced to create successful online documentation. An argument could be made, in fact, for paying even closer attention to this part of the text construction process for Web delivery than for print delivery. Because the Web is itself an interactive environment, and any successful role-playing is more dramatic than that found in printed text (because of the element of physical interaction), careful attention must be given to the development and creation of personas prior to the construction of the text.

The effects of poorly conceived or constructed roles cannot be mitigated by well-designed graphics and navigation, or well-crafted text. If we as users don’t like who we are allowed – sometimes required – to become as we enter a particular site, we are not likely to stay for long. And if the authorial persona we are expected to engage with is offensive, condescending, confusing, inconsistent, or just plain boring, few sites can hold us for long. (Coney and Steehouder 7)

Even though Coney and Steehouder’s discussion is not limited to the two types of documentation I call out at the beginning of this paper, it is valid and applicable nonetheless.

The incorporation of plain language style and standardization in text destined for Web delivery helps to ensure that, while users are deciding whether or not to engage in the roles offered to them, they won’t misunderstand the message, procedure, or results that authors are trying to convey. Although there is clear value in the reader-response approach to constructing the text (establishing personas, scenario-based writing, etc.), the interpretation of meaning in documents such as these should be limited. Plain language style and standardization work well together to limit the ways users interpret instrumental discourse.

Perhaps as the medium for the delivery of instructional and informative documentation changes, authors and theorists should be sensitive to the possibility that audiences (whether they be readers or users) and their needs may change as well. Readers will always contribute to the meaning of a text. It is up to us, as technical communicators, to write as clearly, concisely, and unambiguously as possible to ensure that the reader’s contributions to the text in online documentation are ones that enhance, rather than impede, their ability to understand the results presented or perform the procedures with accuracy. This is by no means a revelation, but it undoubtedly carries greater significance on the Web than it does in print documentation.

Works Cited

Coney, Mary B. and Michael Steehouder. “Role Playing on the Web: Guidelines for Designing and Evaluating Personas Online.” Technical Communication Online 47:3 (2000).

Coney, Mary B. “Contemporary Views of Audience: A Rhetorical Perspective.” The Technical Writing Teacher 14 (1987): 319-335.

Coney. “Technical Readers and Their Rhetorical Roles.” IEEE Transactions on Professional Communication 35:2 (1992): 58-63.

Cooper, Alan. The Inmates are Running the Asylum. Indianapolis, IN: McMillan Computer Publishing, 1999.

Foucault, Michel. “What is an Author?” Textual Strategies: Perspectives in Post-Structuralist Criticism. Josue V. Harari, ed. Ithaca: Cornell University Press, 1979. 141-160.

Gibson, Walker. “Authors, Speakers, Readers, and Mock Readers.” College English 11 (1950): 265-269.

Hailey, David E. Jr. and Christine Hailey. “Hypermedia, Multimedia, and Reader Cognition: An Empirical Study.” Technical Communication Online 45:3 (1998).

Mazur, Beth. “Revisiting Plain Language” Technical Communication Online 47:2 (2000).

Moore, Patrick. “Instrumental Discourse is as Humanistic as Rhetoric.” Journal of Business and Technical Communication 10:1 (1996): 100-118.

Ong, Walter J. “The Writer’s Audience is Always a Fiction.” PMLA 90 (1975): 9-21.

Redish, Janice C. “Understanding Readers.” Techniques for Technical Communicators. Carol M. Barnum and Saul Carliner. New York: Macmillian, 1993. 15-41.

van der Meij, Hans. “Examining the Relationship Between Quality Writing and Quality Reading.” Technical Communication Online 47:2 (2000).

Whitburn, Merrill D. et al. “The Plain Style of Scientific and Technical Writing.” Journal of Technical Writing and Communication 8 (1978): 349-58.

[2] The term “persona” referred to by Coney and Steehouder here, and as used throughout my discussion, is based upon Alan Cooper’s definition provided in The Inmates are Running the Asylum:

Personas are not real people, but they represent them throughout the process. They are hypothetical archetypes of actual users. Although they are imaginary, they are defined with significant rigor and precision. Actually, we don’t so much “make up” our personas as discover them as a byproduct of the investigative process. (124)