Concrete Advice for Abstract Writers

Posted in: Technical Track

October is abstract-writing season. Many database conferences have their call-for-papers deadline in the last half of October, and I spend significant portions of my time considering the areas I’m interested in these days and whether they will make good presentations. Having an interesting topic to present is only half the battle; I must convince the conference organizers that my presentation will be educational and entertaining. Most conferences base their decision on a title and abstract submitted by the hopeful speakers, so much depends on being able to compose a short description of your presentation that will catch their eye and compel them to invite you to the conference.

November is abstract-reading season. I volunteer with multiple user groups, and as part of my activities, I review abstracts and recommend the ones I think should be included in the conference program. I estimate I’ve read close to a hundred abstracts in the past few weeks. When reviewing abstracts, I see huge variance – the best abstracts are clear and make the topic sound exciting. Bad abstracts are either boring or give you no meaningful idea of what the presentation will include. The worse are just a random collection of buzzwords. I always assumed that presenters who write bad abstracts either don’t know what they are going to talk about or don’t care enough about the topic to make the abstracts better.

At least this is what I used to believe, until my own husband asked me to take a look at an abstract he was about to send off. It was terrible. I know that my husband is smart and that he cared about the topic. (How can anyone not care about methods of cheating in visual cryptography?). As I sat with him at the kitchen table, gently trying to explain the issues in the abstract and how to correct them, it occurred to me that abstract writing does not come naturally to everyone.

The main difficulty in writing good abstracts is that you are trying to accomplish multiple goals in the same short text: You are trying to convince the abstract reviewer that the topic is interesting, that you are an expert on the subject matter, and that you will be educational and entertaining. At the same time, you need to describe the general content of the presentation to your potential audience so that they’re able to make an informed decision on whether to attend the presentation.

I recommend splitting the abstract into two parts and dedicating a paragraph, or at least a sentence, to each.

The first part is the purpose. The goal here is to explain why the topic is relevant and interesting. This section should sound like a newspaper headline since they share a similar goal: to catch the eye and create interest.

For example:
“Getting training data for a recommender system is easy: if users clicked it, it’s a positive – if they didn’t, it’s a negative. … Or is it?”

This part shouldn’t be overly verbose. One or two sentences are typically enough to introduce the topic, demonstrate its importance, and create interest in the presentation.

“The MapReduce programming model lets developers without experience with parallel and distributed systems utilize the resources of a large, multi-CPU system. Hadoop clusters can be used to implement this model, but Oracle Database also provides mechanisms to support the same model – and with less programming. “

The second part should provide more details about your specific presentation. It is a prose-form of your presentation top level outline. Which topics will you focus on? What will the audience learn? Will there be a demo or examples of use-cases?

For example:
“In this talk, we use examples from production recommender systems to bring training data to the forefront: from overcoming presentation bias to the art of crowdsourcing subjective judgments to creative data exhaust exploitation and feature creation.”


“Bryn and Maria address ways to implement an application to solve a specific problem where, because of the typically huge volumes of data that must be distilled down to provide interesting information, performance matters. A person whose job is to work with an installed system won’t be able to use what he explains in his talk to tune its performance.”

Here’s a complete example for an excellent abstract that follows this format:

“Craigslist uses a variety of data storage systems in its backend systems: in-memory, SQL, and NoSQL. This talk is an overview of how craigslist works with a focus on the data storage and management choices that were made in each of its major subsystems. These include MySQL, memcached, Redis, MongoDB, Sphinx, and the filesystem. Special attention will be paid to the benefits and tradeoffs associated with choosing from the various popular data storage systems, including long-term viability, support, and ease of integration.”

You read this type of abstract and you immediately know what the presentation is about (variety of data storage systems), why they are interesting (craigslist uses them), and what the main topics of the presentation are (tradeoffs, benefits, support, integration, and a long list of data storage systems).

The most common reason reviewers reject abstracts is that we can’t figure out the content of the presentation, or the abstract does not convince us that the presentation has anything new or interesting to say about the subject.

Two common mistakes to avoid:

1. Abstract is not an intro – Too often I see abstracts that are all about explaining why the topic they will talk about is interesting and important. It is important to remember that an abstract should summarize the entire presentation, it should not contain just the content of the first 3 introduction slides. We and your audience need to understand what you will talk about, not just gain a general idea of the subject matter.

2. Abstract is not a random collection of buzzwords – Too often I see an abstract that is simply a collection of randomly chosen buzzwords thrown together. There is nothing that will get your abstract faster onto my “reject” pile. If I can’t get a clear idea of the main three points of your presentation by reading your abstract, I will strongly suspect that you have absolutely no idea what you want to talk about. If you don’t care enough about the topic to figure out what you want to say, I don’t care to accept it.

Sheeri has an old blog post with even more mistakes to avoid. She is also on conference committee for many conferences and knows what she is talking about. (Except for the overly clever titles. I love clever titles.) Remember that the way to success is to avoid failing.

Just taking this small two-part construction step for your abstract will put you way ahead of 90% of the abstracts I see submitted to conferences. Your abstract will be interesting, not too long, and will include specific details on your topic. If you picked the right topic, this is enough to get the abstract accepted to most conferences.

Good luck and have an excellent conference season!



Want to talk with an expert? Schedule a call with our team to get the conversation started.

3 Comments. Leave new

Kamran Agayev A.
November 22, 2012 5:09 am

Nice article Gwen!

Log Buffer #296, A Carnival of the Vanities for DBAs | The Pythian Blog
November 23, 2012 1:02 am

[…] Gwen Shapira has written an excellent and concrete advice for abstract writers. […]


To be fair, I love overly clever titles too. But when you’re submitting to conferences with non-native English speakers, sometimes you have to remove idiomatic expressions.


Leave a Reply

Your email address will not be published. Required fields are marked *