One of the things I’m hoping has become clear–perhaps painfully so for a few of us–is the extent to which a digital humanities project represents a substantial amount of work. Even a supposedly small element in a project, like metadata tagging, can turn out to be a difficult and time-intensive piece of work, one which generally isn’t much fun but which has to get done. Continuation, expansion and maintenance of an existing site, like EBBA, typically entails a repetition or reiteration of this kind of work. If the EBBA site adds a new search term (searching by place or by type of image), then a new set of metadata must be developed and then entered for every single item in the archive.

Projects involving tools require either direct coding or adoption of existing code from other sites. In theory, a tool developed to speed the entry of metadata for the EBBA project could be employed for similar projects; in practice, tools often are either outdated or coded in a way so specific to a single project that they require modification for broader use. Hence, the development and proliferation of project platforms (WordPress and Blogger, for example, are blogging/web-page platforms; Omeka is a platform tailored for more metadata-intensive application). Standards for metadata exist alongside such platforms, like the TEI standard we’ve looked into earlier in the semester.

When a collaborative online project exists in the way that user involvement typically exists (with Facebook or myspace or Youtube or Wikipedia), everything seems easy enough. You log in, post your edit to the wiki entry, other people vet the entry, and it’s all good. In practice, this kind of open development conceals from the typical user the degree of work which was involved, from developing and maintaining a platform (like the wiki platform), to administrating a site (Wikipedia servers must be purchased, maintained, replaced, just as one example), not to mention the difficulty in starting up such a project in the first place. And while the Internet bills itself as a kind of instant gratification engine–Google tells you how many tenths of a second it took to generate its results, for instance–the actual time and investment of energy required to develop an online project, not to mention the requirements to put it into practice, looks much closer to scholarly and academic norms and expectations. Most projects I’ve seen which make their histories known took years to get past the starting gate. EBBA, for example, began development in 2003. That means the EBBA development has gone on longer than, say, the iPhone, from initial conception to present implementation.

One of the challenges digital humanities face going forward, within the academic community, is articulating more clearly to those who assess scholarly work the degree of time, planning and organization required to prototype, much less “complete,” a single project.