I’ve been doing quite a few presentations lately, and I am currently following a method that has been working out for me quite well for the last year or so.
I don’t claim my method to be unique, and it’s definitely inspired by people I’ve seen presenting, worth mentioning are Scott Hanselman and Steve Sanderson. The reason for this post is only to share with you my approach and hope you will find it helpful. I won’t iterate over great presentations tips posts that you can find over the web but just describe the process I am using.
So with that long introduction beyond us let’s get to step number 1.
1. Organize your talks on disk– I’ve created a folder to contain sessions that I consider active. Once in a while I scan that folder and retire talks that are not likely to be used in the future and move it to another folder, so this folder won’t be cluttered and you can navigate and find your stuff quickly. (Make sure this folder is backed up regularly, anyway today it’s not an excuse anymore to backup everything you have for a few bucks a month).
2. Create a folder for new talk – this one is quite self explanatory. I use the format of starting with a date and talk subject but you should change it for whatever works out for you.
3. Brainstorm.txt – With a technique mainly learned from Scott Hanselman, I’m starting out every new talk by creating the Brainstorm.txt. I putting into the file ideas, bullets of topics I would like the talk to contain and I try to measure out the timing for each topic. Later on it will be my talk note which I can print out and place it near my machine while presenting, containing important stuff I want to remember and timing and make sure I’m on track.
Here is an example:
* Azure Mobile Serivces
* Phone API
— 5 min
Motivation for this talk
Decided we want to build a wp8 app. But what are the steps to follow?
— 10 min
Idea: Show the final app.
—- 15 min
Show Pivot vs Panorama
Show some frameworks: SuiteValue, MVVMLight
Talk about WAMS
—- 35 min
Part 0 – Setting up from new project. Adding packages: SuiteValue and Toolkit, Add Icons and splash.
– Setting up StandardFiles and Folders
– Adding App specific service code => Part 1
Part 1 – Adding Pivot + ViewModels composition => Part 2
Part 2 – Adding Invite UI + ViewModel => Part 3
Part 3 – Adding Invite Command + AppBar => Part 4
Part 4 – Adding Gifts UI + ViewModel => Part 5
Part 5 – Adding CustomMessageBox for editing Gifts => Part 6.
Part 6 – Adding Unitest project and showing Asynchronous tests => Part 7
4. Creating slides for talk – nothing new here, by following the brainstorm.txt, I can structure my slides with more ease.
5. Writing Code – For most of my talks I try to create a sample application or applications and demonstrate the features of whatever I’m talking about. I avoid completely the use of snippets (I had more then one talk that is completely unusable now cause I’ve somehow (or more precisely Visual Studio) lost those snippets.
Instead of Snippets I use Git. (the inspiration for this came from Steve Sanderson that used in one of his talks a source control to jump straight to a working demo). Git will server us really well, it is fast, it is robust, it can be pushed to github (By the end of my talk I share a url for the github repository to people get immediate access to code and slides), it contains everything locally, it can be moved around without fear of breaking up and much more.
When I have git created, I start working on my demos, I can use git and commit, but it’s completely optional and up to you. When you are done and everything is ready do make a commit, so you can always go back to the final state of the demo application.
Now, it is time to start removing code and features (YES). Delete and remove till you are back to what you consider square one, meaning, at the start of your talk this is how you want the sample application to be, it can be empty, it can be already doing stuff, all depend on your talk.
Now tag this commit with “Step0”. This is the baseline. Every time you are going to present this talk, you can “checkout” and return to “Step0”.
From here you start adding code. granularity of the steps is up to you, I usually prefer to have a something that can be shown to the audience with every passing step, but it’s really your choice. Whatever you do be consistent and name them “Step1”, “Step2”, … , “StepN”. I like the steps to appear in the Brainstorm.txt, so I will have a cheat sheet during the talk to remind me what each step should do. (also good when you review the talk after a while) In some cases I also mention the main file which the step had altered so I can make sure to avoid having crowd fear to forget what did I change.
Using this format it’s very clear for the eye during the talk:
Part 3 – Adding Invite Command + AppBar => Part 4
Part 3 is the start for this sample, and Part 4 has this demo implemented. Easy and clear.
Add code, Commit, Tag, update Brainstorm.txt, repeat and rinse.
By using this technique you can pretty much concentrate on the code itself. for example it is most likely you have added all the necessary references in Step0, cause you have only deleted code from the final version when you got to Step0.
Another critical benefit is that now you always have a working a demo. if you choose to live code part of the code and you get lost, you can always jump straight to the end of the step and viola, a working demo. No longer you need the mercy of the demo gods, you control the environment and it has zero chance for mistakes if you prepare carefully.
6. Preparing your tool for the talk – I usually use VIsual Studio in my talks, I’ve am using the Nuget console inside Visual Studio which is basically a PowerShell. You can configure PowerShell with Git by using this post. But you can use command line, I just like it inside the IDE, I don’t have to switch, and usually I can do it so quickly that the audience doesn’t really know how I’ve pulled that magic .
7. Executing the talk – now all you have to do is talk with confidence, smile, be responsive, enter git checkout –f “StepX” (-f is very important, cause you want to force and ignore any changes you might have made during the talk). After that I usually explain what were the code changes, so while I agree it is less visible then moving around snippets but with the right commentary it will be understood and appreciated by the audience that you don’t waste their time with fumbling around with code and snippets.
8. Wrapping up – usually I transfer my slides to PDF and push it to github as well, and share the link with the world.
Questions? No. Go and prepare for your presentations now you can concentrate on the content, and not on memorizing steps.
Good Luck, hope that helps someone.