How to write a (Digital Humanities) abstract? Lessons Learned from Reviewing

Writing abstracts and conference submissions is a key element of academic life, yet, I find that there is little guidance for those new to the activity. There are many things to know that will (in my experience) drastically increase your chances of getting accepted. Acting as a reviewer teaches you a lot about becoming a better writer, just like evaluating applications teaches you how to write good applications. However, only very few young academics actually get the opportunity to see the other side of the process. Usually, evaluation work is dominated by more senior academics, leaving newcomers dependent on their guidance, support, and mentorship. But not everybody has equal access to dedicated mentors with enough time on their hands to help teach you these basics effectively.

It’s a flaw in our academic system that we invest so little time and energy in training but it’s not the individuals’ fault – the system simply doesn’t value activities that don’t result in a direct output on your CV, i.e. necessary and vital academic care work. Well, that’s what you get for living in a society of unequal power relations that does not value care work.

Anyway, that’s where this blog post comes in. In it, I will try to outline abstract writing best practices that I have learned from being a reviewer (and of course, some experience writing abstracts myself and learning from more established peers).

Standing on the shoulders of giants for the basics of abstract writing

In this post, I want to reflect on writing article and conference reviews, covering both the perspectives of being a reviewer and being a submitter. I think it makes sense to discuss both in a single blog post due to their significant overlap. This was inspired by Quinn Dombrowski’s great blog post about writing abstracts for the DH conference, updated for 2023. I will first summarize Quinn’s excellent arguments briefly and offer some insights of my own. I did not contribute to DH this year and will most likely not attend. However, I have acted as a reviewer and love how much one can learn from the open review process, especially by observing other reviewers’ comments and their reactions to submissions (which can vary greatly from one’s own impressions – that in itself is a key takeaway: there are many possible reactions to the same piece of writing).

You can read more on How to Write a Paper or Conference Proposal Abstract and Converting your class paper into a conference presentation.

As Karen Kelsky summarizes, abstracts are formulaic and need to contain the following elements (try one sentence each, Kelsky’s original post also has examples):

1) big picture problem or topic widely debated in your field.
2) gap in the literature on this topic.
3) your project filling the gap.
4) the specific material that you examine in the paper.
5) your original argument.
6) a strong concluding sentence.

These are the basics that I often refer to as the “abstract triad” (topic/relevance, gap/probem, solution/hero narrative). But that alone isn’t enough. (Also, it would be mistaken to believe that just knowing about this structure will automatically make you know how to package your own research that way. It takes practice.)

How to use the ‘Abstract Triad’ to make your proposal more convincing

1. Topic Relevance: Begin with a sentence explaining the topic and its relevance. Ensure it’s clear to people unfamiliar with the subject, highlighting why it’s important.
2. Gap in Literature: Identify a gap or urgent problem in the existing literature. Explain what has been overlooked, why it needs addressing now, and how filling this gap will change the field’s perspective.
3. Hero’s Narrative: Describe how you plan to solve the identified problem.

When you’re writing your own abstract it’s hard to know what to look out for. When I was starting out with academic writing, I had no idea how any of it really worked (although I think I was a bit misguided and thought otherwise). Now I feel like I understand it more and more because of my increasing experience and also, acting as a reviewer myself. I can tell what I don’t like about somebody else’s abstracts and thus know how to make mine better, hopefully. So one of the goals of this article is to give an insight on what I have been thinking while acting as a reviewer for DH2024, so that you can learn from other people’s mistakes.

Quinn Dombrowski’s guide to writing a DH abstract

Quinn Dombrowski has recently made an updated blogpost about How to Write an ADHO DH Conference Proposal in 2023 (there used to be an earlier 2019 version). It adapts the advice given in the earlier blog post reflecting changes in the review criteria for the conference. Led by Christof Schöch, the review criteria revision aimed to develop a set of reviewing guidelines for long-term use that aim to elicit constructive feedback and require reviewers to justify their numeric choices through text comments.

The evaluation criteria are the following (and give a good guidance for what to include in a good abstract, the text after the colon is an explanation by me but there are also the official explanations):

1. Description of current state of knowledge and best practices in relevant areas, backed by useful references (20%): “How does this fit into topics and discourses that DH as a field is interested in?”
2. Contribution beyond current state of knowledge and best practices (20%): “What’s new about your stuff?”
3. Detailed description of your approach or method within the limitations of the abstract format (20%): be technical (as in concrete) but don’t overdo it, an abstract shouldn’t be a laundry list of code libraries you used.
4. Contribution to diversity in topics, approaches, perspectives, and recognition of work by disadvantaged or under-represented groups (15%): Partially contributes to the “What’s new?” aspect but also helps diversity, gotta love it. Totally Ninja-approved criterion.
5. Submission structure and clarity (15%): Check the criteria and stick to them.
6. Overall recommendation based on evaluation criteria and additional considerations (10%): This can help clarify whether the reviewer wants your contribution to be accepted, as this can sometimes be hard to tell when there are lots of comments (does that mean it’s bad or was it just so engaging that the reviewer had lots to say?).

For workshops, the criteria are slightly modified to focus on the content and didactical approach of the workshop.

Dombrowski provides advice on structuring a DH submission, considering the disciplinary context, providing DH context through citations, detailed description of the work, and the stakes or importance of the project, and also advises on handling proposals for unfinished projects (don’t use the future tense) and encourages participating in the conference because it is hybrid and thus, an opportunity to present to the international DH community, even when you can’t afford to travel to Washington.

Quinn has also written the aforementioned blogpost about how to write abstract a few years ago that may still be helpful (A guide to writing DH conference submissions) that broadly discusses what I often refer to as “the abstract triad” (for example here under “Pitch a Hero Narrative” or see Karen Kelsky, How to Write a Paper or Conference Proposal Abstract).

Make your project sound interesting and relevant

You always need to convey what makes your project interesting, significant or unique (even if it’s likely not all that unique in all of its aspects). Here are some key points to consider, following Quinn Dombrowski’s advice:

1. Start with an Overview: Provide a general description of your project. What are you working on? The novelty could be some standard digital humanities method applied to a new corpus, archive, or subject matter.
2. Highlight What’s Special: Explain what makes your chosen corpus, archive, or subject matter unique, important or interesting. Is it understudied? What knowledge would it provide if studied the way you suggest?
3. Relevance: If your project relates to important debates or issues in your discipline, explain these clearly. Remember that your reviewer may come from a different disciplinary background, so pretend to explain to an educated but non-specialist person.
4. Context Matters: Be aware that there are varying academic cultures and contexts, so explain where you’re coming from and what theories and assumptions you use in a way that can be understood by someone outside your narrow field.
5. Contribution to Diversity: Consider how your project contributes to diversity in the DH field. This could be in terms of subject matter, methodology, linguistic diversity, or audience. Be explicit about this contribution to assist reviewers in recognizing this aspect in their evaluation.
6. End with the Stakes: When concluding your abstract, Dombrowski recommends to reiterate the stakes of your project. This involves clearly articulating why your work is important, what new perspectives or knowledge it brings, and its relevance to scholars who may not work in your exact area or who might only share a few methods with you.

Novices give themselves away by too much detail or not enough

As a reviewer, it is apparent to me that newcomers often assume reviewers have deep knowledge of their topic, which isn’t always the case. Explaining sufficiently is crucial, but often feels like over-explaning ( but there’s a fine line to being condescending). Especially for technical content, balancing detailed technical explanations with humanities stuff such as relevance (answering the question “So what?”) is key. Understanding the conference audience is also important; for instance, technical aspects will be judged differently for the DH conference compared to the Computational Humanities Research Conference (CHR). I plan to write another blog post reflecting in 2024 on my 2020 post about CHR, reassessing my views after attending in December 2023.

Obviously, all of my actual reviews and whom I reviewed is totally confidential, but I can say this much: Sometimes you can tell, for example, when the person whose work you’re reviewing is new to academic writing or these abstracts. This often shows itself in that they’re very much in their head and assume that everybody else knows as much about their topic as they do, but they don’t. That was definitely a mistake I personally made all the time. It’s still kind of hard balancing making your writing accessible to novices but not offending experts by explaining in patronizing ways. So if that’s a mistake you tend to make, please know that it’s a learning process and everybody makes these mistakes. Even after you have been informed of this fallacy, you are still likely to continue with the trial and error. It doesn’t magically go away. It takes practice.

Anyway, your reviewers can be pretty far away from what you’re doing, even though they’re in the same field, and actually, they may not even be in the same field as you. So always over-explain. That was one of the hardest things for me starting out, to explain it in a way that somebody from outside my field could understand it, but it’s crucial that you do that. If you’re writing something technical, it’s important that you include the nitty-gritty details (as far as they’re relevant), but I also saw one submission this year that was the exact opposite, i.e. the text was just nitty-gritty details and not enough explaining its relevance for the (digital) humanities.

Try to answer questions like “Why is this new or interesting?”, “Why should anybody come to your talk (even if they don’t work on your topic)?”, “How does it contribute to diversity?”, etc. and (over-)explain the relevance, especially of details pertaining to your discipline because your reviewer might not know a lot about where you’re coming from. Be sure that you don’t lose them by not explaining enough, even though some explanations may seem ridiculously basic to you as an expert on your niche topic. Due to the many submissions, even a relatively well-fitting reviewer probably will share less of your context than you may expect – after all, they can’t give you someone who is too close to you (for example through shared projects or affiliations). Thus, to ensure this, the committee may end up picking reviewers a bit further out of your scope than you would have anticipated. Make sure they can still follow.

Talk about technical details more than you would for your disciplinary colleagues but also, don’t list every detail. If you do that, most likely you’ll run out of characters for explaining why people should care. And this cannot be left out!

As Quinn puts it

In short, you don’t have to define what NLP is, but the trade-off is that your reviewer will want you to say specifically what you’re doing and “text analysis” won’t cut it. (source)

You can request a technical reviewer at the ADHO DH conferences now but I think there are some implications to that (that I will elaborate on in another blog post at some point).

Towards the end of this blogpost, I’ll go into more detail on the “more detail or not enough” questions but since it seemed a bit redundant, I moved this to the end, in case you’re still interested.

Common criticisms in (DH) abstract reviews

I will list a few very common mistakes or criticisms with hopefully enough background that you can understand them alright. Afterwards, there’s another lengthy discussion on one typical novice mistake (too much detail or not enough) that hopefully becomes understandable through the longer narrative (as it isn’t a straightforward issue).

But now, without further ado, here are some of the most common criticisms, sorted into types. Some points are somewhat redundant but maybe this helps giving you an idea of what can go wrong. These are all inspired by actual criticisms I gave or saw in reviews. I did not copy anything verbatim (and if I did in some case, then it is by mistake and was not my intention). However, the sentences may relate closely to some reviews I saw or wrote myself.

You need to back up your claims

1. Lack of References: The abstract lacks bibliographic references, to the technologies mentioned and their developers or to debates and previous implementations in the DH community.
2. Lack of Scholarly Literature and Bibliography: The submission lacks references to scholarly literature and does not provide a bibliography, making it difficult to assess their grounding in the current state of knowledge.
3. Backing Up Claims: The paper makes significant claims but needs to substantiate these with relevant references and methodological details.
4. References: References are crucial for grounding arguments and demonstrating awareness of existing debates and workflows. The absence of references is a significant shortcoming, especially for a long paper intended for substantial and completed research.
5. Insufficient Bibliography: A more comprehensive bibliography is necessary. = Lack of discussion on related works and current state of the field. Absence of references to significant contributions or papers. Insufficient bibliography on the topic.

You need to situate yourself within the research tradition

• Lack of Related Works Discussion: The submission does not discuss related works or the current state of the field, omitting references to significant contributions or papers.
• Engaging with DH Debates: The abstract does not engage with current debates in digital humanities or acknowledge similar projects in digital scholarship. This engagement is crucial for situating the project within the broader DH context. Without them, it is unclear how the research contributes to the field of digital humanities. The proposal should demonstrate how the use of digital methods is significant to the research and the broader DH community.
• Situate the Project within a Research Tradition: The project needs to be situated within a specific research tradition, explaining its significance and relevance to the field. This involves giving examples and contextualizing the research problem the intervention addresses.
• Lack of Context and Citations: The submission lacks sufficient context to understand its place in the current state of knowledge. It is very short, without citations, and provides little insight into approach, method, or argument.

Use the abstract triad to create an effective introduction that situates your work within the field and demonstrates how it contributes significantly to filling a research gap or addressing a research desideratum.

Depending on the type of submission, you need to present results or show the impact of your work

• Programmatic Nature of Abstract: The abstract is programmatic, i.e. promising much without providing concrete examples or evidence of its use or effectiveness.
• Related Work and Conclusions: Including sections on related work and conclusions would enhance the structure and comprehensiveness of the submission.
• Research Status and Suitability for Conference: The research appears to be in progress or at the proposal stage, rather than being substantial, completed, or involving significant new methodologies. This is not in line with the expectations for a long presentation at the conference. Be aware of the different requirements for various submission types. Long presentations typically require substantial and completed research, as opposed to work in progress. Short presentations or posters may have different criteria.
• Project Report: The paper primarily reports project activities without drawing meaningful conclusions or exploring their significance.

You need to be concrete

• Absence of Concrete Examples and Case Studies: There are no concrete examples or case studies illustrating how the suggested intervention has aided scholars. Inclusion of screenshots or code snippets to demonstrate the platform’s functionalities would be beneficial.
• Insufficient Information on Intent and Content: The submission lacks detailed information about its objectives and content, making it difficult to determine the exact focus of the work.

To be accepted in and relevant for a DH conference, you need to find the sweet spot between Humanities relevance and technical detail

1. Lack of Clarity on Target Audience and Relevance: The abstract fails to clearly define the specific sub-field of DH or the intended audience for which the method/tool is relevant. You need to explain the research desideratum the tool responds to and its relevance for an international audience.
2. Insufficient Focus on Humanities Methodologies: The abstract is overly technical, with insufficient emphasis on humanities methodologies relevant to the project.
3. Questionable Suitability for DH Conference Audience: The level of technical detail (too little or too much) might not be of interest to a broader DH audience. The abstract should be revised to make the work more accessible and relevant to the DH community, potentially considering other conferences more aligned with the project’s focus (thus, a disciplinary conference or a more tech-minded conference).
4. Relevance: The tool appears relevant to DHers, but the proposal could benefit from more specific examples to illustrate this relevance.

Stick to formal guidelines and produce a readable abstract

• Need for Better Structure and Clarity: The abstract requires significant restructuring for readability and relevance. It should include an introduction that provides context and motivation for the project, explaining terms and methodologies that may not be familiar to all DH audience members.
• Readability and Technical Background: The submission is well-written and understandable, requiring some technical background to fully appreciate it (thus, maybe make it a bit easier to follow for non-specialists). The reading flow can be improved by getting to the point faster and being less dense.
• Visualizations: For papers with dense material, consider developing less confusing ways to visualize complex data.
• Structure: A paragraph outlining the structure and content of the actual presentation, including what the audience can expect to learn from it, should be included.
• Lack of Clear Structure and Bibliography: The paper lacks a clear structure, a bibliography, and an explanation of unfamiliar acronyms. Unfamiliar acronyms are introduced without clarification.
• Inconsistent Formatting and Redundancy: Inconsistent formatting and repeated key points detract from clarity.

Your work should be new and diverse

• Limited Diversity: The focus is primarily on Western European studies, with limited attention to non-hegemonic languages or broader diversity aspects.
• Why? Unclear need for developing a new research tool without comparison to existing solutions.

Explain your methods in sufficient detail

Many submissions fail to provide adequate detail on the methodologies used, including the specific technologies and approaches employed. This makes it challenging to evaluate the technical implementation and credibility of the work.

Submissions frequently fail to provide clear references and details for claims made, such as when you’re the first to combine certain tools or methods, or lack specificity in describing how tools are applied.

1. Methodological Details: The paper needs to specify the methods used, such as the machine learning models, and provide details on the analysis, including materials digitized and the treatment of output.
2. Methodological and Technical Gaps: There is a need for more detail on how these methods relate to and support the research question. The proposal lacks specific information about the digital methods employed, including details about their implementation and relevance to the research objectives. The author should include more details about the digital methods used, how they are applied, the results they show, and their contribution to advancing digital humanities.
3. Corpus Description and Selection: Details about the corpus used for analysis, including its collection, digitization, OCR process, representativeness, and potential biases, are missing or unclear. Detailed information about the corpus of documents, including period, format, biases, and pre-processing steps, is necessary for understanding the feasibility and potential gaps in the research pipeline.
4. Clarity and Precision: The proposal lacks clarity and precision, making it difficult to assess the reliability of the results. Clear descriptions of the research pipeline and expected outcomes are needed.
5. Lack of Methodological Argument: The abstract outlines functional requirements but lacks an argument on how these were elicited or formally defined.
6. Contextualization in Technical Papers: Technical papers should be accessible even to those not deeply familiar with the technologies. In a digital humanities context, it’s important to provide enough background to make clear why your contribution is significant and what problem it addresses. Additionally, consider including lessons learned that are relevant to scholars outside your specific sub-field.

If requesting a technical review, ensure that your proposal includes sufficient technical detail and specifications on the implementation or you may find their evaluation is not very good.

However, I also think that technical reviewers can sometimes be harsher than more big-tent-y Humanists (so think about if you are likely to truly benefit from a technical reviewer). I will explore my feelings about different reviewing traditions in a future blog post.

Some more takeaways from acting as a reviewer

In the case of my reviews, which obviously remain confidential (I’m gonna say it so cryptically that nobody can know what I mean), there were two people who I suppose were early career scholars. I think I’m kind of writing this blog post also for them (and others like them). Or maybe past me. Who knows. Anyway.

Get technical but don’t forget the why

One of them was somebody who wrote something very technical, and as I said earlier, it’s good to be technical at DH conferences. However, this was so technical that it was a lot of technical detail. I think it was directed at developers in the digital humanities (people who would be interested in why you chose certain libraries and technologies). There are lots of developers in the digital humanities, but I think it’s very unlikely that you get those as a reviewer. (Research software developers are often employed in projects and accordingly probably take on less unrelated service work like reviewing, at least I think so, or may not even be allowed to do that as part of their paid work.)

Anyway, to me, the submission felt like “Okay, you list all these technologies. I’m sure you put a lot of work into picking them out. But do I really care? No.” This person seemed really passionate and really knowledgeable, but the way this was communicated to me just didn’t make any sense. I’m sure this person knows the why. But they simply didn’t state it and to me, it was not obvious at all.

I struggled to understand the rationale behind the technical choices because there was no information on why I should care, leading me to question the submission’s focus and relevance. The missing element was what I call the “abstract triad”: start with a sentence about the topic and relevance, followed by identifying a gap in the research, and conclude with what you’re doing to address that gap.

This structure makes clear why your work is important. In this case, the submitter included many technical details without explaining their significance whatsoever. Although I could, of course, deduce potential applications, it was challenging without explicit context.

Don’t make me Google things

The submission even mentioned a method that required me to Google what the acronym meant. It was not a very unique acronym and there was hardly enough context in the submission to even be sure what the acryonym really stood for.

If you leave your reviewers to google terms they don’t understand, you’re totally at their mercy. What if that term is ambiguous (in fact, many terms are used differently in different Humanities disciplines) and I find the wrong one?

As Joshua Schimel, a highly recommened author who writes very useful things about academic writing, reiterates in his excellent book Writing Science, the writer’s job is to make the reader’s job easy. No googling. Your writing should be self-contained. Also, when busy and having to be fast reviewing a ton of abstracts, even really benevolent reviewers can get slightly pissed and, of course, you don’t want to make your reviewer angry and consequently get fewer points.

Obviously, I’m not stupid. I can think a little bit about the term and I can Google it and gain some knowledge about it, but if you’re leaving me to Google it, obviously everybody gets different search results, so you have no control whatsoever about what the other person’s going to find. To me, that term seemed pretty niche, but apparently this person was so surrounded by people from their field to whom this term probably was completely normal, so the person didn’t realize that this was a niche term that is barely understandable for somebody outside of that subfield.

Don’t fret. I made the same mistakes

My own experience with abstracts about alchemy taught me the importance of explaining your work to a general audience. Misconceptions about alchemy, for example, are common, and failing to provide context in an abstract can lead to misunderstandings. I learned to clarify the impact and relevance of my research, situating it within current trends in the history of science (like, for example, that alchemy is not bullshit and reminding reviewers that Jungian views of alchemy are not accepted in the history of science anymore since the 1990s, even though they still run rampant in the public opinion about alchemy). I explain that I’m contributing to this new view that is accepted in the history of science research community that alchemy is an important historical phenomenon worthy of being studied. If I don’t do that, I get very bad and unhelpful reviews in DH contexts. However, with that relevant context, I haven’t run into problems ever since.

I guess if you’re not into alchemy, you didn’t know all those things and if I hadn’t said them, you would have read my abstract with your preconceptions about alchemy, which may have been false because you’re not working in the field. But that’s what you’re letting happen if you don’t explain your abstract so that a very general public can understand what it’s about. It’s something that you definitely need to learn how to do. Initially, I didn’t know how to do that because it all seemed so obvious to me and I didn’t know how to explain the impact or the relevance or where I’m situating myself. To explain how you’re situating yourself within the field, you need to know the field pretty well. And initially, when you don’t know the field, it’s really hard to know what other people know. You usually know lots of details about your niche sub-field, but you don’t know so much about the field and its overall trends at large. That’s going to come, don’t worry. Initially, it’s going to be a little bit hard to figure out, but you can, for example, get feedback from other people to help with that.

This skill develops over time, and getting feedback from others before submitting can be very helpful to get a feeling for how people read and react to your abstract. Different people can have vastly different readings of a text, believe me, you will be astounded. Don’t miss out on the opportunity of ascertaining this before you submit!

Also, don’t forget that (especially) at international conferences, the reviewer may not share the same tradition with you. They might even be in a very different international tradition that you hadn’t even heard about before.

For example, I once pitched a bit of a history of science topic and I got an Asian reviewer who I thought was very strict. He gave really bad marks without explaining what he didn’t like about my paper. This bad score was enough to totally tank my average points, leading to me getting rejected. I think this new reviewing system will help with those things. But there are still issues with reviewers coming from very different traditions and academic cultures. I didn’t properly situate myself by saying which discourse I wanted to contribute to and thus, they graded me badly. So make sure that doesn’t happen to you.

When submitting to a DH conference, do include enough technical detail to make your suggestions meaningful and verifiable

The other person, who I think is also was probably an early career person, pitched something that was actually a quite technical project, but the abstract read a lot like an abstract for a history conference. It talked only about the impact that this research would generate. I even thought it was even well-written for a history conference. But it did not include any technical detail at all.

The person may even have requested technical reviewers, but they didn’t give the technical reviewers anything to go on. This resulted in poor reviews, especially from the more technically-minded reviewers who found that they could simply not verify any of the claims because they were so broad and there were no technologies mentioned. Remember how Quinn Dombrowski said that just “text mining” isn’t enough detail. This is an example of that. A successful DH abstract has to balance technical detail and Humanities context.

Both these cases illustrate the importance of providing relevant context and explanation in your abstract, especially at a diverse conference like DH. Reviewers may come from different traditions and fields, so it’s crucial to articulate your work’s relevance and situate it within the appropriate discourse. Avoiding these pitfalls will enhance your chances of getting accepted.

Phew, that was it for today! Hope this helps!

Yours,

the Ninja