In his 2003 review of 20 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. (pp. 345-346)
Moran points to other machines to which we delegate “low-status work”—the “dishwasher, lawn mower, vacuum cleaner, slicer-dicer, or rug shampooer” (p. 346)—and notes how early research in Computers and Composition searched for an analog in the computer and word processor. The then-possibilities of automated work often pointed to the drudgery of teaching or assessing writing, specifically “copy-editing, revising, and retyping” (p. 346). From Hugh Burns’ 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” (pp. 6-7).
The vision of writing tools pioneered by early Computers & Composition scholars continues to echo in contemporary software. The spelling, grammar, & 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 exceptions1, 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 the case of SearchLink, a computer script written by software developer and blogger Brett Terpstra, which automates the process of adding hyperlinks to a web document. Through an activity-based analysis of SearchLink, 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 are able to 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. 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. (personal interview)
Ultimately, we position Terpstra's approach to automation as a way of developing workflow thinking. 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, p. 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 practice 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.
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) or 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 that 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 Charlie 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. (p. 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 rhetoric and composition—not as a way to prescribe process, but rather 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 in which 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 also 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? (p. 124)
In other words, 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 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” [p. 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 family of activities (Prior & Schaffner, 2011) related to “writing workflows” frequently write and talk about automation with regard to 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 a new one. 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.
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 to illustrate the various ways software and scripts have attempted to relieve this friction, and where Terpstra's SearchLink fits into this history.
In the Web's early days (circa 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 particular 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 odd characters like angle brackets and remembering the abbreviations for common tags.
Early blog software removed some of these complications. Blogger and Pitas first appeared in 1999 (Blood, 2004, p. 54; Walker Rettberg, 2014, p. 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" (p. 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" (p. 54).
While Blood implied that the ease of Blogger and similar tools led to more frivolous writing on blogs, Mortensen & 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" (p. 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" (p. 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. (p. 55)
While the process of handcoding 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.
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 brackets and a URL in parenthesis:
[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] houses reviews of presentations from the recent [Computers and Writing] conferences. : http://www.digitalrhetoriccollaborative.org : http://www.siteslab.org/cwcon/2016/
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).
Movable Type and Blosxom both 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 that 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 & CSS 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 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, 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 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 one 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. Prior to writing SearchLink, Terpstra created a script to batch process the copying and pasting of links from a Web browser. To use it, one simply opens up each Web page to which one wants to link in separate tabs of the Web browser window. Then, one would invoke the script, which would grab the URL from each open Web page and paste it into the Markdown document as a reference link. One could 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 tradeoffs and batch processing links in this way does as well. First, writers must know to what pages they want to link before invoking the script. It's certainly possible to use the script to paste the links one suspects one will want prior to drafting, and then manually seek out additional links if they become necessary. Similarly, it's possible to draft the document and leave placeholders for the links, 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 particular workflow that works well with the script is a research phase, that 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.
"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. (personal interview)
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' (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 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 ("Multitasking"), 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?" (personal interview)
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 (cf. 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. (personal interview)
Thinking of flow, we might also draw connections to the affective dimensions of writing—and 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.
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 which 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]. (Terpstra, 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” (personal interview). 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.net. 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 & 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 & 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 plugin for the Alfred launcher, a macro for Keyboard Maestro (which helpfully provide 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 it could run in Editorial.
In this chapter, we have sought to walk the fine line between seeing automation as a mindset 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 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 that "I know a sixth-grade teacher who had her students create dashboards instead of writing papers" (p. 104). Closer to the field of Writing Studies, Cheryl Geisler's (2004) Analzying Streams of Language also provides models for what we see as research workflows. In the book's Preface, Geisler writes that "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" (p. xiii) and "techniques throughout the book provide you with step-by-step explanations for using these tools for your analysis" (p. xx). And workflows often circulate at a local or institutional level, perhaps through professional development workshops where instructors are taught to batch download & upload grades rather than inputting them one-by-one into Canvas or Blackboard.
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 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.
While we are not aware of any projects aimed at creating a software-based composing tool involving people in the field, there are several projects designed to support pedagogy developed by scholars in the field. These include Eli, Marca, and My Reviewers. Additionally, scholars in the field are developing tools to support publishing, including Vega. ↩︎