To Slide…or Not To Slide?
Each month, the folks I work with have a Java Lunch. A volunteer gives a 1-hour tech talk on something Java-related, but we’ve also had talks on ANTLR, Ruby, Groovy, and many other technologies. These lunches are fun, informative, and a good way to get free pizza.
I signed myself up to present in November — I plan to show some advanced Swing concepts. There are many reasons to give a presentation:
- Giving a presentation to your peers is one of the best ways to learn something.
- A speaking engagement provides a hard deadline, forcing you to get something done.
- Presentations can be a good way to spread some knowledge.
- Public speaking is a great career move.
But I already know Swing really well…and I don’t really need a deadline for this. Here is my real motivation:
- I want to improve my presentation skills.
I want to push the envelope a bit and expand my repertoire beyond PowerPoint with bullet points. I want to learn how to give dynamic presentations that make people say “damn, that kicked ass!” (yep, I stole that from Kathy Sierra). I want them to feel this way because they learned something within the 1 hour time constraint.
Mistakes to Avoid
I think I am a good speaker, but I certainly can improve. Here are some mistakes I (have made and) plan to avoid:
- Do not include an introduction slide. This wastes precious time because people in this audience already know who I am and what the topic will be.
- Do not include an “outline” slide. With only 60 minutes, why waste 5 minutes describing what I am about to talk about? I’d rather use my time talking about Swing.
- Absolutely do not include a “History of Swing” slide. Technology history lessons put people to sleep.
- Don’t make everything “beginner level”. Far too many technical presentations cater to rookies and are boring. This is particularly true when the audience is a group of consultants who know Java inside and out.
Things That I Would Like to Do
- Show working code snippets throughout the presentation.
- Show real working Swing examples.
- Keep the pace up. We only have an hour.
The goal of a 1-hour presentation is not to teach people details. It is to spark people’s imagination, show them what is possible, and to give people a kick in the pants (or perhaps point them in the right direction) if they are interested in pursuing the technology further.
No Slides?
One idea is to skip the slide show completely. Instead of slides, I could show a series of small Swing examples: real, running programs. After showing each example, I can switch over to an IDE, pointing out the most important code snippets. Small fonts can be an issue, but IDEA makes it easy to zoom in.
Other OCI employees have given presentations in this style and it works very well.
Bullet Points
Most presentations fall into this category, and I refuse to do it this way any more. I will not have a series of slides with bullet points.
Lots of Slides
This is an option I never considered until seeing Archaeopteryx: A Ruby MIDI Generator, via Alex’s blog.
That presentation does show some working code along with a real demo. But the bulk of the presentation consists of hundreds of slides. Giles burns through the slides at a frenetic rate, and the results are phenomenal. I have never seen or given a presentation remotely like this.
What Should I Do?
I feel like I should take one of two avenues. Either go all demo+code, or go the “super fast paced slide show” approach. I must admit, the super fast slide show approach appeals to me for these reasons:
- It is completely different than what people are used to
- If done well, it can be extremely entertaining
- It’s a big challenge
- It may avoid awkward context switching as I constantly switch back and forth between code examples and demos
That last bullet is important to me. A lot of speakers spend too much of their hour stumbling back and forth between demos, the command prompt, and their IDE. Perhaps if I put everything into a fast-paced, well scripted Keynote presentation, I can avoid these context switches.
What do you think? I just placed an order for slide:ology, perhaps that will inspire me.
Hi,
I agree on many of the points to do and not to do. The one where I disagree is the “no outline”. It is a good thing to introduce people to what you have planned, so it is easier for them to follow. You can probably avoid those between individual parts, but still those are a good thing, because you can a) remind people about what is coming and b) mark previous parts as done, which will help people feel that some things are done. You don’t need to repeat all the outline over and over again and I doubt that it will take 5 mins of your presentation time anyway
Heiko
Maybe the outline can be on a handout. If you do use slides, perhaps either occasional headings or some kind of “breadcrumbs” can let the audience know where they are in the outline.
For the “fast presentation” you may want to give Pecha Kucha a try:
http://www.wired.com/techbiz/media/magazine/15-09/st_pechakucha
Looks like a great presentation style, and gives you some time to do demos or answer questions.
I enjoyed http://en.wikipedia.org/wiki/The_Takahashi_method
It is also the ‘lots of slides’ type of presentation.
Here’s an example when Matz used it
http://www.youtube.com/watch?v=Vor6Yul7CMg
I’d like to see the examples + IDE style… and I’ll be there so my vote counts
Having done 2 pecha kuchas, I highly recommend not doing one. They take hours to prepare and six minutes to deliver. This just isn’t a good fit for a technical presentation. If you have a group of people drinking and you want to talk about Art History for 6 minutes then give it a shot. But don’t try it with something technical.
Also, the mega-slide Lawrence Lessig approach (that is where Giles learned it) is also incredibly hard to prepare.
My suggestion is to look at Edward Tufte’s advice. Create a 2-4 page handout that documents everything you will talk about. That way the information has a life span outside the presentation. And they can read the handout beforehand and come prepared with questions. Handouts and IDEs make great companions.
Great post. Agree with much.
- Introduction slide – in your setting enough people probably know you that it doesn’t matter. But I find this is useful to have up till the pres starts just so people know they’re in the right place. But you don’t need to actually *say* anything at all with it.
- Outline slide – I disagree on this. I think giving people a frame of reference to hang the rest of the talk on is useful. If you’re doing a separate handout – that’s a great alternative.
- All code can work but generally it works better if it’s all code + a handout with the takeaways and references and it’s generally helpful if you can link the two together (either in order of presentation or by saying what you’re talking about. One downside to all or mostly code talks from presenter side is that it’s much harder to give them multiple times as you can’t keep the material in memory so you have to re-prep each time. Or at least that’s a problem I have. Shoot for a 1 page double-sided handout – that’s ideal both from eco and usefulness standpoint.
- I second the “don’t do it” advice on the many slide approach. Prep time would be enormous. Not only for the slides themselves but you have to basically have the presentation very rigid to make it match the slides (word for word basically). That takes lots of prep and lots of practice. If it works, it’s jaw-dropping. Otherwise excruciating.
- On the switcharoo question, it’s something I’ve struggled with. On the Mac, you can Cmd-Tab between Keynote running full-screen and other apps like an IDE *without killing Keynote*. (Note that this requires you to be running in mirror screen mode and NOT use the Keynote presenter display which is a painful loss.) That can be pretty smooth to an audience. No idea if ppt is similar. I like doing code because I’m most comfortable there and can dynamically do things to answer questions. I dislike it because of the context switch and the difficulty in showing concise examples. With Swing, it seems like the visual nature of it would make it worthwhile to show demos. Practice your demos – it helps.
Go for the super fast slide show, but with: *an outline*.
And post the slides here. I’m sure many of my Swing friends will be interested.
big +1 for moving beyond slides… more from July 07:
http://codetojoy.blogspot.com/2007/06/beethoven-didnt-use-powerpoint.html
re: history. I disagree but more on that later.
I design presentations (and other things) for a living and have a couple thoughts:
1. Less is more. Do NOT fill the screen with junk. Keep each slide simple. Very simple. And use slides to highlight and reenforce key concepts only, not for every sentence you utter.
2. Those “rapid-fire, hundreds of slides” presentations are really, REALLY hard to pull off well. You have to be exceptionally well prepared and well rehearsed to make it work.
Want a simple lesson on presentation? Watch a Steve Jobs keynote.
Dunno about omitting the history of Swing… That’s the only way that some of its design decisions make sense. Omit the AWT story and any developer worth his salt will say, “this is idiocy — no way I’m using such a bizarrely-made toolkit.”
Agree with you 100% that in general it’s a good idea to omit history.
re: history. I agree that ‘the obligatory history’ is common and not necessary.
However, I wouldn’t be categorical on it. I have seen Stuart Halloway give a history of classloaders (e.g. why ‘endorsed’ happened in 1.4, etc) and Glenn VanderBerg on a history of garbage collection strategies. Both were absolutely riveting.
More important than structre is the standard stuff of public speaking: connecting to the audience, avoiding nervous verbal habits (which are rampant among geeks), understanding whitespace, etc. I have seen online presentations that had all the bells and whistles but are a disaster with a view to public speaking (a la ToastMasters or Dale Carnegie). My favourite speakers have a ’stage presence’ that is reminiscent of theatre.
It doesn’t matter what your presentation looks like on a technical levelâbullet points are just as good as an IDE for conveying ideas. What matters is what you say, and how you say it. You can have the best slideshow ever and give a horrible presentation, but if what you have to say is interesting and useful and you’re engaging, it doesn’t matter if your slides consist solely of stock images of greenery and diverse people smiling.
Pretend you’re talking to a friend or someone you really respect (and talk that wayâdon’t adjust your mannerisms because there’s a larger audience). Whatever you would interrupt the conversation to scrawl on a napkin, use as a slide. Everything else is pretty much clutter.
History is good if it’s relevant. Don’t relate the entire history of Swing; just the parts that explain anything that’s unclear.
Seth Godin’s advice on handouts is good:
“Third, create a written document. A leave-behind. Put in as many footnotes or details as you like. Then, when you start your presentation, tell the audience that youâre going to give them all the details of your presentation after itâs over, and they donât have to write down everything you say. [â¦]
IMPORTANT: Donât hand out the written stuff at the beginning! If you do, people will read the memo while youâre talking and ignore you. Instead, your goal is to get them to sit back, trust you and take in the emotional and intellectual points of your presentation.”
Finally, if your goal is to teach, don’t learn about giving slideshows. Learn about teaching.
(On a side note, could you adjust the CSS on the comments to include half-em vertical margins or em indents, so that we don’t have to double-return every paragraph?)
(warg i broke your unicode
i am sorry for using an ellipsis and an em dash)
One thing we can learn from politicians is rhetoric, the art of speech. Al Gore’s Keynote presentation won a Nobel prize
Rhetoric was invented thousands of years ago, distilling the esence of successful expositions. It still works because human nature hasn’t changed since then. Unfortunately, neither have most references on the subject.
A good (classic) source: http://rhetoric.byu.edu/canons/Arrangement.htm
This would be a modern way to explain the arrangement of exposition:
1. raise interest
2. establish context (information already known to the audience)
3. present new information
4. draw conclusions
5. call to action
Last step may be omitted if the purpose is to entertain the audience rather than driving it.
Hope it helps.
Instead of slides, why not make a Swing app that presents for you?
I did something similar when I gave presentations on using wikis…
no powerpoint, all wiki.
While this may be too late for your presentation, I agree with a lot of the other commenters about the outline. An outline can be super-useful in keeping people on track. If someone gets lost, at least they can get back on track at the next bullet point. It’s also very helpful for note-takers.
As for the huge number of slides approach, I’ve never tried it myself, but if it takes a long time to prepare, it may be better for presentations that are going to be reused many times, like the ones Larry Lessig gives.