Many humanities instructors seek to incorporate digital humanities (DH) projects into the classroom to give students vital experience in modern research methods and communication mediums, introducing concepts and skills that will serve them in academic endeavours, in future careers, and in better understanding our digital world (Spiro; Bonds; Hangen; Varner). Often these experiences rely on common content management platforms such as Omeka and Scalar, which facilitate initial adoption, allowing the students and instructor to interact with the platform using a familiar web-based administrative interface. However, this can result in a “buttonology” approach to instruction where students learn the specifics of a single visual interface, clicking through forms and buttons, without gaining the fundamental web and data literacies instructors want to teach (Russell and Hensley). Furthermore, these platforms also require extensive server infrastructure and ongoing maintenance that can limit the sustainability (or even the possibility) of the projects.

In 2021–2022 the authors convened a team of librarians and teaching faculty from University of Idaho (U of I) and University of Oregon (UO) forming the Learn-Static initiative to explore alternatives informed by a minimal computing philosophy. These approaches strip away complex infrastructure by using static web-based templates to refocus learning on fundamental concepts and increase sustainability. Static web approaches have a number of appealing benefits and possibilities (Wikle et al.), however, instructors will find few resources specifically geared to creating projects for the classroom and can often be daunted by the initial learning curve. To help fill that gap, Learn-Static seeks to bring together open source static web templates, open access learning resources, and instructor-focused materials in adaptable packages ready for use in the classroom. These open educational resources can be integrated into the curriculum to expand learning and research opportunities for both students and instructors. This paper introduces the concepts behind Learn-Static, reports on the pilot program that tested Learn-Static DH projects in the classroom, and reflects on the potential for future development of the initiative.

Background

Static and Dynamic Web

Before looking at the Learn-Static project, it is important to understand the contrast between static and dynamic websites, and how static websites fit with a minimal computing approach. Platforms typically used in the classroom such as Omeka, Scalar, Drupal, or WordPress are content management systems (CMS) installed on a server used to generate a dynamic website. This means that when a visitor navigates to a URL on the website, the CMS uses server-side processing to interpret the request, retrieve content and templates from a database, and generate the correct HTML response on the fly to display in the visitor’s browser. This server-side processing allows the CMS to provide powerful tools to users by exposing many content editing and configuration options as part of a web-based administrative interface. For example, many users will be familiar with logging into a website to edit a blog post or clicking a few buttons to change the website’s look from a set of pre-configured themes.

However, CMSs are complex applications and must be installed on a relatively powerful server to provide reasonable performance to visitors and managers, and must be vigilantly updated to maintain security. The technical complexity of the application is often hidden from the creators as many applications are available as “one-click” installations on managed web hosting services or are deployed behind the scenes by IT professionals. However, for all their power, dynamic web platforms come with risks, commitments, and tradeoffs that might not be obvious—setting up a CMS is like adopting a puppy that requires constant ongoing maintenance and attention (Dombrowski, “Sorry for all the Drupal”). This reality may unexpectedly lock instructors into spending time as system and user administrators, paying a subscription to a third party to manage it, or requiring a clear sunset date to close down the project website.

In contrast, a static website is composed of plain HTML, CSS, JS, and media files stored on a basic web server ready to be delivered to visitors without any server-side processing or database. Much like a shared folder of files, every page on a static website exists on the server as a file before the user navigates to it and is sent to the user’s browser without any dynamic changes. Because of this fundamental simplicity, static websites can provide high performance even from the most basic web server or hosting solution, and remain secure even without ongoing maintenance. This has the potential to minimize infrastructure requirements and lower barriers for developers, all while using less bandwidth and energy, ultimately resulting in less cost for website creators, maintainers, and visitors.

Since static websites have no server-side applications, databases, or user accounts, there is no web-based interface to edit content and manage these websites. Manually creating all the files necessary for a website would be tedious, so modern static web approaches are facilitated by static site generators that utilize simplified markup, plain text data files, and modular templates to create complete websites ready to deploy on a server. Site generators provide some of the power of CMSs to separate content and presentation, although the interface is generally at a lower level, involving editing content in plain text formats and using command line tools. The final static website is built by the generator (or an automated build service), and the files are copied onto a web server ready for end users. As with a CMS, creators will still need to navigate the complexity of selecting a hosting option; however, because of the simplicity and minimal requirements of static websites, there are a wide variety of options available, such as personal web space provided by an institution, free static hosting services such as GitHub Pages, or basic self-managed platforms such as Reclaim Hosting. Many open educational projects such as Programming Historian and The Carpentries use the free-tier infrastructure provided by GitHub to facilitate collaboration and hosting, which can minimize the barrier to publishing content.

Some well-known examples of static web frameworks for digital scholarship projects already exist, such as Wax, Ed, or CollectionBuilder, and a growing number of unique DH projects are built using static web tools. These approaches view DH infrastructure through the critical lens of minimal computing, asking what is essential to a project, what is sustainable in any given context, and what trade-offs, costs, and investments are represented in platform choices (Gil, “Design” and “The User”). Roopika Risam and Alex Gil summarize these critical questions to define minimal computing “as a heuristic comprising four questions to determine what is, in fact, necessary and sufficient when developing a digital humanities project under constraint: 1) ‘what do we need?’ 2) ‘what do we have’ 3) ‘what must we prioritize?’ and 4) ‘what are we willing to give up?’” (Risam and Gil 1). We can apply this same evaluation to the platforms chosen for use in the classroom.

Typical CMS options are powerful tools and can represent a good choice in many teaching contexts. The dynamic web platforms often ease and simplify initial adoption if IT help is available for set up and robust managed server resources are provided. However, the overall complexity and ongoing maintenance requirements may risk creating opportunity costs that reduce our flexibility, creativity, and the concepts we can teach, while locking us into unsustainable long-term commitments. In the context of classroom projects, this often results in broken websites, dead links, and lost data—and the aforementioned “buttonology” phenomenon in classroom learning.

Static web approaches often represent a greater upfront investment in learning, which can be daunting in many contexts. However, by minimizing digital infrastructure and maintenance, some cost barriers are removed, enabling projects to be created even with limited resources. The DIY workflows and low security risks of static websites reduce the need for system administrators and IT support, allowing DH practitioners to initiate and take full control of the project. Thus, the initial investment in learning can pay dividends by growing agency, agility, and long term sustainability for our projects and organizations.

Benefits of Static Web for DH Pedagogy

The Learn-Static initiative seeks to demonstrate that, beyond being a viable option for DH projects in general, the methodologies behind static web development are especially well-suited to enhancing DH pedagogy by providing fundamental learning opportunities and sustainable project outputs, which opens up new opportunities in the classroom.

Compared with the graphical user interface (GUI) abstraction of CMS platforms, working with static websites more clearly reveals the data and code powering digital projects. Instructors and students create content and customize a website by editing spreadsheets and plaintext files that become the project’s source code, rather than accessing and updating these fundamentals through the forms and buttons on a web interface. This puts the focus on creating and curating data, demonstrating the independence of content from platform and presentation, and avoiding the conflation of tool and methodology (Tenen). When students learn to add and edit a website’s content or data without the editing software of a CMS, they are prompted to explore their project’s directory structure, which can grant them a fuller understanding of how content is consumed by the static site generator and manipulated to populate the website’s front end. This engagement with the project’s source at a fundamental level allows students (and their instructors) to build highly transferable skills in data, digital, and web literacies. Instructors can draw on the static web approach to incorporate web development and computational concepts into their course projects, integrating these skills with the tasks of preparing and analyzing source materials to build critical perspectives of digital culture.

Some critiques of the static web approach focus on the technical and emotional labour involved in teaching the technological complexity of static projects, arguing that knowledge of the many technical skills that go into building a static website should not be an imperative to participating in digital scholarship projects (Dombrowski, “Minimizing”). It is true that getting started with static web projects requires investing time in learning technical skills, but committing to a CMS requires devoting a significant amount of time to learning its interface as well. Part of what the Learn-Static project aspires to address is how to lower barriers so beginners can spend that time learning transferable technical skills rather than learning the specifics of a CMS interface. This does not mean that students need to become versed in developing classroom digital scholarship projects from scratch; rather, their contributions might look more like creating spreadsheets or using Markdown or HTML to add to or edit the project’s content and design. Depending on their chosen course of study, this may be the only opportunity some students get to practice these technologies in school. We recognize that the static approach is not always the best fit for every digital scholarship project’s context—depending on an institution’s resources and the technical aptitude of collaborators, there may be alternate development methods more suited to the project at hand. In the specific context of DH pedagogy, we see the potential of static web projects to enable teaching and learning reusable technical skills as a huge benefit. In our approach, the time that is invested in learning these skills and becoming more critical users of digital culture becomes part of the project’s objective, in tandem with its published output. An intentional approach to creating reusable static web code templates, documentation, and lesson plans similar to those developed for the Learn-Static initiative is one solution for reducing the technical and emotional labour of teaching technological concepts while also increasing the depth of the student learning experience.

Beyond their pedagogical benefits, static web development cycles are also a good match for the reality of labour in academic research. Digital projects, especially in the classroom, usually involve intense work during a short period of activity and are then left with no resources for ongoing maintenance. Dynamic platforms are best shut down if they are not maintained, leaving behind broken links in place of the evidence of learning cited in student portfolios and leading to the loss of unique content. However, static websites remain functional even when left alone for long periods of time unmaintained, providing a lasting public resource and record of their work. Furthermore, because the project data is prepared in standards-based formats, the outputs are computation-, migration-, and preservation-ready information. By working with this data as an investment, students can better understand the context beyond the assignment outputs to see the potential of reuse in the inevitable future platform, project, or inquiry.

Finally, their low cost and minimal required resources enable static-based projects to be more agile and inclusive. Static web development methods allow users to iterate through project stages with less up-front investment, quickly prototyping ideas or building out smaller projects. In the classroom, this enables new opportunities: for example, students might each create their own website or small groups of students might create whole series of websites iterating with the same data. The minimal infrastructure overhead and low cost mean more collaborators can be involved in development across varying contexts and use cases.

Ultimately, any platform adopted for a classroom project will require a significant investment in learning for both students and instructors, so it is important to critically consider how to balance the costs involved and how to maximize the value of the experience. We understand that teaching statically generated projects can be daunting for instructors just learning the concept themselves. Therefore, a primary goal of Learn-Static is to make it easier for both students and instructors to start incorporating this style of development into the classroom by creating templates and models to follow and adapt to a variety of classroom contexts.

Learn-Static Approach

In 2021, the U of I/UO team received a National Endowment for the Humanities (NEH) Digital Humanities Advancement Grant to develop and pilot the Learn-Static materials. Prior to receiving this funding, we had identified a need for static web–focused pedagogical tools for DH projects based partly on our experience teaching the digital collections framework CollectionBuilder. Many CollectionBuilder workshop participants expressed their interest in using the static web approach in the classroom and were eager for models of how to incorporate it. Our impetus behind creating static web DH projects was therefore not just the project code and outputs themselves but also the creation of thorough documentation and resources for curious instructors, including lesson plans and demo projects. We expect that the average Learn-Static user is not an experienced programmer—in many cases, they will be novice GitHub and command line users. Technical curiosity and a willingness to learn are all that are required to jump into the Learn-Static materials.

Learn-Static is intended to be the pedagogically focused counterpart to Lib-Static, a methodology and community around incorporating static web tools into the library setting. Similar to Lib-Static, we hope the Learn-Static model attracts a community of users who are invested in producing DH classroom projects that are sustainable and free and that provide opportunities for teaching important transferable digital literacy skills. To accomplish this goal, we produced two types of Learn-Static educational resources: (1) a set of five foundational modules that serve as an on-ramp for learning the basic components of static web development, focusing on the topics of GitHub, Markdown, HTML, data concepts, and computational methods; and (2) a set of four classroom projects which we think of as teaching kits that contain the code template and documentation for a class project. Our classroom projects cover the subjects of digital collections, digital oral histories, multimedia essays, text analysis, and digital project recovery.

Grant Activities

Work on the foundational modules was conducted by librarians over the first four months of the grant in fall 2021, and the classroom projects were created and piloted by librarian–faculty pairs in history and English classrooms in spring 2022. As we progressed through the project timeline, we were especially interested in assessing whether the foundational modules were effective on their own or more meaningful when incorporated into the larger documentation of the class projects. We were also curious to know if collaboration between an instructor and librarian was integral to the success of the classroom projects or if they are conducive to implementation by the “lone” DH instructor or librarian—someone who might reside at an institution where collaboration may not be possible. To assess the effectiveness of the modules and classroom projects, we used traditional means of surveying students in our history and English courses periodically throughout the semester and project timeline. To assess the usability of the modules and projects by instructors, we assembled an expert team of advisors with varying DH approaches and backgrounds to review the modules and projects individually. After their review, advisors joined the grant team for two days of discussion about our experiences using and teaching the modules and projects.

Foundational Modules

The Learn-Static foundational modules teach the basics of creating a statically generated web project in manageable pieces using the static site generator Jekyll and deploying the website on GitHub Pages. There are currently five modules, each with a focus on introducing one of the following topics:

• GitHub: surface-level introduction to using GitHub, including instructions for creating a GitHub account and repository and turning on a GitHub Pages website

• HTML: set of brief lessons that provide an overview of the fundamental building blocks of websites, with a focus on HTML

• Markdown: instructions for using Markdown, a simplified markup language for adding formatting elements to plain text files

• Data Manipulation: introduction to metadata, using and editing spreadsheets in Google Sheets, and instructions for downloading an existing metadata sheet, edit it in Google Sheets, save it as a CSV, and re-upload it to GitHub

• Computational Methods: using sample data included in the repository, step-by-step instructions demonstrate how Jekyll builds a static website and how the Liquid template language is used to manipulate and control the data that populates the website

Each module exists as a minimal GitHub repository, with step-by-step instructions contained in a single Markdown file. Screenshots are kept at a minimum to decrease the inevitable work that will go into maintaining these modules in the future. In each case, following the steps of the module entails the user copying the module files and code into their own GitHub repository and editing it through the GitHub user interface—no software download is required. The modules can be used sequentially (moving from an introduction to GitHub to writing content for the web using Markdown and HTML, to delving into data manipulation and computational methods with Jekyll’s templating language, Liquid), or they may be used as discrete lessons or homework assignments. Each takes approximately 30 minutes to complete and delivers just enough introductory information to prep students for further project work in class. For example, the week before beginning a digital collections project to which all students will be contributing via GitHub, the instructor might assign the Intro to GitHub foundational module so that students come to class prepared, having already set up their GitHub accounts and learned how to make a commit on a GitHub repository. This is meant to save class time, allowing the instructor to skip over some of the basics and jump right into creating a tangible project. Links to external resources are included in each module for those who want to pursue a more in-depth introduction to the subject.

While we initially imagined the foundational modules as pieces that could be woven together into a fully-fledged workshop, in actual practice we found them more useful as introductory lessons that we could pick and choose from when teaching the longer classroom projects. They are better suited to learning specific skills which can then be applied to a project, rather than learning those skills just for the sake of learning. Overall, the foundational modules served their purpose as short, easily manageable introductions to concepts of static web development that can be remixed for more specific contexts, and they provided us as developers practice in thinking through technical documentation that we were able to apply to our design of the classroom projects during the second half of our grant period.

Classroom Projects

We conceived of our four statically generated DH classroom web projects as transferable teaching kits, generally applicable projects that could be customized and tweaked to fit a variety of classroom subjects and settings. With this as our motive, we roughly designed each classroom project to produce a specific web output and consist of a code template in a repository on GitHub, a demo project website, and a website containing documentation for students and sample lesson plans for instructors. Depending on the class framing and allotted project time, an instructor or librarian might copy the project code and set up a website to which all the students contribute, or each student might copy the project code individually to set up their own project website. Each project has an individual objective; overviews and a brief description of how each project was implemented are included below:

• Digital Exhibit Lab: taught as a semester-long project in an undergraduate twentieth-century American history course to provide experience in traditional and digital archival research and primary sources. After exploring relevant collections in the archives, students received instruction on how to digitize and describe archival material, then contributed items to the class’s digital collection by uploading digital objects and creating metadata records in a Google Sheet. This course was in-person, synchronous, and not billed as a digital history course. Output: a single digital collection website containing primary sources curated by the class that were used for their research essays.

• Writing with Visualizations: taught as a semester-long project in an undergraduate twentieth-century American history course. Students received instruction on how to create a GitHub account, turn on a GitHub Pages website, write an essay in Markdown, and incorporate digital primary resources into the essay using Jekyll’s templating language, Liquid. The course was all-virtual, asynchronous, and not billed as a digital history course. Output: each student created their own website complete with multimedia essay.

• Oral History Lab: taught as a semester-long project in an undergraduate history course titled The Long 1960s. This project facilitates students’ experience of conducting, transcribing, coding, and analyzing oral history interviews. Students learn to treat an interview as data, assigning qualitative subject tags to it in Google Sheets and creating Markdown stubs for each interview in the class project’s GitHub repository. Once interview data is uploaded to the repository, it appears on the project’s website, generated by GitHub Pages. This course is in-person, synchronous, and not billed as a digital history course. Output: a single class website that contains all oral histories collected by the class.

• Data Recovery for Digital Collections: taught as a class project in an English course. Students received real-world data collected by a local nonprofit and were tasked with cleaning the data and preparing it for a CollectionBuilder digital collection website. Students learned data concepts such as controlled vocabulary, formatting, and functions working in Google Sheets. This course was in-person, synchronous, and billed as a DH course. Output: a single digital collection website containing items from the dataset that was cleaned and curated by the class.

All of the projects described above were taught in classes composed mostly of humanities majors without dedicated knowledge in web development. In all project scenarios, the projects were implemented in the classroom by a librarian–faculty duo, with the faculty member contextualizing the project within the realm of the course subject matter and the librarian teaching the technical skills required to participate in the project.

Each of these projects was developed with the goal of producing deliverables for the students and instructors (including long-lasting websites that students can include on their résumés), and teaching key components of data literacy and web development alongside the curation of humanities resources. In the scenarios described above, students needed at minimum to create a Google account and collaboratively edit a Google Sheet. At most, students also established GitHub accounts and created commits to add Markdown content to their project websites.1 Notably, the barrier for entry was still relatively low: no software download was required, and all contributions could be made through a web interface.

Though the majority of these students are not likely to build a digital collection or conduct oral history interviews in their prospective careers, it is reasonable to expect that they will edit a spreadsheet or write content for the web in the future—technical and pragmatic skills that this approach allowed them to learn and experiment with. When taught in this fashion, these skills complement and enhance the critical thinking around humanities data curation, the benefits of which have been widely acknowledged in DH pedagogical literature (Flanders; Fyfe; Posner; Cobourn). When students are curating items for a digital collection, cleaning up metadata descriptions, or preparing an interlocutor’s personal history for web publication, they get a first-hand experience of the subjective decisions that must go into refining much of the web content they use on a daily basis, an exercise which builds their critical digital literacy.

Challenges

We faced challenges throughout our creation and piloting of these tools, some more anticipated than others. Engaging with these technologies for the first time does involve a significant learning curve. Even though we did our best to mitigate the frustrations involved in participating in these projects by breaking down modules into smaller pieces, in all but one case we were teaching classes that were not specified as DH classes. There was pushback from history students who were unaware upon signing up for the class that they would have to learn new technical skills to participate in graded class projects. In many cases, students who were hesitant at first grew more comfortable with using spreadsheets and GitHub over the course of their project, especially when work for that project stretched across the entire semester, as the multimedia essay projects did. Repetition (repeatedly making commits, styling text in Markdown, etc.), was especially crucial to building students’ comfort with the technologies. In extreme cases where students could not participate in the digital project due to extenuating circumstances, they were asked to complete an alternative version of the assignment (for example, in the case of the multimedia essays, some students were given permission to write an essay in a Microsoft Word document instead of in a Markdown file on GitHub).

Another challenge we faced was aligning our (often overly ambitious) ideas for what could be accomplished in a class or workshop setting with reality. For example, the learning modules were initially intended to be combined for use in a UO Libraries data and digital literacy workshop. However, because they are short and intended as introductory prep for further hands-on classroom work, completion of the modules themselves does not produce a satisfying deliverable that workshop participants can take away. In our experience, most technically focused library workshops draw more participants if they promise a practical deliverable. Instead of combining the modules into one workshop, therefore, the UO Libraries hosted a CollectionBuilder workshop with documentation that utilized portions of the modules, particularly the Intro to GitHub and Markdown modules. Ultimately, our experience with the learning modules proved that they were better designed for general contexts in a standardized format (i.e., Markdown files) that could easily be adapted and incorporated into specific project documentation.

In the case of our digital collections project in the UO English DH class, the instructor–librarian pair had to pivot to spend more time on data cleaning, best practices, and recovery than they originally planned, meaning that students lost the opportunity to learn to navigate the GitHub interface, but did walk away from the class with substantial data literacy skills and a better understanding of the bias that goes into curating and describing digital collections, as they standardized and removed problematic vocabulary in metadata and images that were obtained through a partnership with a local nonprofit. In the end, the instructor–librarian pair built the digital collection using the data that the students cleaned, so students still had a deliverable to point to, even if their technological focus was not on web development skills but on clean data. In the end, the flexibility and ease of creating the statically generated collection quickly allowed the project leaders to adapt to focus on skills that were relevant to the project and meaningful to the students.

As the scenario above exemplifies, we discovered that instructor–librarian collaboration is key on these projects. In our own teaching scenarios, humanities instructors contextualized the project within the course while also learning technical skills themselves, while librarians guided students through their technical learning and ensured the digital infrastructure of the project was working correctly. Of course, the collaboration between digital librarians and humanities instructors on DH projects is not uncommon: in many cases, collaborative projects like this are undertaken using Omeka or Scalar. No matter the platform, however, as technical experts, the librarian is typically expected to maintain the project for the long term. Criticisms that static projects require more learning or work by the collaborators often discount the labour of system administration, configuration, and ongoing maintenance required of CMS platforms, work which is sometimes outsourced to IT, but often falls to librarians. When the project is statically generated, this maintenance duty becomes less of a drain on time and resources, enabling librarians to more fully engage in teaching and creative development, while learning technical skills that make this work more sustainable. For example, the Digital Exhibit Lab can be framed in various ways depending on the learning objectives for the course, from students simply contributing items found in their archival research to students fully customizing a digital exhibit. The project as implemented in the pilot U of I history course focused on students doing archival research, digitization, and contributing their items by creating metadata in a spreadsheet. The shared digital exhibit was completed by the librarian. This was an opportunity for students to build spreadsheet skills (that they are not exposed to in the history curriculum) while immersed in critical inquiry into digital archives and research. As this replaced a similar project based in Omeka, using the template simplified the librarian’s contribution to the project, minimizing the necessary infrastructure and maintenance, and freeing up more time for hands-on classroom teaching.

Finally, when we set out to build the Learn-Static classroom projects, we initially imagined the materials we created as generic enough to be usable across many classroom contexts. In the act of creating them, however, we were bound to the constraints of the subject matter and class time available to us and our co-instructors, meaning that the classroom project documentation and demo websites turned out to be highly specific to each course context. As we wrap up the grant, we are now faced with the challenge of doing some decontextualizing of our classroom project materials so that their documentation is clear, understandable, and easily adaptable to instructors and digital librarians in a variety of disciplines and institutions.

Conclusion

Though there is a significant investment in technical learning required for the instructors and students that use these tools in the classroom, particularly for beginners, the investment pays off in the project outcomes: students gain transferable digital literacy skills and instructors can fully customize and leave class project websites live for long periods of time without worrying about security risks, continuous maintenance, or in many cases paying for hosting. For instructors just starting from scratch, the choices and learning required to set up a project like this may seem daunting, but we hope our foundational modules will get them started and feeling comfortable with this style of development and teaching and point them to additional resources they can pursue to continue their learning. Ideally, we see Learn-Static becoming a community effort, with instructors from a variety of institutions contributing their own lesson plans, learning modules, classroom project templates, and assessment practices. We want users to understand ultimately that they are not beholden to the modules and project templates currently available but are encouraged to use them as a starting point, to edit and remix them to fit their own project’s needs. We hope communicating our project code and contexts, and identifying the success we have experienced in breaking up technical learning into manageable introductory portions to teach students transferable skills and produce sustainable project deliverables will inspire others to begin learning and teaching static web for DH projects, one step at a time.

Works Cited

Bonds, E. Leigh. “Listening in on the Conversations: An Overview of Digital Humanities Pedagogy.” CEA Critic, vol. 76, no. 2, 2014, pp. 147–157, http://www.jstor.org/stable/44378544.

Cobourn, Alston. “Spreading Awareness of Digital Preservation and Copyright via Omeka-based Projects.” The Journal of Interactive Technology and Pedagogy, 28 Mar. 2016, https://jitp.commons.gc.cuny.edu/spreading-awareness-of-digital-preservation-and-copyright-via-omeka-based-projects/.

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

Dombrowski, Quinn. “Sorry for All the Drupal: Reflections on the 3rd Anniversary of ‘Drupal for Humanists.’“ Quinn Dombrowski, 8 Nov. 2019, https://quinndombrowski.com/blog/2019/11/08/sorry-all-drupal-reflections-3rd-anniversary-drupal-humanists/.

Flanders, Julia. “The Productive Unease of 21st-Century Digital Scholarship.” Digital Humanities Quarterly, vol. 3, no. 3, 2009, http://www.digitalhumanities.org/dhq/vol/3/3/000055/000055.html

Fyfe, Paul. “Digital Pedagogy Unplugged.” Digital Humanities Quarterly, vol. 5, no. 3, 2011, http://www.digitalhumanities.org/dhq/vol/5/3/000106/000106.html.

Gil, Alex. “Design for Diversity: The Case of Ed.” The Design for Diversity Learning Toolkit, 20 June 2019, https://des4div.library.northeastern.edu/design-for-diversity-the-case-of-ed-alex-gil/.

Gil, Alex. “The User, the Learner and the Machines We Make.” Minimal Computing, 21 May 2015, https://go-dh.github.io/mincomp/thoughts/2015/05/21/user-vs-learner/.

Hangen, Tona. “Historical Digital Literacy, One Classroom at a Time.” Journal of American History, vol. 101, no. 4, Mar. 2015, pp. 1192­–1203, https://doi.org/10.1093/jahist/jav062.

Posner, Miriam. “Humanities Data: A Necessary Contradiction.” Miriam Posner’s Blog, 25 Jun. 2015, https://miriamposner.com/blog/humanities-data-a-necessary-contradiction/.

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

Russell, John E., and Merinda Kaye Hensley. “Beyond Buttonology: Digital Humanities, Digital Pedagogy, and the ACRL Framework.” College & Research Libraries News, vol. 78, no. 11, 2017, https://doi.org/10.5860/crln.78.11.588.

Spiro, Lisa. “Opening up Digital Humanities Education.” Digital Humanities Pedagogy: Practices, Principles and Politics, edited by Brett D. Hirsch, 1st ed., vol. 3, Open Book Publishers, 2012, pp. 331–364, https://doi.org/10.2307/j.ctt5vjtt3.19.

Tenen, Dennis. “Blunt Instrumentalism: On Tools and Methods.” Debates in the Digital Humanities 2016, edited by Matthew K. Gold and Lauren F. Klein, U of Minnesota P, 2016, https://dhdebates.gc.cuny.edu/read/untitled/section/09605ba7-ca68-473d-b5a4-c58528f42619.

Varner, Stewart. “Library Instruction for Digital Humanities Pedagogy in Undergraduate Classes.” Laying the Foundation: Digital Humanities in Academic Libraries, edited by John W. White and Heather Gilbert, Purdue U P, 2016, pp. 205–222, https://doi.org/10.2307/j.ctt163t7kq.14.

Wikle, Olivia, et al. “What Is Static Web and What’s it Doing in the Digital Humanities Classroom?” dh+lib, 22 June 2020, https://dhandlib.org/2020/06/22/what-is-static-web-and-whats-it-doing-in-the-digital-humanities-classroom/.