At THATCamp ’08 I learned how to draw a smiley face with a few geometric programming commands.

Dan Chudnov demonstrated how to download Processing, a Java-based environment intended for designers, visual artists, students, and others who want to create something without being full-time professional programmers. Dan’s purpose was to show librarians, scholars, artists, and free-range humanists that getting started with simple programming isn’t as hard as people sometimes think. You don’t have to be a computer scientist or statistician to develop skills that can be directly useful to you. Dan posted a version of what he was demonstrating with the tag “learn2code.”

I’m not a trained programmer, was not new to programming altogether, but was new to Processing, and for a while I didn’t have much reason or time to do more with it. But last winter I found myself highly motivated to spend some of my spare time making sense of tens of thousands of pages of text images from the Internet Archive that were, for my purposes, undifferentiated. The raw, uncorrected OCR was not much help. I wanted to be able to visually scan all of them, start reading some of them, and begin to make some quick, non-exhaustive indexes in preparation for what is now a more intensive full-text grant-funded digitization effort (which I will also be glad to talk about, but that’s another story). I wanted to find out things that just weren’t practical to learn at the scale of dozens of reels of microfilm.

Processing has turned out to be perfect for this. It’s not just good for cartoon faces and artistic and complex data visualizations (though it is excellent for those). It is well suited to bootstrapping little scraps of knowledge into quick cycles of gratifying incremental improvements. I ended up cobbling together a half-dozen relatively simple throwaway tools highly customized to the particular reading and indexing I wanted to do, minimizing keystrokes, maximizing what I could get from the imperfect information available to me, and efficiently recording what I wanted to record while scanning through the material.

Having spent plenty of hours with the clicks, screeches, and blurs of microfilm readers, I can say that being able to fix up your own glorified (silent) virtual microfilm reader with random access is a wonderful thing. (It’s also nice that the images are never reversed because the person before you didn’t rewind to the proper spool.) And immensely better than PDF, too.

At THATCamp I would be glad to demonstrate, and would be interested in talking shop more generally about small quasi-artisanal skills, tools, and tips that help get stuff done — the kind of thing that Bill Turkel and his colleagues have written up in The Programming Historian, but perhaps even more preliminary. How do you get structured information out of a PDF or word processing document, say, and into a database or spreadsheet? Lots of “traditional humanists,” scholars and librarians, face this kind of problem. Maybe sometimes student labor can be applied, or professional programmers can help, if the task warrants and resources permit. But there is a lot of work that is big enough to be discouragingly inefficient with what may pass for standard methods (whether note cards or word processing tools), and small enough not to be worth the effort of seeking funding or navigating bureaucracy. There are many people in the humanities who would benefit from understanding the possibilities of computationally-assisted grunt work. Like artificial lighting, some tools just make it easier to read what in principle you could have found some other way to read anyway. But the conditions of work can have a considerable influence on what actually gets done.

More abstractly and speculatively, it would be interesting to talk about efficiencies of reading and scale. Digital tools are far from the first to address and exacerbate the problem that there is far more to be read and mapped out than any single person can cope with in a lifetime. Economies of effort and attention in relation to intellectual and social benefit have long shaped what questions can be asked and do get asked, and to some extent what questions can even be imagined. Digital tools can change these economies, although not in deterministically progressive ways. Particular digital applications and practices have all too often introduced obfuscations and inefficiencies that limit what questions can plausibly be asked at least as much as microfilm does. Which is why discussions even of low-level operational methods, and their consequences, can be of value. And where better than THATCamp?