Abstracts are art

How to create an abstract to inform and delight.
Published

May 14, 2024

Writing a conference proposal (often called an abstract) can feel daunting at first. Conference committee members will be using it to evaluate your topic’s fit into the conference schedule, and it will likely be the talk description attendees use to determine if they want to join your session. The overall goal of an abstract is to inform the reader what your topic is about and give compelling reasons for them to invest their time and mental bandwidth into your ideas. Abstracts are an art form, but also a skill you can build on!

As with any good engineering problem, the first step is to read the documentation. The conference likely has a page or two about the kinds of talks they are interested in, the length of an abstract, and previous talks. It’s worth the time to read through this information. Make sure to note if there is a maximum length. Double check if that length is characters or words (if it hasn’t messed you up at least once yet, it will). Note the topics of previously accepted submissions, does your content fit in with prior art? Take this information and determine if the conference is a suitable fit for the content you would like to present. If so, time to begin!

Even if it’s a few simple bullet points, start with a list of what you hope to achieve. At the very least, have your main topic plus at least two sub-topics, why people should care, and what people will walk away knowing. This list will become your guiding light on what really matters when you are tempted to add feature lists to your abstract.

During a panel discussion on How to Get a Paper Accepted at OOPSLA, Kent Beck’s advice was that a good abstract only needs four sentences:

The first [sentence] states the problem. The second states why the problem is a problem. The third is my startling sentence. The fourth states the implication of my startling sentence.

Most of the abstracts I write follow some loose interpretation of this four-sentence rule. The first sentence in an abstract should clearly explain the pain point you are trying to resolve in your talk; the second sentence is why that pain point matters. The third sentence is where you explain how your work solves the problem, or otherwise is the main idea of the talk. Finally, the fourth sentence is where you get to envision a world where someone uses your third-sentence solution. What process has been improved, what friction has been alleviated, or what has otherwise improved in someone’s life due to your talk? Make an argument as to why your talk is worth attending.

In the case of longer abstracts, I usually end up with three paragraphs. The first paragraph is created using the four (ish) sentence model. The second paragraph provides evidence of why your solution is the best choice. The evidence outlined here will probably become the main subpoints in a slide deck when you are presenting. The third and final paragraph describes what knowledge listeners should know when they walk away. Keep in mind that listeners will NOT walk away with the ability to apply your ideas in a complex way, since they will probably only remember 10% of your talk by the time they get back home. They might, however, know what your solution is and when to use it. The last 1-2 sentences of this paragraph also recap the problem and solution outlined in the first paragraph. It’s easy to fall into the trap where you want to write your whole talk out when you are given a healthy word count to do so. Do remember that a limit is just that, a limit. There is no need to fill your abstract with extra nonsense just to meet that limit. Clearly outline the points you are going to make and why they are important, but this is not the time to explain all the details. It may help to remember who you are writing this abstract for:

If I am sure to consider my audience – first, an overworked program committee member, and second, a jetlagged and overstimulated conference attendee – I am far more likely to explain things clearly and eschew jargon. (William Benton’s excellent blog post “Concrete advice about abstracts”)

In fact, oftentimes readers will appreciate brevity, so long as you give enough information that they can assess the relevance of your talk to their work.

With the structure done, reread your abstract once and check for misspelled words, clarify any confusing wording, and remove jargon. Not everyone will be familiar with the terms you know, and your abstract will be accessible to a wider audience if you write in language that others understand. Jargon for one industry may be common knowledge in another, but use your best judgment on what is reasonable; have a friend or colleague read through your work as a second opinion if you’re not sure! You’ll want to have thought about your talk content, but in the abstract submission phase, it is not necessary to have a script or slides or anything extra prepared until you hear if your abstract is accepted.

Finally, if you are considering is X idea worth a submission? the answer is YES! You have unique ideas, experiences, and thought processes that people want to hear. If a full length talk seems too overwhelming, many conferences have lightning talks that are 5-10 minutes long you can sign up for beforehand or during the conference. Remember not all presentations are about ground-breaking new technology you developed. Learning how you and your team approached and solved a difficult problem, why you chose one framework over another, or even well-researched hot-takes all make for great presentations.

Happy conference season, wishing you all accepted talks!