At almost every event I’ve spoken at in the last twelve months, somebody has asked me how I created my slides. Typically they are talking about my code samples, but I wanted to cover all aspects of creating my slides.
You Are The Star, Not Your Slides
It’s often said that you, as the speaker, should be the star of the show. Your slides should be inconsequential, a supporting act. If the projector dies, your audience shouldn’t miss out on much.
While I strongly agree with the sentiment — after all, you’re paying to see the speakers — I disagree that your slides don’t matter. Your slides can be a valuable part of the experience for the audience.
Different Ways To Learn
Thanks to Heather White and her fantastic talk at Lone Star PHP, Stepping Outside Your Comfort Zone: Learning to Teach, I learned there are seven different majors ways that people learn:
- Visual
- Physical
- Aural
- Verbal
- Logical
- Social
- Solitary
I try to hit as many of these as possible with my talks, I use photographic title slides to give visual learners a keyframe to hang on to, as well as bright colors and diagrams. I speak out loud for aural learners, and often my talks are recorded. Physical learners can take their own notes, and I encourage questions for the social learners.
Presentation Technique
There are two different presentation techniques I see commonly used.
Bad Subtitles
As some of you may know, I have a hearing problem. Before I got hearing aids, going to a talk was hit-or-miss. If the speaker or the PA was too quiet, all I had to go on were the slides.
Due to my hearing loss, I always (even now, with hearing aids) watch TV with subtitles/closed captions on — I find that if you put too much content on your slides, they start to become bad subtitles for your speech.
I get distracted by differences, and I focus more on the words on the slide than what you’re saying. Combatting this scenario is why the advice de-emphasizing your slides is often given.
No Content
To counter this, some speakers have started to do slides with just images/gifs, sometimes adding a word or a title. This can be entertaining in person, but I get frustrated when I hear about a great talk and the slides end up being 25 pictures of cats with random words — there is no take home value, and nobody is going to retain everything you say.
Splitting The Difference
I try to blend these two techniques by having a title slide that I talk to, and then behind it I have bullets with more details that I usually skip passed during the talk. This slide serves three purposes:
- Speaker notes: I set Keynote to show only the upcoming slide in the speaker view, and I use the bullets as speaker notes
- Clarification: I can switch to that slide to clarify something, e.g. a class name
- Take home: when I upload the slides, I leave those in, they summarize everything I’ve said
Design
Fonts
The most important thing for a slide is legibility, so I spent a lot of time picking fonts. I have gone with the “Source Pro” family from Adobe, these comprise of Source Sans Pro and Source Code Pro. There is also the most recent addition to the family is Source Serif Pro, but I try to limit my slide to two fonts.
One of the benefits of these particular fonts is they come in a bunch of weights. This gives the ability to emphasize (semi-bold, bold, black weights) or de-emphasize (extra light, light) portions of my text.
These fonts also hold up well at font sizes small and large, and in print. I use Source Code Pro every day in my IDE, Editors, and terminals, and have blown it up to fill a wall on a projector.
In fact, I use these same two fonts on this site, Source Sans Pro for titles and body text, and Source Code Pro for code (I override the default gist stylesheet for this!).
I try to make sure text is no smaller than 60pt, but will go down to about 52pt if necessary.
Colors
The most important thing about colors is contrast. I have found that on-the-whole, bright colors on a dark background stand the most chance of being visible on projectors, but I did have to invert my slides for one conference this year.
I ended up finding the monokai theme that is available for most every highlighting tool, IDE, editor, and terminal out there. The monokai theme consists of five colors on a grey background, to which I added the Akamai blue and orange (branding++), and white for titles/text.
I use these eight colors for all code, graphs, and diagrams in my slides:
Title Images
As mentioned, I use images on my title slides. I generally go for images that are visually striking, and are in some way related to whatever topic the slide is about. For example, for HTTP/2 Server Push, I used a picture of a push mower (and in fact, replicated that in this post on server push).
I find most of the images I use by using the Flickr advanced search. I set license to “Commercial use allowed” (I find conference talks a grey area and decide to err on the side of caution), ensure safe search is on, and change the sorting to “Interestingness”. Sometimes I will also open the Advanced panel and choose only portrait orientations and large images.
If this doesn’t yield usable results, I will fall back to Google’s image search. Here, you can also set your license under “Search Tools > Usage Rights” where I choose “Labeled for reuse”, I set “Type” to “Photo”, and “Size” to “Large”.
I find this typically will yield a visually striking image that I am free to use so long as I follow the rules laid out by the (typically Creative Commons) license.
I will then place them on my slide and change the transparency — due to the dark grey background behind this will darken the image, until I feel there is enough contrast between the image and the title text
Code
Lastly, the code. I do try to limit the amount of code I put in my talks, I don’t think slides are the best medium to learn to code from. This does mean that I try to make my code as easy to consume as possible.
Syntax Highlighting
As I mentioned, I use the monokai theme (or monokai-light for the inverted one), and I use the python Pygments library to perform the actual highlighting. Pygments has the ability to output RTF formatted output, so I have a function in my bash setup that will take the contents of my clipboard and replace them with a syntax highlighted version of the same text:
This function will take the first argument to specify the language to highlight (defaults to PHP), will set the “startsinline” option if necessary. It then pipes the output of pbpaste into pygmentize, passing in flags to set the format -f rtf, and then sets the theme (style), font (fontface) and font size (fontsize) options with the -O flag: -O style=monokai,fontface=Source Code Pro,fontsize=120. The fontsize is double whatever the pt size would be, as I mentioned earlier, I try to use 60pt, so it’s set to 120.
Lastly, it pipes the output to pbcopy allowing me to just Cmd+V and paste it back into Keynote.
I still call it like key for PHP code, or say key json for JSON instead.
Example Highlighting
I also use animation to highlight code as I step through it — this is what I think makes most people ask what tool I use.
You can see an example here:
The purpose of this is to ensure that the audience can follow along as I explain the code. I will also show larger blocks of code and zoom in and pan around, I believe this helps maintain context in larger code examples.
I do this entirely in Keynote. This effect is created primarily with three shapes, the first two are both black rectangles set to 65% opacity for obscuring the upper and lower parts of the code, while the third is transparent rectangle with a white border, allowing me to “ring” the code I’m highlighting.
I used to “hand” animate each stage of the animation, painstakingly adding animation “Actions” to move and resize the three independent elements, but I have now come up with a better technique: Magic Move.
Magic Move is a slide transition that will cause Keynote to automatically create an animation between matching elements on two different slides. So now, rather than have one slide with 30+ different animations, I duplicate the slide, move the elements where I want them to end up for that step, and turn on Magic Move for the previous slide:
This drastically cuts down on the time it takes to do the animations and the animations end up being smoother as a result. I no longer dread wanting to change the code on any given slide.
Live Demos
My typical mantra when it comes to live demos is: don’t.
But, there’s something entertaining about a live demo, and I’ve never met an audience who wasn’t forgiving about issues. My hard and fast rule is to never do a demo that requires internet connectivity.
When giving live demos I always make sure I have a screencast of the same demo, as well as screenshots — worst case scenario I can flip through slides and give the play-by-play.
More recently I’ve been building my demos inside docker containers; this gives me a simple and easy way to manage them, and ensure I’m getting repeatable results every time.
Time & Effort
I put 120+ hours into every slide deck I create, and I continuously tweak them before every presentation based on the previous rendition. I strive to make them as entertaining and educational as possible for the live audience, while also being informative for the passive audience.
Not Without My Slides
While I can give my talks withouts my slides — everything I say in my talks has at some point been part of a conversation at least once I’m sure — I truly believe that they enhance my ability to teach dramatically. At the end of the day, the goal is teach something, and as we learned above, different people learn in different ways.
So, yes, I can give the talk without my slides, but I’m potentially leaving people behind if I do.
Thanks to Katie McLaughlin for reviewing this post.