| layout | permalink |
|---|---|
default |
/speaker_faq/ |
-
Consider your audience. The Program Committee judges proposals based upon how interested C++Now attendees are likely to be in the content. The more niche your content, the less interest there will be, which increases the likelihood your presentation will be rejected.
-
Focus on topics about which you are knowledgeable and passionate.
-
Choose a short, punchy title that clearly states the purpose of the presentation. Clever titles can grab attention, but cutesy titles may do the opposite.
-
Try to write just one sentence to describe your presentation. As with documenting classes or functions, if you can't boil down the description, you're likely doing too much in one presentation.
-
Consider describing a challenge, problem, or situation you will address and then discuss how you will address or solve it.
-
Provide enough details to allow the reviewing to make an informed decision. The less well known you are to the reviewer or community, the more you have to show that you know the material, can organize a good presentation, and can interest the audience.
-
C++Now is a technical conference, so discussions of management problems, while not uncommon, are not appropriate.
-
Intentions to present on what does not yet exist increases the risk of rejection. For example, if you intend to present a library, don't expect the Program Committee to take on faith that you'll create that library and a good presentation by the time of the conference.
-
Overly simplistic subjects will almost certainly be rejected.
-
Don't underestimate your time requirements. If you are unused to technical presentations, then five minutes is a lot longer than you think and forty-five minutes is a lot shorter than you think.
Yes.
Yes.
No, please bring your own or arrange with the program committee to get access to one.
No. OpenOffice.org’s Impress and Apple’s Keynote are popular alternatives.
Take a look at Doug Gregor’s Google Tech Talk presentation at http://video.google.com/videoplay?docid=-1790714981047186825 Suggestions from experienced presenters include:
- Think about who your audience is, and target your talk toward the middle of that audience. Boost users, for example, are C++-literate and can be assumed to know about Boost in general, so concentrate on the Boost library you are presenting.
- Your audience can read, so don’t just stand there and read your slides to them. Explain the bullet points or code examples on your slides. Give the rationale behind the design. Relate new material to things they are already familiar with.
- Do include code examples; C++ programmers often understand code examples better than prose descriptions.
- Look at your audience. Make eye contact.
- Repeat questions from the audience before answering, particularly with a larger audience where not everyone may be able to hear other audience members.
- Don’t just tell your audience what something is, tell them how to use it themselves. Show them real code.
- Involve your audience; ask them questions.
Given the capacity of the rooms, plan on a maximum of 100 and a minimum of 20.
This can vary from speaker to speaker and topic to topic, but something of the order of 10 minutes for a 90-minute session. You can take questions as they arise, leave them until the end (or, for long sessions, just before the next break), or a mix of both, but be sure to let the audience know at the beginning if you are happy to take questions as they come or whether you prefer to leave them until the end. Of course, if you are involving the audience by asking them questions, you should expect questions in return during the session. In taking questions during the session, try to be brief and to not get sidetracked. If a question deserves a longer answer than the flow of the material allows, or is a little off topic, say so and suggest coming back to it either at the end or offline.
It depends on the amount of detail on each slide, the amount of time allowed for questions, any time budgeted for demos, and, of course, the typical slide velocity of the presenter. If you are unsure, it is worth rehearsing all or part of your presentation to get a sense of the timing. Different presenters have different average slide velocities: some presenters use only a few slides, and move to a new slide once every five minutes or so; others move through their slides at a rapid rate, up to once every minute or so. Work out where you are on this scale and determine a slide limit based on the duration of your session divided by your typical slide velocity.
Running compiles or demos can add interest, but be very sure the app will work! Live demos are notorious failure points. There is nothing sadder that attending a presentation designed around a live demo that the presenter can’t get working.
At the minimum, provide a PDF file of your slides.
No, although part of the fun and benefits of a conference come from offline interactions with attendees in informal settings such as the hotel bar. :-)
At a minimum, please plan to arrive the day before your session, and allow plenty of leeway for travel delays. And of course we hope you will come for the entire conference, and leave some time to enjoy the spectacular setting.