Kai's Reflections

Inception

The origins of this project for me started at the beginning of the semester. I had a brainworm nagging at me: What would a clearer, more expository and exploratory alternative to Voyant Tools look like? The ridiculous follow-up would be: Could I build a reasonable facsimile of this alternative in a semester? The answer to the second question given my employment situation, class schedule, and personal life is a firm no, but my original brainworm will inform some of my reflections.

Independent of my original vision, a joint project for Digital Humanities tends to butter my toast; adding a pair of eyes and a different brain to an academic project helps uncover blindspots under tight deadlines. I'm also a proponent of complementary skill sets in teams. When Bri proposed working together on a text-based deformance project, I jumped at the chance.

Theory and Practice

As mentioned in our project introduction, the practice of deformance provides our theoretical bulwark against trivializing our approach. My introduction to these types of practices came from a class taught two years by Kevin L. Ferguson called Alternative Digital Cultures. Using Samuels and McGann's seminal work on deformance and Stephen Ramsey's The Hermeneutics of Screwing Around; or What You Do with a Million Books as a launchpad, the class focused on small project work, often deforming and experimenting with ways to defamilize digital media. Examples of my own work from that class include a video PechaKucha and a series of movie screenshots animated by the astrology software StarStax. Other, more professional efforts from Ferguson are here, and from one of his fellow travelers here.

I offer the background above for useful contrast to our project output. On the one hand, our transformations of the targeted texts falls squarely within the types of deformance examined in Samuels and McGann, with an emphasis on methods one can use without computer/digital assistance: reading backwards (our paragraph reversals), focusing on parts of speech, etc. However, when comparing these manipulations with the examples from Alternative Digital Cultures, I'm struck by methods that use the medium qua material, deforming in ways only made accessible with digital technologies and tools.

Contributions

Contributions can be gleaned from the commit history of our repository.

Most of my code contribution was built with Compromise. For this project I also managed some merge complications in our Git repo, tried to pull the site together into a cohesive whole with a navigation, paratext, style, and so on. I am paricularly proud of the Adjective–Noun Pairs, which could provide a nice band/project name generation machine. In fact the project name was created from three adjective–noun pairs.

One covert goal of how I wanted to contribute to this project was to create scaffolding for Bri to focus on learning the technical skills she was interested in. Outside of one hiccup related to learning how Git works, I think this goal was met.

Challenges

I am always cutting scope for these class projects. Estimating effort for this type of techincal work is notoriously difficult.

One challenge I faced was the relative maturity of the Compromise library. The development effort is lead by one contributor, and while updates are made regularly at present, the creator himself admits to shortcomings:

compromise tries its best to turn text into data. it makes limited and sensible decisions. it's not as smart as you'd think.

This limited nature resulted in a fair amount of corrections and refinement on my end to make some of the parts of speech parsing and tokenization work.

One aspect of collaboration in Digital Humanities projects that I don't always account for is training about code version control systems, in our case, Git and GitHub. The CUNY Graduate Center and the GC Digital Research Institute (GCDRI) do provide adequate training for use of these versioning tools in a single contributor scenario. The second collaboration is necessary, the value and complication of Git workflows becomes apparent. It's not intuitive or straightforward to learn how to branch, resolve merge conflicts, or keep a feature branch up to date with production. I commend Bri for sticking with it, and I was happy to provide assistance shuffling code between repositories and solving merge conflicts while she came up to speed on how to work collaboratively in a GitHub repository. Again, these tools are not always intuitive until you've worked with them for a while.

Potential Evolutions

What would a clearer, more expository and exploratory alternative to Voyant Tools look like?

Using this project as a basis to understand that question, I will point out three factors that would be critical for future evolutions:

Related to my own Digital Humanities journey, this project puts me at a fork in the path. Before this semester, I was convinced that I would pursue a traditional thesis about the cultural poetics and history of pre-personal computers. After starting this project, I wonder if an equally interesting option would be a capstone attempting to build a genuine alternative to Voyant Tools. The major tradeoff in building a capstone would be abandoning what brought me back to graduate school in the first place: a chance to research, process information, and practice articulating it clearly and effectively to an audience. The downside of pursuing a written thesis would be opting out of a chance to focus on delivering a comprehensive product in a structured environment using web technologies I've been tickled to learn this semester.