Almost a year ago I said I was taking a break for speaking, with the main reason being I wanted to focus on getting out of my comfort zone and learning stuff (which I did, if you’ve been following my posts on Rails, Mac, etc.). In order to help with my learning I also attended to conferences, which was great. In doing so, I’ve also picked up a couple of things *not* to do after analyzing certain things that a couple of speakers tend to do.
Your screen projected out to two big screens
It’s usually a good thing for the speaker to walk around once in a while, and maybe point things on the big screen while doing this presentation. However, if the computer is hooked up to two or more big screens, pointing things out on one of the screens SUCKS for the audience. People on the other side of the room probably can’t read what you’re pointing at, or it’s very likely that you’re standing right in front of the screen and they can’t see a big portion of it at all.
So what’s the solution to that? One option would be to get one of those laser pointers, and use that to point at one screen, and then at the other screen, which you can do from a distance. Or maybe get *two* of those, so you can point to the screens at the same time! If you get a fog machine going, that’ll make you look like the super Geek Jedi! (but then, people may not be able to read the screens anymore).
All joking aside, the real remedy for that couldn’t be simpler: use the mouse pointer, which is *always* showing up on all screens!
Showing slides containing code listings
I’ve seen speakers showing slides that only contain code. That is a good way to present code in the flow that fits your presentation. However, I’ve seen speakers packing so much code in a single slide that people can hardly read what’s on it. Worse still, the speaker talks about what the code does, but the audience has no reference to know where exactly on the screen they should be focusing on.
There are certain things one can do to address that:
- Refactor the code so there’s less to be listed on screen! 🙂
- For the cases where the code can’t be shortened, make sure you can easily zoom into the sections of the code you’re explaining. That’ll give the audience a reference as to what part of the code you’re talking about, *and*, it’ll make it easier to read due to the bigger fonts.
More tips
A couple of the sessions I’ve attended to recently reminded me of my When the geniuses talk or write… Zzzzzzz… post. I sit there thinking, “you see, that’s already a complex topic, and you’re making it look even harder. Is it because you want you took look smart, or me to look stupid, or you are just oblivious to it?“. I believe that the 80/20 rule applies here: 80% of the people that goes to a session doesn’t know much about the topic and want to learn, and 20% of the people already know something about it and would like deeper knowledge. If the second group isn’t happy for not having in-depth content, they just walk out and go find another session. In my mind, it’s better to lose 20% than 80% of your crowd (the 80% crowd may not walk out on you, but they’re likely to give you a bad rating if they didn’t learn anything from you).
There are plenty of other blog posts our there with tips for presenters. Here are some that I think to be pretty good:
Presentation Tips Learned From My (Many) Mistakes
11 Top Tips for a Successful Technical Presentation
Claudio Lassala's Blog 