(Note: Brandon is going to blog about related work! Will link here once that’s live.)

This is a post to tell yall about a neat little web development thing that’s allowed me to easily make (and keep updated!) nifty things displaying kinds of data related to both professional development (easy CV webpage and printable format generation!) and bibliography/book arts (an online type speciment book, based on an easily-updatable Gsheet backend!). If you aren’t interested in the code, do just skim to see the photos showing the neat webpage things this can make.

Figure 1: Screenshot of a type specimen webpage created with Jekyll and a CSV of data.

Figure 2: Screenshot of a CV webpage created with Jekyll and a CSV of data.

Jekyll (skip this section if you know what Jekyll is)

Jekyll is a tool for making websites that sit in a middle ground between using a complex tool like WordPress or Drupal (a content management system, aka CMS) or completely coding each page of your website in HTML by hand, and I think easier to create and manage than either extreme. It’s set up to follow principles of “minimal computing” (aka #mincomp), which is a movement toward making technical things more manageably scoped with an emphasis on accessibility for various meanings of that. For example, using website development tools that keep the size of your website files small lets folks with slow internet still access your site.

If you want to know more about Jekyll, I’ve written peer-reviewed pieces on the what, why, and how to learn to make your own Jekyll-generated DH websites—suitable for folks with no previous web development experience!—as well as (with co-author Brandon Walsh) how to turn that into a collaborative research blog with a review workflow (like how ScholarsLab.org manages its blog posts). Basically, Jekyll requires some webpage handcoding, but:

• takes care of automating bits that you want to use across your website so you don’t have to paste/code them on every page (e.g. you header menu)
• lets you reuse and display pieces of text (e.g. blog posts, events info, projects) easily across the website (like how ScholarsLab.org has interlinked blog posts, author info, people bio pages, and project pages linking out to people and blog posts involved with that project)

DATA PLOP TIME

The cool Jekyll thing I’ve been enjoying recently is that you can easily make webpages doing things with info from a spreadsheet. I am vaguely aware that may not sound riveting to some people, so let me give you examples of specific uses:

• I manage my CV info in a spreadsheet (a Gsheet, so I have browser access anywhere), with a row per CV item (e.g. invited talk, published article)
• I also keep a record of the letterpress type and cuts (letterpress illustrations) owned by SLab and by me in a Gsheet

I periodically export these Gsheets as a CSV file, and plop the CSV file into a /_data folder in a Jekyll site I’ve created. Then, I’ve coded webpages to pull from those spreadsheets and display that info.

Figure 3: Screenshot of my letterpress specimen Gsheet

Data Plop Op #1: Online Letterpress Type Specimen Book

You don’t need to understand the code in the screenshot below; just skim it, and then I’ll explain:

Figure 4: Screenshot of some of the code pulling my letterpress Gsheet data into my Jekyll webpage

I include this screenshot to show what’s involved to code a webpage that displays data from a CSV. What this shows is how I’m able to call a particular spreadsheet column’s data by just typing “”, rather than pasting in the actual contents of the spreadsheet! LOTS of time saved, and when I edit the spreadsheet to add more rows of data, I just need to re-export the CSV and the website automatically updates to include those edits. For example, in the above screenshot, my CSV has a column that records whether a set of letterpress type is “type high” or not (type high = .918”, the standard height that lets you letterpress print more easily with different typefaces in one printing, or use presses that are set to a fixed height). In the code, I just place “” where I want it in the webpage; you can see I’ve styled it to be part of a bullet list (using the “<li>” tag that creates lists).

In the screenshot, I also use some basic logic to display different emoji, depending on what’s in one of the CSV columns. My “uppercase” column says whether a set of letterpress type includes uppercase letters or not. My code pulls that column (“”) and checks whether a given row (i.e. set of letterpress type or cut) says Uppercase = yes or no; then displays an emoji checkmark instead of “yes”, and emoji red X instead of “no”.

Here’s how one CSV line displayed by my specimen book webpage looks (I haven’t finished styling it, so it doesn’t look shiny and isn’t yet live on my very drafty book arts website):

And I was also able to code a table version, pulling from the same data:

If the code discussion is confusing, the main takeaway is that this method lets you

1. manage data that’s easier to manage in a spreadsheet, in a spreadsheet instead of coded in a webpage file; and
2. easily display stuff from that spreadsheet, without needing to make a copy of the data that could become disjoint from the spreadsheet if you forget to update both exactly the same.

Data Plop Op #2: Keeping your CV updated

I used to manage my CV/resume as Google Docs, but that quickly turned into a dozen GDocs all with different info from different ways I’d edited what I included for different CV-needing opportunities. When I had a new piece of scholarship to add, it wasn’t clear which GDoc to add it to, or how to make sure CV items I’d dropped from one CV (e.g. because it needed to focus on teaching experience, so I’d dropped some less-applicable coding experiences from it) didn’t get forgotten when I made a CV that should include them.

UGH.

A happy solution: I have 1 CV Gsheet, with each row representing a “CV line”/something I’ve done:

I periodically export that CSV and plop it into a Jekyll site folder. Now, I can do 2 cool things: the first is the same as the letterpress specimen book, just styling and displaying Gsheet data on the web. This lets me have both webpages showing a full version of my CV, and a short version of my CV, and theoretically other pages (e.g. code a page to display a CV that only includes xyz categories):

And! I’ve also coded a printable CV. This uses a separate CSS stylesheet that fits how I want a printed CV to look different from a website, e.g. don’t break up a CV line item between two pages, don’t include the website menu/logo/footer. Same text as above, styled for printing:

When I need a whittled down CV that fits a page limit, or that just shows my experience in one area and not others I’m skilled in, I can just make a CSV deleting the unneeded lines—my spreadsheet ahs category and subcategory columns making it easy to sort these, and also to tag lines that could appear in different sections depending on CV use (e.g. sometimes a DH project goes under a peer-reviewed publication section, or sometimes it goes under a coding section as I want my publication section to only include longform writing). But I add new lines always to the same core Gsheet, so I don’t get confused about what I’ve remembered to record for future CV inclusion where.

I currently don’t have this CV website online—I just run it locally when I need to generate a printable CV. But I’ll be adding it to my professional site once I have a bit more time to finish polishing the styling!

In conclusion

Jekyll + CSV files =

(One of the letterpress cuts recorded by my specimen book Gsheet/webpage, as discussed above!)

In the leadup to planning our pedagogical workshops for the Praxis year, I explored a variety of methods and concepts. With my background in Geographic Information Systems (GIS), I naturally expressed interest in mapping as maps present a unique story and can facilitate new questions in research. I was also interested in digital storytelling, because as a historian, history is about presenting a narrative about the past that helps answer questions about the present, and hopefully knowing about history can impact our future. Ultimately, I decided to settle on digital storytelling, that also incorporates maps.

Drawing from the Digital Pedagogy in the Humanities site, it describes digital storytelling as the process of creating and sharing stories using digital tools, incorporating multimedia elements such as images, sound, and words in a narrative that is disseminated online. I really like the term used within the prompt for storytelling called remix. Remixing takes existing material and alters it and combines it to create something new. My own interpretation of digital storytelling is understanding and reinterpreting people, places, objects, or events in their proper context.

I am also connecting these definitions to my personal goals for the workshop. Earlier in the semester, one of our sessions asked us to state our goals for the workshop. One of my goals is a workshop that empowers participants to think on their own behalf and not rely solely on my instruction. A second goal is that my workshop will encourage collaboration among the participants. A third goal is I see more of a facilitator, so my goal is to help guide the conversation during my workshop versus being in teacher mode only. A fourth goal is to incorporate real-life experiences into the workshop. My final goal is to embrace the silences or vagueness of sources that come with research.

In the first part of the workshop, I will briefly present the opportunities available for digital storytelling drawing on my own experiences of using ArcGIS StoryMaps to present a narrative. For instance, a few years ago, I developed a class project Visualizing Segregation in Orlando: 1887-1950 where I used StoryMaps to visualize narrative segregation in Orlando, Florida. My StoryMap incorporated maps, images, and text that provided an interactive way to learn more about the history of segregation during the Jim Crow era. My brief presentation will open an opportunity to discuss techniques in digital humanities. There is more than one way to tell a story, so this portion also will provide an avenue for others to present their own ideas about digital storytelling. We will discuss questions like, what are good components that should go in a story or how should the order of a story be. (Also, based on conversations with Brandon, Tropy could serve as another digital tool, but still need to explore more before the workshop presentation).

In thinking about something simple, something familiar to me, and something that incorporates maps, my low-tech workshop will focus on digital storytelling influenced by our experiences on Grounds at UVA. As a graduate student, with my first year at UVA being entirely online due to COVID, my interactions on Grounds have largely been limited to select buildings and locations on grounds where my graduate classes were or where I held my discussion sessions. Even now, there are areas of Grounds I have never been. The low-tech activity thus will incorporate a printed map. Using a map like the UVA Visitors Map (second page), attendees will individually use colored dot stickers to mark building locations or general spaces on grounds where they frequently interact. Additionally, attendees will write short descriptions that describe these interactions in more detail such as what buildings or spaces we have interacted with, the frequency of these interactions, and our typical experiences there.

The last part of the activity will be collaborative exercise. After each person finishes their edited maps and written descriptions, they will hand these materials to another person. Now that each person has someone else’s sources (data), you will then see to draft a narrative about that person based on the evidence provided, and afterward, each person will share their narrative. As most stories we read about are often told second-hand, this activity will provide the attendees the opportunity to be creative and innovative in creating narratives about people we either have become familiar with or barely know. We can then conclude by thinking about the narratives we just created about each other but think of them digitally. One central question would be, what digital methods and tools are available to enhance these narratives (objects, images, sounds, etc.)?

In conclusion, I brainstormed various ideas for my workshop. Yet the process left me feeling very overwhelmed and anxious, not about presenting the workshop itself, but about finding the right idea and the right project that was low-tech. In meeting with Brandon, I had a moment of eureka where I decided to focus on being simple and work with what is familiar to me and not overcomplicate things. There is the popular phrase, Keep it Simple, Stupid (KISS) thought to have been coined by Kelly Johnson, a lead engineer for Lockheed Skunk Works, who argued that designs for products should be constructed simple enough that a common man could repair them with basic training rather than risking people’s lives with complexities. I plan to take this phrase to heart, but since I do not wish to insult the intelligence of anyone, I will change the last word to scholars. Keep it Simple, Scholars. It will make your life much easier.