By Olivia Wikle and Evan Peter Williamson
Static Web Methodology as a Sustainable Approach to Digital Humanities Projects
The short- and long-term costs of the web platforms adopted for digital humanities (DH) projects extend far beyond the financial: when we choose a digital platform we are also making decisions about how to invest and deploy our time as well as technical and social resources in the digital projects we create and maintain (Barats et al., 2020). The friction between the institutional, technical, and social infrastructures in which we make choices about our digital projects has too often led to unsustainable projects and practices in DH work. Many advocates of a more sustainable approach to DH (including the participants in the DH 2022 panel on “Sustainability + the Politics of DH Infrastructure” which inspired this short paper [Footnote 1]) have noted the opportunity cost of investing in systems over people: As DH practitioners, the time (or money paid to contractors) we must invest in managing servers, maintaining platform updates, and learning idiosyncratic administrative systems ultimately limits our ability to create and sustain unique, innovative projects. In response, many librarians and DH practitioners have been reexamining platforms through a minimal computing lens, asking, as Risam and Gil have summarized, “what is, in fact, necessary and sufficient when developing a digital humanities project under constraint”, a methodological inquiry that leads “a decision-making process driven by the local contexts in which scholarship is being created” [1] (Risam and Gil, 2022).
This reflection in our own context has led librarians at the University of Idaho to pursue new project-development methods that minimize digital infrastructure as a means to maximize investment in people, while growing agency, agility, and long-term sustainability in both the institution and our digital outputs. For nearly a decade, we have been developing digital collections, scholarship projects, and instructional content using static web tools, leading to our development and support of the digital collection framework CollectionBuilder. Building on CollectionBuilder, we have remixed template components and techniques to create custom projects such as oral history exhibits, deep maps, and digital editions, which we present below. This development approach, centered around minimal static web templates driven by tabular data, which we call Lib-Static, seeks to increase the return on learning new technical skills that all digital projects require, while also establishing technical solutions and social workflows that more closely match the structure of academic work cycles and DH project needs. In particular, the static web approach encourages the creation of preservation-ready project data, enables periods of iterative development, and capitalizes on the low-cost/low-maintenance characteristics of statically-generated sites to optimize limited economic resources and personnel time. This short paper will introduce the Lib-Static development methodology as a provocation to rethink DH infrastructure choices, asking how our frameworks can build internal skills, collaboration, and empowerment to generate more sustainable digital projects.
The Challenges of DH Infrastructure
Working within the realities of academic funding and project planning, DH practitioners often still assume that traditional large-scale infrastructure is a necessity, which can result in huge sums sunk into outsourced development, contract work, and 3rd party subscriptions. This reflects an economic model that prioritizes purchasing systems over internal development of people and capacity. However, we (DH researchers and publishers) need to work with and maintain these systems, which can drain our time and reduce our agility and creativity, as well as lock us into unsustainable long-term commitments. Beyond the missed opportunities to focus our time more productively, on the practical side the lack of human resources to continuously maintain needy digital infrastructure can result in dead links, half functioning websites, and lost data–the strikingly rapid loss of investment poured into the project.
For example, we often want to teach creating a digital archive in the classroom, giving students the full experience of publishing their curation, description, and interpretation of archival objects on the web. However, even in setting up a fairly low barrier platform for this use case such as Omeka, we are adopting (as they say) a puppy that requires constant ongoing maintenance and attention [2] (Dombrowski, 2019). This requires us to either invest significant time in being system administrators, pay a subscription to a 3rd party to do it, or have a clear sunset date to close down the site–each of which requires the correct resources and can have serious drawbacks. Will the students be able to reference the outputs of their project? Will their work remain an accessible resource? How will the librarians facilitating the project have to invest their time?
All DH platforms demand investment in learning (no matter how slick the system)–how can we make the most of that investment to build resilient capacity in our organizations and the DH community? At University of Idaho Library, balancing these questions has led to the development of a minimal, static web-based approach to creating digital scholarship projects and teaching DH in the classroom, that enables librarians to efficiently collaborate with faculty and students while centering sustainable systems, workflows, and data.
Static Web Opportunities
Most of the web today is built using dynamic web applications, such as content management systems like WordPress or Drupal, which use server-side processing and databases to respond to user requests and manage data. Likewise these types of CMS or repository systems are chosen to build most DH projects because of the powerful web-based features they provide such as administrative interfaces, user management, and theming–think Scalar, Omeka, StoryMaps, or Samvera. These platforms enact a distinct division between IT maintainers/administrators, system designers, UX designers, and project/content creators, allowing any part of the equation to be outsourced. These applications come with heavy infrastructure requirements and ongoing maintenance costs–they require well resourced servers to provide adequate performance and continuous vigilant updating to avoid serious security risks. Any customizations to the platform add complexity to the maintenance.
In contrast to dynamic platforms, static websites are composed of plain HTML, CSS, JS, and media files ready to be delivered to users without any server-side processing or database. This simplicity provides high performance for users, minimal infrastructure requirements for IT, and lower barriers for developers. It uses less bandwidth, less energy, and fewer server resources–which ultimately means less cost for creators, maintainers, and end users. Modern approaches are powered by static site generators that utilize simplified markup, plain text data files, and web APIs to simplify the creation of site content and automate building complete websites ready to deploy.
Static web approaches have some unique benefits that have the potential to make DH projects more sustainable. First, because static assets do not require any server-side processing, they can be deployed on minimal servers (or free hosting services), significantly lowering cost and ongoing maintenance, while providing higher performance and scalability without further investment. This matches the reality of academic DH projects, which often involve lots of work during an initial active period and then are usually left with few if any resources for ongoing maintenance, so project websites need to be okay being left alone for long periods of time. Static sites are suited to this type of neglect, avoiding the security risks and increasing breakage associated with insufficiently maintained dynamic platforms.
With no additional software to administer on the server, static sites’ comparatively simple workflows and security reduce the need for system administrators, making it possible for DH practitioners to take complete control of the development and hosting process. This gives us a concrete opportunity to learn and build on basic web development and programming skills as we collaborate on a project, which can lead to more creative solutions and use of the platforms we are working with–and build additional capacity to power future projects. This helps acknowledge and remove the division of technical labor and “scholarly” contributions, as Chan and Sayers argue, “from the labor perspective, a minimal computing project positions technical work as creative and critical work beyond familiarity with management systems” [3] (Chan and Sayers, 2022). The low cost of this approach also makes the development process more agile and inclusive: we can iterate through project stages with less up front investment, quickly prototyping ideas (or changing course without too much loss if an idea doesn’t pan out) and building out smaller projects. This opens up opportunities to collaborate with more people, contexts, and use cases, including those without significant funding support. In practice, this can mean more people involved directly in development and the creation of projects that were previously impossible–student projects, classroom experiences, one off exhibits, or community led collaborations–while empowering more people with the skills necessary to sustain these resources.
Finally, an essential benefit is the creation of preservation-ready data as a byproduct of project creation. Static web projects are built on structured plain text data and code in open standard formats–the content and data are not locked into a platform, but are prepared for preservation, migration, and reuse in the inevitable future with a new platform or new project.
Lib-Static in Practice
At the University of Idaho Library we have been building static web-based projects as the core of our digital scholarship practice, many of which are rooted in the CollectionBuilder code framework. Below we present a few examples that we hope help illuminate why we have made this choice, highlighting some of the things we think the static approach has enabled while supporting more sustainable collaborations and digital outputs.
Most of this work takes place in our DH center, the Center for Digital Inquiry and Learning (CDIL), led by librarians with faculty and student collaborators. The library and CDIL do not have dedicated IT personnel. Prototype project sites are typically hosted on GitHub Pages or our self-managed Reclaim hosting. Final published versions are manually built and deployed to basic static site hosting provided by our main university IT.
The chart below demonstrates our typical workflow, technical infrastructure, and collaborator involvement for a static web project:
Project Workflow | Description of Work | People Involved |
---|---|---|
Curation, Digitization, and Metadata ↓ |
Scholarship work focuses on curating data, digitizing objects, and creating quality descriptive metadata. | Librarians consult with collaborators (students and/or faculty) to envision site features and iteratively develop metadata templates that will support the site’s design. Collaborators focus on creating metadata in spreadsheets and curating their items. |
CollectionBuilder Project ↓ |
Prepared metadata CSV and digital media files are added to a CollectionBuilder code template. The template defaults are replaced by project configurations. Project code is edited in a text editor such as Visual Studio Code, and stored in GitHub. | Librarians set up the project and work on code customizations to support new feature ideas. Collaborators focus on contributing the site’s content using Markdown and metadata spreadsheets. |
Static Site Generator ↓ |
The static site generator Jekyll knits together the source code in the CollectionBuilder template to output a static site. There is no admin interface or log in! Jekyll is run on a local computer or via a hosting service such as GitHub Pages. | During iterative prototyping phases, the site is generally built on GitHub Pages to enable collaborators to see their changes to metadata or site content quickly. Final deployment is handled by librarians, building the site with Jekyll and moving it to the library’s server. |
Static Website | Final site is HTML, CSS, JS, and media files ready to be hosted on any basic server or hosting service. | Librarians maintain the static sites for the long term. Librarians package the complete data and media files for archival storage preservation. |
Digital Collections → Research, Analysis, Access
We first started working on a static web approach in pursuit of a more sustainable method to create and maintain our library’s digital collections. At first we redesigned and migrated a handful of sites that had aging / broken features or deserved more specialized presentation. Before too long, we were rebuilding all our digital collections using a shared template, enabling us to balance customized browsing features and interpretive content with a sustainable workflow. The work on this template eventually grew into the CollectionBuilder project, an open source framework for creating digital exhibits powered by static web methodology. Our skills also grew with the project, enabling us to create more features and unique collections along the way, opening up access to more materials and content–but also enabling us to include more collaborators, opening up our collections to more people creating unique interpretive writing and exhibits.
Digital collections are made up of a few distinct chunks of data: the digital media files, metadata describing the items, and interpretive content. Once separated out from a specific platform, this data is easier to work with and update using standard tools, and becomes a preservation-ready package, a digital archive ready to be plugged into any access framework. This separation also makes convenient divisions for collaboration–curating and digitizing objects, describing items in spreadsheets, writing about the context in Markdown files, and developing website features. In practice, faculty and graduate students often collect and curate archival content during their research process (often in collaboration with librarians and archivists). With just a folder of files and a spreadsheet, we are able to generate digital collection websites to explore and publish these materials. For students, seeing their items as data and as a digital archive can become an iterative aspect of the research and analysis. Their work will prepare access and publishing, while also creating new means of exploring and answering research questions. These types of iterative and exploratory collections were not possible when our infrastructure was tied to a more rigid traditional asset management system.
For example, one of our earliest static web collaborations was on the Historical Japanese Ceramic Comparative Collection with archeology graduate student Renae Campbell. Together, we were able to transform her thesis research into an interactive website with new ways to visualize the information, increasing the impact and access to her research. The work was completed during a summer fellowship, with Campbell’s focus on spreadsheet data and ideas for presentation, and librarians’ focus on creating the site. Campbell is able to contribute periodic updates with new items and metadata corrections (which only require working with a spreadsheet), but no ongoing maintenance is required.
Likewise, CTRL+SHIFT started as a collection of interviews of contemporary American poets conducted by librarian Devin Becker. In building a website for public access, Becker’s graduate research assistants created new metadata (tagging the interview transcripts) and imagined new features for the website, which in turn became a means of interrogating the collection, exploring new ways to understand and discover. The flexibility of the platform enabled publishing these evolving interpretive threads by remixing the data and the recipes of display, without needing to rebuild the infrastructure.
Creative nonfiction writing student Isabel Marlens was exploring archival materials about historical wildfires in Idaho, curating items that informed the project Fire Lines. During her research, she encountered records of the timber protective associations which contain fascinating historic data and perspectives that informed fire policy in America. As a byproduct of her research process, others are also now able to explore these resources alongside her published interpretive essay. These small collections, responsive to researchers interests and needs, are uniquely enabled by the minimal digital collection template approach.
Static Web for Digital Scholarship
Applying the static web approach to our digital scholarship projects has allowed for sustainable publishing: we’re able to develop unique projects and keep them up for the long-term without major maintenance responsibilities. Preservation-ready data is prepared as part of the workflow, integrating stewardship of unique materials into our practice. It has also increased options for us to be creative, as we learn more about the technology we’re using and remix our template recipes to create unique features and explore new ideas. And it is continuously expanding the ways we collaborate, from embarking on initiatives to migrate old projects to teaching collaborators how to contribute content to spreadsheets or GitHub repositories.
One example of this is Storying Extinction, a multidisciplinary digital project which maps and documents the extinction of caribou from Idaho. Graduate students on this project collected interviews and videos, created spreadsheets of data, and sketched ideas for web functionality. Librarian Devin Becker, building from a CollectionBuilder template, remixed map features to develop a highly customized site enacting the collaborators’ concept of a “deep map” presenting multiple paths to explore and understand the collected videos, interviews, and interpretive content. This involved combining a typical CollectionBuilder item page with the Leaflet.js powered map layout, using the “flyTo” function to animate movement across the landscape. The same collaborators built on this experience and template to develop Keeping Watch, a geospatial narrative mapping project documenting the fire towers of Idaho.
Another example is the Letters of Marie Mancini project, which provides access to long hidden letters of 17th-century noblewoman Marie Mancini. Faculty and student collaborators transcribed, translated, annotated, and encoded the letters in TEI, which freed librarian Olivia Wikle to develop a custom site to transform and visualize that data for engaging public access. Starting from a base CollectionBuilder template, adding approaches from the Wax static framework, and remixing a variety of other code recipes, the project represents the flexibility a static approach enables. Wikle wrote Rake tasks (Ruby scripts integrated into the project) that are able to transform the project’s plaintext data into website features presenting the letters’ transcriptions and translations in multiple languages, and to view patterns across them via maps and timelines.
Teaching with Static Web
When it comes to teaching, we’ve been able to use static web development to create lasting digital artifacts, without adding long-term system maintenance to classroom prep. This approach frees us up to teach students basic digital and data literacy skills (using formulas in spreadsheets, writing for the web using markdown, creating a commit on GitHub) that they’ll likely put to use in their future careers, while we remix templates to create OER resources that fit the unique classroom context. Librarian Evan Williamson even created a digital collection with a 2nd grade class in this way, using paper forms to collect metadata about students’ favorite classroom books.
In 2022, we worked with faculty and librarian collaborators on an NEH-funded initiative called Learn-Static to explore and create resources for teaching with static web tools. These include documentation for getting started with GitHub, managing data in spreadsheets, and writing in Markdown and HTML, as well as example lesson plans that demonstrate how these various skills can be incorporated into the classroom as part of a larger DH project (such as building a digital collection or coding oral histories). Librarians and instructors worked together to develop project templates, assessments, and resources that were then used and refined in the classroom. In this context, the static web approach facilitated collaboration between instructors, the creation of reusable open educational resources, and the teaching of more fundamental digital literacies integrated into domain-appropriate projects. For example, Digital Exhibit Lab started as a customized version of CollectionBuilder designed for a classroom project creating a shared digital collection. To enable students to iteratively test and debug their own metadata spreadsheets (without breaking the live site), the code uses PapaParse to load a published Google Sheet on the fly. Students get instant feedback on their work, allowing active prototyping where they can see the impacts of metadata refinements in real time. This functionality was further developed into the CollectionBuilder-Sheets template.
Conclusion
Overall, our experience has been that a static web methodology has opened up a more agile and sustainable approach to our digital initiatives, while growing internal skills, collaboration, and empowerment. The creation of well-structured and well-described data as part of the project process ensures our role in stewardship and preservation of unique materials and research, while the flexibility of static templates has increased our creativity. Likewise, the ease of iterative development and prototyping has enabled new opportunities that were previously prohibitively costly. By minimizing infrastructure costs and commitments, we have been able to invest time in growing our internal capacity for deep collaboration, creative thinking, and sustainable project management. While a minimal computing static web methodology is not optimal for all situations, recent work informed by this approach demonstrates that it is a viable and powerful option when holistically balancing the costs of the institutional, technical, and social infrastructures that can sustain innovative DH scholarship.
Footnotes
[1] “Panel 1-01: Sustainability + the Politics of DH Infrastructure”, ADHO DH2022, July 2022, https://dh2022.dhii.asia/dh2022bookofabsts.pdf
References
Barats, C., Schafer, V., and Fickers, A. (2020). Fading Away… The Challenge of Sustainability in Digital Studies. Digital Humanities Quarterly, 14(3). https://www.digitalhumanities.org/dhq/vol/14/3/000484/000484.html.
[3] Chan, T., and Sayers, J. (2022). Minimal Computing from the Labor Perspective. Digital Humanities Quarterly, 16(2). http://digitalhumanities.org/dhq/vol/16/2/000600/000600.html.
[2] Dombrowski, Q. (2019). Sorry for All the Drupal: Reflections on the 3rd Anniversary of ‘Drupal for Humanists.’ Quinn Dombrowski, published November 8 2019, https://quinndombrowski.com/blog/2019/11/08/sorry-all-drupal-reflections-3rd-anniversary-drupal-humanists/.
Drucker, J. (2021). Sustainability and Complexity: Knowledge and Authority in the Digital Humanities. Digital Scholarship in the Humanities, 36 supp_2: ii86–ii94. https://doi.org/10.1093/llc/fqab025.
Gil, A. (2018). Design for Diversity: The Case of Ed. The Design for Diversity Learning Toolkit. https://des4div.library.northeastern.edu/design-for-diversity-the-case-of-ed-alex-gil/.
Gil, A. (2015). The User, the Learner and the Machines We Make. Minimal Computing. https://go-dh.github.io/mincomp/thoughts/2015/05/21/user-vs-learner/.
[1] Risam, R., and Gil, A. (2022). Introduction: The Questions of Minimal Computing. Digital Humanities Quarterly 16(2). http://digitalhumanities.org/dhq/vol/16/2/000646/000646.html.
About the Authors
Olivia Wikle is the Head of Digital Scholarship and Initiatives at Iowa State University, where she collaborates on projects involving digital scholarship, digital collections, and the institutional repository. She is a co-developer of the CollectionBuilder static web framework, and her research interests include sustainability in digital libraries and digital literacy instruction.
Evan Peter Williamson is the Head of Digital Scholarship and Open Strategies (and Digital Infrastructure Librarian) at the University of Idaho Library, working with the Center for Digital Inquiry and Learning to bring cool projects, enlightening workshops, and innovative services to life. Despite a background in Art History, Classical Studies, and Archives, he always manages to get involved in all things digital–especially websites, digitization, and digital preservation. His recent focus has been on data driven, minimal infrastructure web development, currently embodied in the CollectionBuilder project.
Subscribe to comments: For this article | For all articles
Leave a Reply