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. 1
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.
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.
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] houses reviews of presentations from the recent [Computers and Writing] conferences. : http://www.digitalrhetoriccollaborative.org : 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.
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” ) 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.
"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.
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.
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.
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 Review, Marca, and My Reviewers. Additionally, scholars in the field are developing tools to support publishing, including Vega. ↩︎
Jay David Bolter and Richard Grusin (1999) distinguish between the "twin logics of immediacy and hypermediacy" (5) in their analysis of their concept "remediation." In discussing films that seek to help "viewers feel as if they were 'really' there" (5), they lay out the logic of immediacy, which "dictates that the medium itself should disappear and leave us in the presence of the thing represented: sitting in the race car or standing on a mountaintop" (5–6). Hypermediacy, on the other hand, "makes us aware of the medium or media" (34), such as in cable news, where multiple video streams and text crawls present a "real" worldview whose mediated nature is obvious. Importantly, both logics seek the same end: "the desire to get past the limits of representation and to achieve the real" (53). "Transparent digital applications seek to get to the real by bravely denying the fact of mediation; digital hypermedia seek the real by multiplying mediation so as to create a feeling of fullness, a satiety of experience, which can be taken as reality" (53). For writers creating blog posts, either logic may be preferred. Terpstra opts for the transparency afforded by SearchLink to avoid the mediation of web browsers and the temptations to explore other pages. Other writers may revel in multiple browser windows open at once, tiled across the screen, providing inspiration and guidance as they write their way through them.↩︎