The criticism most frequently leveled at digital humanities is what I like to call the “Where’s the beef?” question, that is, what questions does digital humanities answer that can’t be answered without it? What humanities arguments does digital humanities make?

Concern over the apparent lack of argument in digital humanities comes not only from outside our young discipline. Many practicing digital humanists are concerned about it as well. Rob Nelson of the University of Richmond’s Digital Scholarship Lab, an accomplished digital humanist, recently ruminated in his THATCamp session proposal, “While there have been some projects that have been developed to present arguments, they are few, and for the most part I sense that they haven’t had a substantial impact among academics, at least in the field of history.” A recent post on the Humanist listserv expresses one digital humanist’s “dream” of “a way of interpreting with computing that would allow arguments, real arguments, to be conducted at the micro-level and their consequences made in effect instantly visible at the macro-level.”

These concerns are justified. Does digital humanities have to help answer questions and make arguments? Yes. Of course. That’s what humanities is all about. Is it answering lots of questions currently? Probably not really. Hence the reason for worry.

But this suggests another, more difficult, more nuanced question: When? When does digital humanities have to produce new arguments? Does it have to produce new arguments now? Does it have to answer questions yet?

In 1703 the great instrument maker, mathematician, and experimenter, Robert Hooke died, vacating the suggestively named position he occupied for more than forty years, Curator of Experiments to the Royal Society. In this role, it was Hooke’s job to prepare public demonstrations of scientific phenomena for the Fellows’ meetings. Among Hooke’s standbys in these scientific performances were animal dissections, demonstrations of the air pump (made famous by Robert Boyle but made by Hooke), and viewings of pre-prepared microscope slides. Part research, part ice breaker, and part theater, one important function of these performances was to entertain the wealthier Fellows of the Society, many of whom were chosen for election more for their patronage than their scientific achievements.

Upon Hooke’s death the position of Curator of Experiments passed to Francis Hauksbee, who continued Hooke’s program of public demonstrations. Many of Hauksbee’s demonstrations involved the “electrical machine,” essentially an evacuated glass globe which was turned on an axle and to which friction (a hand, a cloth, a piece of fur) was applied to produce a static electrical charge. Invented some years earlier, Hauksbee greatly improved the device to produce ever greater charges. Perhaps his most important improvement was the addition to the globe of a small amount of mercury, which produced a glow when the machine was fired up. In an age of candlelight and on a continent of long, dark winters, the creation of a new source of artificial light was sensational and became a popular learned entertainment, not only in meetings of early scientific societies but in aristocratic parlors across Europe. Hauksbee’s machine also set off an explosion of electrical instrument making, experimentation, and descriptive work in the first half of the 18th century by the likes of Stephen Gray, John Desaguliers, and Pieter van Musschenbroek.

And yet not until later in the 18th century and early in the 19th century did Franklin, Coulomb, Volta, and ultimately Faraday provide adequate theoretical and mathematical answers to the questions of electricity raised by the electrical machine and the phenomena it produced. Only after decades of tool building, experimentation, and description were the tools sufficiently articulated and phenomena sufficiently described for theoretical arguments to be fruitfully made.*

There’s a moral to this story. One of the things digital humanities shares with the sciences is a heavy reliance on instruments, on tools. Sometimes new tools are built to answer pre-existing questions. Sometimes, as in the case of Hauksbee’s electrical machine, new questions and answers are the byproduct of the creation of new tools. Sometimes it takes a while, in which meantime tools themselves and the whiz-bang effects they produce must be the focus of scholarly attention.

Eventually digital humanities must make arguments. It has to answer questions. But yet? Like 18th century natural philosophers confronted with a deluge of strange new tools like microscopes, air pumps, and electrical machines, maybe we need time to articulate our digital apparatus, to produce new phenomena that we can neither anticipate nor explain immediately. At the very least, we need to make room for both kinds of digital humanities, the kind that seeks to make arguments and answer questions now and the kind that builds tools and resources with questions in mind, but only in the back of its mind and only for later. We need time to experiment and even—as we discussed recently with Bill Turkel and Kevin Kee on Digital Campus—time to play.

The 18th century electrical machine was a parlor trick. Until it wasn’t.

* For more on Hooke, see J.A. Bennett, et al., London’s Leonardo : The Life and Work of Robert Hooke (Oxford, 2003). For Hauksbee and the electrical machine see W.D. Hackmann, Electricity from glass : The History of the Frictional Electrical Machine, 1600-1850 (Alphen aan den Rijn, 1978) and Terje Brundtland, “From Medicine to Natural Philosophy: Francis Hauksbee’s Way to the Air-Pump,” The British Journal for the History of Science (June, 2008), pp. 209-240. For 18th century electricity in general J.L. Heilbron, Electricity in the 17th and 18th Centuries : A Study of Early Modern Physics (Berkeley, 1979) is still the standard. Image of Hauksbee’s Electrical Machine via Wikimedia Commons.

During a discussion of e-book readers on a recent episode of Digital Campus, I made a comparison between Amazon’s Kindle and Apple’s iPod which I think more or less holds up. Just as Apple revolutionized a fragmented, immature digital music player market in the early 2000s with an elegant, intuitive new device (the iPod) and a seamless, integrated, but closed interface for using it (iTunes)—and in doing so managed very nearly to corner that market—so too did Amazon hope to corner an otherwise stale e-book market with the introduction last year of its slick, integrated, but closed Kindle device and wireless bookstore. No doubt Amazon would be more than happy with the eighty percent of the e-book market that Apple now enjoys of the digital music player market.

In recent months, however, there have been a slew of announcements that seem to suggest that Amazon will not be able to get the same kind of jump on the e-book market that Apple got on the digital music market. Several weeks ago, Sony announced that it was revamping its longstanding line of e-book readers with built-in wifi (one of the big selling points of the Kindle) and support for the open EPUB standard (which allows it to display Google Books). Now it appears that Barnes & Noble is entering the market with its own e-book reader, and in more recent news, that its device will run on the open source Android mobile operating platform.

If these entries into the e-book market are successful, it may foretell of a more open future for e-books than has befallen digital music. It would also suggest that the iPod model of a closed, end-to-end user experience isn’t the future of computing, handheld or otherwise. Indeed, as successful and transformative as it is, Apple’s iPhone hasn’t been able to achieve the kind of dominance of the “superphone” market that the iPod did of the music player market, something borne out by a recent report by Gartner, which has Nokia’s Symbian and Android in first and second place by number of handsets by 2012 with more than fifty percent market share. This story of a relatively open hardware and operating system combination winning out over a more closed, more controlled platform is the same one that played out two decades ago when the combination of the PC and Windows won out over the Mac for leadership of the personal computing market. If Sony, Barnes & Noble, and other late entrants into the e-book game finish first, it will have shown the end-to-end iPod experience to be the exception rather than the rule, much to Amazon’s disappointment I’m sure.

I’m very happy to report that CHNM has been awarded a grant from the National Endowment for the Humanities under its Institute for Advanced Topics in Digital Humanities program to do for the summer scholarly institute what THATCamp is doing for the scholarly conference. Under the banner of “better, faster, lighter”—as well as more pragmatic, more collaborative, and more fun—CHNM will host a diverse group of twelve digital humanists for a busy week of tool-building in Summer 2010. Welcome to One Week, One Tool, a digital humanities barn raising.

With a decade of successful digital tool-building experience under its belt, we at CHNM have come to the conclusion that effective digital tools are forged mostly in practice rather than theory. Although inspirational ideas and disciplinary training are necessary, the creative process succeeds or fails due to pragmatic, often hidden or ignored fundamentals such as good user interface design, thorough code commenting and documentation, community engagement, dissemination and “marketing,” and effective project management. We may have a vision for an ideal end product, but frequently a tool is made or broken in seemingly more mundane aspects of software development.

Too often these practical aspects get lost in our conferences and workshops, only to be encountered by inexperienced tool builders at later stages of development and release. We thus believe a useful digital humanities institute should involve a great deal of doing in addition to basic instruction. There is no reason that a week long institute can’t both teach and produce something useful to the community—an actual digital humanities tool—while also laying the foundation and skills for future endeavors by the participants. Indeed, the act of doing, of building the tool, should be the best way for participants to learn what digital humanities really is and how it really happens.

We therefore propose a unique kind of institute: One Week, One Tool will teach participants how to build a digital tool for humanities scholarship by actually building a tool, from inception to launch, in a week—a digital humanities barn raising.

One Week, One Tool won’t be for the faint of heart. For one week in June 2010, from early mornings to late nights, we will bring together a group of twelve digital humanists of diverse disciplinary backgrounds and practical experience to build something useful and useable. A short course of training in principles of open source software development will be followed by an intense five days of doing and a year of continued community engagement, development, testing, dissemination, and evaluation. Comprising designers and programmers as well as project managers and outreach specialists, the group will conceive a tool, outline a roadmap, develop and disseminate a modest prototype, lay the ground work for building an open source community, and make first steps toward securing the project’s long-term sustainability.

One Week, One Tool is inspired by both longstanding and cutting edge models of rapid community development. For centuries rural communities throughout the United States have come together for “barn raisings” when one of their number required the diverse set of skills and enormous effort required to build a barn—skills and effort no one member of the community alone could possess. In recent years, Internet entrepreneurs have likewise joined forces for crash “startup” or “blitz weekends” that bring diverse groups of developers, designers, marketers, and financiers together to launch a new technology company in the span of just two days. One Week, One Tool will build on these old and new traditions of community development and the natural collaborative strengths of the digital humanities community to produce something useful for digital humanities work and to help reset the balance between learning and doing in digital humanities training.

Are you ready to rumble?

Via Mashable, yet another timeline service: Timetoast.

Many readers will have seen this already, but Robert Darton’s February piece in The New York Review of Books is the most readable discussion I have seen of the Google Books settlement.

Fresh + New(er), the Powerhouse Museum’s always interesting blog, describes that museum’s recent open house for local Wikipedians and the common ground they found between expert curators and amateur encyclopedists.

The American Association of State and Local History (AASLH) provides cultural heritage professionals with some relevant information on surviving the economic downturn.

JISC provides advice on choosing (or not choosing) a Creative Commons license.

Missed it at the launch? Didn’t see the point? Don’t know where to start? Ars Technica has a nice reintroduction and tutorial for Yahoo Pipes, a visual web content mashup editor. Here’s an example of the kind of thing you can do very easily (20 minutes in this case) with Pipes: an aggregated feed of CHNMers’ tweets displayed on a Dipity timeline.

Ahoy, Mateys! Mills Kelly’s fall semester course “Lying about the Past” was revealed today in The Chronicle of Higher Education. Read how Mills and his students perpetrated an internet hoax about “the last American pirate” and what they learned in the process. The Chronicle is, unfortunately, gated, but you can read more on Mills’ fantastic blog, edwired.

I’m sure many of you have encountered NITLE’s prediction markets, but a recent presentation at CNI by NITLE’s Director of Research Bryan Alexander reminded me I haven’t blogged it yet. As I told Bryan recently, the prediction markets are a great example of form (crowdsourcing educational technology intelligence) fitting function (NITLE’s mission to advise member schools on emergent practices) in the digital humanities.

Sadly, The Times of London recently reported a raid on the offices of Memorial, a human rights and educational organization that seeks to document the abuses of the Soviet Gulag prison camp system. Memorial was a key partner on CHNM’s Gulag: Many Days, Many Lives, and its generous research assistance and loan of documents, images, and other artifacts was essential to our successful completion of the project. It is very sad to see this brave and worthy organization suffering the same abuses in Putin’s Russia that it has worked so hard to expose in Stalin’s.

Last month the Smithsonian Institution’s National Museum of American History (NMAH) celebrated its grand reopening after an extended closure for major renovations. Meanwhile, in the web space, NMAH launched its History Explorer, which aggregates and categorizes online educational content from across the museum. Worth a look.

Feeling increasingly alienated by commercial software companies and increasingly uncomfortable with my absurd level of Mac lust, I finally decided this weekend to get off the Apple train and make the switch to Linux.

Until I’m sure I’ve worked out all the kinks, I’m running a dual boot setup of Ubuntu 8.10b and Mac 0S 10.5 on my MacBook Pro. It was a pretty simple operation, which took up the better part of my Sunday morning, but not much more than that. I more or less followed the Ubuntu support community’s MacBook Pro documentation line for line, and everything more or less seemed to work. A few quick Google searches showed me how to install Skype and a few other applications that aren’t included in the main Ubuntu repositories. Aside from a couple minor annoyances (e.g. “right-click” is confusingly keyed to F12 or a two-finger trackpad click) so far I’m very happy.

In the coming weeks, once I’m sure I have everything I need off my old system, I hope to leave Apple entirely. I’m a little worried about what I’m going to do about my music; I’ve bought quite a bit from the iTunes Store. But the fact that my music is locked up in iTunes shouldn’t be a reason for sticking with Apple. It is yet another reason to leave.

Currently I’m looking at a combination of a Dell Mini 9 and either a desktop or 15″ laptop. If nothing else, I have a whole new range of hardware to ogle.

Let me join the choruses celebrating WordCamp Ed, which makes its debut in Fairfax on November 22, 2008. Organized by CHNM and the Center for New Designs in Learning and Scholarship at Georgetown (but mainly by our own Dave Lester), WordCamp Ed will bring together teachers of all stripes to talk about educational uses for the WordPress blogging platform. Building on the success of last spring’s THATCamp, the one-day event will feature a morning of pre-planned speakers and a barcamp-style afternoon of smaller discussion sessions. Registration is free at the WordCamp Ed blog. We only have space for about 100, so get your name in early.

[Image credit: Tom Woodward]

Congratulations to the Omeka dev team (especially Jeremy Boggs, Kris Kelly, Dave Lester, and Jim Safley), which today announced the release of version 0.10 alpha, the first major release of Omeka since February’s 0.9.0. For those of you who don’t know about Omeka, it is CHNM‘s next generation web publishing platform for collections-based research, one that puts serious web publishing within reach of all scholars and cultural heritage professionals.

The alpha version includes a major reworking of Omeka’s data model to support unqualified Dublin Core and a complete overhaul of Omeka’s theme and plugin APIs. Omeka 0.10 alpha allows us to start work on a set of interoperability and data migration tools for CONTENTdm and other widely used repository and collections management software and stabilizes Omeka’s APIs to make it easier for community developers to build new plugins and themes. A gorgeous new admin theme will make using Omeka even easier for site administrators.

Omeka 0.10 alpha is available through the Omeka dev list for testing purposes only. We strongly discourage using version 0.10 alpha on a production site. We’re aiming for a stable public release of Omeka in late October. Stay tuned!

Listeners to the most recent episode of Digital Campus will know that I’m a fairly heavy user of Twitter, the weirdly addictive and hard-to-describe microblogging and messaging service. But anyone who uses the wildly popular service regularly will also know that the company’s service architecture has not scaled very well. During the last month or so, as hundreds of thousands have signed up and started “tweeting,” it has sometimes seemed like Twitter is down as often as it’s up.

Considering the volume and complexity of the information they’re serving, and the somewhat unexpectedness of the service’s popularity, I tend not to blame Twitter for its downtime. As a member of an organization that runs its own servers (with nowhere near the load of Twitter, mind you), I sympathize with Twitter’s situation. Keeping a server up is a relentless, frustrating, unpredictable, and scary task. Yet as a user of Twitter, I still get pretty annoyed when I can’t access my friends’ tweets or when one of mine disappears into the ether.

It’s clear, however, that Twitter is working very hard to rewrite its software and improve its network infrastructure. How do I know this? First, it seems like some of the problems are getting better. Second, and more important, for the last week or so, Twitter has been blogging its efforts. The Twitter main page now includes a prominent link to the Twitter Status blog, where managers and engineers post at least daily updates about the work they’re doing and the problems they’re facing. The blog also includes links to uptime statistics, developer forums, and other information sharing channels. Twitter’s main corporate blog, moreover, contains longer posts about these same issues, as well as notes on other uncomfortable matters such as users’ concerns about privacy under Twitter’s terms of service.

Often, an organization facing troubles—particularly troubles of its own making—does everything it can to hide the problem, its cause, and its efforts to fix it. Twitter has decided on a different course. Twitter seems to have realized that its very committed, very invested user base would prefer honesty and openness to obfuscation and spin. By definition, Twitter users are people who have put themselves out there on the web. Twitter’s managers and engineers have realized that those users expect nothing less of the company itself.

As a Twitter user, the company’s openness about its difficulties has made me more patient, more willing to forgive them an occasional outage or slowdown. There is a lesson in this for digital and public historians. Our audiences are similarly committed. We work very hard to make sure they feel like we’re all in this together. We should remember this when we have problems, such as our own network outages (CHNM is experiencing one right now, btw) and technical shortcomings.

We are open with our successes. We should be open with our problems as well. Our audiences and partners will reward us with their continued loyalty and (who knows?) maybe even help.