Table of Contents

Writing Workflows / 6: Workflow Mapping

Chapter 6: Workflow Mapping


We have envisioned this as a book for writers. More specifically, we’ve hoped that the methods and narratives discussed will inspire writers to look more carefully at their tools, environments, and dispositions. But many writers—especially those working and teaching within higher education—are wary of such calls when they relate to writing technologies. We see this as the product of many complex factors: Most schools and employers offer a sanctioned and familiar writing technology (currently, Microsoft Word), and learning a new technology means moving outside an institutionally supported system; adopting or changing a technology—especially a computer-mediated one—can introduce initial complications and pain points; and time spent learning something new (or even considering how or why one might adopt something new) is time not spent on the actual work of putting words onto the page or screen. And a discussion of writing technologies can tap into a broader sense of vendor fatigue—a sense that all these new tools and technologies get in the way of simply doing the work.

These are all reasons why we aren’t going to close this book by suggesting that you try the apps Ulysses or OmniOutliner or buy a Baron Fig notebook or any other specific writing technology. Instead, we want to step back and recommend a broader practice of meta-awareness, encouraging writers to consider why they have chosen particular writing technologies or practices, how those technologies and practices shape their process, and what a change to those practices might offer.

In chapter 1 we argued that workflow thinking offers writers a way to rethink and reevaluate how they approach knowledge work. In this chapter, we introduce workflow mapping, which provides a visual, spatial, and reflective means of examining a writing process. Where workflow thinking is a future-focused approach, workflow mapping focuses on current and past practices. Through mapping, a writer foregrounds the role of mediating technologies, asking why they’ve chosen to use those technologies and how they shape the writing process. The map can function as an analytical heuristic (we could, for example, map David Sparks’s workflow), but here we position mapping as a personal, reflective practice—a means of facilitating workflow thinking.

In this chapter we define and contextualize workflow mapping, which we situate within discussions of writing process and the types of composing activities introduced in chapters 3, 4, and 5. We also dive into our own writing practices, using maps as a way to examine our practices and affective preferences. Through videos, images, and narratives, we model mapping and take an autoethnographic approach to our own practices. In doing so, we hope to offer a pedagogical counterpoint: although workflow mapping can work as an instructional exercise, it must begin as a personal practice. We wouldn’t recommend that anyone try to teach or demonstrate mapping without first examining their own practices.

Finally, this chapter concludes with recommendations for two workflow-focused scholarly genres. Both workflow thinking and mapping point to the possibilities of new composing technologies, but new composing technologies aren’t often the focus of academic inquiry. We suggest that two genres—workflow narratives and software reviews—can position writing technologies more centrally within academic conversations and practices. Although the chapter ends with a broader call for the prominence of writing technologies within the field, it begins with the much more personal act of mapping, asking how technologies function in personal practice.

Workflow Mapping

Workflow maps are visual, spatial, and reflective considerations of the roles of tools, technologies, and mediation within a writer’s process. They are a means of developing workflow thinking, and mapping helps the writer consider how she develops and iterates on a writing process through writing environments and technologies. At first glance, a workflow map might look similar to the organizational flowcharts and diagrams used in business contexts. Those business-centered genres align with what Patricia Sullivan and James E. Porter (1997) describe as a modernist mapping exercise: “The assumption of a modernist mapping strategy is that the map represents information about an existing and static reality. Such maps are used more for organizational and representational purposes than for heuristic ones” (79). A corporate flowchart might match that description, acting as a prescriptive visualization of how a task should move from origin to completion. Although that flowchart might help a business to quickly produce more units of a product, it isn't a helpful model for writers. Instead, we see workflow maps as an instance of Sullivan and Porter’s "postmodern mapping"—a term that points to mapping as “one tactic for constructing positionings of research that are reflexive” (78). Rather than describing a static reality, postmodern mapping centers on a map that “can be judged, we think, on what it allows, what it blocks, what else might be pictured, how it freezes time, and how it allows time to escape” (80).

"Mapping" can be a troublesome term. Maps are ideological texts—documents that “are seen as complicit with social-control mechanisms inextricably linked to power and authority” (Barton & Barton 2004, 235). However, as Carolyn Rude (2009) reminds us, mapping—used thoughtfully—can be a productive metaphor: “Maps show spatial relationships and provide directions. Paths through geographies, systems, and buildings can be hard to represent through words alone. Maps encourage movement and exploration and the breaking down of boundaries. Maps identify spaces and call for attention: To ‘put it on the map’ is a way to emphasize an issue, idea, or program by giving it a space” (178). By mapping their workflows, writers can make space for metacognition, and they can examine and emphasize how mediated practices work within—and change across—the writing process.

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:

Workflow map for drafting a speaker introduction
The workflow map helps us to see how the writer moves across a number of composing spaces and technologies as she moves toward a complete draft.

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.

Workflow map for drafting a speaker introduction with DevonThink added
Here the writer adds the DevonThink database application (noted through the app's icon of a blue nautilus shell) as a digital commonplace book. The map helps her see where the database might fit into her process, and the faded remnants of a notebook help her see how past practices inform new ones. There's also a minor shift in the arrows marking movement across technologies. Although the database facilitates preservation and recall, the map shows how it might limit flexibility.

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.

Worfklow maps showing a Word document leading to a Google document leading to a question mark
In making this workflow map, the writer sees movement between MS Word and Google Docs (represented here by their application icons) but isn't sure how to think about file management and backup.

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).

Workflow map showing a Scrivener document leading to an advisor and back
This simple workflow map, showing the movement from a Scrivener file (represented by its app icon) to an advisor, points to challenges with the Scrivener file format. How will the writer share the document? Does the advisor use Scrivener, or will the writer need to export to a different file format? And how will the writer incorporate feedback and notes into her copy of the Scrivener document?

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.

Workflow map showing a Scrivener document leading to an advisor and back
The writer has decided that she will export her Scrivener project to a Word file for advisor feedback. This solves the sharing part of her workflow, but the new map signals a possible point of friction: how will she bring the Word comments back into the Scrivener file?

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.

Mapping our workflows

As we developed the concepts of workflow thinking and mapping through our analysis of the case studies in chapters 3, 4, and 5, we also considered our own practices and histories with writing technologies. In the videos and maps below, we share those histories of workflow thinking and produce maps to represent some of our current writing practices.

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.

To view this video please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

Derek demonstrates the succession of practices and applications he has used for file versioning, from saving discrete files to using various version control systems.

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.

Workflow map showing a Word document dated 2006-06-07, leading to a Word document dated 2006-06-08, leading to a folder named my compiled dissertation
My first attempt at file management was creating a new file every day with a well-defined naming scheme.

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).

Workflow map showing a computer pointing toward a set of documents that say commit and then a document that says commit log. Behind it, the previous map is visible.
Instead of saving new files every day, I moved on to using version control software. These tools let writers create a descriptive log of each meaningful change in a file and store the additions and deletions along with that log message.

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.

To view this video please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

The practices I developed for using version control systems led me to leave Microsoft Word as a writing tool and experiment with other software. By moving to plain text file formats, I have been able to use a variety of tools to work with the same files. Depending on the various trade-offs I decide to make for any given project, there are a number of tools I can choose to work with.

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.

Workflow map depicting three different options: a Word document and commit log leading to a stop icon; a Scrivener icon leading to a stop icon; and an icon for the Atom text editor, a commit log, and an image of an advisor.
This workflow map depicts the roadblocks I encountered with various combinations of tools. First, I was not able to take advantage of version control features while using Word files. Next, I was not able to collaborate with coauthors while using Scrivener. Lastly, I have found that I can use the Atom text editor, along with the Git version control system, to write with a coauthor while meeting all of my technical and affective writing requirements.

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

To view this video please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

Tim traces his workflows to MS-DOS and Windows 3.1.

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.

Sketch of notebooks and a computer directory structure
In the above map, my two interests—computing and writing—are disconnected.

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.

Sketch of notebooks with arrows pointing to a computer screenshot
Ethan Schoonover's Kinkless template for OmniOutliner helped me to see how the computer could assist with personal organization, generating a link between my interests in computing and knowledge work. In this map, I can see how my interest in the Kinkless template replaced (but was also informed by) my interests in tinkering with the file system, which is represented by faint shadows in the map.

To view this video please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

Through apps like VooDooPad and DevonThink, I explored the possibilities of a personal database.

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.

Worfklow map with icon for the VooDooPad application added
As I started writing with VooDooPad (represented in this sketch by its app icon of a cartoonish voodoo doll on a clipboard), it linked into all of my work—texts, binders, and organizational software. The personal wiki was a place to collect everything.

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.

Workflow map with DevonThink icon at center
When I found the personal wiki too constraining, I turned to DevonThink (represented here by its blue nautilus shell icon), which offered a much more robust personal database. It also occupied a more central place in my process.

As my workflow map changes, the outlines and shadows of past choices show how they still linger in and inform my workflow.

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.

To view this video please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

Evernote soon found a place at the center of my workflow.

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.

Workflow map with Evernote at center
Soon, Evernote (here represented by its green elephant logo) was at the center of my process—replacing DevonThink and VooDooPad but still informed by those practices. In this map the iPad has taken the place of notebooks but does much of the same work.

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.

workflow map with Evernote at center
Sublime Text gave me a writing interface I liked, but it added additional complexity to my workflow.

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

To view this video please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

I would later use Scrivener and Ulysses as my primary writing environments.

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.

Workflow map with Ulysses at center
Ulysses allowed me to continue with a set of computational practices I've developed over the years, but it replaced many different apps, offering a simpler (and less app-intensive) approach.

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.

Workflows and scholarly genres—Ways forward

Throughout this book we have argued that attention to workflows can help us to better understand and highlight the role of mediating technologies in a writer’s process. But how do writers learn about new technologies, especially in an academic context? How can we see or share use cases for new tools without wading into marketing materials or suffering through vendor sales presentations?

We conclude by pointing to two possible scholarly genres—the software review and the workflow narrative—that can help to center workflows within the disciplinary conversation around writing. These genres aren’t entirely new: The software review has much in common with the book review and briefly appeared in Computers and Composition in the 1980s, and the workflow narrative often appears in conference presentations and on academic blogs. However, by moving these genres more centrally into our scholarly publications, we can both foreground and preserve them—calling attention to the importance of mediating technologies within the study and teaching of writing.

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 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.


At the start of this book we argued that specialists in Writing Studies don’t regard their personal mediated preferences and practices as a shareable form of knowledge beyond the level of the individual narrative. In this closing chapter, we’ve offered a metacognitive practice (workflow mapping) and scholarly genres (the review and the narrative) that can bring additional awareness to the tools and technologies that writers use. When combined with workflow thinking, these approaches offer subtle shifts for those working in the field of Writing Studies—a way of pushing the mediated specifics of writing beyond lore and into a more central place in the discipline.

Our goal isn’t to celebrate a specific technology or to encourage the adoption of a specific tool. In fact, we’re wary of anyone who says you must use a particular tool to accomplish a task. But we’ve spent years following the workflow affinity space of Sparks, Terpstra, and Viticci, and we’re persuaded by their approach: one grounded in a mantra of “What are the possibilities here?” By beginning with this question, they invite creativity and exploration while also acknowledging that different writers prefer to work in different ways. Similarly, we hope that the broader practices of workflow thinking and mapping can help writers better imagine their work across a variety of tools and spaces—from notebooks, to whiteboards, to custom computer scripts—as well as learn about, be creative with, and mindfully adopt a broad range of writing technologies.

We also, at the start of this book, pointed to the messy histories and connotations of the word "workflow"—a point worth returning to in this closing section. We hope that this book has made the case against workflows as deskilling or industrial-focused and has instead repositioned them as a personal practice grounded in mindfulness and craft. That kind of mindful inquiry happens throughout the workflow affinity space, as evidenced in blogs, podcasts, and discussion boards, and we have much to learn from it. But we also acknowledge that Sparks, Terpstra, and Viticci have a certain set of goals and interests. They often chase states of flow or efficiency or frictionless work—values that echo computer science and computer-adjacent industries. In expanding the audience for workflows, we hope that other writers can push against these perspectives and show how workflows can be adopted and used in different ways with different priorities.

The enthusiasm for writing technology in the workflow affinity space echoes the creativity and experimentation found in early computers and writing conference publications. By bringing workflows into conversation with process and writing theory, we hope that the genres and practices we suggest can bring more people into the conversation, moving writing tools and technologies into a conversational space that is creative, critical, and experimental—and most important, welcoming to all.