by Ethan Gates, Senior Software Preservation and Emulation Technologist

While one of my primary duties as a Technologist for the Software Preservation and Emulation unit is to translate user needs and workflows into requirements for our development team on the Emulation as a Software Infrastructure (EAASI) platform, I have only ever dabbled in the actual ground-level effort of programming and code maintenance involved in developing software. Over recent years I have tried to extend my abilities with Bash and Python scripting (both for personal and professional pursuits), the better to understand the perspective of my colleagues when it comes to our development infrastructure on GitHub, or the complexities involved when proposing a new EAASI feature for prioritization. But I often wish that I had a better handle on some of the specific technologies and tooling involved in the EAASI stack – particularly web-native languages like JavaScript – so that, even with my relatively naïve skills, I might actually be able to save some of our small dev team’s limited capacity by jumping in with minor edits to the code base, particularly when it comes to small changes in EAASI’s browser interface like adding a tooltip to provide a user with helpful context on certain labels, or adjusting the API endpoint called by pressing a particular button. 

With that aim in mind, I recently went searching for professional development opportunities that might help boost my ability and confidence in programming for the web, and found myself largely disappointed with the options that I could find. While any number of intro-level tutorials, both free and paid, exist for JavaScript, I personally have a very difficult time actually absorbing and moving past abstract programming concepts (“what is a ‘function’, etc.) without applying them to a real-world project. On the flip side, when it comes to programming (and particularly programming with a foundational web language like JS) many of the more in-depth and structured options – webinar series, or actual full-length courses or certifications – are distinctly aimed at professional coders and clearly aimed to prepare their participants for work at technology firms. If you too have done any investigation in this area, you probably know what I’m talking about: a lack of engagement with the actual input or output of the projects you work on (let alone cultural heritage or digital archives specifically), hyper-specificity on a hot new flavor-of-the-month tool, an assumption that you are looking to become a programming “rock star.” While there are some wonderful GLAM-oriented efforts like Library Carpentry and Programming Historian that more fit the bill, I wasn’t finding much that hit all three corners of what I was looking for: the particular tools and skills involved (building web sites or applications with user interfaces), the breadth and comprehension of pedagogy involved (i.e. more than an hour-long step-by-step tutorial to complete a particular task), and the type of coursework that activates my interest and ability to implement what I’m learning (something digital culture-oriented). 

So I was quite glad to eventually stumble on the School for Poetic Computation, a non-profit, experimental school in Brooklyn that offers a variety of both in-person and virtual classes and workshops. SFPC’s mission – to facilitate study of art, code, hardware, and critical theory through lenses of decolonization and transformative justice – resonated enormously, as I realized I wasn’t looking to just “get better at JavaScript,” but rather have a chance to push my basic, syntactical/abstract understanding of coding languages into sample implementations, all the while critically engaging with the actual, concrete purposes that I was applying that understanding to. Sticking by our unit’s vision to “champion inclusive pathways” to software-dependent collections and Yale Library’s Staff Values of access, diversity, and creativity, writing code for EAASI is not (and should not) just be a matter of picking the right tool or simplest approach in a strictly technical sense, but one that accounts for the particular end goals we’re striving for (a broader and more accessible cultural record) and the ideas and principles sparked along the way. 

I applied and used my professional development funding to attend “HTTPoetics”, a 5-week course dedicated to exploring the creative possibilities of HTML, CSS and JavaScript. From late July through August, I would meet for three hours every Friday on Zoom with instructor Todd Anderson (one of SFPC’s co-directors) and about 20-25 other students, in a session that mixed aspects of a creative writing seminar (starting with small breakout groups to share and discuss the small web sites that we created for “homework” each week), group discussion (on a series of assigned readings and example sites), and an interactive tech demo (with Todd live-coding techniques and syntax to jump-start ideas for the next week’s homework). 

(If you’re curious – the full syllabus is available here!) 

As far as I could tell, I was the only person who came in to the course from a professional background in archives or libraries, though far from the only one NOT coming from a professional or formal background in coding. The other attendees spanned artists, community organizers, and grad students or independent researchers from a variety of disciplines. Skill levels in the subject matter also varied greatly: some came in with even less experience building web sites than me, while others were taking time away from a hunt for full-time programming work. I was also surprised by the geographic diversity: while most of the attendees were calling in from somewhere in the U.S., we were also regularly joined by a solid handful of folks from Europe, South America, and Asia. 

In living up to SFPC’s promised attentiveness to professional, social, racial, economic and gender backgrounds, this multi-faceted group was a constant source of inspiration, support and joy over the course of those five weeks. The one mutual thread among the students seemed to be a shared frustration with the monolithic, opaque nature of the modern web, and an invigoration brought on when looking at “old” or even just simple, single-purpose sites, and digging into their guts together. 

(I was tempted just now to call this “nostalgia”, but I’m going to reject that framing, because as we explored and shared our work together, one of my biggest takeaways from the class was that the anarchic, free-flowing creativity and spontaneity of the early/’90s web is less a lost, bygone place we can never return to, and more a muscle that many folks have forgotten or perhaps never been given the opportunity to flex) 

Going in, I assumed I would have some opportunities to gently plug principles of web archiving, maybe link folks to some helpful resources to save the stuff they created – I did not expect how quickly and immediately preservation would frame the entire course when, mere days before the first session, Glitch announced it was winding down and would close project hosting in July. This was the platform Todd had used for hosting student work in this and other SFPC courses for a couple years; the shutdown notice had led to a scramble not just to adjust the syllabus and tutorial sections of this edition of HTTPoetics, but to find alternative hosting and migrate dozens of previous projects that had been selected for capstone “anthologies.” 

(In the end we used Neocities, which, as I understand it, has some limitations as far as the live-coding demonstrations that Todd preferred to do in-class and in the types of files you can upload to a free account, but is very on-brand to the spirit of the course in any case) 

I found this context colored many of the conversations and small group sessions throughout the rest of the course – several times we explicitly talked about the transience of the web, the fear of losing creative projects that one might consider “still in progress” even when one doesn’t have the opportunity to return to it for months or even years, and the friction between wanting to share and build community over your creative work with others and also have some say or control over the infrastructure with which you so do so (a zero-sum game when there is only so much time and money available to not just create but maintain or even host web content).  

On the flip side, the impermanence of the web and our projects was not universally considered a bad thing. One of the artists in the class mentioned how much they appreciated Neocities as a sort of digital workbench and the ability to treat projects for the class as one-off experiments. An explicit acknowledgement that our pages might disappear in even a couple years lowered the pressure to think through every small decision.  

I wrestle with this sometimes when it comes to talking about personal digital archiving or working with artists, especially when archivists and the like start veering into the territory of recommending specific tools, practices and systems to help creators make their materials “more preservable.” These sorts of conversations are obviously in good faith, intended in the spirit of teaching and sharing knowledge rather than dictating method, and basically 100% of the time aimed at a self-selecting audience of users/creators that are explicitly interested in preservation in the first place, so I don’t in any sense mean to imply that archivists should not do this kind of outreach. But zooming all the way back to the big picture, sometimes I can’t shake the feeling of the tail wagging the dog: shouldn’t creators have the total freedom to create, and be able to leave the thorny discipline of digital curation and preservation to those who have dedicated their time and effort to learn the intricacies? 

Ultimately though I think this class helped me work to dismiss that nagging feeling; “total freedom to create” is a red herring in the first place (see once again: reliance on Glitch and Neocities, their computing infrastructure, and their business models for this course to even happen), and the exchange of hyper-individualized skillsets and interests is what makes the internet at its best. I learned some concrete concepts of JavaScript and web coding that will aid my understanding of UI/UX design and conversations around the EAASI platform in the future (Marijn Haverbeke’s Eloquent JavaScript and the p5.js JS library stand out as resources this course introduced that I will return to over and over), but I was also able to share information about Webrecorder, show my classmates how to plug their work into OldWeb.Today, and search the Internet Archive’s animated GIF portal, GifCities. That kind of opportunity for skill-share is so essential, no matter the particular disciplines involved. 

I’ll wrap this up by posting the four sites that I created for the course, along with a brief explanation of my thinking/process for each. And if you’d like to see and hear more from the others in the class, please check out the class anthology and/or the Twitch stream from Sep. 28 where several of my classmates presented their works live! 

Week 1 assignment: Make a bad website. Make a website that is ugly. Do it on purpose. Break an unwritten rule. Set yourself free. 

https://bfool.neocities.org/httpoetics/week1

I really honed in on the “break an unwritten rule” bit of this assignment, challenged myself to think up various principles of contemporary web design that I’ve picked up via osmosis, and set out to the opposite. Modern sites have lots of empty space – so I packed the background with a tight, cluttered grid. Modern sites favor small snippets of text – so I jammed in as much text as possible (and specifically a meta-quote that is about text and words itself, taken from The Talos Principle, which is probably too clever by half but I had to pick something). Modern sites try to make their navigation clear, so you know where to find things – so I put a welcome message and most of the “content” past an indefinite scroll that will vary depending on your device. I didn’t specifically check but I am sure the color and background choices violate every principle of web accessibility that exists (sorry). Images will never be found. Emojis and tags will render wildly or not at all depending on your browser. Enjoy. 

Week 2 assignment: Make a website that is way too big. Make either one massive page (6000px x 4000px at least) or a collection of many small, interconnected pages (at least 7). Imagine a giant sheet of paper you can only see part of at any one time, or an old mansion full of weird tiny rooms. Fill it with secrets and things to find. It’s ok to leave space. 

https://bfool.neocities.org/httpoetics/week2

This site (“a personal archive”) is my most direct reflection on working in digital preservation. The overwhelming rows and columns of file folders are a pretty good visual approximation of how I feel about the scope of what digital archivists are asked to “save.” It takes incredible time and effort just to suss out the handful of pieces that any one person might, in fact, actually deem worth saving – and even then, it takes even further action (in the site’s metaphor: actually clicking on the “Save Me” button) to make that thing accessible/visible. 

There’s one example right at the start of the page to get you used to the mechanism, but there are 8 “objects” total in this sea of folders that you can ultimately choose to Save (and it’s a “personal” archive because those objects represent some of my favorite things: a book, a movie, a video game, a TV show, a podcast, a web site, an album, and a hobby). Best of luck! (And just be glad I did not have time to figure out and follow through on my original idea, which was that every time you clicked “Save Me” on one object, one of the other 8 objects would randomly disappear, making the search zero-sum and increasingly even more frustrating) 

Week 3 assignment: Create a website that changes when you press a button. The button could be a or a keyboard key. Is it a slideshow? A reading machine? A divination system? A place that changes over time? 

https://bfool.neocities.org/httpoetics/week3

I guess I have a contrarian streak (or maybe I was still in the “rule-breaking” mindset from the Week 1 assignment), but my immediate thought with this assignment was to make a site that changed when you pressed a button but where the entire design of said button would actively deter you from pressing it.  

Once I had a giant, red, DO NOT CLICK button, I was put in mind of the story of Lot’s wife, from the Book of Genesis. The story is very similar to the myth of Orpheus and Eurydice – while escaping the destruction of Sodom, Lot and his family are explicitly directed by an angel not to look back at the city. The command is not really explained, nor are the consequences, just a direction from on high. Lot’s wife disobeys and looks back anyway, and in punishment is turned by God into a pillar of salt. I realized that what I had here in the button was a “Lot’s Wife Simulator”: a temptation to defiance (exacerbated, in the context of this site, when there is literally nothing else you can do on the page). 

One reason why the story of Lot’s wife was so top-of-mind is that “Lot’s Wife” is one of my favorite poems by one of my favorite poets (Anna Akhmatova); a brief but exquisitely mournful work that dares to actually empathize with Lot’s wife as a human being rather than a parable. So the more appealing, animated text begging the user to, in fact, click the button (and the faint background text) are a nod to the poem. 

Week 4 assignment: Make a website that changes as you move the mouse. Are you drawing? Reading? Revealing? 

https://bfool.neocities.org/httpoetics/week4

Windows 11 users, don’t freak out – that is a browser window, not your desktop. (It is my desktop, but that’s neither here nor there). The “revealing” bit of this assignment, and my general interest coming in to this course in UI design and emulation (and UI design FOR emulation), got me thinking about how startling it is sometimes to dive back 30, 40 years in the history of personal computing and, despite all the differences from modern software, still be confronted with many uncannily familiar features, designs and layouts. 

As you move your mouse over each quadrant of the page, you’ll uncover a different historical computing environment that is still visible in the bones of Windows 11 or similar – and if you click, you’ll be linked directly to a emulator of that environment that you can boot up and play with, right in your browser.