Module 1

Having now survived Module 0, congrats–you now have the two major skills you need to do well in this course and in digital humanities work broadly: patience and persistence!  There was a lot to juggle last week between getting new accounts set up, working with new technical skills, and our theoretical introduction to new modes of thought in the readings.  

Tone is hard when we’re all online, and even in past face to face versions of this class students often have worried that I think they’re asking a dumb question or that they should know better when they stumble on part of an assignment.  There are no dumb questions.  I want you to do well, and I want you to even enjoy the process a little bit.  My undergrad class is getting lots of bitmojis of me cheering this semester for this reason, but you guys are only going to get this one, so cherish it.

Miriam Posner, one of the leading lights in digital humanities pedagogy, has this philosophy for her DH classes which I share:

1. This is not a contest.  The only way to win is for everyone to win.  If you finish early, watch Slack to see who else needs help.  You guys have already done a great job with this by answering each others’ questions when I’m not available or forming working pods to help each other.
2. You are not bad at technology.  Technology is not one single thing; it’s a lot of different skills and you can excel at some while not enjoying others.  Some things will come easier to you than to others, and some things will be more difficult.  Part of the process of this course is identifying your own strengths that you’re not even aware of yet.
3. Your mistake is almost certainly very minor.  People stumble over all kinds of small things, like not being able to find where a file was saved, not being able to figure out how to open a new file, or a minor typo in a link or code.  This is always fixable!  Many of us stumbled over minor typos in the pretty links, or in the names of our html or css files.  This is ok!  If something doesn’t work, take a step back to proof read or have a friend proof read–often something as small as a misplaced quotation mark can break a link or a piece of code.
4. No one is an expert in everything.  The point of this class is to get an overview of major skills so you can decide what you enjoy and what you want to specialize in.  It is ok if one module isn’t your thing.

The image below, of the Venn diagram of our perception of our own knowledge vs others, is true of a lot of academic work but it’s especially true of DH work.  You don’t see others’ struggles–you often only see their end product while you’re struggling trying to get there.  Just because you didn’t see their struggle doesn’t mean it didn’t happen.

I’ve said this to many of you individually, but I will repeat it ad nauseum this semester until you can hear me whisper this over your shoulders: troubleshooting is the most important skill you need for DH work.  One of my goals for this class is to equip you with enough theoretical grounding and language to describe what you’re trying to do that you can troubleshoot your way to a solution even if the technical details for the tools we’re working with in this class change.  

As an illustration of this, I mentioned last week that I’m significantly re-doing the Maps assignment for Module 8.  (It’s not done yet, but don’t worry, it will be soon).  The technical details of the problem aren’t important, but the general outlines of it are the kind of troubleshooting I hope you all come away from this class with.  I know what kind of skills I want you all to practice with the assignment I’m writing, but some of the platforms I prefer to teach with have changed the way they handle some things since the last time I taught this course in 2019.  They can still Do The Thing, but it’s just a matter of figuring out how and how to get it done in a way that is (relatively) painless for you all.  (This is a very important aspect of teaching with technology that we’ll talk about later in the course).  Figuring out how to solve this problem was a matter of trying many variations to figure out where the problem was occurring, reaching out for help, and finally realizing that the big pain in the ass work around wasn’t necessary because the way the problem displayed in one place didn’t affect the end product.  Sometimes troubleshooting is also a matter of figuring out the technical limitations of your chosen platform and working around them to do what needs to be done (see, for example, my biannual Twitter meltdowns about the garbage limitations of Blackboard).

You will probably never have to write another HTML page by hand for the rest of your career (unless you’re into that kind of thing).  But there are some basic principles I want you to take away from that assignment going forward:

• Web pages are made of component elements that you can read.  We’ll use this later when we start pulling data off web pages.
• Files can talk to and modify each other.  We’ll use this later when we start writing programs to fetch and extend data.
• You can write code!  Sometimes it’s fussy and it may not be your favorite thing, but you can do it!

This coming week in Module 1, you will be working with your discussion groups to record a roundtable or podcast style discussion of one future week’s readings.  If you haven’t already done so, you should coordinate a time to meet via Zoom or other platform with the other members of your group to record your discussion, and read all of your group’s assigned materials before meeting.  Pre-planning will make your discussion much smoother.  Before meeting, identify 2-3 main points you all want to make sure to discuss.  You have each others’ emails, you can direct message on Slack, and you can make your own private channels on Slack to help you coordinate. 

See the Module 1 page for further details on structuring and editing your discussion.  It’s often very helpful to have a designated “moderator” to help move things along.  Do not summarize the reading; think of this more as framing what your group finds most interesting or provocative about the assigned material so that you can shape what the rest of the class will respond to.

Additionally, I take everyone’s privacy and comfort very seriously.  If even one member of your group does not wish to show their face, please opt for an audio-only format or video recording with a place holder for that person or people.  If even one person in the group prefers to have the recording hosted privately, let me know and we’ll arrange to put it up on Blackboard where only members of our class will be able to see it.

Other than your discussion starter material, you have no assigned reading this week.  You have a brief assignment on working with data in spreadsheet format, but I promise it will not be as time consuming as the HTML assignment was.  I will be available on Zoom during Monday office hours, our Wednesday afternoon scheduled meeting time, and throughout the week on Slack and email to help troubleshoot the assignment or discussion recording issues.  If you or your group aren’t sure about something in your assigned reading, please feel free to drop by Zoom or come chat on Slack.