Continue reading »]]>

Yesterday, Dan Cohen tweeted a comment about all the places where THATCamps are springing up, causing me to once again look over the list of past and upcoming THATCamps–almost 50 in total.  It really has become a world-wide phenomenon.

All of which caused me to tweet:

Given the global nature of #THATCamp, it’d be cool to design a project to which each thatcamp can contribute a piece over time.

To which @thatcamp replied:

@ericdmj You are SO right. So much is possible. Could be a #THATCamp proposal, even, such a project.

So, being a good follower of instruction, this I now do.

That said, I have no firm suggestions.  But to start the gears turning: what hacking/programming-focused project could we do that would allow asynchronous contributions over long spans of time by people who are, more than likely, only dedicating a single session at any given THATCamp thereto?

An hour here, an hour there, here in Paris, there in Canberra, there in New England. . . . What could we build across time and space?

Any and all thoughts welcome!

Continue reading »]]>

This session proposal overlaps with Patrick’s idea for a humanities coding session, but it’s different enough that I thought it might warrant its own session. Whereas Patrick would like to draw together people who write or hack code in a digital humanities context, I’d like to bring together people who are interested in the critical reading of code as a media object.

Critical code studies is an emerging field related to software studies and platform studies, but it’s more closely attuned to the code itself of a program rather than the program’s interface and usability (as in software studies) or its underlying hardware (as in platform studies). (NOTE: I’ve ridiculously mischaracterized software studies and platform studies here. In fact, according to Nick Montfort’s original formulation of platform studies, code is an integral component of the overall platform, meaning critical code studies is actually a subset of platform studies.)

Critical code studies might look at the algorithms of a program, the programmer’s inline comments to the code, or the way code is hacked and transmitted. It borrows many of the tools of literary and historical scholarship, but infuses them with what Katherine Hayles describes as “media-specific analysis.” Mark Marino has a good introduction to critical code studies, and I’d humbly recommend my own look at the code of SimCity as another example of critical code studies.

My interest in code studies is pedagogical as much as it is methodological. Code is not just for coders. I believe that as digital humanists, we need to teach everyday people, and in particular, nonprogramming undergraduate students, what Michael Mateas calls procedural literacy. This session, then, would serve as an introduction to critical code studies, and I’d stress that no programming experience is necessary. If you know how to read, you can begin reading code. And if you know how to read critically, you can begin reading code critically.

Continue reading »]]>

It’s come to be expected at digital humanities-oriented conferences that there will be a vibrant backchannel—commentary, questions, dissent, and amplification, usually taking place in real-time (but not always real-place) on Twitter. Even scholarly conferences that are not strictly digital, such as the Modern Language Association, have begun to have ongoing and serious discussions on the conference backchannel.

Derek Bruff has written extensively on encouraging conference backchannels and dealing with distraction and incivility on backchannels, and I want to take his ideas even further in this session, asking how can we build—literally build from the ground up—a better backchannel?

That’s right, I want to hack the way we yack.

The Better Backchannel might be a software solution built on top of Twitter, but I don’t want to assume that Twitter is the best or even default platform for the Better Backchannel. Perhaps the Better Backchannel is a disparate set of existing tools, assembled in a new way. Or maybe the Better Backchannel is not a tool at all, but a set of practices.

To begin, I see four broad questions to consider (there are more of course, and I hope you add them in the comments below):

• What are the limitations of existing backchannels?
• What do we want the Better Backchannel to do that existing backchannels don’t do or do badly?
• What existing tools support these features, or can be hacked to support these features?
• And how can we put the Better Backchannel into operation?

In the ideal world, we answer these questions in the session and actually build the thing on-the-spot. That’s not going to happen, of course (the building, that is), but we may end up with a blueprint that some sort of future One Week | One Tool team might act on. And in the meantime, we might learn something that will enrich our current use of backchannels.