Game Change: Digital Technology and Performative Humanities

“Game changing” is a term we hear a lot in digital humanities. I have used it myself. But try, as I was asked to do for a recent talk at Brown University’s Ancient Religion, Modern Technology workshop, to name a list of truly game-changing developments wrought by digital humanities. I come up short.

Struggling with this problem, I found it useful in preparing my talk to examine the origins or at least the evolution of the term. I’m sure it’s not the earliest use, but the first reference I could find to “game changing” (as an adjective) in Google Books was from a 1953 Newsweek article, not surprisingly about baseball, specifically in reference to how Babe Ruth and his mastery of the home run changed the game of baseball. This is a telling, if serendipitous, example, because baseball fans will know that Babe Ruth really did change baseball, in that the game was played one way before he joined the Red Sox in 1914 and another way really ever since. Babe Ruth’s veritable invention of the home run changed baseball forever, from the “small ball” game of infield singles, sacrifice bunts, and strategic base running of the late-19th and early-20th centuries to the modern game dominated by power and strength. As Baseball Magazine put it none-too-flatteringly in 1921: “Babe has not only smashed all records, he has smashed the long-accepted system of things in the batting world and on the ruins of the system has erected another system or rather lack of system whose dominant quality is brute force.” From what I could gather from my quick survey of Google Books, for the better part of the next thirty years, the term is mainly used in just this way, in the context of sports, literally to talk about how games have been changed.

In the 1980s, however, the term seems to take on a new meaning, a new frequency and a new currency. Interestingly, the term’s new relevance seems to be tied to a boom in business and self-help books. This probably comes as no surprise: I think most of us will associate the term today with the kind of management-speak taught in business schools and professional development workshops. In this context, it’s used metaphorically to recommend new strategies for success in sales, finance, or one’s own career. It’s still used in the context of sports, but most of what I found throughout the 80s and 90s relates to business and career. Going back to our graph, however, we see that it’s not until the turn of this century that term gets its big boost. Here we see another shift in its usage, from referring to business in general to the technology business in particular. This also comes as no surprise, considering the digital communications revolution that tooks shape during the five years on either side of the new millenium. Here we see a new word appended to the phrase: game-changing technology. And even more specifically, the phrase seems to become bound up with a fourth word: innovation. Today use of the term has been extended even further to be used in all manner of cultural discourse from politics to university-press-published humanities texts.

But when we use the term in these other arenas—i.e. in ways other than in the literal sense of changing the way a sport or game is played—in order for it to be meaningful, in order for it to be more than jargon and hyperbole, in order for the “game-changing” developments we’re describing to live up to the description, it seems to me that they have to effect a transformation akin to the one Babe Ruth effected in baseball. After Ruth, baseball games were won and lost by new means, and the skills required to be successful at baseball were completely different. A skilled baserunner was useless if most runs were driven in off homeruns. The change Ruth made wasn’t engendered by him being able to bunt or steal more effectively than, say, Ty Cobb (widely acknowledged as the best player of the “small ball” era) it was engendered by making bunting and stealing irrelevant, by doing something completely new.

In the same way, I don’t think technologies that simply help us do what we’ve always done, but better and more efficiently, should be counted as game-changing. Innovation isn’t enough. Something that helps us write a traditional journal article more expertly or answer an existing question more satisfactorily isn’t to me a game-changing development. When you use Zotero to organize your research, or even when you use sophisticated text mining techniques to answer a question that you could have answered (though possibly less compellingly) using other methods, or even when you use those techniques to answer questions that you couldn’t have answered but would like to have answered, that’s not to me game-changing. And when you write that research up and publish it in a print journal, or even online as an open access .pdf, or even as a rich multimedia visualization or Omeka exhibit, that to me looks like playing the existing game more expertly, not fundamentally changing the game itself.

These things may make excellent use of new technologies. But they do so to more or less the same ends: to critique or interpret a certain text or artifact or set of text or artifacts. Indeed, it is this act of criticism and interpretation that is central to our current vision of humanistic pursuit. It is what we mean when we talk about humanities. A journal article by other means isn’t a game changer. It is the very essence of the game we play.

If those things, so much of what we consider to be the work of digital humanities, don’t count as game changers, then what does count? In his new book, Reading Machines, Steve Ramsay argues that the promise of digital technologies for humanities scholarship is not so much to help us establish a new interpretation of a given text but to make and remake that text to produce meaning after meaning. Here Steve looks to the Oulipo or “workshop of potential literature” movement, which sought to use artificial constraints of time or meter or mathematics—such as replacing all the nouns in an existing text with other nouns according to a predefined constraint—to create “story-making machines,” as a model. He draws on Jerry McGann and Lisa Samuels’ notion of cultural criticism as “deformance,” a word that for Steve “usefully combines a number of terms, including ‘form,’ ‘deform,’ and ‘performance.'” For Ramsay digital humanists “neither worry that criticism is being naively mechanized, nor that algorithms are being pressed beyond their inability” but rather imagine “the artifacts of human culture as being radically transformed, reordered, disassembled, and reassembled” to produce new artifacts.

This rings true to me. Increasingly, our digital work is crossing the boundary that separates secondary source from primary source, that separates second-hand criticism from original creation. In this our work looks increasingly like art.

The notion of digital humanities as deformance or performance extends beyond what Steve calls “algorithmic criticism,” beyond the work of bringing computational processes to bear on humanities texts. Increasingly digital humanities work is being conceived as much as event as product or project. With the rise of social media and with its ethic of transparency, digital humanities is increasingly being done in public and experienced by its audiences in real time. Two recent CHNM projects, One Week | One Tool and Hacking the Academy, point in this direction.

An NEH-funded summer institute, One Week | One Tool set out to build a digital tool for humanities scholarship, from inception to launch, in one week. For one week in July 2010, CHNM brought together a group of twelve digital humanists of diverse disciplinary backgrounds and practical experience (Steve Ramsay among them) to build a new software application or service. The tool the group created, Anthologize, a WordPress plugin which allows bloggers to remix, rework, and publish their blog posts as an e-book, is currently in use by thousands of WordPress users.

At the outset, One Week | One Tool set out to prove three claims: 1) that learning by doing is an important and effective part of digital humanities training; 2) that the NEH summer institute can be adapted to accommodate practical digital humanities pedagogy; and 3) that digital humanities tools can be built more quickly and affordably than conventional wisdom would suggest. I think we succeeded in proving these claims. But as a project, I think One Week | One Tool showed something else, something unexpected.

One of the teams working on Anthologize during One Week | One Tool was an outreach team. We have found that outreach—or more crudely, marketing—is absolutely crucial to making open source tools successful. The One Week | One Tool outreach team made heavy use of Twitter, blogs, and other social media during the week Anthologize was built, and one of the strategies we employed was the Apple-style “unveil”—letting a user community know something is coming but not letting on as to what it will be. All twelve members of the One Week | One Tool crew—not only the outreach team, but the developers, designers, and project managers as well—joined in on this, live-Tweeting and live-blogging their work, but not letting on as to what they were building. This created a tremendous buzz around the work of the team in the digital humanities community and even among a broader audience (articles about One Week | One Tool turned up in The Atlantic, ReadWriteWeb, and the Chronicle of Higher Education). More interestingly, these broader communities joined in the discussion, inspired the team at CHNM to work harder to produce a tool (actually put the fear of God in them), and ultimately influenced the design and distribution of the tool. It was, as Tim Carmody, now of Wired Magazine put it, representative of a new kind of “generative web event.”

Quoting his colleague, Robin Sloan, Tim lists the essential features of the generative web event:

Live. It’s an event that hap­pens at a spe­cific time and place in the real world. It’s some­thing you can buy a ticket for—or fol­low on Twitter.

Gen­er­a­tive. Some­thing new gets cre­ated. The event doesn’t have to pro­duce a series of lumi­nous photo essays; the point is sim­ply that con­trib­u­tors aren’t oper­at­ing in play­back mode. They’re think­ing on their feet, col­lab­o­rat­ing on their feet, creat­ing on their feet. There’s risk involved! And that’s one of the most com­pelling rea­sons to fol­low along.

Pub­lish­able. The result of all that gen­er­a­tion ought, ide­ally, to be some­thing you can pub­lish on the web, some­thing that peo­ple can hap­pily dis­cover two weeks or two years after the event is over.

Per­for­ma­tive. The event has an audience—either live or online, and ide­ally both. The event’s struc­ture and prod­ucts are carefully con­sid­ered and well-crafted. I love the Bar­Camp model; this is not a BarCamp.

Ser­ial. It doesn’t just hap­pen once, and it doesn’t just hap­pen once a year. Ide­ally it hap­penn… what? Once a month? It’s a pat­tern: you focus sharply on the event, but then the media that you pro­duce flares out onto the web to grow your audi­ence and pull them in—to focus on the next event. Focus, flare.

To this list I would add a sixth item, which follows from all of the above, and is perhaps obvious, but which I think we should make explicit. Generative web events are collaborative.

CHNM’s Hacking the Academy project is another example from digital humanities of this kind of generative web event. On May 21, 2010, Dan Cohen and I put out a call for “papers” for a collectively produced volume that would explore how the academy might be reformed using digital media and technology. We gave potential contributors only seven days to respond, and during this time we received more than 300 submissions from nearly 200 authors.

Turning this into the “book” that eventually became Hacking the Academy would take considerably longer than a week. The huge response presented us with a problem, one that required us to rethink our assumptions about the nature of authorship and editing and the relationship between the two. Reading through the submissions, some as long as 10,000 words, others as short as 140 characters, we struggled with how to accommodate such a diversity of forms and voices. Our key breakthrough came when we realized we had to let the writing dictate the form of the book rather than the opposite. We established three formal buckets (“feature essays,” “coversations,” and “voices”) and three topical buckets (“scholarship,” “teaching,” and “institutions”) into which we would fit the very best submissions. Some of the good longer pieces could stand on their own, relatively unedited, as features. But in most cases, we had to give ourselves permission to be almost ruthless in the editing (at least when compared to long accepted notions of authorial versus editorial prerogative in academic writing) so that submissions would fit into the formal and intellectual spaces we created. Long or short, formal or informal, we let the best writing rise to the top, selecting contributions (either entire pieces or very often just a particularly compelling paragraph) that could be juxtaposed or contraposed or placed in conversation with one another to best effect.

In the end, the “book” exists in several forms. There is the “raw” index of every submission. There is our 150-odd-page remix of this material, containing more approximately 40 articles from more than 60 authors, which is being published online and in print by the University of Michigan’s MPublishing division and Digital Culture Books imprint. Then, and I think most interestingly, there are third-party remixes, including one by Mark Sample re-titled Hacking the Accident.

Appropriately, Hacking the Accident is itself a performance of sorts. Using the classic Oulipo technique of N+7, in which the author replaces every noun in a text with the noun seven dictionary entries ahead of it, Mark has created a new work, not of humanities scholarship, but of literature, or poetry, or theater, or something else altogether.

These are just two examples, two with which I am particularly familar, of what we might call “performative humanities.” There are others: most significantly, the lively performative exchanges that play out in the digital humanities Twittersphere every day. I wouldn’t go so far to say performance is the future of humanities in general or even digital humanities in particular. But I do think the generative web event is one example of a game-changing development. Performance is a different ball game than publication. The things required to make a successful performance are very different from the things required to make a successful text. It requires different skills, different labor arrangements, way more collaboration, and different economies than traditional humanities research.

We can look to new tools and new research findings, but I think we will only know for sure that digital humanities has changed the game when what it takes to succeed in the humanities has changed. We will know the game has change when bunting and base-running aren’t working any more, and a new kind of player with a new set of skills comes to dominate the field of play.

[Image credit: Wikipedia]

[This post is based on a talk I gave on February 13, 2012 at Brown University in Providence, Rhode Island. Many thanks to Michael Satlow for the kind invitation, generous hospitality, and an excellent two-day workshop.]

Connecticut Forum on Digital Initiatives

Today, I’ll be speaking at the Connecticut Forum on Digital Initiatives at the Connecticut State Library under the catch-all title, “The Roy Rosenzweig Center for History and New Media: New initiatives, oldies but goodies, and partnership opportunities with ‘CHNM North’.” The long and short of it is that the institutional realities of being a grant-funded organization and the imperatives of the Web have meant that CHNM has from the beginning been a dynamic and entrepreneurial organization that’s always, always looking for new opportunities, new partners, new collaborations.

Among the projects I’ll point to are:

Partners wanted.

Post-Doc at CHNM (North)

Many Found History readers will know that I have recently moved full-time to Connecticut, working remotely and traveling to Fairfax four or five days each month to meet with the gang at CHNM. Since moving north, I have been lucky to make a slew of new friends and colleagues in the bustling New England public history and digital humanities communities. Several new collaborations are percolating, and CHNM is now seeking a post-doc to help lead one of these, with the Connecticut Humanities Council.

Here’s the advertizement. I hope to see your application.

Postdoctoral Research Fellow

The George Mason University, Roy Rosenzweig Center for History and New Media (CHNM) within the Department of History and Art History is seeking a full-time Postdoctoral Research Fellow.

The Postdoctoral Research Fellow will work closely with CHNM’s Managing Director and colleagues at the Connecticut Humanities Council (CHC) on a new collaboration to create a central online resource for Connecticut state history. Based in Middletown, CT., near the campus of Wesleyan University, the Postdoctoral Research Fellow will provide primary project leadership, produce extensive historical content, and manage staff in close coordination with colleagues at CHNM and CHC. This is a unique opportunity to make a substantive leadership contribution to an innovative, high-visibility online resource in a relaxed but performance-centered environment with a team of humanists, designers and developers working at the cutting edge of digital humanities.

We are looking for someone who has earned a doctoral degree in history or a closely related field, and hands-on experience in digital humanities work. Priority will be given to candidates who have a track-record of conceiving, managing and completing Web-based and other public humanities projects. Writing experience for a production-oriented publication (e.g., a blog or newspaper) and familiarity with Wikipedia community norms and practices are preferred.

For full consideration, applicants must apply online at jobs.gmu.edu for position number F8860z; complete the faculty application; and upload a cover letter, curriculum vitae, and a list of three references with their contact information. We will begin considering applications on 9/13/11.

CHNM is the leading producer of open source tools for humanists and historical content on the Web (e.g., zotero.org, omeka.org, teachinghistory.org and gulaghistory.org). Each year CHNM’s award-winning project Web sites receive over 16 million visitors and over a million people relay on its digital tools to teach, learn and conduct research.

CHC is a public foundation incorporated in 1973 as a state-based affiliate of the National Endowment for the Humanities. CHC produces and funds public humanities programs that bring together people of different viewpoints, ages and backgrounds to explore issues of vital concern, share new ideas and perspectives, and experience the cultural richness around them.

PressForward

pressforward We have been threatening to do it for years. Frustrated with the inadequacies of traditional modes of scholarly publishing for the digital age, we have long batted around the idea of launching a “CHNM Press.” Today, we are pleased to announce the launch of PressForward, a new initiative to explore and produce new means for collecting, screening, and drawing attention to the vast expanse of scholarship that is currently decentralized across the web or does not fit into traditional genres such as the journal article or the monograph. In recent years, on sites like Slashdot, Techmeme, and Google News, the web beyond academia has developed sophisticated mechanisms for filtering for quantity. Over centuries, the academy has honed a set of methods of filtering for quality, through peer review. PressForward aims to marry these old and new methods to expose and disseminate the very best in online scholarship. We are pleased to add PressForward to our stable of projects (including THATCamp and Hacking the Academy) that are re-imagining scholarly communication for the Internet age and grateful to the Alfred P. Sloan Foundation’s Digital Information Technology program for making this exciting new adventure possible.

Learn more about PressForward on our new site, or by sending us an email. You can also follow us on Twitter or via RSS.

For Your Listening Pleasure: History Conversations

A few years back I had the bright idea to launch a second podcast (Digital Campus being the first). It languished. In fact, I only ever managed to record three episodes. The last one was recorded in February 2008.

It’s time to retire the website, but I don’t want to lose what I believe is some valuable content, especially the conversation I had with friends shortly after Roy’s death. So, here it is. The entire run of History Conversations, “an occasional dialogue with historians and history lovers about their interests, their ideas, and their lives in history,” in a single post.


Hello, World

In this pre-inaugural episode of History Conversations, Tom tests out his software and explains a little of the rationale behind the show. Join us in a couple weeks for our first conversation.

Running time: 4:41
Download the .mp3
[audio:http://foundhistory.org/audio/hc_0.mp3]


Episode 1 – Peter Liebhold

Tom kicks off the podcast with a conversation with Peter Liebhold, Chair and Curator of the Division of Work and Industry at the Smithsonian’s National Museum of American History. Tom asks Peter about his daily work at the Museum, his straight and not-so-straight road into history, and the role of public history … and pledges not to go another four months between episodes.

Running time: 29:29
Download the .mp3
[audio:http://foundhistory.org/audio/hc_1.mp3]


Episode 2 – Roy Rosenzweig, In Memoriam

In Episode 2 we remember Roy Rosenzweig, friend, colleague and pioneer in all manner of public history. Guests Mike O’Malley (co-founder of the Center for History and New Media and Associate Professor of History at George Mason University), Steve Brier (Vice President for Information Technology and External Programs at the CUNY Graduate Center and co-founder the American Social History Project), and Josh Brown (Executive Director of the American Social History Project and Professor of History in the Ph.D. program at the CUNY Graduate Center) join Tom for a conversation about Roy’s life, work, and long commitment to democratizing history.

Running time: 32:22
Download the .mp3
[audio:http://foundhistory.org/audio/hc_2.mp3]


Episode 3 – A Look Back at Braddock

This month the volunteer historians of the Look Back at Braddock project join Tom for a conversation about the challenges and opportunities posed by local history. Located near the center of Fairfax County, Virginia, Braddock District has changed rapidly in the 20th century, and members of the community have taken it upon themselves to document the changes. Working largely without funding, John Browne, Mary Lipsey, Gil Donahue, and their colleagues have produced a rich oral history collection, a successful book, and a new website. What does it take for a group of committed amateurs to launch and sustain a multi-year history project and what keeps them going? Find out here in Episode 3 of History Conversations.

Running time: 31:42
Download the .mp3
[audio:http://foundhistory.org/audio/hc_3.mp3]

Hey you! Come to THATCamp NCPH

Here is a partial list of places an easy workday’s drive from Pensacola, FL:

  • Athens, GA
  • Atlanta, GA
  • Auburn, AL
  • Baton Rouge, LA
  • Beaumont, TX
  • Biloxi, MS
  • Birmingham, AL
  • Chattanooga, TN
  • Gainsville, FL
  • Hattiesburg, MS
  • Huntsville, AL
  • Jackson, MS
  • Jacksonville, FL
  • Knoxville, TN
  • Lake Charles, LA
  • Macon, GA
  • Memphis, TN
  • Mobile, AL
  • Montgomery, AL
  • Nashville, TN
  • New Orleans, LA
  • Orlando, FL
  • Oxford, MS
  • Savannah, GA
  • Shreveport, LA
  • Tallahassee, FL
  • Tampa, FL

If you live in or near one of these places, or if you plan to be at the National Council on Public History Annual Meeting next month, or if you just happen to be in Pensacola on the 5th  of April, then you should come to THATCamp NCPH. It is open to everyone—not just people attending NCPH and not just public historians. Anyone with an interest in the humanities, technology, or both can attend for lots of creative unconference goodness. Registration closes tomorrow (March 15th), so hurry up and nab your seat.

Stuff Digital Humanists Like: Defining Digital Humanities by its Values

[A very rough transcript of my talk at the CUNY Digital Humanities Initiative on December 1, 2010. The DHI’s theme for this semester’s program was “What is Digital Humanities?” This is my attempt to answer—or dodge—that question. Many thanks to Matt Gold and all my friends at CUNY for a great event and a thought-provoking discussion.]

Our colleague Bethany Nowviskie might scold me if I didn’t preface this conversation by saying there are different strains of digital humanities. Bethany might define those strains as “old” and “new.” I’d probably divide things along more disciplinary lines, looking to a tradition of digital humanities that comes out of literature and one that comes out of public history. If I had to place myself along these axes I’d probably land where the “new” and “history” strains meet. There are, of course, lots of other ways to slice the pie.

But instead of exploring the genealogies of digital humanities any further, I’d like to switch gears and instead talk about digital humanities as community, or more precisely, as a set of overlapping personal communities, each one centered around individual, self-identified digital humanists. Thought of this way, digital humanities starts to look a lot like a social network. Indeed, in some ways digital humanities increasingly is a social network built, for better or worse, on Twitter’s platform. What follows is a description of digital humanities as seen from my vantage point as a node in that social network.

In as much as digital humanities is an Internet-based social network, it should come as no surprise that digital humanities looks a lot like the Internet itself. Digital humanities takes more than tools from the Internet. It works like the Internet. It takes its values from the Internet.

Jonathan Zittrain does a good job of describing these values in his excellent book, The Future of the Internet and How to Stop It. Among the values Zittrain says are hard coded into the very architecture of the Internet are something he calls the “procrastination principle” and something he calls the “trust your neighbor approach.”

The procrastination principle (or “end-to-end argument”) is a design principle that states that most features of a network should be left to users to invent and implement, that the network should should be as simple as possible and that complexity should be developed at its end points not at its core, that the network should be dumb and the terminals should be smart. This is precisely how the Internet works. The Internet itself doesn’t care whether the data being transmitted is a sophisticated Flash interactive or a plain text document. The complexity of Flash is handled at the end points and the Internet just transmits the data.

There is an analogous value in digital humanities. Innovation in digital humanities frequently comes from the edges of the scholarly community rather than from its center—small institutions and even individual actors with few resources are able to make important innovations. Institutions like George Mason, the University of Mary Washington, and CUNY and their staff members play totally out-sized roles in digital humanities when compared to their roles in higher ed more generally, and the community of digital humanities makes room for and values these contributions from the nodes.

Zittrain points out that the procrastination principle necessarily implies a second principle he dubs the “trust your neighbor approach.” In order to permit innovation from the nodes, the network has to trust that those innovations are benign. Moreover, the network requires one server to pass along another’s packets: when I send an email to a colleague in Australia, I have to trust that my data packets will be passed along by other machines on the network in the several hops they will have to take to get to their destination. The Internet assumes assumes people will be good citizens.

Digital humanities makes some similar assumptions in its commitments to open access, open source, and collaboration. As Bethany has said elsewhere, “how many other academic disciplines or interdisciplines work so hard to manifest as ‘a community of practice that is solidary, open, welcoming and freely accessible’ — a ‘collective experience,’ a ‘common good?'” We allow allow all comers, we assume that their contributions will be positive, and we expect that they will share their work for the benefit of the community at large.

Thus in some important respects, the values of digital humanities proceed directly from the design decisions made by the original architects of the Internet. Surely we don’t always live up to these ideals, but we value them just the same.

Or at least this is the direction my theorizing of the question “What is Digital Humanities?” increasingly takes me. But in the end, I’m not sure that theorizing this question is particularly useful. Fortunately, thinking of digital humanities as a social network provides another vector along which to define it: the stuff around which it coalesces.

Most of you will already have groked the not-so-hidden reference to the Stuff White People Like blog in my title today. For those of you who aren’t familiar with this blog, it was started in 2008 by a blogger named Christian Lander and later turned into a bestselling book by the same title. Along the way, it was imitated by hundreds of other “stuff * like” blogs.

As you can see from this list, the “stuff * like” concept is by now pretty cliched. But the fact that it has been so successful as an Internet meme points to its utility: it is often easier, more comprehensible, and more productive to define diverse and diffuse communities—especially Internet communities—in terms of the things to which they gravitate rather than the abstract conceptual boundaries that separate them from other communities.

Indeed, this insight is not unique to “stuff * like” bloggers. In its current sorry state we forget how successful MySpace once was, but it became for a time the dominant social network largely on the strength of this insight, by identifying music as one of most important things around which social groups congregate. In many respects, MySpace was community or set of overlapping communities built around bands and shared music tastes. IMDB does something similar with movies. Digg does it with web links. Yelp does it with restaurants. Even Apple is directly trying to capitalize on MySpace’s original insight with its dubiously successful new music centered social network, Ping.

It follows, therefore, that if digital humanities is a social network, then one of the things that will help us understand it better is looking at the things around which the network coalesces, the stuff digital humanists like. In this I’d also make one possibly more controversial claim: not only do we like these things better than their alternatives, we like them better than their alternatives because they work better than their alternatives in the real world.

Here are five to start us off:

  • Like: Twitter / Don’t like: Facebook. The first thing we have to mention, which we have mentioned a few times already, is Twitter. The reasons we like Twitter are complex and I won’t pretend to understand them all, but I’ll throw out a few suggestions. First, its “follow” rather than “friend” model is more open, allows for the collaboration and non-hierarchy that the Internet and digital humanities values. Second, and related to this, Twitter is the place where content-creators—journalists, writers, artists, web developers, etc.—tend to hang out. We overlap with those communities, or at least seek to overlap with them, in productive ways. They are the distant nodes from which we hope new innovations will come. Third, Twitter, in the way we use it, is mostly about sharing ideas whereas Facebook is about sharing relationships. Scholars are good at ideas, maybe less so at relationships.
  • Like: Agile development / Dislike: long planning cycles. The second thing I’ll mention is agile development, the philosophy of “releasing early and often,” which we do not only with software/code but also with our ideas and writing when we Tweet, blog, and chat. We do this as good neighbors but also in the hope that releasing our code and ideas will improve with contributions from end points of our networks.
  • Like: DIY / Dislike: Outsourcing. Most of the most successful digital humanities projects are those done by scholar/technologists not those imagined by scholars and implemented by technologists. Likewise, the most successful digital humanists are scholars who know the technology, often those who are self-taught, not ones who seek a client-vendor relationship with technologists. We take this insight to heart in our hiring at CHNM, looking for people with formal training in the humanities and self-taught tech skills.
  • Like: PHP / Dislike: C++. Fourth, and following from the last point, we like PHP not C++. This is another way of saying we like the transparent, easy-to-learn, and simple (if sometimes ham-handed) technologies of the Web more than the more powerful, more sophisticated, more elegant, but less approachable compiled code of the desktop. A focus on getting the most out of simple, transparent, vernacular technologies allows us to keep the door to the field open to new entrants.
  • Like: Extramural funding / Dislike: Intramural funding. In one respect, this may seem obvious: everybody likes grants. In another respect it’s probably going a little too far to say we don’t like intramural funding: it is essential to building and maintaining capacity for our centers and staff. But it seems to me the most successful digital humanities projects are those that result from competitive grant making processes, especially the federal grant making process. Why is this? I can point to at least three reasons: 1) Attracting grant money keeps us innovating, which, like it or not, is a premium in our business. Grants are given for new work, not for more of the same. 2) Writing grants and serving on panels keep us in conversation with the field. We have to keep current and keep in touch with one another to justify our projects to grantmakers and to recommend others’ projects for funding. Increasingly, funding guidelines themselves require collaboration. 3) Unlike much traditional scholarship, which often requires one big deliverable (a book) after years of close-kept study, research, and writing, grant work requires defining and meeting a set of closely timed, concrete deliverables, a mode of work which encourages the kind of agile development so valued by the Internet and digital humanities community.

These things represent a set of shared interests, map onto a set of shared values, and in doing so they identify and define a community. We could identify lots of other things that digital humanists like and dislike. In fact your list may be very different than mine—please let me know in comments. As I said at the outset, this is just the view from my node in the network.

I haven’t “defined” digital humanities beyond defining my community and its values today and I don’t think I need to go any further than that at this point. Elsewhere I have suggested that perhaps digital humanities doesn’t have to answer questions, at least not yet. Likewise I’m not sure we have to define digital humanities yet beyond describing a community and a set of shared values. Our job for now is to continue to work together, and the rest will take care of itself.

Digital rocking the public history job market

Things are looking up for digitally minded public historians. At least six new media focused tenure-track academic public history positions are open this fall, including:

Happy hunting!

Omeka and Its Peers

As an open source, not-for-profit, warm-and-fuzzy, community service oriented project, we don’t normally like to talk about market rivals or competitive products when we talk about Omeka. Nevertheless, we are often asked to compare Omeka with other products. "Who’s Omeka’s competition?" is a fairly frequent question. Like many FAQs, there is an easy answer and a more complicated one.

The easy answer is there is no competition. 😉 Omeka’s mix of ease of use, focus on presentation and narrative exhibition, adherence to standards, accommodation for library, museum, and academic users, open source license, open code flexibility, and low ($0) price tag really make it one of a kind. If you are a librarian, archivist, museum professional, or scholar who wants a free, open, relatively simple platform for building a compelling online exhibition, there really isn’t any alternative.

digital_amherst

[Figure 1. Digital Amherst, an award-winning Omeka powered project of the Jones Library in Amherst, MA.]

The more complicated answer is that there are lots of products on the market that do one or some of the things Omeka does. The emergence of the web has brought scholars and librarians, archivists, and museum professionals into increasingly closer contact and conversation as humanists are required to think differently and more deeply about the nature of information and librarians are required to play an ever more public role online. Yet these groups’ respective tool sets have remained largely separate. Library and archives professionals operate in a world of institutional repositories (Fedora, DSpace), integrated library systems (Evergreen, Ex Libris), and digital collections systems (CONTENTdm, Greenstone). Museum professionals operate in a world of collections management systems (TMS, KE Emu, PastPerfect) and online exhibition packages (Pachyderm, eMuseum). The humanist or interpretive professional’s online tool set is usually based around an off-the-rack web content management system such as WordPress (for blogs), MediaWiki (for wikis), or Drupal (for community sites). Alas, even today too much of this front facing work is still being done in Microsoft Publisher.

The collections professional’s tools are excellent for preserving digital collections, maintaining standardized metadata, and providing discovery services. They are less effective when it comes to exhibiting collections or providing the rich visual and interpretive context today’s web users expect. They are also often difficult to deploy and expensive to maintain. The blogs, wikis, and off-the-rack content management systems of the humanist (and, indeed, of the public programs staff within collecting institutions, especially museums) are the opposite: bad at handling collections and standardized metadata, good at building engaging experiences, and relatively simple and inexpensive to deploy and maintain.

Omeka aims to fill this gap by providing a collections-focused web publishing platform that offers both rigorous adherence to standards and interoperability with the collections professional’s toolkit and the design flexibility, interpretive opportunities, and ease of use of popular web authoring tools.

omeka_tech_ecosystem

[Figure 2. Omeka Technology Ecosystem]

By combining these functions, Omeka helps advance collaboration of many sorts: between collections professionals and interpretive professionals, between collecting institutions and scholars, between a "back of the house" and "front of the house" staff, and so on.

omeka_user_ecosystem

[Figure 3. Omeka User Ecosystem]

In doing so, Omeka also helps advance the convergence and communication between librarians, archivists, museum professionals, and scholars that the digital age has sparked, allowing LAM professionals to participate more fully in the scholarship of the humanities and humanists to bring sophisticated information management techniques to their scholarship.

Which brings us back to the short answer. There really is no competition.

One Week | One Tool: Interim Report

As promised on Twitter, I’m sharing the report (with a few minor copyedits and corrections) I submitted this week to NEH on One Week | One Tool. This is an interim report, which means there are plenty of questions that remain unanswered. The grant continues for another year, during which time the One Week | One Tool crew will be working to support and extend their work together. I’m sure I’ll be blogging about their progress as we go, but at the very least I’ll post again with the final report next summer.

Executive Summary

One Week | One Tool represents a groundbreaking experiment in digital humanities training and digital humanities tool building. Culminating with the institute held July 25 – July 31, 2010 at the Center for History and New Media (CHNM) at George Mason University and the institute participants’ successful construction and release, in seven days, of a completely new open source software product, One Week | One Tool has made significant strides in proving its central claims: 1) that learning by doing is an important and effective part of digital humanities training; 2) that the traditional NEH summer institute can be adapted to accommodate this kind of practical digital humanities pedagogy; and 3) that digital humanities tools can be built more quickly and affordably than common practice would suggest. The second year of the project will seek to reinforce these claims and continue to advance participant learning through ongoing engagement and further development of the tool that was built during their week at CHNM—Anthologize.

Recruitment

The first task of the One Week | One Tool team was to publicize the institute. After dates were chosen, we developed a simple website in the style of an Old West poster to call for proposals. The call for proposals was issued in early February and closed in mid-March. To publicize the call, we leveraged CHNMs extensive outreach networks among digital humanities bloggers and on Twitter, where the announcement generated significant attention and excitement. Applicants were asked to answer three questions: 1) What skills/experiences/interests you think are most important to building a successful tool? 2) Which of these skills/experiences/interests you will bring to the barn raising? 3) What you think you will get out of attending that will help you in future pursuits? From this call, we received 48 formal applications and approximately another dozen serious expressions of interest.

The selection process was remarkably difficult. At least 35 of the 48 applicants were perfectly qualified to attend. To differentiate among them, we stuck to the criteria we outlined in our original proposal and laid out in the call. Applicants were chosen not on the basis of specific qualifications (e.g. a higher degree or particular skill set), but on evidence of teamwork, patience, flexibility, and resourcefulness (such as a history of picking up a programming language on one’s own). We were also looking to assemble a diverse group who together would possess the entire range of skills necessary to conceive, manage, build, and disseminate a tools project. The final group represented a broad range of scholars, students, librarians, museum professionals, developers, user interaction designers, bloggers, and project managers. They were also relatively diverse in terms of gender (4 women, 8 men) and seniority (ranging from a recently graduated college student to a tenured faculty member). Given the importance of intra-team dynamics to the success of software development projects, we took pains to introduce participants to one another via Twitter in the weeks after their acceptance so that they could begin establishing a sense of camaraderie ahead of their intense week of working together in July.

The Institute

Institute participants arrived on Sunday, July 25, 2010 for a kick-off meeting at George Mason University’s brand new Mason Inn and Conference Center, which served as the participants’ home away from home during One Week | One Tool. Participants’ transportation and lodging were arranged and paid ahead of time, with an additional $1000 stipend provided to each participant as an honorarium and to cover any incidentals. After a round of personal and professional introductions, project director Tom Scheinfeldt provided a brief introduction to CHNM and some of the core values CHNM brings to its open source software development work. Particular emphasis was placed on the value of "use," that the best measure of a tool’s success is its uptake and actual use by its intended audience. The first evening concluded with a brief discussion of participant and organizer expectations and an exhortation to get a good night’s sleep.

Monday was originally designed as the "teaching" phase of One Week | One Tool, during which CHNM staff members would provide participants with some lessons in software development best practices. This was ultimately the least successful portion of the program. Although introductory talks on technical aspects of software development (Jeremy Boggs), outreach mechanisms and community building (Trevor Owens), and the state of the art of digital humanities tools (Dan Cohen) were well received, participants were eager to get down to brass tacks, and we made a strategic decision to cut short the lectures and begin brainstorming tool choices a half day early on Monday afternoon.

Brainstorming continued through Monday evening and into Tuesday morning. By mid-morning on Tuesday, the group had proposed dozens of possible directions for the week’s tool building. By lunchtime, it had distilled those ideas down to six possible candidates. Over lunch, the group asked followers on Twitter to vote on the six choices. Well over 50 outside observers recorded their preferences. Taking this outside feedback into account, the group conducted two rounds of voting of its own, making a final consensus decision by mid-afternoon on Tuesday.

Work then turned to choosing roles and responsibilities. With guidance from CHNM staff, by Tuesday evening, participants had arranged themselves into three teams: Development, User Experience, and Outreach. Work began immediately, with developers making choices about encoding and architecture, user experience team members outlining potential use cases, and outreach staff researching the competitive marketplace and writing website copy.

Wednesday, Thursday, and Friday were each long days of code, design, and writing. The group quickly established a daily routine, which started with an all-project check-in meeting at CHNM’s offices at 10:00 a.m., was punctuated by a return to the Mason Inn at about 6:00 p.m., and ended with yet more work
at the hotel bar, usually until well past closing. Communication, leadership, and even membership among the teams were fluid, with teams spontaneously reconfiguring as particular skills were required for particular tasks. Moreover, throughout this "doing" phase, Tom, Dan, Jeremy, and Trevor encouraged additional CHNM staff—including Sharon Leon, Sheila Brennan, Ammon Shepherd, and John Flatness—to be available to help participants solve problems and make tough decisions. By Saturday morning, the One Week | One Tool team had designed and built the software; established an open code repository, a ticketing and bug tracking system, and a set of open source community development channels; and mounted an outreach and marketing campaign that consisted of an original name, logo, and website, as well as promotional bookmarks and stickers, a CafePress storefront, a formal press release, a media contact sheet, a set of public use cases, an FAQ page, and other end-user support channels.

During the course of the week, several members of the team "live blogged" and Tweeted (using the hashtag #oneweek) about this process, but they did so without giving away the final choice of tool, which served to create a buzz about the launch among potential users in the digital humanities community. Between July 25th and August 1st, hundreds of tweets were tagged #oneweek, mostly by outside observers, a measure of the extent to which One Week | One Tool captured the imagination of the digital humanities community. The tool the group produced, Anthologize, was launched on Tuesday, August 3, 2010 with a live video episode of CHNM’s popular Digital Campus podcast. More than 125 people took time out of their work day to tune in to the live announcement. In the days following the announcement, One Week | One Tool and the Anthologize were featured by Atlantic.com, Read Write Web, the Chronicle of Higher Education, and dozens of digital humanities blogs. As one external commentator put it, Anthologize and One Week | One Tool experiment had "set the DH world abuzz."

Anthologize

Anthologize is a free, open-source plugin that transforms WordPress 3.0 into a platform for publishing electronic texts. Anthologize lets users grab posts from their WordPress blog, import feeds from external sites, or create new content directly within Anthologize. Users can then outline, order, and edit their work, crafting it into a single volume for export in several formats, including PDF, ePUB, and TEI. Among Anthologize’s projected users are scholars (to edit anthologies of thematically related blog posts or publish conference proceedings), teachers (to edit student class work into e-portfolios or organize course reading packs), and cultural institutions (to publish exhibit books or donor gift books). Directions for future development include additional export formats, improved importing of external web content, footnote support, and integrating blog comments into the Anthologize editorial workflow.

Learning Outcomes

We are still collecting survey responses and assessing the results, but early on it is clear that One Week | One Tool was a positive learning experience for the participants. Unlike many curriculum-based institutes, the experiences and therefore the learning outcomes at One Week | One Tool varied widely among the participants depending on their team membership and on the skills they brought to the institute. Nevertheless, an initial analysis of participant survey responses reveals some commons themes. Among them:

  • Most participants responded that they learned about collaboration, leadership, and team building. Doug Knox pointed to the "self-taught lessons in group dynamics for a team of pragmatic collaborative autodidacts" he took from One Week | One Tool. As one participant responded, those lessons included "the kind of flexibility, trust, humility, and perseverance that is necessary to take on a relatively big project in a short period of time." In a post titled "Unexpected leadership," Boone Gorges echoed these lessons, writing "leadership doesn’t work without humility and trust." Effie Kapsalis described that same lesson plainly on the Smithsonian 2.0 blog: "Trust. Period."
  • Related to this were the lessons in decision making and calculated risk that most participants said they took away. As one participant wrote, "the experience really made me understand how much fear of acting alone can stall development and how trusting the emergent properties of the system can really lead to fantastic results." Jana Remy wrote in a related vein on her blog, "…one of the most important things we’ve learned through this workshop is the importance of calculated risk. It’s risky to forge forward with a digital project without months of planning, coding, and testing. It’s risky to trust near-strangers to deliver on such a tight deadline…. Our team selected one of the more daring choices available for our project. We were ready to be bold and to dream big. Even if the rest of the world doesn’t see our tool’s potential to be as earthshaking as we do, the process of manifesting our vision for this tool has been a valuable lesson in and of itself, and will certainly carry through to our future endeavors."
  • Several participants responded that they learned about outreach methods, marketing, and dissemination of digital humanities products. As one participant said, "I really found the information on how to manage publicity and outreach extremely useful, and I was completely stunned by the results…."
  • Several participants said they learned particular technologies (e.g. WordPress and Git) and practical lessons in open source software development best practices: "I also think I came to understand a bit more about how agile methodologies really work," remarked one participant.
  • Some participants pointed to their improved understanding of "what constitutes a full end-to-end development cycle." Experienced programmers and project managers, even those who entered the week with hundreds of thousands of lines of code under their belts and long track records of successful digital humanities work, responded that they learned about the differe
    nces between building a tool "from conception to roll-out" as they did at One Week | One Tool and the ad-hoc or task-specific development they do in the normal course of their work.

Every participant that responded to our survey said that One Week | One Tool met or exceeded his or her expectations, that it met its stated goals, that the experience would advance his or her career objectives, and that the model of learning by doing was effective. There were, however, at least two criticisms that were repeated by several participants. First, as mentioned above, most participants would have preferred to cut the Monday lecture portion of the program shorter, something we addressed on the spot and will keep in mind for any possible repeat events. Second, at least two people wanted to see more learning from fellow team members. The fast paced development cycle too often forced participants to keep their noses to the grindstone and opportunities for cross-pollination and peer-to-peer learning were sometimes missed. In any repeat performance of One Week | One Tool we will take seriously one participant’s observation that "…the group itself would have benefited from a more concerted effort to mix up knowledge multilaterally. There was some tension between working in small teams to get work done and making sure we had informal chances to share a sense across groups about the state of progress and the development of our sense of purpose. There were in fact essential unplanned lateral communications in all directions, and the bar was especially important in that. It worked, but there could be room to make it a more reflective process. We should have been teaching our strengths as well as contributing them, and apprenticing in our less-strong areas."

Yet in discussing One Week | One Tool’s learning outcomes, it is also important to note that, perhaps unlike more traditional institutes, the learning appears to have extended well beyond the twelve participants who traveled to Fairfax. This possibly unique aspect of One Week | One Tool results from the fact that: 1) it was an event, and 2) it produced a product for widespread distribution and use. As Tim Carmody posted on Snarkmarket, One Week | One Tool was a "generative web event," an "ongoing communal broadcast." Because it took place over a limited and clearly delineated time period, because it posited a provocative, easy-to-grasp, and unlikely challenge (academics build something in a week?), because it maintained an air of secrecy, and because it was widely publicized, One Week | One Tool was able not only to create "buzz" but to provoke conversation and discussion of serious issues among a broad range digital humanities scholars who could use their common experience of One Week | One Tool as a touchstone for debate. Two examples of this kind of broader discussion are ongoing exchanges about the nature of electronic writing and its relationship to the printed page and about the relative merits of pre- versus post-launch user studies.

Next Steps

Over the next year, the original group of twelve participants will continue to develop the tool from remote locations around the country, forming the core of an open source developer and user community that they will build and support. Indeed, the team has already developed and released a "point release" version 0.4 in the time since they left Fairfax. During the next ten months, the group will fix bugs in the software and add new features. It will continue to disseminate the software through online outreach and in-person conference presentations. As part of the group’s training in digital humanities software sustainability, it will also work with staff at CHNM to write grant proposals for additional funding and implement cost recovery mechanisms where appropriate. In June 2011, the group will travel back to Fairfax for THATCamp 2011 to assess the progress of the past year, gather additional feedback from community members, and make decisions about future development and support of Anthologize.

Conclusion

Overall, we are pleased with the progress of the One Week | One Tool project. The main learning objective of the project was to teach software development and deployment skills to a group of diverse group of digital humanists. As explained to participants on the first evening of the institute, we believe the best measure of the success of a tool is its use by and usefulness to its intended audience. By extension, the best measure of whether a group of people have learned to build successful tools is whether the tool they built is actually useful to and used by its audience. Early indications are good. In less than ten days the Anthologize website has received 232,000 hits, 75,000 page views, and 13,000 unique visitors, and the Anthologize software has been downloaded more than 2,500 times. We have high hopes for the coming year, and we will continue to keep track of these numbers and follow the projects that use Anthologize.