Digital History Seminar
History 8550 is an advanced graduate seminar designed for students to produce original digital scholarship that advances historical arguments through computational methods. Building on foundational digital history skills, this course guides students through the complete process of conceiving, developing, and executing a significant digital history project.
Students will work collaboratively with the instructor and their primary advisor to design a project that employs digital methods to make meaningful historiographical interventions. Unlike traditional seminar papers, the final projects in this course are multifaceted, typically including a documented dataset created from primary source research, computational analysis code, and a substantial written component of 7,500 to 10,000 words that integrates findings with existing scholarship.
The course is structured around key milestones that scaffold the research process, beginning with project planning and literature review, moving through dataset creation and methodology development, and culminating in peer review and project presentation. Students will engage with current debates in digital history, learn best practices for reproducible research, and develop skills in project documentation and scholarly communication.
The governing principle of this seminar is that digital history work is sequential. Datasets must be complete before analysis can begin, and analysis must be substantially underway before you can formulate an argument and write seriously. Everything in the schedule is built around protecting that sequence. You do not want to reach November without a finished dataset.
- Design and execute original digital history research that uses computational methods to advance historiographical arguments and make meaningful scholarly interventions.
- Create and document historical datasets from primary sources using methodologically transparent and reproducible research practices.
- Integrate digital analysis with traditional historical scholarship by producing substantial written work of 7,500 to 10,000 words that synthesizes computational findings with existing literature.
- Apply best practices for scholarly communication in digital history, including project documentation, peer review processes, and presentation of digital scholarship to academic audiences.
Hardin Hall 004
- No books to purchase — all readings are online, through the library, or on Canvas.
- A GitHub account.
- An AI coding assistant. Clemson ChatGPT is free and is the course default. Claude Code is an optional paid alternative and is what the instructor will use.
We meet Wednesdays from 5:45 to 8:15 pm in Hardin Hall 024. Readings are due the day of the session they appear under. Written milestones are due at the time noted in the Due this week box for that week. Several weeks have no seminar meeting and are reserved for dataset construction, drafting, and individual conferences. Those weeks are not optional time off, they are the working core of the course.
W01Aug 19Welcome and Project FramingIntroductions, semester overview, and a first pass at everyone's project.Proposal›
Wed · Aug 19
- Be prepared to introduce your project’s topic and to discuss with the class the methods and data you plan to use.
Readings
- Stephen Robertson and Lincoln Mullen, “Arguing with Digital History: Patterns of Historical Interpretation,” Journal of Social History 54, no. 4 (2021): 1005–1022. This is the introduction to Models of Argument-Driven Digital History, which we return to on September 16th. Read it for the taxonomy of argument types and come prepared to say which one your project is reaching for.
- Booth, Colomb, Williams, Bizup, and FitzGerald, The Craft of Research, 5th edition, Chapters 3–4 (available online through the library). “From Topics to Questions” and “From Questions to a Problem.”
Assignment
Send your advisor an email with a one to three paragraph description of the project you propose to tackle for this class. Copy me and ask your advisor to sign off on this topic for your digital seminar paper. Your description should outline the following:
- Your topic and the relevant historical context and historiography
- The question you are trying to answer
- Your data and sources for the project
- The proposed method you plan to use
- The proposed output for the project, and who you imagine its reader to be
W02Aug 26Project ProposalsWorkshop discussion of everyone's project description.Questions›
Wed · Aug 26
Assignment
- Read your classmates’ proposals and generate one to two questions for each of them. Submit to Canvas before class and be prepared to discuss each proposal in the room.
Due this week
- Tue · Aug 25 — project description posted to Slack and Canvas by noon, matching what you sent your advisor
- Wed · Aug 26 — questions on classmates’ proposals submitted to Canvas before class
W03Sep 2Individual ConferencesNo seminar meeting. One-on-one conferences and dataset work.One-on-one›
Wed · Sep 2
- No seminar meeting. Schedule a one-on-one meeting with me for this week. Otherwise, work on your datasets.
W04Sep 9Data, Sources, and ViewsFrom source to schema to view. Wireframing and prototyping workshop.Prototype›
Wed · Sep 9
Before class
- Bring an example of a primary source you plan to use. Be prepared to discuss your plans for constructing a dataset from that source base.
- Look at two of the example projects listed in this syllabus and come prepared to name one thing each interface reveals and one thing it hides. Nothing to write up.
In class
- Source and schema. What constitutes one row of your data, and what does your source actually contain?
- Interfaces and arguments. Discussion of the readings and of the transparency checklist below.
- Sketch, then prototype. Wireframe on paper first, by hand, before touching any tool. Then use Claude to build a clickable prototype from your sketch.
- Report out. Show your view and state in one sentence what it argues.
Transparency checklist
These are design constraints, not suggestions. We will use them as the basis for critique and they are a starting point, not all encompassing.
- Every view should be linkable so that a reader can cite it.
- Show the n. A reader should know how many records underlie any view.
- Make missing data visible rather than silently dropping it.
- Never let the interface imply precision your sources do not have.
Readings
- Mitchell Whitelaw, “Generous Interfaces for Digital Cultural Collections,” Digital Humanities Quarterly 9, no. 1 (2015).
- Johanna Drucker, “Humanities Approaches to Graphical Display,” Digital Humanities Quarterly 5, no. 1 (2011).
- Cameron Blevins, “Digital History’s Perpetual Future Tense,” in Debates in the Digital Humanities 2016 (2016).
Assignment
- Revise the prototype you started in class and submit it along with a short written component. Full details will be distributed in advance of this session.
W05Sep 16Making Historiographical InterventionsSituating the project in the literature, and checking the prototype against the argument.Lit reviewPrototype due›
Wed · Sep 16
In the second half we will pull your mockups back up. Does your prototype argue what your historiographical intervention says you are arguing? If your prototype is essentially a search box, that is a useful diagnosis rather than a failure, and it usually means the argument is not yet sharp enough. We will work on closing that gap.
Before class
- A two to three page overview of your project as it relates to the literature in your field.
- A list of sources, divided into primary and secondary.
- Read your classmates’ overviews and be prepared to discuss in class.
Readings
- Booth, Colomb, Williams, Bizup, and FitzGerald, The Craft of Research, 5th edition, Chapters 5–7 (available online through the library).
- Sharon Block, “What, Where, When and Sometimes Why: Data Mining Two Decades of Women’s History Abstracts,” in Models of Argument-Driven Digital History.
- Look at one more article in Models of Argument-Driven Digital History and be prepared to discuss it in class.
Due this week
- Tue · Sep 15 — historiography overview and source list posted to Slack and Canvas by noon
- Wed · Sep 16 — prototype and write up posted to Slack and Canvas
W06Sep 23Dataset ConstructionNo seminar meeting. Build your dataset and schedule a conference.One-on-one›
Wed · Sep 23
- No seminar meeting. Work on your dataset and code. Schedule a one-on-one meeting with me sometime between today and October 9th.
W07Sep 30Dataset CompleteNo seminar meeting. Dataset milestone, then move on to code.Dataset›
Wed · Sep 30
- No seminar meeting. Build against the specification you developed during the September prototype exercise, and revise it as your sources push back. Those revisions are not failures, they are the substance of your data biography.
Due this week
- Wed · Sep 30 — dataset complete, or ideally earlier, and you should be moving on to writing code for your project
W08Oct 7Progress Reports and Writing StrategiesWhere everyone stands, and how to move from analysis into prose.Reverse outline›
Wed · Oct 7
Before class
- Create a reverse outline of Maureen Flanagan’s article “Gender and Urban Political Reform: The City Club and the Woman’s City Club of Chicago in the Progressive Era,” American Historical Review 95, no. 4 (October 1990).
- See Zach Schrag’s “How to Write an Outline” on HistoryProfessor.org.
Due this week
- Wed · Oct 7 — reverse outline due at the start of class
W09Oct 14DraftingNo seminar meeting. Fall break falls Monday and Tuesday. Write.First draft›
Wed · Oct 14
- No seminar meeting. Fall break runs Monday, October 12 through Tuesday, October 13. The university is open and Wednesday classes are unaffected, but we are not meeting this week regardless.
Due this week
- Fri · Oct 16 — first rough draft due by 11:59 pm
W10Oct 21Individual ConferencesNo seminar meeting.One-on-one›
Wed · Oct 21
- No seminar meeting. Schedule a one-on-one meeting.
W11Oct 28Individual ConferencesNo seminar meeting.One-on-one›
Wed · Oct 28
- No seminar meeting. Schedule a one-on-one meeting.
W12Nov 4Progress ReportsSecond drafts due, with code and analysis close to complete.Second draft›
Wed · Nov 4
Readings
- Lynn Hunt, “How Writing Leads to Thinking,” Perspectives 48, no. 2 (February 2010).
Due this week
- Wed · Nov 4 — second rough draft due by 5:30 pm, between 5,000 and 7,000 words, with code and analysis complete or nearly so
W13Nov 11DraftingNo seminar meeting. Work on final drafts.—›
Wed · Nov 11
- No seminar meeting. Work on your final drafts.
W14Nov 18Peer Review in Digital HistoryWhat review looks like in this field, and how to do it on GitHub.Full draftReader report›
Wed · Nov 18
In class
- What does peer review in the field of digital history look like?
- How is digital peer review different?
- Peer review assignments and an overview of how to use GitHub for peer review.
Readings
Read the three sets of review guidelines below as a baseline for our discussion. As you read, think about what we might add or change for digital scholarship.
- Programming Historian, “Reviewer Guidelines.” Note that they use open rather than blind review, and that reviewers are credited in the byline.
- Journal of American History, “Digital History Reviews.”
- Digital Humanities Quarterly, “Peer Reviewing for DHQ.”
- Barbara Y. Welke, “The Art of Manuscript Reviewing: Learning from the Example of Peggy Pascoe,” Perspectives on History (September 2011).
Due this week
- Wed · Nov 18 — complete project drafts due
- Tue · Nov 24 — peer review reader report due by 5:00 pm, emailed to the person you are reviewing with me copied
W15Nov 25ThanksgivingNo seminar meeting. Holiday runs November 25 through 27.—›
Wed · Nov 25
- No seminar meeting. The Thanksgiving holiday runs November 25 through 27.
W16Dec 2Scaling UpLooking ahead to the dissertation, and a technical check on every project.Tech check›
Wed · Dec 2
- Looking ahead: scaling up and beginning to think about the dissertation.
Assignment
Final Project Tech Check. Submit your GitHub repository to Canvas so that I can confirm the project runs on other devices. Before submitting, make sure all paths are relative and that any files, data, or other materials the project needs are included in the repository.
Due this week
- Wed · Dec 2 — GitHub repository submitted to Canvas for tech check
W17Dec 9Digital History SalonSeminar paper presentations at 4:00 pm.PresentationFinal paper›
Wed · Dec 9, 4:00 pm
- Seminar paper presentations. Roughly 15 minutes each followed by roughly 10 minutes of questions and discussion.
Due this week
- Wed · Dec 9 — presentation at the Digital History Salon
- Fri · Dec 11 — final papers due by 11:59 pm
Digital History Project and Paper (70%) ›
You will complete a substantial digital history project that demonstrates mastery of computational methods in historical research. The final project may take one of two primary forms.
- Option 1. Digital History Article. An article-length piece of writing that employs digital methods to make a historiographical interpretation. This format integrates computational analysis directly into traditional scholarly writing. Examples can be found in journals like Current Research in Digital History, the Journal of Digital History, or the Journal of Cultural Analytics.
- Option 2. Digital History Project and Website. A digital history project and website based on original historical research with a substantial written component. This format creates a public-facing digital resource while maintaining rigorous scholarly standards. Look at examples like America’s Public Bible, Religious Ecologies, Mapping Early American Elections, or Mapping the Gay Guides.
These two options account for most of the types of projects students might undertake in this course. However, if you have an idea for something that doesn’t fit these categories, talk to the instructor. These are by no means the only forms of digital scholarship.
Regardless of the format you choose, all projects include three core components.
- Dataset. A documented dataset built from primary source research. It must include a data biography explaining your methodology and should be hosted in its own GitHub repository, which can be private if necessary for ethical or copyright reasons. The specific structure and format will vary depending on your methodology and will be discussed in consultation with the professor.
- Code. Computational analysis code appropriate to your chosen method, whether that is data manipulation, text analysis, mapping, network analysis, or something else. All code should be well commented, reproducible, and hosted in a GitHub repository with transparent documentation of the methods used.
- Written component. A substantial written analysis of 7,500 to 10,000 words that integrates your digital findings with existing scholarship. The format will be determined in consultation with the professor based on your chosen project type.
Presentation of Digital Project (10%) ›
Participation, Peer Review, and Written Work (20%) ›
Throughout the semester you will complete drafts, peer reviews, and other written assignments that scaffold your final project. These milestones are outlined in the schedule and should be posted to Canvas and Slack as noted. This portion of your grade includes the following named components.
- Weekly participation in seminar discussion and workshop sessions.
- Prototype.
- Peer review reader report.
- Drafts and other written milestones as noted in the schedule.
Grading scale ›
- A 94–100%
- A− 90–93%
- B+ 87–89%
- B 84–86%
- B− 80–83%
- C+ 77–79%
- C 74–76%
- C− 70–73%
Artificial intelligence use policy ›
AI is changing the field of digital history rapidly. You will have access to an AI coding assistant throughout the term and you should use it to help you generate code for your project as necessary. We will talk throughout the semester about what it means to use AI in an ethical way as a part of digital history research and you’ll develop your own ideas about how AI should or should not fit into your own work. However, there are some ground rules which are in keeping with the Digital History Ph.D. program’s Artificial Intelligence Policy, which can be found in the graduate handbook. I take these ground rules extremely seriously and any use of AI which violates these principles will be treated as academic dishonesty and handled in accordance with the Graduate School’s policies.
Use AI freely for:
- Writing, debugging, refactoring, and explaining code. Note that you must be able to read and explain the code if asked, so don’t allow it to build without being deeply involved.
- Setting up environments and resolving installation problems.
- Understanding technical documentation.
- Transcription, extraction, or other similar tasks.
You remain responsible for:
- Whether the output is correct, and being able to demonstrate how you know.
- Whether the method suits your sources and your question.
- Every historical claim you make on the basis of a computational result.
If you cannot explain what a piece of your code does, and why it makes the choices it encodes, you do not yet own it and it is not ready to submit. This applies whether you wrote it, an agent wrote it, or you found it on the internet in 2010.
Written analysis is your own. Any written analysis (aside from technical documentation) you submit should be your own writing and your own thinking. Using AI to draft that prose is not permitted. The analysis is where you demonstrate historical judgment, and outsourcing it defeats the purpose of the assignment and of the degree.