An Example

In chapters 3, 4, and 5, we pointed to how writers move across applications and file formats. Our participants often describe that movement as related to efficiency or frictionless composing; they want to effortlessly move text from one tool to the next, minimizing redundancy or perceived drudgery. At first this might appear to be standard computer science practice—the desire to simplify or automate as many tasks as possible. But we think there’s a more important takeaway here for writers. The shuttling of text across composing technologies encourages workflow thinking. It pushes against the common practice of writing in a single app without making a deliberate choice about how that app’s features match one’s preferences, and it facilitates the modular approach to writing that we’ve discussed in this book. Let’s consider a fairly simple example:

Writer X is introducing a visiting lecturer. She will need to speak for only two or three minutes, but she expects a large audience and wants to carefully compose her remarks and read from a script. While drafting her introduction, she does a few things: She reviews the lecturer’s CV, she pulls some of her favorite quotes from the lecturer's work, and she jots down a few personal anecdotes. Then, in a notebook, she outlines and drafts an initial version of the introduction. She reads it aloud a few times, making sure she can strike the right tone, and then she types the draft in a word processor. Finally, she chooses an easy-to-read font, increases the type size and the line height, and prints the document.

When we map this example, we can see how the writer moves across artifacts and writing technologies, working toward a final draft that meets the expectations and conventions of a formal public speech:

Even in this simple example, the map helps us to see the writer’s movement across artifacts and composing technologies as she produces a conventional double-spaced document. By mapping her workflow, we can engage in workflow thinking, and we can see that her process has much in common with that of Sparks, Terpstra, and Viticci—despite the fact that her writing technologies initially appear to be less specialized. Workflow mapping draws our attention to movement across technologies and spaces, and it helps us see how a writer chooses to adopt or abandon particular writing technologies at various places in the writing process. Through the act of mapping, we can also imagine how additional or different writing technologies might encourage new and creative approaches to writing tasks.

By mapping workflows, and by seeing process as existing within a continuum of writing technologies and practices, writers have the opportunity to look carefully at their practice, asking questions like: How portable is a particular piece of text? How do I take and save notes? Are my notes and drafts preservable—and would it be useful to return to them in the future? And how might my current preferred technologies encourage or discourage practices of saving, organizing, and returning to text?

Mapping pushes against (or discourages) seemingly simple notions of how a writer works with technologies, challenging the idea that a writer opens a notebook or application, starts writing, and ends writing at a later point. Instead, mapping helps us to foreground the many embodied and affective practices at work, and it situates process within mediating technologies, histories, practices, and cultural contexts. It encourages metacognition, and in doing so it brings writing technologies to the foreground.

Mapping also draws attention to moments in the writing process that might be otherwise obscured. To better illustrate this, let’s return to the above example. It’s a description of a purposefully simple writing task, and it is the sort of genre in which an informal process description might erase mediating technologies. But a workflow map can tell us much about the processes and possibilities of composing even simple texts.

Our writer began by reviewing the speaker’s CV and publications, looking for poignant and quotable excerpts. She could collect those quotations in the notebook where she’s drafting her introduction, or if she preferred to work digitally, she could collect them in a document draft of the speech and write around them as she composes. But by looking at the map of her notetaking process, she can ask: Could these notes be used for other writing purposes in the future? Would I benefit from keeping a paper commonplace book? Or a database of quotations? If so, what methods of collection and organization might work best? Through mapping, the writer can examine how different technologies might change her reading practices and how they can be woven into her writing practices.

Because the map focuses on writing technologies and modularity, it highlights the movement of text across mediums, software, and files. It also draws attention to the changes in labor (or friction) incurred by moving the text into and out of new spaces. Through mapping, the writer might ask: What would I gain by using a commonplace book? How might it change my thinking—or future projects? Does that trade-off warrant a change in approaches? Mapping helps the writer think through the implications of these decisions. But it also draws attention to the possibilities of new technologies. Suppose, for example, the writer stumbles onto a newly released application that is designed specifically for storing quotations. Her map might help her imagine where this application fits into her process—and how it might then shift her approach to composing. Her map also supports serendipity: by thinking through her workflow and its gaps, she is prepared to imagine exactly where this application could fit into her process—and how it might then shift her approach to composing.

Mapping can also draw attention to opportunities for the circulation and reuse of a particular text. This can happen at the personal, individual level: a writer might move discarded parts of a draft into a new “cutting floor” database, hoping that castaway paragraphs might spark a new idea in the future. But mapping can also draw attention to circulation and reuse beyond personal process. For example, introductory remarks are often a disposable text—sometimes scrawled on the inside covers of conference programs or on the backs of previously printed documents. But in prompting questions about reuse, the map can draw attention to how other readers and writers might encounter and reuse these documents. When the writer prints her remarks in a double-spaced large-size font for easy reading at a lectern, she might also decide to print additional copies for audience accessibility—or to also export the document in a HTML file that could be digitally posted and shared. Because the map draws attention to the movement of text across applications and files, it encourages writers to see how that movement might extend into multiple artifacts that serve the needs of varied audiences and types of circulation.

Workflow mapping in context

As we’ve documented in this book, the writers in the workflow affinity space are quick to adopt new writing technologies. They’re also hesitant to work with a single tool. Rather, they often rotate through technologies and move drafts across different composing spaces as the text approaches a final form. Mapping encourages this, and its metacognitive facets prompt the writer to ask questions about the histories of these decisions: "When did this practice begin?" the writer might ask. Or, "How did I develop this practice—and how is my approach to new tools guided by the ways I used past ones?" In this way, layers of past maps echo through the drawing of new ones. These layers remind the writer of how past practices continue to inform and shape each new mediated act of composing.

Writers' workflows are mutable: they change in response to new situations, new writing tasks, and the availability or use of new technologies. In other words, creating a workflow map is not necessarily about crafting a personal "best practices" document that will henceforth dictate how one approaches a writing task. Instead, we see workflow maps as generative documents that help writers think through how they might align their expertise with certain writing practices and tools, their environmental preferences and constraints, the task and its constraints, and other factors for a given or prospective recurring writing task. We have found such maps to be especially generative in our own practice when we make explicit the trade-offs between factors and focus on friction points that could be resolved through alternate arrangements of tools, preferences, practices, or spaces.

For example, a writer poised to begin composing their dissertation may craft a workflow map to depict:

• what devices they will use to compose;
• what physical spaces they will compose in;
• what software they will use to compose; and
• how digital files will be saved, backed up, distributed for feedback, and revised over time.

As this writer works through these considerations, they may explicitly recall or simply be shaped by past experiences working with file management, writing complex texts, and using various writing technologies. Of course, it's likely that this writer has not yet written such a lengthy, complex text before, so there are no certainties here, and the map may have to evolve as they run into constraints in practice, software, or spaces that were not encountered in writing other kinds of texts. This particular writer may have found Google Docs useful for writing seminar papers in their PhD program, but they may also recall that in writing their MA thesis they found Microsoft Word to be a little frustrating in terms of organizing and managing such a long text. The memory of this friction could lead the writer to look for alternative writing software or practices for managing organization within Google Docs or Word. They may also be shaped by historical associations with spaces—looking to use a favorite local coffeeshop or library nook for drafting but willing to do editing and revision anywhere that is convenient. In creating the map, this writer may also find that they don't have enough expertise or information to craft a good file backup and versioning plan. In reviewing their previous writing tasks, they find a hodgepodge of practices:

• one seminar paper is represented by several files in a folder, with names such as "rough_draft.docx," "version_1.docx," "smith_draft_to_advisor.docx," "final.docx," "final2.docx," "final2proofed.docx," and "final2proofed_newbib.docx";
• weekly reflection papers for one seminar are saved as single files in Google Docs;
• a collaborative conference proposal is saved as three separate files in Google Docs, each with their own automatically saved version histories.

This writer, in crafting their workflow map, realizes this area needs some attention in order to develop an effective strategy for the dissertation.

Another writer may find in crafting the workflow map that they need to wrestle with trade-offs introduced by different writing technologies and practices. This writer has chosen to use Scrivener because of its affordances for organizing long texts in small chunks, as well as being able to store research, drafts, and notes all in the same file. Yet, in crafting their workflow map, this writer realizes they will need to send drafts to dissertation committee members more often than they have in previous writing tasks (e.g., a seminar paper might get one round of review with the professor but not several).

Sharing a document out of Scrivener involves exporting the main text to a separate file, typically a Word-compatible .docx file. Reviewers will then put comments on that file and return it to the writer. But how will the writer then incorporate those notes into the Scrivener file, where they want to keep working and where they want to keep all notes and material related to the dissertation? The writer uses the exigence of completing the map to think through the available technical and practical options:

• keep the reviewed Word files separate and open in another window while addressing the notes in the Scrivener file;
• transfer the comments from the Word file to the relevant sections in the Scrivener file by copying/pasting the comments from Word into Scrivener (which also has a comment feature);
• import the commented Word file into Scrivener, which converts the Word document into a Scrivener sheet with Scrivener comments on it (yet creating a duplicate of the text already saved in Scrivener in the form of the writer's original draft); or
• convert the commented Word document to a PDF and then import to Scrivener, where it will retain its formatting.

Unfortunately, none of these options seem like perfect solutions for this writer. She ultimately decides that she will import the Word file and let it convert to Scrivener format and explicitly mark it as a duplicate reviewed text. But she makes a note for herself in the workflow map that if this seems to be troublesome in practice, there are other solutions that can be tried.

These examples of writers' workflow maps return us to our methodology for the study overall: tracing "environmental-selecting and -structuring practices (ESSP's)" (Prior & Shipka 2003, 219), which "highlight people's situated agency, their tuning to and of environments, their making of artifacts of all kinds," often for the purpose of "externalizations meant to regulate thought and affect, to channel attention and action" (228). While we have named these texts "workflow maps" to highlight the "workflow thinking" we see represented and encouraged in them, they can also be understood as maps of literate activity, following Prior & Shipka's definition of it:

Literate activity is about nothing less than ways of being in the world, forms of life. It is about histories (multiple, complexly interanimating trajectories and domains of activity), about the (re)formation of persons and social worlds, about affect and emotion, will and attention. It is about representational practices, complex, multifarious chains of transformations in and across representational states and media (see Hutchins 1995). It is especially about the ways we not only come to inhabit made-worlds, but constantly make our worlds—the ways we select from, (re) structure, fiddle with, and transform the material and social worlds we inhabit. (181–82)

The sample maps above (and the maps following the videos below) illustrate these various aspects of literate activity in several ways. First, they represent a bridge between histories of previous practices across activities and future desires for practice (moving from seminar paper to dissertation in the above examples). The map as a whole, and often each point on the map, represents an assemblage of "durable activity systems, individual tools, or specific material-semiotic encounters," each of which fold together "multiple histories" (Prior & Schaffner 2011, 54). Although further research is necessary to determine to what extent writers making such workflow maps specifically and explicitly recall these histories and think through them, we suggest that the map represents them whether through conscious deliberation or not. Additionally, besides representing varied histories folded together, these maps "premediate" (Grusin 2004) future practices as well, as writers work through future constraints and trade-offs and imagine their activity.

Next, in documenting the "representational practices" and their varying transformations across time, media, and devices, these workflow maps serve as further reminders of the distributed aspects of our thinking. Not every map will document each transformation to the extent that an interested literacy researcher might, but even these differences offer insight into the writer's understanding and motives for the workflow. Practices that are folded together into a single point on the map figure differently in a writer's understanding than those that span several points. For example, consider a map that depicts composing with an icon of the writing application and depicts file backup using several images and words to represent a complex process. Both activities involve various steps and affordances of their respective apps, but the author of the map collapses these in one area (composing) and details them in another (backup), suggesting perhaps the extent to which they have been internalized or habituated.

Finally, these workflow maps can serve as a means of supporting writers in making their material and social worlds more conducive to writing. As generative texts (rather than prescriptive procedures handed down from above) these maps support writers as they search for ways to exert agency within the constraints and trade-offs in which they work. The writers in the examples above use commercially available software applications, but by crafting their workflow maps to take into account their preferences, the tools' affordances, and the task constraints, they demonstrate a distributed agency. We see the agency that arises from this mapping process as separate from a blanket admonition against letting tools determine one's working practices or the unbridled enthusiasm of early adopters. In our conception of workflow mapping, writers acknowledge that the affordances of tools sometimes require that writers bend their preferences and that sometimes new tools require too much bending to be worthwhile.

Derek's Workflows

File management is an often overlooked aspect of writing with computers. Most word processing applications require users to explicitly save discrete files somewhere in their file system hierarchy, and even applications like Ulysses that don't work with separate files require writers to perform some kind of organization of text fragments. As the example of the dissertator above illustrated, many of us fill folders with a haphazard collection of different files named similarly but typically not following a systematic pattern. My own frustration with this practice led me to version control software and the practice of keeping a narrative, intentional log of discrete changes to my texts.

During my graduate school coursework, I went through a few different writing software phases. I started off using Word but then quickly became enamored with the open source movement and switched to the OpenOffice word processor. Later, after I grew frustrated with that application and quit using it, I couldn't open files I had created in OpenOffice using Word, and they weren't indexed in the desktop search application I was using. This experience led me to think more carefully about the longevity of my files and the various trade-offs involved in nearly any computing practice. When I began writing my dissertation, then, I was primed to develop some new practices for file management. I was also returning to seminar papers I had written, looking for good ideas to use in my dissertation. Looking through coursework folders with their collection of files with random names led me to devise a more standardized practice for the dissertation.

I began by saving each day's work as a new file. Word's "compare document" feature let me choose a file from early in my drafting and compare it with the current version to see all the progress I had made and to verify that I hadn't cut something that would turn out to be useful. By the time I had finished the dissertation, though, it seemed a bit like overkill to have folders filled with thirty or more files, with no telling what the differences were or where important changes had been made.

When I was putting the finishing touches on my dissertation, I experimented with using version control software to store a record of the changes I was making. Basically, version control tools allow users to create a snapshot of a file (or set of files) and attach a brief message to that snapshot. These snapshots are called "commits." Later, users can review the messages in chronological order and see exactly what additions or deletions were made to the file at each point. I experimented with a few different kinds of version control software but ended up using only the basic features: creating a narrative log of the changes I made to a text over time. I found that having this log led me to feel freer in making large-scale revisions and to cut text without worrying if I would regret it later (since the text could be restored easily using the version control software tools).

In tandem with my move toward version control software, I became more convinced of the value of saving my texts in plain text file formats. In large part, this is due to many of the benefits mentioned by participants in this study and was largely influenced by my engagement with their texts, podcasts, and tutorials. Most important, version control software offered more affordances when using plain text files instead of Word files, including the ability to see the exact file changes right in the commit log instead of having to using the unwieldy "compare documents" feature in Word.

However, before I dove into writing in plain text for all of my research writing tasks, I briefly used the writing application Scrivener. I was interested in working with the outline metaphor the application uses to organize text and found I could keep up my version control practices using its built-in features. Working with snippets of easily moved text instead of writing digital "pages" was a revelation, and I found working with rough and drafty text much easier. However, when I began working with a coauthor on a new project, I couldn't find easy ways to collaborate synchronously with Scrivener. I stopped using Scrivener, but I wanted to keep writing in the ways that Scrivener afforded. Luckily, plain text file formats make it simple to open the same file in many different apps, so I was able to experiment with a wide variety of apps without disrupting my writing practices.

Ultimately, I landed on using the Atom text editor with a few special plug-ins designed to make it pleasant to write Markdown text instead of computer programming languages. With Atom I could arrange the window in the same way as Scrivener and approximate the outline format that I found so useful. Further, I could use built-in Git version control tools to collaborate with my coauthor.

Tim's Workflows

My interest in organizing and using files comes from years of disorganization during my high school and undergraduate education. I had notebooks and binders and the means of making a paper-based workflow, but I could never pull it together—I was perhaps too fragmented or too messy or too distracted. At the same time, however, I was developing a keen interest in the computer’s hierarchical file structure, and I can remember making deeply nested DOS folders on the family computer. I considered these separate activities and didn’t see how one could inform the other.

After starting grad school and searching for any technology that might help me keep up with the rapid pace of reading and writing, I found Ethan Schoonover’s Kinkless template for the OmniOutliner application, and the method really worked for me: Each thing-to-do is a project, each project is comprised of tasks, and each of those things gets a hierarchical entry in the outliner. Given my years of traversing the computer file system, I saw a clear connection between the Kinkless system and the digital folder structure.

The Kinkless organization system was limited to project and task management, and it didn’t help me organize reading notes or drafts. But it did inspire me to start searching for other possibilities. When I found VooDooPad, I saw a lot of possibility in the personal wiki. I liked the idea of linked pages, and it was satisfying to see how daily work could accumulate into a large hyperlinked database.

When VooDooPad became too cumbersome, I moved into DevonThink, which did much of the same work but offered many more features: deep databases, rich tagging structures, and easy information collection. I took the linked logic I learned from VooDooPad and moved my work into DevonThink databases.

The move to DevonThink, however, helped me to better see how affect drives many of my writing preferences. I simply didn’t enjoy writing in DevonThink—it looked too sterile, too “computery.” I started searching for other apps—something that could build on DevonThink's database logic but also offer a better composing space. I found Evernote.

Evernote is often called an “everything bucket”—an application that encourages the reader to stash all sorts of files and information in it. Evernote could hold my notes, my drafts, and my research materials, as well as personal documents and photos. It was also one of the first apps with phone-based capture, and I would take pictures of whiteboards from meetings or handouts from classes and stash them in Evernote. Everything went into Evernote.

As I mentioned in the video, I didn’t love writing in Evernote, so I modified a script that allowed me to access all of my Evernote documents via a text editor that I liked for writing (Sublime Text). This was the first time I had tried to get two apps to interface with each other, and it was my first introduction to modular work via scripted computer affordances. I was soon using the store-everything features of Evernote with a simple text editor as its interface.

In the years since, I’ve moved to Scrivener and Ulysses—applications that support writing long texts in discrete chunks.

Today, I rely on a “collection” metaphor for my reading and writing, a practice that I can trace back to my experience with DevonThink. I use a writing application (at this moment, Ulysses) that operates as the central collection point for all text in my life. Everything goes into the Ulysses inbox. From there, texts are organized and stored in different projects and folders, all of which support writing in small chunks. Ulysses also allows me to export text in a number of different formats, so a syllabus section might start in Ulysses and be later exported to HTML for posting to the class website. Or a new paragraph for this book might begin as Ulysses Markdown and later be exported to plain text that can be saved to GitHub so that Derek can read and respond to it. I can use Ulysses as a starting point, and through Ulysses I have built a writing environment that meets my current affective preferences—and through which the visual appearance of a draft on my screen can be different from the final artifact produced. I still like the idea of a central repository (like an everything bucket) for all the text in my life, but I’m now working with one that allows for a customized drafting environment, easy export, and a visual organization of projects.

Through these narratives and maps, I can see how my writing practices ebb and flow over time. I notice how past practices inform current ones, and I can imagine places where new applications might fold in. These practices aren’t static, and I’m sure my workflow will change by the time this book is in press. But that’s also part of the pleasure of workflow thinking—imagining how practices can change over time and considering how new technologies might offer a new perspective on familiar problems and tasks.

The Software Review

“Let’s face it,” Stephen M. North argued in 1992, “reviews are the small change of academic writing” (348). North was writing about scholarly book reviews, a staple but somewhat messy fixture in most academic journals, noting, “Book reviewing can be—and is, for many academic (and nonacademic) enterprises—the occasion for vital, visible, memorable exchanges: the print equivalent, say, of the salon and/or the street corner, current and accessible. Book reviewing is not that for us—or, to the extent that it is, I would argue, it is so mostly in spite of, not because of, the way we handle it” (349).

Today, many of North’s observations about book reviews still hold: publishers want their books reviewed in academic journals, but book reviews carry less professional currency than research articles; book reviews are often written in a shorter time span than research articles and are subject to less editorial scrutiny; and, unlike trade reviews, academic book reviews are often published months (or years!) after the initial release of a book. However, book reviews offer important contributions: they draw attention to notable books, they put authors in conversation, and they mark current debates and discussions in the field. Despite their small professional currency, book reviews remain an important mainstay in most professional journals.

Software reviews, on the other hand, are mostly the purview of trade journals and tech blogs. This wasn’t always the case. The earliest issues of Computers and Composition, for example, featured many short pieces about writing software, such as Muriel Harris and Madelon Cheek’s (1984) “Computers across the Curriculum: Using Writer’s Workbench,” Isaiah Smithson’s (1986) review of “The Writing Workshop,” and Barry M. Maid’s (1986) review of “Prewrite.” In 1987 the journal published Lee Roger Taylor Jr.’s “Software Views: A Fistful of Word-Processing Programs” under a “Software Review” banner and continued that with Robert Boston’s (1990) “Review of Collaborative Writer.” By 1992, Johndan Johnson-Eilola’s “Structure & Text: Writing Space & Storyspace” was published under the more general “Review Essay” banner, after which the software review genre mostly disappeared from the journal. Bradford Morgan’s Research in Word Processing Newsletter, which was published throughout the 1980s, also featured the occasional software review. By the late 1990s, however, the software review no longer had a home in Rhetoric and Composition’s professional publications.

There are a few exceptions worth noting. The recently launched (January 2018) journal Research in Online Literacy Education has a tech reviews section, but it is focused on teaching technologies. The Kairos PraxisWiki occasionally publishes software-focused pieces with an emphasis on practical use (and often pedagogy), such as Aaron Beveridge’s (2018) “The Markdown Movement: Writing’s Influence on Markup” and Steve Marsden’s (2017) “Using Evernote to Encourage and Monitor Student Research.” Mostly, however, the PraxisWiki pieces focus on broader pedagogical practices and tangentially considers the software related to them. Similarly, the blog Profhacker often posts about new writing or research software, but these posts are typically quite short and draw attention to an app rather than seriously consider how that app might function in a range of composing contexts.

Instead, we argue that the software review can serve an important professional function—one that aligns well with workflow mapping and thinking. As an example of what these reviews might look like, we point to Serenity Caldwell’s (2018) review of the iPad. Caldwell’s review is composed on the iPad, and her review shows her doing a range of work across several apps: drawing, writing, manipulating video, opening files, and more. Her review also includes a technical note describing the software used in and the process of composing the review. In Serenity’s hand-drawn review, we gain an understanding of what the platform can do, but we also see how she uses it. The review is both technical (in terms of examining functional literacies) and rhetorical (asking what a user can produce with the tool).

John Siracusa’s annual reviews of the Mac operating system—published on the tech blog Ars Technica from 1999 to 2014—offer another possible model of the software review. Siracusa’s reviews are notable in the tech community because of their length. “Long form doesn’t even begin to cover it,” Ars Technica senior editor Lee Hutchinson wrote about Siracusa's reviews, as “a Siracusa review could stretch to a [Content Management System]—breaking 30,000 words and beyond." In his reviews, Siracusa would painstakingly detail every change, tweak, and revision to the Mac operating system, leading users through a comprehensive tour of what happened when they updated their Mac.

Some parts of Siracusa’s reviews were explanatory or descriptive, noting how the software had changed over the previous year:

Notification Center changes its appearance, animation, and purpose in Yosemite. It still slides out from the right edge of the screen, but it’s now a sheet of dark vibrancy that overlaps the screen rather than pushing the entire screen image to the left. A tab bar at the top switches between the interface’s two functions: displaying notifications and showing an iOS-style “Today” view. Everything that’s not a notification (e.g., the widget used to send an instant message or write a tweet) has moved into the Today view. (2014, Notification Center section, para. 1)

Siracusa would describe changes in the software, but he would also contextualize the logic behind those changes for the reader. For example, in describing how Apple’s Safari web browser started hiding a website’s complete URL (and showing instead just the domain), Siracusa wrote:

This leads to the second reason to bring the iOS-style address bar to Safari on the Mac: simplicity. Though we technology enthusiasts may consider URLs an integral and well-understood part of our Web browsing experience, the vast majority of people have little interest in URLs beyond the one part of them that is commonly understood: the domain name. Everyone knows what google.com is, but few people know or care about the alphabet soup of text that may follow the domain name. If you accept this premise, the iOS-style design follows naturally. Rather than adding elements to the address bar or trying to visually differentiate the components of the URL, Apple has chosen to reduce the visible address to the one part that people understand—which also happens to be the one part that matters when it comes to avoiding URL-based phishing attacks. (2014, Safari section, para. 1)

Siracusa would also use his review as a place for critique, consideration, and speculation. In the following excerpt, he considers MacOS’s adoption of transparent interface elements:

Apple has taken great pains in Yosemite to ensure that any content that does show through transparent interface elements is extremely diffuse and indistinct. But the aspects of the background that do show through—mostly color—are often magnified. Inevitably, I find myself searching for a reason. Why is it important for me to see any aspect of what’s behind the front-most active window? Why risk reducing both the usability and attractiveness of the UI? To what end? (2014, Philosophy section, para. 1)

Siracusa’s reviews were expansive, thorough, and critical. In later years, Ars Technica packaged them as ebooks, allowing subscribers to read them offline in multiple sittings and file them as reference material. Although Siracusa stopped writing the reviews in 2015, many tech bloggers have continued the genre. Federico Viticci’s MacStories blog often publishes long-form reviews of Apple software, such as Tim Nahumck’s (2018) review of the iOS writing application Drafts, which offers more than ten thousand words of examination and reflection about a single iPhone writing application. Nahumck’s review walks the reader through the application’s interface, explores the advanced features, and contextualizes the app within several specific writing scenarios. It is part instructional manual, part model, and part inspiration.

Although we can find many examples of these long-form software reviews on tech blogs, there isn’t a parallel in the field—and we think there should be. Writing Studies–based software reviews don’t have to dwell in the technical details like reviews in a trade journal or tech blog might; instead, reviews of writing software by writing specialists could critically consider the application and its potentials for writers and writing teachers. These reviews could examine the functional affordances of writing tools, critically read the design, and consider how the app might fit into personal workflows. And they could do so by drawing on disciplinary knowledge and theory.

More important, the software review could do what the book review already does for published scholarship: situate artifacts (in this case, writing technologies) directly within our disciplinary conversations. The review would position writing technologies as an object of inquiry, as something central to our disciplinary expertise about writing, and as something to be explored, shared, and discussed.

The Workflow Narrative

The workflow narrative is a common genre, and readers of this book might have already encountered it in blogs or conference presentations. The workflow narrative typically presents a contextualized and personal approach to dealing with writing tasks, project management, or some other facet of knowledge work. These narratives often begin with an exigence (I wanted to plan a new article while waiting for car service at my local mechanic) or experience of friction (Each semester, I find myself creating the same folder structure for new classes) and then move into a rich description of the problem solved and the technologies and practices that were used in doing so. The narrative provides specific examples of how to use writing technologies in applicable practices, and it directly connects to workflow thinking by encouraging the reader to imagine how that technology might fit into their process.

These narratives also present a workflow as shareable knowledge. Workflow narratives are often filed under “lore” or are read as a “what works for me” documentation, perhaps because of their seeming similarities to the frowned upon what-I-did-in-class-today pedagogical genre. We want to push against that. Workflow narratives can provide us with concrete data on how writers use technologies in specific contexts and practices to accomplish a goal. They also model technology use and they expand our understanding of what is possible with a given writing tool. And like the software review, these narratives can help to reposition writing technologies as a central point of disciplinary focus and expertise.

For example, the Omni Group (a software development company) collected workflow narratives as part of its Inside OmniFocus marketing materials for the OmniFocus application. OmniFocus is a complex project management tool, and the narratives help users see how the app functions in day-to-day work contexts—showcasing personal hacks and how-tos. In her Inside OmniFocus post “Spending Time on What Matters,” Polina Burkart narrates how to organize daily tasks with syntactical priority markers:

Don’t fall into the Amazon trap. What is the Amazon trap, you ask? That’s when you need to order a new Brita filter and spend an hour reading reviews on Amazon because it’s so important that you order exactly the perfect filter. Think about the diminishing returns on your time, and aim to spend more (80%) of your time and energy on what matters and less (20%) on the Brita filters in your life. To help me with this, I order my tasks by importance and amount of time/energy to complete. I use the contexts @!, @!!, and @!!! to help me prioritize and not fall into the Amazon trap.

@!: Tasks that will take a relatively short amount of time or minimal energy. @!!!: Tasks that will take a significant amount of time or that will require quite a bit of focus/concentration. @!!: The in-betweens. I usually can identify what really should go into @! and @!!!, and then everything else goes into @!!. (n.d., para. 5)

Burkart is describing how she uses the OmniFocus "contexts" feature, which was originally designed to mark the physical spaces in which work occurs—at home, at the computer, at the office, and so on. Users, however, have found new ways to bend that software feature, and Burkart’s energy-based system of @ symbols and exclamation points helps users imagine new ways of organizing tasks and to-do lists.

Workflow narratives are common genres in academic blogs, and we could point to many examples, such as Raphael Kabo’s (2018) workflow for writing academic documents in Markdown or Daniel J. Vreeman’s (2015) tutorial for using Scrivener to write scientific papers. The blog and forum-centric nature of the genre has many upsides, most notably that it encourages a sort of give-and-take conversation. In discussion threads and comment sections, many of these narratives feature lively conversation about the process, with other users asking questions and offering their own modifications. However, we argue that the workflow narrative should also have a home in professional journals, a space where it can be more centrally located—and preserved within—the disciplinary conversation about writing.

By making room for these narratives in our scholarly publications, we can help move them beyond lore and into shareable disciplinary knowledge. This comes with several benefits. These narratives, for example, highlight the specifics of labor and the work of writing technologies within it—modeling disciplinary practice and demonstrating the work of writing (and knowledge) technologies. They help others see how we do our jobs—from drafting an article to running a committee meeting—and show how writing technologies are woven throughout that work. They also provide historical accounts of how writers use technologies. For example, academic journals from the 1980s show a market that was teeming with word processing software. Today, however, accounts of those technologies tell us little about what they looked like or how they were used. Workflow narratives can capture accounts of writing technologies and preserve them for future readers.