Rome Wasn't Digitized in a Day - Council on Library and Information ...

185
their use of a resource, be it a challeng<strong>in</strong>g <strong>in</strong>terface or confus<strong>in</strong>g data, would stop them from us<strong>in</strong>g it.
These f<strong>in</strong>d<strong>in</strong>gs, Warwick et al. (2008b) proposed, should be carefully considered by the creators of
digital resources:
Thus it is <strong>in</strong>cumbent on producers of digital resources not only to understand the work<strong>in</strong>g
practices of the scholars for whom they design, but to produce a resource that is attractive,
usable and easy to understand. However, perhaps surpris<strong>in</strong>gly, there appears to be no research
that assesses how well digital humanities resources are perform<strong>in</strong>g <strong>in</strong> these respects (Warwick
et al. 2008b).
Thus the need to understand the work<strong>in</strong>g practices of the scholars for whom a resource is be<strong>in</strong>g
designed is as important as creat<strong>in</strong>g an attractive and usable resource.
While none of the 20 digital humanities projects chosen for analysis was with<strong>in</strong> the discipl<strong>in</strong>e of
classics, the results of the LAIRAH <strong>in</strong>terviews provide some useful <strong>in</strong>formation on what makes a
digital resource successful <strong>in</strong> the long term. Warwick et al. (2008b) explored the documentation (if
any) on each website and conducted a semistructured <strong>in</strong>terview with a project representative that
covered the creation and history of a resource, fund<strong>in</strong>g, technical standards, dissem<strong>in</strong>ation, and user
test<strong>in</strong>g. Not surpris<strong>in</strong>gly, they found that the <strong>in</strong>stitutional context and “research culture of particular
discipl<strong>in</strong>es” greatly affected the production and use of digital resources. One major issue was limited
<strong>in</strong>stitutional recognition and prestige for scholars who did digital humanities work; another was
uncerta<strong>in</strong>ty among their colleagues as how to value digital scholarship. Another critical issue for the
success of digital humanities projects was adequate technical support and staff<strong>in</strong>g. While most
pr<strong>in</strong>cipal <strong>in</strong>vestigators (PIs) were relatively happy about the level of support they received (typically
from local IT staff or expert colleagues), those that reported contact with a digital humanities center
received an even higher level of expert advice. Staff<strong>in</strong>g issues were paramount, as research assistants
required both subject knowledge and a good grasp of digital techniques. The grant-funded nature of
most projects also made it hard for research assistants to obta<strong>in</strong> adequate technical tra<strong>in</strong><strong>in</strong>g or for PIs to
reta<strong>in</strong> them beyond <strong>in</strong>dividual projects.
The most important factor that led to resources that were well used, however, was active dissem<strong>in</strong>ation
of project results. All the projects whose PIs were <strong>in</strong>terviewed spent considerable time dissem<strong>in</strong>at<strong>in</strong>g
<strong>in</strong>formation about their resources at conferences and workshops. Warwick et al. (2008b) noted that this
type of “market<strong>in</strong>g” was a very new area of activity for many academics. A related if not unexpected
f<strong>in</strong>d<strong>in</strong>g was that the most-well-used resources tended to be long-lived. This was not necessarily an
<strong>in</strong>dicator of successfully meet<strong>in</strong>g user needs. “The persistent use of older digital resources, even when
newer, perhaps better ones become available,” Warwick et al. put forward, “may be expla<strong>in</strong>ed by a
commercial phenomenon known as ‘switch<strong>in</strong>g costs’”(Warwick et al. 2008b). In other words, users
often rema<strong>in</strong> loyal to a particular resource because the effort <strong>in</strong>volved <strong>in</strong> switch<strong>in</strong>g to a new tool is to
great.
Another area explored by Warwick et al. (2008b) was the amount of user contact <strong>in</strong> which successful
projects were engaged. They found that few projects had “undertaken any type of user test<strong>in</strong>g” or
ma<strong>in</strong>ta<strong>in</strong>ed any formal contact with their users. In addition, most projects had little if any
understand<strong>in</strong>g either of how their resources were used, or how often. All projects, however, were
<strong>in</strong>terested <strong>in</strong> how their projects were be<strong>in</strong>g used and had made some efforts <strong>in</strong> this area. The most
common method, accord<strong>in</strong>g to Warwick et al., was the idea of “designer as user” or where most PIs
assumed that their subject knowledge meant that they understood the needs of users and thus could