Critical Making Fellowship 2026-2027

Jessica writes:

Within the United States, the racialization and criminalization of Black and Brown bodies have been and continue to be a violent process. One shape and form of this violence is police violence, more specifically, police shootings. Different articles, books, scholars, and organizational databases have gone about examining and tracking police killings, including but not limited to: Washington Post’s Fatal Force Database and Mapping Police Violence.

This year-long fellowship and project is a data visualization project using data from the Washington Post’s database, with a focus on the Latiné people killed in police shootings.

The Visualization Itself

The current idea: there will be a cutout of the United States, and using a pin model, four years of Latiné deaths across the states will be physically represented. Breaking the data into grouped years, the model will drop each year’s number of victims, year by year, with different points of information represented by the pins’ form, color, height, and grouped quantity by diameter.

Focus of Anticipation:

The pins will drop by year and hang suspended. Imagine a map base with pins standing on top, but the base will be embedded with gaps/holes that the pins will fall through when released and stay suspended, so they don’t fall completely to the ground but hang on the mirrored side of where they once lived.

Take, for example, the year 2015, which has 176 recorded victims of police killings; the distribution of the 176 persons will simultaneously fall while the victims of the remaining three years remain standing until the year has passed. The pins dropping down at different intervals represent the ways Latiné death is anticipated and almost inevitable. Latiné bodies within the United States anticipate the potentiality of violence, the knowledge that racialized bodies are not and have not been safe within the nation-state.

Along with this lived sense of precarity and anticipation, the hope is that the viewer who sees this visualization and its process will notice and feel the growing sense of anticipation, though it will differ from the embodied one the community itself feels.

A question here: why not just let the pins drop, and why keep them suspended? Beyond the practicality and efficiency of restarting the board to all four years standing, I am working and inspired by Latiné writing and artistic production of death. It may sound odd, but the idea of the suspension comes from a mixture of Mexican and Chicanx celebration of the Day of the Dead and a poem by Jose Olivarez.

The idea is that underneath the main structure and base of this nation, the lives of the dead remain. The nation-state stands on top of these deaths and is built on this history.

Design and Prototyping

What have we tested and thought through so far? With any prototype, the minute you think you narrow down one detail, a thousand more questions arise. Theoretically, to aid in the visualization of different data elements we have discussed what about the pins can be transformed to make different points.

For example, the height of the pin will represent the different age groups largely affected by police killings; the diameter, the quantity. Where one year has 176 victims, imagining filling even one map with 176 pins felt nearly impossible, not even to consider a four-year range. To consider that the diameter of the pin will represent quantity groups.

1 victim – pin of 4 diameters 5 victims – pin of 7 diameters 15 victims – pin of 10 diameters

Along with height and diameter, the pins will have two different color groups for sex: male and female.

Questions We’ve Encountered

As we began designing and isolating the data, each detail of the prototype raised new questions. With any data visualization projects there are certain audience takeaways you try to achieve. With maps, the process raises more and more questions about geographic exactitude versus approximation. Along with that, you ask the prototype which parts of the data you can visualize at the same time versus what gets lost or is prioritized differently along the way.

Ammon starts here:

A Pedagogical Approach

We started thinking about this project by beginning with the end in mind. I have found that bigger projects like this benefit from taking this approach first, as it narrows down the plethora of alternate paths that are available at the start of a project.

We started by thinking about the project being all done. It’s created, installed, and ready for people to interact with it. Now imagine someone has just finished interacting with the piece. The answer to the following two questions guide our design and development of the project as we go forward. What emotion do you want this person to have? What knowledge should they walk away with?

The answer to the first question was: Anticipation. They should feel a bit of anxiety and trepidation as they anticipate which pins will fall next, and how many will fall. Who’s next?

The answer to the second question was: The concentration of deaths occurs in the border states. With those two questions answered we could delve into how best to represent the anticipation and the knowledge. We came up with a few different alternatives but always came back to the idea of pins dropping through the map. As Jess explained above, the suddenness of some of the pins dropping away leads to anticipation for the next set of pins to drop. Where? How many? Who?

Hie ye! What was, in the past, named “Coffee and Code” is now Speaking in Code. (Don’t worry, we’ll still plan to have coffee.) I always liked that title we gave to a great event well over a decade ago now, where we brought digital humanities practitioners (coders, designers, etc…) to think about the ways in which we speak in, and with, code. That’s the spirit I’ve always wanted to bring to our current event series. It’s a gathering to share, to work out or work through ideas through digital humanities practices that are iterative and experimental, but to do that together, in the attentitve presence of engaged, supportive folks.

With that, here’s the line up for this coming Fall 2026. Join us in person or on Zoom!

• September 9 - Winnie E. Pérez Martínez
• September 23 - Doug Chestnut
• October 7 - Jeremy Boggs
• October 21 - Shane Lin
• November 7 - Jessica Gómez

Applications are now open for Praxis Fellowships to be held during the 2027-2028 academic year. Further details below about the application.

If you’re interested in learning more about the fellowship or have questions about anything you read below, please consider attending the information session for the 2027-2028 cohort - Wednesday, September 9th, 2026 from 10:00-11:00 on Zoom. Please register to attend. If you cannot make the information session never fear! We always record it, and you can get access to the recording by registering for the session and/or emailing Brandon Walsh.

The Praxis Program is a unique and well-known training program in the international digital humanities, offered by the UVa Library’s Scholars’ Lab. This fellowship supports a team of University of Virginia PhD students each year as they explore various aspects of digital humanities together. Under the guidance of Scholars’ Lab faculty and staff, Praxis fellows conceive, develop, and share a range of digital humanities activities over the course of the year. Our fellows blog about their experiences and develop increased facility with project management, collaboration, and the public humanities, even as they tackle (most for the first time, and with the mentorship of our faculty and staff) new programming languages, tools, and digital methods. Praxis aims to equip fellows with the skills necessary for future research, teaching, and administration within digital humanities.

Praxis training takes a variety of shapes meant to reflect the full-range of DH work. As a part of their training with us, student cohorts regularly publish a range of values statements describing the intentional communities they want to build together. They also design and teach digital humanities workshops based on their own interests as a means to exercise minimalist pedagogical approaches to DH. Students design speculative projects and events that might go on to be implemented with the Lab. They also participate in a range of technical and design activities meant to reflect the range of digital practices they will encounter in their research. At times, Praxis teams have developed and launched specific, named projects. Fellows join our vibrant community and have a voice in intellectual programming for the Scholars’ Lab.

Beginning as a 2011-2013 pilot project supported by a grant from the Andrew W. Mellon Foundation to UVa Library’s Scholarly Communication Institute, the Praxis Program is now generously supported by UVa Library and GSAS. The Praxis Program is a core module of PHD+, a university-wide initiative to prepare PhD students across all disciplines for long-term career success. The work Praxis Fellows undertake over the course of their fellowship year may be submitted in partial fulfillment of the portfolio requirement for UVA’s Graduate Certificate in Digital Humanities and supplements the curricular work undertaken in that program.

Eligibility

The Praxis fellowship comes with an award of $10,000 distributed during the fellowship year. Fellows may work with their DGS and GSAS to determine whether this amount will be taken on top of their base package, or relieve the fellow of a GTA appointment. In either scenario, fellows are expected to devote roughly 10 hours per week to work in the Scholars’ Lab.

All doctoral students at the University of Virginia working within humanities disciplines, on topics demonstrably connected to the humanities, or working in adjacent fields are eligible to apply. Students outside of GSAS or with other concerns should reach out to Brandon Walsh to discuss their eligibility given their particular circumstances.

Applicants must be enrolled full time in the year for which they are applying. In addition, applicants must be capable of attending weekly in-person meetings in both the fall and spring semesters of their fellowship year (though we can certainly accommodate travel needs within reason). We welcome and encourage applicants to discuss how your particular backgrounds and identities, whatever that might mean for you, factor into your unique ability to contribute to the program.

N.b. - Praxis students are not expected to come in with particular technical training or experiences - we cover that over the course of the fellowship year! Prior experience with digital technology is only one part of an application and should not keep anyone from applying. Everyone brings something different to the team, and your strengths in critical thinking about media, collaboration, project development, and more could be great ways for an application to shine. Concerned students are encouraged to reach out to Brandon Walsh, our Head of Student Programs, to discuss their backgrounds or eligibility.

How to Apply

The application process for Praxis is simple! You apply individually, and we assemble the team, through a process that includes group interviews and input from a committee about your application. To start, we ask for a letter of intent (roughly 2 pages single-spaced). The letter should include:

• What brings you to us? - a description of the applicant’s curiosity in the program, (could include a description of proposed use of digital technologies in research if relevant, but interest and curiosity can be valid starting points as well);
• How do you work? - a narrative about how the applicant approaches collaboration and learning;
• What do you bring to the table? - summary of what skills, interests, methods the applicant will bring to the Praxis Program;
• What do you want out of this? - summary of what the applicant hopes to gain as a Praxis Fellow, both in the short and the long term;
• When can you meet? - your availability on the days and times we’ve identified for group interviews: November 30th from 10AM-12PM or December 4th from 1-3PM ET (you will only have to participate in a single hour-long group interview);
• Anything else we should know? - pronouns, a name you go by other than the one on your email, any other experiences or backgrounds you want to make sure we are aware of, or anything else you would like to share.

In addition, we ask for a brief note (a PDF or screenshot of an email is fine) from the applicant’s department chair or DGS stating that they are aware the student is applying for the fellowship and support the application (given that the application can affect teaching rosters).

The best Praxis applications are the ones that go beyond listing the skills and research one hopes to bring or take away from the experience. Instead, focusing on weaving those elements into a narrative of how the program connects to your life plans and how you, in turn, connect to the spirit of the program. We recommend applicants start by reading our charter and a blog post on “Questions to ask When Applying.”

Questions about Praxis Fellowships and the application process should be directed to Brandon Walsh. Completed application materials are due November 1st and can be uploaded through the GSAS application portal. Please do consider this application to be part of a process - the beginning of a conversation about how we can work together. We highly encourage students to write to Brandon Walsh to discuss their interest in the program and how the Lab can contribute to their professional development. Together we can begin to discuss how the Lab can be a part of your time here, with Praxis or otherwise.

We don’t know where you parked your car, but we can help you make a map to retrace your steps. And that’s just the first session! After that, we’ll go beyond basic cartography, covering common GIS operations and techniques in an easy and supportive environment that even the heads can follow.

This semester we’ll primarily be GISing with the desktop GIS software ArcGIS Pro, covering basic use and techniques that will get you comfortable and exploring on your own. If you’re interested in ArcGIS Online, we’ll briefly cover that in the last couple of sessions, and will do a deeper dive in the Spring. Not sure what the difference is? ArcGIS Pro is a Windows-only desktop program that you install on your (Windows) computer. ArcGIS Online is a web-based GIS platform that you access through a web browser on nearly any device. Mark Patterson sums it up well here. Still not sure? As always, feel free to contact us with any questions.

• Sessions are one hour and assume participants have no previous experience using GIS. These will be hands-on demonstrations with step-by-step tutorials. Feel free to pick and choose the sessions you think you’ll benefit from the most
• We will meet in-person in the Scholars’ Lab (Shannon Library 308) on Tuesdays from 2PM to 3PM, and openly welcome the UVA and larger Charlottesville community.
• We will provide laptops for easy access to ArcGIS Pro.
• Walk-ins are welcome, but due to a limited number of laptops, we strongly encourage registering using the links below or at our Events page. If you’re waitlisted, please contact us at uvagis@virginia.edu.
• We will not be offering a virtual option this semester. We apologize for any inconvenience.
• Please note, these workshops are not intended for course instruction. If you’re here at the direction of your professor, or if you’re teaching a class and would like to include GIS instruction, please contact us at uvagis@virginia.edu.

September 8th - Making Your First Map with ArcGIS Pro

Here’s your chance to get started with geographic information systems software in a friendly, jargon-free environment. This workshop introduces the skills you need to make your own maps. Along the way you’ll get familiar with the desktop GIS application ArcGIS Pro, and a gentle introduction to cartography. You’ll leave with your own cartographic masterpieces and tips for learning more in your pursuit of mappiness at UVA.

Register Here!

September 15th - Old Maps and Aerial Photos: Georeferencing in ArcGIS Pro

Would you like to see historical maps overlaid on modern aerial photography? Do you need to extract features of a map for use in GIS? Georeferencing is the first step. We will show you how to take a scan of a paper map and align in it in ArcGIS.

Register Here!

September 22nd - Mapping Your Spreadsheet: Plotting Lat/Lon Coordinates

Do you have a spreadsheet of Lat/Lon coordinates you would like to see on a map? We will show you how to do that and more. ArcGIS Pro makes it easy to take your tabular data and generate stylized points on a map.

Register Here!

September 29th - Mapping Street Addresses (Geocoding), and More Spatial Things

Do you have a list of street addresses crying out to be mapped? Have a list of zip codes or census tracts you wish to associate with other data? We’ll start with addresses and other things spatial and end with points on a map, ready for visualization and analysis.

Register Here!

October 6th - Editing Spatial Data in ArcGIS Pro

Until we perfect that magic “extract all those lines from this paper map” button we’re stuck using editing tools to get that job done. If you’re lucky, someone else has done the work to create your points, lines, and polygons but maybe they need your magic touch to make them better. This session shows you how to create and modify vector features in ArcGIS Pro. We’ll explore tools to create new points, lines, and polygons and to edit existing datasets.

Register Here!

October 13th - Easy Demographics: ArcGIS Pro and Social Explorer

Need to make a quick demographic map? This workshop will show you how easily navigate Social Explorer. This powerful online application makes it easy to create maps with contemporary and historic census data and religious information.

Register Here!

October 20th - Introduction to ArcGIS Online

With ArcGIS Online, you can use and create maps and scenes, access ready-to-use maps, layers and analytics, publish data as web layers, collaborate and share, access maps from any device, make maps with your spreadsheet data, customize the ArcGIS Online website, and view status reports.

Register Here!

October 27th - ArcGIS Story Maps

ArcGIS StoryMaps is a spatially enabled website/application builder that allows you to add narrative and multimedia context to your ArcGIS Online maps (or locational context to your narrative and multimedia content, depending on how your brain works). Whether telling a story, giving a tour or comparing historical maps, ArcGIS StoryMaps is an easy-to-use builder that creates polished presentations.

Register Here!

When I first read Kenny Werner’s book Effortless Mastery: Liberating the Master Musician Within, I was in college studying jazz improvisation and musical performance. At the time, the book was powerful and transformative for its approach to thinking through performance anxiety and imposter syndrome— things I still struggle with in relation to musical performance. Recent conversations about GenAI and digital humanities left me wanting to revisit Werner’s approach to thinking through craft and difficulty.

The central conceit for Effortless Mastery is this: the degree to which we care about an activity can get in the way of our ability to do it. When we care deeply about doing something well, about performing at a high level, this sincere anxiety and the tension that follows interfere with our ability to prepare for the excellence we want to achieve. Approaching our craft with this heightened sense of the stakes reinforces a fraught relationship to our craft that comes out in practice, play, and performance. Effortless Mastery is about choosing a different path, centering mindfulness in our craft in a way that can be practiced. In the prototypical Effortless Mastery exercise, one sits at the piano and only practices a single note for 5-10 minutes a day. The goal is to approach this isolated note with such intention and care that it becomes effortless. Let your finger, in a childlike way, press down on a key with as little tension as possible. Only add new notes when the first one has become the most perfect and effortless thing that it could possibly be. According to Werner, performers will likely find this approach to practice excruciating. We feel like we have too much material to learn. Too much to do—not enough time. But Werner argues that, if approached diligently, his form of practice will actually pay dividends and elevate all parts of our performance. Our relationship to our instrument and to music will improve, and we will find it easier to enter a heightened state of flow and bliss as we perform. There are also affirmations that focus on changing the way you relate to the instrument.

I’m interested in how we can apply the same kind of approach to the work that we do in the academy. In some ways, the concept of effortless practice cuts against the way I tend to teach and write about DH. I’ve argued in the past that frustration is a feature for DH students. Learning is hard in a way that we can’t avoid, and we have to teach students how to live with these challenging emotions. But lately I’ve been thinking about how perception of difficulty can get in the way of our pedagogies, particularly as we all try to reckon with the impact of GenAI on our teaching. When a humanist sits down to learn something new, it can be easy to reach for GenAI as soon as they start to feel frustrated. Is it useful for them to sidestep challenging emotions? Would we rather they sit with the difficulty longer? How do we help students shift their own understanding of what is difficult and what is not? Finally, to talk back to myself, how might it change the possibilities students see for themselves if we framed DH instead as a space of effortlessness rather than one of frustration and difficulty?

The domains are different—how many of us would describe our DH work as a space of artistic bliss? But I still think there can be utility in thinking through the shape of an effortless digital humanities. What is the DH equivalent of putting your finger to a single note? What are the building blocks for all other digital humanities work? And how might we practice these techniques daily in 10 minutes to promote an effortless approach to doing so? To begin answering these questions for myself, I sat down at my laptop and mapped out how this sequence might work in my classroom. In what follows, I map out a way you might extrapolate this kind of approach over the course of a sixteen-week semester, slowly building up a daily practice in the spirit of developing an effortless digital humanities. Try it with your students and let me know how it goes.

Terminal

One of the first things I do when sitting down for DH work is open my terminal, so this is where my daily practice begins. The terminal is an essential tool for so many other DH activities, but it adds a layer of abstraction to learning that can take a while for students to overcome. Here are some ideas for playing one note on the terminal each day. Under each week I describe a sequence of activities meant to be performed daily, early each morning, in about 10 minutes. Each new week adds one or two new elements to the repeated sequence. Only advance to a new week when you feel you can perform the previous week with complete effortlessness. Feel free to repeat weeks. Better to go slow. And be sure to include (or adapt!) the light affirmations that I include. Our primary statement will be one directly from Werner’s text: “It is not hard, it is just unfamiliar.” A few caveats: in what follows, unless otherwise specified, code blocks represent lines that should be entered into the terminal. Throughout this post I am sharing MacOS terminal commands. Programming Historian has some useful lessons for those looking to adapt these for Windows. And, finally, things will, by design, become very repetitive. It is quite possible I will leave out a step while copying things over. Let me know if you find such a thing and I will edit accordingly.

• Week 1:
  • Open the terminal. Say, “I have opened my terminal. It is not hard, it is just unfamiliar.”
• Week 2:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say “I am currently in my user folder. It is not hard, it is just unfamiliar.”
• Week 3:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop. It is not hard, it is just unfamiliar.”
• Week 4:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop. It is not hard, it is just unfamiliar.”
• Week 5:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”
• Week 6:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Change into the new folder with cd test_folder. Say, “I have changed into my new folder called test_folder.”
  • Return to your desktop with cd ... Say, “I have returned to my desktop.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”

For many experienced DH practitioners, these steps would take maybe 10 seconds. But if you’re new to the terminal entirely each of these things could take quite a bit longer and cause a great deal of anxiety. Encourage students to move slowly, repeating each week’s steps regularly moving on to the next step. After several weeks, hopefully, they will feel a greater sense of comfort with the idea of what the terminal is, where to find it, and how to use it. Working incrementally in this way can take something from challenging to rote practice.

Git

Version control systems seem especially good for this kind of regular work. Git and GitHub are tools that students often find very difficult to conceptualize and master, but 90% of what you need to do can be handled by the same set of steps. Perhaps by making Git practice an everyday routine we can make more room for understanding the concepts. The next several weeks will build on the previous terminal sequence.

• Week 7:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Change into the new folder with cd test_folder. Say, “I have changed into my new folder called test_folder.”
  • Make this folder a git repository with git init. Say, “I have made this folder into a git repository.”
  • Return to your desktop with cd ... Say, “I have returned to my desktop.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”
• Week 8:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Change into the new folder with cd test_folder. Say, “I have changed into my new folder called test_folder.”
  • Make this folder a git repository with git init. Say, “I have made this folder into a git repository.”
  • Make a few file in your folder with touch index.html. Say, “I have made a new html file.”
  • Confirm you have a new file to add in git with git status. Say, “I have shown that git acknowledges the new file.”
  • Return to your desktop with cd ... Say, “I have returned to my desktop.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”
• Week 9:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Change into the new folder with cd test_folder. Say, “I have changed into my new folder called test_folder.”
  • Make this folder a git repository with git init. Say, “I have made this folder into a git repository.”
  • Make a few file in your folder with touch index.html. Say, “I have made a new html file.”
  • Confirm you have a new file to add in git with git status. Say, “I have shown that git acknowledges the new file.”
  • Add your new file to your git staging area with git add index.html. Say, “I have added my file to staging.”
  • Confirm you added the file successfully with git status. Say, “Git status shows that I did this successfully.”
  • Return to your desktop with cd ... Say, “I have returned to my desktop.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”
• Week 10:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Change into the new folder with cd test_folder. Say, “I have changed into my new folder called test_folder.”
  • Make this folder a git repository with git init. Say, “I have made this folder into a git repository.”
  • Make a few file in your folder with touch index.html. Say, “I have made a new html file.”
  • Confirm you have a new file to add in git with git status. Say, “I have shown that git acknowledges the new file.”
  • Add your new file to your git staging area with git add index.html. Say, “I have added my file to staging.”
  • Confirm you added the file successfully with git status. Say, “Git status shows that I did this successfully.”
  • Commit your new file with git commit -m 'My first commit. Say, “I am committing my new file to git.”
  • Confirm you added the file successfully with git status. Say, “Git status shows that I did this successfully.”
  • Return to your desktop with cd ... Say, “I have returned to my desktop.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”

At this point, I might have students continue to repeat these steps for several weeks. Again, an experienced practitioner could do this in no time at all. Newcomers will find this to be quite a lot. At some point, after enough days have gone by, things might start to get annoying. Good! You’re experiencing effortlessness. Only add new steps when you feel like what you have done so far is effortless. Remember: it is not hard, it is just unfamiliar.

Building a basic website

At this point, my bulleted list is getting overly complicated, so I’ll simplify things going forward by using shorthand and sandwiching the new steps inside of a “set up” and “clean up” phase. Refer above for the associated commands. It is probably clear where I am going at this stage: I think designing a basic website and understanding how to view it on your computer is another foundational DH skill. And we can make this sequence a very light daily activity.

• Week 11:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Add a new line inside your index.html file that says, “This is a basic webpage.” Describe what you have done.
    • Open that file in the web browser of your choice. Say, “I am viewing my html file in a web browser.”
  • Clean up:
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 11:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Stage your change with git add . Describe what you have done.
    • Commit your change with git commit -m 'Made a change'. Describe what you have done.
  • Clean up:
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 12:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Include the basic skeleton of an HTML page by pasting the contents of this page in index.html.
  • Clean up:
    • Add and commit all changes.
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 13:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Paste the basic skeleton of an HTML page into your index.html. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • It’s a review week. Each day, write down comments, in your index.html file, explaining what one of the lines in the HTML file does.
  • Clean up:
    • Add and commit all changes.
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 14:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Paste the basic skeleton of an HTML page into your index.html. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Each day, write down comments, in your index.html file, explaining what one of the lines in the HTML file does.
  • Clean up:
    • Add and commit all changes.
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 15:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Paste the basic skeleton of an HTML page into your index.html. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Make a CSS file with “touch style.css”. Describe what you have done.
    • Link it to your index.html file by adding the following line within your <head> tag: <link rel="stylesheet" href="style.css">
  • Clean up:
    • Add and commit all changes.
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 16:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Paste the basic skeleton of an HTML page into your index.html. Make a new CSS file and link it to your index file. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Change the background color of your <body> tag to be:

      body{
      background-color: red;
      }
      

    • Save your file. Refresh your browser to see the new page. Describe what you have done.
  • Clean up:
    • Add and commit all changes.
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”

Again, step away from things if at any point the exercise starts to feel like they are causing effort or friction. Reduce what you’re asking yourself to do for the next session. I think you will find if you proceed like this for a week or two you will very quickly develop proficiency with a range of DH building blocks. A webpage with red background (my go-to example for teaching CSS because it is very obvious something has happened) might not feel very exciting to an advanced practitioner, but I would be immensely pleased with a student able to go from nothing to this level over the course of a semester.

These kinds of exercises might feel trite and meaningless, but you can’t put a price on confidence. Effortless fluency and literacy with the basics provide a strong foundation for more advanced study. Spend 5 to 10 minutes on them every day. As Werner would say, “What do you have to lose?” We can all find 5 or 10 minutes, and that unit of time is a small sacrifice that ultimately will not take that much away from other work. Wouldn’t it be great for students to approach their work with a sense of confidence that they can inhabit a DH space that works for them? Exercises like these can help our students make DH a daily part of their lives. Daily work building a personal, effortless digital humanities will prepare our students to face the bigger and more advanced problems they will inevitably face. They will do so with confidence that they can find the answers within themselves and their own process. The next time they reach for a GenAI prompt when faced with a problem, they just might pause and look inwards first.

Shane Lin, Winnie Pérez Martínez, & Jeremy Boggs wrote & submitted an essay on their UVA digital archive work around the events at UVA+Charlottesville August 11-12th 2017, for a library & DH special journal issue on static sites.

Jeremy is reading No! The Art and Activism of Complaining by Sara Ahmed & thinking about what Bartleby the scrivener would do when faced with AI.

Amanda Wyatt Visconti published 3 free teaching zines (94 pages!) in Spring 2026 on censored public history, a book arts method, & exploring creative research funding opportunities.

Drew reworked the footprint of projects highlighting Indigenous benches in Brazil, to help justify their continued preservation despite the departure of the collaborator from the University.

On June 2nd I’ll be giving a workshop for the PHD+ program here on how to develop a sustainable summer writing practice. This session will be one of the opening discussions for a daylong event that asks PhD students to take their research topic and transform it across a range of different formats: podcasts, websites, and zines. The goal for my part is to collect a number of different writing activities to show examples for how one might experiment with writing practice. For me, sustainable writing can be found through regular work, joy, and playing with constraints. To get there, I suggest students do the following:

• Experiment with different formats for writing. For this I discuss otter.ai.
• Distinguish between the different phases of the writing process and sit down with a clear goal in mind.
• Scale up to a daily practice rather than experimenting to start with tons of words each day.
• Incorporate free writing (hat tip to Sean Michael Morris here for his beautiful approach to the craft).
• Incorporate stochastic practice as a means to jolt your creativity. I’ll use Peter Schmidt and Brian Eno’s Oblique Strategies deck here.

I then close with a short activity that asks students to brainstorm the different components for a practice of their own: format, location, frequency, amount, and method. After jotting a few ideas each for each category, I’ll guide them through a discussion of how to remix these components into something that works for them. Slides follow below. The particular deck theme I used was food themed, which felt appropriate.

Shane Lin and UVA Library colleague/SLab alum Jacqui Sahagian typeset a letterpress example at the Virginia Book Arts printshop, to teach an upcoming “Transforming Your Research” workshop for PhD+ students, focusing on creative research practice using historical and current technologies.

Drew & Arin have been working with IATH Fellow Tess Farmer’s Digital Sabils project on Cairo’s charitable water fountains, including Arin live remote troubleshooting a team in Egypt’s 3D artifact scanning, & this mapping work from Drew.

Amanda Wyatt Visconti recently presented on their intersecting DH & letterpress work (including makerspace, coding, & accessibility research as well as creative practice) as a speaker for Partners in Print’s “Print Futures” series.

A quick one today on how I manage my task list each day and the tools I use for doing so.

For years I have used Slack to manage my working life. If you click a single message you can select “remind me later” and select a date and time. I use this religiously, scheduling out reminders for particular times and dates. If I need to follow up on a thing, it gets a date. If I need more time to reply to a message, it gets a date. You can also schedule reminders for yourself separate from messages. So, if I have an overarching task, it gets a date and reminder. It’s not uncommon for me to open slack and get 10 notifications at 9:00 AM that tell me what I am supposed to be doing for the day. Here’s a glimpse at my reminders for today:

This system has worked well for years. I rarely let anything slip, because I just file everything away as a reminder and snooze if necessary. But Slack recently changed how their reminders work. DISASTER. I can’t fully grasp how to reset the way it manages this system, but now it seems to be giving me double alerts for these notifications in a way that collapses them with DMs. It’s deeply irritating. While I’m sure I could figure a workaround, I decided it was time to disentangle this particular tool from my daily task management.

So, I’m experimenting with a physical notebook for the first time in at least a decade. Here’s my daily notebook for today:

I’ve tried such things in the past but never stuck with them for long, but this run seems to be sticking. In part, I think this is because of how I’ve made working with the notebook part of a daily ritual. Each day’s page is broken into three segments: must do, can do, and waiting. I start each day by looking at the previous day by looking at the previous page to see what needs to be moved over. I’ll then check my inbox and shuffle things around based on how answering email goes. This process gives me a sense of things that are urgent and those tasks that require actions from other people. I typically close out each work day by referring to the page once more and updating things. This process is helped along by the fact that I have found a particular set of pens that are deeply, unironically joyful to use. Working with them provides a meditative tactile sensation that grounds my start and end to each day.

Sharing all this is a tad embarrassing. I have discovered writing in a journal! I have terrible handwriting! Pens are nice! But I can’t emphasize enough what a shift this has been for my working life. It’s brought an embodied ritual to each day that I didn’t have before, and I’ve found it surprising how much energy can come from shifting this foundational part of my working rhythm. So, if you’re feeling stuck, it’s never too late to change. Your process can always find new shape if you give it new tools.

Following the advice in Brandon Walsh’s warning, “anything that gets in the middle will keep you from blogging,” I simplified the steps to update and publish my website because the situation was getting a little miserable.

GitHub Pages is a great way to host your static sites free, if you don’t mind keeping your code public. It’s an especially smooth experience if you produce your site with Jekyll because it enjoys built-in support on this hosting platform. In other words, when you upload your Jekyll code to a public GitHub repository and activate GitHub Pages, the site will deploy automatically and become live within seconds (unless something goes wrong).

But I am using 11ty, a JavaScript-based framework, and while it’s common to host other kinds of static websites on GitHub besides Jekyll, it does add some extra steps. I was so close to publishing my website, I really didn’t want to stop for the ideal solution, so I created one main branch for deployment and another deploy one to serve the html files produced after 11ty parsed my root directory. This meant manually copying, pasting, and replacing old html files for newer ones between these 2 branches to keep the site updated. It got old quick. So quick changing this workflow became my top priority issue within the site.

Thankfully, I complained about it to Brandon at the Lab the other week, and he suggested I look for an 11ty version of a “Rakefile,” a document he uses to include custom website build and deployment instructions in his Jekyll website. Some digging pointed out that GitHub Actions might be the easiest way to go.

Using Actions involves changing a setting in your repository, a 1-line edit to your package.json, and a YAML file describing your desired build and deploy workflow for GitHub Pages to host your site. True, I didn’t know what my desired workflow file should look like, but Google turned up a useful Mini-Tutorial in the 11ty documentation that explains the full deploy process and shares a YAML example ready for you to copy and use within your web project.

This worked, but I really didn’t know what was going on in the file at all, so I asked Claude Code 2.1.109 to make me a deploy.yaml file to deploy my 11ty site on GitHub Pages. The file that came out, frankly, works just as fine for my purposes the sample one. One notable difference was the simplicity of Claude’s YAML vs the sample one in the official 11ty documentation, which is thorough and filled with many options to understand.

I stuck to using the sample YAML in 11ty’s docs because it’s safer and adds caching to the deploy workflow, for example.

I kept the simpler Claude Code deploy until I felt that I had a general sense of what was going on in the file. GitHub’s “Workflow Syntax” page was key to understanding what is going on in the file, and what the commands mean. It’s messy, though, and hard to navigate. I skimmed through 75% of it before I found the answer to one of the questions that bothered me the most: “What the heck is that actions/setup-node@v4 doing?” I knew it was setting up Node.js version 4, somehow, but how? Turns out it’s accessing and serving a contained version of Node used by through GitHub Actions to parse and deploy my 11ty site.

name: Deploy
on:
  push:
    branches: [main]

concurrency:
  group: pages
  cancel-in-progress: true

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - uses: actions/configure-pages@v5
      - run: npm run build
      - uses: actions/upload-pages-artifact@v3
        with:
          path: ./_site

  deploy:
    needs: build-and-deploy
    runs-on: ubuntu-latest
    permissions:
          pages: write
          id-token: write
    environment:
      name: github-pages
      url: $
    steps:
      - uses: actions/deploy-pages@v4
        id: deploy

Figure 3. Code block with the simpler GitHub Actions workflow generated by Claude Code 2.1.109 to build and deploy my 11ty website. A.k.a. deploy.yaml

Brandon Walsh has been elected co-VP/Presidents Elect of the U.S.-based, international-membership digital humanities scholarly org, the Association for Computers & the Humanities!

I recently got word that my manuscript for Embedded Pedagogies: Digital Humanities Teaching and the Infrastructure of Change was accepted for publication with Open Book Publishers. As exciting as this is, there is still much work to do. I could not have asked for more thoughtful and generous peer reviewers, but even thoughtful and generous feedback still takes time to incorporate. One reader’s report especially requires a kind of work that used to give me a lot of difficulty when I was a graduate student. The substance of the report was that there were two critical conversations with which I needed to engage more deeply. The reader suggested thoughtfully that I needed to incorporate those conversations that critique the field of librarianship (#critlib especially) if I wanted to claim librarian as an identity. The other critique: my writing on artificial intelligence felt a little thin and needed to be built out. Also very fair. I hadn’t actually anticipated writing about AI, but it does feel more and more urgent the more time passes. Despite my own reluctance I found myself needing to read much more about generative AI.

So, here I have two areas in which I need to read more deeply. Such critiques can feel very overwhelming and abstract, and it is helpful to find ways to make them smaller and actionable. Experience has helped me towards a system that works for me, so I thought I would share a few thoughts here on my workflow for this research and revision process. While each step below does build on the others, I typically think of each phase as a separate component. I try to stick to a single goal when I sit down at my desk (or stand at my treadmill—more on that below).

Gathering

First, I gather a list of citations to explore. I might drop a bunch of links in a word doc, open a range of tabs, or print a stack of texts. The anonymous reviewer above suggested the #critlib Zotero library, which turned out to be an extraordinary resource. Reading through a collection of articles here took me to the Critical Library Pedagogy Handbook. Exploring that resource took me to the Journal of Critical Library and Information Studies. And working through that material took me on a deep dive into In the Library with the Lead Pipe. In each case, I started by skimming titles and abstracts just to get a sense of what could be relevant.

Reading

I read 2-3 articles per day from the stack created during the gathering phase (after all, one can only take in so much per day). As I go, I typically underline some things, underline and star others, and then underline and star and write CITE in capital letters next to others. At the end, I’ll make a few notes at the top of the article about whether or not the thing seems useful and about where I see the material fitting into the book. I typically do this work on the treadmill, which I mention for no other reason than to note how important it is for me to associate particular kinds of work with particular spaces and practices. In this way, my “to read” pile gradually morphs into a “read but needs to be transcribed” pile.

Lifting and Transcribing

At this point, I shift back to my computer. I have three folders there: “to transcribe,” “to integrate,” and “done.” For each article that I have read, I create a blank word document titled with the name of the author. I transcribe that article’s quotations with page numbers into its corresponding holding document, and I also assemble the actual, formatted citation for my references list. As this point, I am typically done with the actual, full text of the article. It exists for me only as a series of quotations, a citation, and a few notes to the effect of “mention in Chapter Three when you talk about the interview” or “more of an explanatory footnote than an actual citation to Chapter Four.”

Integrating

Only now do I actually open the manuscript itself. Given that is revision work for an actual, already extant manuscript, I typically have a pretty good idea of where things are likely to fit in and be useful. This phase involves integrating the new material into my text, stitching things together, and rewriting whatever components were complicated by the new references. Sometimes, this process is fairly seamless. Other times, this process involves substantial rewriting in light of the way the citations change my thinking about particular ideas. After the initial pass at integration, I make a note about the page numbers where I have revised new material. That way, I have a better sense of which pages to focus on during later editing.

Proofing

In this final phase, I make sure to return to things with fresh eyes. I will read more broadly than just the sections I have surgically edited, and I’ll hope to see where things fit, where they don’t, and what other edits might be needed to make things flow together. But the pages listed in the previous phase help me know where to focus.

Each of these phases feeds the others, so I am constantly moving forward. I feel as though I am making progress, and I also feel as though the big abstract task of reworking my argument to fit more closely into a particular critical conversation is more manageable and more doable. Importantly, each of these segments requires a different kind of work in ways that I appreciate. Transcribing and creating a citation require far less mental energy for me than reading or integrating. I welcome these variations.

Hopefully this is useful for seeing how I go about the revision process. Keep an eye out for Embedded Pedagogies, the text of which will be available print on demand and freely online. I am so grateful for the particular anonymous reader I describe above. It’s been enjoyable to dig into broad areas that overlap with my work but that were not top of my mind. I’ve learned a lot, and I think my work is much stronger for it.

Brandon Walsh’s 1st book, “Embedded Pedagogies: Digital Humanities Teaching and the Infrastructure of Change” is forthcoming from Open Book Publishers!

Brandon Walsh presented on adaptive makerspace tech & some of our digital collecting projects, for our local historical society’s event at a retirement home.

Will Rourk directed a team of students, Fluvanna County community, & architecture preservation professionals in completing the documentation necessary to nominate the ~1935 Evergreen African-American School as an official historic site with the Virginia Dept of Historic Resources.