Writing Abstracts in the Digital Humanities
This is an outline to a workshop I've given on how to write an abstract for a digital humanities conference. The workshop was for Humanities Computing students. See also the Common Outlines for Abstracts.
This is a very short guide that covers:
- How to find out about conferences
- Where to find examples of conference abstracts
- How to go about writing a proposal
- What to put into a conference abstract
- What not to put in and what to ask yourself about
Where to find out about conferences
The two major conferences in our field are:
To keep abreast and learn about upcoming conferences you should subscribe to HUMANIST. This is THE SINGLE BEST LIST IN THE FIELD for hearing about conferences in a timely fashion. The list is moderated and posts on similar subjects are clumped to make it easy to skip what you aren't interested.
Where to find examples of conference abstracts
To see examples, go to past conferences (the more recent the better.) See what people are saying about your topic. For example:
I have examples of my own and from students that you can see.
How to go about writing an abstract
Here are some thoughts on writing an abstract:
- Start early - before the CFP comes out if you are working on a project. That way you can quickly do what you decide to write up rather than writing an aspirational abstract. Writing abstracts should be part of the rythm of your research.
- Develop an organizing question or challenge. Try the question/challenge out early on others. Ask them what they think would go in a paper that answers the question.
- Check with people who might have a stake in your research. Should you add people as a co-author? Do you need to check with other people that were part of the project?
- Give yourself time to proof read the abstract before submitting. There is no sympathy for poor grammar.
- Gather references.
What to put in an abstract:
I have a very specific outline that I follow that works. It is not the only way to write an abstract, but it is one successful way.
- The proposal should start by identifying the question or challenge which will be addressed.
- The proposal should provide a context for the question/challenge such that the reader understands the importance of the question.
- The proposal should then summarize how the presentation will then address the question. What will actually happen in the presentation? Will technology be demoed or not? Here is are some possible parts to a response to a question/challenge:
- Background to the problem/project
- Theoretical discussion of the questions addressed
- Prior work by others or by your team
- Demo of the project
- Results of an assessment or evaluation of the project
- Next steps or aspects of the project that haven't been done and will be done next
- The proposal should then elaborate on the key parts of the presentation.
- End with references.
Obviously different types of projects will have different types of outlines. Follow this link to see some other common outline patterns.
What not to put in and what to check:
It is a good idea to check your abstract before submission. Here is a check list:
- Is there a clear question or challenge that will be addressed? Will the presentation (though not necessarily the abstract) clearly provide a reasonable answer or suitable response to the challenge? Don't ask a question and then outline a presentation that doesn't deal with it.
- Will the work reasonably be done by the time of the presentation?
- Can the reader infer what will actually happen in the presentation if accepted? Don't snow the reader with random stuff just to impress them.
- Will there be a demo, and if so, is it clear what will be demoed and how?
- Have you listed all the people who should be listed as authors? Are you giving appropriate credit to collaborators and sources of support?
- Have you discussed similar work? Have you recognized what work came before?
Here are some things that irritate me in abstracts, no matter how well written. I should add that I and others have done every one of these things. One reason for warning you is that I have given and heard too many weak papers that do the things mentioned below. Others may feel differently. For that matter, some people can do these in ways that are interesting so don't take these as rules. In fact, breaking the rules well is something we all should do. Nonetheless, I offer these for graduate students new to writing abstracts who may want to be think about how their work will be received by senior members of the field.
- Proposals which are about how you aren't a digital humanist. Why are your presenting at a DH conference then? You can tell us if you don't have a lot of experience or have limited experience, but tell us and move on. Don't wallow in it. Don't tell us to ask for forgiveness if your paper is poor. Don't apologize for being uninteresting - apologies are even more uninteresting.
- Proposals which are about how you got into the digital humanities and your personal background. We all have personal stories - Why would we be interested in yours? There are important moments when you need to explain the orientation or perspective you bring to the project, but that should not be the whole paper unless you are really good at autobiography.
- Proposals about projects that haven't done anything, especially proposals about projects that just got funded and you are really telling us that you got funded. Boasting is not sharing research.
- Proposals from people outside DH that are patronizing and assume that we haven't thought about programming, or ethnography or design etc.. Knowledge from other fields is welcome, but don't patronize us when you haven't bothered to learn about the field of DH.
- Proposals about instructional technology projects that don't discuss whether the project was assessed in any way.
- Proposals without any recognition of work that has come before (ie. no bibliography and no research into what others are doing). You are never the first. If you are creative you can always find projects that prefigured yours.
Think of research as a conversation to which you are going to contribute to. How can you connect to what others are saying? How can you say something they would be interested in at this point?
