PART III ][ Chapter 13

The Digital Humanities and Its Users

CHARLIE EDWARDS

In her poignant and piercing intervention, “Eternal September of the Digital Humanities,” Bethany Nowviskie reflects on how “our daily voicing of the practice of digital humanities (and not just on special days—every day) helps to shape and delimit and advance it.” She continues, “That voicing operates wholeheartedly to welcome people and fresh ideas in, if sometimes to press uncomfortably (one intends, salutarily) against the inevitable changes they will bring.” Recently, though, the voices of digital humanities (DH) have been discordant, talking of pioneers and parvenus, makers and tweeters, workers and lurkers. Others—notoriously—have figured themselves as the out-group to DH’s in-group, the dull ground against which the “stars” of DH shine (Pannapacker). Here, though, we will focus on what I hope may be a more unifying image: the user. I will try to frame DH not as a field defined by its borders, and the skills required to breach those borders, but instead—in an analogy that should appeal to the community’s tool builders—as a system with users. This can help us to make some important moves. It allows us to shift the debate from charged hermeneutics (“Are DHers inclusive?”) to practical heuristics (“Which features of DH as a system enhance or undermine access and participation?”). It compels us to acknowledge that DH, as a system, has serious usability issues that affect both new and experienced users. And it suggests how these problems, contingent as they are on the system’s current design, might be addressed.

Usability has typically been defined and evaluated in terms of a system’s ease of learning, ease of use, efficiency, and user satisfaction.¹ How, though, can this be relevant to an academic field? If DH is a system, any academic discipline is a system. Should entry to a discipline, use of its theories and methods, be “easy”? William Pannapacker finds DH inaccessible: “It’s perceptible in the universe of Twitter: We read it, but we do not participate. It’s the cool-kids’ table.” But are the barriers to entry that “outsiders” perceive really usability issues, or simply points on DH’s inevitable learning curve? As one DHer tweets in response, acerbically, “Wonder if DH seems exclusivist to some because the gateway to full participation can include real, definable skills.”² Surely the painstaking acquisition of specialist knowledge is an essential aspect of professionalization in any field. Yet surely also a field that marks its difference as the “digital” owes some explanation not just of what can be accomplished digitally but also of how those digital moves are to be made. Humanists are summoned by DHers to “build” (Ramsay “On Building”), enjoined by others to “be online or be irrelevant” (Parry), implicitly deprecated in the title of Patricia Cohen’s New York Times coverage, “Humanities 2.0.” But, as we will find, the gateways to participation, even the paths to the gateways, are obscure.

There are other ways, however, in which the concept of usability can be seen as problematic, both in itself and in its application here. As a business practice, usability and user experience (UX) design claims success in directing the user to a specific end: adoption of a site, retention on the site to view ads, seamless completion of commercial transactions. What implications might this have for DH? Pannapacker likens the atmospherics of DH to the “alienating” culture of Big Theory in the 1980s and 1990s, so I invoke one of the biggest theorists of the period perhaps inadvisedly. But Derrida has reminded us, “Metaphor is never innocent. It orients research and fixes results” (17). And this particular metaphor could involve some risk. Does it (as does, arguably, the entire project of usability) subscribe to a naive determinism that draws a straight line between wireframe design and desired outcome? Does it rest on an undertheorized, instrumental conception of technology that seeks only to achieve a smooth, seductive fit of tool to hand? After all, the usability.gov home page ventriloquizes the user: “Please don’t make me think!” This summons in turn a nightmare vision: the user as consumer, passive and unreflective. This figure, with the crass n00b,³ haunts texts such as “Eternal September” and the comments thereon. By corollary, does viewing DH as a system render DH as “applied” (versus “pure”) humanities, submitting to the service orientation that Nowviskie in her post explicitly resists? Does it, in other words, offer up DH as a prosthesis for the humanities to wield?

To me, these questions are not mere artifacts of the metaphor but deeply relevant as DH moves forward. Pannapacker’s post claims to mark the moment of the field’s transformation from “the next big thing” to simply “The Thing”; his headline posits DH as “triumphant.” While common sense argues skepticism here, nonetheless DH does seem to have reached a pivot point in its development. “Eternal September” references the moment in 1993 when Usenet, a discussion system favored by early adopters, was inundated by naive users introduced by the mainstream service provider AOL. But we are also given a glimpse of the user experience: “about thirty days in, newbies had either acclimatized to Usenet or they had dropped away.” Until recently even DH’s tool builders have paid scant attention to usability, as Matthew Kirschenbaum notes in his discussion of the topic, “So the Colors Cover the Wires.” Now, though, DH does seem to be changing in response to its new users, as we will see. But in offering alternatives for users beyond compliance and abandonment, how will the role of those users be conceived? What forms of participation will be enabled? It is not the user as such but the user as consumer that renders the builder as service provider, proffering DH as tool to hand. Yet DH’s direction in this regard is far from clear.

Traditionally, the most common methods of usability assessment are formal testing—in which selected representative users are observed interacting with the system to perform specified tasks, sometimes in a lab environment—and heuristic evaluation, where an expert reviews the system’s interface against a set of best practices. This essay, I freely admit, does neither. Instead, it traces a history of the user in DH, before turning to examine DH as system. More recent thinking on usability shifts the emphasis from system to user and her lived experience of the system in its context of use (McCarthy and Wright, 5).⁴ So as the essay explores the online landscape—the “user interface,” as it were—of the digital humanities in its current design, it focuses on reading traces of users’ situated experiences in blog posts, in comment threads, and on Twitter, then lays out this user’s informal analysis of the results. I will propose that DH and its possible futures are likely to be shaped, delimited, or advanced by how DHers choose to design and build their conceptions of the user, and the extent to which all users can participate in that process.

DH and Its Users; or, Missing Masses?

A UX designer typically begins by asking two basic questions: who is to use the system, and for what ends? It need hardly be said that regarding DH these are contested points; for evidence, we can simply look at Pannapacker’s blog post, the multiple definitions of DH generated every year by the University of Alberta’s international Day of Digital Humanities event, and indeed this collection itself. But the responses to these questions have also changed over time. As Patrik Svensson describes in “Humanities Computing as Digital Humanities,” the field in its initial expression (humanities computing) had very different “epistemic commitments” from those articulated under the rubric of “digital humanities,” and the renaming is far from unproblematic. Indeed DH can be seen, perhaps, as a legacy application that at its core was not designed for widespread use and that struggles to integrate more recent modules that have this as their goal.

The origin story of DH tells of a stand-alone tool developed initially for a single user, Roberto Busa—his Index Thomisticus, a concordance of the works of St. Thomas Aquinas (Hockey). Looking at DH tools literally rather than metaphorically, they have often been designed by researchers for researchers (often themselves). As even prominent tool builders acknowledge, the uptake for many DH tools has remained small, the users almost coextensive with the makers, even where the goal of the development team has been to reach a broader audience. Multiple explanations for this have been offered from within the field. The lack of enthusiasm among “traditional” humanists for computer-assisted textual analysis, for example, is often explained by a humanistic tendency to associate computation with empiricism, positivism, and other such suspect enterprises (Mueller; Ramsay, “In Praise of Pattern”). John Bradley, however, points to the system design, suggesting “computing humanists” and their “colleagues down the hall” have different mental models of the role of computing in literary study. The latter are, even now, operating under the “conduit model” in which the computer is simply a text delivery mechanism. Computing humanists, meanwhile, have built tools based on their own models, models that do not reflect how “traditional” literary scholars actually do their work. Whatever the cause, the effect seems clear. Martin Mueller conducted a distant reading of the titles of monographs and articles in scholarly journals, his aim being to measure mainstream interest in what he terms “literary informatics.” He concludes that it remains a niche activity, of interest only to those who participate in it. It has had, he says—and he is deeply involved in such work—“virtually no impact on major disciplinary trends” (305).

Widening the lens to DH more generally, Oya Rieger’s newer research supports Mueller’s conclusions. In her study of faculty at Cornell’s Society for the Humanities, Rieger asked about their familiarity with the digital humanities. The results: only four of forty-five participants were actually engaged in what they regarded as DH work; four more had an understanding of it; nineteen had heard the phrase but couldn’t explain its meaning; and the rest were entirely unfamiliar with the term. She found, moreover, that the scholarly practices of the participants were unaltered, aside from the adoption of generic tools such as search engines—technology as conduit, to use Bradley’s term. Meanwhile, “many tools and techniques that are being associated with sophisticated digital practices, such as data mining or visualization, remain accessible and relevant to only a handful of scholars.” Of course, it is entirely possible that with recent coverage of DH in venues such as the Chronicle of Higher Education and the New York Times⁵—and the propulsive rhetoric of that coverage—the figures Rieger quotes may now have changed. But based on the history of the field one might have real skepticism about DH’s potential to attract, let alone retain, the deluge of new users that “Eternal September” images. On this view, in fact, Eternal September may be moot.

Recently, however, some DHers have adopted a more inclusive mode of tool building, as Tom Scheinfeldt describes. “At CHNM,” he writes, “we judge our tools by one key metric above all others: use. Successful tools are tools that are used …any open source software project’s goal should be use by as many of its potential users as possible” (“Lessons from One Week | One Tool”). This, he explains, brings many benefits to the project:

CHNM’s tools, such as Zotero, Omeka, and the newly announced Scripto, reflect this orientation: they are polished and professional, with attractive interfaces and a robust user documentation and support infrastructure.

This approach is very different from that of earlier DH projects, which focused on the system’s raw functionality rather than the user’s experience. But it is a persuasive one, not least to funding agencies. Instead of, or in addition to, developing bespoke tools designed to serve a small group of researchers at single institutions via discrete projects, DHers may increasingly develop products aimed at large numbers of users across institutions and outside the academy. And with the attention to usability and outreach that Scheinfeldt describes, such initiatives may very well attract new users not just to the tools themselves but also to DH in general. But this trajectory raises two critical questions regarding the newcomers: First, can DH accommodate them, and if so, how? And second, how do they relate to the field? We will turn to the first issue shortly. As to the second, we should acknowledge that even as funding for DH efforts is being justified by recourse to usage, it is far from clear how DH’s new users will map onto the field. Do they even have a place within it?

Rieger’s study of faculty in the humanities begins by commenting on the “richness and diversity” of existing discussions of DH but notes that “what seem to be missing are accounts from a wide range of scholars who are not characterized as ‘doing digital humanities’”; this lack, indeed, is the driver for her work. Not coincidentally, however, accounts of them are also missing. Thanks to its name, those in the field struggle to name those conceived as outside it: are they “traditional,” or “analog,” humanists? And if we examine the emergent folksonomy of DH, it is difficult to find a term that those others might identify with. Here, for instance, is how Matthew Jockers of Stanford Literary Lab parses the field: “Group ‘A’ is composed of researchers who study digital objects; Group ‘B’ is composed of researchers who utilize digital tools to study objects (digital or otherwise).” Group B accommodates use, it is true, but Jockers’s emphasis is on research; it does not explicitly account for other modes, such as work that focuses on pedagogy. We should note that his post is occasioned by an encounter with the other, a colleague who “asked in all earnestness, ‘what do I need to do to break into this field of Digital Humanities?’” This is a reminder that the metaphor of the lab, ubiquitous in DH, has its own associations: experimentation and collaboration are there, to be sure, but it also conjures a bright pristine working environment sealed to all but the eminently qualified. To generalize, most humanists are not in the habit of breaking into laboratories.

It is understandable, perhaps, but surely not inevitable that “traditional” humanists are defined by exclusion. In fact, as Svensson notes, it is rather strange: “if the methodology and tools are central to the enterprise it seems counter-intuitive to disassociate yourself from many of the potential users (and co-creators) of the tools” (49). The effect is that these users become visible only if we trace the outlines of the negative space created by DH’s self-definitions. For instance, the provocation Steve Ramsay issued at the 2011 Modern Language Association (MLA) Convention, “Who’s In and Who’s Out,” promotes the “builder” or “maker” as paradigmatic DHer. But even though he insists he is “willing to entertain highly expansive definitions of what it means to build something,” it is doubtful that Ramsay intends the term to accommodate end users, and the humanities as such only appear as a target of “methodologization.”

In these examples “traditional” humanists appear, if at all, in peripheral vision, like Bradley’s “colleague down the hall.” Where are their points of entry? How can they have agency, value? They are shadows. In a comment on Steve Ramsay’s “On Building,” Alan Liu teases out the almost buried metaphor: in the world of construction, “there is a whole ecology of positions and roles necessary for building—including also the client, urban planners, politicians, architectural critics, professors of engineering, etc.” He worries that we risk “builder essentialism” in promoting the work of the coder over the “multiplicity of builder roles” necessarily involved. “It takes,” he says, “a village or, as Bruno Latour puts it, an actor-network.” Latour’s famous essay “Where Are the Missing Masses? The Sociology of a Few Mundane Artifacts” accuses his fellow sociologists of discriminating between humans and nonhumans, the missing masses: “I do not hold this bias (this one at least) and see only actors—some human, some nonhuman, some skilled, some unskilled—that exchange their properties.” These actors are bound together in a network, or, more accurately, the network is produced in their interactions. Is it fanciful to suggest that DHers risk reversing that bias? That in its focus on delimiting the field based on qualifications, DH can be seen as privileging not just the coder over less technical contributors but also that which is built over those who will use it? Are users, and especially newbie users, the missing masses of DH?

Two of DH’s most recent and most successful projects, in fact, are specifically aimed at engaging the unskilled. Transcribe Bentham, based at University College London, has trained amateurs of all stripes to serve as paleographers transcribing the papers of philosopher Jeremy Bentham. And DHAnswers, the Q&A forum recently developed by the Association for Computers and the Humanities and ProfHacker, enables its members to pose questions to the DH community on topics ranging from “What is DH?” to “Lightweight data management/storage/transformation for use with web services.” The importance of end users here is obvious—they are essential to the functioning of both projects. Viewed as an actor-network, however, we can see that DHAnswers should not only be regarded as a service provided by expert practitioners for those in need of help. It is also a place of exchange in which those asking the questions act as strong levers inducing the community to document its knowledge.

Both of these projects provide defined pathways for end-user contributions. But what Scheinfeldt describes in “Lessons from One Week | One Tool”—the open source software development model—goes further. He shows not only how the user qua user actually supports the project but also how the user community generates a special type of user, the volunteer developer who is key to the project’s success: “They find and fix bugs. They provide end user support. They write documentation. They add new features and functionality. They provide vision and critical assessment.” At least in theory, then, open source development offers a paradigm for DH as a whole that can incorporate the full range of its users, regardless of technical skill set. Such a model imagines each user as full member of the community, whether as end user or developer-user, where the end user is on a continuum with the developer-user, and that continuum acts as an optional pathway to more technical forms of engagement. At its best, this represents more than the hand-waving “fuzziness” about “community and comity, collaboration and cooperation” that Ramsay deplores in “Who’s In and Who’s Out,” but rather the lived experience of people working in the field. We can see this when Patrick Murray-John describes a “mini-collaboration” on Twitter in which he (a programmer) and Mark Sample (a confessed nonprogrammer) debugged and tested a widget he had built, concluding that this is how he thinks DH will “work and develop”: “collaborations—on whatever scale—between humanists at different positions on the ‘I am a coder’–‘I ain’t a coder’ spectrum.” And scholar-builder Stéfan Sinclair tweets,⁶ “I would add to @sramsay’s post that there can be a fine (and oftentimes porous) line between using and building.” By contrast, one could suggest that part of the shock that the recent unanticipated release of Google’s text analysis tool, the Ngram Viewer, administered to the DH community was its abrupt demotion of skilled makers in the text analysis domain to read-only end users of the tool’s limited affordances. They became, in other words, consumers. The multivalent user must be actively enabled and can be intentionally or unintentionally disabled by the system design.

Google may have brought text analysis to the masses but does not engage with them in this work. The site does not invite users to “contact us” or provide feedback, let alone participate in its making. Interfaces can be seen as performing a protective, even prophylactic, function; on this view, limiting the user’s options minimizes the load the system must bear. But the user is not merely mass to be supported, as Transcribe Bentham and DHAnswers demonstrate. If DHers feel the system’s new users as an inertial drag, it may be because the design itself is exerting resistance.

DH as User Experience

Until recently, however, DH as a system has grown by accretion rather than design. Much as they build tools, standards, and methods from scratch, DHers also adopt and adapt things that come to hand—Twitter is one example—and incorporate them into their workflow. The design of DH is to some extent “found” design. But these acts of finding and appropriating nonetheless should be regarded as design choices that have consequences, some beneficial for all users, others less so. In his “Stuff Digital Humanists Like,” Tom Scheinfeldt makes what he acknowledges is a strong claim: that the stuff digital humanists like (Twitter, PHP, and so on) “work better” than their alternatives. In what follows I will borrow Scheinfeldt’s method, examining three key features of DH and attempting to evaluate how they “work” for their users at a tactical level. But we will also test another of his arguments—one that, like this essay, proposes an analogy. “Digital humanities takes more than tools from the Internet,” he writes (“Stuff Digital Humanists Like”). “It works like the Internet. It takes its values from the Internet.” These values are built into the very architecture of the web, which, he explains, emphasizes the nodes rather than the network as sources of innovation, assuming “that the network should be dumb and the terminals should be smart.” And just as the Internet functions by trusting those nodes to distribute the information sent to them, so does DH: “we 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” (ibid.).

We will see, though, that the vision Scheinfeldt describes is as yet incompletely realized in DH’s system design. Rather it is unevenly distributed, and the user finds herself falling into the gaps between that vision and her everyday experience of the field. This is not because DHers do not subscribe to the values that Scheinfeldt articulates. On the contrary, many in the community are working hard to improve DH’s outreach and infrastructure. But Lisa Spiro’s essay in this collection has as its premise the observation that DH has not, to date, cohered as a community around a set of shared values. And the implementation of values in system design is neither commonplace nor a straightforward transaction. Even researchers whose work specifically focuses on values in technology design have noted that, while design for usability is by now thoroughly mainstream, “we are still at the shaky beginnings of thinking systematically about the practice of designing with values in mind” (Flanagan, Howe, and Nissenbaum, 323). As our exploration of the DH user experience will show, the current design presents real challenges for both new and established users and in practice strains against the values DHers endorse.

GOOGLING THE DIGITAL HUMANITIES

Let’s begin with an experiment. Asked recently to address the question “What Is Digital Humanities and What’s It Doing in English Departments?” Matt Kirschenbaum told his audience, “It’s tempting to say that whoever asks the question has not gone looking very hard for an answer.” (In a comment on the associated blog post he is blunter still, writing of “intellectual laziness.”) He characterizes DH as having a “robust professional apparatus” that is “easily discoverable” and demonstrates this by Googling the term and consulting its entry in Wikipedia. If we follow his example we can certainly get a sense of the field: Google lists first (at time of writing) the Wikipedia entry for digital humanities, then the Association of Digital Humanities Organizations (ADHO) site, Digital Humanities Quarterly, the Digital Humanities 2011 conference (titled “Big Tent Digital Humanities”), two entries for the National Endowment for the Humanities’s Office of Digital Humanities, and so on. But think of the participant in Rieger’s study who commented, “When I hear ‘digital humanities,’ I think about funding. Only those with connections to established centers are able to do it.” There would be little in Google’s result set to make him think otherwise. Almost all the sites listed in the first pages are associated with major initiatives and premier institutions. This also means that smaller projects—especially those addressing topics that are underrepresented in the field—continue to be hidden from view.

The presence of any “big tent” to unite DH’s disparate parts is also far from apparent. Currently, at least, there is no site that explains, advocates, and showcases work of the DH community, in its full range, to all its potential audiences (general public, faculty, students, curators, librarians, administrators, funders, and so on), that invites users in and helps them navigate the field. And surveying the sites that users might reach from the Wikipedia page, Google’s search results, and the ADHO’s list of resources, very few set their work explicitly in the context of the digital humanities, articulate their mission in terms that are accessible to a broader audience, or link to other sites in the community.⁷ Institutional, not shared, identity is to the fore; as Neil Fraistat, director of the Maryland Institute for Technology in the Humanities (MITH), acknowledges in his contribution to this collection, the major DH institutions “rarely collaborate with other centers, with whom they compete for funding and prestige.” It is not surprising, then, that it’s hard to detect a feeling of community in the search results and that they reflect instead DH’s fragmentation. But from a user’s perspective, the lack of connective tissue between even key components of DH means that Google is actually essential to navigate the field—the problem being that to Google something one already needs to know that it exists.

In his discussion of “Inclusion in the Digital Humanities,” Geoffrey Rockwell has argued for both maintaining DH as a commons (we will return to this concept in a moment) and creating “well-articulated onramps”—professional training, graduate programs, and so on—that will allow people to access it. But signposts to the commons, to the on-ramps, are also needed to make them discoverable by the very people who need them most. Surely, though, Google or Wikipedia should not function as the home page for the digital humanities, its core navigation. This is not to propose an AOL for DH, a blandly corporate interface layer. Rather that the DH community, not the algorithm of a proprietary tool, should decide how its work is presented and made accessible and navigable for its users. If experienced users protest that newbies are finding only the most noticeable parts of DH and mistaking them for the whole, it’s important to remember that they—we—confront a complex and fractured field largely without a guide.

TWEETING THE DIGITAL HUMANITIES

DHers have adopted Twitter to such a degree that it is in danger of defining the field by synecdoche in the broader imaginary. They have found Twitter’s core functionality profoundly compelling, in spite of its usability issues. (Notoriously, it appears first in Google Instant’s suggested answers to the query “how to use.”) Kirschenbaum, for instance, tweets,⁸ “Q: Has Twitter done more as DH cyberinfrastructure than any dedicated effort to date?” DHers use it for information sharing, discussion, and community building, though its effectiveness and appropriateness for each has been questioned. Bethany Nowviskie’s post “Uninvited Guests” and the associated comments explore the tension between openness and privacy in tweeting at academic conferences, and she acknowledges sympathetically that new users are likely to feel “a little inept and lost.” In the aftermath of the 2011 MLA Convention, Mark Sample worried about the “Twitter Hegemony” that rendered nonparticipants as silent, and Perian Sully pointed to the lack of communication between users of Twitter and other existing online communities such as museum listservs, advising DHers to “stop using Twitter as the vehicle for outreach.” These are significant problems. But if indeed Twitter—like Google—is a critical component of DH’s cyberinfrastructure, three additional weaknesses stand out.

First, just as Google promotes well-connected sites, so DH’s chosen network privileges those who are, or are reciprocally linked to, well-connected users. Twitter’s asymmetric follow model does provide extraordinary access to DH’s “stars,” along with a weaker version of the seductive telepresence familiar from earlier modes such as instant messaging. But as Kirschenbaum has discussed (“The [DH] Stars Come Out in LA”), the lack of mutuality in Twitter relationships can simply replicate or “reify” the offline hierarchies of DH. In practice, this means that the net here is not neutral but biased in favor of those with more and better connections. Their messages are the most likely to be distributed, their voices the most likely to be amplified. User-defined modes exist that slice across this bias: the use of hashtags, for instance, through which the voices of all users tweeting on a particular topic can be heard, regardless of status, and many Twitter users generously adopt a principal of reciprocal following. But the bias is there, and disproportionately and daily inhibits the reach of new users and those at the margins of the DH network who have limited access to its more powerful nodes.

This problem impacts existing users, too, perhaps especially the stars themselves. One commenter on Kirschenbaum’s “The (DH) Stars Come Out in LA,” Jordan Grant, a self-described DH newcomer, observes, “I ‘follow’ and listen to DH stars because they serve as essential hubs for new information and ideas—from job announcements to emerging research to this very blog post. Without the stars, I don’t know how well the DH community would function” (emphasis added). That is quite a load to bear. We could suggest, in fact, that part of the wearying “always ‘on’” nature of the role that Nowviskie describes in “Eternal September” stems from that responsibility—to act as hub, catching and rebroadcasting messages that are important to the community. Established users, for instance, form the crowd that sources DHNow, the online journal of the digital humanities, which is powered by their tweets.⁹ And as we have seen, users with weaker connections rely on them to communicate their messages effectively. It is not only Twitter as network but stars as nodes that are critical components of the DH infrastructure—they are cybernetically welded into it.

Another issue affects all users who actively attempt to follow the field: while Twitter is very good at disseminating information, it is notoriously bad at making it persistent. Here, for instance, are a couple of tweets from Kathleen Fitzpatrick¹⁰: “Some weeks back somebody wrote a great post about returning to blogging from Twitter as a means of creating a more permanent archive …but now I can’t track that post down. (Irony? Perhaps.) Anyhow, if you remember that post, would you let me know? Thanks!” David Berry has likened Twitter to the stock ticker, noting the impact of the ticker on its users when it was introduced in the late nineteenth century. Users were reported to have entered a trance-like state, marked by “attention, vigilance and constant observation.” Coping with a real-time feed of the kind of information that flows across the DH network, however—information that users actually may want to retain—is very demanding. And users absent themselves at a cost, as Fitzpatrick notes¹¹: “Funny how far out of the loop I now feel if I spend a day offline.” For information capture, Twitter is a mode better suited to the flâneur than the DH bricoleur. In “So the Colors Cover the Wires,” Kirschenbaum recalls the “baroque array of spoofs, tricks, workarounds, fixes, and kludges” that characterized web development in the mid-1990s (with the uneven results that spawned the usability industry). But nostalgia for that moment may be premature: every day, hundreds of individual acts of writing to storage take place, using our own “baroque array” of practices—favoriting, bookmarking, RSSing, archiving, harvesting, extracting—all subject to the whims of Twitter’s infrastructure and changing business practices. This is part of the invisible work of keeping up with DH, tedious but necessary, inefficient and seemingly inevitable, since it is built into the current system design.¹²

WRITING THE DIGITAL HUMANITIES: CENTERS AND NODES

The centerless, distributed nature of the Internet that Scheinfeldt references gives it its flexibility and extensibility, its resilience and failover capabilities. And it is an important feature of DH, for the same reasons. In his post “On the Death of the Digital Humanities Center,” Mark Sample fears for the future of the DH center, and we know that his fears are justified. Only recently, Transcribe Bentham, an exemplary project, announced that it had exhausted the funding that supports its public outreach and collaboration efforts.¹³ Sample advises us, “Act as if there’s no such thing as a digital humanities center.” We should instead form our own networks and alliances outside established institutional structures: “To survive and thrive, digital humanists must be agile, mobile, insurgent. Decentralized and nonhierarchical. Centers, no. Camps, yes.” But a commenter, Kathy, raises a critical issue: “Ok, Mark, this is great advice. But, how will those camps and discrete collaborative relationships have any wider impact? Everyone will re-invent the wheel every time?” The problems that Kathy describes, however, already beset DH. Whether DH centers proliferate or etiolate, DH has no center, and this, to my view, is its biggest usability problem.

DH’s weak front end complicates the user’s ability to discover and navigate the system as a whole, as we have seen. The field’s reliance on Twitter as a backbone for scholarly communication renders key information only fragmentarily and fleetingly readable, requiring individual users’ persistence to make it persistent. But the centerless model, to be effective, relies on a seamless interoperability that simply does not exist in DH. Like the other issues we have explored, this has very practical implications. As Kim Knight reports in her MLA 2011 talk for a panel on “The Institution(alization) of Digital Humanities,” the diffusion of what she calls DH’s “ecology” means that “one must actively traverse the terrain of the ecology, looking for connections, all of the time.” She is “100% certain,” she says, that there is work going on in her area of specialization of which she is totally unaware. In fact, DH is an enormously complex, multifunction, distributed system that is largely undocumented. There are of course many rich resources available—the Digital Research Tools (DiRT) wiki, for example, or the supporting information provided by the Text Encoding Initiative, to give just two examples. (We will see more.) But without some kind of shared knowledge base, such resources are very hard to find. And users need to be able to find information before they can read it.¹⁴ Under these circumstances, if new users ask the same questions again and again, if we reinvent the wheel (and we do), who can blame us? No wonder the dread of Eternal September: a forum such as DHAnswers is the place where people go when they fail to find an answer to their questions in the user documentation; it is not usually the first port of call.

Where we can point to DH projects, information about how they were made is typically not available; this is true even of open-source work. Jeremy Boggs, a DH scholar-builder, writes in his post “Participating in the Bazaar: Sharing Code in the Digital Humanities,” “I would argue that, right now, the digital humanities is getting really good at shopping/browsing at the bazaar, but not actually sharing. We seem to have no problem using open source tools and applications, but very rarely are we actually giving back, or making the development and sharing of open source code a central part of our work.” Sample proposes that DH centers can and do act as a “Digital Humanities Commons,” for “knowledge and resources we can all share and build upon.” But Kathy counters, “It’s not happening yet, the sharing.” When users do attempt to share information, many of them, especially those outside of the major centers, have nowhere to put it. Users—including users at the margins—consistently create things of value for the DH community. Here are just a few small examples from recent months: a Google document collating knowledge on transcribing documents generated at MITH’s Application Programming Interface (API) workshop in February 2011, another from THATCamp Texas 2011 with a rich collection of links and thoughts related to DH pedagogy, Sheila Brennan’s list of suggestions on “Navigating DH for Cultural Heritage Professionals,” and CUNY’s Digital Humanities Resource Guide. Useful artifacts, all of which appeared on Twitter, then disappeared from view. In other words, DH’s users are actively building plug-ins but have nowhere to plug them in. The design of the system, its lack of a writeable core, militates against one of the most prized virtues of system building: reuse. And once again this problem disproportionately affects the newest and least connected users. To be clear, I’m not advocating here a command and control model—quite the reverse. But for DH to be truly usable, the center needs to be smart enough to enable the nodes to be smarter.

Shaping the Digital Humanities

Learning about the digital humanities, navigating the field, communicating across it, contributing to it—all these things are difficult in DH, as we have seen. The problems users face are not mere annoyances, though, as they may appear to some expert users; in each case they work to inhibit access and undermine community. There is danger, however, in proposing design as a solution here, even beyond the determinism this would imply. In naming DH an “ecology” Knight captures the anxiety that accompanies this moment in DH’s evolution. The messiness of DH, like any ecology is, she writes, its “condition of existence.” What impact might a designed intervention have? This tension exists in regard to usability, too. For Jakob Nielsen, one of the movement’s leading protagonists, usability is a website’s “condition for survival” (“Usability 101”). But it has also been associated with a dogmatic excess of design. Clay Shirky, for instance, has argued that Nielsen’s demands for standardization are too prescriptive and would be a homogenizing force that stifles the web’s natural modes of growth and innovation: “The Internet’s ability to be adapted slowly, imperfectly, and in many conflicting directions all at once is precisely what makes it so powerful.” There is much creativity in the act of kludging. Outside institutionally endorsed DH centers, indeed, DH could be viewed end to end as a grand kludge, with users improvising tools, techniques, funding, project teams, and career paths to advance their larger visions. What might be lost in systematizing DH’s ecosystem?

On the other hand, can we assume that DH will maintain homeostasis in a way that balances the needs of all its users? So far, it has not. Nielsen states that a usability test with only five users will discover 85 percent of the design problems in a system; many more than five users experience DH as exclusive. At THATCamp SoCal 2011, held just after the MLA Convention ended, participants created a position statement that reads, in full,

To these users, DH is already homogenized. While in Knight’s view, the primary threat to DH’s ecology is “the process of discipline formation,” DH is not as undisciplined as it seems. Not only does it have the “professional apparatus” that Kirschenbaum describes, but its “daily voicing” has inevitably settled into habitual practices. Perhaps the bigger threat is that DH’s disciplinary formations might solidify around unrecognized inequities.

If we were to propose a design for DH, then, where might we look for a model? Several analogies have been offered in the course of this piece: DH has appeared as Usenet, as Twitter, as the Internet itself. I will suggest one more. In “Lessons from One Week | One Tool,” Scheinfeldt shares his prescriptions for a successful open-source development community: “open communication channels, …access to the project’s development road map” so developers know where their work is most needed, and “technical entry points” where they can “hone their chops on small bits of functionality before digging into the core code base.” Most of all, they need “a sense of community, a sense of shared purpose, and a sense that their volunteer contributions are valued.” All of this, he tells us, must be “planned, managed, and built into the software architecture” (ibid.). A visit to Omeka.org or WordPress.org shows such a community in action—a community that, as we discussed earlier, includes the full range of users, from novices to experienced programmers. These sites speak to all users, showcase what is possible using the software, provide forums and rich user documentation; they not only invite the user to “get involved” but guide her to specific ways she can contribute according to her skill set. Importantly, as the WordPress site tells us, “Everything you see here, from the documentation to the code itself, was created by and for the community.”¹⁵

It might seem uncontroversial, anodyne even, to propose the open-source software development model as a paradigm for DH. But much as it is employed and invoked within the field, key enabling features are not yet embodied in the system’s design, as we have seen. If there were a DH road map, for example, where would it be? Who would have created it? Who would know about it, and how? There are lessons here for DH. For one thing, in very practical terms, we might suggest that a shared knowledge base on the example of WordPress’s documentation wiki, the Codex—a DH Codex, if you like—could alleviate much of the difficulty of the current user experience: making information findable, lifting the communication burden from DH’s “stars,” and providing the ability for anyone to contribute, so that the field would truly reflect the range of its participants’ concerns. Such a space, a true DH Commons, could have larger implications, however. It could reify not institutional structures but radical interdisciplinariness, supporting both weak forms of collaboration, such as linking and commenting, and strong collaboration through shared development of resources. It could offer a loose and simple framework that would only minimally constrain creative messiness, enabling not top-down direction but communal self-organization. It could grow and flex to accommodate a generous definition of the field; if a user, any user, felt that DH elided, say, accessibility issues, she could create a page and begin the process of sharing her knowledge, simultaneously opening the possibility (not, of course, the certainty) of drawing together a worldwide community of practice around that knowledge; to Kim Knight’s point, maybe the terrain could be mapped after all, its contours and lacunae made visible. The DH community could debate its values there, collectively define best practices for implementing them, and collaboratively develop a road map for DH’s future initiatives. It could enact the metaphor of DH as “meeting place” that Svensson advocates in his contribution to this collection.

Naive? Perhaps. We should not overestimate the inclusiveness of the open source model, of course; declaring a system open does not make it so, and even the Ur-collaboration, Wikipedia, has struggled with diversity issues, as its self-study has revealed.¹⁶ And yet DH does seem to be navigating an outward turn. Last year saw the launch of DHAnswers and Lisa Spiro’s initiative to “Open Up Digital Humanities Education.” Recently, Project Bamboo, the multiyear, multi-institution effort aimed at creating shared cyberinfrastructure, released the proof-of-concept text analysis tool, Woodchipper. The associated website invites users to participate in alpha testing and links to a wiki where users can provide feedback. And the Scholars’ Lab, under the direction of Bethany Nowviskie, has created Spatial Humanities, “a place to ask questions, discover research, learn from tutorials, and explore innovative projects” that use spatial technologies and that allows users to contribute to a knowledge base. If to date, DH as a system has tended to evolve, significant elements of it are now being proactively and quite literally designed. When implemented on a large scale and with large financial investments, however, such infrastructure can become the equivalent of a definitive edition in textual scholarship: unsupplantable for a generation. But our small, local, and particular decisions also shape DH, as Nowviskie reminds us; inescapably, we are all designing DH.

Here, then, are a few questions, questions that are equally applicable locally and institutionally, literally and metaphorically, as we shape our communities and practices as well as our tools: Which users will be included in designing and building DH? How participatory and reflexive will that process be? How will the design balance efficiency, ease of use, and user agency? There are arguments to be made against implementations that privilege a frictionless usability over summoning the user to thought, that emulate the app rather than the open web. So, will the colors cover the wires? Will those users who wish to engage more deeply be permitted to trace the wires to their source, even to the core? Or will the interface enforce a clean line between who’s in and who’s out, makers and users, producers and consumers? How will the concept of the user be inscribed, or circumscribed, in DH’s emergent design?

Of course, as Latour reminds us, “circumscription only defines how a setup itself has built-in plugs and interfaces; as the name indicates, this tracing of circles, walls, and entry points inside the text or the machine does not prove that readers and users will obey” (237). Fortunately, a system cannot legislate behavior or desire. McCarthy and Wright note that users “appropriate the physical and conceptual space created by producers for their own interests and needs; they are not just passive consumers” (11). Users will navigate their own paths through the interface of DH, paths of innovation and resistance. Another possibility, of course, is that they will not use the system at all. Notwithstanding the claims of usability consultants, adoption is stubbornly unpredictable. Laura Mitchell, a commenter on Perian Sully’s post, draws a telling parallel with gender studies, her own area of expertise: “Despite at least 40 years of exacting scholarship, gender remains a sub-field, a fundamental aspect of human social existence that scholars can choose to ignore if they want to. And DH??” The analogy DH’s critics like to make is with Big Theory, and this is the implication: that one day we will look back on DH as just another wave that broke over the academy, eroded its formations perhaps in some small places, and then receded, leaving a few tranquil rock pools behind. Mitchell’s concern is that the skills newcomers need to acquire form a real barrier to entering DH and thus will limit its reach. The open-source model, however, suggests that our field’s current focus on qualification, on boundary setting, is unnecessary and that the choice between emptying the term “digital humanities” of meaning on the one hand and defending it as specialist redoubt on the other is a false one. Instead it offers another vision: that by working, individually and collectively, to adopt and actively enable a flexible and extensible conception of the user, we can include all comers as diverse actors in the network of DH.