Goals

  1. Extend accepted methods of collective authorship.

The inspiration for this project came out of our interest in a trend in experimental writers choosing to engage in collective authorship for political and aesthetic purposes. We were familiar with two different ways authors engaged in this practice: flarf poetry, in which authors construct poems out of search engine results, and traditional multi-author works, such as Army of Lovers by Juliana Spahr and David Buuck, which although authored by two individuals is written in a singular voice. Our project aimed to extend the practice of collective authorship by creating connections between a computer and multiple physically present people. We wanted the users to collaborate with their fellow users and the machine elements of the demo. We wanted the users to feel the tension between control of and dependence on their fellow users and the computer. We wanted the users to think about what goes into collective authorship and what makes an author? What makes a poet?

  1. Investigate personhood/subjectivity behind search queries.

This is something Kris Cohen is also considering in his chapter, “Search Engine Subjectivities:” can a person be defined by/reduced to what he or she types into a search engine? One of the goals of our project is for users to think about just who (or what) is doing the collaborating. The three people operating the Makey Makey play a clear role in the collaborative process. However, what is significantly less clear is the role of the human behind the search query. While the search queries generated by Beacon are the actual material for our aesthetic project, how do we take into account their anonymity, their randomness, and their non-intentionality as poetry? This should deliberately lead to some discomfort on the part of the users; as “authors” they are not actually producing material, but rather appropriating it from Beacon, a site that wasn’t originally intended to be used for generating poetry. Additionally, Cohen forces us to consider not only how the search engine itself defines what is typed into it (fragmented words, phrases, terms), but also how it shapes “personhood” (our curiosity, our access to knowledge, our feeling that the machine is looking back at us). The users are, after all, doing the choosing: which queries are “poetic”? Which queries do we (as a collective) relate to? Yet this question of relationality is one that is mediated through technology; in other words, the Makey Makey forces us to question how we relate to other subjectivities when we only know them through the machine.

  1. Interrogate the concept of (im)permanence on the Internet.

In pursuing our project, we also wanted to test a theoretical point that the class has encountered, which is the dialectic of permanence and impermanence. As a class, we’ve discussed the way computers and certain websites (such as Facebook or, more relevant for our project, Google—both of which it’s important to remember are ultimately created and kept up by humans) retain users’ data indefinitely: once you post an unflattering photo to Facebook, even if you delete it, it’s still “out there.” Then again, in class we have also talked about just how fleeting and intangible things are on the net. We wanted to work with Beacon and Play Doh to actively interrogate (im)permanence, which we’d heretofore only dealt with conceptually. Beacon flashes search queries across one’s screen at such a speed that they’re difficult to read, let alone memorize or really think about, so we wanted to make capturing the queries part of our project. Play Doh allowed us to visualize the “trace” choices and actions made in our demonstration. We wanted the users to work together to capture screenshots of search queries from Beacon by pressing their Play Doh “buttons.” We wanted the users to feel that their choices mattered for the content of the future poetry that would be created after the conclusion of the demo. We wanted the users to think about (im)permanence as they selected which search queries to capture and which to let slip away.

Specifications

Material materials:
Makey Makey
Wires with alligator clips (6)
Breadboard wires (2)
Play doh
Computer
USB cord
Table

Immaterial materials:
Access to automatedbeacon.net
SnagIt software
Functioning internet browser

Immaterially material materials:
Humans (3)

Setup:
1. Configure 2 breadboard wires to attach to “F” and “right click” on Makey Makey.
2. Attach 1 alligator clip to each of the breadboard wires. Attach an additional alligator clip to the “click” space on the Makey Makey.
3. Form Play Doh into 3 separate round, flat, smooth surfaces; each should be roughly the size of one’s palm.
4. Insert the other end of the 3 alligator clips (the ones already attached to the Makey Makey) into separate Play Doh molds (each alligator clip gets its own Play Doh surface).
5. Attach remaining 3 alligator clips to “earth” section on Makey Makey.
6. Plug Makey Makey into computer with USB cord.
7. Download SnagIt software (available for 15 day free trial).
8. Once downloaded, close SnagIt window, leaving only the small SnagIt “capture” display to the bottom, side, or top of computer screen.
9. Display automatedbeacon.net in Internet browser.
10. Make sure all materials (Makey Makey, Play Doh, computer) are safely on table surface and can be easily accessed by users.

Instructions: 1. Automatedbeacon.net should be running on computer screen. SnagIt “capture” should be to the top, side, or bottom of screen, ensuring it does not interfere with visibility of flashing search queries.
2. Each of the 3 human users should hold their own alligator clip, the end of which is attached to “earth.”
3. Each person should decide on one of three different roles. The roles are as follows:
User #1: Initiates capture – in control of “click” command
User #2: Completes/saves capture – in control of “F” command
User #3: Cancels/rescinds capture – in control of “right click” command
4. Each user should have access to the Play Doh mold that corresponds with their command. For example, User #1’s designated Play Doh is the one that corresponds with the “click” command, etc.
5. As automatedbeacon.net runs, users should collectively decide on search queries that feel appropriate to include in a collaborative poem. How users decide what is “appropriate” will vary.
6. When a choice is made, User #1 should initiate the SnagIt “capture” function by pressing his or her Play Doh.
7. While User #1 initiates the decision, User #2 must decide whether or not to “save” the capture. User #2 can “save” the capture by pressing his or her Play Doh.
8. User #3 has the option to “cancel” the capture before User #2 “saves” it. User #3 can “cancel” the capture by pressing his or her Play Doh.
9. Users may choose to verbally communicate among themselves or to not communicate at all.
10. Users may also decide when the appropriate number of search queries has been saved.
11. Once finished, users may access saved search queries via the SnagIt software. Users should then create a poem from collected queries. Users may choose to arrange, modify, or supplement queries as they see fit.

Rationale

The search queries in Beacon are not meant to be aesthetic. Their purpose is utilitarian: to find information relating to a specific set of key words/phrases. However, ours is not the first project to look to search engines as sources of found poetry. The genre of flarf poetry similarly integrated the non-aesthetic element of the search result into an aesthetic project. However, our project extends and complicates collaborative projects like flarf in a number of different ways.

By using Beacon as source material, our poetry is generated from the search query rather than the search result. This allows us to foreground curiosity and desire, which are inherent in the practical act of using a search engine. While the goal of our project is an aesthetic one rather than a practical one, there is an element of intentionality that connects the users to the person behind the search query. The three users have to collectively agree on which queries are “poetic,” potentially leading to important conversations as to why we value one query over another. The reason we have three users is to explore which phrases are broadly agreed to be good “aesthetic” choices. For instance, even though user #1 initiates the capture, user #2 needs to save the capture, and in an added twist, user #3 has the potential to reject the capture at any moment. When the demonstration is done, we can assume that whatever phrases have been captured have been collectively agreed upon by the three users.

However, our project also demonstrates how authorship is extended beyond the three people attached to the Makey Makey. For example, when testing the prototype, Nathaniel was in the position of initiating the screenshot. However, he expanded the collaboration by requesting the input of the supposedly “non-participating” audience members. Nathaniel’s decisions to initiate captures were not necessarily based on verbal confirmations, but rather a general communal display of affect. For instance, when a particular search query made everyone laugh, Nathaniel was far more inclined to initiate the capture.

Additionally, it’s important to keep in mind that the material for our poetry comes from Beacon. Users are not producing their own content, the anonymous “authors” of the search queries are. We wanted to use our demonstration to dig into questions of who (or what) we consider to be an author, as well as to consider Cohen’s questions of “personhood” and subjectivity of personal data as it is mediated by technology. In creating the demonstration to extend notions of collective authorship, we considered the writers of each search query that flashed across the screen on Beacon as a potential co-author on the project. However, we also wanted to consider the way the search engine determines the form that the language takes. Cohen mentions:

whether expressed in the interrogative, declarative, or a less categorizable voice, search queries want something . . . More direct than most questions, often dispensing with grammar and syntax, and appearing for the most part without punctuation, they could almost be demands, a primitive language game: ‘slab!’ ‘porn!’ (7)

This is a relatively simple instance of the role of the machine in the way collaborative authorship works in our project. Cohen also discusses the way the search engine shapes human subjectivity in general, claiming that

Search engines grant this kind of access . . . access to the feeling that it would be possible to find anything . . . by re-wiring curiosity and the circuits curiosity can travel . . . This in turn impacts how we learn, how we change ourselves, how we move toward horizons of self, and how we alter those very horizons. (15)

While the human is obviously mediated through the technology of the search engine, and further through Beacon, as users of search engines, we also recognize and relate to something fundamentally human in each query.

If we’re conscious of the human aspect here, we’re also required to considered issues of consent and control in our collaborative project. At the most basic level, we were conscious of the fact (and we wanted our users to be too) that the authors of the search queries did not consent to have their searches broadcast on Beacon, let alone to be used in a poetic project. This calls to mind other times when non-aesthetic material has controversially been made aesthetic (for instance, Kenneth Goldsmith’s use of Michael Brown’s autopsy report as a work of conceptual poetry). Furthermore, the fact that the users only chose, and did not produce, the work allows them to distance themselves from any potentially contentious material. This was an issue the flarf poetry community encountered; authors refused to take responsibility for any offensive content in their poetry, as they could easily claim they did not actually write it. On the flip side, issues of consent (or lack thereof) in a poetry project seem small compared to the consent implicit in one’s use of search engines. Searchers may or may not realize exactly how or to what extent they are agreeing to the search engine’s ownership of their personal data.

Closely related to the issue of consent in our project was that of control. We wanted to make explicit the tensions regarding control that are involved in collective authorship. In a traditional single-author situation, the writer has total control over the resulting project, but this is not the case in our project. While the authors of the search queries clearly lack control, we also wanted to explore how control is distributed among the three users attached to the Makey Makey. We used Play Doh to record physical evidence of the extent of control each user exerted in the demo. In Kirschenbaum’s “Every Contact Leaves a Trace,” he writes that “ultimately electronic data assumes visible and material form through processes of instrumentation that suggest phenomena we call virtual are in fact physical phenomena lacking the appropriate mediation to supplement wave-length optics; that is, the naked eye” (19). From the imprints in the Play Doh, the control of each user is made visible. However, the Play Doh also complicates Kirschenbaum’s idea of the trace in that the imprints don’t directly transcribe which phrases the users agreed upon. That each user played (or didn’t play) a role in the collaborative process is documented, but the exact record is left out.

The use of Play Doh also contributes to the function of our demonstration as a form of performance art. By having each of the three users hooked up to the Makey Makey, and making physical impressions in the Play Doh, audience members watching the collective process can visualize the collaboration as it happens. We were also able to project Beacon on the screen, mimicking the actual Beacon installations (that exist in addition to the website) of Thompson and Craighead. This additionally foregrounds some of Cohen’s concerns regarding how the aesthetic intervenes in our idea of the machine. While projects such as this one don’t necessarily change the function of the search engine, they do force us to consider questions surrounding aesthetics, the machine, and the role of human subjectivity. As Manovich suggests, “we would want to develop a poetics, aesthetics, and ethics of [the] database” (219, emphasis mine). We find it helpful to consider our project in relation to Manovich’s concept of “info-aesthetics,” which he defines as “a theoretical analysis of the aesthetics of information access as well as the creation of new media objects that ‘aestheticize’ information processing” (217). By both practicing and interrogating the nature of collective authorship, we invite further thought on the intersection between technology, media theory, and literary practice.