Main »

Writing Abstracts In The Digital Humanities

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.
  • Try the question/challenge out early on others. Ask them what
  • 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. There is no sympathy for poor grammar.
  • Gather references.

What to put in

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 to 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 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 paper then provide an answer or suitable response to the challenge?
  • 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?
  • 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. None the less, 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? It is relevant if you don't have a lot of experience or have limited experience, but tell us and move on. 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 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 auto-biography.
  • Proposals about projects that haven't done anything, especially proposals about projects that just got funded and they are really telling us that they 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 and learn about the field.
  • 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).

Navigate

PmWiki

edit SideBar

Page last modified on November 30, 2015, at 01:23 PM - Powered by PmWiki

^