Operationalizing Minimal Computing Values Through Shared Computing-Platform Development: A Case Study of DigitalArc and Opaque Publisher

In Brief: This article explores how minimal computing principles guided the parallel web development of two related but distinct publishing platforms, DigitalArc and Opaque Publisher.  DigitalArc, a community-driven digital archive and exhibit platform, was developed in response to principles governing post-custodial archiving, taking it one step further to ensure communities maintain ownership of their materials and their digital artifacts. The Opaque Publisher, originally developed in support of a born-digital dissertation, adapts DigitalArc to support refusal theory for scholars who have to negotiate the tensions between using unethically obtained evidence in support of their research with moral objections to a lack of informed consent. At first glance, the use cases for each platform seem different, but both are providing mechanisms for individuals-by-proxy and communities to assert control over how their respective stories are shared.

By Kalani Craig, Michelle Dalmau and Sean Purcell

This article details the conversations, dependencies and contingencies that developed as our team simultaneously built two related, but distinct academic publishing platforms and considered the theoretical motivations for having done so. The first of these, DigitalArc (DA), was designed to support the creation of low-cost sustainable digital exhibits and archives built by and for communities who want to control how their histories are presented online. DA was designed as a community-driven digital archive and exhibit platform, ensuring communities maintain ownership of their materials and their digital artifacts.¹ The second, the Opaque Publisher (OP), used DigitalArc as a foundation for a digital-exhibit and digital-publication platform that supports scholars who want to redact or remove information that was obtained from medical patients without their informed consent. The modeling and development of both platforms were guided by complementary frameworks that shaped our decision to use DigitalArc as the technical foundation for the Opaque Publisher (Zenzaro, 2024; Ciula et al., 2018).

In “The Digital Opaque: Refusing the Biomedical Object” (Purcell, Craig & Dalmau, 2025), we outlined our adoption of refusal theory in the rejection of unquestioned institutional norms around the use and display of unethically obtained medical specimens. This theoretical framework was operationalized in the OP as an author-audience interaction that allows authors to identify sensitive information in both the text of, and images included in, an academic publication. Readers are then given the ability to control how and whether that sensitive information is redacted fully or partially, or displayed openly, with the default view set to “partially opaque,” serving as a compromise between fully redacted and fully open. 

Here, we outline a history of technical interventions that supported ethical creation and interpretation of sensitive content through the iterative implementation of two publishing platforms. Core to both platforms were ethical-research considerations and public-communication audiences, which in turn drove the adoption of minimal computing approaches. We hope that, by focusing on the audience needs we identified for the two projects, the existing models we assessed for the OP’s parent framework, and some of the serendipitous contingencies that shaped the minimal-computing development of both platforms, we can offer some lessons for other digital-humanities development teams seeking to operationalize their theoretical frameworks in the form of technical choices. 

DigitalArc: A Community Digital Archive Platform 

In Fall of 2018, our team began to assess options for a spring 2019 course centered around the creation of a public-history archive as the main classroom activity. As the instructor, Craig initially asked for consulting advice about potential archiving platforms from Dalmau and other members of the team at the Institute for Digital Arts and Humanities, and from Dalmau and members of her digital-libraries team. Using their advice, along with obstacles that arose with our own institution supporting digital projects, Craig began to assess the potential for Github Pages as a publishing platform.

In Fall of 2018, our team began to assess options for a spring 2019 course centered around the creation of a public history archive as the main classroom activity. Our audience was twofold: first-year undergraduates with little to no research experience in history or technical experience in digital humanities, and the public audiences who would be engaging with the digital collection and historical essays those first-year students would develop as a part of their class. Models for this sort of endeavor existed in spades, most of which focused on the simplicity of content creation for content creators with minimal technical skill. Content management systems (CMS) allow these users to interact with a graphical user interface (GUI) and engage in button-pushing and form-filling behaviors that build multi-media experiences palatable to public audiences, with integrated display for photos, videos, audio, and text (Russel & Merinda, 2017). From Google Sites and WordPress in the corporate freemium sphere to Drupal and Omeka, open-source platforms commonly used in academic contexts, many of these content management systems modeled the use of a programming language (often PHP) supported by a back-end database (often MySQL) that served on-demand pages built “on the fly” as a reader requested each page on the web site. Our institutional support was rich for Omeka in particular, and we appreciated Omeka’s focus on non-profit academic public engagement. However, acquiring, critiquing, and applying digital literacies are key outcomes for the course, and we were able to hone these literacies, with the built-in support structure offered by the class, by exploring a more transparent code base offered by static sites (Wikle, Williamson and Becker, 2020).

As with many technical projects, however, serendipity wrinkled the fabric of our plan: that same semester, university IT rolled out a required upgrade to PHP on the servers that were available for hosting that, in turn, prompted a systemwide Omeka upgrade. This IT-driven upgrade represented, on the one hand, a very well-provisioned IT environment that could support database-driven CMS support for many sites, and on the other, a very clear division between that institution’s IT’s environment-building responsibility and researchers’ site-creation and maintenance responsibilities. Dozens of sites needed upgrades in order to remain accessible for public view, and in many cases, the creators of those sites were not equipped to handle such upgrades. That semester, Omeka served as both a model for what worked exceptionally well for novice creators in the site-building phase, and as a warning for the errors our students, and our public audiences, might expect to see in the site’s long-term post-project maintenance.

The experience pushed us away from big tech into the realm of “minimal computing,” an approach that responds to the tension between the often-limited resources and needs of a community of practitioners–which can include individual partners with institutional affiliation–with limited resources. The shift in focus to this tension between need and resource availability has as its main effect the need to consider how and why we’re using the technologies in the first place. Roopika Risam and Alex Gil anchor the minimal-computing movement’s motivation in “a very real fear” of big tech’s ideologies of fast growth at all costs, disruption over stability, and expense over access. Such ideologies continue to exclude communities whose “voices and stories…have been elided” in the cultural record, this time in a digital space instead of in physical collections (Gil and Risam, 2022). By contrast, minimal-computing best practices offered a framework that helped us evaluate these early-stage classroom priorities by asking what we had, what we needed, and what we wanted to prioritize. We had a team capable of managing almost any technical environment. We needed to reduce or eradicate long-term institutional dependencies and create an archive without longer-term sustainability concerns that Omeka and WordPress presented in the immediate institutional context. We wanted to prioritize short-term labor and development over a need for students or us to handle the long-term maintenance that Omeka and WordPress presented. As we further developed DigitalArc in the years that followed, this tension between resource limitation and need, then, led us to consider moving much of the maintenance complexity of the technology and the labor onto our institutional team, through development and documentation, in order to shift the expense of technology away from anyone who might be interested in using our platform later on.

Minimal computing’s emphasis on smaller-scale projects, with initial labor investment by technical experts that result in lower barriers to long-term technical maintenance and much lower cost, is also informed by a resistance against a “maximal” digital humanities, which leans on a combination of well-provisioned institutional support and the structural exigencies that require researchers to respond quickly to a limited set of choices when that institutional support changes. When these maximal computing tendencies are transferred from well-resourced IT environments and institutional support for long-term maintenance into other settings, the changed institutional pressures in turn create institution-specific site-creation and sustainability concerns that vary greatly from context to context (Miya & Rockwell, 2025).

The contingencies we faced, even in an IT-rich environment, helped guide us as we considered how to de-institutionalize both the minimal-computing and maximal-computing  platforms to which we had access. We anticipated that implementers of a minimal-computing platform would need methodical yet easy-to-step through documentation, to scaffold what they might initially see as a less  “user-friendly” interface. In this case, to achieve a minimal codebase in support of ongoing sustainability, we rely on substantive documentation. Herein lies one of several counter-intuitive responses to minimal computing. Despite these contradictions, our choices were intended to allow more agency for communities and scholars, giving both our developer team and our audiences a better handle on both the short-term and long-term “considerations of the costs, limits, or wisdom of scale” (Walsh 2024).

In Spring of 2019, our classroom began using the first version of a minimal-computing digital-exhibit template that would become DigitalArc many years later. The feature set included in this student-built version of the platform was partially inspired by Omeka’s academic focus on discovery and presentation based on well-formed metadata and its ability to support meaningful interactions with multimedia objects. We also took cues from the many CMSs that developed on WordPress’s model of simple authoring for novice creators, and cues from colleagues in digital humanities whose research on minimal computing suggested that the back-end design and documentation requires a heavier lift up front, but easier ongoing and longer term management over time (Wingo & Anderson, 2025). We also took steps to narrate the parallels between CMSs like WordPress or Weebly and the features that Github’s GUI editing pages offered, as a bridge to help build student confidence that Github Pages could come quite close to the ease point-and-click editing with minimal training time for them.

The tech stack that supported this initial minimal-computing approach was centered around Jekyll, a static-site generator that takes a different approach to the design and publishing of sites than Omeka and WordPress’ dynamic pages (on-request PHP-and-database generated pages).² In this model, pages are built when creators make edits, rather than being built when a public viewer requests the page; if something went wrong with an edit, or with part of the tech stack, the implementers would have a greater chance of noticing and fixing the problem before the viewers would encounter an interruption to the site. As with Omeka and WordPress, Jekyll lets us design and implement headers, footers, and page templates that would apply to any of the content generated by students. As with other CMSs, we set up customization of fonts, colors, navigation elements, and other basic design. We later added support for custom metadata and navigation labels, which was intended to support both multilingual audiences and communities’ preferred vocabulary.

Our one compromise with the world of “maximal” computing, which we will address more fully below, was to host our Jekyll site on Github. From a teaching perspective, Github’s free user-account option and focus on collaborative editing made it easier for students to collaboratively access Github during class. From a site-editing perspective, Github’s Pages feature automatically added the template features we built to any of the simpler “markdown” files. Creators authored these markdown files, which focus on representation of the digital objects in the collection, including descriptions and corresponding images, text or time-based media files (see Fig 1). Markdown serves as the vehicle for encapsulating curated information (metadata) described through basic text formatting, which reduces technical barriers associated with scripting languages and database implementations. 

Figure 1. Image description: A screenshot of the markdown that describes an item included in the the DigitalArc Platform demo exhibit site. Available in markdown form at https://github.com/DigitalArcPlatform/demo/blob/main/_items/Item-1-document.md and as a reader-facing page at https://digitalarcplatform.github.io/demo/items/Item-1-document.html

For students, connecting these easy-to-teach text-only editing processes meant they could use Github’s online GUI-based editor. This experience highlighted the division of labor in minimal computing that places additional up-front burdens on our developers. It was our responsibility to: understand that Github Pages’ existing GUI interface was viable as a point-and-click user interface for file editing; create as user-friendly an environment as possible within the context of Github Pages; explain the affordances of Github Pages as having some additional difficulty up front but a much longer-scale ease of maintenance and use that allowed for better trade offs; and provide documentation of that environment that makes it more easily adaptable by novices.

While our first development effort in Fall of 2019 was aimed at the infrastructure for a one-time classroom engagement, it would, in true minimal-computing fashion, come to include “ethical concerns that influence our practice” (Risam, 2025). These ethical considerations added to the benefits that we found in choosing custom development in Github Pages over the similarly time-consuming customization and long-term maintenance we would have had to budget in order to to use an existing digital exhibition and publishing platform that had institutional support. We quickly realized that this minimal-computing model had several additional affordances that we could use for other projects. First, as we built the student exhibit, we realized it was an easier model for novices to adapt free of charge for multiple projects, as compared to the freemium option that is more common for platforms like WordPress or Weebly, in which a single user is limited to a single free site. Building and applying new single-page templates in Jekyll was easier with limited design and programming skill, both for our team’s own development work and for future potential community members learning to customize and launch their own web sites. Second, the collaborative, free, non-academic context of Github had promise for audiences whose experiences with universities and other large institutions was less than positive (Sutton & Craig, 2023).

The specifics of our rollout in the classroom and those that followed, however, presaged a persistent concern that Quinn Dombrowski addresses in “Minimizing Computing Maximizes Labor”: “going ‘minimal’ requires a great deal of technical labor” (2022). Students needed additional support to transition from a fully GUI-based editing interface to the combination GUI/text-based editing system that GitHub Pages and Jekyll require. Coming face-to-face with this early on helped us establish teaching and documentation principles that addressed the longer-term implications of a minimal-computing platform-development agenda. This trade-off emphasized, for us, the importance of creating scaffolded documentation for DA implementation that allows for a more flexible, accessible user experience and easier maintenance for web site content creators and managers (see Figure 2).³

Figure 2. Image description: A screenshot of the documentation that describes how to edit markdown that describes an item included in the DigitalArc Platform, starting with directions for posting items. Available at https://digitalarcplatform.github.io/documentation/docs/publishSite/posting/

With both concerns and affordances in mind, we began to use these minimal-computing approaches in other settings, including 3 community-facing History Harvest projects that took place over the 4 years that followed the student-focused digital-archive classroom experience.⁴

Opaque Publisher: A Scholarly Publishing Platform 

It’s here that we time-skip forward to 2023, and the development of the Opaque Publisher. By then, our team had experience building DA into a templated platform that drew on existing models of community archiving and had fully integrated ideas of minimal-computing labor division into our workflow. Prototyping through an ACLS-funded grant⁵ helped us build and test a reasonably featured minimal-computing Jekyll template that served several community archive projects as well as proved its adaptability to other web-publishing needs.⁶

The affordances we identified during the initial iterations of what we now know as DigitalArc also played a role in setting up DA to become a useful foundation for the OP. Our experience with the adaptability of minimal-computing Jekyll sites was crucial for the timely development of the OP. Jekyll’s development process meant that our OP team members with basic HTML skills and a willingness to experiment could see DA in its fully articulated form and use that as an easily portable example to customize a new platform. That changed the up-front labor required of the more skilled members of our development team, allowing us to divide the labor more easily and to repurpose code across our different Jekyll projects, which lowered the burden of learning for team members who were still learning that customization skillset. We appreciated this method because Jekyll offered an environment that not only scaffolded our team as they experimented with their newly built site in increasingly complex ways, but encouraged them to do so because each small success helped them see themselves as capable of technical tasks. 

The second–our focus on moving DA outside of its original institutional context–offered an anchor for the OP’s goal of refusal–an intentional rejection of institutional context and institutional harm. Those experiences provided a foundation for operationalizing the refusal theory that Sean Purcell’s then-dissertation project brought to our attention.⁷ At minimum, his  functional requirements included a digital exhibition platform that mirrored the formatting requirements associated with academic publishing (citations, tables of contents, and indices). These elements were not included in DA’s development, owing to a difference in intended audience and intended output. In addition to this, the project’s interactive approach to refusal required templating for the platform’s interactive elements, which could be added to prepared markdown files by a user familiar with basic hypertext markup language (HTML).⁸ One of the advantages of working on these two projects in parallel was an opportunity to develop resources for future Jekyll templates that attend to the overlapping, but distinctions shared by academics, archivists, and communities.  

While DigitalArc offered an easy starting point for a team already familiar with Github Pages and the specifics of the DigitalArc template itself, there was no shortage of CMS options that were designed with some academic apparatus in mind. We re-evaluated our minimal-computing starting point–what do we have, what do we need, and what are our priorities–as we did due diligence. Omeka’s third-party development community included a footnote plugin, and Omeka’s base install had a built-in table-of-contents generator. Scalar diverged from the exhibit model to offer a combination of non-linear and table-of-contents-based reading processes, but customizing Scalar required a higher learning curve for our team. However, Scalar’s computational overhead and its dependence on PHP complicated the process of long-term digital preservation. Mukurtu’s focus on the ethics of digital exhibits was a good fit for the refusal theory that drove Purcell’s dissertation, but its dependence on Drupal 7 triggered worries for us about the long-term sustainability of the platform. In hindsight, platform worries beyond our initial reluctance to use Omeka were well-founded; Drupal 7 support ended in January 2025, leaving Mukuru in limbo, and Scalar experienced a maintenance outage in August of 2025.⁹ As with DigitalArc, we wanted to engineer around potential vulnerabilities and gaps in site availability, and the friction between open, non-profit archival platforms and dependency on a constantly updating database-driven codebase meant moving away from these easily accessible platforms.

Despite the surfeit of academic CMS models, flexible redaction models were harder to find. Print redaction, like that done in Adobe Acrobat or other print-document generators, assumes permanent strike-throughs or blackouts. Again, Mukurtu offered inspiration for changing levels of visibility based on community-oriented traditions and ethics, but those levels are controlled by site creators rather than readers or audience members. Ultimately, DigitalArc offered both the longer-term maintenance that we prioritized, the non-institutional platform that aligned with our ethical goals of institutional refusal, and the fastest customization path for a series of interface options that reified authorial choices about which text and image sections were sensitive but allowed the redaction-level display of those sections to be reader-controlled (Fig.3). In choosing to go further down the minimal-computing path that we started with DigitalArc so,​ we provide readers with a way to engage with the tensions and ethical questions that we posed in the companion article: “as scholars we have to show our work, and this practice of showing is often at the expense of those whose lives and deaths are entangled in our research programs.” (Purcell, Craig & Dalmau, 2025)

Figure 3. Image description: An example of how refusal informed the opacity functions in the OP in which users are able to toggle how they view the images and text based on whether the subjects depicted in primary materials consented to the research. This example was drawn from Purcell, Sean “Teaching Hygiene” in The Tuberculosis Specimen. (2025). https://tuberculosisspecimen.github.io/diss/dissertation/1_3_4

Our choices were made with an audience of scholar-authors looking for simple technical solutions in mind. That focus pushed us away from the integration of more complex programming and toward a mostly-CSS solution to implement the interactive opacity filters. For text, the opacity filter activates unique span classes in the textual narrative that have been flagged during composition.¹⁰ The interpolation of image and text was done mostly in markdown, using Scrivener, with a few text-string replacements that allowed Purcell to easily insert the necessary HTML to apply the Javascript redaction, a process which we describe more fully in “The Digital Opaque.” The actual content of the images, however, were much more complicated as every image that needed to be made opaque had to be edited three times: first, to crop and format for web; second, to edit and remove the first level of opacity for the ‘partial opacity’ version of the site; and third, to remove more of the image for the ‘opaque’ version of the site (fig. 4). When the site loads for a user, all three versions of these images are loaded at the same time, but only one is visible for the user at any time.

Figure 4. Image description: The three versions of each image corresponded with the opacity guidelines of the site, incrementally removing elements of the bodies of patients based on the project’s predefined protocols. From left to right, a white woman drinking from a glass while staring at the camera, in the next image her eyes are obscured, in the final image her whole face is obscured. Three unique versions of every image had to be made. Lockard, Lorenzo B.. Tuberculosis of the Nose and Throat. St. Louis: C. V. Mosby Medical Book & Publishing Co., 1909

We tested a few versions of the opacity functionality during the platform’s development. The first was Javascript-heavy. As one of the most common Javascript libraries in use for web site development at the time of OP’s development, React.js (https://react.dev/) offers a broad platform to build interactive user-controlled opacity of both images and text drawn from the opaqued parts of those images. Two things led us to an alternative path. React’s requirement for local compilation, coupled with the sometimes unpredictable attention to backward compatibility because of React’s emphasis on the constantly changing world of mobile-app development, had the potential to create sustainability issues. That, along with its origins in a very profit-driven corporate Facebook setting, led us to emphasize CSS control rather than Javascript control of the opacity features. We instead adapted basic show/hide options that were already built into the non-profit Zurb Foundation 6 library (https://get.foundation/). This CSS library’s user-contribution-oriented development process aligns with our community-oriented goals, Zurb’s smaller contributor base leads to a slower code-update rate, making it more suitable for a project with few developers available to update code in response to new library releases, and the smaller library base also meant we could load a local copy of the library, frozen at a particular release date. These choices, in turn, provide a more predictable user experience in the preserved versions of the site that are hosted not at Github but in other disciplinary and institutional repositories and in the Internet Archive. By keeping the site architecture simple, the published sites are more accessible to end-users and to web archiving tools that struggle to replicate more complex interaction.

Purcell’s introduction of refusal theory also provided the team with another opportunity to question our minimal-computing approach. Microsoft purchased Github in 2018, just as we were addressing the workload of updating those Omeka sites that had broken. Our choice to engage in a minimal-computing endeavor was thoughtful and anchored in careful consideration; our choice of Github Pages and Github’s front-end file-editing GUI was less well-theorized, and the OP offered us the opportunity to reconsider our choice. While we decided Github was the most timely and stable choice for hosting the dissertation, we also made offsetting decisions owing largely to the affordances of minimal computing sites. The most crucial of these was to take a cue from the LOCKKS program (https://www.lockss.org/) in our choice of static-site generation through Jekyll. Static sites are more easily preserved in packaged form on multiple platforms, like IU’s institutional repository Scholarworks, to open-source repositories like Knowledge Commons. More importantly, static sites function with their intended behavior on the Internet Archive, which serves as a fully-open-source public repository of general knowledge.¹¹ The distribution of many copies of completed archives in a variety of forms has also flagged a future need to explore alternatives to Github Pages like GitLab, in order to provide a platform for the DigitalArc template and its automated static-site page building process outside of Github’s environment.

Conclusion

While many of the choices we made were specifically oriented around the audiences for DA and OP, and the models in the digital-archive and digital-publication spaces that offered some but not all of the features we needed, the interplay between two platforms developed for different audiences on different models by the same team of scholar-developers has offered us some lessons that we are now integrating into our future work.

The first lesson we learned along the way is that contingency matters, and that the impulsive choices we made in response to serendipity and contingency can be a foundation for thoughtful, worthwhile change. If not for the PHP upgrade in Fall of 2018, we might not have repositioned our long-term platform-choice goals for DA in the context of minimal computing. That choice, in turn, shaped our choice of CSS-heavy redaction in the OP, a choice that has made our code more portable.

Our second takeaway is that it is hard to fully escape maximal computing. While Jekyll offers the option of building a website entirely on a personal computer, doing so has an enormous amount of technical overhead. In order to re-scope the technical skills required of our community-archive audiences, we needed Github’s full infrastructure–its web-based editing system, Github Pages and Github Actions–which is itself maximal and monopolistic.¹² While we’ll always need a maximalist web platform to provide support for less technical content creators, both in the community-archive world and for self-publishing in the digital humanities, diversification of platform away from monopolies–to Gitlab and Bitbucket in particular, in this instance–will also help us as we seek to live up to the goals we set of static-site generation in service of long-term stability for both DA and OP users. Practically speaking, this compromise allowed for users to author and access sites on their phones and creators to minimally maintain sites over  a long period of time with no upgrades or technical skills necessary to keep the site accessible to public audiences.

The functionality we developed for DA and the OP may be imperfect and can be time consuming. However, the code that drives that functionality can be operationalized as part of the ethical reconsideration of a scholar’s primary evidence. Whether that evidence is from communities whose partnerships with institutions have been fraught or from subjects whose evidence was included in archives without their consent, the code that presents our evidence in a variety of forms is a humanistic process, an endeavor that happens in context and should treat context and contingency as an opportunity to understand our relationship to technology, rather than as something to be erased.

---

Acknowledgements

We would like to thank Nate Howard, Sagar Prabhu, Jessica Organ, and Morgan Vickery for contributing to the web application development of DigitalArc and Opaque Publisher. We also want to thank our friends and colleagues who also shaped this work, especially Emily Clark, Vanessa Elias, and Marisa Hicks-Alcaraz. We would also like to thank Élika Ortega, Roopika Risam, and Alex Gil, and especially members of the Minimal Computing Go:DH working group, for the various ways of framing minimal computing for the digital humanities and for the publics more broadly; for the inspiration and the paradoxes that have kept us on our toes. We are big fans of In the Library with the Lead Pipe’s open peer review process, and appreciate Quinn Dombrowski, Pamella Lach and Jessica Schomberg for their feedback. We are grateful to get to this (better) version of the article. Lastly, we would like to thank our funders for making this work possible: the New York Academy of Medicine, the Center for Research on Race Ethnicity and Society, and with support from the American Council of Learned Societies’ (ACLS) Digital Justice grant program.

---

References 

Hannah Alpert-Abrams et al., “Post-Custodialism for the Collective Good: Examining Neoliberalism in US – Latin American Archival Partnerships,” Journal of Critical Library and Information Studies 2, no. 1 (2019)

Christina Boyles et al., “Postcustodial Praxis: Building Shared Context through Decolonial Archiving,” Scholarly Editing 39 (2011).

Dombrowski, Q. (2022). “Minimizing Computing Maximizes Labor,” Digital Humanities Quarterly 16, no. 2, https://dhq.digitalhumanities.org/vol/16/2/000594/000594.html. 

Ciula, Arianna, Øyvind Eide, Cristina Marras, and Patrick Sahle. (2018). “Models and Modelling between Digital and Humanities. Remarks from a Multidisciplinary Perspective.” Historical Social Research / Historische Sozialforschung 43, no. 4, https://www.jstor.org/stable/26544261.

Miya, Chelsea and Geoffrey Rockwell. (2025). “Platitudes: The Carbon Weight of the Post-Platform Scholarly Web”, The Journal of Electronic Publishing 28, no. 2. doi: https://doi.org/10.3998/jep.7247 

Purcell, Sean, Kalani Craig, and Michelle Dalmau. (2025). “The Digital Opaque: Refusing the Biomedical Object,” In the Library with the Lead Pipe, https://www.inthelibrarywiththeleadpipe.org/2025/digital-opaque/.

Purcell, Sean. (2025). “The Tuberculosis Specimen: The Dying Body and Its Use in the War Against the ‘Great White Plague.’” Indiana University. https://tuberculosisspecimen.github.io/diss/.

Risam, Roopika. (2025). DH2025 Keynote – Digital Humanities for a World Unmade. https://roopikarisam.com/talks-cat/dh2025-keynote-digital-humanities-for-a-world-unmade/. DH2025, Lisbon.

Risam, Roopika, and Alex Gil. (2022). “Introduction: The Questions of Minimal Computing.” Digital Humanities Quarterly, vol. 16, no. 2, http://www.digitalhumanities.org/dhq/vol/16/2/000646/000646.html.

Russel, John E., and Merinda Kaye Hensley. “Beyond Buttonology: Digital humanities, digital pedagogy and the ACRL Framework” College & Research Libraries News. (December 2017), 588-591, 600.

Sutton, Jazma, and Kalani Craig. (2022). “Reaping the Harvest: Descendant Archival Practice to Foster Sustainable Digital Archives for Rural Black Women.” Digital Humanities Quarterly, vol. 16, no. 3, https://dhq.digitalhumanities.org/vol/16/3/000640/000640.html.

Ton, Mary Borgo, (2019). “Shining Lights: Magic Lanterns and the Missionary Movement, 1839-1868. https://scholarworks.iu.edu/dspace/handle/2022/26951.

Walsh, Brandon, (2024). “Maximalist Digital Humanities Pedagogy.” Walshbr.com (blog). https://walshbr.com/blog/maximalist-digital-humanities-pedagogy/. 

Wikle, Olivia, Evan Williamson and Devin Becker. (2020). “What is Static Web and What’s it Doing in the Digital Humanities Classroom?” In M. Brooks et al.(Eds), Literacies in a Digital Humanities Context: A dh+lib Special Issue  (pp. 14-18), https://doi.org/10.17613/ryea-4z10. 

Wingo, Rebecca, Anderson MR. (2025). A Sustainable Shared Authority: The Future of Rondo’s Past. Public Humanities. doi: https://doi.org/10.1017/pub.2025.29. 

Zenzaro, Simone, (2024). “Models for Digital Humanities Tools: Coping with Technological Changes and Obsolescence.” International Journal of Information Science &Technology, vol. 8, no. 2, http://dx.doi.org/10.57675/IMIST.PRSM/ijist-v8i2.283.

1. Institutional dependencies can facilitate the creation and publication of a digital community archive but they can also result in reduced, or perceived reductions in community control over their own materials. For example, an institutional partnership might mean communities need to meet digital archiving standards that require costly equipment, where a community archive goal focuses on capturing community contributions (interviews, artifacts, etc.) in the best possible way, using easy-to-access and affordable mechanisms like one’s smartphone and DIY lightbox. Another example is reliance on more advanced technological infrastructure offered by institutions. Rather than opt for a post-custodial approach in which an institution like a public library or local history center hosts the digital archive, community members can do so themselves (Alper-Abrams et al. 2019; Boyles et al. 2011). ↩︎
2. For an example of a more complex installation of Jekyll, which relies on the user installing a programming environment on their computer to compile their site, see Amanda Visconti, “Building a static website with Jekyll and GitHub Pages,” Programming Historian 5 (2016), https://doi.org/10.46430/phen0048. Note that the “difficulty” level for this tutorial is rated as “low”. ↩︎
3. DigitalArc provides step-by-step documentation from planning a community archiving event to publishing a digital archive: https://digitalarcplatform.github.io/documentation/. The Opaque Publisher does the same: https://opaquepublisher.github.io/documentation/. ↩︎
4. In order of development cycles, these are the earlier versions of DigitalArc: Identity Through Objects (https://iubhistoryharvest.github.io/), Remembering Freedom: Longtown and Greenville History Harvest (https://longtownhistory.github.io/), Homebound (https://homeboundatiu.github.io/), La Casa / La Comunidad (https://lacasaiu.github.io/). ↩︎
5. To learn more about the ACLS-Funded DigitalArc project, visit: https://digitalarcplatform.github.io/. ↩︎
6. rchIvory: An Interdisciplinary Research Project” (https://www.archivory.org/), On Display: A Twenty-First Century Salon Des Refusés (https://ondisplayattulane.github.io) and Kalani Craig’s Digital History Dossier for Tenure as Associate Professor of History (https://tenuredossier.kalanicraig.com/) ↩︎
7. Purcell, Sean. 2025. “The Tuberculosis Specimen: The Dying Body and Its Use in the War Against the ‘Great White Plague.’” Indiana University. https://tuberculosisspecimen.github.io/diss/ ↩︎
8. For an example of the custom code developed for the OP, see: https://tuberculosisspecimen.github.io/diss/dissertation/X_2_1 ↩︎
9. At the time of writing this article, Mukurtu had still not released version 4, which would move away from Drupal 7 to Drupal 11. Currently, Mukurtu 4 is available in as a stable beta: https://mukurtu.org/mukurtu-4/. ↩︎
10. Flagging of text and images depended on a predefined ethical framework, and highlighted at different phases in research. For The Tuberculosis Specimen, opacity designations were decided based on different approaches to biomedical informed consent and subject privacy ( https://tuberculosisspecimen.github.io/diss/dissertation/FAQ ). Images were flagged as they were added to chapter drafts and text was flagged during the project’s ‘ethics audit’–a moment prior to publication where researchers are invited to reflect on what processes they used and materials they included and alter their final result to match the ethical frameworks they hoped to meet in the project (Purcell, Craig & Dalmau 2025). These sections were flagged in the project’s word processing program (Scrivener), using placeholder text, which would be changed using a batch find-and-replace script for text files (https://tuberculosisspecimen.github.io/diss/dissertation/X_2_3). ↩︎
11. The Wayback Machine is able to preserve Sean’s dissertation as-is: https://web.archive.org/web/20250516183042/https://tuberculosisspecimen.github.io/diss/. The same isn’t true for Mary Borgo Ton, whose born-digital dissertation preceded Sean’s at Indiana University. Mary had to combine several output and documentation approaches to preserve, as closely as possible, her dissertation since the Wayback Machine was unable to preserve content produced by Scalar, which is a more complex PHP site. Instead parts of Mary’s dissertation were preserved via Indiana University’s institutional repository: https://scholarworks.iu.edu/dspace/handle/2022/26951. ↩︎
12. For a broader view of how Github’s quasi-monopoly shapes student experiences in higher-education classrooms, see https://ploum.net/2026-01-05-unteaching_github.html; for Github’s relationship to Microsoft and even more monopolistic technology platforming, see https://medium.com/asecuritysite-when-bob-met-alice/as-github-glitches-are-we-too-dependent-on-microsoft-01d9c2f67329 ↩︎