When giving a talk or submitting a talk to a conference, you are often asked to give an abstract for this talk. This abstract is particularly different from that that you write for a paper for instance. However, it carries some characteristics that are indeed the same.
As I am for the third year in a row in the program committee for the Frankfurter Entwicklertag (Frankfurt Developer Day) – an industry conference – I thought it might be a good idea to provide a small tutorial for producing talk abstracts that lets program committees easily assess the quality of your work and also lets your work shine in the conference programme.
Having a good structure is key to getting your idea through. If you bore your readers they possibly won’t read until the end. Also if you give all the important information away in the first sentence why should your read bother until the end? So finding the right balance is your task.
A talk abstract is usually larger than a paper abstract. Typical paper abstracts are about 200-250 words. For the Entwicklertag we limit abstracts to 5,000 characters – which is roughly 850 words. You should USE this space… If you just write three sentences it is hard to tell if this is actually great or not.
As Frank Herbert writes in Dune “A beginning is a very delicate time.” The first part of your abstract is there to convince people that it is actually worth reading the whole thing.
Always start with a problem statement. Tell your reader what you are trying to solve or what particular thing you are addressing in your talk.
When your reader has understood what the problem actually is, then you need to convince her that it is actually a problem worth solving. This is the motivation. Tell us why we should care. You can either do this by sketching the benefits of this problem being solved or by outlining the cost of ignoring it.
Now that you caught your readers attention it is the time to actually cash in on it and tell them what you are suggesting in your talk. It is the section where you present your approach to things. Here you can be much more detailed but be sure not to give everything away… Keep them interested to actually listen to your talk, but let the committee know that you know what you’re speaking about. Evidence helps a lot – for instance: GitHub repository? Name it!
Finally it is time to close. It is also the last chance you have to convince the last doubters that your work is great. So first conclude and quickly recap all the things you told us earlier. And then give us some motivation to come to your talk. What do we take home? Will we be a better person? Will be be a better programmer?
A good abstract should stand for its own. It should be self explanatory. You don’t have to mention every detail of your work, but you have to have every major point that your make in the text. Be concise and don’t add any fluff… We just want to read about this particular talk and not anything else.
You should be aware of your target audience… Don’t overshoot and rely on things they might not know. But also don’t underestimate what they already know.
Ask yourself while writing: “Would I go to the talk or does the abstract already include everything that I need to know?” Because your ultimate goal should always be getting people to your talk.
… all this only works if you have a great thing to talk about in the first place. It is just a way to get your idea across to your readers which you ultimately want to come and enjoy your talk.