Jason Swarts
Abstract
Purpose: To describe the practice of technical documentation on software user forums and consider what value technical communicators add when they are no longer solely responsible for generating help content. Argue that documentation needs undergo a shift as users’ tasks expand beyond what is directly accommodated in the software’s design. Users no longer need stabilization knowledge (knowledge of what software is designed to do) but possibility knowledge (knowledge of what the software is capable of doing).
Method: Interviews with moderators and frequent posters on four software user communities for Microsoft Excel, Adobe InDesign, Mozilla Thunderbird, and GIMP. Questions probe the participants’ sense of what makes helpful contributions on software user forums. Answers are coded thematically.
Results: Moderators and frequent posters stress the importance of maintaining high quality content and high quality social interactions. High quality content is that which is credible and situationally authentic, expansive, and targeted. High quality interactions are those that effectively involve multiple members of a community and distribute responsibility for addressing user problems to those community members with the most suitable experience/expertise.
Conclusions: While community members may adequately generate the necessary help content, technical communicators are needed for abilities that are also strongly associated with the profession but that often seem of secondary importance. Technical communicators may be skilled moderators who can use their genre knowledge to correct, clarify, and contextualize software problems; use their interpersonal skills to help maintain ties among members of the community; and use their knowledge of text usability and organizational communication to create infrastructure for storing and retrieving help content that is performed in the user community.
Keywords: user communities, documentation, moderation, information architecture
Practitioner’s Takeaway
- Technical communicators cannot generate enough specialized help documentation to meet all user demand, but a community of users can. Technical communicators can help maintain the community.
- Technical communicators understand how to articulate tasks effectively and how to structure useful solutions.
- Technical communicators are skilled at interpersonal and organizational communication, which helps hold the software user community together, ensuring that it continues to function as a vibrant and credible source of documentation.
Introduction
When new software products are developed and released, there follows a period in which users learn the software’s designed operation. Traditionally, documentation assisted the user in this cultivating this knowledge. And if the software addresses a need indispensably, then there may come a point at which users permanently adapt their work to software, or any technologies, that have become ubiquitous and essential. Desktop publishing and Internet technologies are good examples. Each results in a reorganization of people and resources around it, rippling out to touch other activities. The point of observing that technologies become semi-transparent components of cognitive, social, and professional infrastructures is that users reach a point when their activities are not isolated to a particular technology but are instead distributed across the infrastructure of which that technology is a piece. This change marks a shift in the location and nature of tasks with which users need support. Consider the illustration in Figure 1.
The change is subtle: early in a technology’s development, the tasks we accomplish with it often fall within the sphere of the software’s programming, within the range of tasks that developers anticipated and that technical communicators documented. At this threshold, the software meets user needs and functional expectations, and assuming no change in the nature of the tasks supported, consumers become uninterested in further features and development (see Norman, 1998, p.33). We know, however, that tasks shift as the exigencies, constraints, and contexts change. In the interim, between the shift in tasks and the development of more specialized technologies, users make do with what they have and fit existing technologies into new roles by using them in coordination with other technologies. For example, we use email for correspondence but now also for file transfers, for collaborations, for reminders. It is all still correspondence, but the tasks get fuzzier around the edges as the task goals shift from models assumed in the email client’s programming.
Task shift is the exigence for innovation and development. As tasks shift, existing technologies fit the task goals imperfectly and require innovation. But this interstitial period is one in which users need a lot of support and traditional documentation is often of little help. At one level, the problem is related to genre and the ways that the genre of software documentation has stabilized over time, as the rhetorical situations calling for that kind and form of information stayed the same (see Van Der Meij, 2009). The social action that recurs in the genre of software documentation (see Miller, 1984 for this use of “genre”) is that of a single user interacting with a finite range of software interfaces to accomplish known tasks. A testament to the stability of the software documentation genre is its instantiation in assistive technologies such as structured writing tools that reinforce a concept/task/reference model of help topics. Task shift destabilizes help content, perhaps not the structure of concept, task, and reference but instead the scope of information that makes up salient concepts, appropriate tasks, and useful references.
Traditional documentation supports a particular kind of learning, aimed at creating what Engeström calls “stabilization knowledge” (2007, p. 271), knowledge that freezes or standardizes and creates an abstraction of an otherwise messy reality. Traditional documentation does this well and appropriately in early stage product adoption; people need to learn the standard operations. As tasks shift, learning needs shift toward what software is capable of doing in relation to other technologies, in an increasingly complex web of task-based technological dependencies. Information supporting these shifted tasks must be more plastic, where “inputs and outputs are less well defined; and information is less targeted” (Brown & Duguid, 2000, p.95).
In support of shifted or shifting tasks, there is a need for “possibility knowledge” or agent-based knowledge that is developed and deployed in the moment (Engeström, 2007, p. 271). Possibility knowledge is destabilized and deals with the uncertainty of the task situation, the network-like confluence and influence of other factors (p. 272). Engeström’s example is analogous to ours. He described a task where a patient visits a doctor for diagnosis and treatment of a standard medical condition that is uncomplicated by underlying chronic conditions or addictions and whose treatment is uncomplicated by drug interactions, insurance difficulties, immunities, and the like. Likewise, documentation written as stabilizing knowledge assumes uncomplicated tasks, for instance running a report that is uncomplicated by the nature of the format or privacy of the data going into the report, uncomplicated by a variety of intersecting analyses and motives that the report must address, and uncomplicated by the various technological and social connections across which that information must be shared.
When there are multiple, intersecting exigencies that touch upon and constrain one another, the tasks shift and the standard or genred responses do not hold; they must destabilize into more flexible and raw streams of knowledge that rely on the agent or the practitioner to display, represent, and assemble (see Hart-Davidson, 2013, p. 59) in a way that responds to the particularities of the situation.
For this kind of help, users often turn to user forums and other sources of crowd-based instruction, which are capable of being individualized and dynamically created (see Frith, 2014). User forums act as a kind of performed documentation or documenting space by creating possibility knowledge through reconstruction of the situation out of which tasks have shifted. This process of reconstructing the rhetorical situation is a social one (Bawarshi & Reiff, 2010, p.70); it takes place within the context of an activity and within the social and historical and technological contexts of action (see “polycontextuality” in Engeström et al., 1995; Spinuzzi, 2007). Under these rhetorical conditions, the role of the technical communicator is to assist in the construction of the rhetorical situation to which a task has shifted and to which a user is oriented.
This role is one that Selber (2010) anticipated when discussing the shift from print documentation to electronic documentation. He argued that the transition to electronic documentation and just in time, highly individualized learning is that the nature of what technical communicators manage has changed. With traditional documentation, technical communicators managed publications. As the rhetorical situations calling for documentation grew more complex and networked, more attention shifted to managing flexible units of content like tasks and concepts. In electronic documentation sets, the work of technical communicators has shifted toward the management of knowledge (Selber, 2010, p.112) and, importantly, to managing the sources of that knowledge, which is the community or social of which Bawarshi and Reiff wrote. The shift has been recognized by others as well, including Frith (2014) who uses the occasion to reframe the work of technical communicators as curators, organizers, and facilitators of this content (2014, pp. 179-180).
This research elaborates the position that technical communication addressees the management of knowledge resources, the orchestration of the crowd which, when organized, can leverage considerable intellectual power (see Shirky, 2011; Sunstein, 2006) given proper direction and ability to distribute the cognitive effort to members of the community who are best capable of handling it (see Hutchins, 1995). This is unfamiliar ground for many technical communicators, and it marks a foray into areas of work that we are not accustomed to contemplating. The question concerning us here is what this knowledge and work looks like. How do people acting as technical communicators encourage content that addresses problems arising from shifted tasks and cultivate an environment in which that help can be performed and practiced?
We can see this work on display in the various user forums to which users of software and other technologies go to engage in possibility learning. Sometimes technical communicators work in those settings, either out of enjoyment or on behalf of the companies for whom they otherwise produce standard written documentation. But as more people are moving to forums and other interactive and social settings for assistance, it appears important to consider what role technical communicators could be playing as stewards of information and not the sole creators of that content. As such, this article takes up the following:
- What knowledge is exhibited and encouraged in forums?
- How do people manage that knowledge?
- Where does the work of information creation and community cultivation overlap with the skills typically associated with technical communication?
Content, as I hope to show, is not the problem. We have plenty of it, but the people who are the most skilled at and capable of generating the raw content are going to be those who are living the shifted tasks. It’s time that we stop thinking that our jobs are to provide content and instead look at that work as organizing content providers, and accommodating that information to others. We learn about this function by observing how members and moderators of software user communities already adopt these roles as citizen technical communicators. To get there, we must first consider how user forums are altering our awareness of what we document and how.
Methods
I sampled content from four busy user forums for four popular software packages: Microsoft Excel, Adobe InDesign, Mozilla Thunderbird, and GIMP. This research was declared exempt from IRB (#1774). A research assistant and I filtered the threads first by number of visits, then by post count. Our aim was to find the most frequently viewed and most active threads. Often, these threads were long and active because they originated from complex problems.
These kinds of problems showcase what is most valuable about the user forum as a source of documentation: it is a performance of help that is orchestrated by community members, who play the role of technical communicators. We can see in those interactions the kind of work that trained technical writers would excel at: eliciting knowledge, managing the output, shaping the products of those exchanges into usable artifacts for community members (tutorials, quick starts, FAQs, knowledge base articles). I focused data collection on the members of the community who had earned status, variously as elders, gurus, or moderators. These are the people who have the credibility and authority to weigh in significantly on a topic and to alter the shape of a conversation. In effect, these people acted as technical communicators, just as any contributor could, but they had been bestowed with authority and stature by the community. Upon identifying these members of the community, I approached 20 moderators/senior community members via private message about their willingness to be interviewed for this research. Hereafter, I will just refer to both groups collectively as moderators since that is the authority and privilege that they held. The questions from which all interviews started were:
- Why do you participate on this forum?
- How do you use the forum?
- What do you consider to be the qualities of helpful contributions to this forum?
- How would you describe the role of the community/forum moderator?
Depending on the answers, I would follow up with additional questions.
The interviews were conducted by phone and email (especially in situations where time differences prohibited synchronous communication). Following techniques of first cycle coding of topics (see Saldaña, 2009), I coded for topical themes. Through iterative cycles of coding, I refined the codes by splitting and combining codes until all of the data were accounted for. The conversations gravitated toward three particular issues that defined helpful content on the forum: the content, the interactions among community members, and the role of the forum moderators.
Results: The Work of Moderation and Technical Communication
In this section, I offer an overview of themes in the interview data, in terms of the questions raised earlier: what knowledge is exhibited and encouraged in the forums and how is that knowledge managed? After coding the data, two general concerns emerged as driving forces that guided how moderators managed the forums. The first is that there were issues of controlling the quality of the content, mostly concerning the quality of the contributions made by the community in response to a query. Another dimension of concern was with the quality of the interaction, the interoperation of the community as a collection of like-minded individuals and the need to enculturate newcomers to the practices and predilections of the community. Quality interactions, shaped by subtle moderator influence can lead to both better questions and also to a more congenially-distributed sharing of responsibility for articulating and trying out answers among community members. The last area of focus was the roles that forum moderators played both as technical communicators and as those who coordinated the efforts of the user community.
Knowledge Content Created
Quality Content Is Credible And Authentic. Traditionally, technical communicators have defined their contributions to product documentation around the production of content, writing the concepts, tasks, and references that make up the documentation. In a user community, however, content is not in short supply. There is an overgrowth of content that requires cultivation to be useful to those who have sought it and those who might come upon it through future searching of the community forums. The moderators and frequent posters I interviewed revealed considerable concern with managing the quality of the information and saw doing so as a principal part of their work. Within this broad category of work, a number of themes arose. One of the draws for users who post questions is the people who are offering the answers, people who are interested in the technology and who use it on a regular basis. When they make contributions, it is clear that they do so out of experience and the ability to understand the situations users find themselves in.
Whether out of pride or pure altruism, the software forums are frequently seen as a place for the most knowledgeable of users to demonstrate their depth of knowledge and experience (EF3). Users appear to recognize a difference in the quality of help that appears in different locations. Where the embedded help files for some software might be seen as “generally poor” (EF4) the more chaotic presentation of help is more authentic because posters recognize that many of the “regulars are real users with real experience, not telephone operators reading from a script” (AF1). Users do recognize that the “help files are obviously useful in specific contexts, but there is little documentation in terms of how [the] various functions can be combined in more complex scenarios” (EF4) like networked task contexts. The help documents oversimplify by making too many assumptions about the commonality of the underlying circumstances in which the users need to learn about and apply solutions (see Mehlenbacher, 2013).
The official documentation does not sufficiently appeal to the kinds of users who visit the software forum. The documentation describes scenarios and motivations of use that do not appear to match the complexity or messiness of situated practice and so lack a particular credibility or appeal to ethos. Where in traditional documentation the primary appeal to ethos comes from the writer’s association with the software developer, the credibility of the user forum derives from their authenticity, the extent to which their answers are grounded in the particularities of the situation presented. The very idea of authority is a social construct; authority is attributional and the product of a social interaction. In the same manner, the authority or ethos of community-generated content arises from the quality of the interaction through which that authority is established (Hauser, 2002, p. 148). What is frequently overlooked about ethos appeals is that they are, at heart, appeals showing that the interlocutor is working with the best interests of the community in mind. And to cultivate that ethos, there needs to be a medium of interaction that is two-way and responsive, unlike text. Moderators have a role to play in this process by helping to underscore the credibility of the information being presented.
The moderators and posters are also aware that the authenticity of their help sometimes comes at the expense of its apparent credibility. Aside from the moderators and the frequent posters, many people on a software forum are unknown and anonymous. And so there is still a need for official documentation (MF PP1), but it is not always helpful from the start. Ideally, helpful answers and good solutions to common problems become a part of the official documentation after the answers have been verified and the steps adequately documented. I have argued elsewhere that answers in a software user forum do go through various stages of stabilization, starting with the thread that gets stickied, when tutorials are created, and when official knowledge base articles are written, and eventually when solutions are embedded in scripts and baked into new releases of the software itself (Swarts, 2015). But if the instructions provided through official documentation are the plans for how work ought to get done, the authentic answers that arise from the forums are the situated applications of those answers that are revised on the fly and in real time. Their authenticity arises from the rigor of the situations in which the solutions are developed and accommodated to users who often “can’t be bothered to put themselves in someone else’s shoes, and will fare much better with an individualised answer rather than a link to a thread that solves a similar issue” (EF3).
Quality Content Is Sometimes Expansive. Good answers sometimes acknowledged that software packages are complicated and that there may be many right answers for some kinds of questions. As one moderator summed up, “[t]here’s not just one set of instructions that if you want this to happen, you have to do ABC. You can do ABC, or you can do ABG, or CDF, or whatever. You may get exactly the same result or you may get something slightly different” (AF1). The answers, literally, expand to other topics and tasks, and preconditions may impinge on the best answer for the question posed. At times, users arrive at the software forum with an idea of how to solve a problem that might be overly complicated or fraught with unforeseen problems. In these situations, posters and moderators hope “the reply will get the poster, and other readers of the thread, thinking about not only the specific problem but other similar problems. Even to the extent of reconsidering their approach to the whole project to make the task more robust or simplified” (AF PP2). We have all probably experienced similar situations of committing to a particular answer or approach in spite of the mounting evidence that it will not work.
Not only are software packages complicated, it is also the case that the tasks people bring to the forums are not neatly confined to a particular piece of software. So a spreadsheet question might involve, principally, the use of a spreadsheet program, but also require interface with accounting software or project management software or might require bringing over data from a different format. When users work on tasks, they often do not use single technologies but instead build around themselves networks of technologies or “functional organs” that are yoked together to accomplish the work (see Kaptelinin, 1996). In these situations, it is unclear where a question would go. It is unlikely that the exact question involving the situated interoperation of a variety of technologies could be addressed within the official documentation from one particular program. Moderators can help draw out some of these situational complexities to make the full nature of the problem as clear and expansive as it needs to be.
Another aspect of expansiveness is that good answers ought not to address only the questions being asked but also to create the right conditions to allow a transfer of knowledge or skills to similar situations. To those posters and moderators attempting to build this knowledge, the best solutions are those that are “so well constructed as to be easily applied to numerous similar situations with only minimal alterations” (EF2). They are solutions that “not only resolve the original problem but also explain the mechanics behind the solution (coherently of course)” (EF4). Both of these approaches not only address questions that are raised but also help to create knowledgeable users, some of whom might remain members of the community. Consider that a user forum only supplies useful help information so long as content flows through the threads. Content stops flowing if there are not enough people with enough knowledge and experience to put the content in. So, expansive answers ask the users who post questions to indulge the answer providers with a little extra attention and a willingness to read to learn instead of simply read to do (Redish, 1993). By showing how problems and solutions touch on a variety of concepts and related tasks and how they are supported with a variety of reference materials, answers and the engagement that they support in the forum can help create conditions for learning.
Knowledge Managed
User forums tend to attract members with a variety of reasons for contributing to an emergent knowledge base but who often do so out of a desire to be part of a community. For these contributors and those who merely use the forum, there is a benefit to the communal interaction that must be supported. This matter comes to the heart of what technical communicators often do best but do not always recognize in themselves or get recognized for: technical communicators are good communicators. They are good at doing the work of articulation (see Slack, Miller, & Doak, 1993) of linking people and resources together, of making communities and collaborations possible. This articulation work is important in a user community and to the task of documenting shifted tasks.
Quality Interactions Are Speedy, Persistent and Customized. A welcoming community is a quality that moderators and frequent posters strive to maintain. And one of the first tasks is to ensure a continual stream of interactions that welcome newcomers and returning visitors to the site (see Frith, 2014, p. 180). There are few things that cause a thread and community to wither faster than the lack of response.
Without feedback from the community, there is no community. “This is one of the problem points of community forums: lack of feedback and the option to just abandon your post. It results in threads that just don’t continue, as well as threads that provide perfect solutions, which may never be probably acknowledged” (EF3).
Posters likened the dynamics to “walking into the hardware and just saying, “‘Well, all you guys here look like you know what you’re doing. How would you do this project?’” (AF1). It is a friendly gathering of skilled people who are interested enough in a topic to help people with their questions. In fact, many people, when asked to describe the most helpful responses, said that it was any response to the question at all. The beginning of the engagement process, even if to ask for clarification of the problem, even if just to acknowledge that a post has been seen, is understood to have a significant positive effect on the outcome a thread, if only because the basic engagement keeps the thread alive.
The motivation is to keep information flowing through the community. If there are speedy responses, even short acknowledgments, then visitors stay engaged in the thread and are more likely to come back. The speedy reply also addresses user concerns about whether the forum is busy enough to get answers within a reasonable time frame. But mere activity is not enough to make the community valuable. The advantage of two-way communication is that it allows for the exploration of problems to get at customized answers and, by in large, moderators are willing to engage individuals at the level they are at: “time permitting, stay with a thread when the replies from the OP (original poster), esp newbies, displays evidence of not understanding or misunderstanding the information being offered” (AF PP2). Those people who feel like they have benefited from the intelligence and persistence of the community are more likely to continue contributing.
This attitude results in community members demonstrating remarkable patience, allowing posters to start threads on what seem to be the same questions, repeatedly. Sometimes the questions are the same, but just as often “you get questions about situations that are similar but not the same. As something that might have been asked before a new way to do something, or an odd ball requirement. And then you have to talk about the ramifications of using this technique or that technique and let people decide whether one way is better than the other” (AF 1).
Quality Interactions (Re)Assemble the Community. In addition to tending to the needs of newcomers, community members must also tend to the needs of the community and make the effort to build out the community and to strengthen its connections by involving community members with different skills sets (for example, coding, scripting, design), keeping posters engaged in threads, and helping newcomers become helpful and engaged contributors themselves.
When asked why they participate in the forums, what brings them back when they are receiving no financial benefit, many moderators and posters pointed to the camaraderie between them and the forum regulars, the ability to come and talk with the regulars about “arcane topics” that might not come up as questions. Just as many have altruistic reasons for sticking with the forum: “[m]ainly to give back some of what I’ve learned” (AF 1) and to “pay it forward” (GF PP1). In the eyes of their peers, the best community members are “[p]olite, supportive, [and] knowledgeable, with willingness to delve deeper if the discussion heads in that direction” (AF PP3). These members make up communities that do not want to make any member or newcomer feel unwelcome.
It is also important to get the community to come together and act as a community. In this sense, we are talking about community as an effect, a dynamic, a spontaneous, coordinated interaction that is often invoked by posters or moderators. A frequent poster from the GIMP forum describes it this way: “[t]he best contributions usually come from the most experienced coders or users of GIMP. Today would be a perfect example to answer this question. [Moderator] asks about a gradient effect, she has used one of my tutorials to accomplish it in part, but asks if there is a better way. In comes [Community Member] (a very skilled coder and contributor) who offers a very unique description along with screenshots” (GF PP2). Around the moderator, the other respected members of the community converge and in this convergence begin to offer something that is beyond what the original poster had sought: it is a kind of wisdom and depth of response that is possible because of how knowledge is distributed across the members of the forum but then coordinated in the forum. The larger community “shares resources and ideas” (GF PP3) because they have different ones to share.
Of course people come to the user forums to have their questions answered, but the forum must also renew itself by being a place where knowledge is explored and developed. There is the expectation that users will be engaging in this content to become more learned themselves and to become contributing members of the community: “I chose a forum to answer in based on it’s [sic] online atmosphere. The people asking questions should be those who are after help to resolve their problem but at the same time want to increase their own understanding of the problem and solution” (AF PP2). In fact, the moderators and posters often see themselves as educators.
Maintaining quality content and quality interactions are both outcomes of a process of communication. And this is where technical communicators excel and can assert their value. Identifying the roles that technical communicators can play in that setting is a matter of identifying how communication skills can be put to use, not generating content but in orchestrating the development of raw content and organizing the logistics of a response and follow up to those conversations. In concluding, by talking about the roles the technical communicators can play in this dynamic theater of documentation, we can again turn to the moderators to see how they understand their own roles.
Discussion: A Place for Technical Communicators
I conclude by discussing how the practices discussed in the interviews overlap with commonly technical communicator skill sets. The purpose is to show where we might apply our expertise if our attention is not solely focused on generating raw help content.
Correct, Clarify, and Contextualize
One of the most important roles that technical communicators can play in managing community forums is, perhaps, the most intuitive one: guide the discussion (see Frith, 2014, p. 178). Moderators nudge both questions and responses so that they are clearer and so that the answers that follow are more accurate. They correct mistakes if discovered. They expand content to related issues or consolidate for better precision. Most often, the role played by moderators is simply to keep the threads on topic. This is a function that shows up repeatedly in the moderator comments and reflects a realization that threads can quickly diverge, adding sprawl to the thread and preventing forward movement toward a clear answer. Length of discussion is not a problem so much as a lack of focus. One way in which this problem manifests itself is when other users follow the original poster and use the same thread to ask their own question, which may appear to be the same but could be quite different given the range of circumstances in which their own problems arose. Moderators then see it as their function to “discourage lots of other people from chiming in. We’ll let them chime in if they have a very similar problem, and it doesn’t prove a distraction to the original poster. But it’s got a very specific focus” (AF2).
Moderators can also recognize when problem statements seem unusual, lack detail, or whether answers are wrong or incomplete. In situations like these, moderators can push the thread in the right direction by correcting the course of the discussion as soon as an error is detected. “A frequent problem in providing support on the forums is that the initial post from the OP provides little useful information, e.g. ‘My browser doesn’t work anymore.’ The subsequent exchange seeks to elicit details that might be helpful in diagnosing the user’s problem” (MF 1). Technical communicators are similarly tuned to the same details and problems in their own writing. Within a user forum, the skill is turned outward to the people who are generating the content. Technical communicators understand the genred forms of help topics, the kinds of information that prove useful to both understanding a problem and carrying out a solution. It is a simple matter of participating in the discussion to draw this information out and let the community work with a full understanding of the problem and the user work with a fuller explanation of the solution.
Technical communicators, like moderators, can step in and help start an answer off on the right foot by appreciating the difficult nature of the problems being addressed. First, they can recognize that one cannot make assumptions about the poster’s starting point (for example, the state of their software or operating system); neither can one know about the full parameters of the problem. If the poster is unaware of what factors have a role in creating the problem, neither can it be entirely clear what the ideal solution will be. A long enough conversation, however, will likely touch on these points, and a moderator who knows the general shape of these discussions can probe for more information about the work environment in which the problem occurs and the poster’s expectations for a solution. Effective moderation can prompt the community members to provide this kind of information and in doing so focus the conversation.
Maintain the Community
As I have implied throughout, another important factor is politeness. Moderators will sometimes need to maintain civility and find a place for everyone in the community. In part, moderators do this work because their role is “to facilitate discussion, which includes correcting errors posted by other contributors to the topic and getting the topic on track if it goes off on a tangent” (MF PP1). Fulfilling this role sometimes means that the moderator is the first to respond in a thread, to break the ice on an issue that might be so obscure that regulars in the community cannot find a way into the question (AF1). But above all, the goal is to “[m]aintain the sense of community. Online forums live or die by the quality of their participants and the atmosphere they project. If we can keep the users happy and encourage them, the forum will thrive and everyone benefits” (EF2). Not to diminish the professional responsibilities of technical communicators, but this is also something at which we excel. Numerous studies (Rainey, et al., 2005; Whiteside, 2003) point out that technical communicators are skilled at facilitating interpersonal interactions around and about technical content. And since continued discussion is the medium out of which solutions to complex problems emerge and the credibility of answers and posters are established, forums depend on the guidance of people who are skilled at putting people into conversation and keeping them there and focused.
Create Infrastructure
The last function is understated but is critical to identifying what is important and worth knowing in a thread and in a user community: the ability to recognize and create information out of the experiential and social data that community members bring and the computational data that comes from their interactions with software. Moderators help create information by giving it form, by understanding how different members of the community need to see problems to respond to them and need to see solutions to enact them (also in Frith, 2014, p. 179). Moderators clean and merge and organize and label threads to make them usable (EF2 and EF3). In other words, they make dynamic content findable by giving it structure (see Hackos, 2002; Morville, 2005). They also facilitate the transformation of stabilized community knowledge into permanent documentation artifacts. In this way, moderators make sure that the forum is helpful as a resource while also serving as a conduit for issues back into the official documentation and even back into the product itself. Organizational communication is another strength that technical communicators can bring. They are accustomed to talking with developers and users and can effectively liaise between those groups. They can bring the developers into contact with the users and serve as a point of access.
Even within the forum, however, exercising some sensibility about information design is enough to make the content on the forum useful to both current conversants but also to future visitors. Clarifying title threads is one quick way to make improvements: “we are quite adamant about people having appropriate thread titles that briefly describe the problem” (EF1). Technical communicators can also help with the tagging of specialized content (for example, code snippets) so that it is easily found and recognized (EF3). All are elements of information architecture. Another cognitive and affective design aspect concerns how well a thread can communicate the payoff for reading it. Threads marked “closed” or “resolved” help communicate that an issue has been addressed and so potentially builds the confidence of the community members browsing search results.
Returning to a point from earlier in this paper, we can sum up by pointing out that technical communicators do have a role in the creation of knowledge on a community forum, but in recognizing that the users seek contingent and situated knowledge, the technical communicators will contribute by making possibility knowledge or the conditions in which such knowledge can be created through an exploration of task shifted situations. This is not to say that technical communicators have no role in creating the more representational, stabilization knowledge but that the very reason some people come to the software user forums is that there is no stabilized form of knowledge that will, as yet, suffice for the messiness and contingency of their shifted tasks.
The technical communicator best serves this community by facilitating the conditions for creating possibility knowledge while looking for opportunities to turn whatever content is generated into stabilization knowledge (as print documentation, embedded help, knowledge bases, software updates). Moreover, the technical communicator will also exercise her assets by maintaining the conditions necessary to explore the possibility of knowledge, for meeting contingencies and playing out their effects on help topics. Technical communicators need not be responsible for generating all of the help content or for foreseeing all of the help topics. The user base is doing this traditional technical communication work already, and our roles may be to help diffuse into these user communities not technical communication artifacts but rather a sensibility or a process of doing technical communication work. We do not diminish our professional contributions in shifting to those role but instead refocus them on skill sets for which our expertise has been under appreciated.
References
Bawarshi, A. S., & Reiff, M. J. (2010). Genre: An introduction to history, theory, research, and pedagogy. West Lafayette, IN: Parlor Press. Retrieved from http://wac.colostate.edu/books/bawarshi_reiff/
Engeström, Y. (2007). From stabilization knowledge to possibility knowledge in organizational learning. Management Learning, 38(3), 271–275.
Engeström, Y., Engeström, R., & Kärkkäinen, M. (1995). Polycontextuality and boundary crossing in expert cognition: Learning and problem solving in complex work activities. Learning and Instruction, 5, 319–336.
Frith, J. (2014). Forum moderation as technical communication: The social Web and employment opportunities for technical communicators. Technical Communication, 61(3), 173–184.
Hart-Davidson, W. (2013). What are the work patterns of technical communication? In J. Johnson-Eilola & S. Selber (Eds.), Solving problems in technical communication (pp. 50-74). Chicago, IL: University of Chicago Press.
Hauser, G. A. (2002). Introduction to rhetorical theory. Long Grove: IL: Waveland Press.
Hutchins, E. (1995). Cognition in the wild. Cambridge, MA: MIT Press.
Kaptelinin, V. (1996). Computer-mediated activity: Functional organs in social and developmental contexts. In B. A. Nardi (Ed.), Context and consciousness: Activity theory and human-computer interaction (pp. 45–68). Cambridge, MA: MIT Press.
Mehlenbacher, B. (2013). What is the future of technical communication? In J. Johnson-Eilola & S. Selber (Eds.), Solving problems in technical communication (pp. 187-208). Chicago, IL: University of Chicago Press.
Miller, C. R. (1984). Genre as social action. Quarterly Journal of Speech, 70(2), 151–167.
Norman, D. A. (1999). The invisible computer: Why good products fail, the personal computer is so complex, and information appliances are the solution. Cambridge, MA: MIT Press.
Rainey, K. T., Turner, R. K., & Dayton, D. (2005). Do curricula in technical communication jibe with managerial expectations? A report about core competencies. In Proceedings IPCC Professional Communication Conference 2005 (pp. 359–368). Piscataway, NJ: IEEE.
Redish, J. C. (1993). Understanding readers. In C. M. Barnum & S. Carliner (Eds.), Techniques for technical communicators (pp. 15–41). New York, NY: Macmillan.
Saldana, J. (2009). The coding manual for qualitative researchers. Thousand Oaks, CA: Sage.
Selber, S. A. (2010). A rhetoric of electronic instruction sets. Technical Communication Quarterly, 19(2), 95–117.
Shirky, C. (2011). Cognitive surplus: How technology makes consumers into collaborators. (Reprint ed.). New York, NY: Penguin.
Slack, J. D., Miller, D. J., & Doak, J. (1993). The technical communicator as author. Meaning, power, authority. Journal of Business and Technical Communication, 7(1), 12–36.
Spinuzzi, C. (2007). Guest editor’s introduction: Technical communication in the age of distributed work. Technical Communication Quarterly, 16(3), 265–277.
Sunstein, C. R. (2006). Infotopia: How many minds produce knowledge. New York, NY: Oxford University Press.
Swarts, J. (2015). Help is in the helping: An evaluation of help documentation in a networked age. Technical Communication Quarterly. doi: 10.1080/10572252.2015.1001298
Van Der Meij, H., Karreman, J., & Steehouder, M. (2009). Three decades of research and professional practice on printed software tutorials for novices. Technical Communication, 56(3), 265–292.
Whiteside, A. L. (2003). The skills that technical communicators need: An investigation of technical communication graduates, managers, and curricula. Journal of Technical Writing and Communication, 33(4), 303–318.
About the Author
Jason Swarts is a professor of English at North Carolina State University. His research and teaching centers on mobile communication, coordinative work practices, and emerging genres of technical communication. Contact: jswarts@ncsu.edu.
Manuscript received 31 December 2014; revised 16 February 2015; accepted 16 February 2015.
