Fig02. Workflow maps, which we introduce in chapter 6, use layered diagrams to consider how writing practices and preferences accrete over time.

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

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

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

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

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

Fig44. My first attempt at file management was creating a new file every day with a well-defined naming scheme.

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

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

Fig47. In the above map, my two interests—computing and writing—are disconnected.

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

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

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