On the Impact of Single-Source Publishing in the Technical Communication Industry Richard Rabil, Jr. Texas Tech University December 2008 In the 1980s, desktop publishing changed the way technical communicators work, and in the 1990s, the Internet’s rise to prominence did the same. Now, content management (CM) and single-source publishing (SSP) seem to be having their turn. Far from fads that disappear almost as soon as they emerge, CM and SSP continue to be major points of scrutiny, excitement, controversy, and concern among technical communicators around the world. Whether they like it or not, technical communicators have seen (or will see) their work radically transform. Not only will their tasks change, but people like Anne Rockley (2001) have said a paradigm shift will occur just as it did in the mid 1980s with the revolution of desktop publishing. In fact, Michael Albers (2003) argued that the effects of single sourcing are comparable to the effects of the industrial revolution on preindustrial labor (336), and George Pullman and Baotang Gu (2008) recently concluded, “CMSs are transforming text into data, and the discipline of technical communication will never be the same” (3). In this paper, I briefly define CM and SSP, along with some key associated concepts such as structured authoring and XML. I then discuss the various effects of these technologies and methodologies on three groups: organizations, end users, and writers. Finally, I add my own judgment to the mix of perspectives, focusing on five particular points: • That technical communicators will need to be experts in both structured and unstructured writing • That they will need to be more involved in the design and decisionmaking processes of content management systems • That they must stop viewing technology as a set of neutral tools • That they must learn how to talk and think like strategic entrepreneurs to increase their organizational credibility
Rabil 1
•
That teachers of technical communication will need to stress a tight integration of rhetorical and technological skills
The Basics: Defining Content Management Concepts What is content management? CM refers broadly to the processes or activities surrounding the management of content throughout the information development life cycle. As JoAnn Hackos puts it, “Content management is not exclusively about SGML, XML, databases, or Web publishing… Content management is about organizing, categorizing, and structuring information resources so that they can be stored, retrieved, published, and reused in multiple ways” (9). Another more process-oriented definition is, “The process of managing electronic content through its lifecycle—from creation, review, storage and dissemination to destruction” (qtd. in Clark, 2008, 38). For example, CM activities include inventorying existing content, developing outlines or information models, and searching for and retrieving content. Single source publishing, also simply called “single sourcing,” denotes the automatic reuse of content from one source. Although Rockley simply calls it “writing information once and using it many times” (2001), the Society for Technical Communication’s Single-Sourcing Special Interest Group gives a more formal definition: “using a single document source to generate multiple types of output; workflows for creating multiple outputs from a document or database” (qtd. in Williams 321). In both definitions, the central idea is to reuse content multiple times in multiple formats, without having to rewrite or reinvent the wheel. It is important to note that single sourcing does involve not copy and pasting, but references or draws content from a database (Rockley, 2001; Sapienza, 2002, 157). Whereas content management refers to the broad combination of processes, technologies, and activities for working with content, SSP is usually done through a content management system (CMS), i.e., a software application built on a database. There are several types of CMSs, including document management systems, Web content management systems, and XML-based component-content management systems. There is also a fourth type of CMS that has important implications for technical communicators: enterprise content management (ECM) solutions, among which EMC/Documentum is an industry leader. ECM systems include not only a component-content management system, but also applications that handle Rabil 2
electronic financial records, digital images, e-mail, human resource documents, and Web content (Clark, 2008, 39-40). In this paper, my focus is exclusively on component-content management systems, since they are the ones most likely to be used by technical communicators today. The important distinction to note here is that while SSP and CM are closely related concepts, single sourcing is focused on reusing content in different formats, whereas content management not only includes single sourcing but also the practices surrounding information modeling, tagging, version control, search, retrieval, and the ability to dynamically publish content. So, henceforth, I use the term “content management,” or simply CM, to refer broadly both to the processes of CM as well as the technological capability to perform single sourcing. What is structured authoring? In CM, reuse is the ultimate goal, which ultimately means chunks of content must be consistent and self-contained. This cannot be achieved without strict writing guidelines, standard terminologies, and information architectures or models shared by writers, subject matter experts (SMEs), and editors. When we talk about applying such models and rules for writing, we are talking about structured writing: “the practice of writing content following structured writing guidelines or models… Models explicitly identify the content that needs to be included, the order in which is should be included, and the places where content is reused” (Rockley, 2003, 350). What is XML? What is separation of presentation and content? I group these questions together because they are closely related. XML (extensible markup language) is a non-proprietary specification for defining markup languages. In the context of CM, XML code is used to tag chunks of content as well as data so they can be stored in a database, queried, shared between disparate systems, and attached to a style sheet for presentation on the Web. Moreover, because it enforces adherence to a set of rules or document type definition (DTD), XML supports structured writing. One major advantage of XML is that its tags are not predefined. Rather, XML allows you to define your own tags to match your organizational needs (Scriptorium 4). In contrast to HTML, which specifies how text should look, XML describes what text is. By enclosing paragraphs or bits of data with descriptive tags, XML makes the structure of content explicit, whereas without tags, a document’s structure is merely implied (Scriptorium 9; Sapienza, 2002, 161). Rabil 3
XML relates to the idea of separation of presentation and content, which, simply put, means removing the formatting and styles from text, such as color and italics, so that it is as “format neutral” as possible. Many believe this separation is not really possible, a view that Dave Clark (2008) thoroughly examines and elucidates in his article, “Content Management and the Separation of Presentation and Content.” He argues that in the context of CM, the separation of content and presentation has a unique meaning, namely, that “content is content modules,” whereas “presentation is output structure, navigation, visual style, and genre definition” (48). By this he means that authoring in a CM environment involves fitting content into predefined structures and semantic relationships. A predefined visual presentation, often maintained by a group separate from the writers, is applied to the content upon request rather than upon original creation of the content. In the context of CM, the notion of separating presentation and content, coupled with the use of XML, is powerful for several reasons. One, it provides useful labels for the content you write and store in a database, making it easier to organize, search, and reuse. Moreover, XML is a universal language that can be read by any computer system, so it enables much more efficient sharing and exchange between systems. What Are (or Will Be) the Effects of the CM Trend? Many authors who discuss the current or future effects of CM usually take the approach that the effects are good, bad, or a melding of both. In this section, I will approach the question by looking at the effects of CM on three groups: organizations, end users, and technical communicators. In each subsection, I have tried to represent the multiplicity of views on the effects of CM. Effects on Organizations Some of the most widely advertised effects of CM are that it will save time, avoid duplication of effort, and avoid tedious updating and bad version control (Rockley 2001; Clark, 2002, 21). Such claims hold enormous appeal for organizations that must provide different types of information to customers in both print and Web formats. A potential result is improved productivity, especially in technical documentation where repetition of standard sections is common (Baker).
Rabil 4
Perhaps the next most positive implication for organizations is that CM has immense potential to establish a central, searchable repository of information that eliminates the isolated silos of information among different groups or departments (Andersen (2008) 65). Too often, organizations fall into what Ann Rockley (2003) calls ‘The Content Silo Trap,’ which is the tendency of different groups to create, store, structure, and archive their own information assets without talking to each other, a practice that results in redundant information, duplicated efforts, and inconsistencies. Yet another implication of CM for organizations is in the area of knowledge management. Organizations are increasingly recognizing the importance of capturing, structuring, and storing valuable organizational knowledge that exists in employees’ memory, but “because this intellectual capital is cataloged in the minds of people, it is more difficult to direct and leverage” (Applen 305). To capture and store this knowledge, organizations require a knowledge management infrastructure, a critical element of which could be a CMS that helps make organizational knowledge more accessible.. Accuracy and consistency across an organization’s published content is another positive effect touted by proponents. Creating documents from scratch presents a huge problem not just for consistency of terms and design, but corporate message (Trotter). On an organizational level, then, the value of CM, XML, and structured authoring is that they not only require but enforce compliance with an established model, set of standards, or content organization (Scriptorium 1). Without such a structured approach, writers throughout the organization, especially large ones, run the risk of producing and presenting information inconsistently. Despite all these positive implications, however, there are just as many challenges. For example, although CMSs may save time in terms of avoiding version control or tedious updating, they are incredibly complex technologies that require significant thought and planning before adoption or implementation. The market is filled with vendors offering tools with hundreds of features. Matching the right system to organizational needs is no simple task, as a simple review of JoAnn Hackos’ detailed “Content Management Requirements Checklist” indicates (385), or as a brief visit to a Web site like CMS Watch will reveal. Furthermore, once adopted, organizations face the high cost of training employees (Robidoux 115). Databases, research has shown, are one of the most complicated technologies for non-technical users to harness for their own uses (Mirel 388). In fact, Robert Kramer, through an in-depth analysis of an IBM singleRabil 5
source publishing system that makes extensive use of XML and DTDs, argues that single sourcing can bring unexpected technological challenges that increase the workload of the people who maintain them (333). Applen also warns that if not properly planned for, using XML can lead to systems that are too complex to manage efficiently, ultimately resulting in knowledge that is inaccessible (310). And Sapienza argues that while HTML is generally pretty easy to learn, XML is generally a more complex technology to grasp (168), perhaps partly due to the need for knowledge of DTDs and XSLT. Of course, many systems such as AuthorIt provide a WYSIWIG interface for users to work with, and vendors often claim that their CMS require little to no technical knowledge. But Andersen debunks this assumption, arguing that even WYSIWIG CMSs are complex tools to learn, regardless of how intuitive their interfaces are (75). Finally, there is the unavoidable reality that some organizational documents are more conducive to being structured into reusable chunks than others. Mark Baker, for example, maintains that genres with substantial repetition benefit far more from structured authoring, and that CMSs will be more successful in organizations where writers or content managers are available to devote themselves to structured writing. In his view, CMSs will not be effective in other areas like HR and marketing where the knowledge workers do not write full time, and are even less accustomed to structured writing than technical communicators are. Effects on End Users I use “end user” to mean two groups of people: (1) the members of an organization who need to search for and find content to carry out their jobs, and (2) the customers of an organization who need to answer a question, complete a task, or get educated on a topic. Whether searching a help system or browsing a Web site, end users don’t just need information fast; they need information that is accurate, consistent, and up-to-date. They also need many different types of information, and they usually want it in multiple formats. Finally, if possible, they want the information to be customtailored. CM vendors promise that their CMS will fulfill enable organizations to fulfill these needs, specifically by providing consistency of message, consistency of structure and presentation, consistency of tone and style, findability (e.g., through consistent structure and keyword searching), and customizeable content. Rabil 6
Proponents of CM highlight consistency as an important benefit that help people use documentation more effectively (Hamilton). They usually say “consistency” to mean consistency in the use of terminology, meaning, and branding, which theoretically leads to fewer errors or contradictions—e.g., in places like product descriptions, instructions, or conceptual overviews—that users would otherwise have to sort out on their own. When conducted properly, CM ensures that chunks of content will be more consistent in structure and formatting, i.e., in terms of headings, organization, labeling, layout, and formatting. The advantage here to the user is completeness of content, as well as a reduction in irrelevant content components that may creep in when structure is not as strictly controlled (Rockley, 2003, 351). CM is also said to facilitate quicker retrieval of content in multiple formats, since content is indexed and stored in a central repository. When done rightly, CM promotes consistent tagging of metadata to stored content (e.g., through the use of XML tags or otherwise), thus increasing findability. Finally, customization is a crucial benefit to end users. This is what Rockley has called “dynamic customized content” ((2001) 191). Content stored in a database can be more easily selected and assembled to suit the needs of the situation. Certain CMSs and document database systems allow the creation of user profiles that identify user patterns and match relevant content to those patterns, resulting in a greater degree of end user personalization (Rockley, 2001, 191; Albers, 2000, 192). Ultimately, this blurs the line between end users and authors. As Sapienza (2004) puts it, “With structured documentation, a user might encounter content systems that can be customized. The user’s role is no longer that of a recipient and student of a static system, but rather that of a co-creator of a dynamic and changing one” (399). This ends up giving users more control, as they have the power to manipulate and display information according to their interest, and thus to enhance their memory of content and space (Sapienza, 2004, 405). But even if consistency across content is achieved, that does not necessarily mean the content will be relevant to the end user’s specific context (Hamilton). While terms may be consistently used, and branding and formatting may be parallel across print and Web outputs, the content will not achieve its full effect if it was not written with a thorough understanding of user needs (Hackos 59). The issue, in other words, is that even with consistency, content can fail to achieve usability and rhetorical effectiveness. Moreover, the basic premise behind customizeable content is that users will manipulate information that has already been published. Albers Rabil 7
(2000) notes a number of challenges here, a main one being that content components can be taken out of their original order, which means that some of the interrelationships between them can be lost. “With the generation of dynamic documents,” he says, “the reader’s needs are different each time a document is generated ... As a result, a different information structure gets created, a structure an editor cannot review for consistency and comprehensibility” (198). The effect on the end user, in other words, is less testable. Sapienza (2004) makes a similar case, noting that existing research on the usability of customizeable information displays is currently inadequate. While results from various studies show that customization can aid memory and improve system use, other results show that customization is easier for experts than novices, which would require building different levels of expertise into the XML metadata (405). Finally, there are multiple questions surrounding how people will be affected by the shift to modularity. The question was raised at least as early as 1993, when Stephen Bernhardt wondered whether readers would be less tolerant of “extended arguments and reasoning,” whether “fragments” of information would dominate texts, and whether reading would become more like scanning (418). Years later in 2008, Clark argued that a likely effect is the expectation among end users to have “alternative access to content” via techniques such as RSS feeds (56). Providing content in chunks, then, may result in a desire among audiences to be able to collect and integrate content pieces from multiple sources, which in turn will change the way technical communicators work, as well as how they think of themselves as authors. Effects on Technical Communicators Because so many different authors have theorized the effects of CM on technical communicators, I have broken the major claims into subsections, each of which include competing or nuanced viewpoints. CM reduces tedious labor and promotes reuse. This argument is just as compelling for writers as it is for organizations, and has been made by many successful vendors, experts, and practitioners like Ann Rockley (Rockley 2001) and JoAnn Hackos (2002). For example, because CM enables easy updating of information (i.e., changed in a single source, then automatically updated to appropriate modules), it thereby eliminates manual updates to each module of the content in different formats and mediums. But is such reuse desirable if it does not connect with the audience’s needs and context? Authors like Michael Albers (2000), Dave Clark (2002), Rabil 8
and Richard Hamilton (2008) question whether we can truly imagine all the possible uses of a content chunk beyond the current situation, or to imagine it in the context of a whole document. If paragraphs rarely make sense when taken out of context of a whole document, how we can make sure paragraphs are indeed “self-contained” (Albers 199)? Not everyone in the field is so skeptical, however. Working at Hewlett-Packard Company, Charlotte Robidoux explains that teams work around the context problem by storing reusable modules and the documents they reference in separate “books,” thus allowing context-specific content to be added at the moment of compilation (127). Where she works, teams manage changes to modules by submitting a change request through a formal workflow, in which authors and editors meet to discuss the impact the change will have (127). In addition, experts like Rockley and Hackos rigorously underscore the importance of extensive user research and task analysis to ensure that modules do in fact meet contextual needs. Nevertheless, authors such as Locke Carter (2003) and Dave Clark (2008) contend that the affordances of single sourcing will put pressure on writers to deliver content solutions for decision makers who are less interested in usability and more interested in meeting stricter budgets. In such cases where implementation is inevitable, some of the best strategies include sharing the broad vision for the changes that will come, and to provide sustained open communication throughout process (Carter 318). CM lets writers focus on writing instead of formatting and layout (Rockley, 2003, 351-352; Kevin Dick, 2002; Scriptorium 15). This goes back, of course, to the concepts of structured authoring and separation of presentation from content. When content is created as “format neutral” text in a CMS, it can later be united with a style sheet, thus allowing writers to focus on composing instead of getting bogged down in design. But will this spell the death of the “unified writer” that emerged with the desktop publishing revolution in the 1980s (Carter 319)? Many technical writers today enjoy the union between writing and design and resist watching that union disappear. However, authors like Robert Kramer do not believe this will happen, at least not exactly in the sense that skeptics believe. Rather, Kramer argues we will simply need to gain more technical and problem-solving competencies traditionally seen at the heart of IT, in addition to existing writing and design skills (333). As mentioned above, CM and XML do take a lot of technical skill to learn, apply, and understand. Sapienza (2002) noted that it requires skills in “infrastructural management,” Rabil 9
and possibly some programming expertise in languages like Perl and PHP (167). In a later article, Sapienza (2004) contends that XML and structured writing depends on the “interrelatedness of content and usability techniques” (400), suggesting that there is, after all, a great need to unite presentation concerns with structured authoring. CM can increase the power and prestige of the technical communicator. (Dave Clark, 2002, 21). Applen (2002), for example, argues that XML will enable technical writers to be knowledge managers who enjoy higher status, and Sapienza (2002) believes that learning XML may give technical communicators more power, since designing DTDs is an act of defining knowledge (161). But with great power comes great responsibility. Knowledge management is a large field with concepts and techniques that are both familiar and unfamiliar to technical communicators, who would probably need more training to learn how to structure and define information, and marry it to context (Battalio 240). Besides that, “what exactly should constitute a valid document structure, grammar, and syntax, and who should develop it?” (Sapienza, 2002, 161). People answering this question may find themselves locked in rigorous debates with various members of an organization who have different views on how knowledge should be defined. Applen realizes that gaining agreement on such matters can be a significant challenge that involves collaboration and negotiation across groups within an organization (310), which may mean technical communicators do much less writing. CM changes the concept of “ownership.” In traditional content authoring, a writer is assigned to write a document, and is, in a sense, the “owner” of that document (Rockley, 2003, 352). But in structured authoring common to CM, writers are not typically owners of a whole document, but parts or modules of a document that must relate to other modules. Rockley (2003) observes that writers who once controlled an entire document may now only be responsible for a set of modules that appear in specific sections across multiple web- and print-based products (352). She argues that this will lead to a more team-based approach that will bring satisfaction comparable to that of an athletic team taking pride in its victories (352). Hackos says this form of authoring is actually more liberating, since it lets writers focus on the content alone (69). And Robidoux (2008) presents a strong argument for how teaching structured authoring in collaborative settings can help writers prepare for successful CM work. Still, others believe this changing notion of Rabil 10
authorship is too restrictive and fear it will ultimately result in draining writers of their “artistic impulse” (qtd. in Robidoux 110). Writing, editing, and managing neutral chunks of content seems like assembly-line labor. Yet people like Sapienza (2004) reject this notion, arguing instead that writing in modules requires a “deliberate and highly skilled process that is at the heart of any craft” (111). CM requires strict compliance with models, rules, and standards. To achieve coherence and accuracy for reuse, writers need to write and edit for consistency not just in mechanics, but also in tone, sentence structure, and paragraph style, since multiple authors (often writing at different times and places) will need to work out differences in writing style and persona. Although this requires highly-detailed style guides or models to ensure standards are followed (Trotter), Hackos believes this structured approach is a powerful enabler for dynamic content reuse (68). Naturally, writers have difficulty adapting to such changes. Structured writing, as Sapienza (2007) points out, follows an “accumulative structure” in which the order of parts is less important than the parts themselves (94). In unstructured authoring, by contrast, writers typically develop documents holistically, in which the order of content is syntactical, sequential, and fairly linear, and in which transitions between paragraphs are important. Writers are more accustomed to this “developmental structure,” which relies on logical, chronological, or causal transitions to aid comprehension (Sapienza, 2007, 94). With CM, however, rigorous compliance with an information models, rules, and standards is essential, while the “whole document” is often invisible. Albers (2000) said editors will need to more actively advise writers on expressing ideas consistently (201). There could be a very real temptation to enforce standards for their own sake, resulting in “dumb conformance” without really adding value to enterprise (Baker). CM is something that will require more business savvy and strategic planning. Several authors believe this to be the case. After all, CMSs are often bought with business needs in mind, and once adopted, they will put immense business pressure on writers and require the construction of relationships between people and resources (Hart-Davidson et al. 12; Clark, 2008, 53). What will it take to ensure that CM is ultimately successfully? Among other things, numerous scholars in the field strongly recommend that technical communicators gain skills in long-term planning and business Rabil 11
strategy (Albers, 2005, 271; Guthrie 5).
Conclusion: Where I Stand I understand the angst technical communicators feel towards CM. The fundamental premise of CM—content reuse—appears to be at odds with the core of contemporary technical communication theory and practice, which places a high value on the uniqueness of each rhetorical situation. By promoting the creation of neutral modules that can transcend context, single sourcing goes against the grain of what technical communicators conceptualize as the heart of their discipline, what Clark (2002) terms “context-driven communicative goals” (20). How do we cope with this? I am convinced that CM will eventually permeate most organizations in which technical communicators work. And after reviewing a fair portion of the literature on these topics, I see a complex range of pros and cons to this development. My position within the discourse is based on five major points. First, I believe that in addition to being experts at “standard expository,” “linear,” or “unstructured” writing, technical communicators will need to be experts in structured or modular writing. I do not, as many technical communicators fear, expect that structured writing will completely replace unstructured writing. However, given today’s trends toward Internet computing, modular information, and multimodal communication, I do expect that structured writing will become increasingly prevalent, and therefore, more critical for technical communications to learn, test, and apply. For the time being, I do not think we have quite reached the point where structured authoring and content reuse constitute the majority of methodologies that technical communicators use. But if we do reach that point (and I suspect we will), I believe technical communicators will need to integrate structured writing techniques into their diverse repertoire of communication capabilities in greater measure. Two, I believe that technical communicators must actively influence the design of CMSs and participate in the dialogue that CM vendors and IT business leaders are having. Clark and Andersen (2005), Stewart Whittemore (2008), and Rebekka Andersen (2008) argue forcefully for such participation. Whittemore, for example, upon observing that the sheer volume of content in a CMS requires writers to exercise the rhetorical canon of memory more than ever, offers some excellent CMS design recommendations, a major one being that we allow technical communicators to visualize relationships between modules in more visual-spatial and 3-D views, rather than remaining satisfied with the traditional folder/file-based view of information Rabil 12
(102). This approach to influencing CMS design is the kind that technical communicators should be taking. Furthermore, Rebekka Andersen (2008) argues convincingly that enterprise content management (ECM) solutions will affect technical communicators in significant ways, and that we must confront the ideological assumptions behind the claims of ECM vendors and create a stronger voice in the ECM discourse, or otherwise watch our roles be shaped by the technology that upper management decides to impose on us (63). Andersen provides good practical advice in her article on how to do so. Third, from a more theoretical perspective, I believe technical communicators must avoid the “technology as a tool” paradigm that Clark and Andersen (2005) warn against. Technology is not neutral; it encourages certain uses over others. In the case of CM, the most prominent affordance is content modularization and reuse, yet if we embrace this affordance too quickly, I fear we will succumb to a philosophy of expediency that elevates financial motives over the real needs of end users. Hence, as far as is possible, I believe technical communicators should be active members of efforts to carefully assess the impact of CMSs on the local context, i.e., how it will impact organizational authors, end users of the systems, and the consumers of information. A great source I have found for taking this approach is Bonnie A. Nardi and Vicki O’Day’s Information Ecologies: Using Technology with Heart, which advocates viewing technology as part of an “information ecology” of people, practices, and values in a local context. I have found this to be a useful critical framework for determining why, when, and how to implement technology for the good of the community. This leads to my fourth point: I believe technical communicators must learn how to articulate the ways in which CMS adoption aligns or fails to align with broader organizational goals. I base this conviction on the understanding that CMS technology affects organizations in profound ways, as a study by William Hart-Davidson et al. (2008) recently concluded: The process of coming to content management touches nearly everything about the culture of writing in an organization, beginning with how texts are understood and encompassing every step of the text generation life cycle up to and including the way a text should behave when a user interacts with it. An organization might need new software, new hardware, new personnel, new editorial policies, new training—all to make a Rabil 13
culture of content management stick… And so we have found that we must find new ways to talk to organizations about these changes—not only about the mechanics, but also about the bigger picture implications... (12) In a similar vein of thought, Paul Trotter (2008) said that one of the biggest problems of CMS adoption is that so few people understand how to articulate how and why content is an “information asset” that affects organizational success. In the context of CM, therefore, I believe that technical writers must learn to think and talk like entrepreneurs (Clark and Andersen 299), and to articulate the impact of CM in business terms, such as how CM affects an organization’s stated mission or lines up with stated strategic objectives. As a result, I believe technical communicators will increase their organizational credibility and better position themselves to positively affect the adoption, implementation, and execution of CM tools and practices. Finally, I agree with the numerous authors like Jon Battalio (2002), Filipp Sapienza (2002), Michelle Eble (2003), and Charlotte Robidoux (2008) who have argued for different approaches to teaching technical writing that include more modules in single-sourcing, structured writing that is highly collaborative, and XML coding in undergraduate and graduate technical communication programs. The important point to note is that such authors suggest do not simply suggest we should teach more technological skill, but that we may need to reconceptualize and restructure our curriculums to teach a tighter integration between writing for print and writing for the screen. They also tend to make a related argument (one with which I strongly agree): that we need to inculcate a closer union between rhetorical and technical skill, combining competencies in communication and tools expertise to meet human needs in technology-laden working environments. In fact, Sapienza (2002) argues that achieving this union is what we, as technical communicators, are uniquely positioned to do in an era where the combination of data and prose is increasingly common practice (156). Teachers, in my view, will need to ensure that such “skills synthesis” remains genuine, and avoid the mistake of valuing tools expertise over communication expertise, or vice versa. The more that CM continues to change the way technical communicators think, act, and work, the more I am convinced that a “yin and yang” pedagogical perspective will be the most important, in which we teach students both how to be better writers and Rabil 14
users of technology in equal measure. I suspect that striking this balance will be one of the greatest challenges to teaching and practicing technical communication in the future.
Rabil 15
Works Cited Albers, Michael J. (2002). The technical editor and document databases. What the future may hold. Technical Communication Quarterly. 9.1: 191-206. Albers, Michael J. (2003). Single Sourcing and the Technical Communication Career Path. Technical Communication 50.3: 335-343. Albers, Michael J. (2005). The Future of Technical Communication: Introduction to This Special Issue. Technical Communication 52.3: 267-272. Andersen, Rebekka. (2008). The Rhetoric of Enterprise Content Management (ECM): Confronting the Assumptions Driving ECM Adoption and Transforming Technical Communication. Technical Community Quarterly 17.1: 61-87. Applen, J. D. (2002). Technical Communication, Knowledge Management, and XML. Technical Communication. 49.3: 301-313. Baker, Mark. (2008). Structured Content: What’s in it for writers? CMS Watch. Retrieved Nov 9, 2008 from http://www.cmswatch.com/Feature/79-Writers,-XML,-and-CMS Battalio, Jon. (2002). Extensible markup language: How might it alter the software documentation process and the role of the technical communicator? Journal of technical writing and communication. 32.3: 209-244. Bernhardt, Stephen. (1993) The Shape of Text to Come: The Texture of Print on Screen. College Composition and Communication. 44.2: 151-175. Reprinted in J. Johnson-Eilola and S. Selber (Eds.) (2004). Central Works in Technical Communication. New York, NY: Oxford U. Press. 195-210. Carter, Locke. (2003). The Implications of Single Sourcing for Writers and Writing. Technical Communication. 50.3: 317-321. Clark, Dave. (2002). Rhetoric of Present Single-Sourcing Methodologies. Proceedings of the 20th Annual International Conference on Computer Documentation. 20-25. New York: ACM Press. Clark, Dave. (2008). Content Management and the Separation of Presentation and Content. Technical Community Quarterly 17.1: 3560. Clark, Dave, and Rebekka Andersen. (2004). Renegotiating with Technology: Rabil 16
Training Towards More Sustainable Technical Communication. Technical Communication. 52.3: 289-301. Guthrie, Melissa L. (2000). Avoiding the Drone Syndrome: How to Keep Your Technical Writing Job Interesting in an Age of Automated Publishing.” STC Conference Proceedings. Retrieved Nov 1, 2008, from http://tc.eserver.org/19840.html Hackos, JoAnn. (2002) Content Management and Dynamic Web Delivery. New York, NY: John Wiley &Sons. Hamilton, Richard. Content Reuse: Is It Harmful? The Content Wrangler. Retrieved Oct 27, 2008, from http://www.thecontentwrangler.com/article/1899/ Hart-Davidson, William, Grace Bernhardt, Michael McLeod, Martine Rife, and Jeffrey Grabill. (2008). Coming to Content Management: Inventing Infrastructure for Organizational Knowledge Work. Technical Community Quarterly 17.1: 10-34. Kramer, Robert. (2003). Single Source in Practice: IBM's SGML Toolset and the Writer as Technologist, Problem Solver, and Editor. Technical Communication 50.3: 328-335. Mirel, Barbara. (1996). Writing and Database Technology: Extending the Definition of Writing in the Workplace. Electronic Literacies in the Workplace: Technologies of Writing. 91-114. Urbana, IL: National Council of Teachers of English and Computers and Composition. Reprinted in J. Johnson-Eilola and S. Selber (Eds.) (2004). Central Works in Technical Communication. New York, NY: Oxford U. Press. 381-393. Pullman, George, and Baotong Gu. (2008). Guest Editors’ Introduction: Rationalizing and Rhetoricizing Content Management. Technical Community Quarterly 17.1: 1–9. Rockley, Anne. (2001). The Impact of Single Sourcing and Technology. Technical Communication 48.2:189-194. Rockley, Anne. (2003). Managing Enterprise Content: A Unified Content Strategy. Indianapolis: New Riders. Rockley, Anne. (2003). Single-sourcing: It’s about People, Not Just Technology. Technical Communication 50.3: 350-355. Sapienza, Fillip. (2002). Does Being Technical Matter? XML, Single Source, and Technical Communication.” Journal of Technical Writing and Communication. 32.2: 155-170. Sapienza, Fillip. (2007) A Rhetorical Approach to Single-Sourcing Via Rabil 17
Intertextuality. Technical Communication Quarterly. 16.1: 83 – 101. Sapienza, Fillip. (2004). Usability, Structured Content, and Single Sourcing with XML. Technical Communication 51.3: 399-408. Scriptorium Publishing Services, Inc. (2002). Structured Authoring and XML. Retrieved Nov 17, 2008, from http://www.scriptorium.com/structure.pdf Slack, J. et al. (1993). The Technical Communicator as Author: Meaning, Power, Authority. Journal of Business and Technical Communication 7.1: 12-36. Reprinted in J. Johnson-Eilola and S. Selber (Eds.) (2004). Central Works in Technical Communication. New York, NY: Oxford U. Press. 381-393. Trotter, Paul. (2008). Effective Content Reuse: Storing Paragraphs, Not Topics, Is Key to Content Management Success. The Content Wrangler. Retrieved Nov 9, 2008, from http://www.thecontentwrangler.com/article/1895/ Whittemore, Stewart. (2008). Metadata and Memory: Lessons from the Canon of Memoria for the Design of Content Management Systems. Technical Community Quarterly 17.1: 88-109. Williams, Joe D. (2003). The Implications of Single Sourcing for Technical Communicators. Technical Communication 50.3: 321-328.
Rabil 18