The Tale of %PDF-1.4
Appropriately, as I first attempted to open Preserving.exe, the webpage loaded as follows:
%PDF-1.4 %âãÏÓ 3 0 obj <>stream hÞœVÛŽÛ6_}×Wð‘ VŒx_©Çv³_R_iš5Ò_A__YÞUëËV’7Íß÷ )ÉÞÆiš®5-r†gæÌœÑó—·ŠÝ
And so on, for a number of pages.
A script on my computer had malfunctioned, the PDF containing the report for the Preserving.exe summit had not loaded correctly in Safari. As a frequent user of the internet, Microsoft Word, and Safari, I knew there were a number of ways to remedy this situation: I right-clicked on the link in the word document, used my mouse to hover over “Hyperlink > Edit Hyperlink…” copied (pressing Command-C) the text from there, opened a Safari window, and in the URL textbox, pasted (pressing command-P) the text into the URL text box at the top of the window.
The PDF appeared, and I had just used several dozen bits of knowledge, techniques, and tools that are implicit in the software for Safari, Microsoft Word, and OS X El Capitan. These, as Henry Lowood describes in his discussion of the “Lure of the Executable,” are things that should be considered and documented when we archive software materials, because even if the software systems are executable, it does not mean that they are understandable.
Let’s Think About the User
A common thread through the works of Lowood and Chan/Cope is the focus on the ways in which the user interacts with the collection/software. Sebastian Chan and Aaron Cope’s acquisition of the iPad app Planetary was for the Cooper-Hewitt, and the Hewitt sisters who began the collection envisioned it as an educational resource for designers. Eleanor Hewitt went so far as to write that she was not particularly concerned with the destruction of the materials due to overuse, as long as design traditions were passed down. Chan and Cope seem to focus on the present: they even have a fairly temporary system in place where the creator of Planetary checking on the derivative works made from the source code they made available through the collection. They are mapping out the original vision for the collection, ensuring that design traditions are passed along today.
This seems to be a rather unique perspective amongst collectors; many worry much more about the longevity of the collection, including Lowood. However, he still is concerned with the users, but his focus more centered on use cases far in the future: what are we gaining and losing in our preservation of software, and how will they particularly affect future users? We return to screen essentialism; sometimes, the data you do not see could be far more important than that you do.
Lowood also has some pretty strong critiques of attempting to create an authentic experience using hardware.
“While I do not have a crystal ball at hand, my guess is that for most researchers documentation of historical use of software is a more valid source than a personal experience somehow deemed authentic.”
This rings true to me as someone who has done ethnographic fieldwork on past events. While an “authentic” simulation of a protest might put me in the moment in ways that I could not get from recordings, I would value a video of the protest much more than that. Similarly, even if an archive took the time and money to maintain an NES system with an old television, shag carpet, and mustard-yellow vinyl couch, the experience would not be the same as a home movie of children playing the NES, and interviews with them. after all, we see the NES today through the lens of the XBoxOne and PS4; even an authentic experience with it now does not erase those memories.
What Did I Just Acquire?
The underlying story beyond all of these articles is that the supporting documents matter, and it is rare for them not to be useful. The question considered by Alice Allen and Peter Teuben, posed by Doug Reside: “What are the things we can safely say no to archiving?” rings out, and the answer is that there are a lot of things that are necessary to support the longevity of the collection and the variety of users who may be interested in it.
Both the Planetary and Prom Week case studies demonstrate how having additional materials beyond a video game itself can aid in the understanding of the video game. The bug reports, the decisions made during the development process, revision history of the code, and other supporting materials all can contribute to popular and scholarly knowledge, to future software designers, and to our knowledge of the history of video games. As Matt Kirschenbaum notes:
“Software is thus best understood as an artifact: not some abstract ephemeral essence, not even just as lines of written instructions or code, but as something that builds up layers of tangible history through the years.”
Whether or not later programmers have access to the code of earlier games, by understanding how each piece of software was built, we can better connect one to another.
Documentation Beyond the Code: My Hatred of Clippy
This image of a paper clip with eyes, seemingly benign, highlights one of the other things noted by Kirschenbaum and our other authors: software is not simply a tool, but it has become ingrained in our popular culture at a number of levels. An image of Clippy stirs in me a wrath of a thousand papers interrupted by a little animated paper clip. Software is just as culturally significant as film is today, arguably more so.
Should a ethnographer hear a reference made to a video game, they do not necessarily need to play the game, they need some material to help them understand what that experience was like in its time. This means documenting nostalgia as this Buzzfeed article does, to a certain extent, for those classic 1990s educational video games. At the end of the day, an executable file is simply not enough.