Introduction

In his 2003 review of twenty years of Computers and Composition, Charles Moran describes what many wished computers would do:

A hope often articulated in the early volumes of Computers and Composition was that computers would eliminate what the authors defined as drudgery, both for student writers and writing teachers. . . . When someone characterizes an activity as drudgery, that act of classification confers low status on the activity. Drudgery is work that we wish would go away, work that we wish we could be freed from so that we might get on to other, more satisfying, more useful work. (345–46)

Moran points to other machines to which we delegate “low-status work”—the “dishwasher, lawn mower, vacuum cleaner, slicer-dicer, or rug shampooer” (346)—and notes how early research in Computers and Composition searched for an analog in the computer and word processor. The possibilities of automated work at that time often pointed to the drudgery of teaching or assessing writing, specifically “copy-editing, revising, and retyping” (346). From Hugh Burns’s TOPOI, to Bell Labs’ Writers Workbench, to Homer and WANDAH and Writer’s Helper and countless others, the field spent much of the 1980s developing microcomputer software in the hopes of eliminating, or at least reducing, drudgery. Although several popular writing applications were created by commercial developers, much of the development of writing software happened under the guise of English teachers. “Who are these people spending so many hours developing computer programs?” William Wresch asked in his 1984 introduction to The Computer in Composition Instruction: A Writer’s Tool. “First and foremost,” he answers, “they are English teachers. . . . They are not a group of computer hackers who suddenly decided to start creating programs in writing instruction” (6–7).

The vision of writing tools pioneered by early Computers and Composition scholars continues to echo in contemporary software. The spelling, grammar, and usage checkers built into most major contemporary word processors (such as Word, Pages, and Google Docs) call back to early writing software tools and many early automation efforts. Today, text editors and writing applications such as Hemingway, Write!, and Grammarly offer tools that can (to better and worse degrees) facilitate copyediting and revision. However, for the most part this work is no longer happening within the field—or even with the consultation of experts in the field. With a handful of exceptions, we are no longer writing teachers writing software, and we no longer research automation. ¹

Automation, however, continues to live on in professional writing contexts. Examples might include the copyeditor who uses a Word macro to change APA references from sentence case to title case, or the InDesign editor who automates the conversion of typography elements through a bespoke in-house application. In these workplace cases, the writer isn't using the computer to assess sentence variety or automate the teaching of a grammar construct; instead, the writer is using the computer to replicate a task—to do some monotonous work.

In this chapter we explore Brett Terpstra's blog writing workflow, paying special attention to his creation of a script to automate the process of adding hyperlinks to a post. Through an activity-based analysis of his SearchLink computer script, we argue that automation is a productive art—a practice that results in a composed object (the script or program) that functions as a new actor mediating writing activity. In composing computer scripts (the software that produces automation), writers demonstrate the kinds of reflective and metacognitive awareness valued in the field.

Through the case of SearchLink, we can examine how the script draws on and contributes to Terpstra's "just write" ideology, which privileges uninterrupted focus, attention management, and the affective dimensions of writing. We position Terpstra's approach to automation as evidence of his workflow thinking. Whenever he is not able to "just write," Terpstra experiences friction and seeks to better understand the task and identify new workflows.

Terpstra is especially known for reducing friction. In our interview with him, he described his career by saying:

I make a living finding those problems and selling people things that they don’t even know they need yet, or fixing friction that they just found out they had. And so I’m hyper-aware of anything that I think could be faster or easier or automatic.

For Terpstra, this happens by reading for friction. In looking at a writing process and asking, "What could be faster or easier?" Terpstra imagines how a change in writing technologies might reshape his work. For him, this search is about getting to a place where he (or someone who uses his software) can "just write," but reading for friction can also serve other purposes—exploring the possibilities of constraints or facilitating creative approaches to routine tasks.

Our approach in this chapter is to examine the friction Terpstra identified in his blogging workflow and how and why he eliminated it through creating and using SearchLink. As explained in chapter 2, this approach follows sociohistoric and actor-network theory in attending to “genesis and disruption” or “things in the making and things breaking down” (Prior 2008, 15). During such moments it is possible to see and follow the actors and motives that drive practices and activity in a way that is much more difficult when such practices are black-boxed and habitual. In order to fully understand what the SearchLink workflow means to Terpstra and how those meanings are formed, this chapter follows the actors by examining the technologies, people, infrastructures, and environments that played a role in the disruptions leading to the genesis of SearchLink.

Blogging Friction

Brett Terpstra has a good deal of expertise in web technologies, yet this expertise does not make working with them frictionless. In this section we briefly survey the history of blogging from a technical perspective in order to illustrate the various ways software and scripts have attempted to relieve this friction and to show where Terpstra's blog writing workflows fit into this history.

In the web's early days (ca. 1997), writing for the web introduced complexities beyond what writers working with word processors may have encountered. Beyond the rudimentary file management required by word processing, web writing involves creating multiple HTML files, organizing them in folders, and uploading them to a web server online. The difficulties of these practices—especially in pedagogical contexts—are documented in late '90s scholarship (Mauriello, Pagnucci & Winner 1999; Gresham 1999). Furthermore, writing in HTML, instead of the familiar print-like environment of a WYSIWYG word processor, involves writing in HTML markup—typing angle brackets and other odd characters and remembering the abbreviations for common tags.

Early blog software removed some of these complications. Blogger and Pitas first appeared in 1999 (Blood 2004, 54; Walker Rettberg 2014, 9) and allowed writers to create blogs without setting up a server or managing files. Users could then write blog posts without knowing any HTML. As Blood (2004) remarked, "I sometimes wonder whether the new bloggers knew enough HTML to construct a link. Whether they did or not, Blogger was so simple that many of them began posting linkless entries about whatever came to mind" (54). Blood contrasted these "linkless blogs" to the "filter-style Weblog," arguing that "filter-style" "could become an important new form of alternate media," while the "linkless blogs" contained merely "entries about whatever came to mind. Walking to work. Last night's party. Lunch" (54).

While Blood implied that the ease of Blogger and similar tools led to more frivolous writing on blogs, Torill Mortensen and Jill Walker (2002) offer a different perspective. They describe the ways blog software shapes their writing activity, contrasting Blogger with Tinderbox, a hypertext authoring application. Rather than seeing the Blogger interface as discouraging or obscuring links (as Blood suggests), they show how the "blog this" button Blogger provided via its toolbar "eas[ed] the connection between online reading and writing—if you click the button while viewing a Web page, Blogger will automatically set up a writing space for you with a link to that page and space for you to write your comments" (254). They contrast this ease of composing and publishing a post while reading online with the "much more complex ways of writing and linking notes" (255) afforded by Tinderbox.

Although Blood positions Blogger as bringing perhaps too much ease to the composing interface, she frames the software as also introducing unneeded complexity:

In 1999, Weblog software automated a process that was so simple any Web generalist could do it by hand. Since then, toolmakers have introduced such complexity into the Weblog form that only a programmer is able to reproduce their results. Like a 1930s automobile mechanic contemplating a fuel-injected engine, I can only scratch my head. Modern Weblog technology accompanies each post with such a conglomeration of pings and scripts that I can never hope to keep up. (55)

While the process of hand-coding HTML pages to update one's blog may be simple, even bloggers with technical expertise found compelling reasons to automate their blogs with software. In the early 2000s, software like Radio Userland and Movable Type provided similarly simple composing interfaces as Blogger but also let users host their blogs on their own server, either by producing a folder of HTML files to be uploaded to a web server or by installing the software on the server itself.

Initially, none of these blog tools offered WYSIWYG authoring tools in their interfaces, requiring that users still type HTML for formatting text. However, software such as Movable Type or Blosxom soon supported Markdown plugins, which converted text written in Markdown (a simplified HTML syntax) to HTML upon posting.

We might use the <strong>strong</strong> tag to bold words, or the <em>emphasis</em> tag to italicize them.

We might use the **strong** tag to bold words, or the *em* tag to italicize them.

Removing the requirement of writing in HTML serves to reduce a good amount of friction for bloggers. Writing HTML, and reviewing HTML documents for editing and proofreading, could be tiresome. Consider the HTML link element, which a blogger might use frequently. It is cumbersome: it requires a URL, at least one attribute value (often more), and a seemingly empty “a” tag.

<a href="http://www.digitalrhetoriccollaborative.org">Digital Rhetoric Collaborative</a>

Visually, the link tag disrupts and obscures the anchor text, and a paragraph filled with link tags is difficult to proofread and edit.

In Markdown, the long link element is replaced with anchor text in square brackets and a URL in parentheses:

[Digital Rhetoric Collaborative](http://www.digitalrhetoriccollaborative.org)
    

Writers who find the URLs distracting can optionally move them to the end of the paragraph or document:

The [Digital Rhetoric Collaborative][1] houses reviews of presentations from the recent [Computers and Writing][2] conferences.

      [1]: http://www.digitalrhetoriccollaborative.org
      [2]: https://candwcon.org/2018/
    

Beyond simplifying the addition and display of links and URLs in documents, Markdown allows writers to work around other cumbersome elements of the syntax (including the requirement of wrapping every paragraph with a “p” tag and simplifying emphasis and strong tags).

Both Movable Type and Blosxom used graphical interfaces that presented authors with text entry areas in which to compose their posts. Movable Type saved the posts in a database, while Blosxom saved posts as regular files in folders. Both tools output static HTML files to a web server. Many contemporary blogging tools with similar graphical interfaces, such as WordPress or Drupal, work dynamically instead, so that the web pages are generated via scripts when users visit each blog page.

These dynamic tools have many affordances but also some important drawbacks. Their dynamic elements rely on software that opens one's blog to attack by malicious code, which means bloggers must constantly stay up to date on the frequent security updates. Today there are popular blogging tools that eschew databases and work similarly to Blosxom in that they consist of a collection of discrete files authored in Markdown. However, these new tools, called "static site generators," often have no graphical interfaces at all. Users create a collection of Markdown files and HTML and CSS (cascading style sheet) templates, then run a script that compiles these files into the actual HTML and CSS files that are then copied to a web server. Writing a new blog post with such a system means creating a new Markdown file and then running the script again, which will create or update the relevant HTML files that are then uploaded to the server.

In 2011 Terpstra moved from WordPress (a dynamic site tool) to Jekyll (a static site generator). As he noted in his blog post introducing his interest in switching, with Jekyll “the speed and stability increase is immense” (Terpstra 2011, para. 1). Over the course of the next year, he posted several accounts of the various scripts and web design techniques he was employing in building the new site with Jekyll. A year and a half later, though, as he reflected on the change, he remarked:

Over the course of building this new site, I’ve realized that I really don’t have many issues with WordPress, and Dreamhost has always been pretty stable for me. I just get antsy and want to try new things, so I’m giving this a shot. (Terpstra 2013, para. 2)

Terpstra’s blog follows the conventions of many blogs that focus on the same family of activities surrounding Markdown. There are software reviews (e.g., Mindmeister, Übersicht, and Day One), tips and tricks related to Markdown, the occasional post related to Apple software and hardware, and other technology-related topics.

One of the key features of these blog posts is that they often include links to other materials: other web pages or apps in the Mac or iOS app stores. In Terpstra's blog, links to other web pages include links to blog posts written by others or older posts on Terpstra's own blog, links to home pages for software applications, and links to Amazon products. Some posts (which appear annually, including 2011, 2012, 2013, 2014, and 2015) include dozens of links to software applications on the Mac and iOS platforms along with mini-reviews.

While Terpstra writes these posts in Markdown, and thus is able to use the more efficient and easier-to-read linking syntax afforded by it, it can become tedious to create these links when writing posts with dozens of links or writing several posts a week with several links each. To create each link, a blogger working with Markdown still has to locate the correct URL and enter it into the document. The most manual, straightforward way to do this would be to open a web browser and find the page one wants to link, either through a search engine or by navigating to a site and then locating the specific page within that site's menus or organization. Once the right page has been found, one can copy the URL and paste into the Markdown document.

However, this task can also be automated in several ways. One method of automation is batch processing, or taking a series of tasks a person might accomplish at different times throughout a work session and instead completing them one after another immediately. Batch processing is a technique that predates computing, of course, but for tasks that can be accomplished with computers, batch processing speeds them up immensely. Before writing SearchLink, Terpstra created a script to batch process the copying and pasting of links from a web browser. To use it, a person simply opens each web page they want to link in separate tabs of the web browser window. Then they invoke the script, which copies the URL from each open web page, and they then paste that list of URLs into the Markdown document as a block of reference links. They can then add the links to the document by referring to the reference link name, either while composing or after the document is already composed.

Automation always involves trade-offs, and batch processing links in this way does as well. First, writers must know what pages they want to link before invoking the script. It's certainly possible to paste useful links with the script before drafting and then manually seek out additional links if they become necessary. Similarly, it's possible to draft the document, leaving placeholders for the links, and then collect them at the end of the session. However, efficient use of the script would seem to encourage locating all the pages ahead of drafting the document: this way links could be added while drafting without needing to leave placeholders that need to be filled in later. One workflow that works well with the script is a research phase, which might include drafting notes in a document and keeping an open browser window with tabs relevant to the project. Then, when the research is complete, all the URLs from the tabs are pasted into the document by the script and the document can be composed.

Such a workflow privileges a writing process focused on "putting words on the page." Proponents of such a process see the goal of a writing session to be getting as much text written as possible without switching to other activities (like searching for a particular web page or locating and reading a reference text). We would argue that Terpstra's interest in this process led to his creation of SearchLink and that his use of SearchLink continues to strengthen his commitment to this writing process.

SearchLink

While adding all the links for browser tabs can help a writer with "putting words on the page" without having to bounce back and forth between the browser and text editor, it does require going to the browser at some point to open all those pages. Even this bit of friction was removed in late 2012 with Terpstra's creation of SearchLink. This script automatically adds web links to text through the use of a special syntax, no browser tabs required. “When you’re writing or blogging,” Terpstra writes on SearchLink’s homepage, “it’s time consuming to think about linking as you go. With these formats [provided by SearchLink], you can basically leave a note about what a certain phrase should be linked to and keep writing. When you’re done, run SearchLink on the entire selection and all of your ‘noted’ links will be updated [to web links]” (Terpstra 2016, para. 13).

[The Sweetland DRC](!g Sweetland Digital Rhetoric Collaborative) hosts blog carnivals, reviews of conference sessions, and a wiki about the field.
    

Basically, while they are composing, writers indicate where they want a hyperlink to appear in the text, and then they write a search query (e.g., the same series of words one would type into the Google search field). SearchLink uses that search query to return the URL of the first hit and creates the hyperlink formatted with Markdown syntax.

SearchLink offers two main benefits for writers looking to create text with hyperlinks. First, it allows writers to include link placeholders in their text as they write, so they don’t have to move back and forth between composing and locating web pages and copying URLs into the text. Second, it removes the need to locate web pages altogether by adding the URLs automatically, based on the result of the search query.

In exchange for these benefits, SearchLink requires some additional expertise from writers. First, writers must create the text using the Markdown syntax (a simplified HTML syntax) instead of a graphical user interface or HTML itself. Additionally, writers must remember the special syntax for search queries (e.g., typing !g before the search query text returns a URL from a Google search; !a returns a URL from an Amazon search). More important, writers must be familiar enough with the search services and the result they’re looking for so that their search query will return the link they want as the first hit.

For teachers in Writing Studies, SearchLink may initially seem like an amusing or interesting tool for other writers but not something to use or teach to students. For a web writing course, or one where students will blog, it might seem appealing, but the additional expertise required to use SearchLink may outweigh the benefits it provides. Learning Markdown and the SearchLink syntax may not provide much benefit for writers still learning HTML or adding only one or two links per text.

And yet, regardless of whether one wishes to learn to use SearchLink or not, we chose it as an example of automation because it illustrates three key aspects of automation. First, automated workflows mediate writing activity, sometimes even reshaping the task (e.g., Hutchins 1995). SearchLink, as we explain in subsequent sections, changes blogging from a hypermediated (Bolter & Grusin 1999) activity involving shifts between web browsing and writing to a more immediate (Bolter & Grusin 1999) writing activity.² Second, SearchLink requires significant expertise on the part of the writer using it, demonstrating the possibilities for automation to avoid deskilling people. Further, the different kinds of expertise required to write the SearchLink script and to use it are rarely, if ever, examined in the field of Writing Studies. Third, SearchLink illustrates how automated workflows and scripts can be commodified and distributed through open source channels. This is an aspect of service that our field has not fully embraced, leaving software design to software publishers or others.

Ultimately, we see Terpstra's search for friction and the resulting automation as a helpful window into workflow thinking. Across our years of teaching, we've seen students and colleagues repeatedly bump into moments of friction (such as dealing with tedious file and folder structures or fighting against spellcheck and autocorrect), and we have watched as those students and colleagues attribute that friction to the finicky or arcane nature of computing technologies. But Terpstra's SearchLink challenges that perspective, instead pointing us back toward Moran's dream of erased drudgery and asking how the computer might minimize friction in writing. And Terpstra's case helps us see how the act of reading for friction offers new ways of thinking about and working with writing technologies.

Automation

Before moving forward, however, we should first clarify and offer caveats. When we talk about automation, we aren’t arguing for a renewed focus on machine grading (Ericsson & Haswell 2006), the use of plagiarism detection services (Purdy 2005), or improving spambots. Instead, we hope to point the field back toward the spirit and sense of invention prevalent in 1980s approaches to computing. Furthermore, we recognize that many efforts to automate tasks in recent decades have sought to deskill humans or remove them from the task altogether. We hope to counter these examples with depictions of automation that increases the active potential of the people who employ it. We are encouraging a return to the possibilities of machines, to consider how software and scripts might help us not just eliminate drudgery but how they might also encourage us to reconsider our composing processes. Automation in this sense isn’t simply eliminating or streamlining tasks; it is working alongside the computer and software to reconsider how and where we invent and compose.

This is not to say that we are promoting automation in all writing tasks for all writers. In pointing the field in this direction, we want to extend the spirit that Charles Moran describes in his 2003 retrospective:

In Computers and Composition, we are generally upbeat, optimistic, enthusiastic, and forward-looking—more so than we are in other journals. Our hopefulness is refreshing and positive. I’d not want us to be anything other than what we have been and what we are. In the pages of this journal when a hope is dashed, as it often is by our research, we do not lose hope, but transform it: If this application of new technologies doesn’t help, then this other one will; if it doesn’t seem to work for this student population, then we should try it with this other student population; if technology doesn’t improve this aspect of a writer’s work, then we should try it on another aspect of the writer’s work. (344)

This spirit was pervasive in computers and writing scholarship in the 1980s, and we can see those results in the scholarship and software produced. That spirit continues in the field’s scholarship today but mostly in questions about multimodal and web-based spaces. It appears less so in the case of writing software and specific scripts and tools. Independent developers, however, have carried forward that optimistic spirit within the context of alphabetic writing technologies, building tools that offer automative possibilities and affective interfaces. In exploring their work, we hope to return to the possibilities of automation within the field of Writing Studies—not as a way to prescribe process but as a way to explore the generative possibilities of automation within the context of workflows.

However, writing about automation brings with it considerable baggage. The term has seen significant movement in the field, from the early promises of erasing drudgery, to the turn against machine grading and automated assessment, to the current questions about algorithms and institutional writing software. Today, automation in the early twenty-first century also calls to mind questions of efficiency, labor, and industry as we move further into a moment where more jobs are replaced with automated industrial solutions. In many popular contexts and conversations, automation is the erasure of a human and ethical world, a space where bodies are replaced with machines and a commercial push for profit values efficiency above all else. These are all very real concerns, and we don’t wish to diminish them.

There are models in the field, however, that demonstrate how automation can transform literate activity in beneficial ways. Johndan Johnson-Eilola and Stuart Selber (1996), drawing on Shoshana Zuboff’s (1988) distinction between automating and informating, show how hypertexts can often display aspects of each quality. For example, they describe how a hypertext maintenance manual might speed up a maintenance person’s navigation and retrieval of information (automating their use) and afford new activities, like allowing users to communicate with one another (informate). They then suggest a new distinction:

Although the automating/informating distinction offers a useful starting point, what becomes primary (from our perspective) is not the specific characteristics of any one technology but how those characteristics are taken up, channeled, defined, and defied by people. Because most hypertext applications possess at least some degree of informating capacity, our point is not that a certain type of hypertext generates information while another merely automates processes. For those technologies that informate, what is done with that information becomes central. In other words, does a specific hypertext primarily contract or expand communication processes? (124)

That is, while automated activities are too often situated in contexts that lead to decreased autonomy and agency for people involved, they might otherwise be situated in a manner that supports people in transformative and empowering ways. This is not so easily realized within complex infrastructures, so we don’t want to suggest that such a change is straightforward or easily accomplished. As Bradley Dilger (2008) proposes, we can begin with disrupting assumptions. He argues that breaking assumptions about programmers (that only special people can be programmers and that it is “exclusive to experts” [132]) can help support writers who can use automation techniques to develop new writing practices. Similarly, we propose that the writing activities of our participants offer some examples of how automation might be reclaimed for textual production within the field. Through our analysis of their work, we argue that attending to writing workflows can help us to better define and contextualize approaches to automation.

Writers participating in the Markdown affinity space frequently write and talk about automation in terms of their workflows. These writers seek to use automation to remove friction in order to accomplish tasks more efficiently, accurately, or with more focus. Friction, for these writers, is invoked when they say there’s a better way to accomplish a task, when they note there are unnecessary steps in a process, or when they describe software as getting in their way.

For example, David Sparks told us about how his readers often lose the download codes for the digital books they purchased from him and write to him requesting new ones. Rather than finding new codes and composing a reply to each reader “by hand,” he created a script (with Apple’s Automator application) that generates new codes and pastes them into an email template. This type of approach ensures accuracy (there’s no risk of incorrectly copying part of the code and pasting it in a message) and reduces the friction found in a monotonous task. David Sparks is often an advocate for automating tasks on his podcast, but he identifies Brett Terpstra as the “mad scientist” (Sparks & Floyd 2013) of automation and scripting.

Using SearchLink

Terpstra’s development and use of SearchLink demonstrates a combination of rhetorical and technological expertise, and the SearchLink syntax assumes proficiency with search engine queries and logic structures. For SearchLink to be a helpful tool, the user needs to have confidence that their query will yield the desired website, which means some queries are better than others. For example, !g Conference on College Composition and Communication would be more successful than !g CCCC, and SearchLink is most helpful when the user has this sort of knowledge. Although it would be technically possible for SearchLink to offer the user an interstitial or modal window of search results and prompt for a selection from that list, Terpstra designed a more seamless application—one that relies on, but also is faster because of, the user’s ability to craft accurate search engine queries.

SearchLink also supports linking practices beyond those of typical web browsing practices. To directly link to an application in Apple’s App Store, Terpstra would have to open iTunes, search for the application, and find the redirect link to that application’s page. SearchLink can create that link without opening iTunes. Likewise, Terpstra generates blog revenue through referral or affiliate links, and he can modify SearchLink so that it appends his affiliate number to Amazon or iTunes URLs. Without SearchLink, these affiliate values would require, at a minimum, substantial and tedious copy and paste work for each URL. However, through his knowledge of scripting and his awareness of his writing practices, Terpstra can extend SearchLink to generate any type of link needed for his web writing.

Spotlight on Affiliate Marketing

Although many websites generate revenue through banner advertising and advertising networks, affiliate marketing has grown in popularity, especially through small and product-focused blogs. Affiliate marketing predates the web, but it quickly found traction in early internet spaces such as Prodigy (Walker 2013). Today, Amazon is a huge driver of affiliate practices; a blogger can write about a product, include an affiliate link to Amazon, and receive a commission if the reader purchases an item from that site. Affiliate marketing is more or less popular in different spaces; some online forums ban the practice entirely, while some bloggers, like David Sparks, often render the practice in friendly and familiar terms: "Either way, if you are going to buy the MacUpdate bundle and want to help pay for the site costs, buy through the affiliate banner on the left and I'll get $3 of the purchase" (Sparks 2008, para. 1).

The Wirecutter, a popular gadget review site, generates its revenue based on affiliate links and argues that the affiliate model is better than one supported by banner advertising, explaining:

All we can say is that the most important things to the health of this site are its reputation and its relationship with readers. Here’s why: We are going to recommend gear, no matter what, and we’re going to make our best efforts to recommend the things that we truly believe are worth the money. If we recommend something because we are biased or lazy and the pick sucks, you can return the piece of gear and we will make zero dollars. (Cheng & Lam n.d., para. 31)

The Wirecutter was recently purchased by the New York Times Company, which is perhaps a testament to the viability of this business model.

Affiliate marketing provides another way of looking at the ongoing news cycle of the gadget blogger. To generate revenue the writer needs to explain and endorse products that the reader will buy, which creates a model in which there’s always a next new thing—a tool to upgrade or an application to switch to. Although the affiliate link deemphasizes clickbait stories and paginated article design, it still finds the technology writer enmeshed in practices of ongoing consumption.

Terpstra has experience developing apps, and SearchLink directly draws from that experience; it isn’t a solution that a novice could easily build. It does, however, fit into a broader narrative in which Terpstra extends his skill sets and knowledge by developing solutions to problems and friction points that he identifies. That is, in order to build a tool like SearchLink, Terpstra has to (1) identify the problem or potential point of friction, (2) understand where that friction sits within his existing workflow, (3) know where scripts or applications can intervene within that workflow, and (4) develop a solution that fits within those confines. In doing so, Terpstra has to complete a metacognitive assessment, recognizing what he knows, what he doesn’t, and how he might learn and apply new technologies and practices. Each new project or script helps him better understand the potentials and boundaries of his writing technologies, shaping future activities and providing him with knowledge that might solve future problems.

"Just Write" ideology

As we alluded to previously, Terpstra is a committed proponent of a writing process aimed at composing a large chunk of text without switching to other applications or research sources. His development of SearchLink reflects his adherence to this workflow. In our interview, he described his preference for staying in his writing app while drafting to avoid opening a web browser:

The reason it started [developing SearchLink] was my biggest frustration with blogging was that I was constantly having to go run Google searches, switch out of the app I was writing in, run the search, come back, paste the link, give it a title, and all the formatting and all of that was just becoming—I realized that half of my blogging time, and this was when I was writing for TUAW [The Unofficial Apple Weblog], and it was actually, time was more of the essence in getting the blog post out—and being able to just highlight text and have the link inserted without ever leaving my application was a huge, huge deal for me.

As Terpstra explains it here, staying in the writing application is more efficient; it saves time and helps him publish timely blog posts more quickly. Additionally, there's another aspect to this kind of efficiency, a kind of conservation of attention or concentration. Such conservation is at the heart of the ideology underpinning workflows dedicated to "getting words on the page." Terpstra refers to this kind of workflow as "just write." As Terpstra describes SearchLink on the project page of his website:

SearchLink allows you to just write, marking things to link as you go. . . . When you’re writing or blogging, it’s time consuming to think about linking as you go. With these formats, you can basically leave a note about what a certain phrase should be linked to and keep writing. When you’re done, run SearchLink on the entire selection and all of your "noted" links will be updated. (Terpstra 2016, para. 2)

Although Terpstra doesn't explicitly identify increased concentration (or decreased distraction) as a benefit of SearchLink, it doesn't seem a stretch to infer that's part of what he's talking about when he says the tool lets users "just write". In a blog post announcing an update of SearchLink, Terpstra claims:

If you write in Markdown and ever switch away from your editor to get a link and haven’t tried SearchLink out, you should. I can say with a good amount of certainty that it will change the way you blog, email, and write. (Terpstra 2015, para. 3)

While speeding up the process of adding links to a blog post draft does qualify as a "change," we think that integrating SearchLink into one's writing process could lead to more significant differences than just speeding it up. Drawing on Edwin Hutchins's (1995) work on distributed cognition, we see SearchLink changing the activity of blogging by turning it into a "just writing" activity as opposed to a link gathering and writing activity. In other words, SearchLink shifts Terpstra's mental efforts from link gathering in a browser to search query construction while composing. Even if he were to type the same search query into the document that he would use in the web browser, he does not have to switch applications, review the page of results, evaluate them, or click on the best link. Given psychological research into the costs of task switching on concentration (American Psychological Association 2006), such a shift seems significant.

In wanting to "just write," Terpstra—like many other participants in our study and members of this affinity space—seeks an experience of flow (Csíkszentmihályi 1990) that minimizes the possible mediation or interruption of writing technologies and foregrounds his interaction with the text. In our conversation, Terpstra differentiated the act of “just writing” from that of tinkering or developing workflows, and “writing” often means generating text that will ultimately lead to a blog post. Writing, in this sense, is a focused labor, and Terpstra wants to eliminate the undesirable ways in which software might disrupt that focus—or flow. As he explained during our interview, he sees value in software that can support that focus:

The complications of writing are in research and structuring the order of information and then being able to manipulate and shuffle the ideas until you work it out into a document. And if the software that can make that frictionless for you provides just the options it needs to in order to accomplish that task, you're concentrating on those more kind of philosophical points of writing and less on "How am I going to move this paragraph to another chapter?"

In computing spaces, this approach to flow is often linked to the reduction of distractions. In terms of software and software marketing, distraction and flow are often connected through user interface design features, such as minimal text editors and distraction-free writing tools—software with fewer UI elements, which is marketed as offering greater attention to flow and a greater sense of productivity (see Van Ittersum & Ching 2013). In reviews and publicity materials, these distracting elements are often tied to writer’s block: “Cure writer's block with distraction-free text editor Byword,” one Macworld article suggests, while MakeUseOf.com says that you can "get over writer’s block with OmmWriter, a zen distraction-free writing app."

As David Sparks described in our interview, these distraction-free tools offer him tangible benefits:

Well, it improves your focus on your words. And there's only one thing that can do, is make it better. . . . And frankly when you have a system that refuses to let you fiddle with fonts and headings when you're trying to write the words, the focus on the words is gonna make the words better. I mean, it's just my opinion, honestly. I'm sure there's people who are much better writers than I that open up Microsoft Word and they make brilliant stuff, but I think if given everything else equal, if you get somebody on a system like this, I think that they can do a better job of writing some good text.

Thinking of flow, we might also draw connections to the affective dimensions of writing, especially the desire to find or create a writing environment that meets a particular aesthetic preference. Distraction-free and customizable writing environments speak to this desire, as do the many blogs that showcase writing and working spaces (e.g., "The Sweet Setup", "The Setup Interviews"). Further, when activities are viewed through the lens of "friction," then automated workflows designed to reduce that friction create a sense of relief, a reduction of frustration.

Distributing Automation

This chapter has focused on the case of Brett Terpstra and SearchLink, but we don’t think that workflow automation should be limited to a particular type of computing or scripting behaviors. We also don’t want to offer Terpstra’s work as an idealized practice or suggest that writers should learn scripting languages and start programming. SearchLink is compelling to us because, like much of Terpstra’s work, it offers complex automation in an easy-to-install package. Any writer can install and use SearchLink without knowing the scripting languages that drive it, and SearchLink provides an approachable introduction to the power of writing-focused automation. (SearchLink does require familiarity with the Mac user interface and file system, a topic we will address in later chapters.)

Although applications like SearchLink are often created to solve user-specific writing problems, the distribution and adoption of those workflows generates professional credit and prestige for the developers. Terpstra’s “mad scientist” moniker comes from his experiments in scripting, many of which he gives away for free but that indirectly drive revenue for his paid, commercial applications and for his sponsored blog posts. On one of his appearances on the Mac Power Users podcast, Terpstra says:

I get letters every day—every day, at least three or four—from people that have a question or they just want to say thanks, and so many of them start with “Hey, I first heard about you on [Mac Power Users]." . . . It’s amazing. So many people have discovered me through [the podcast]. (Sparks & Floyd 2017)

As we discussed in the previous chapter, David Sparks describes the Mac Power Users audience not as experts but as “students and educators and doctors and lawyers and people who own small businesses who are just trying to get better at this stuff.” Although Terpstra’s programming expertise places him outside of this general audience, his scripts and programs—many of which are built for writers—help him reach, interact with, and market to a broader computing public. Likewise, the listeners who write to Terpstra gain access to a professional programmer who develops tools for writers.

In the next chapter we discuss the case of Federico Viticci, editor in chief of MacStories. Rather than focusing on advertisements, Viticci monetized the MacStories website through “Club MacStories”—a subscription-based weekly newsletter with exclusive content. One popular segment of this newsletter is “Workflow Corner,” in which “each week we’ll help Club MacStories members with their iOS and OS X workflows. Submit your requests and we’ll try our best to come up with a solution” ("Club MacStories" n.d., para. 6). Like Terpstra, Viticci draws on his scripting knowledge to help users simplify tasks or work through computing challenges (particularly related to the limitations of phones and tablets). These efforts have both increased his professional profile and generated an audience-friendly revenue model for the MacStories website.

In both of these examples, workflows and automation technologies invoke a public, one that differs from traditional software distribution channels. Much like developers sharing and iterating open source software (a tradition that extends from the development of the UNIX operating system [Kelty 2008]), Terpstra and Viticci engage directly with the users of their workflows, and they often incorporate end user feedback or revisions into their projects. Their automation solutions are opinionated (often developed with their own practices in mind), but they’re also malleable and evolving, shifting with the needs of their audience and with the changes in their computing platforms. As an example of this malleability, SearchLink itself has been adapted by several people and discussed online. These users have implemented SearchLink within other software automation tools, allowing them to run the script in new ways and contexts. There is a plug-in for the Alfred launcher, a macro for Keyboard Maestro (which helpfully provides reminders for the SearchLink syntax), snippets for TextExpander (created with Terpstra's troubleshooting assistance), an extension for the iOS Workflow app, and a plugin for PopClip. The developer of the iOS text editor Editorial even converted the original SearchLink script from the Ruby scripting language to the Python scripting language so that it could run in Editorial.

In this chapter we have sought to walk the fine line between seeing automation as a mind-set that creates opportunities for new writing practices and increased satisfaction with writing, and seeing automation as another opportunity to commodify decontextualized writing tips and tricks. Although Terpstra monetizes and markets several of his software products, he doesn't present them as panaceas, and the development of each script begins with his own particular use case. His approach to automation is grounded in metacognition and in reflection on his own practice. This personal approach to automation, however, also introduces him to a broader affinity group—one where workflows, processes, and practices are shared and discussed. And within this affinity group, the ongoing conversations about automation show how we might productively theorize and apply automation within writing technologies.

This robust ecology of workflow creation, modification, and distribution highlights the scarcity of something similar within Writing Studies. Although the term "workflow" doesn't have the same currency in academic contexts, there are parallels in textbooks, professional advice, and lore. In his book Net Smart, Howard Rheingold (2012) describes his complex web dashboards, through which he filters "Google News and Yahoo! News searches, Google alerts, hashtag searches on Twitter, blog posts from experts, and feeds on tags from Flickr, YouTube, and Delicious," and Rheingold argues for the pedagogical value of building such information-parsing workflows, noting "I know a sixth-grade teacher who had her students create dashboards instead of writing papers" (104). Closer to the field of Writing Studies, Cheryl Geisler's (2004) Analyzing Streams of Language also provides models for what we see as research workflows. In the book's preface, Geisler writes, "One of the most exciting features [of this book], formulas in Excel developed explicitly for the tasks of analyzing verbal data, will save you hundreds of hours of time in doing your analysis" (xiii), and "Techniques throughout the book provide you with step-by-step explanations for using these tools for your analysis" (xx). Workflows often circulate at a local or institutional level, perhaps through professional development workshops where instructors are taught to batch download and upload grades rather than inputting them one by one into Canvas or Blackboard.

Spotlight on Macros

Although Microsoft Word might not seem like the most scriptable or programming-friendly environment, macros—programs that function within Word and perform repeatable functions—have been part of the word processor since the early 1990s. Early versions of Word featured a WordBasic programming environment, and a number of third-party advanced user guides offered writers a way into WordBasic—extolling the benefits of automation and offering tutorials on the automation of recurring word processor tasks. In many of these macro introductions, however, the macro is presented as something helpful and approachable, despite a user’s potential fear of programming. Brent Heslop and David Angell's “Everything Microsoft Didn’t Tell You about WordBasic” (from PC Magazine, July 1993) illustrates these tensions: “Anyone can dive into WordBasic to modify macros or create their own, but Microsoft’s limited support of WordBasic, along with the stigma attached with programming, may have kept you from discovering this simple-to-use, powerful customization tool” (71).

This theme persists nearly twenty years later, now complicated by the growth from WordBasic to Visual Basic Applications (VBA), a much more powerful and complicated means of scripting macros. In chapter 32—the final chapter—of the Word 2013 Bible, Lisa A. Bucki introduces readers to the VBA macro:

Word macros are programs that you use to automate things you do in Word. At their simplest, macros can automate repetitive chores. At their most complex, macros are full-blown VBA (Visual Basic for Applications) programs that add features to Word. You can use macros to create shortcuts to features that aren’t directly available and assign them to the Quick Access Toolbar or to keyboard shortcuts. You can use a macro to perform a series of editing steps. Why are they called macros? Macro means big. In effect, a macro is a way of boiling a lot of instructions (something big) into a single command (something small). (para. 1)

Bucki positions the macro as something conceptually simple: a process for chaining together a series of small steps into a single executable action. However, macros are often presented as a power-user tool requiring experience or programming skills. Bucki’s book is a comprehensive guide to Microsoft Word, yet it saves macros for the book’s final pages, offering a caveat in a call-out box:

Providing a full grounding in macros, Visual Basic, and using the Visual Basic editor is beyond the scope of this book. If you’re a Word developer, you very likely know everything you’ll read in this chapter. This chapter isn’t for you. Instead, it’s for users who want to know how to get started recording and writing macros. Once you’ve gotten started, take a course or invest in a book devoted to Visual Basic. (para. 5)

Macros, as Bucki implies, exist in a space outside of typical word processor use cases. They draw on programming languages (Visual Basic, in the case of Word), programming syntax and structure, and on the user’s ability to (1) recognize that a scriptable problem exists and (2) know that Word provides a system for scripting a solution. And, as Bucki also notes, macros have long been vectors for virus distribution, and macro-enabled documents often come with a MS Word Security Warning—discouraging the casual user from exploring Word's scripting potential.

Although macro use hasn’t found significant traction within the field of Writing Studies, macro use was briefly considered and encouraged during the late '90s boom of word processor research. For example, in “What Works for Me” (1996), John R. Chamberlain presented macros as a way to simplify and streamline feedback on student writing. “I’ve found that a lot of the notes and corrections I write on student essays are for common mistakes,” Chamberlain writes, continuing to say:

Rather than writing these responses out each time, I store the typical things I say about topic sentences, thesis statements, concluding paragraphs, sentence fragments, etc., as macros. By using macros, I can give students abundant feedback about these issues without spending a lot of time writing the same comments over and over. This frees my time for offering additional comments that are more personal, thoughtful, and engaging for them and me. (219)

Word macros have a significant history and remain in use in many professional writing contexts, but they aren’t on the radar of the writers and programmers within the workflow affinity space that this book explores. There are a couple of possible reasons for this, and they’re worth noting. First, the workflows affinity space of this book is largely based on web writers, and those web writers are working with a specific set of UNIX-inspired or -related tools: UNIX hosting tools, web languages like Javascript, Mac OS shells, and so on. Many of these writers approach text through HTML, and this finds them scripting and automating tools that are closely related to the technologies of web publishing and web development. Likewise, many of these writers have abandoned composing in Microsoft Word, so it isn’t surprising that they have little interest in the function or possibility of Word macros.

Before we turn to those technologies of web production and automation, however, we want to note that Word macros provide another pathway to automation, and this avenue might be of interest to writing instructors who teach and work largely with Microsoft Word. For example, the Copyediting-L listserv offers editors a space to share macros and scripts that automate routine tasks. Paul Beverly’s Macros for Editors is a helpful model, providing hundreds of macros such as “AAnAlyse,” which verifies that indefinite articles agree with the following word, and “PDFsoftHyphenRemove,” which unhyphenates all words in the document. In this regard, many copyeditors use scripting to minimize the drudgery of copyediting and make more time for what they view as the more important parts of their work.

Conclusion

This chapter has sought to demonstrate how automation could serve as a useful activity for writers—and facilitate workflow thinking—by prompting reflection on writing processes and through shifting the focus of activity toward less frustration and more concentration. When software stops causing "friction" and starts supporting one's work, writers can experience new relationships with their tools and their tasks. Furthermore, identifying tasks to automate can become an orientation to other activities beyond writing. This perspective has its problems and dangers, as we described at the top of this chapter, such as when automation seeks to displace people and their intelligence. We should remain critics of these efforts. Yet automation, as this chapter has illustrated, can be implemented in ways that support and extend people's abilities.

In offering Terpstra's SearchLink as a case for analysis, we hope to guard against decontextualized practices while adding automation as another possible means of workflow thinking. Just as the Markdown syntax was born in John Gruber's moment of thinking "there has to be a better way," we see the practice of automating writing as a means of productively expanding the possible within digital writing practices.

In the next chapter, we first explore workflows that seek to overcome the limitations of operating systems and computing paradigms through the case of Federico Viticci and his mobile (iOS) workflows. Such workflows can variously appear innovative and haphazard, like Rube Goldberg machines or as elegant workarounds. Sorting through such perspectives, and knowing when to engage in cutting-edge workflow construction, is a key practice the next chapter aims to explain.