Networked Rhetoric: iFixit and the Social Impact of Knowledge Work

Guiseppe Getto, Nathan Franklin, and Sheryl Ruszkiewicz

Abstract

Purpose: Technical communication scholars have shifted to considering the role of communication specialists as knowledge workers within larger networks, such as work groups, organizations, and institutions. From our interest in this trend as well as our aims to bridge workplace and classroom contexts, we conducted a case study of the networked interactions of key actors involved in iFixit’s Technical Writing Project, as enacted in a technical writing classroom at a state university.

Method: From Latour’s definition of an actor as a component of a network capable of impacting other components, we conducted a qualitative case study examining the interactions of technical writers, technical writing students, technological devices, tools, and wiki technologies during students’ completion of the Technical Writing Project. In particular, we examined how these actors exerted rhetorical impacts on one other during students’ writing processes.

Results: The results of our study were that the Technical Writing Project asked students to assemble a complex rhetorical situation that involved technical knowledge-making as well as assembling both human and nonhuman actors to create high-quality documentation. Further, this documentation was created in a situation strongly influenced by both workplace realities and the interactions enabled by an open source wiki that allows for contributions by interested Internet users.

Conclusion: We believe our study on the reciprocal impacts of both human and nonhuman actors in the context of a learning project that spans workplace and classroom context calls for new models of rhetoric that better account for networked knowledge-making.

Keywords: technical writing, knowledge work, network, rhetoric, case study. service-learning

Practitioner’s Takeaway

• Emerging technologies such as open-source documentation platforms are making possible new partnerships between the workplace and the classroom. Such partnerships hold the promise of producing better-prepared technical communicators, as well as providing technical communicators with the opportunity to help train the next generation.
• In order for academic-industry partnerships to be fostered, collaborative networks must be formed between technical communication scholars and technical communication practitioners, networks in which all stakeholders have the opportunity to influence one another in positive ways.
• Such collaborative networks challenge existing rhetorical models for teaching, research, and preparing documentation, and thus require new models that take into account the growing complexity of knowledge work, especially when it involves emerging technologies.
• iFixit’s Technical Writing Project provides evidence that academic-industry partnerships can provide fruitful, challenging, and complex opportunities for knowledge work that has positive social impacts beyond the classroom.

---

Introduction

While researching emerging technologies used to bridge workplace and educational contexts over the past several years, two of the authors of this article (Guiseppe and Sheryl) were approached by the technical writing firm iFixit to engage in a service-learning initiative called the Technical Writing Project, which centers on the creation of free repair manuals for technological devices (http://edu.ifixit.com/). Designed to bolster participation in iFixit’s overall project of creating the largest free online repair manual (http://ifixit.com/), the curriculum supporting this service-learning initiative has grown into a large network of college students and instructors across the country who receive free toolkits, as well as free devices (for example, cell phones, handheld GPS, smartphones, and so forth), from iFixit’s large stockpile of recommissioned e-waste, in return for creating wiki-based repair guides under the tutelage of iFixit technical writers.

While developing curriculum to support this project within our respective courses and programs, we became increasingly interested in the ways in which iFixit has fostered a network of college students, teachers, and repairers of technological devices from a wide variety of industries. We began to wonder, in other words, about the relationships between components of the network surrounding iFixit’s wiki—one that includes technical writers, students, teachers, wiki technologies, devices, and toolkits. While considering these issues, Guiseppe also began a research relationship with iFixit, a relationship that would culminate in a case study of the Technical Writing Project as enacted in his own classroom.

Grounded in a series of interviews with iFixit’s technical writing staff, a rhetorical analysis of process documents exchanged between technical writing students and iFixit staff, and a rhetorical analysis of iFixit’s wiki itself, his central research questions were:

• What are the interactions among key actors involved with a technical documentation project utilizing an open source wiki?
• What bearing might these impacts have, if any, on models of rhetoric used by researchers and teachers of technical communication?

Guiseppe’s main impetus for researching iFixit’s wiki, in other words, was to assess the extent to which the network of people and technologies surrounding the wiki is worth considering from a rhetorical standpoint. He wondered if this network might hold implications for research on the relationship between humans, technologies, and rhetoric.

We think his findings, along with our collective experiences engaging with iFixit’s Technical Writing Project, could inform the ways researchers and teachers of technical communication think about emerging technologies like the oManual, the open source documentation system upon which iFixit’s wiki runs (http://omanual.org/). And we think that these findings could inform the way researchers and teachers think about the networks afforded by such technologies. We begin our exploration of these issues with a more thorough introduction to the theoretical framework behind our case study of the Technical Writing Project. We then articulate the methods we employed in this case study into the relationships of various actors within iFixit’s network, and the findings these methods rendered. Our goal throughout this report of research findings and analysis of extant literature will be to encourage scholars and professionals interested in these issues to reconsider some of the ways in which their professional activities are being impacted by, and are thus impacting, the development of emerging technologies that are in turn changing the ways we think about rhetoric.

Theoretical Framework: Speculative Realism, Knowledge Work, and Networked Rhetoric

As myriad recent publications attest, an increasing amount of technical communication scholars have shifted to considering the role of communication specialists as knowledge workers within larger networks, such as work groups, organizations, and institutions (Bay, 2010; Grabill, 2007; Johnson-Eilola, 2005; McNely, 2011; Slattery, 2007; Spinuzzi, 2007; Spinuzzi, 2008). This shift builds on conversations from related disciplines like engineering, applied psychology, and information technology (IT) that go back several decades and that attempt to theorize socio-technical assemblages, or networks of interconnected knowledge workers that are mediated by technology and technical knowledge-making (Cummings, 1986; Davis, 1982; Fox, 1995; Geels & Schot, 2007; Haavik, 2011; Molleman & Broekhuis, 2001; Nierderer & van Dijk, 2010). Many technology-driven workplaces (such as technical writing firms, software development firms, and Web design firms), for instance, now contain such numerous components as a wide variety of Information and Communication Technologies (ICTs); widely divergent forms of technical documentation; and ad hoc groups of writers, developers, interns, supervisors, and quality assurance teams (Slattery, 2007; Spinuzzi, 2009; Whittemore 2007).

Less attention has been paid to how components of networks such as these exert rhetorical impacts on one other. By “rhetorical impacts” we mean ways in which people, technologies, and other components of networks reciprocally influence the actions of one another. Technical communicators frequently employ technologies like content management systems to collaboratively produce written content for publication and delivery to a variety of audiences, for example. Though we know this is the case and have a variety of models for managing people, technologies, and workflow (for example, Bradley & McDonald, 2011; Hackos, 2007; Hart-Davidson et al., 2008; Hinchcliffe & Kim, 2012; Morgan, 2012), these approaches have not been codified into contemporary rhetorical models usable by researchers and teachers of technical communication who are interested in bridging educational and workplace contexts.

To begin to develop such a rhetorical model, we framed our understanding of iFixit’s Technical Writing Project by drawing on socio-technical assemblage theory, which considers the ways in which knowledge workers utilize technologies to develop complex relationships with one another to accomplish work. Beginning in the 1980s, researchers of socio-technical assemblages, as Davis (1982) and Cummings (1986) pointed out, focused on the transition from an industrial economy based on mechanized production to a service economy based on leveraging technical systems for the purposes of continual learning and knowledge management. More recently, a split has appeared between structuralist approaches conceived of as empirical, ready-to-hand frameworks for studying socio-technical assemblages (for example, Geels & Schot, 2007) and post-structuralist approaches, some of the latter even drawing on Latourian conceptions of human and nonhuman relations within networks (for example, Haavik, 2011). Our study of the network surrounding a technical writing wiki would definitely fall within the latter camp, as we attempted to understand this network from the ground up as a series of interactions, not through a ready-to-hand framework. At the same time, we wish to extend existing theory to conceive of the complex interactions among actors within networks as fundamentally rhetorical.

We also draw on technical communication scholarship on knowledge work within groups, organizations, and institutions (Bay, 2010; Grabill, 2007; Johnson-Eilola, 2005; McNely, 2011; Slattery, 2007; Spinuzzi, 2007, 2008). Our main takeaway from this literature, to quote Spinuzzi (2007), is that knowledge work helps networks “hold together and form dense interconnections among and across work activities that have traditionally been separated by temporal, spatial, or disciplinary boundaries” (p. 268). Other important precedents are methods developed from Latourian concepts, such as Actor Network Theory (Hart-Davidson et al., 2008; Johnson-Eilola, 2005; Latour, 2005; Spinuzzi, 2008). This body of work has provided empirical justification for the concept that all components of networks are actors—a concept we explore more below—and thus has provided a necessary groundwork from which to envision the rhetorical impacts actors within networks have on one another.

With this lens in mind, we hoped to develop an understanding of iFixit’s Technical Writing Project as a network that links human action to nonhuman action, and that sees this linkage as potentially rhetorical. This understanding problematizes the modernist project of cleanly separating cultural objects from the objects of the natural sciences, as Latour (1993) would have it. Instead of sterilized poles of knowledge (that is, the cultural and the natural), Latour examined how networks are made up of what he has called “quasi-objects,” which are defined as mixtures of actors that make it difficult to pinpoint exactly where the natural and the cultural start and end respectively (p. 55). Latour’s work has thus made legible the idea, echoed by Graham Harman (2009), that “[t]here are only actants,” meaning that all components of networks (that is, people, technologies, documents, and so forth) have the potential to impact other components in complex ways (p. 63). To be considered an actor for Latour (2005), in fact, means being able to “translate, transform, distort, and modify” other actors (p. 39). Further, actors come in all shapes and sizes (for example, both human and nonhuman).

In the wake of the last decade, thinkers of this persuasion have come to be known by some as “speculative realists” to indicate their acknowledgement of both the role of human perception and the impacts of nonhuman actors in research and theory-building (Bennett, 2010; DeLanda, 2013; Harman, 2002, 2005, and 2009). In a similar vein, Thomas Rickert (2013) has recast rhetoric as irreducible to human intent and action. Specifically, he recently contended that “rhetoric cannot be reduced to the intent—deliberate or posited—to persuade, for we have to include the larger background, including our activity against which the particular assemblage of elements comes to be seen as suasive” (p. 160). For Rickert, including “the larger background,” or the networks within which rhetors operate, is essential because rhetoric is intimately tethered to material being and is therefore ontological (based in materiality), as opposed to being solely epistemological (based in knowledge-making) (p. 162).

We follow this vein below to construct a case study of both material means and knowledge-making within iFixit’s Technical Writing Project, a case study that acknowledges the networked interactions of key actors we encountered, including technical writers, technical writing students, technological devices, tools, and wiki technologies. In particular, we examine how these actors exerted rhetorical impacts on one another, or how the people, technologies, and other components of the Technical Writing Project we observed appeared to reciprocally influence the actions of one another. We begin this discussion by detailing the research methods we employed to produce these findings.

Method

Research Sites and Participants

Our study was conducted at two main sites: online via iFixit’s main wiki interface (http://edu.ifixit.com/) and via interviews conducted over videoconferencing software, and in a face-to-face technical writing classroom at a four-year state university. Our goal was to understand how several different kinds of actors rhetorically impacted one another within the network surrounding the Technical Writing Project. Because the goal of the Technical Writing Project is primarily educational, and because Guiseppe was in his second semester of using the project as a final assignment in his Technical Writing class, he agreed to have student participants recruited from his class. At the same time, we began a rhetorical analysis of all online documentation and technologies clearly linked to the Technical Writing Project. Because we wanted to be certain we understood the goals of the iFixit technical writers who created this project, we also recruited participants from the six technical writers that iFixit employs, of which three agreed to participate.

The Technical Writing Project (http://edu.ifixit.com/) was designed as a flexibly-structured curriculum for use by technical writing instructors who wish to teach the art of documentation in a hands-on manner. This is accomplished by inviting students to document methods for repairing a particular technological device, such as a cell phone, smartphone, or handheld GPS. It is also intended as an introduction to repair for anyone, student or otherwise, who wishes to contribute to iFixit’s large catalogue of free, open source, wiki-based repair documentation (http://edu.ifixit.com/). The Technical Writing Project is scaffolded mainly by a “Student Roadmap,” which contains “Milestones,” or descriptions of best practices for each stage of the Project:

• Getting Started: Provides various resources for getting started on the Project, including an instructional video on the Project, the environmental mission behind the Project, advice on how to choose a device to create documentation for, a guide for creating a free account within iFixit’s wiki, and a checklist of necessary supplies.
• Milestone 1: Provides a guide to the creation of a “Troubleshooting Page,” which “helps users diagnose what is wrong with their device and points them to the correct repair guides.”
• Milestone 2: Provides a guide to the creation of a “Device Page,” or a kind of homepage for the device being documented, which hosts all the information for that device in an organized manner.
• Milestone 3: Provides a guide to photographing the stages of repair and creating one or more “Repair Guides,” which are intended as step-by-step instructions to guide users through a specific repair process.
• Milestone 4: Provides a guide to usability testing and peer reviewing the rough drafts of completed guides, defined as assemblages of the three genres mentioned above: a Troubleshooting Page, a Device Page, and one or more Repair Guides.

The Milestones are intended less as linear steps for completing the Project, and more as benchmarks for instructors to use to guide students, and for use by students who wish to guide themselves, though checklists of what should be accomplished at each Milestone are included. At any time, students engaged in the Technical Writing Project also have the option to submit their in-progress documentation to iFixit technical writers for review, or to ask any questions they may have about their developing documentation. Guiseppe, as an instructor in the program, was additionally guided by Brittany McCrigler, one of iFixit’s technical writers who is also their Director of Education Services and whose job it is to manage educational initiatives, as well as to recruit, advise, and ship devices and toolkits to instructors who wish to participate in the Project.

To capture rhetorical impacts among various actors engaged in a heavily networked project to create repair documentation, we designed a qualitative case study (Miles & Huberman, 1994; Stake, 1995 and 2000; Yin, 2009) of several actors engaged in the Technical Writing Project. These actors included two student teams (of three students each) engaged in the Technical Writing Project as a final assignment for completion of Guiseppe’s Technical Writing class, the devices students documented, the tools and technologies students used during their work, the iFixit technical writers who guided the students, and all documents produced along the way. In this article we present a case study of some of the rhetorical impacts we observed among these actors, specifically impacts involving reciprocal influence among the people, tools, and technologies associated with the Technical Writing Project.

Researcher Role(s)

To compensate for the complexity of our case study, we negotiated appropriate moments of data collection, as well as modes of data to collect, with participants. Beyond best practices in teacher research, such as those articulated by Ray (1993), this collaborative approach also stems from best practices in critical ethnographies of writing, such as those articulated by Cushman and Monberg (1998), Horner (2002), and Brown and Dobrin (2004). Encouraging researchers to focus on collaboration, reflexivity, and reciprocity with participants, these thinkers also emphasized how material conditions impact the researcher-participant relationship and, as a result, the usefulness of the knowledge derived from a given study.

Our guidelines for data collection and analysis were thus wrought through rhetorical knowledge-making with participants, as Ray (1993) would have it, because we thought this was the best way to understand the actors we were researching within the specific, material conditions of the Technical Writing Project (p. 146). Because Guiseppe had power over student participants, for instance, after attaining IRB approval for the project, he documented informed consent via a student research assistant who wasn’t part of the class, and asked this RA to let him know which student teams were able to be researched, after he had already assigned individual students to teams, all to reduce the risk of coercion.

He also documented class policies indicating that nothing observed during research could affect student grades, and was also careful to work with students’ schedules as though students were any other kind of participant. He also reminded student participants that his collection of writing process drafts and his observations of their work with iFixit were entirely optional and dependent on their allowing him into their composing lives beyond the classroom. This courtesy was also extended to iFixit technical writers, as we vetted key moments and methods of data collection with them, such as when we gathered screenshots of their wiki. We wanted to make sure that the screens we captured were the same ones they used themselves when creating repair guides. Through this investigation, we learned that there was a behind-the-scenes moderation panel only visible to technical writing staff and were provided screenshots of this panel for our analysis.

We would also argue that this collaborative spirit was extended to nonhuman participants. A key initial actor in our study was Zotero (http://www.zotero.org/), an application for downloading and preserving Web-based data in its original form. At first appearance, Zotero is a Web researcher’s best friend as it allows researchers to download and catalogue every component of a Web site in its original form (for example, image, link, page layout, and so forth). For whatever reason, however, iFixit’s wiki interface did not appreciate Zotero’s attempted intrusion into its system, and our initial attempts to download the entire interface into a Zotero catalogue (called a “library”) resulted in a dizzying output of over one thousand, three hundred digital objects, which ranged from photographs to icons to hyperlinks to text, all “catalogued” in no discernible order. We saw this as a key act of communication by iFixit’s wiki indicating that Zotero was not an appropriate tool for archiving its interface, and decided instead to utilize the much more low-tech (but time-consuming) option of moving through the interface and capturing each screen view.

Data Sources and Procedures

Our unit of study (Merriam, 1998, p. 27; Stake, 2000, p. 436) was the interactions of various actors within an instance of the Technical Writing Project, as enacted in Guiseppe’s face-to-face Technical Writing classroom. In developing this case study, we drew on qualitative case study (Miles & Huberman, 1994; Stake, 1995 and 2000; Yin, 2009) research procedures and methods. Over the course of a three-credit-hour semester, Guiseppe interviewed three iFixit Technical Writers who serve as mentors for the Project, collected screenshots of the wiki interface students used to create documentation through the Project, collected all written documents that two teams of three students each created for the Project, and kept a teaching journal of observations of the two teams of students. During the last five weeks of Guiseppe’s Technical Writing class, all work in the class was devoted to the Technical Writing Project, which was assigned as a final project for all students in the class, all of whom were also apprised that this would be the case at the beginning of the semester. During this period, Guiseppe collected several forms of qualitative data (see Table 1).

Data Analysis

After data collection was complete, Guiseppe began analysis, with Nathan and Sheryl assisting with overall interpretive themes, though neither dealt with the raw data directly. Our first unit of analysis was the “actor,” which we defined, following Latour (2005), as a component of the network surrounding the Technical Writing Project that exhibited the ability to directly influence the behaviors of one or more other components, or to “translate, transform, distort, and modify” the behavior of other components (p. 39). We thus analyzed the following components of the Technical Writing Project for their potential influence on other components:

• students enrolled in Guiseppe’s Technical Writing class;
• technical writers responsible for mentoring students through The Technical Writing Project;
• technological devices, both those used by students during their repair process (for example, smartphones used to take pictures for their documentation), and the devices students were creating repair documentation for;
• wiki technologies, specifically those employed by iFixit to create an online repository of free repair documentation;
• and tools, specifically those included in the iFixit toolkit that instructors receive as part of their participation in the Technical Writing Project.

We analyzed these actors (as evident in the video recordings, screenshots, written documents, and Guiseppe’s observational notes) by conceptualizing them as part of the same network, a network that afforded “rhetorical impacts” between these various actors.

By “rhetorical impacts” we mean, following Latour (2005) and Rickert (2013), ways in which the people, technologies, and tools associated with the Technical Writing Project appeared to reciprocally influence the actions of one another. We thus identified the actors associated with our case study that appeared to have the most influence on other actors, which we ascertained through triangulating the impacts of each actor on every other actor (see Table 2). Specifically, using qualitative research coding procedures (Merriam, 1998; Strauss & Corbin, 1990), we coded each actor for interactions we observed between it and other actors, and for affordances each actor appeared to perceive within other actors, and thus attempted to articulate rhetorical impacts between actors (see Table 2). By “affordances,” we mean what Lee (2007), following several others, has called “perceived affordances,” a term grounded in the belief that “text-making practices are not determined by what the resources naturally offer but are shaped by how people [and, we would add, any type of actor] perceive what various representational resources can or cannot do for them” (p. 227). We thus attempted to understand each actor in terms of how it interacted with other actors within the network of the Technical Writing Project on both an epistemological (knowledge-making) and ontological (material) level.

To further illustrate this complex analytic procedure, we here provide a detailed example of how we coded one student from Team One as an actor within our case study of the network surrounding the Technical Writing Project. Of the three students in Team One—Ben, Kurt, and Kelly, Kurt distinguished himself early in the Project as the team leader (note: all student names are aliases, as per participants’ wishes). He was the first to ask questions of both Guiseppe and the iFixit technical writers, for instance, and was often the first to spot errors and needed improvements in his team’s documentation. He also clearly saw the Project as an interesting challenge, as he was the first to express the belief in class that the technical writers were “experienced” writers who existed as part of a “real world” he had yet to venture into. This belief would later be echoed both by his fellow team members and by students in Team Two, as evidenced throughout final project cover letters, demonstrating his impacts on his fellow students.

What was perhaps most compelling about Kurt, however, were the ways in which he worked systematically to understand the rhetorical situation he found himself in, and what the available means were for creating effective documentation. He was the first student to revisit the Milestones for the Project, for instance, and to interrogate them as benchmarks for his team’s developing documentation. As he would relate in his own final project cover letter: “you really have to check and recheck and recheck your information to be a technical writer.” This “checking” work was a kind of triangulation that Kurt put his team through, a triangulation that included checking the inner-workings of the wiki, the camera angles of photographs of the device his team was assigned to document, the overall purpose of the documentation they were creating, and help and feedback from the technical writers.

Kurt’s writing process within his team, in fact, would heavily influence our coding scheme for all data collected. When we realized that Kurt was engaging in a very interesting, and networked, writing process, a writing process that involved a kind of feeling out of all the available affordances among other people, tools, and technologies, we stopped thinking of our study as a simple writing process case study and began thinking of it as a case study of a network, a network involving various interrelated, and reciprocally impactful, components. Once we began to understand this, we knew we had to try to understand exactly how all the components present were interrelated, and turned to the theories of socio-technical assemblage and speculative realism that we summarized above for possible units we might analyze.

To first test out this conception of our data as representing a network involving both material objects and knowledge-making processes, we used Kurt as our first potential actor by sketching the initial grid represented in Table 2 above and trying to understand how Kurt’s behaviors as a writer related to all the other components with which we observed him interacting. In collaboration with Nathan and Sheryl, for example, Guiseppe attempted to triangulate Kurt’s behaviors with behaviors among the other people, technologies, and tools by going through each separate piece of data, articulating any interactions that were evident between Kurt and other actors, and then writing the first draft of the above narrative regarding Kurt and sending it to Nathan and Sheryl to see if it made sense to an audience outside the initial research situation. Nathan and Sheryl, in turn, were the first to question what affordances Kurt was responding to, and to ask if what Guiseppe had observed Kurt doing was rhetorical in both an epistemological and ontological sense, or, in other words, if Kurt was potentially making knowledge via the affordances of material components he perceived as available to him. This would result in expanding the grid to include categories for “affordances” and “rhetorical impacts,” and broadening the coding process to include each separate actor we could parse. As we represent below, through this process, students, technical writers, wiki technologies, devices, and tools associated with the Technical Writing Project would arise as actors that impacted one another within the observed network of our case study.

Findings

In this section, we present our findings in three subsections. Each subsection is centered on a particular kind of rhetorical impact we observed between the actors we studied. The first subsection, for instance, discusses the iFixit technical writers and their intended, and actual, impacts on other actors, including their belief in the “Right to Repair,” or the belief that all users of technological devices should have the right to repair their own devices. The next subsection is devoted to iFixit’s toolkits and wiki technologies, and how they influenced the human actors who used them to create repair documentation. Finally, we present the impacts we observed students exerting as they worked to create effective repair documentation for the first time.

iFixit Technical Writers and the Right to Repair

Started in 2003 by two college students enrolled at Cal Poly San Luis Obispo, iFixit has become known within the tech world for providing repair information on electronics. As a startup, iFixit was run out of the shared dorm room of Kyle Wiens and Luke Soules and provided free, open-source repair guides as well as parts and custom toolkits to help users successfully repair their devices. At the center of iFixit, is their massive wiki of free, publicly available repair guides that any user can contribute to. Dubbed “the free repair guide for everything, written by everyone,” the ten-year-old wiki (http://ifixit.com) contains over ten thousand repair guides generated by a pool of over six hundred and sixty thousand hobbyists, technologists, engineers, technical writers, and technical writing students who are regular contributors to the site (B. McCrigler, personal communication, December 3, 2013).

iFixit also devotes significant resources to outreach and engagement around what they call the Right to Repair, or a series of environmental, socio-political, and consumer rights issues surrounding electronics. As the landing page of their wiki boasts: “iFixit is a global community of people helping each other repair things. Let’s fix the world, one device at a time.” One of the main instances of this outreach is of course the Technical Writing Project, which (at time of writing) has generated over three thousand, five hundred guides developed by students at more than twenty universities, each guide averaging two thousand, six hundred views within six months of being posted, with a grand total of ten million, five hundred thousand views on student guides so far (M. Djuric, personal communication, October 14, 2013).

For the iFixit technical writers we interviewed, however, repair is as intimately tied to the effective application of tools, technologies, and knowledge-making as it is to creating impacts on people who use technological devices. As Miroslav Djuric, Chief Information Architect and founding member of iFixit, put it during his initial interview:

From the outset, the founders [of iFixit] knew that there was going to be no way for us to do all of these guides in-house and that we would need help from the Internet to do them. So, we started building a wiki-based system for information pertaining to repair… Now, granted that sometimes may not be as desirable, because sometimes erroneous information gets posted, so we have what we call a moderation queue, where all of the changes made on iFixit, somebody has to review: either an iFixit admin or a moderator on the site. And, to determine who is a moderator, we’ve set up a reputation system. So, the more you participate in iFixit, the more your reputation can go up by people upvoting your correct response to a question or liking your guide. Eventually you reach moderator status because we figure you’ve been on iFixit long enough, so you can go in and approve or moderate some of these other changes. …Now, there are sometimes debates whether you can do this procedure one way or the other, and so what we’ve found in the past was having somebody update a guide and change the procedure a bit. And so every time that happens, we catch it, and I go ask some of the technical writers, “hey, such-and-such on the Internet has suggested that we take out this cable first instead of the other one.” So then, we go back and look through the guide—we usually have a standalone device that we can play with that’s already broken and so we go through—and we verify and if it’s a decent suggestion, it goes live.

This emphasis on repair, moderation, and process improvement is interesting, for our purposes, from a rhetorical standpoint. It calls for both an approach to the affordances of a variety of tools and technologies, as well as a social element that involves knowledge-making with other people.

This emphasis is displayed, for instance, throughout the interfaces available to first-time repairers, such as Guiseppe’s Technical Writing students, who are faced with a series of rhetorical options at each stage of the creation of their documentation, such as when creating a new wiki page (see Figure 1). On this first page, writers must choose between several smaller genres (for example, Guide, Device, Wiki, or Item), each of which calls for a different orientation to knowledge-making, tools, technologies, and other people. While a Guide page uses “how-to instructions” and “high quality photographs” to “teach someone how to do something,” for instance, a Device Page is “anything that warrants a repair manual.” Students from both teams spent a large portion of the first class in which they actually began working on the Project, studying this page, interrogating its affordances, and asking questions to Guiseppe about how they might proceed.

Both teams then chose to begin with a Guide page, even though the Milestones for the Project recommend starting with a Troubleshooting Page, or a page devoted to common problems users have with a specific device. Their rationale, as Tricia, a student from Team Two, put it during class, was that this was their best way to “figure out” how to proceed because they felt “overwhelmed” by the Milestones and all the generic specifications they presented. iFixit’s development of the reputation system that Miroslav mentions above, a reputation system that rewards merit through community-based participation and the specific effects community members have on one another, is an example of a system that supports an epistemology of “figuring out,” however. Within such a system, the ground for knowledge-making is constructed by the interactions of a variety of actors, both human and nonhuman. Each moment in the writing process for creating documentation for the Technical Writing Project asked students to leverage a variety of actors, in other words, actors who influenced their decision-making processes at the same time that they were in-turn influenced by decisions students made.

Because Guiseppe was only on his second run-through of the Technical Writing Project, for instance, he emailed Brittany McCrigler, iFixit’s Director of Education Services, to ask for validation regarding his students’ decision to go against the grain of the Milestones. Her response was that students could approach the project however they saw fit, and that the Milestones were simply guidelines to consider. This response appears emblematic of an approach to knowledge-making championed by several speculative realists, such as DeLanda (2013), who argued that knowledge-making must account not only for “knowing-that” relevant facts exist, but also for “knowing-how” to put the contextual information surrounding facts into action (p. 73).

Within such a paradigm, knowledge workers can’t focus exclusively on knowing-that formulas for producing assumptions, by which we mean that their focus can’t be on what is already known. Miroslav’s above response to a hypothetical Internet user suggesting a change to a professionally-produced guide could be: “no, we already know that this is the best way to repair this device.” He goes beyond this to demonstrate a knowing-how model of knowledge-making when he admits the possibility that a professionally-produced guide could be improved by investigating how a new solution might improve the guide. This approach to knowledge-making is also exemplified by Brittany’s comfort with students figuring out their own approach to creating documentation, even when a perfectly good workflow already exists and is articulated in the Milestones. As Brittany put it during her initial interview:

We do rely on our community and we do rely on our students. Our students create a lot of content for us and so does the community, because right now we have a small technical writing team, and we can’t write thousands of pages a day. So, we spend a lot of time making sure that that experience is good, that the students have a good experience and that they learn how to do it, and users find it easy and want to contribute. We’ve learned a little bit about the human psychology on the Web and how people interact with [the wiki], but it’s really amazing to see how many people do contribute. Like Wikipedia, it helps to have that wider knowledge base for things. We’ve done a few car guides, [for example,] but we don’t really have the ability to strip a car down to its nuts and bolts, so it’s nice to see users able to arrive at information.

Writers are “able to arrive at information” as part of the Project because that information is produced via emergent, knowing-how formulas, formulas which encourage writerly engagement and participation in the networked production of knowledge. Repair documentation here represents a form of knowledge-making wrought through the physical manipulation of tools and technologies, tools and technologies that can be used in a variety of ways, ways that in turn impact the people who use them. At the same time, however, this knowledge-making is never quite finished as other writers troubleshoot, debate, and bring in their own perspectives “from a wider knowledge base,” or the sum total of knowing-how formulas made available via all the users of the wiki. The rhetorical impacts created by—and on—individual writers (and other kinds of actors) within the iFixit wiki is thus highly relational and is afforded by technologies that allow for multiple solutions to problems to co-exist (such as in a discussion forum).

As our third iFixit interviewee Andrew Goldberg, technical writer for iFixit and former participant in the Technical Writing Project, said during his interview:

Helping the students helps us teach people how to improve the community. They’re [key] in expanding the community and getting people to come in and contribute, ask questions, make guides. That’s what we really want to be able to expand: the entire world of coming here, fixing things, and teaching people how to fix things.

Throughout our analysis, we saw evidence that the Right to Repair is a central motivating force behind the “entire world of coming here,” or the experiences students have creating documentation for the Technical Writing Project. This ideal of “teaching people how to fix things” arguably scaffolds the entire process of the Project, from the ways students are invited to enter the Project by making rhetorical choices involving how they want to impact other members of the community, to the tools and technologies that iFixit has developed and mobilized in support of the Project. As we discuss in the next section, however, these tools and technologies also exhibited a life of their own in our case study of a technical writing project intended to showcase the importance of tools and technologies in our daily lives.

The Technical Writing Project’s Nonhuman Actors and How They Impacted Their Human Counterparts

A central theme in the body of literature come to be known as speculative realism is the de-centering of the human actor as the sole arbiter of action within networks (Bennett, 2010; DeLanda, 2013; Harman, 2002 2005, and 2009; Latour, 2005). These theories further hold that everyday objects like tools, technologies, and even furniture can initiate action in the world in meaningful ways. One object that was of particular interest to us in our case study of the Technical Writing Project was the “spudger,” a tool that is part of the toolkit iFixit sends to instructors for use in the Project (see Figure 2). Designed to enable repairers to leverage small openings in devices, many of which hide components that are glued together by manufacturers to prevent repair, the spudger plays a key role in the Project by allowing writers to pry open devices, further enabling them to document internal components. Though not invented by iFixit, the spudger has become a hallmark of the iFixit toolkit because of the frequency of its use in the repair process (B. McCrigler, personal communication, April 4, 2013).

First-time repairers, such as our student participants, are often confused by the tool, however, because, in the words of Becky, a member of Team Two, the tool is “weird.” During a follow-up interview with Brittany, she also revealed that this reaction is common not only among students who engage in the Project for the first time, but also among members of the press who have interviewed her about the Project (B. McCrigler, personal communication, April 4, 2013). When we investigated this shared belief among the participants of both student teams that the spudger is a “weird” object, we began to understand that by weird, participants meant that they didn’t understand the intended purpose of the tool, or necessarily even see it as a tool, at first. For both teams, the spudger was an odd-sounding object whose potential impact on the Project was yet to be discovered.

“What is this?!” Becky exclaimed on the first day that the toolkits were handed out, holding the spudger up and examining it dubiously.
“It’s called a spudger. It’s used to pry open devices,” Guiseppe replied.
“A spudger? That’s weird.”
“Maybe, but it’s also useful. You’ll see.”

It was only when they first required the use of a spudger, such as when they began to disassemble their devices to document components for Repair Guides, that our student participants began to recognize its surprising utility, and the role it plays in the repair process. As mentioned above, both student teams made the decision not to follow the progression for the Project suggested by the Milestones, which suggested creating a Troubleshooting Page first. Students decided instead to start by disassembling their devices into their basic components, to “see how they worked” in the words of Kurt. For Team One, their device was a Sony Ericsson W890i, and for Team Two, it was a BlackBerry Pearl Flip 8220. As anyone who has tried to repair one of their own devices knows, disassembling a device that a manufacturer has effectively sealed, often in a way that actively prevents repair, is no mean feat. As each team attempted to disassemble their devices into their basic components, they quickly encountered this difficulty.

Even when one removes all the screws in a device, using the miniature screwdriver included in iFixit toolkits, the components of some devices are glued together. This was the case with the BlackBerry Pearl, which needed to be pried apart. As luck would have it, this was also the device assigned to Becky’s team. Guiseppe observed Becky, while helping another team in the class, going systematically through the iFixit toolkit, trying each tool in turn. Finally, with a brief pause, she eyed the spudger, and then picked it up, applying it to the case on her device. After using the pointed end of the spudger to create a gap between the two halves of the case, she deftly flipped the tool around and used the flat end to pry the two halves apart. With a satisfying pop, the case finally came apart and Becky clapped her hands in excitement.

Moments such as these in which nonhuman actors impacted the actions of their human counterparts, we argue, are evidence of the potential rhetorical impacts of nonhuman actors within professional networks like the one surrounding the Technical Writing Project. Becky first perceived the spudger as having virtually no affordances for her writing process. When the spudger enabled her to complete a necessary task, dissembling her device so she could document its repair, the spudger also impacted her perception of it, and what it could do for her. In a very real sense, it became an actor in that moment, in the form of a tool that had suddenly demonstrated its usefulness.

We saw evidence of such impacts every time a student responded to an affordance that was specific to a tool or technology they needed to leverage for the Project. These nonhuman actors impacted the ways students pursued the writing of their documentation, presenting opportunities for doing so, as well as limitations. This process was reciprocal, in other words: as students tried out the affordances of a tool or technology, they discovered how those affordances affected the rhetorical choices they had before them. Each choice created a range of new choices within the networked writing process they were engaged in.

This was also evident, as we explain below, in the ways students began to perceive what they were doing as a specific kind of knowledge work. As Natalie, a member of Student Team Two put it, after her team had completed the disassembly of her device: “So, we’ve taken apart our device—now what do we do?” Having chosen to largely abandon the Milestones, students suddenly found themselves in unfamiliar territory, with parts of their devices lying all over the tables in the computer lab in which the class took place. To move forward, they had to begin to interrogate the Milestones as affordances linked closely with the wiki technologies they would use to create their documentation.

Students as Knowledge Workers

An open-ended, but empirically-grounded model of knowledge-making founded in knowing-how formulas seems very pertinent to the learning environment common to many technical communication classrooms, where students are often expected to generate some variety of technical expertise at the same time that they strive to become proficient and flexible communicators for real world audiences. This was certainly the case in Guiseppe’s classroom, where students were introduced to a variety of professional knowledge-making strategies, from staging instructions in documentation to best practices in Web-based content strategy—all in preparation for their participation in the Technical Writing Project. As student participants began the project, however, during the last third of the class, they quickly encountered the important differences between knowing-that and knowing-how. This was summed up in Kurt’s response to the project, that, “you really have to check and recheck and recheck your information to be a technical writer.”

After several assignments traditional to technical communication pedagogy (which asked students to craft materials for fictionalized cases), student participants were surprised by the degree to which the Technical Writing Project required a hands-on knowledge of their assigned devices (including how to disassemble and reassemble them), and how to correctly describe and photograph each step of a specific repair process. As has already been mentioned, students in each group initially struggled to stage their repair, and to understand the intended rhetorical impacts of their documentation on a larger audience of people seeking help for fixing their own devices. This was exacerbated by their decision at the beginning of the Project to pursue a path alternate to the suggested Milestones.

Having gotten stuck after disassembling their devices, however, both student teams, led by Kurt (Team One) and Tricia (Team Two), respectively, began to interrogate the Milestones as potential guidelines for moving forward. Specifically, they began to discuss the utility of a Troubleshooting Page, mentioned in Milestone 1, and what it meant for the audience of Internet users who utilize the iFixit wiki to help them in their repairs. Through discussions with Guiseppe, students came to understand the Troubleshooting Page as a key touchstone between the needs of this audience and their developing documentation. They began to invent possible scenarios for repairing their respective devices, to research such scenarios online, and to include these scenarios in their incipient Troubleshooting Pages. This moment of comprehension got both teams of students writing within the iFixit wiki. Once they understood the Troubleshooting Page as a way for audiences to utilize their documentation, and thus created drafts of these pages for their devices, they were able to further invent specific repair processes that users might engage in.

This kind of networked writing process, we’d like to further claim, facilitated a knowing-how model of knowledge-making for the creation of repair documentation. Rather than focusing on the fact of their disassembled devices, students began to hypothesize how visitors to the iFixit wiki might utilize the disparate parts of these devices to perform a specific repair. Students began to ask questions of each other in their teams, such as “well, what would someone need to do to replace their battery?” and “what if their motherboard went out?” Such critical interrogation would eventually lead to documentation that provided step-by-step guides to repairing specific elements of their devices (see Figure 3). The creation of such documentation required students to hypothesize how users of the documentation might actually put it to use, in other words, rather than simply relying on factual knowledge regarding the current status of their devices (for example, whether or not it would turn on, how new it looked, obvious damage, and so forth). Students had to mobilize a rhetorical knowledge of the future life of their documentation.

Such rhetorical knowledge also extended to requests by iFixit technical writers for deep-level revision of student drafts of their documentation. Once students had completed these drafts, they expected them to immediately rise to the level of workable documentation, as judged by iFixit technical writers. However, they quickly discovered that this wasn’t necessarily the case. The technical writers found numerous issues in both drafts, including photographs that didn’t communicate repair steps effectively, textual descriptions that needed to clarify what was being done at each step of repair, and possible repair processes that hadn’t been included (but were common ones the technical writers received requests for). Even though the technical writers were encouraging and complementary in their critiques, these requests for revision made Guiseppe somewhat nervous that students would lose investment in the Project altogether.

Fortunately, both student teams would rise to the occasion, working hard to complete several rounds of revision in collaboration with the technical writers. Students seemed to genuinely appreciate the challenges of working with writers who were members of a professional network they were encountering only briefly. As Tricia, a member of Team Two, mentioned in her final project cover letter:

Throughout this project I have come to learn just how technical technical writing really is. Each time our group was hoping to be finished with our guides, there was another area to improve, correct, or modify. The slightest change in wording can change the entire step, so it is crucial to review each step throughout each guide to ensure the audience will understand it to its entirety. In addition, I have come to learn that although working in groups may not always be ideal, it’s an important skill in the writing field; communication is key.

Like a good speculative realist, Tricia seems to appreciate her encounter with a rhetorical situation that outstripped her previous understandings of professional communication. She further appears to perceive this situation as representative of knowing-how formulas for making knowledge that are important to the professional world beyond the classroom.

In this way, the networked process of checking, improving, and modifying writing in response to a variety of both human and nonhuman actors we observed among our student participants appears appropriate to a learning environment meant to train flexible communicators who can adapt to a variety of tools, technologies, and rhetorical situations. Though they found it to be a challenging final project, students we observed seemed to genuinely appreciate this opportunity to deal with a complex rhetorical situation, a situation that required “important skill[s] in the writing field.” Finally, though we don’t have data by which to gauge how their individual engagement with the Technical Writing Project impacted student behaviors after Guiseppe’s class ended, their respective guides became part of the iFixit wiki (http://www.ifixit.com/Device/SONY_Ericsson_W890i and http://www.ifixit.com/Device/BlackBerry_Pearl_Flip_8220) and show evidence of having been put to use, both through discussion about them on iFixit discussion forums, and through revisions made to them by other iFixit users.

Implications

(Re)Considering Rhetoric and Its Role in Networks

One of the main implications to the above findings is that rhetoric plays an important role in the formation of professional networks, but that this role may be more complex than previously thought. This is especially the case if we consider the role of nonhuman actors in such networks, and the rhetorical impacts they have on their human counterparts. It is unclear, for instance, how to prepare professional communicators, such as technical writers, for knowledge-making that is as dependent on the impacts tools and technologies have on humans, as it is on the ways humans employ tools and technologies. Findings such as ours, as well as those of our precedent scholars cited above, indicate that new models of rhetoric that account for these emerging complexities must be developed if technical communication scholars are to successfully come to grips with new social realities that confront us on a daily basis.

In an effort to orient an admittedly ongoing conversation toward such models, without presenting definitive conclusions on what such models should contain, we offer the following heuristics as takeaways from our above argument:

1. More knowing-how, less knowing-that: If rhetoric, as deployed in technical communication, is to become a discipline centered on assembling knowledge rather than proceeding from accepted knowledge, then we must work harder to become tinkerers, as iFixit technical writers would have it. We need to take things apart, put them back together, see how they work, and then encourage this behavior in our students. And this tinkering should not only involve technologies, but also assumptions as well. We might ask questions like: what makes a research method viable for a professional communicator in a society increasingly mediated by technological and technical complexity? What makes a knowledge-making strategy salient if we embrace the notion that we can never fully understand the potential impacts of technologies and tools within networks we find ourselves in, but must instead measure the impacts of these actors as we employ them to find our footing?
2. Decenter the human rhetor: If models of rhetoric, and their attendant assumptions regarding knowledge-making and social impact, are to embrace nonhuman as well as human actors, then we must carefully examine the impacts of the nonhuman on the human and vice versa. Such examination might beg questions like: what do these impacts mean for the way we employ trusted rhetorical concepts such as the rhetor, topoi, audience, and memory? How can we employ these concepts as fundamentally epistemological and fundamentally ontological at the same time? What would it mean for these concepts to be less siloed as discrete concepts and defined more based on their impacts upon one another within a given network?
3. Study complex social realities: To develop such models, we might begin to investigate increasingly complex rhetorical situations that necessarily involve high levels of human-nonhuman interaction. It would’ve been much simpler for us to present a case study of technical writing students, for instance, or technical writers, or to present a rhetorical analysis of a very interesting technology for creating open source documentation. Once we realized that the rhetorical impacts we were investigating necessarily involved the interactions of all these actors, as well as several others, we decided to represent the complexity of a variety of relationships, rather than just one specific subset. Such studies risk discerning no tangible links between units of study, but the potential rewards of such research are that it might teach us new ways of learning, new ways of doing, and new ways of impacting key audiences and stakeholders.
4. Reconsider social justice as technological as well as social: Though many will probably agree with this statement, it is important to remember that the experiences users have within technological systems, and with their attendance devices, are party to the same social constraints and systems of ethics as experiences that happen outside of such systems. If we have learned anything from the participants of this study, it is that injustice can be found in even the most highly-technical and knowledge-based systems, as in the case of manufacturers who design cutting-edge technologies that are nearly irrepairable and then restrict access to knowledge used for repair to encourage blanket consumerism, all without due consideration to increasing amounts of electronic waste. Professional communicators invested in becoming advocates for both social and technological justice might find new and inventive avenues for improving our world.

We hope that the above heuristics are taken as encouragements to discussion rather than as agonistic assertions. If we have learned anything from this research project, it is that tinkering involves failure, frustration, and being willing to be wrong, but that this is a good thing. It’s important. Failure is learning. At the least, we hope we have presented a compelling case study of an emergent professional network that bridges educational and workplace contexts, a network that is being used by professional communicators and students to foster compelling varieties of knowledge work. We also hope, however, as every researcher does, that our findings might help our colleagues across various disciplines to develop even more robust and socially useful research methods, outcomes, and models.

References

Bay, J. (2010). Networking pedagogies for professional writing students. The Writing Instructor. Retrieved from http://www.writinginstructor.com/bay.

Bennett, J. (2010). Vibrant matter: A political ecology of things. Durham, NC: Duke University Press.

Bradley, A., & McDonald, M. (2011). The social organization: How to use social media to tap the collective genius of your customers and employees. Boston, MA: Harvard Business Review Press.

Brown, S., & Dobrin, S. (2004). Ethnography unbound: From theory shock to critical praxis. Albany, NY: State University of New York Press.

Cummings, T. (1986). A concluding note: Future directions of sociotechnical theory and research. Journal of Applied Behavioral Science. 22, 355–360.

Cushman, E., & Guinsatao Monberg, T. (1998). Re-centering authority: Social reflexivity and re-positioning in composition research. In C. Farris & C. Anson (Eds.), Under construction: Working at the intersections of composition theory, research, and practice (pp. 166–80). Logan, UT: Utah State University Press.

Davis, R. (1982). Sociotechnical theory: Managing boundaries to enhance student learning. Human Relations, 35, 261–281.

DeLanda, M. (2013). Ontological commitments. Speculations: A Journal of Speculative Realism. Speculations IV, 71–72. Retrieved from http://www.speculations-journal.org/storage/DeLanda_Ontological%20Commitments_Speculations_IV.pdf.

Fox, W. (1995). Sociotechnical system principles and guidelines: Past and present. Journal of Applied Behavioral Science, 31, 9–105.

Geels, F., & Schot J. (2007). Typology of sociotechnical transition pathways. Research Policy, 36, 399–417.

Grabill, J. (2007). Writing community change: Designing technologies for citizen action. Cresskill, NJ: Hampton Press.

Haavik, T. (2011). On components and relations in sociotechnical systems. Journal of Contingencies and Crisis Management, 19(2), 99–109.

Harman, G. (2002). Tool-being: Heidegger and the metaphysics of objects. Chicago, IL: Open Court.

Harman, G. (2005). Guerrilla metaphysics: Phenomenology and the carpentry of things. Chicago, IL: Open Court.

Harman, G. (2009). Prince of networks: Bruno Latour and metaphysics. Prahran, Victoria: Re.press.

Hart-Davidson, W., Bernhardt, G., McLeod, M., Rife, M., & Grabill, J. (2008). Coming to content management: Inventing infrastructure for organizational knowledge work. Technical Communication Quarterly, 17, 10–34.

Hinchcliffe, D., & Kim, P. (2012). Social business by design: Transformative social media strategies for the connected company. San Francisco, CA: Jossey-Bass.

Horner, B. (2002). Critical ethnography, ethics, and work: Rearticulating labor. JAC, 22, 561–84.

Jäger, U. (2010). Managing social businesses: Mission, governance, strategy, and accountability. New York, NY: Palgrave Macmillan.

Johnson-Eilola, J. (2005). Datacloud: Toward a new theory of online work. New York, NY: Hampton.

Lamberti, A., & Richards, A. (2011). Complex worlds: Digital culture, rhetoric, and professional communications. Amityville, NY: Baywood.

Latour, B. (1993). We have never been modern. Cambridge, MA: Harvard University Press.

Latour, B. (2005). Reassembling the social: An introduction to actor-network-theory. Oxford, UK: Oxford University Press.

Lee, C. (2007). Affordances and text-making practices in online instant messaging. Written Communication, 24, 223–49.

Licht, C. (Producer). (2013, September 20). CBS this morning [Television broadcast]. New York, NY: CBS Broadcasting Inc.

McNely, B. (2011). Sociotechnical notemaking: Short-form to long-form writing practices. Present Tense, 2(1), 1–9.

Merriam, S. (1998). Qualitative research and case study applications in education. San Francisco, CA: Jossey-Bass.

Miles, M., & Huberman, M. (1994). Qualitative data analysis: An expanded sourcebook. Thousand Oaks, CA: Sage.

Molleman, E., & Broekhuis, M. (2001). Sociotechnical systems: Towards an organizational learning approach. Journal of Engineering and Technology Management, 18, 271–294.

Morgan, J. (2012). The collaborative organization: A strategic guide to solving your internal business challenges using emerging social and collaborative tools. Columbus, OH: McGraw-Hill.

Nierderer, S., & van Dijk, J. (2010). Wisdom of the crowd or technicity or content? Wikipedia as a sociotechnical system. New Media & Society, 12(8), 1368–1387.

Ray, R. (1993). The practice of theory: Teacher research in composition. Urbana, IL: NCTE.

Rickert, T. (2013). Ambient rhetoric: The attunements of rhetorical being. Pittsburgh, PA: University of Pittsburgh Press.

Slattery, S. (2007). Undistributing work through writing: How technical communicators manage texts in complex information environments. Technical Communication Quarterly, 16, 311–325.

Spinuzzi, C. (2007). Guest editor’s introduction to the special issue on technical communication in the age of distributed work. Technical Communication Quarterly, 16, 275–277.

Spinuzzi, C. (2008). Network: Theorizing knowledge work in telecommunications. New York, NY: Cambridge University Press.

Spinuzzi, C. (2009). Compound mediation in software development: Using genre ecologies to study textual artifacts. Writing Selves/Writing Societies. Retrieved April 15, 2009 from http://wac.colostate.edu/books/selves_societies/.

Stake, R. (1995). The art of case study research. Thousand Oaks, CA: Sage.

Stake, R. (2000). Case studies. In N. Denzin & Y. Lincoln (Eds.), Handbook of qualitative research (2nd ed., pp. 435–454). London: Sage.

Strauss, A., & Corbin, J. (1990). Basics of qualitative research: Grounded theory procedures and techniques. London: Sage.

Whittemore, S. (2007). Metadata and memory: Lessons from the canon of memoria for the design of content management systems. Technical Communication Quarterly, 17, 88–109.

About the Authors

Guiseppe Getto is an assistant professor of technical and professional communication at East Carolina University. His research focuses on user experience (UX) design and the development of participatory cultures within communities and organizations as well as online. He has taught at the college level for over ten years. During that time, he has also consulted and formed service-learning partnerships with many non-profits and businesses, from technical writing firms to museums to art councils. Contact: gettog@ecu.edu.

Nathan A. Franklin is an English instructor at Whatcom Community College, where he researches and teaches object-oriented ontology/rhetoric as well as how to develop writing curricula that foreground the rhetorical agency of nonhumans. He has taught at the college level for nine years. Contact: nfinitum.nathan@gmail.com.

Sheryl Ruszkiewicz is a special lecturer at Oakland University (MI), where she teaches first-year writing courses that include a technical writing service-learning project. She has taught at the college level for five years, and previously taught at the secondary level. Her research includes the application of UX design and gamification to the pedagogy of writing and rhetoric. Contact: ruszkiew@oakland.edu.

Manuscript received 16 May 2014; revised 22 July 2014; accepted 22 July 2014.