--- "John W. Holmes" <[EMAIL PROTECTED]> wrote: > Since I'm fresh back from php|cruise, I thought I'd comment and ask > for comments on what it takes to give a good technical presentation. > I'm planning on writing about this topic in my next php|architect > column, so be aware that anything said here may appear in it.
I've considered writing about this before. Good topic. :-) > 1) Rehearse: This is a must. You have to run through your > presentation a couple times and preferably in front of other people > so they can provide feedback. Even if you can't reherse in front of other people, running through it by yourself and actually saying it out loud can help you determine where you stand on time. You want to be able to keep a relaxed pace during a presentation, because going through anything quickly will leave almost everyone confused, no matter how simple the topic seems to you. You also don't want to be out of material half-way through. > 2) Dry Run: As important as rehearsing before hand is doing a dry > run of the presentation in the actual place where you'll be giving > the presentation and preferably with the actual equipment you'll be > using. I don't think this is as important, but maybe it's because I always present from my own laptop. The only thing you want to keep in mind is that it is practically impossible to have font that is too large. Text that is too large is much better than text that is too small. Use a HUGE font size. > Do the colors show up (especially yellows and oranges). Use high contrast and never depend on accurate colors. > Can you read the fonts from the front and back of the room? I can answer for you: no! Make your font size larger. :-) > Do you need a microphone? A good conference organizer should have microphones in any rooms large enough to warrant them. > 3) Typing Code: Don't type code during your presentation. Why not? From my experience, people appreciate live demonstrations of the techniques you're discussing. I think you need to only be concerned with two things: 1. Make your font HUGE! Seriously, if you're going to do anything from the command line, make your font so big that it's cumbersome to you. Do this before you start presenting, just in case someone asks a question that you can better demonstrate through live demo. 2. Make any example painfully simple. If it's not simple, it needs to be prepared ahead of time, as John suggests. > 4) Text Editors: If you're going to use one, make sure you can adjust > the text size. Make it HUGE! :-) People that can't read it won't necessarily speak up, and why make them? > 6) Questions: Speaking of questions, try to pause between each slide > and at least look up to see if anyone has any questions. You should be looking up almost the entire time. In fact, you should almost never, ever read from a slide anyway. I think there is nearly a 100% literate rate among conference attendees. Let them read the slides; you discuss. > If you want to hold all questions until the end, make sure you say > so, but understand that this will be hard for the audience to do. Don't even try this. I've often has question and answer periods at the end, but I've yet to have a question. People want to ask questions when they think of them, and when your presentation is over, people want to do one of two things: 1. Leave (number one answer) 2. Come ask you a question face-to-face > 8) Graphics and Transitions: This one will probably raise some > arguments, but I don't see much a need for pretty graphics and > transitions. Count me as arguing. :-) Pictures are good. Better are pictures that illustrate whatever it is you are discussing. If you have slide after slide of bulleted lists, you're talk is going to be boring. I hate boring talks. > 9) Make Slides Available: This one should be a no brainer, but make > sure people can get to your slides after the presentation, especially > if they contain code. The exception is, of course, if you're not allowed to (such as an ApacheCon tutorial). > 10) Uhmmmm: Uhmmm... Ahhh.... This is what practicing is for. Try to > avoid excessive "uhmms" and "ahhs" and other noise words when you're > in front of an audience. I've read (in reference to public speaking) that "uhhh" is encouraged. The reason people think of this as bad is when they notice it - and this only happens when you have nothing to say. Dead silence is even worse. So, what you really need to do is avoid losing your train of thought. :-) > This certainly isn't all inclusive, so please add to this with your > own advice and experiences. Thank you. I should point out that my comments are mostly from the perspective of an attendee, since I've seen many more presentations than I've given. I think a better resource than these few emails is Conference Presentation Judo, a talk given by Mark Jason Dominus: http://perl.plover.com/yak/presentation/samples/slide001.html Chris ===== Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming mid-2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
