07 July 2016
James Ward also wrote an article on how to write abstracts, and I realized after I published that I forgot to call out to his article as well. Mea culpa.
First off, James' post is here, and for the most part, I think we agree on most things.
Where he says "Make the title clear, concise and enaging", I would word that differently, simply because too many readers will see "engaging" and think "cute", which I have come to dislike. Go with simple, straightforward, and clear. Go with boring. (The body of that list item makes it more clear, I think, that he and I actually agree on this.)
James then says "Start the abstract with a problem or controversial statement". Staring with the problem is basically the "pain" part of my abstract. I dislike the idea of starting with a controversial statement, however, because I think that tends to attract the wrong kind of attendee to your session. Specifically, it goes back to the whole, "You get what you go looking for" mantra that parents have been trying to teach their kids---if you go out there looking for a fight, you'll find one soon enough. In an abstract, if you say, "Object-orientation is dead; functional programming is here to rule the world", several things will happen:
Of course, if the intent of the session is to encourage that kind of argumentation, which is common for a speaker panel or some other audience-participation-driven session, then by all means, go for it. But remember, your abstract is your contract with the audience---if you don't make good on the contract (including the salacious "Jer-ry" parts, if that's what you promise), then you've failed and you're probably going to get hammered in the evals.
Next: **"Make the abstract about the content and attendee, not you". This one, I didn't talk about, and he's right. In all fairness, I think this is true of much more than the abstract, and something I think is just a general approach/attitude about all speaking, but it deserves mention and I'm glad James throught to bring that out.
Here we might disagree a little bit more strongly: "Clearly describe what attendees will take away from the session". My concern hinges on the word "clearly"; many reades might take that to mean "in great detail", and as I said earlier, an abstract is not a detailed play-by-play of what you're going to do in the talk, but a high-level overview. The body of his tip suggests that he and I are more on the same page, though, when he says, "Make sure the abstract clearly identifies what the attendee has to gain from going to the session". In other words, make sure the session has the Promise to go along with the Pain.
But when he says, "Although this could have been improved by more clearly saying that attendees will not just walk away with the 'why' but the 'how'", I'm not sure I agree. It depends on the focus of the session---for a higher-level session, such as a discussion of the Fallacies of Distributed Computing, for example, the "how" isn't as important. The "why" is essentially the point of the session. If the session is supposed to be technical and demonstrative, however, then the "how" needs to come out, and it's a good idea to say that in the abstract, but without giving away which "how" points you're going to discuss. (Again, you as the speaker want to maintain some "pivot room" within the talk, even after it's been submitted.)
Lastly, James rounds it out with "Like a resume, make it professional". People, that shouldn't even have to be mentioned. If you want to be taken seriously, you have to take your communication skills seriously in turn.
(Sidebar: I've heard some folks complain that this unfairly biases the selection process against those for whom English is not a native language. I'm sympathetic to that point, but you have to see it from the organizers' perspective---if the conference is in English, and the abstract doesn't demonstrate a strong grasp of the English language, what faith do the organizers have that the presentation itself will have a strong grasp of the English language, and thus be something the attendees will be able to understand? And let me be the first to say that if I were preparing to deliver a session in France, speaking in French, I would fully expect my session to be rejected out-of-hand, because my French simply isn't up to the task, written or spoken. This isn't about discrimination, it's about making sure the attendees get what they paid for: something they can understand and use in their day jobs. It's for this same reason that American speakers need to be very sensitive to American cultural references when speaking outside of the US, something I already alluded to in the previous article. Clarity must triumph.)
Honestly, if you're not a professional writer, then it behooves you to take your abstract to a copyeditor or your favorite family "GrammarNazi" and ask them to do a pass on it. It may not be fun---being corrected rarely is---but if it makes the difference between a "one look and to the rubbish bin" and "a second look and maybe a third and acceptance",isn't it worth it?
Last modified 07 July 2016