Digital Humanities – Page 2

Getting into Digital Humanities: A top-ten list

Today I’ll be joining a roundtable discussion hosted by the New York Council for the Humanities for its incoming class of public humanities fellows. I was asked to prepare a “top-ten list” for public humanists looking to get started in digtial humanities, and with the help of friends on Twitter, I came up with the following:

Stop worrying about the definition of DH: One thing people like you, who are starting out in digital humanities do is worry an awful lot about the definition of digital humanities. Is what I’m going really digital humanities? Does it count as digital humanities? I’m here to tell you to stop worrying about whether what you’re doing is or is not digital humanities. Stop worrying about the definition of digital humanities. Digital humanities is not a thing, it’s not a discipline, it’s not a field. Digital humanities is a community of practice and once you enter that community of practice, once you starting working with other people who call themselves digital humanists, who are in that community of practice, once you start attending events where digital humanists frequent, once you start doing those things, once you start entering that community of practice, you are a digital humanist and whatever you’re doing counts.
Enter the circle: The first thing you should do is get yourself on Twitter. I know people are skeptical of Twitter and for some very good reasons. But when it comes to digital humanities that’s really where the community is so I would suggest getting a Twitter account and then getting a couple of other things. Next thing you should do is get a Feedly account. Feedly is an RSS reader. There are other RSS readers that you may want to use. Feedly is a web-based service that’s very easy to get up and running with. Get a Feedly account. Start subscribing to blogs. Start reading those blogs. Start Tweeting the link that you find there. The way that the digital humanities community uses Twitter is to share links to interesting resources, interesting readings, and other things that they find on the web. You start doing that, you’ll start getting followers and you should start following some people. Find a digital humanist you know and whose work that you like on Twitter, find out who that person is following and follow the people that she’s following. Once you start doing that, you’ll start seeing the kinds of issues that digital humanists are interested in. Then what you should start doing is blogging yourself. Go get yourself a WordPress blog. Either host it yourself or host it at wordpress.com. Start writing down your own thoughts, Tweeting links to that. Other people will start putting your feed from your WordPress blog in their Feedly accounts. They’ll start subscribing to your blog, reading your blog, tweeting your links. This is what I call entering the circle. Really, the digital humanities, and I’m going to say this several times during the course of this video, digital humanities is really a community of practice. That’s all it is and so you need to enter that community of practice and the best way to do that, the first way to do that, is online through these social media, that sort of virtuous circle of blogs, Twitter, and RSS feeds.
Start with partners: An interesting thing happened to me when I was preparing this list that I think illustrates the last point on the list and leads us to the next point on the list. When I started writing this up I posted an update to Twitter asking for suggestions from my followers, the community of DHers who I engage with, what they thought were the top 10 lessons that a new digital humanist like yourselves could and should learn. I got a lot of great feedback, some of which is in this talk. I ended up in a long discussion with two colleagues, Jason Heppler and Trevor Owens, and we were debating the merits of whether we should advise people to start with a particular tool if they were looking to get into digital humanities or whether they should start with a research question and find a tool to match that. Should they let the tool determine the research question or should they let the research question determine the tool? And we talked about that back and forth. I tend to lean on the tool side. Other people lean on the research question side. But, in fact, I don’t come down really on either side. I actually think you should start with something else, a third thing, and that’s with collaboration. All digital humanities projects are collaborations or nearly all. There are very few digital humanities projects that you can do fully on your own. Most things require a team of people or at least a couple of people because there’s a lot of different skills involved with digital humanities projects and it’s very rare that one person brings all of those skills to bear, that all of the skills necessary to carry out the project are contained in the skillset of one person. So most projects, almost all projects, are collaborations and what I like to do – and this is my practice, this is the way I work – is I like to find the partners first. I like to find people who I think are doing great work, who I think are interesting, who I think I really want to work with, who are cool, whatever and I look for the spaces between our work, the spaces between the partners where we intersect, where we overlap, where interesting work can be done.
Attend THATCamp: So who are these partners? Well, if you’re a technical person you probably should want to seek out some content folks to provide you with the stuff that’s going to fill the database, that your project is going to be based around. If you are a non-technical person, well, you should probably be searching for some technical assistance, some people with a more technical bent. Those are often the pairings that we find. Where do you find those people? Well, a very good place to find those people if you don’t already know them, and you may. They may be your close collaborators and that’s always the first place to look but if they’re not one place to look for them is THATCamp, The Humanities and Technology Camp. THATCamp started in 2008 at the Center for History and New Media at George Mason University as an unconference, a very informal gathering of people with an interest in the humanities and technology. A very low overhead gathering and a very informal and non-hierarchal gathering where people of all experience levels, all skill levels, all technical interests and backgrounds, all humanities interests and background could get together in a very non-threatening environment to find one another and connect. Since 2008, these events have grown virally and there have now been more than 150 locally organized, grass roots THATCamps around the world. There’s surely one near you. Go to thatcamp.org. You’ll find a map there on the home page, which lists upcoming THATCamps in an area near you. I know there are several going in the Northeast in the next several months and I encourage you strongly to start there as a place to look for partners, educate yourself, and especially to connect.
Write grants, not papers (or write grants and papers): Digital humanities is a projects-based field. What that means is that people and institutions in digital humanities are known more for their projects than for their publications. That means that it’s often more important to write a grant proposal than it is to write a paper. Writing a grant proposal forces you to describe what it is that you’re going to do. Describing what you’re going to do is the first step to getting something done and being done is the goal of every project. So if you want to finish a project, start with a grant proposal. Start with a description of what you’re going to do, not with what you think.
Release Early and Often: When you’re starting a project, sometimes it’s useful to think about the smallest version of that project, the smallest possible version of the project that will still be complete. So let’s say that you were thinking about building a vast archive of digital primary sources. Well what’s the smallest possible version of that project? Well maybe it’s a list of the 10 most important of those sources. Maybe it has some dates, some call numbers, and an image or two pasted to a piece of paper. That is still the project, it’s just not the fully realized, the most elaborate version of the project that you can think of. We sometimes call this the minimum viable product. Then what you do with that minimum viable product is you get it out there as quickly as possible. You get it out there to the audience so that you can receive feedback, bug reports, and then roll that feedback back into the next version of the product, the next minimum viable product, which will have gone some way towards your fully realized version of the project. We call this strategy of minimum viable products and releasing early and often, agile development and it’s how the best digital humanities projects are built.
Digital is always public: One thing this notion of community of practice and release early and often points to is that digital humanities is essentially public humanities. All digital work is public. When you put something out there on the web it is a public document and it will be found by people who you never intended to find it. Means you have to be very careful when doing digital work to think first and foremost about audience. When starting a digital humanities project audience should be uppermost in your mind and as you continue to release versions of the project, to iterate, to work in an agile fashion on the project, always keep in mind the audience for the project.
Try.New.Things: One of the hardest things about digital humanities to me is that the technologies keep changing out from under you. What that means is you always have to be willing to try new things, to try, to fail, to pick up a piece of software, a new method, to work with it, to figure it out on your own. Most digital humanists are self-taught. You can’t wait for someone to train you. The politics of intellectual property aside, one of the reasons that digital humanists love open source technologies and standards like the Web and Firefox and other open source software packages is because you can open them up and you can change the code, and especially because you can break them.
Break something: Breaking things and then fixing them is one of the very best ways to learn a new technology. The ability to break open source software, to figure out what you did wrong, to go in and change it, fix it, and maybe even make it better, is one of the best teaching methods out there.
Lather, rinse, repeat: You will never stop learning. The situation of trying new things, breaking things, fixing them, learning how to do that is something that you’ll have to do continually in digital humanities. The technologies are always changing out from under you. The methods are always changing, evolving. You have to evolve as a practitioner with them.

N.B. As my mother always told me, “do as I say, not as I do.”

Innovation, Use, and Sustainability

Revised notes for remarks I delivered on the topic of “Tools: Encouraging Innovation” at the Institute of Museum and Library Services (IMLS) National Digital Platform summit last month at the New York Public Library.

What do we mean when we talk about innovation? To me innovation implies not just the “new” but the “useful.” And not just the “useful” but the “implemented” and the “used.” Used, that is, by others.

If a tool stays in house, in just the one place where it was developed, it may be new and it may be interesting—let’s say “inventive”—but it is not “innovative.” Other terms we use in this context—”ground breaking” and “cutting edge,” for example—share this meaning. Ground is broken for others to build upon. The cutting edge preceeds the rest of the blade.

The IMLS program that has been charged and most generously endowed with encouraging innovation in the digital realm is the National Leadership Grants: Advancing Digital Resources program. The idea that innovation is tied to use is implicit in the title of the program: the word “leadership” implies a “following.” It implies that the digital resources that the program advances will be examples to the field to be followed widely, that the people who receive the grants will become leaders and gain followers, that the projects supported by the program will be implemented and used.

This is going to be difficult to say in present company, because I am a huge admirer of the NLG program and its staff of program officers. I am also an extremely grateful recipeint of its funds. Nevertheless, in my estimation as an observer of the program, a panelist, and an adwardee, the program has too often fallen short in this regard: it has supported a multitude of new and incredibly inventive work, but that work has too rarely been taken up by colleagues outside of the originating institution. The projects the NLG program has spawned have been creative, exciting, and new, but they have too rarely been truly innovative. This is to say that the ratio of “leaders” to “followers” is out of whack. A model that’s not taken up by others is no model at all.

I would suggest two related remedies for the Leadership Grants’ lack of followers:

More emphasis on platforms. Surely the NLG program has produced some widely used digital library and museum platforms, including the ones I have worked on. But I think it bears emphasizing that the limited funds available for grants would generate better returns if they went to enabling technologies rather than end prodcuts, to platforms rather than projects. Funding platforms doesn’t just mean funding software—there are also be social and institutional platforms like standards and convening bodies—but IMLS should be funding tools that allow lots of people to do good work, not the good work itself of just a few.
More emphasis on outreach. Big business doesn’t launch new products without a sale force. If we want people to use our products, we shouldn’t launch them without people on staff who are dedicated to encouraging their use. This should be refelected in our budgets, a much bigger chunk of which should go to outreach. That also means more flexibility in the guidelines and among panelists and program officers to support travel, advertizing, and other marketing costs.

Sustainability is a red herring

These are anecdotal impressions, but it is my belief that the NLG program could be usefully reformed by a more laser-like focus on these and other uptake and go-to-market strategies in the guidelines and evaluation criteria for proposals. In recent years, a higher and higher premium has been placed on sustainability in the guidelines. I believe the effort we require applicants to spend crafting sustainability plans and grantees to spend implementing them would be better spent on outreach—on sales. The greatest guarantor of sustainiability is use. When things are used they are sustained. When things become so widely implemented that the field can’t do without them, they are sustained. Like the banks, tools and platforms that become too big to fail are sustained. Sustainability is very simply a fuction of use, and we should recognize this in allocating scare energies and resources.

The Dividends of Difference: Recognizing Digital Humanities' Diverse Family Tree/s

In her excellent statement of digital humanities values, Lisa Spiro identifies “collegiality and connectedness” and “diversity” as two of the core values of digital humanities. I agree with Lisa that digital humanists value both things—I certainly do—but it can be hard to *do* both things at the same time. The first value stresses the things have in common. The second stresses the ways we are different. When we focus on the first, we sometimes neglect the second.

This is something that has been driven home to me in recent months through the efforts of #dhpoco (post colonial digital humanities). Adeline and Roopika have shown us that sometimes our striving for and celebration of a collegial and connected (or as I have called it, a “nice”) digital humanities can, however unintentionally, serve to elide important differences for the sake of consensus and solidarity. #dhpoco has made us aware that a collegiality and connectedness that papers over differences can be problematic, especially for underrepresented groups such as women and minorities, especially in a discipline that is still dominated by white men. A “big tent” that hides difference is no big tent at all.

As these critiques have soaked in, they have led me to wonder whether the eliding of differences to advance a more collegial and connected digital humanities may be problematic in other ways. Here I’m thinking particularly of disciplinary differences. Certainly, the sublimation of our individual disciplines for a broader digital humanities has led to definitional problems: the difficulty the field has faced in defining “digital humanities” stems in the first place from people’s confusion about the term “humanities.” Folks seem to get what history, philosophy, and literary criticism are, but humanities is harder to pin down. Just as certainly, calling our work “digital humanities” has made it more difficult for us to make it understandable and creditable in disciplinary context: the unified interdisciplinary message may be useful with funding agencies or the Dean of Arts and Sciences, but it may be less so with one’s departmental colleagues.

But what else is lost when we iron out our disciplinary differences? Our histories, for one.

Most of us working in digital humanities know well the dominant narrative of the pre-2000s history of digital humanities. It is a narrative that begins with the work of Father Busa in the 1950s and 1960s, proceeds through the foundation of the Association for Computers in the Humanities (ACH) in the 1970s and the establishment of the Humanist listserv in the 1980s, and culminates with foundation of the Text Encoding Initiative in the 1990s. Indeed, it is in the very context of the telling of this story that the term itself was born. “Digital Humanities” first came to widespread usage with the publication of A Companion to Digital Humanities, which proposed the term as a replacement for “humanities computing” in large part to broaden the tent beyond the literary disciplines that had grown up under that earlier term. The Companion contains important essays about digital work in history, anthropology, geography, and other disciplines. But it is Father Busa who provides the Foreword, and the introductory history told by Susan Hockey is told as the history of digital textual analysis. Indeed, even Will Thomas’s chapter on digital history is presented against the backdrop of this dominant narrative, depicting history in large part as having failed in its first attempts at digital work, as a discipline that was, in digital terms, passed by in the controversies over “cliometrics” in the 1960s and 1970s.

Let me be clear: I’m not slagging Susan, Will, or the other authors and editors of A Companion to Digital Humanities. Their volume went a long way toward consolidating the community of practice in which I’m now such a grateful participant. If it aimed to broaden the tent, it succeeded, and brought me with it. Nevertheless, as an historian, the story of Father Busa, of Humanist, and even of cliometrics is not my story. It is an important story. It is a story I do not refute. It is a story that should be told. But as a digital historian who isn’t much involved in textual analysis, it isn’t a story I can much identify with. Nor is it the only story we can tell.

My story, one I expect will resonate with many of my digital history colleagues, is a story that considers today’s rich landscape of digital history as a natural outgrowth of longstanding public and cultural historical activities rather than a belated inheritance of the quantitative history experiments of the 1960s and 1970s. It is a story that begins with people like Allan Nevins of the Columbia Oral History Office and Alan Lomax of the Library of Congress’s Archive of American Folk-Song, especially with the man on the street interviews Lomax coordinated in the aftermath of the Pearl Harbor attacks. From these oral history and folklife collecting movements of the 1940s and 1950s we can draw a relatively straight line to the public, social, cultural, and radical history movements of the 1960s and 1970s. These later movements directly spawned organizations like the American Social History Project / Center for Media and Learning at the CUNY Grad Center, which was founded in the 1980s—not coincidentally, I might add, by Herb Gutman who was the historical profession’s foremost critic of cliometrics—and the Roy Rosenzweig Center for History & New Media (my former institution), which was founded in the 1990s.

Importantly, these roots in oral history and folklife collecting are not simply institutional and personal. They are deeply methodological. Like today’s digital history, both the oral history and folklife collecting of the 1940s and 1950s and the public and radical history of the 1960s and 1970s were highly:

technological;
archival;
public;
collaborative;
political; and
networked.

Digital humanists often say that particular tools and languages are less important than mindset and method. Our tools are different, but digital historians learned their mindset and methods from the likes of Alan Lomax.

Thus, from my perspective, the digital humanities family tree has two main trunks, one literary and one historical, that developed largely independently into the 1990s and then came together in the late-1990s and early-2000s with the emergence of the World Wide Web. That said, I recognize and welcome the likely possibility that this is not the whole story. I would love to see this family tree expanded to describe three or more trunks (I’m looking at you anthropology and geography). We should continue to bring our different disciplinary histories out and then tie the various strains together.

In my view, it’s time for a reorientation, for another swing of the pendulum. Having made so much progress together in recent years, having explored so much of what we have in common, I believe the time has come to re-engage with what make us different. One potentially profitable step in this direction would be a continued exploration of our very different genealogies, both for the practical purposes of working within our departments and for the scholarly purposes of making the most of our methodological and intellectual inheritances. In the end, I believe an examination of our different disciplinary histories will advance even our interdisciplinary purposes: understanding what makes us distinctive will help us better see what in our practices may be of use to our colleagues in other disciplines and to see more clearly what they have to offer us.

[Image credits: Smithsonian Institution’s Cooper-Hewitt Museum, Library of Congress, Radical History Review]

Looks Like the Internet: Digital Humanities and Cultural Heritage Projects Succeed When They Look Like the Network

A rough transcript of my talk at the 2013 ACRL/NY Symposium last week. The symposium’s theme was “The Library as Knowledge Laboratory.” Many thanks to Anice Mills and the entire program committee for inviting me to such an engaging event.

When Bill Gates and Paul Allen set out in 1975 to put “a computer on every desk and in every home, all running Microsoft software” it was absurdly audacious. Not only were the two practically teenagers. Practically no one owned a computer. When Tim Berners-Lee called the protocols he proposed primarily for internal sharing of research documents among his laboratory colleagues at CERN “the World Wide Web,” it was equally audacious. Berners-Lee was just one of hundreds of physicists working in relative anonymity in the laboratory. His supervisor approved his proposal, allowing him six months to work on the idea with the brief handwritten comment, “vague, but exciting.”

In hindsight, we now know that both projects proved their audacious claims. More or less every desk and every home now has a computer, more or less all of them running some kind of Microsoft software. The World Wide Web is indeed a world-wide web. But what is it that these visionaries saw that their contemporaries didn’t? Both Gates and Allen and Berners-Lee saw the potential of distributed systems.

In stark contrast to the model of mainframe computing dominant at the time, Gates and Allen (and a few peers such as Steve Jobs and Steve Wozniak and other members of the Homebrew Computing Club) saw that computing would achieve its greatest reach if computing power were placed in the hands of users. They saw that the personal computer, by moving computing power from the center (the mainframe) to the nodes (the end user terminal) of the system, would kick-start a virtuous cycle of experimentation and innovation that would ultimately lead to everyone owning a computer.

Tim Berners-Lee saw (as indeed did his predecessors who built the Internet atop which the Web sits) that placing content creation, linking, indexing, and other application-specific functions at the fringes of the network and allowing the network simply to handle data transfers, would enable greater ease of information sharing, a flourishing of connections between and among users and their documents, and thus a free-flowing of creativity. This distributed system of Internet+Web was in stark contrast to the centralized, managed computer networks that dominated the 1980s and early 1990s, networks like Compuserve and Prodigy, which managed all content and functional applications from their central servers.

This design principle, called the “end-to-end principle,” states that most features of a network should be left to users to invent and implement, that the network 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.

In my experience digital cultural heritage and digital humanities projects function best when they adhere to this design principle, technically, structurally, and administratively. Digital cultural heritage and digital humanities projects work best when content is created and functional applications are designed, that is, when the real work is performed at the nodes and when the management functions of the system are limited to establishing communication protocols and keeping open the pathways along which work can take place, along which ideas, content, collections, and code can flow. That is, digital cultural heritage and digital humanities projects work best when they are structured like the Internet itself, the very network upon which they operate and thrive. The success of THATCamp in recent years demonstrates the truth of this proposition.

Begun in 2008 by my colleagues and I at the Roy Rosenzweig Center for History and New Media as an unfunded gathering of digitally-minded humanities scholars, students, librarians, museum professionals, and others, THATCamp has in five years grown to more than 100 events in 20 countries around the globe.

How did we do this? Well, we didn’t really do it at all. Shortly after the second THATCamp event in 2009, one of the attendees, Ben Brumfield, asked if he could reproduce the gathering and use the name with colleagues attending the Society of American Archivists meeting in Austin. Shortly after that, other attendees organized THATCamp Pacific Northwest and THATCamp Southern California. By early-2010 THATCamp seemed to be “going viral” and we worked with the Mellon Foundation to secure funding to help coordinate what was now something of a movement.

But that money wasn’t directed at funding individual THATCamps or organizing them from CHNM. Mellon funding for THATCamp paid for information, documentation, and a “coordinator,” Amanda French, who would be available to answer questions and make connections between THATCamp organizers. To this day, each THATCamp remains independently organized, planned, funded, and carried out. The functional application of THATCamp takes place completely at the nodes. All that’s provided centrally at CHNM are the protocols—the branding, the groundrules, the architecture, the governance, and some advice—by which these local applications can perform smoothly and connect to one another to form a broader THATCamp community.

As I see it, looking and acting like the Internet—adopting and adapting its network architecture to structure our own work—gives us the best chance of succeeding as digital humanists and librarians. What does this mean for the future? Well, I’m at once hopeful and fearful for the future.

On the side of fear, I see much of the thrust of new technology today to be pointing in the opposite direction, towards a re-aggregation of innovation from the nodes to the center, centers dominated by proprietary interests. This is best represented by the App Store, which answers first and foremost to the priorities of Apple, but also by “apps” themselves, which centralize users’ interactions within wall-gardens not dissimilar to those built by Compuserve and Prodigy in the pre-aeb era. The Facebook App is designed to keep you in Facebook. Cloud computing is a more complicated case, but it too removes much of the computing power that in the PC era used to be located at the nodes to a central “cloud.”

On the other hand, on the side of hope, are developments coming out of this very community, developments like the the Digital Public Library of America, which is structured very much according to the end-to-end principle. DPLA executive director, Dan Cohen, has described DPLA’s content aggregation model as ponds feeding lakes feeding an ocean.

As cultural heritage professionals, it is our duty to empower end users—or as I like to call them, “people.” Doing this means keeping our efforts, regardless of which direction the latest trends in mobile and cloud computing seem to point, looking like the Internet.

[Image credits: Flickr user didbygraham and Wikipedia.]

No Holds Barred

About six months ago, I was asked by the executive director of a prestigious but somewhat hidebound—I guess “venerable” would be the word—cultural heritage institution to join the next meeting of the board and provide an assessment of the organization’s digital programs. I was told not to pull any punches. This is what I said.

You don’t have a mobile strategy. This is by far your most pressing need. According to the Pew Internet and American Life Project, already more than 45% of Americans own a smartphone. That number rises to 66% among 18-29 year olds and 68% among families with incomes of more than $75,000. These are people on the go. You are in the travel and tourism business. If you are only reaching these people when they’re at their desks at work—as opposed to in their cars, on their lunch breaks, while they’re chasing the kids around on Saturday morning—you aren’t reaching them in a way that will translate into visits. This isn’t something for the future. Unfortunately, it’s something for two years ago.
You don’t have an integrated social strategy. I could critique your website, and of course it needs work. But a redesign is a relatively straightforward thing these days. The more important thing to realize is that you shouldn’t expect more than a fraction of your digital audience these to interact directly with your website. Rather, most potential audience members will want to interact with you and your content on their chosen turf, and these days that means Facebook, Twitter, Pinterest, Tumblr, and Wikipedia, depending on the demographic. You have to be ready to go all in with social media and dedicate at least as much thought and resources to your social media presence as to your web presence.
Your current set of researcher tools and resources aren’t well-matched to what we know about researcher needs and expectations. Ithaka Research, a respected think tank that studies higher education and the humanities, recently released a report entitled “Supporting the Changing Research Practices of Historians” (I’d encourage everyone here to give it a good read; it has a ton of recommendations for organizations like this one grappling with the changing information landscape as it relates to history). One of its key findings is that Google is now firmly established as researchers’ first (and sometimes last) stop for research. Lament all you want, but it means that if you want to serve researchers better, your best bet isn’t to make your own online catalog better but instead to make sure your stuff shows up in Google. As the Library of Congress’s Trevor Owens puts it: “the next time someone tells you that they want to make a ‘gateway’ a ‘portal’ or a ‘registry’ of some set of historical materials you can probably stop reading. It already exists and it’s Google.” This speaks to a more general point, which is related closely to my previous point. Researchers come to your collection with a set of digital research practices and tools that they want to use, first and foremost among these being Google. Increasingly, researchers are looking to interact with your collections outside of your website. They are looking to pull collection items into personal reference management tools like Zotero. More sophisticated digital researchers are looking for ways to dump large data sets into an Excel spreadsheet for manipulation, analysis, and presentation. The most sophisticated digital historians are looking for direct connections to your database through open APIs. The lesson here is that whatever resources you have to dedicate to online research collections should go towards minimizing the time people spend on your website. We tend to evaluate the success of our web pages with metrics like numbers of page views, time spent per page, and bounce rate. But when it comes to search the metrics are reversed: We don’t want people looking at lots of pages or spending a lot of time on our websites. We want our research infrastructure to be essentially invisible, or at least to be visible for only a very short period of time. What we really want with search is to allow researchers to get in and get out as quickly as possible with just what they were looking for.
You aren’t making good use of the organization’s most valuable—and I mean that in terms of its share of the annual budget—resource: its staff expertise. Few things are certain when it comes to Internet strategy. The Internet is an incredibly complex ecosystem, and it changes extremely quickly. What works for one project or organization may not work for another organization six months from now. However, one ironclad rule of the Internet is content drives traffic. Fresh, substantive content improves page rank, raises social media visibility, and brings people to the website. Your website should be changing and growing every day. The way to do that is to allow and encourage (even insist) that every staff member, down to the interns and docents, contribute something to the website. Everybody here should be blogging. Everyone should be experimenting. The web is the perfect platform for letting staff experiment: the web allows us to FAIL QUICKLY.
You aren’t going to make any money. Digital is not a revenue center, it’s an operating cost like the reading room, or the permanent galleries, or the education department. You shouldn’t expect increased revenues from a website redesign any more than you should from a new coat of paint for the front door. But just like the reading room, the education programs, and the fresh coat of paint, digital media is vital to the organization’s mission in the 21st century. There are grants for special programs and possibly for initial capital expenditures (start-up costs), but on the whole, cultural organizations should consider digital as a cost of doing business. This means reconfiguring existing resources to meet the digital challenge. One important thing to remember about digital work is that its costs are almost entirely human (these days the necessary technology, software, equipment, bandwidth is cheap and getting cheaper). That means organizations should be able to afford a healthy digital strategy if they begin thinking about digital work as an integral part of the duties of existing staff in the ways I described earlier. You probably need a head of digital programs and possibly a technical assistant, but beyond that, you can achieve great success through rethinking/retraining existing human resources.

I’m happy to say that, aside from a few chilly looks (mainly from the staff members, rather than the board members, in the room), my no-holds-barred advice was graciously received. Time will tell if it was well received.

The Hacker Way

On December 21, 2012, Blake Ross—the boy genius behind Firefox and currently Facebook’s Director of Product—posted this to his Facebook page:

Some friends and I built this new iPhone app over the last 12 days. Check it out and let us know what you think!

The new iPhone app was Facebook Poke. One of the friends was Mark Zuckerberg, Facebook’s founder and CEO. The story behind the app’s speedy development and Zuckerberg’s personal involvement holds lessons for the practice of digital humanities in colleges and universities.

Late last year, Facebook apparently entered negotiations with the developers of Snapchat, an app that lets users share pictures and messages that “self-destruct” shortly after opening. Feeding on user worries about Facebook’s privacy policies and use and retention of personal data, in little more than a matter of weeks, Snapchat had taken off among young people. By offering something Facebook didn’t—confidence that your sexts wouldn’t resurface in your job search—Snapchat exploded.

It is often said that Facebook doesn’t understand privacy. I disagree. Facebook understands privacy all too well, and it is willing to manipulate its users’ privacy tolerances for maximum gain. Facebook knows that every privacy setting is its own niche market, and if its privacy settings are complicated, it’s because the tolerances of its users are so varied. Facebook recognized that Snapchat had filled an unmet need in the privacy marketplace, and tried first to buy it. When that failed, it moved to fill the niche itself.

Crucially for our story, Facebook’s negotiations with Snapchat seem to have broken down just weeks before a scheduled holiday moratorium for submissions to Apple’s iTunes App Store. If Facebook wanted to compete over the holiday break (prime time for hooking up, on social media and otherwise) in the niche opened up by Snapchat, it had to move quickly. If Facebook couldn’t buy Snapchat, it had to build it. Less than two weeks later, Facebook Poke hit the iTunes App Store.

Facebook Poke quickly rose to the top of the app rankings, but has since fallen off dramatically in popularity. Snapchat remains among iTunes’ top 25 free apps. Snapchat continues adding users and has recently closed a substantial round of venture capital funding. To me Snapchat’s success in the face of such firepower suggests that Facebook’s users are becoming savvier players in the privacy marketplace. Surely there are lessons in this for those of us involved in digital asset management.

Yet there is another lesson digital humanists and digital librarians should draw from the Poke story. It is a lesson that depends very little on the ultimate outcome of the Poke/Snapchat horse race. It is a lesson about digital labor.

Mark Zuckerberg is CEO of one of the largest and most successful companies in the world. It would not be illegitimate if he decided to spend his time delivering keynote speeches to shareholders and entertaining politicians in Davos. Instead, Zuckerberg spent the weeks between Thanksgiving and Christmas writing code. Zuckerberg identified the Poke app as a strategic necessity for the service he created, and he was not too proud to roll up his sleeves and help build it. Zuckerberg explained the management philosophy behind his “do it yourself” impulse in the letter he wrote to shareholders prior to Facebook’s IPO. In a section of the letter entitled “The Hacker Way,” Zuckerberg wrote:

The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it – often in the face of people who say it’s impossible or are content with the status quo….

Hacking is also an inherently hands-on and active discipline. Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works. There’s a hacker mantra that you’ll hear a lot around Facebook offices: “Code wins arguments.”

Hacker culture is also extremely open and meritocratic. Hackers believe that the best idea and implementation should always win – not the person who is best at lobbying for an idea or the person who manages the most people….

To make sure all our engineers share this approach, we require all new engineers – even managers whose primary job will not be to write code – to go through a program called Bootcamp where they learn our codebase, our tools and our approach. There are a lot of folks in the industry who manage engineers and don’t want to code themselves, but the type of hands-on people we’re looking for are willing and able to go through Bootcamp.

Now, listeners to Digital Campus will know that I am no fan of Facebook, which I abandoned years ago, and I’m not so naive as to swallow corporate boilerplate hook, line, and sinker. Nevertheless, it seems to me that in this case Zuckerberg was speaking from the heart and the not the wallet. As Business Insider’s Henry Blodget pointed out in the days of Facebook’s share price freefall immediately following its IPO, investors should have read Zuckerberg’s letter as a warning: he really believes this stuff. In the end, however, whether it’s heartfelt or not, or whether it actually reflects the reality of how Facebook operates, I share my colleague Audrey Watters’ sentiment that “as someone who thinks a lot about the necessity for more fearlessness, openness, speed, flexibility and real social value in education (technology) — and wow, I can’t believe I’m typing this — I find this part of Zuckerberg’s letter quite a compelling vision for shaking up a number of institutions (and not just “old media” or Wall Street).”

There is a widely held belief in the academy that the labor of those who think and talk is more valuable than the labor of those who build and do. Professorial contributions to knowledge are considered original research while librarians and educational technologists’ contributions to these endeavors are called service. These are not merely imagined prejudices. They are manifest in human resource classifications and in the terms of contracts that provide tenure to one group and, often, at will employment to the other.

Digital humanities is increasingly in the public eye. The New York Times, the Los Angeles Times, and the Economist all have published feature articles on the subject recently. Some of this coverage has been positive, some of it modestly skeptical, but almost all of it has focused on the kinds of research questions digital humanities can (or maybe cannot) answer. How digital media and methods have changed humanities knowledge is an important question. But practicing digital humanists understand that an equally important aspect of the digital shift is the extent to which digital media and methods have changed humanities work and the traditional labor and power structures of the university. Perhaps most important has been the calling into question of the traditional hierarchy of academic labor which placed librarians “in service” to scholars. Time and again, digital humanities projects have succeeded by flattening distinctions and divisions between faculty, librarians, technicians, managers, and students. Time and again, they have failed by maintaining these divisions, by honoring traditional academic labor hierarchies rather than practicing something like the hacker way.

Blowing up the inherited management structures of the university isn’t an easy business. Even projects that understand and appreciate the tensions between these structures and the hacker way find it difficult to accommodate them. A good example of an attempt at such an accommodation has been the “community source” model of software development advanced by some in the academic technology field. Community source’s successes and failures, and the reasons for them, illustrate just how important it is to make room for the hacker way in digital humanities and academic technology projects.

As Brad Wheeler wrote in EDUCAUSE Review in 2007, a community source project is distinguished from more generic open source models by the fact that “many of the investments of developers’ time, design, and project governance come from institutional contributions by colleges, universities, and some commercial firms rather than from individuals.” Funders of open source software in the academic and cultural heritage fields have often preferred the community source model assuming that, because of high level institutional commitments, the projects it generates will be more sustainable than projects that rely mainly on volunteer developers. In these community source projects, foundations and government funding agencies put up major start-up funding on the condition that recipients commit regular staff time—”FTEs”—to work on the project alongside grant funded staff.

The community source model has proven effective in many cases. Among its success stories are Sakai, an open source learning management system, and Kuali, an open source platform for university administration. Just as often, however, community source projects have failed. As I argued in a grant proposal to the Library of Congress for CHNM’s Omeka + Neatline collaboration with UVa’s Scholars’ Lab, community source projects have usually failed in one of two ways: either they become mired in meetings and disagreements between partner institutions and never really get off the ground in the first place, or they stall after the original source of foundation or government funding runs out. In both cases, community source failures lie in the failure to win the “hearts and minds” of the developers working on the project, in the failure to flatten traditional hierarchies of academic labor, in the failure to do it “the hacker way.”

In the first case—projects that never really get off the ground—developers aren’t engaged early enough in the process. Because they rely on administrative commitments of human resources, conversations about community source projects must begin with administrators rather than developers. These collaborations are born out of meetings between administrators located at institutions that are often geographically distant and culturally very different. The conversations that result can frequently end in disagreement. But even where consensus is reached, it can be a fragile basis for collaboration. We often tend to think of collaboration as shared decision making. But as I have said in this space before, shared work and shared accomplishment are more important. As Zuckerberg has it, digital projects are “inherently hands-on and active”; that “instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works”; that “the best idea and implementation should always win—not the person who is best at lobbying for an idea or the person who manages the most people.” That is, the most successful digital work occurs at the level of work, not at the level of discussion, and for this reason hierarchies must be flattened. Everyone has to participate in the building.

In the second case—projects that stall after funding runs out—decisions are made for developers (about platforms, programming languages, communication channels, deadlines) early on in the planning process that may deeply affect their work at the level of code sometimes several months down the road. These decisions can stifle developer creativity or make their work unnecessarily difficult, both of which can lead to developer disinterest. Yet experience both inside and outside of the academy shows us that what sustains an open source project after funding runs out is the personal interest and commitment of developers. In the absence of additional funding, the only thing that will get bugs fixed and forum posts answered are committed developers. Developer interest is often a project’s best sustainability strategy. As Zuckerberg says, “hackers believe that something can always be better, and that nothing is ever complete.” But they have to want to do so.

When decisions are made for developers (and other “doers” on digital humanities and academic technology projects such as librarians, educational technologists, outreach coordinators, and project managers), they don’t. When they are put in a position of “service,” they don’t. When traditional hierarchies of academic labor are grafted onto digital humanities and academic technology projects that owe their success as much to the culture of the digital age as they do to the culture of the humanities, they don’t.

Facebook understands that the hacker way works best in the digital age. Successful digital humanists and academic technologists do too.

[This post is based on notes for a talk I was scheduled to deliver at a NERCOMP event in Amherst, Massachusetts on Monday, February 11, 2013. The title of that talk was intended to be “‘Not My Job’: Digital Humanities and the Unhelpful Hierarchies of Academic Labor.” Unfortunately, the great Blizzard of 2013 kept me away. Thankfully, I have this blog, so all is not lost.]

[Image credit: Thomas Hawk]

Ancient Religion, Modern Technology: Takeaways

[Last month, I posted notes from my keynote at Brown University’s Ancient Religion, Modern Technology workshop. I was also fortunate to be invited to offer some concluding observations to the excellent group assembled there. Here they are, my very rough notes.]

1) The community of scholars interested in ancient religion has done some extraordinary digital work with extraordinarily little money. The work of Michael Penn, David Michelson, and other members of “Syraic Mafia” (as that small group of scholars working on ancient Syriac manuscripts was dubbed during the workshop) through projects such as the Syriac Reference Portal is a particularly striking example of this.

2) I was struck by the extent to which this community has identified real problems/questions and how incredibly successful it has been in answering them. It seems to me that integrity and availability of the texts is a much bigger problem in classics than in more modern history. But it is also a problem that lends itself to digital solutions: edge matching, name authority, calendar disambiguation, and handwriting recognition are clearly defined problems with clearly identifiable (if difficult) solutions. These are what we might call “instrumental” uses of technology, and they seem less current among the broader community of digital humanists. I think that broader community could benefit from a renewed focus on these kind of problems in our own domains, but I think this community could stand a broader discussion about the possibly “squishier” things that occupy much of the rest of digital humanities: new modes of scholarly communication, digital pedagogy, open access, public humanities and social media.

3) Digital humanities has too often gone searching for the elusive “one” database/tool/standard. To a large extent, this search has been driven by our funders, who are reluctant to fund multiple projects with the same ends, but we have been complicit as well. I caution this group to avoid this trap. The notion of the “one” doesn’t represent the way either technology or the humanities proceed. Technologies and ideas exist in dialog with one another. Put crudely, they compete in the marketplace. There isn’t one smartphone, and there isn’t one book about Alexander the Great, and we wouldn’t want there to be. In the same way, I don’t think there has to be or even should be one database/tool/standard for the things we want to accomplish. I don’t think we or our funders should be so concerned about duplication of effort or projects that “do the same thing.” We should strive for interoperability in our products, but we shouldn’t wish for just one. I understand where the impulse comes from. It is messy and unsatisfying to have overlapping and competing databases, standards, and tools. But what are the humanities if not messy and, ultimately, unsatisfying? These are the things that spur us on to new research.

Nobody cares about the library: How digital technology makes the library invisible (and visible) to scholars

There is a scene from the first season of the television spy drama, Chuck, that takes place in a library. In the scene, our hero and unlikely spy, Chuck, has returned to his alma mater, Stanford, to find a book his former roommate, Bryce, has hidden in the stacks as a clue. All Chuck has to go on is a call number scribbled on a scrap of paper.

When he arrives in the stacks, he finds the book is missing and assumes the bad guys have beat him to it. Suddenly, however, Chuck remembers back to his undergraduate days of playing tag in the stacks with Bryce with plastic dart guns. Bryce had lost his weapon and Chuck had cornered him. Just then, Bryce reached beneath a shelf where he had hidden an extra gun, and finished Chuck off. Remembering this scene, Chuck reaches beneath the shelf where the book should have been shelved and finds that this time around Bryce has stashed a computer disk.

I like this clip because it illustrates how I think most people—scholars, students, geeks like Chuck—use the library. I don’t mean as the setting for covert intelligence operations or even undergraduate dart gun games. Rather, I think it shows that patrons take what the library offers and then use those offerings in ways librarians never intended. Chuck and his team (and the bad guys) enter the library thinking they are looking for a book with a given call number only to realize that Bryce has repurposed the Library of Congress Classification system to hide his disk. It reinforces the point when, at the end of the scene, the writers play a joke at the expense of a hapless librarian, who, while the action is unfolding, is trying to nail Chuck for some unpaid late fees. When the librarian catches up with Chuck, and Chuck’s partner Sarah shouts “Run!” she is not, as the librarian thinks, worried about late fees but about the bad guys with guns standing behind him. Chuck and his friends don’t care about the library. They use the library’s resources and tools in their own ways, to their own ends, and the concerns of the librarians are a distant second to the concerns that really motivate them.

In some ways, this disconnect between librarians (and their needs, ways of working, and ways of thinking) and patrons (and their needs and ways of working) is only exacerbated by digital technology. In the age of Google Books, JSTOR, Wikipedia, and ever expanding digital archives, librarians may rightly worry about becoming invisible to scholars, students, and other patrons—that “nobody cares about the library.” Indeed, many faculty and students may wonder just what goes on in that big building across the quad. Digital technology has reconfigured the relationship between librarians and researchers. In many cases, this relationship has grown more distant, causing considerable consternation about the future of libraries. Yet, while it is certainly true that digital technology has made libraries and librarians invisible to scholars in some ways, it is also true, that in some areas, digital technology has made librarians increasingly visible, increasingly important.

To try to understand the new invisibility/visibility of the library in the digital age let’s consider a few examples on both sides.

The invisible library

Does it matter that Chuck couldn’t care less about call numbers and late fees or about controlled vocabularies, metadata schemas, circulation policies, or theories collections stewardship? I’m here to argue that it doesn’t. Don’t get me wrong. I’m not arguing that these things don’t matter or that the library should be anything but central to the university experience. But to play that central role doesn’t mean the library has to be uppermost in everyone’s mind. In the digital age, in most cases, the library is doing its job best when it is invisible to its patrons.

What do I mean by that? Let me offer three instances where the library should strive for invisibility, three examples of “good” invisibility:

Search: We tend to evaluate the success of our web pages with metrics like numbers of page views, time spent per page, and bounce rate. But with search the metrics are reversed: We don’t want people looking at lots of pages or spending a lot of time on our websites. We want the library web infrastructure to be essentially invisible, or at least to be visible for only a very short period of time. What we really want with search is to allow patrons to get in and get out as quickly as possible with just what they were looking for.

APIs and 3rd party mashups: In fact, we may not want people visiting library websites at all. What would be even better would be to provide direct computational access to collections databases so people could take the data directly and use it in their own applications elsewhere. Providing rich APIs (Application Programming Interfaces) would make the library even more invisible. People wouldn’t even come to our websites to access content, but they would get from us what they need where they need it.

Social media: Another way in which we may want to discourage people from coming to library websites is by actively placing content on other websites. To the extent that a small or medium-sized library wants to reach general audiences, it has a better chance of doing so in places where that audience already is. Flickr Commons is one good example of this third brand of invisibility. Commentors on Flickr Commons may never travel back to the originating library’s website, but they may have had a richer interaction with that library’s content because of it.

The visible library

The experience of the digital humanities shows that the digital can also bring scholars into ever closer and more substantive collaboration with librarians. It is no accident that many if not most successful digital humanities centers are based in univeristy libraries. Much of digital humanities is database driven, but an empty database is a useless database. Librarians have the stuff to fill digital humanists’ databases and the expertise to do so intelligently.

Those library-based digital humanities centers tend to skew towards larger universities. How can librarians at medium-sized or even small universities library help the digital humanities? Our friend Wally Grotophorst, Associate University Librarian for Digital Programs and Systems at Mason, provides some answers in his brief but idea-rich post, What Happens To The Mid-Major Library?. I’ll point to just three of Wally’s suggestions:

Focus on special collections, that is anything people can’t get from shared sources like Google Books, JSTOR, LexisNexis, HathiTrust. Not only do special collections differentiate you from other institutions online, they provide unique opportunities for researchers on campus.

Start supporting data-driven research in addition to the bibliographic-driven kind that has been the traditional bread and butter of libraries. Here I’d suggest tools and training for database creation, social network analysis, and simple text mining.

Start supporting new modes of scholarly communication—financially, technically, and institutionally. Financial support for open access publishing of the sort prescribed by the Compact for Open-Access Publishing Equity is one ready model. Hosting, supporting, and publicizing scholarly and student blogs as an alternative or supplement to existing learning management systems (e.g. Blackboard) is another. University Library/University Press collaboration, like the University of Michigan’s MPublishing reorganization, is a third.

Conclusion

In an information landscape increasingly dominated by networked resources, both sides of the librarian-scholar/student relationship must come to terms with a new reality that is in some ways more distant and in others closer than ever before. Librarians must learn to accept invisibility where digital realities demand it. Scholars must come to understand the centrality of library expertise and accept librarians as equal partners as more and more scholarship becomes born digital and the digital humanities goes from being a fringe sub-discipline to a mainstream pursuit. Librarians in turn must expand those services like special collections, support for data-driven research, and access to new modes of publication that play to their strengths and will best serve scholars. We all have to find new ways, better ways to work together.

So, where does that leave Chuck? Despite not caring about our work, Chuck actually remembers the library fondly as a place of play. Now maybe we don’t want people playing dart guns in the stacks. But applied correctly, digital technology allows our users and our staff to play, to be creative, and in their own way to make the most of the library’s rich resources.

Maybe the Chucks of the world do care about the library after all.

[This post is based on a talk I delivered at American University Library’s Digital Futures Forum. Thanks to @bill_mayer for his kind invitation. In memory of my dear friend Bob Griffith, who did too much to come and hear this lousy talk.]

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 happens at a specific time and place in the real world. It’s something you can buy a ticket for—or follow on Twitter.

Generative. Something new gets created. The event doesn’t have to produce a series of luminous photo essays; the point is simply that contributors aren’t operating in playback mode. They’re thinking on their feet, collaborating on their feet, creating on their feet. There’s risk involved! And that’s one of the most compelling reasons to follow along.

Publishable. The result of all that generation ought, ideally, to be something you can publish on the web, something that people can happily discover two weeks or two years after the event is over.

Performative. The event has an audience—either live or online, and ideally both. The event’s structure and products are carefully considered and well-crafted. I love the BarCamp model; this is not a BarCamp.

Serial. It doesn’t just happen once, and it doesn’t just happen once a year. Ideally it happenn… what? Once a month? It’s a pattern: you focus sharply on the event, but then the media that you produce flares out onto the web to grow your audience 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.