Skip to content Skip to navigation

A guide to writing DH conference submissions

This year I’ve had the opportunity to try to convince a number of graduate students — both at Stanford and beyond — to submit something to the international DH conference. I’ve been to every North America-based iteration of the conference since 2007, as well as a handful of the European ones, and especially for early career scholars it’s hard to find a better place for getting a broad sense of the field, ideas for possible directions for your own work, and a different kind of interdisciplinary feedback on your projects.

I really appreciate what the DH 2020 program committee has done this year with streamlining the submission process. The word limit is shorter, which makes it more feasible to get a submission together. If anything, it might involve a struggle to be concise. With the exception of long presentations, the maximum word count for any submission type (posters, lightning talks, short presentations, panels, and forums) is 500 words, about one page. But in the course of these conversations with grad students, I’ve been reminded that it’s not the length that’s the barrier, it’s the feeling of writing in an unfamiliar style if you’ve never submitted something to a conference before. You can find many examples of abstracts that were submitted to the DH conference online (e.g. this from the 2019 conference), but not everyone finds it easy to parse their structure. 

Since the deadline for DH 2020 has been extended to October 22nd, here’s a brief guide to writing a DH conference submission. In addition to attending the conference for years, I’ve also been a reviewer for about a decade, and with the caveat that I’ve tended to submit things in the less-harshly-reviewed infrastructure/organization/DH-about-DH categories, I’ve never had a submission rejected.  Especially as the conference gets bigger and more difficult to get into, though, your mileage with these tips may vary.

Pick Your Format

The folks I’ve talked to tend to gravitate towards long or short paper presentations. They’re the most familiar format based on experience with in-class presentations, or at disciplinary conferences. The problem is that the long paper in particular is highly coveted by people who probably have had a lot more time immersed in the field, its discourse, and their piece of pushing that work forward (i.e. senior scholars). Long papers are described as “deal[ing] with substantial completed research, report[ing] the development of new methodologies; or present[ing] rigorous theoretical, speculative, or critical discussions”. For the close reading crowd, that description should be a big deterrent to grad students, especially when contrasted with the short paper, which is "appropriate for reporting on works in progress, limited scholarly interventions, or for describing a singular tool or project… Short presentations are eligible for the Fortier Prize, which explicitly recognizes early career scholars’ work.” The short paper description essentially has a big GRAD STUDENTS: SUBMIT THINGS HERE sign. But because of that, and the possibility of the Fortier Prize (which isn’t open to other formats), short papers also have a higher bar for acceptance.

Personally, I’m a fan of poster presentations. I’ve submitted more posters to the conference than any other format. If you have a poster at the conference, the poster session gives you an opportunity to talk to lots of different people about your work (which itself is a useful experience, even beyond what you might learn from those conversations). Honestly, posters may be the format that gives your work the greatest exposure: while some sessions have packed rooms, others are sparsely attended — whereas there are no parallel sessions opposite the poster session, and in recent years, posters have been hung up near the refreshments for the duration of the conference. In my non-English “DH Across Borders” class, we talked about poster design. While the DH venue gives you an opportunity to be very creative with your poster (you can even sew it in the form of a dress and bring a skeleton to wear it!), here's an exhaustive, detailed guide to making a poster if you haven’t made one before. You can also print it on fabric (for cheaper than on paper, as little as $18+shipping) on sites like Spoonflower to make your travel less annoying.

Lightning talks are a relatively recent format: a 5 minute "presentation of a single project, idea, technology, or problem. It is intended to either solicit feedback from peers or to advertise the release of a new project, dataset, or tool.” It requires less work than making a poster, and gives you a dedicated audience. For grad students who want to present their work in some form, but don’t want to compete for a short paper slot or wrangle a poster, a lightning talk is a good option.

I’m also fond of panels (with multiple speakers who "focus on a single theme and [are] inherently coherent in presenting a substantial body of research or a research question”)  and the new forum format (which “focus[es] on a single thematic or methodological challenge and [is] designed to facilitate a conversation at large with the digital humanities community”), but they take a lot of work to put together the necessary group of people, and aren’t ideal to undertake a week before the deadline. You need to have relationships with people outside your own institution, which is harder for grad students who haven’t been to many conferences or engaged with the broader DH community in other ways. But if you go to the DH conference and have a topic in mind for a panel / forum for a future year, keep an eye out for people who might be interested in joining you.

Paragraph 1: What's Your Problem

When writing a conference submission, the first paragraph should provide some context and catch the reader’s interest. Your presentation should be motivated by some problem. Is there a set of documents that are illuminating for our understanding of something, but they’ve been largely overlooked? Are there major shortcomings in widely-used tools that are impeding some kind of research — or do tools not even exist yet? Do we have a poor understanding of how some literary phenomenon works? Are there sub-communities within DH that could have a fruitful exchange but they’re not connected? Is sustainability and archiving for DH work still a major issue? (Believe me, it is.) Start off your submission by explaining what your problem is.

You also should use this part of your submission to contextualize your problem within DH and/or within your disciplinary field. If you’re talking about how there isn’t a good tool available for a particular method, say a few words about related tools that are out there and how they don’t quite do what you need them to do. If you’re saying that scholarly work hasn’t been done on a certain topic, mention (and cite) similar work that’s been done, and if it’s not obvious, how what you’re doing is different. You want to use this section both to engage the reviewer’s interest and curiosity and, more subtly, anticipate and preemptively deflect possible objections (e.g. where a somewhat naive reader of your work might ask “but what about…?”) It may help to read through the reviewer guidelines before you write this paragraph, because it ties directly to at least 50% of the evaluation.

For a DH conference, it’s worth adding in a few words to explain your references; this will be different for disciplinary conferences, where you can more safely assume that everyone shares more common knowledge about the specifics of your field. For instance, if I were submitting a paper to a Slavic conference, I could just reference A.A. Zaliznjak’s work on Old Novgorod dialect without further explanation. If I wanted to mention that same thing as part of a DH submission, I’d need to explain that he was a leading historical linguist who worked on a series of documents written by and for “ordinary people” between the 11th and 15th centuries, which show a particular set of interesting dialectal traits.

Paragraph 2: What're You Doing About It?

In the first paragraph, you’ve defined some kind of problem. So what are you doing to address that problem? This is the paragraph where you get to talk about your work in a broad way. While the first paragraph is the place to describe previous work that’s been done (scholarship published, tools written, projects undertaken) with a connection — if somewhat tangential — to your work, the second paragraph is the place for you to mention work that you’re specifically building on, expanding, etc. For instance, if you’re doing an extension of something that your advisor started, you can cite your advisor’s work in the second paragraph. Without getting too sidetracked, if there’s an interesting origin story for the project (e.g. how an international partnership came together), you can briefly mention it here, too.

You may be concerned that your project is in too early a stage to submit to the conference. It’s true that if you just have an idea, and you haven’t done any work yet to test out how feasible it is, and you’re not sure what a rough timeline for it will be, it’s a risk to submit it to the conference. But if your project is underway, you have a good handle on the technology and source materials (as relevant), and what you really need to get it done is a little more time and the motivation of a deadline, you can write your abstract with some degree of future projection. You want to be a little bit subtle about it, so it doesn’t sound too much like vaporware, but you can say things like “this project is analyzing…” — even if, in reality, you’re still in the middle of data cleaning, and the analysis is still a few months away.

Paragraph 3: What're You Actually Going to Present?

After you’ve spent a paragraph describing the broad contours of the project and how it’s going to address the problem you specified, you can wrap up your submission by narrowing your focus to what you’re actually going to present at the conference. The first two paragraphs can be reworked slightly from other forms of writing (e.g. grant proposals), but the third paragraph probably needs to be written specifically for this submission, because it needs to map to the submission type you’ve chosen. If you’re putting in a lightning talk proposal, the third paragraph should be succinct: you only have five minutes to present, and saying you’re going to cover an unrealistic number of things in those five minutes will count against you. For a poster or short paper, I’d suggest limiting the number of topics you say you’ll cover to three, or four at the absolute most if you can signal that one of them is brief and straightforward. If you’re submitting a short paper, think about what you actually could realistically cover in ten minutes. For a poster presentation, what could you fit onto a poster and still have it be readable? This is where the benefits of the poster format really become evident: while you should limit what you claim the poster itself will cover, your individual conversations with people who come up to talk to you during the poster session can vary widely, and may go into much more depth than you would’ve been able to cover in a short paper session.

DH Conference Quirks

The reviewers and attendees for the DH conference may be a little different than what you expect from a disciplinary conference. It’s not just faculty, students who aspire to be faculty, and sometimes librarians: there’s a mix of people in a wide range of job positions, with lots of different types of experience. There’s different kinds of librarians, programmers, sysadmins, general-purpose “alt-ac” folks, editors at presses, grant officers, infrastructure people, etc. Far from everyone is a programmer, or would even necessarily self-identify as “technical”, but DH is the place where you can — and should — be specific about the technology you’re using rather than glossing it over with marketing-speak (“state-of-the-art NLP algorithms!”) or generalities (“some NLP code”). Marketing-speak comes off sounding suspicious, and generalities can come off sounding like you don’t actually know how your project works. You don’t need to go into excruciating detail about every single part of your technical stack, but you shouldn’t be shy about saying “Jupyter notebooks” or “Omeka” or “Spacy”. If you’re collaborating with someone else on the technical aspects of your project, ask for their help in writing a sentence or two about the technology.

Angsting About Metadata

I always forget this aspect of DH conference submissions until I’m actually entering them in the system: you have to select terms from a set of controlled vocabularies. These fluctuate from year to year, and the DH 2020 committee has made some significant changes. You should check out the taxonomies in advance and think about how to frame your paper. Your choice of metadata directly impacts who will review your paper, and the folks who tend to do the “text mining and analysis” papers tend to be different (and more interested in a greater level of technical detail) than the "scholarly editing and editions development, analysis, and methods” crowd, even though both groups may be working with the same texts. But I wouldn’t suggest trying to game the system too far, especially if this is your first conference. If you keep going to the international DH conference, you’ll eventually get a sense for what group is the best fit for your work.

In Conclusion

If you’re at all interested in the “how” of digital humanities, the international DH conference is a wonderful place to geek out on those aspects of your work that would get you yawns or glazed-over stares at your disciplinary conference. There’s a number of formats that are particularly well-suited for work in progress, for graduate students, and for folks new to digital humanities. If you’re in North America, this is the closest the international conference will be until at least 2022, and the organizers of DH 2020 are working hard to make it more affordable than some previous (and future) years. There’s still plenty of time to write up 500 words (one page) before Tuesday, October 22nd — so give it a try!