ArticlePDF Available

The consequences of framing digital humanities tools as easy to use



This article examines the recurring ways in which some of the most popular DH tools are presented as easy to use. It argues that attempts to couch powerful tools in what is often false familiarity, directly undermines the goal of encouraging scholarly innovation and risk taking. The consequences of framing digital tools as either easy or more difficult shapes the relationship between librarians and the students and faculty whose research they support, and, more broadly, the role and viability of libraries as spaces devoted to skill acquisition.
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 1
The Consequences of Framing Digital Humanities Tools as Easy to Use
Paige Morgan
ORCID: 0000-0001-8076-7356
This article examines the recurring ways in which some of the most popular DH tools
are presented as easy to use. It argues that attempts to couch powerful tools in what is
often false familiarity, directly undermines the goal of encouraging scholarly innovation
and risk taking. The consequences of framing digital tools as either easy or more
difficult shapes the relationship between librarians and the students and faculty whose
research they support, and, more broadly, the role and viability of libraries as spaces
devoted to skill acquisition.
Keywords: infrastructure, digital humanities, DH tools, DH pedagogy
A digital humanities librarian provides consultations to researchers who are
developing or struggling with DH projects. Frequently, these consultations begin with
the researcher apologizing and explaining to the librarian their poor aptitude for digital
humanities. In many cases, these researchers’ prior experience includes a referral to
one or more digital humanities tools that have been branded as user-friendly/easy to
At first, it can look as though this phenomenon is chiefly the result of language
and rhetoric used to frame various DH tools a component influenced by the software
industry’s move towards graphical user interfaces and marketing software for everyone
to use, whether in the workplace or at home, regardless of gender, age, or other factors
that affect digital tools. That language remains the article’s primary focus. However, the
issue is not simply tool-framing language. The taglines and framing in tool
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 2
documentation are the most visible and stable form, as opposed to more ephemeral
instances of language in LibGuides, promotional materials, and workshops and
conversations at conferences. Researchers are encountering and struggling with an
approach to DH growth and expansion that substantially relies on marketing aspects of
DH research as easy. In other words, this article explores the way that our framing for
DH tools and resources shapes researchers’ emotions and expectations. Sociologist
Susan Leigh Star examined “the work behind the work” in scientific research contexts,
meaning “the countless, taken-for-granted and often dismissed practices of assistants,
technicians, and students that made scientific breakthroughs possible” (Timmermans
2016, 1). The infrastructure set-up for digital humanities, and the pressures that it
places on students, serve as a parallel area of hidden work that can be illuminated.
Despite the presence of easinessrhetoric in multiple contexts, tool presentation
language is often the most concrete example that is available for analysis. Tool
presentation language is the material that constitutes users’ introduction to the tool
usually the front page of a website, the about page, and any promotional videos the
materials that create a tool’s reputation. Instead of residing in a particular tool, or the
tool creators’ choices, this is a problem within the design of the larger field of the digital
humanities, a problem that can remain largely invisible. Recent efforts in library and DH
scholarship have focused on illuminating work in digital humanities that tends to go
unseen (Shirazi 2016); by unpacking the challenges around tool framing, one can lay
the ground for working with them more effectively.
Defining Easiness
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 3
Ease of use is one of the most desirable characteristics for any given tool
rivaled only in popularity by the quality of being free. It is not merely a digital humanities
fascination developers have been pursuing the creation of user-friendly graphical
interfaces since the late 1960s. That pursuit has its own complex and continuing history,
bound up in corporate rivalry and the outsized influence of certain tech leaders, such as
Steve Jobs and his fascination with skeuomorphic design. As the tech industry has
exerted influence on DH in many ways, it is unsurprising that DH tools have emulated
this aspect of tech design.
Easiness can seem like an obvious goal for DH support practitioners and tool
developers; it goes hand in hand with efforts to democratize the field and make learning
and research opportunities more available, regardless of whether institutions have
existing and active DH programs. The easier it is to do DH, the more people will try it
out an appealing prospect at a time when humanities departments are looking for
ways of asserting their continuing relevance, reinventing themselves in response to
cultural shifts, and working to demonstrate that they provide students with job-ready
Easiness is attractive in part because it is powerful. The availability of easy-to-
use tools shapes DH support infrastructure and affects how DH is incorporated into the
classroom, in terms of how much time is needed to show students how to configure a
tool and begin using it. For individual scholars developing projects, perceived ease or
difficulty can be a deciding factor if there are multiple tools from which to choose and
may determine whether the scholar decides to pursue the project at all. Transitioning to
digital from conventional printed scholarship includes an adjustment to iterating through
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 4
multiple stages; and may involve multiple, modular outputs, such as datasets, websites,
and processing workflows (Brown et. al. 2009, par. 7). The technical and scholarly
ambitiousness of a particular project will intersect with each other. Depending on a
scholar or team’s prior experience, the impacts of this intersection may be hard to
predict (Brown et. al. 2009, par. 6). The problem of unpredictable challenges is
complicated further by the pressure researchers face to show their deliverables to
colleagues who may be less accustomed to the ups and downs of iteration, but are still
called to evaluate it, either for promotion or degree completion. While guidelines and
articles from major disciplinary organizations (Modern Language Association 2012;
Presner 2012; American Historical Association 2015) discussing the evaluation of digital
scholarship acknowledge the iterative nature of digital work, it is harder for such
guidelines to prepare colleagues for evaluating mid-stage outputs with aesthetics that
may not match the sophistication of the various commercial websites that individuals
encounter every day. All these factors contribute to making “easy” tools compelling.
Despite its considerable dazzle, easiness is an abstract and intangible quality;
the promise of easiness, or an easy-to-use tool, is that some process (whether display,
formatting, organization, or analysis) can be accomplished with minimal difficulty,
confusion, or extra labor. When such processes are simplified, researchers feel more
able to focus their learning on what they perceive as most relevant to their research
question and intellectual work. In digital humanities, and in the context of technology
generally, easiness is most likely to be associated with tools that are classified as “out-
of-the-box,” meaning that they do not require configuration or modification to work, or
“off-the-shelf,” meaning that they are standardized, rather than customized, and
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 5
intended for general audiences to be able to use. Because easiness is abstract, it can
be taken as synonymous for other qualities, like speed (cf. various statements about
accomplishing a process or analysis with “one click”). Though the variants on “easy” are
common in tool branding, terms like “fast” and “simple” are regular alternatives. For
many tools, it would be more accurate to say that they make a given process not easy,
but easier than an alternative.
Easiness is subjective what is easy for one user may not be for another. It is
important to understand that easiness is subjective because it is situated and
dependent upon other factors. These factors include the particular nature of the material
being worked with (i.e., whether the material is text or image-based), and its condition
(i.e., whether a dataset has been examined and normalized), as well as the availability
(or lack) of training or experience that provides a user with relevant contextual
knowledge. However, researchers may not see this situatedness clearly.
Finally, because easiness is both powerful and subjective, it is value-laden; and it
carries a backlash for individuals who expect to find a process or tool to be easy yet
discover the opposite. The backlash comes in part from researchers’ inexperience with
the various interdependencies and situatedness of easiness many of which are
complexities of technological, academic, and library systems and infrastructure. Ideally,
a researcher pushes past the backlash, and over time they gain familiarity and
experience that help them make choices about their research project or their career with
greater autonomy. Part of the reason that claims about easiness have such weight is
that they inevitably tell us stories about the available infrastructure and its condition
whether or not there are opportunities to learn a particular skill (e.g., a coding
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 6
language), and how legible and genuine those opportunities appear to the audience for
whom the tool is intended. As a result, scrutinizing easiness rhetoric can be helpful for
librarians and administrators who are trying to get a clearer sense of their patrons’
needs, or who want to think more critically about the type of support they are providing.
Examples of Easiness Framing
Easiness has become sufficiently important that in digital humanities LibGuides
and tool bibliographies, it may be the first or second characteristic mentioned for any
tool listed. A typical description might consist of one or two sentences explaining “[Tool]
is free and easy to use and allows you to [process/visualize/analyze content].” This sort
of description echoes the taglines and catchphrases associated with various tools.
Besides Omeka and Scalar, there is Stanford’s Palladio (“Visualize complex historical
data with ease.”), the Knight Lab’s TimelineJS (“Easy-to-make, beautiful timelines”) and
JuxtaposeJS (“Easy-to-make frame comparisons”), CartoDB (“Maps for the web, made
easy”while this is no longer CartoDB’s official catchphrase, it is still widely visible in
search results). Although qualities such as access, sustainability, and portability are
significant concerns in DH, in examining libguides and other DH tool roundups, one
sees that they are referenced far less than if a tool will be easy. The guide authors try to
succinctly articulate what each tool is meant to do; what processes it speeds up,
facilitates, or makes easier; and the language that is used to present its capabilities and
its value to potential users.
In order to get a concrete sense of how this language appears, and the promises
and assertions that tool framing makes, this article will examine three tools developed
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 7
specifically for DH use within the last ten years. The point of this examination is not to
critique or accuse the tools they are merely the most concrete and available examples
of a more widespread ephemeral phenomenon that shows up not only in written
contexts, but also in workshops, webinars, and casual conversations.
Omeka was released by the Center for History and New Media at George Mason
University in 2008, and it is intended for an audience of users in the galleries, libraries,
archives, and museums (GLAM) sector, as well as anyone else wanting to build exhibits
and collections online. It allows for the creation of multiple collections of items with
metadata structured according to disciplinary or institutional schemas and standards.
Users have the ability to follow widespread practices that will make their data
interoperable, adjust those schemas to a local house style, or do a bit of each as
needed. The sort of functionality that Omeka makes possible is available in software
developed for the GLAM community but is often priced at an institutional level that puts
it out of reach of individuals and the smallest institutions. This sort of software may be
available as open-source and may require experienced tech support personnel to
manage the back-end setup and ongoing maintenance. Since the initial release, the
Omeka development team has worked to improve the tool’s functionality and
accessibility, both through the subscription service and by making it
available as a “one-click install” through Internet service providers like Reclaim Hosting.
Omeka’s contributions are remarkable, though hard to explain succinctly for
audiences who are unfamiliar with the existing software contexts. Dan Cohen
summarized it as “WordPress for your exhibits and collections” at the original release,
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 8
aiming at a description that would make it easy for people to describe the tool to others.
Up until September 2017, featured a prominent tagline: “your online exhibit
is one click away.” In its website redesign that tagline was replaced by a less exuberant
description: Getting started is easy with Omeka with our hosted service.” The website continues marketing Omeka via Cohen’s original WordPress
reference under the heading “Simple to use”: “Our ‘five-minute setup’ makes launching
an online exhibition as easy as starting a blog. No code knowledge required.”
This rhetoric isn’t precisely mismatched, because Omeka does indeed allow
users to start adding items and metadata right away. For those already versed in
metadata standards and best practices, the main learning curve will involve getting
accustomed to the interface. However, many digital humanists coming from
departments such as English and History are unlikely to have received this training, and
as such, face an additional and substantial learning curve, because there is more to a
good Omeka exhibit than simply getting content onto the web. The
documentation acknowledges this challenge in its Getting Started section, where it
recommends that users plan out their content before building an Omeka website and
refers them to Cohen & Rosenzweig’s Digital History: A Guide to Gathering, Preserving,
and, Presenting the Past on the Web. The documentation goes further,
recommending that users sketch out wireframes of their site prior to building it. Both
versions of Omeka encourage new users to explore the showcases of existing Omeka
sites. But while Omeka may make building an exhibit as easy as blogging on a technical
level, its framing is easily misunderstood by users who fail to anticipate the complex
intellectual work required to produce a site that is ready to share publicly.
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 9
Scalar is the creation of the Alliance for Networking and Visual Culture (ANVC) in
association with Vectors Journal and the Institute for Multimedia Literacy at the
University of Southern California. An open beta version was released in spring 2013,
and the current version, Scalar 2.0, was released in late 2015. ANVC presents their
work as “explor[ing] new forms of scholarly publishing aimed at easing the current
economic crisis faced by many university presses while also serving as a model for
media-rich digital publication,” and describes Scalar as a “key part” of this process,
facilitating collaboration and material sharing between libraries, archives, scholarly
societies and presses” (ANVC: About the Alliance n.d.). These partnerships have
resulted in one of Scalar’s most unique features: the ability to add images and videos
from organizations like the Shoah Foundation and the Internet Archive to a Scalar site
by performing a keyword search, selecting results with a checkbox, and clicking a
button to import them, along with any associated metadata. This entire process
(including the optional step of editing individual item metadata) can be performed within
the Scalar user interface. Once imported, users can select from a few different layouts
available via a dropdown menu in order to emphasize text or media, or split the
emphasis between the two (Scalar: Selecting a Page's Default View, n.d.).
The other feature that especially distinguishes Scalar from other CMSs is the
structural freedom that it grants users. Where blogging platforms like Blogger,
WordPress, and Dreamwidth structure content chronologically, Scalar has no default
organizational structure. Instead, it allows users to create pages, which can be
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 10
combined into paths, annotated, tagged, or used as tags for other content. This gives
them multiple options for creating non-linear, nested, radial, recursive, and intersecting
narratives. Configuring these choices is accomplished primarily through a Relationships
menu at the bottom of each page created, below the main text input window. The
actual, final steps of creating an organic structure through a combination of selecting
objects and dragging and dropping them within a GUI requires far fewer steps in Scalar
than it would in any other environment, and is further enhanced by the fact that Scalar
includes options to show visual representations of the structure (Path View, Tag View).
However, this structural freedom is also the aspect of Scalar that requires the most
careful advance planning from users in order to avoid producing a tangle of
disconnected, disparate files. As such, its organizational freedom is simultaneously the
feature that most complicates Scalars self-presentation of easiness.
Like Omeka, Scalar articulates its claim of easiness through a comparison to
blogging (“...if you can post to a blog, you can use Scalar”), pointing to the similarities of
the WYSIWYG interface in its text input window and those used by WordPress and
other blogging platforms. The trailer also connects itself to the activity of blogging by
emphasizing the simplicity with which authors can work with a wide range of media
types not just how easy it is to “import media directly without cutting and pasting
code” but also combining different types of media, such as “tagging poems with
videofiles or tagging images with audiofiles.” What the trailer wants to convey is that any
media type the user could imagine from images and text to maps and source code
can be juxtaposed within a Scalar book, all without requiring the book’s author to have
any knowledge of markup language. This emphasis on diverse media formats is
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 11
coupled throughout the trailer with statements about Scalar’s ability to handle quantity
not only in terms of media, but also that Scalar makes it “easy to work with multiple
authors because each author’s contributions are tracked and all versions preserved.” As
the trailer ends, the narrator reiterates that despite the wide variety of options available
(visualizations, paths, annotations, etc.), “all these objects are designed to work
together to make it easier for you to create objects to think with the thinking is still up
to you.”
As was the case with Omeka, Scalar’s claims aren’t untrue it does offer unique
functionality that simplifies and streamlines the processes of juxtaposing media and
crafting non-linear narratives; and it does so in a way that saves considerable technical
labor. In emphasizing its most innovative functionalities, however, Scalar’s framing
underemphasizes that these functionalities come with their own particular workload. The
more complex a narrative structure is, and the more material it contains, the more
important it is to have experience managing data with workflows, strict file naming
practices, and/or data dictionaries. Without such practices, or a site structure that has
been carefully determined in advance, users are more likely to end up with a tangled
mess rather than the sophisticated site that they had hoped for.
Likewise, Scalar’s documentation raises the question of what tool managers tell
users to prepare them for the work of developing site structure. Scalar’s presentation
materials focus on the ease with which Scalar can keep track of multiple users
however, this focus tends to obscure the social decision making that will almost
certainly be required; as well as the emphasis on how much freedom to show different
objects skirts around the reality that producing a good site is often a case of learning
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 12
what not to show in order to keep the narrative streamlined and compelling, rather than
simply showing a great quantity of objects.
DH Box
DHBox ( is currently in development at the CUNY
Graduate Center. As the newest of the tools that I have examined in this piece, DHBox
is an indication that easy tool rhetoric is still being used. DHBox uses containers to
create remote environments in the cloud that are already configured for several popular
and powerful DH tools, including IPython, RStudio, WordPress, and Mallet. Containers
allow programs to run in virtual environments that are identical, rather than risking the
possibility that some users’ settings and configurations will generate errors. Using pre-
configured container environments can substantially cut down on the set-up time before
students can get started actually using tools. The streamlined setup enables students to
work with complex tools like Mallet and the NLTK on their own laptops without needing
a physical computer lab, or requiring the instructor to consult or negotiate with campus
IT personnel.
DHBox makes a few prominent claims about its easiness. A brief statement
centered on its front page explains that “setting up an environment for digital humanities
computational work can be time-consuming and difficult. DH Box addresses this
problem by streamlining installation processes and providing a digital humanities
laboratory in the cloud through simple sign-in via a web browser.” The “About” page
reiterates that DHBox allows a cloud laboratory to be deployed “quickly and easily” from
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 13
any computer with an internet connection, promising a device agnostic lab ready to go
in minutes.
Though DHBox emphasizes how much easier it is to use than it is to create a lab
from scratch, it is not actually intended for beginners, as a closer look at the About page
shows. DHBox makes it simple to set up a lab if you have an internet connection and
“some contextual knowledge.” This abstract phrase gets clarified further down the
tool is intended for users who “know what the command line is” and “what a server
does.” For others, the creators recommend a list of four resources to help bring potential
users into the target audience, including a portion of the Apache HTTP Server
documentation, Shaw’s “The Command Line the Hard Way” book, lessons hosted at the
Programming Historian site, and Posner’s “How Did They Make That?.” This is a
substantial reading list, but one that should provide a novice digital humanist with a solid
grounding in the relevant concepts. Oddly enough, there is no explicit suggestion that
individuals using DHBox need to understand how the gold-standard tools it contains
work the implication is that once the virtual lab is up and running, the rest of the
progress will follow naturally.
The idea of easiness, especially in tech contexts, is often associated with support
for new and inexperienced users; however, DHBox is a reminder that the situated
nature of easiness means that it can also be intended specifically for advanced users.
The presentation materials for DHBox attempt to be direct with would-be users by
offering two benchmark questions that must be answered in order to use the tool
productively; and the creators acknowledge that users might need to learn more, rather
than simply suggesting that the tool will have excellent results for anyone and everyone.
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 14
What tool users are looking for
Tool users want the easiest experience possible, but looking at these three tools
in particular enables one to more concretely define what easiness means in the context
of DH. The emphasis on graphical user interfaces and no coding or technical knowledge
suggests a desire for as little preparation as possible particularly the desire to avoid
learning material that is purely technical and has no equivalent in their home disciplines,
such as understanding image aspect ratios or file compatibility issues. For researchers
who are already overburdened, this is an understandable rational economic choice.
Users are also looking for tools that give them the ability to fully realize their
imaginations, and to produce something new and dramatically different from what non-
DH methods allow. This output could be new because it is a highly visual digital exhibit,
or because it features non-linear narratives or juxtapositions of strikingly different media,
or because it makes it possible for an entire graduate seminar to have access to
sophisticated analytical tools like RStudio and Mallet. Users may likewise be looking for
tools that allow them to explore a particular method in depth, and achieve mastery,
especially within a given period of time, i.e., one semester-long course (Goldstone
Finally, though this is rarely made directly explicit by the tool presentations
themselves, users want stability, and to feel that any effort that they make in a tool will
be rewarded and worthwhile, rather than failing (Terras 2014a; Terras 2014b). This is
most evident in language that gestures towards the tool’s output. Sometimes this is
conveyed by promising speed (an exhibit that is one click away) and sometimes by
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 15
promising complexity. Scalar’s creators understand that “important topics require time
and sustained attention to be fully explored,” and work to convey to authors that with
Scalar, they will be able to create a Scalar book that is worthy of committed attention
from readers. While digital humanists may want to avoid spending time acquiring
extraneous knowledge, they are drawn to the field because they are willing to make an
investment but they want that investment to “provide a satisfying moment of
completion” (Brown 2009, par. 10) or move them closer to being able to declare the
project finished (Kirschenbaum 2009, par. 1).
In light of these needs, we might ask whether easiness is a quality that digital
humanities tool creators should pursue. In “Blunt Instrumentalism: On Tools and
Methods,” Dennis Tenen (2016) argues in favor of caution around easiness in DH
research, because prioritizing it often comes at the expense of understanding the critical
inner workings of analytical tools. Overreliance on out-of-the-box tools can result in
researchers confusing the tools themselves with methodologies (117), and the end
result is that the scholarship is less finely-grained and rigorous. The best kinds of tools,
according to Tenen, are “the ones we make ourselves” though he acknowledges the
formidable labor involved in producing, marketing, and maintaining such tools,
especially when working within academic contexts. Tenen characterizes a preference
for easiness as a sort of intellectual laziness or lazy thinking, when more attention to
method is warranted (118). In some cases, this critique is highly applicable; in others, it
fails to take in to account that the preference for easiness is influenced by a lack of
infrastructure and that some tools, like DH Box, are intended specifically to solve the
common infrastructure problem of a lack of physical space. Out-of-the-box tools, which
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 16
might be better characterized as “entry-level” DH tools, are arguably fulfilling a
community need. But whose role and responsibility is it to guide new users through
those tools and into the more complex understanding of methodologies that might
develop as users become more familiar with them?
How libraries fit into DH infrastructure growth
Whether identified as “digital humanities” or previous terms like “humanities
computing” or “technological humanities,” librarians and scholars have been using tools
in research contexts for a long time. The current wave of DH seems to have begun
around ten years ago, kicked off in part by the creation and release of affordable and
user-friendly tools like Omeka, as well as CHNM’s Zotero citation manager. William
Pannapacker’s 2009 pronouncement in the Chronicle of Higher Education that DH
seemed like “the first ‘next big thing’ in a long time,” was disputed by digital humanists
for whom the field was nothing new still, Pannapacker’s observation reflected the
start of a rise in DH-focused hiring. While the quantity of available new DH-focused
positions was overstated in some cases (Risam 2013), there has been demonstrable
growth in certain sectors. In 2010, there were two searches for Digital Humanities
Librarian jobs, and that number has risen steadily since, with twenty-eight job searches
for librarians or similarly titled library-based, front-facing positions (such as Digital
Scholarship Coordinator, Digital Scholarship Lead) in both 2015 and 2016 an
indication that libraries are actively working to increase their direct involvement with DH
(Morgan and Williams 2015).
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 17
As the field of digital humanities and the number of roles associated with it have
grown, various concerns and questions have arisen about how to effectively build
infrastructure and support systems that are both productive and scalable. Many of these
discussions focus on the roles that libraries and librarians play whether in supporting
DH as a service, being the driving force or an active collaborator in DH growth, or
providing much needed guidance for archiving and maintaining digital scholarly work.
As projects and tools have been created and aged and sometimes disappeared, the
larger DH community has begun to be more aware of the importance of sustainability
(Davis 2016). Furthermore, in enterprise-level software and hardware provision,
librarians have far more expertise and experience than traditional academic personnel.
However, this pressure to achieve success and provide expertise risks becoming
unsustainable for libraries themselves, while simultaneously failing to fully acknowledge
the contributions that they have made to DH growth.
There are several excellent articles and essays discussing the opportunities and
challenges that libraries face as they develop involvement and support strategies for
digital humanities and digital scholarship. In this instance, I want to focus on the
challenges that out-of-the-box, easy-to-use tools seem to have the potential to
ameliorate, if not solve completely. These include the tendency to assign librarians or
coordinators ample amounts of responsibility for creating digital humanities successes
without giving them the necessary authority to do so (Posner 2013, 47), a lack of
training opportunities (Posner 2013, 46), and a tendency to award credit for
achievements to faculty, rather than library collaborators (Posner 2013, 48). These
hurdles are further complicated by the sheer variety of requests that occur, many of
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 18
which include requests for time-consuming and non-extensible customization (Vinopal
and McCormick 2013, 28). Libraries and librarians are under pressure to produce
demonstrable results; to have learned enough from “intensive development for boutique
projects” to provide the scalable support that scholars need, often as inexpensively as
possible (Maron and Pickle 2014, 30); and to have a reproducible model that can be
clearly articulated to stakeholders, and adapted as needed over time.
Easy-to-use tools can help with many of these challenges. Because they are
branded as entry-level tools, and have documentation, they are positioned to allow
librarians to be more hands-off, relieving them of the responsibility for success. If
librarians are more hands-off, they are less likely to go uncredited for their work; and if
the tools can offer the right balance of restrictions and customization, then the library is
absolved of that burden as well.
The 2011 ARL SPEC Kit for Digital Humanities survey found that 48% of libraries
characterized their digital humanities services as offered on an “ad hoc” basis (Bryson
et. al. 2011, 23) sometimes described as a “service-and-support” model, where
projects are initiated by faculty who approach the library with ideas (Posner 2013;
Muñoz 2013). An alternate approach is the skunkworks or library incubator model (see
Muñoz 2013; Nowviskie 2013), where the library develops DH projects in which it plays
a leadership role and allows students and faculty opportunities to be involved. The ad
hoc or service-and-support model can be problematic because relatively few members
of the campus community have access to it.The skunkworks/incubator model depends
on the library having the startup expertise it needs to develop and execute good
projects that are compelling to faculty and students, and that provide them with
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 19
opportunities to develop the experience and skills that they see as useful. Even when
an incubator can successfully create opportunities that draw faculty and students in,
access can be fairly limited. Both of these models have risks in terms of sustainability
and scalability.
A third model has emerged, one that is more scalable and sustainable let’s
call it lightweight-service-and-support.This model may include one or more dedicated
personnel, i.e. a DH librarian or specifically DH programmer, but it is resource-
conservative, and cautious about providing too much one-to-one guidance that would
be unfair to other support seekers, because such guidance would not scale, and would
quickly constitute a significant/unsustainable time commitment for the librarian or team.
The lightweight-service-and-support model relies heavily on easy-to-use tools, which
offer researchers several options while still scaling well to a library’s support capacity.
The tools’ user community, documentation, and their popularity (which can result in
how-to videos and example projects) helps to lessen the amount of training,
management, and outreach that librarians need to do. This model looks very similar to
the second tier of support that Vinopal and McCormick (2013) explain how the
supported tools “should offer a fixed set of templates, so users can pick the format,
style, or functionality that best meets their needs … If services at this level are well-
designed and supported, a majority of scholars could rely on these sustainable
alternatives to one-off solutions” (32). Vandegrift and Varner likewise gesture towards
this model when they provide a concise formula for how libraries should conceptualize
their DH offerings: “the goal is to have the fewest tools to support that meet the most
needs” (2013, 71). Lightweight-service-and-support need not be the only tier of the
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 20
model as Vinopal and McCormick’s four-tiered model makes clear; however, in the
absence of resources for higher tiers to develop potentially ground-breaking and grant-
winning projects, lightweight-service-and-support can still serve a wide range of
community members.
Establishing practices and models that can help make DH in libraries sustainable
and scalable is important work that can and will help libraries continue evolving along
with scholarly disciplines. But are the practices that are scalable and sustainable for
libraries equally sustainable and scalable for the faculty and students who look to the
library for DH opportunities?
DH as scalable and nonscalable
To explain further, anthropologist Anna Lowenhaupt Tsing defines scalability as
the ability to expand without having to rethink or transform the underlying basic
elements. She examines scalability as a specific approach to design one that has
allowed for both the precision of the factory and the computer; and she argues that
scalability is so ubiquitous and powerful that it stops us from noticing the aspects of the
world that are not scalable. To push back against this suppressive impulse, Tsing’s
nonscalability theory is to allow us to see “how scalability uses articulations with
nonscalable forms, even as it denies or erases them” (Tsing 2012, 506). Scalability
prioritizes and values precision-nested fit and it is the driving force behind much of
our current infrastructure. The goals of nonscalability theory are to focus on perceiving
the heterogeneous and nonscalable forms and understand that they, too, have roles to
play in growth. At the heart of nonscalability theory is the question of how we look at,
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 21
and how we handle, the idea of diversity specifically, the diversity of objects that do
not fit within the precision-nested growth structures of scalability. Diversity, argues
Tsing, isn’t simply different it can contain the potential for transformative change.
Rawson and Muñoz (2016) adapt Tsing’s theoretical framework to unpack and
examine their work “cleaning” data in the NYPL’s “What’s On the Menu?” archive,
featuring over one hundred years of menus from restaurants, cafés, hotels, and other
dining establishments. They argue that the concept of “data cleaning” and the use of the
phrase “data cleaning” obscure the complex and heterogeneous details of the process
as well as the degree to which it is high-stakes critical work with far-reaching effects that
can impact the value of research findings. To reduce that process to “data cleaning” is
to misunderstand a highly nonscalable process as a scalable one.
Rawson and Muñoz set out to “clean” and normalize the data of different dishes
and food items within the collection. Although the NYPL had arranged the menus in the
collection to be interchangeable objects within the catalog, and although menus have a
common overall format (i.e., food items with prices, grouped according to particular
meals or particular sections of meals), each menu showed considerable variation. Some
of this variety was straightforward to normalize (e.g., fifteen variant listings for potatoes
au gratin). To clean this data would be to make it scalable to allow users to query the
entire archive of menus to understand when, where, and how potatoes au gratin
appeared, and get an accurate answer. However, as they worked to clean the data so
that it would help answer research questions about the effect of wartime food rationing
on menus or the changing boundaries of what constituted a dish over time, Rawson and
Muñoz began to understand that reducing variants to a single value was “not a self-
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 22
contained problem, but rather an issue that required returning to [their] research
questions and investigating the foods themselves.” The individual menu items’
heterogeneity was central to answering the research questions, and what was needed
was not to make each food item scalable, but instead to create a dataset that would be
compatible with the NYPL archive and illuminate (and allow users to interact with) the
nonscalable heterogeneous aspects of the menu contents.
Becoming aware of the pressures of scalability can be difficult even for
experienced digital humanists. Rawson and Muñoz explain that when they began
“cleaning” their data, they saw their main challenge and goal as “processing enough
values quickly enough to ‘get on with it’” (page). The characteristics associated with
scalability speed, simplicity, and unimpeded growth have considerable overlap
with the characteristics associated with easiness. The tools we use whether we are
their creators or their consumers are not immune to the pressure to be scalable.
Tsing’s theory of nonscalability, which Rawson and Muñoz have shown to have
considerable implications for how we conceive of our goals when working with data, is
equally relevant to both DH projects and to the infrastructure that we build for people
who are working on them. DH projects are nonscalable. This means that they are
particularly nonscalable with various out-of-the-box tools (not only Omeka and Scalar)
because as Tsing explains, scalability is the “ability to expand without distorting the
framework” (Tsing 2012, 523). Tools designed to present and process data may appear
or present themselves as though they come with that framework in place. Omeka has
items and item types with metadata categories; Scalar has pages, paths, and tags
but these components are building blocks, and a highly incomplete framework, if they
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 23
can be said to be a framework at all. And this is precisely as it should be they are
there to be distorted, or, rather, to be transformed, as researchers’ projects take shape.
When tools present themselves as easy, quick, and simple, they are promising
the user that working with them will be scalable. And when those of us who are in the
position of introducing those tools reiterate and reinforce that presentation, we are
likewise telling researchers that they should expect scalability and strive for it, despite
the fact that they are engaging in an eminently nonscalable process. We are
encouraging them to imagine the complex diversity of their material without preparing
them for the transformative process that including it will require. Instead of helping them
learn to see heterogeneity, and find effective ways of interacting with it, by training them
to expect easiness, we are leaving an empty space in their preparation and that
space is as likely as not to end up filled with a conviction of their own inadequacy. The
consequence is not only this emotional plunge. Out-of-the-box tools may successfully
circumvent technical work, but in doing so, they may also bypass the thought process of
imagining a research question and its answers beyond the constraints and affordances
of a single tool. This can impact the depth and richness of the answer to the research
question, as well as the project’s long-term sustainability. Thinking beyond the
capabilities of a particular tool can also be an opportunity for researchers to utilize their
existing disciplinary expertise in making decisions about data categories and
relationships between materials and in the process, gain much needed confidence for
future experimentation, allowing them to work with less dependence upon librarians or
other support personnel.
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 24
Possible avenues for intervention
The ways that easinessrhetoric can shape tool users’ expectations and
experiences are a challenge. This challenge intersects with a related problem, namely,
that the community of practice in DH is still grappling with how best to incorporate data
modeling in DH. A data model defines the objects or entries that a database (or really
any data presentation system, including content management systems) contains. It sets
out the rules for how different pieces of data are connected with each other. If entries
have additional data that modifies them (i.e., a data model about individuals might
include their nationality, and depending on the focus of the database, one part of the
model might specifically focus on defining how to record complexities around nationality,
such as individuals who are born in one country to parents who are citizens of another
Effectively incorporating data modeling involves articulating the questions and
complexities that accompany it in humanities contexts; and the work of disseminating
and/or training DHers to understand their work with various tools as data modeling.
Posner has previously noted that “humanists have a very different way of engaging with
evidence than most scientists or social scientists” (Posner 2015). For example, close
reading is more likely to work towards describing a specific pattern within a text and
tracing it from its start to end point. The focus of many traditional humanities scholarly
essays is identifying and elucidating one or a small number of objects which are unique.
To use Tsing here, humanities research is much more focused on illuminating and
celebrating nonscalability; thus, it is no surprise that humanists have, even within the
DH community, hesitated about invoking the idea of “data” in relation to their work.
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 25
However, organizing data is what allows researchers to produce scholarship (Posner
2015). When the Omeka documentation suggests that users should plan their site
before beginning to use the tool, they are obliquely suggesting that scholars need to
develop a data model that allows an Omeka site to be driven by a more complex
principle than “let me show you all my stuff.” Scalar users face the same challenge
perhaps even more so, since in Scalar the capacity for non-linear and intersecting paths
plus the ability to display both text and media-focused pages means that scholars could
conceivably be working with two interlocking data models: one for their narrative and
one for their non-narrative content. And this need applies to other DH tools as well
including several of the tools available through DHBox. Data modeling is not easy work
but helping students understand how it fits into the process of working with so-called
“easy” tools would be one way of preparing them better.
This example (and potential impact) of data modeling underscores that the
problems created by easy tool rhetoric cannot simply be attributed to the tool creators
and the teams that designed and wrote their publicity materials. If our libguides and
workshop promotional materials draw on the same tool presentation that emphasizes
easiness, then we are also using easiness rhetoric just as the tool makers are. Who has
the responsibility and capacity to intervene in this situation? What kind of intervention is
appropriate? While tool creators bear some responsibility, there is, in most cases, a gap
between the authors of a tool’s presentation site and the readers. Librarians who are
mentoring students and faculty who are learning new tools or who are in charge of
designing and maintaining a local infrastructure systemare positioned to fill that gap
because they are usually closer to the learners than the tool creators are. Given
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 26
humanists’ uncertainty around thinking of their materials as data (Keener 2015, par. 33),
librarians and instructors offering basic tool trainings are more likely to be successful
because they can have conversations that go both ways in consulting contexts. Our
models for DH development and support in libraries need to consider not only what
tools to provide but also how those tools’ capabilities and reputation shape
infrastructure and how we can design around the tools’ rhetoric in response.
In “On Nonscalability,” Tsing points out several examples in which scalability has
been achieved in part through a reliance on disciplined labor. One example that she
uses is that of sugar cane cutters in Puerto Rico in the 1950s. The workers had a limited
time frame in which to work, and their working conditions were crowded and dangerous
especially because of the sharp machetes that each worker used. The result was
that “workers were forced to use their full energy and attention to cut in synchrony and
avoid injury” (Tsing 2012, 512). By disciplining themselves to learn the skill of
synchronous cutting, they solved the company’s problem and transformed
themselves from nonscalable individuals into a scalable work force. Disciplined labor
can be created when any powerful entity (a factory, a corporation, or even a library)
identifies an infrastructural problem that they then leave to less powerful individuals to
solve by changing themselves in some way. The creation of disciplined labor isn’t
necessarily malicious. In the context of library infrastructure for DH tools, the problem is
the nonscalability of individual DH projects versus the scalable support that we offer in
the form of entry-level tools. Because the tools present themselves as easy to use, it is
easier for libraries (and departments) to decide that only minimal training is needed, and
that the rest can be left to the students themselves. The students become disciplined
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 27
laborers because they see DH tool facility as leading both to greater prestige and to
Even when tools make beneficial achievements in terms of what is possible, the
potential for problems exists. Scalar, Omeka, DHBox, and numerous other tools that
can be used for DH make it possible for researchers to produce scholarly objects that
would not have been possible otherwise without months or sometimes years of training.
DHBox takes three tremendous difficulties (money, space, staff), and transforms them
into a different difficulty (an individual user’s knowledge of servers and the command
line). Scalar and Omeka transform the challenge of needing knowledge around
databases, HTML, and CSS, transforming those challenges into the need for a user to
understand how to develop an effective data model. All three tools are beneficial to the
larger community of practice of digital humanities and, yet, all three can be
problematic as well, because through the combination of the way that libraries use them
in building DH infrastructure, and the way that the tools present themselves, they shift
tremendous responsibility for success directly onto the individual user and that user’s
capacity to pick up wide-ranging (and not always easily accessible) knowledge on the
fly. The resulting phenomenon is a form of what economist Jacob Hacker (2008) has
identified as “risk shift.” Hacker identifies risk shift by tracing changes in frameworks for
economic protection (including banking, income, healthcare, and retirement). Risk shift
is the phenomenon by which support provided by larger corporate and social entities
(employers, insurance companies, banks) is withdrawn, and responsibility for preventing
risks is placed on individual families. While Hacker’s research traces this phenomenon
through the larger American employment system, sociologist Tressie McMillan Cottom’s
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 28
recent book Lower Ed: The Troubling Rise of For-Profit Colleges in the New Economy
argues that the same risk shift can be seen in the higher education system as credential
costs that used to be supported by federal grants have shifted more onto students. A
certain reliance on DH tools marketed as “easy to use” creates a similar risk shift for our
students and faculty learning to use them, including librarians who are working with
limited amounts of time to pick up DH skills and experience.
There is no simple solution to the problems that can be created by easiness
rhetoric. Certainly, the answer is not that the tools featuring it are bad and that we
should stop using them. Nor is it for us to take a reverse approach and brand the tools
as ultra-challenging, suitable only for hardcore data nerds (a problematic approach that
has been an aspect of DH in the past in debates about hacking vs. yacking (Cecire
2012; Nowviskie 2016). Training and dialogue specifically focused on data modeling
throughout the community could and will be very helpful, but it will take time for that to
happen. If it does, it will be well-augmented by a more complex understanding among
DH infrastructure providers (whether in libraries, centers, or departments) of what
scalability means with regard to DH. Among other things, this more complex
understanding might involve scrutinizing what needs tools are meeting scrutinize
these needs especially through the tools’ marketing and self-presentation and
consider how those needs might shape infrastructure. One specific aspect of this might
involve looking at the differences between what tool presentation leads users to think
they need (i.e. lots of different types of media) vs. the contextual knowledge that more
experienced digital humanists know they need (including naming conventions, data
models, etc.). This doesn’t mean that libraries necessarily have to dramatically increase
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 29
their DH infrastructure investment or expend substantially more resources — if we are
alert, deliberate, and proactive, it is possible to build infrastructure that is scalable, both
for libraries, and for our users.
When researchers embarking on a digital humanities project look for the right
tool, the perceived easiness of that tool is an important consideration. Tools that can
provide an easy-to-use experience are becoming an important part of library
infrastructure for DH because they seem to require less support and labor from library
personnel involved in introducing DH methodologies to students and faculty. However,
tools branded as “easy to use” can create a backlash in which users’ research stalls and
they blame themselves when a particular tool was more difficult than they expected.
This article has sought to better understand the challenges presented by easy
tool rhetoric for DH service providers by examining the presentation and documentation
of three digital humanities tools. This examination revealed that though the tools have
made valuable contributions that substantially simplify certain technical aspects of
producing websites and multimedia objects, the rhetoric of their presentation tends to
elide the vital and challenging critical thinking that users must do while using the tools.
This elision underscores key competencies, such as data modelling, that the larger
digital humanities community is only just beginning to grapple with. Libraries have an
important role to play in helping tool users develop knowledge that will avoid the
backlash of easy tools.
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 30
[Many thanks to Yvonne Lam for invaluable conversations throughout the development
of this essay; and to Alex Gil, Yvonne Lam, Emily McGinn, Roopika Risam, and Rachel
Shaw for feedback on earlier versions.]
“Alliance for Networking Visual Culture.” n.d.
“Alliance for Networking Visual Culture » About The Alliance.” n.d.
American Historical Association. 2015. “Guidelines for the Professional Evaluation of Digital
Scholarship by Historians | AHA.” American Historical Association. June.
Brown, Susan, Patricia Clements, Isobel Grundy, Stan Ruecker, Jeffery Antoniuk, and
Sharon Balazs. 2009. “Published Yet Never Done: The Tension Between Projection and
Completion in Digital Humanities Research.Digital Humanities Quarterly 3(2).
Bryson, Tim, Miriam Posner, Alain St. Pierre, and Stewart Varner. 2011. “Digital Humanities,
(SPEC Kit 326).
Cecire, Natalia. 2012. “When Digital Humanities Was in Vogue.” Journal of Digital
Humanities 1(1).
Cohen, Dan. 2008. “Introducing Omeka.” Dan Cohen (blog), February 20.
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 31
Cottom, Tressie McMillan. 2017. Lower Ed: The Troubling Rise of For-Profit Colleges in the
New Economy. The New Press.
Davis, Robin Camille. 2016. “Die Hard: The Impossible, Absolutely Essential Task of Saving
the Web for Scholars.” Presentation, Eastern New York Association of College &
Research Libraries Meeting, May 23.
“DH Box.” n.d.
“DH Box: About.” n.d.
Goldstone, Andrew. 2016. “Teaching Quantitative Methods: What Makes It Hard (in Literary
Studies).” Pre-print (forthcoming in Debates in the Digital Humanities 2018.
Hacker, Jacob. 2008. The Great Risk Shift: The New Economic Insecurity and the Decline of
the American Dream. Oxford, New York: Oxford University Press.
Keener, Alix. 2015. “The Arrival Fallacy: Collaborative Research Relationships in the Digital
Humanities.Digital Humanities Quarterly 9(2).
Kirschenbaum, Matthew G. 2009. “Done: Finishing Projects in the Digital Humanities.
Digital Humanities Quarterly 3(2).
Maron, Nancy L., and Sarah Pickle. 2014. “Sustaining the Digital Humanities Host Institution
Support beyond the Start-Up Phase.” Ithaka S+R.
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 32
Modern Language Association. 2012. “Guidelines for Evaluating Work in Digital Humanities
and Digital MediaModern Language Association. January.
Morgan, Paige, and Helene Williams. 2016. “The Expansion and Development of DH/DS
Librarian Roles: A Preliminary Look at the Data.” Presentation, Digital Libraries
Federation Forum 2016.
Munoz, Trevor. 2013. “In Service? A Further Provocation on Digital Humanities Research in
Libraries.” dh+lib. June 19.
Nowviskie, Bethany. 2013. “Skunks in the Library: A Path to Production for Scholarly R&D.”
Journal of Library Administration 53(1): 5366. doi:10.1080/01930826.2013.756698.
———. 2016. “On the Origin of ‘Hack’ and ‘Yack.’” In Debates in the Digital Humanities,
edited by Lauren F. Kelin and Matthew K. Gold. University of Minnesota Press.
“Omeka.Net.” n.d.
“Omeka.Net: About.” n.d.
Pannapacker, William. 2009. “The MLA and the Digital Humanities.” HASTAC (blog).
December 30.
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 33
Posner, Miriam. 2013. “No Half Measures: Overcoming Common Challenges to Doing
Digital Humanities in the Library.” Journal of Library Administration 53(1): 43–52.
Posner, Miriam. 2015. “Humanities Data: A Necessary Contradiction.” Miriam Posner’s Blog.
June 25.
Presner, Todd. 2012. “How to Evaluate Digital Scholarship.” Journal of Digital Humanities
Rawson, Katie, and Trevor Muñoz. 2016. “Against Cleaning.” Curating Menus (blog), July 6.
Risam, Roopika. 2013. “Where Have All the DH Jobs Gone?” Roopika Risam (blog),
September 15.
“Scalar 1 User’s Guide: Creative Use of Structure.” n.d. Scalar 1 User’s Guide.
“Scalar 1 User’s Guide: Selecting a Page’s Default View.” n.d. Scalar 1 User’s Guide.
Shirazi, Roxanne. 2016. Conditions of (In)Visibility: Cultivating a Documentary Impulse in the
Digital Humanities. Invisible Work in the Digital Humanities Symposium. Florida State
University, November 17-18.
Tenen, Dennis. 2016. “Blunt Instrumentalism: On Tools and Methods.” In Debates in the
Digital Humanities 2016, edited by Lauren F. Klein and Matthew K. Gold. University of
Minnesota Press.
(Accepted Manuscript)
Version of Record at
CUL: Easy Tools Submission: 34
Terras, Melissa. 2014a. “A Decade in Digital Humanities.” Melissa Terras’ Blog (blog), May
———. 2014b. “Reuse of Digitised Content: Chasing an Orphan Work Through the UK’s
New Copyright Licensing Scheme.” Melissa Terras’ Blog (blog). February 4.
Timmermans, Stefan. 2016. “Introduction: Working with Leigh Star.” In Boundary Objects
and Beyond, edited by Geoffrey C. Bowker, Stefan Timmermans, Adele E. Clarke, and
Ellen Balka. Cambridge, Massachusetts: The MIT Press.
Tsing, Anna Lowenhaupt. 2012. “On Nonscalability: The Living World Is Not Amenable to
Precision-Nested Scales.” Common Knowledge 18(3): 505524.
Vandegrift, Micah, and Stewart Varner. 2013. “Evolving in Common: Creating Mutually
Supportive Relationships Between Libraries and the Digital Humanities.” Journal of
Library Administration 53(1): 6778. doi:10.1080/01930826.2013.756699
Vinopal, Jennifer, and Monica McCormick. 2013. “Supporting Digital Scholarship in
Research Libraries: Scalability and Sustainability.” Journal of Library Administration
53(1): 2742. doi:10.1080/01930826.2013.756689
... Today, the Humanities' science community is demonstrating its readiness to use the achievements of information science and new computer technologies to gain new opportunities for research. And this interest can be traced both among professional scientists and among students who are just beginning their research and want to be involved in the process of obtaining new scientific knowledge [1]. The opportunities offered by DH are increasingly attracting the attention of students that a humanities degree. ...
Conference Paper
Full-text available
Modern academic librarians strive to qualitatively meet the information needs of their users. At the same time, librarians seek to take an active part in the organization and conduct of research. In this paper, we present the successful experience of Borys Grinchenko Kyiv University (Ukraine) in working on the wiki project “Dictionary of Borys Grinchenko” which uses elements of digital humanities, citizen science and gamification. The main aim of this project is to involve university students in getting acquainted with the Dictionary of the famous Ukrainian ethnographer and ethnographer Borys Grinchenko (1863–1910). During the project, students compete among themselves who will add the most quality explanations and visualizations of the Grinchenko’s Dictionary words to the University wiki portal. The results show that this project not only promotes the development of university web resources but also promotes cultural heritage, develop successful team building, helps to the involvement of students in research activities. This experience will be useful for other academic libraries looking for ways to join the digital humanities and can be replicated in small, low-budget academic institutions.
The usability and long-term preservation of digital humanities projects, such as a digital archive or other project built around digitized materials, depend on thoughtful and thorough metadata creation. The variety of expertise required to create high-quality metadata for digital humanities projects practically requires a collaborative approach. Putting the call for collaboration into practice requires tools that are accessible and functional for all collaborators. Research on tools for metadata creation has tended to focus either on tools for librarians to manage digital project metadata or on tools for independent author metadata creation (Greenberg, 2003 Greenberg, J. (2003). Metadata generation: Processes, people and tools. Bulletin of the American Society for Information Science and Technology, 29(2), 16–19. doi:10.1002/bult.269[Crossref] , [Google Scholar]; Crystal & Greenberg, 2005 Crystal, A., & Greenberg, J. (2005). Usability of a metadata creation application for resource authors. Library & Information Science Research, 27(2), 177–189. doi:10.1016/j.lisr.2005.01.012[Crossref], [Web of Science ®] , [Google Scholar]). The literature has also tended to focus solely on the use of spreadsheets for metadata creation. Lincoln (2018 Lincoln, M. D. (2018). Best practices for using Google sheets in your data project. [Blog post]. Retrieved from [Google Scholar]) has discussed best practices for Google Sheets in archival metadata entry, and Broman and Woo (2017 Broman, K. W., & Woo, K. H. (2017). Data organization in spreadsheets. Peer J Preprints, 5, e3183v1. 10.7287/peerj.preprints.3183v1.[Crossref] , [Google Scholar]) have discussed best practices for spreadsheet data entry in general. This article positions tool selection and configuration as site of collaboration for the creation of digital project metadata through its examination of a Google Forms-based workflow for the creation and organization of metadata.
Productive, equitable, and reciprocal librarian-faculty partnerships are difficult to establish for a range of reasons. This case study describes a long-term collaboration between a Digital Humanities librarian and a History professor. We trace our two-year partnership from inception and test-run in a small undergraduate seminar to a scaled-up and carefully-designed DH intervention for visualizing spatial and temporal historical arguments in a course with three-times the students. The article chronicles our process and analyzes the data from the assessment model we designed for reflecting on the efficacy of the intervention and the success of the partnership. Our collaborative model suggests the value of a partnership built over time, based on shared pedagogical values (in this case, student learning outcome-driven pedagogy and scaffolded instruction) and transparent labor practices.
Full-text available
The paper reviews the meaning and development of digital humanities giving the examples of work published in various DH areas. The paper discusses what using these technologies means for the humanities, giving recommendations that can be useful across the sector. This is the paper published from Melissa Terras' professorial lecture at University College London.
Full-text available
The case of the Orlando Project offers a useful interrogation of concepts like completion and finality, as they emerge in the arena of electronic publication. The idea of "doneness" circulates discursively within a complex and evolving scholarly ecology where new modes of digital publication are changing our conceptions of textuality, at the same time that models of publication, funding, and archiving are rapidly changing. Within this ecology, it is instrumental and indeed valuable to consider particular tasks and stages done, even as the capacities of digital media push against a sense of finality. However, careful interrogation of aims and ends is required to think through the relation of a digital project to completion, whether modular, provisional, or of the project as a whole.
As discussion and debates on the digital humanities continue among scholars, so too does discussion about how academic libraries can and should support this scholarship. Through interviews with digital humanities scholars and academic librarians within the Center for Institutional Cooperation, this study aims to explore some points of common perspective and underlying tensions in research relationships. Qualitative interviews revealed that, while both groups are enthusiastic about the future of faculty-librarian collaboration on digital scholarship, there remain certain tensions about the role of the library and the librarian. Scholars appreciate the specialized expertise of librarians, especially in metadata and special collections, but they can take a more active stance in utilizing current library resources or vocalizing their needs for other resources. This expertise and these services can be leveraged to make the library an active and equal partner in research. Additionally, libraries should address internal issues, such as training and re-skilling librarians as necessary; better-coordinated outreach to academic departments is also needed.
Because computers zoom across magnifications, it is easy to conclude that both knowledge and things exist by nature in precision-nested scales. The technical term is “scalable,” the ability to expand without distorting the framework. But it takes hard work to make knowledge and things scalable, and this article shows that ignoring nonscalable effects is a bad idea. People stumbled on scalable projects through the same historical contingencies that such projects set out to deny. They cobbled together ways to make things and data self-contained and static, and thus amenable to expansion. In European New World plantations, the natives were wiped out; coerced and alienated plants and workers came to substitute for them. Profits were made because extermination and slavery could be discounted from the books. Such historically indeterminate encounters formed models for later projects of scalability. This essay explores scalability projects from the perspective of an emergent “nonscalability theory” that pays attention to the mounting pile of ruins that scalability leaves behind. The article concludes that, if the world is still diverse and dynamic, it is because scalability never fulfills its own promises.
While much work on libraries and digital humanities has focused on how to train and encourage individual librarians, we have not paid enough attention to the administrative and institutional factors required to help these professionals succeed. This article outlines some common sources of frustration for library professionals engaged in digital humanities work and offers sketches of some library-based digital humanities programs that are working to address these challenges.
Library-based digital humanities “skunkworks” are semi-independent research-and-development labs staffed with librarians who act as scholar-practitioners. Their creation is an uncommon, yet uncommonly potent, organizational response to opportunities opened up by digital scholarship. This article describes the Scholars’ Lab at the University of Virginia Library and asserts a critical role for library-embedded digital centers in forging new paths for knowledge work in the humanities.
New York University Libraries and our partners in Information Technology Services offer effective enterprise-wide technology solutions for many academic practices, but we are still working to solve the “faculty Web site problem”—providing services for digital scholarship and publishing in a way that is both scalable and sustainable. This article describes our study of NYU scholars’ needs and digital scholarship support at other research institutions, and then introduces a service model we developed for supporting such services (which may include digitization, hosting of research data, digital publishing, the development of software for scholarly practices, and more). We then discuss the challenges to research libraries of implementing our service model in a scalable, sustainable way, by addressing project and tool selection, staffing, and organizational change.
Libraries and the humanities have always had a great deal in common. Each in their own way, they are tasked with collecting, organizing and preserving our shared, collective memory. They help us remember the past, understand the present and build the future. They are also both experiencing an extremely challenging historical moment where external critics are questioning their value. Libraries are constantly plagued by doubts about their continued relevance (DelGuidice, 2012) and gloomy assessments about the death of the humanities (Fish, 2008) are equally common. One could get the impression that both are shushing and critically-theorizing themselves down the drain hole.
America's leaders say the economy is strong and getting stronger. But the safety net that once protected us is fast unraveling. With retirement plans in growing jeopardy while health coverage erodes, more and more economic risk is shifting from government and business onto the fragile shoulders of the American family. In The Great Risk Shift , Jacob S. Hacker lays bare this unsettling new economic climate, showing how it has come about, what it is doing to our families, and how we can fight back. Behind this shift, he contends, is the Personal Responsibility Crusade, eagerly embraced by corporate leaders and Republican politicians who speak of a nirvana of economic empowerment, an "ownership society" in which Americans are free to choose. But as Hacker reveals, the result has been quite different: a harsh new world of economic insecurity, in which far too many Americans are free to lose. The book documents how two great pillars of economic security--the family and the workplace--guarantee far less financial stability than they once did. The final leg of economic support--the public and private benefits that workers and families get when economic disaster strikes--has dangerously eroded as political leaders and corporations increasingly cut back protections of our health care, our income security, and our retirement pensions. Blending powerful human stories, big-picture analysis, and compelling ideas for reform, this remarkable volume will hit a nerve, serving as a rallying point in the vital struggle for economic security in an increasingly uncertain world.