I've just talked about this at Yapc in Vienna. This paper is still a draft, and will be changed a little over the next few days.
You've been to a Perl conference and seen other people give presentations, and you think you might like to have a go next time. Or you're not sure, you're wondering whether you could do it; perhaps you've briefly entertained the thought, but you're not sure you've got what it takes to become a speaker, sharing the bill with the likes of Larry, Damian, and MJD. And anyway, what would you speak about?
Getting AcceptedFor this conference the organizers published the algorithm they used to work out which talks to accept and reject. They particularly wanted to encourage first-time speakers, and accepted at least one talk from everybody who submitted one; the only rejected talks were from those who made multiple proposals.
Other conferences have other organizers, who may use other criteria, but this gives an idea of how keen the Perl community are to welcome newcomers. Don't be concerned you aren't already well-known; if you've got an idea for a talk, submit it anyway.
What to Talk About?If you've recently created some amazing software that you're eager to evangelize then that's an obvious thing to talk about. But what if you haven't? That's OK -- there's lots of good stuff you can talk about that's produced by others who aren't at the conference, or don't have time to create presentations about it, or are so close to the project that they can't relate to beginners, or ...
Think about what software you've been using recently, and more generally what you've been doing. Good topics for talks include:
Tell others about some great Perl software you've recently been using.
In many areas there's a choice of several ways of achieving something with
Perl. For example, what's the best way of validating parameters? Of the many
ways of sending mail using Perl, which ones suit which circumstances? How do
Apache's mod_perl and FastCGI compare? Many people are only familiar with
one way of doing something, even the creators of these systems; if you do the
research and present a useful comparison then you become the de facto expert
in the field.
Everybody likes to learn something which makes their lives easier, so talks on getting the best out of commonly used software are popular, and gratefully received. The first time I tried this I felt a little fraudulent, giving Bash tips at a Linux conference; I was surrounded by all these clever kernel hackers, my talk was on about software I hadn't contributed to and had no claim to being an expert on beyond reading the publicly available manpage. But it turns out that, despite using it on a daily basis, not many kernel hackers have read and digested the Bash manpage, and the talk went down well.
Mostly it's just a case of finding a subject on which you know a little more than most others at the conference. At a Perl conference people are already going to know a fair bit about Perl, so one option for finding something new to share with them is to talk about something other than Perl.
There's lots of related technology used by Perl people, such as version control systems. SVK is written in Perl, so is obviously on-topic; but other systems such as Git, Mercurial, Bazaar, Monotone are also of interest to Perl programmers, and a talk on one would be handy for those considering using it. Obviously that isn't everybody, but then that's going to be the case for any talk -- that's why a conference has multiple simultaneous talks.
Databases are also used a lot in Perl programs, so there's interest in talks on MySQL, Postgres, Microsoft Sql Server, SQLite, and so on -- or some combination, such as experiences in converting a system from MySQL to Postgres.
Perl is often used in creating web interfaces, which suggests topics such as Ajax, web accessibility, CSS, and HTML5.
On a productivity theme could be tips for using Emacs or Vim well with Perl, or your favourite Windows editor/IDE. Or people who mostly do their Perl hacking on Unix systems might be interested in what to install on Windows to give a comfortable Perl-hacking experience, and what software that Unix users know has Windows ports available.
You could talk about another programming language. There are several reasons why another language could be of interest:
Many people at a Perl conference develop software for a living, and there's a bunch of non-software things which are likely to be relevant to their lives, such as extreme programming, team working, time management, project management, line management, recruitment, interviewing, persuading management to use Perl, and writing good technical English. Any of those could be the source of a good talk.
Wouldn't the above risk making this into a generic technical conference, rather than specifically a Perl one? Well obviously it would if none of the talks were about Perl; I'm throwing out the above as suggestions of things to have as well as unambiguously Perl talks. Though I do think it would be interesting for a Perl conference to embrace this notion and have one of its three streams explicitly devoted to talks on things which aren't Perl but are of interest to Perl people.
Also note that there's a big difference between a talk that's an introduction to Python and one that's an introduction to Python specifically for Perl programmers.
Submitting a ProposalOne you have a topic you need to submit a proposal. Don't fret about this too much: there isn't some secret formal language that you have to use when writing an abstract. Just imagine chatting a colleague in the pub at lunchtime who asks you what your talk is about, and write down whatever answer you'd give. (Or of course instead of imagining this you could use an actual colleague in an actual pub.)
Do note the deadline though. Conferences can receive so many on-time proposals that they don't consider those that arrive late.
Talk DurationYou'll need to pick a duration for your talk. 20 minutes is almost always the right answer, and definitely for any 'introduction to' talks: if a topic can't be given a beginner-friendly overview in 20 minutes then it's too complicated.
When you looked at this conference's programme there were probably a few talks you immediately knew you wanted to see, then for the rest of the time you looked around and picked things you thought might be interesting. My guess is that most of those were 20-minute talks; you're much more likely to chance 20 minutes on a topic you aren't sure about than risk the possibility of being stuck for 40 minutes or longer in a talk that turns out to be of no interest to you. So if you keep your talk short, you're likely to get more people checking it out.
WritingWhen it comes to writing your talk first write a paper.
That may seem like odd advice, a rather roundabout way of getting a presentation created, but there are at least two good reasons for starting with a paper rather than slides:
It's something you already have experience of, so you know how to do it, and are better at it. If you don't think you have experience of writing a paper then instead pretend it's an article, a blog entry, a wiki page, an e-mail to a colleague, or whatever it is you do have experience of.
It's easier to concentrate on the content, without being distracted by the form. Slides make you divide your thoughts into a sequence of chunks, and once you've put content on a slide it can seem like too much hassle to re-arrange it to elsewhere. With a text document it's trivial to keep making changes as you write, to cut-and-paste a few paragraphs to somewhere else, and it doesn't really matter how long your paper ends up.
Once you have your paper, you can turn it into a talk. Or more accurately, you can create a talk about it.
Considering Your AudienceAs I mentioned above, in any conference there are only going to be a few 'must-see' talks for an attendee. There will be some people who are really keen to see your talk, but equally there'll be a significant number in your audience who are mainly there because they're left over from the previous talk, they're waiting for the next one, or because the talk in the other room right now is on XML.
For the people who've come to see your goal is simple: make them want to read your paper. A talk, especially a short one, is not a good way transferring detailed technical information to the audience, and especially not syntax. After your talk people are not going to remember the exact regular expression that you recommended, the particular command-line options needed to do something, or that nifty Vim keystroke; and after lunch they're going to be struggling even with simple things like the name of the module you were talking about or the URL of the website you said had more information.
But that's OK: all those details are in your paper. People who are inspired by your talk and want to do something that you mentioned can look at your paper and find out what they need to know.
So, if the paper contains all the relevant information, why bother with the talk at all? The talk's purpose is to inspire and enthuse people on your chosen topic, to dazzle your audience so much with what they see in your presentation that they are keen to try it out for themselves. Many of your audience won't be aware of your paper's existence, and of those who do it won't have occured to most to read it; your talk is your chance to bring it to their attention.
You can demonstrate what some software does, show how easy it is to use, or how magnificent its output is. By all means include code samples and command-lines and the like -- just remember that their purpose is show the audience that they exist, to plant the seed of what is possible, and that it isn't desirable for you to dwell on them, explaining every last punctuation character.
Hopefully the people who've come specifically to see your talk will be interested in following it up, but maybe some of the others present, randomly passing time, will also take an interest. That's more likely to happen if your talk is engaging, interesting, or even entertaining. For some people your talk simply won't be relevant, but they'll still appreciate it if you entertained them while they sat there waiting for the speaker after you.
As long as the hardcore technical information is available in your paper for anybody who wants them, I'd always go for entertainment over detail in your talk. Again think of the talks you've enjoyed seeing at the conference; they probably include some by speakers who were fun to experience even though what they were talking about has no interest to you.
Live DemosA live demo is an excellent way of getting across what a piece of software does -- people are much more impressed seeing something for themselves rather than just hearing about it. Unfortunately it's also an excellent way of catching the speaker unawares and ruining what would otherwise be a perfectly good presentation.
Some people recommend never to risk a truly live demo, and instead to use a pre-recorded demo, a video created in advance with screen-capturing software.
The main problem with live demos is the difficulty of driving the computer and talking to the audience, at the same time. This gets worse if there's a minor problem with the demo, as sorting that out takes over your available brain cells and the audience are left witnessing you stammering a few incoherent words between frantic keypresses.
So an alternative to screen captures is to get an assistant who's responsible for driving the computer. You only have to concentrate on the audience, and your assistant makes things appear on the screen at the right time. If something goes wrong then you can continue to give the audience your undivided attention while assistant fiddles with the computer.
And even if your talk doesn't feature a live demo, it's useful to have a 'keyboard monkey' merely for controlling the slides; it frees up your hands, and means you can wander around the stage or move closer to the audience.
SlidesTalking of slides, what should you put on them? Firstly let's dismiss a couple of bad reasons for putting something on a slide:
You've already written a paper. Anything the audience (or even, if the buzz about your talk travels far enough, people not in the audience, possibly not even that this conference) want to look up later is in your paper, so there's no need to clutter the slides used during your talk with anything which doesn't directly help the talk at that moment.
And when following along at home it's much easier to read paragraphs of text in a paper than to run through a slideshow.
Some conference talks merely consist of reading bullet points out loud. Those are rarely the good talks. A reminder of what you want to say is good, but there's no need for the whole room to see it. Some laptops can display different things to the speaker from what is being projected, or you can use paper notes. My preference is for a print-out of my slides, annotated with reminders; if you've got somebody else driving the computer then clutching some notes isn't a problem.
One of the worst presentations I've seen had bullet points being complete sentences, each appearing one-at-a-time on slides but with not-yet-reached bullet points displayed in pale grey (on the white background), presumably to remind the presenter what was coming up. But even the greyed-out bullet points were readable from the audience, so on each slide change the audience would quickly scan the contents then sit there waiting for the speaker to read them all out loud.
Then one slide was a full-screen diagram. The speaker ad-libbed, drawing the audience's attention to various points of interest in the diagram; this was much more engaging, and showed what the speaker was capable of. Unfortunately the following slide was bullet point sentences of commentary on the diagram; the presenter went through each one, in most cases reading the out the full bullet point and then adding ``as I just said''. Somehow he'd been trapped by the bullet points, under some compulsion to read each one even though he knew he'd already conveyed the relevant material. Don't do this!
So what should you put on you slides then? As a first approximation, nothing.
Imagine that instead of presenting this at a conference you're explaining the same material to a colleague. You would be able to do this without your colleague seeing large bullet points appearing on the wall behind you. Guess what? You don't need the bullet points at a conference either. 'Death by PowerPoint' is a recognized phenomena, and definitely something you want to avoid.
Slides are good for some things though, the kind of things which when you're trying to explain them to a colleague would cause you to reach for a notepad or a web-browser:
Slides can also be used for emphasis, to re-iterate particularly important points -- but this has to be done sparingly for it to be effective.
Doing the above may mean that there are sections of your talk without any slides. Don't worry about it: if you've decided that the best way of conveying information about something is just to talk about it then adding in some unnecessary bullet points is only going to make it worse.
Most conferences give all attendees papers, on either paper or a CD. If yours doesn't, then make sure that your talk contains memorable instructions of where the audience can find your paper.
Content OrderNearly everything can be improved given a little more time to work on them, but given that most speakers are preparing talks in their own time it seems a little harsh to criticize a presentation you've seen. But there is one metric which can be applied to a talk safe in the knowledge that following it would have taken exactly the same preparation time: would the talk have been better had exactly the same content been presented but in the reverse order.
That sounds ludicrous, but since thinking of it I've been surprised by how many talks that applies to. It's natural to think of presenting material in the order in which you first encountered it, or in the order which people will need to use it. But those often aren't the best order for a live talk:
A talk on using a graphical user interface toolkit showed all the coding first with the live demo at the very end. So he was trying to explain what the effect of various lines of code would be without us having seen any output at all.
A beginner's testing talk covered in detail commands for running tests, with the speaker trying to explain the effect various bits of code would have on the output to an audience who hadn't yet seen a test run or any Tap.
An introduction to some label-generating software started with instructions on how to download and compile it; until the audience have seen what the program does they aren't going to be interested in running it (and anyway this is exactly the sort of detail which can be left to the paper and not mentioned in the talk at all). The talk then proceeded through configuring and running the program, all the time the speaker alluding to what he was trying to generate with it. Finally the last slide showed the finished product, a nice sheet of produce labels. Far better to have those (or, even better, visual aids of actual jars of rhubarb conserve and tomato chutney sporting the labels) as the starting point, so the audience can see what the point of the talk is, and those whose interest has been piqued can follow the details of how the speaker gets there.
If at any point you find yourself struggling to explain something, trying to convince the audience that they'll see what your talking about shortly, then that's a big clue that the order of your content needs swapping over. Remember that a live presentation, unlike a book or webpage, is strictly linear; people can't jump straight to particular sections.
PractisingUnsurprisingly talks benefit from being practised. If you're speaking at a conference then try to find a local Perl Monger's or similar group to present your talk at first; most are very grateful for any offers of talks.
Setting UpYou'd've thought that by now technology would have reached a state where any laptop works with any projector. Unfortunately that appears not to be the case, and every conference features talks delayed at the start as flummoxed speakers graple with laptops and cables.
To avoid this happening to you, scope out the room well in advance of your talk, the day before if possible. Sneak in during a quiet period and try connecting up your computer and make sure everything works.
On the day turn up to the room during the break that precedes the block of talks you're in, and get set up (though obviously you'll have to disconnect from the projector again if you aren't the first talk in your block).
TimingOne of the hardest things to get right in a talk is the timing. There's no magic fix for this, but practice runs definitely help -- and user groups can usually be more flexible than conferences about timing, so it doesn't matter as much if a talk presented there is longer or shorter than you were hoping for.
At a conference overrunning is much worse than underrunning, and can be very rude. Here are some overrunning sins I've seen committed at conferences:
A speaker checks with the following speaker in the room that overrunning is acceptable, delaying the start of the next talk; this ignores the audience members who were planning on changing streams after this talk to one in another room, which isn't being delayed.
A speaker sees there's a five-minute gap between talks so he can continue into that; this doesn't leave the following speaker any time to set up his equipment, and can result in him being very flustered as he's trying to start his talk.
A speaker notes that his talk is followed by the lunchbreak, so concludes it's OK to run into it; this distresses audience members with plans to meet others for lunch, and who don't know where to go by themselves in this foreign country
In short, don't overrun.
Many conferences provide a 'session chair' in each room, who will give keep track of time and signal to you when you have 5 minutes remaining. If this catches you unaware, say you're only halfway through your material, then do not do what many people seem to: attempt to whizz at high speed through all the rest (yes, all of it); the rushing bamboozles the audience, and you end up not finishing anyway, so they never get to hear your conclusions. Instead, remember that all the information is in your paper (so it doesn't matter that you say everything); point this out to the audience, try to decide what is the most important point in your remaining material, cover that, and then deliver your conclusion as planned.
EndingThere appear to be exactly two things you can say to end a talk: either "Any questions?" or "Thank you".
Jumping straight to asking for questions can initiall seem OK, but after a few questions it can become unclear whether the talk has finished yet; the next speaker is getting jumpy because your final slide is still on the screen and he wants to get plugged in; there are people in the audience who want to dash off to a talk in another room but who feel uneasy about leaving before clapping your talk; and there are people arriving from the other room who are chatting on the way in, thinking that you're just engaged in post-presentation chatting with a few individuals. It can all get quite messy and awkward.
The better way is to end simply with ``Thank you'', and a pause. The audience will applaud at this point, and you can disconnect your computer. Then you can seek questions while the next speaker is setting up and the audience are shuffling between rooms.
Further ReadingWhile this talk is specifically about giving 3-hour conference tutorials, much of what MJD says is also useful for 20-minute presentations, and you get to find out why he talks with his mouth full. http://perl.plover.com/yak/presentation/
This talk isn't on the web (and I haven't seen it), but Google finds several people who have seen it writing about it and offering useful nuggets.
Tufte's short book analyses how squashing thoughts into PowerPoint layouts harms what we're trying to say. http://www.edwardtufte.com/tufte/powerpoint
A blog with tips on giving successful presentations. http://www.presentationzen.com/
