Skip to content

Instantly share code, notes, and snippets.

@swinton
Created December 20, 2020 19:04
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save swinton/79f579cfc0131a196b1976767cf06425 to your computer and use it in GitHub Desktop.
Save swinton/79f579cfc0131a196b1976767cf06425 to your computer and use it in GitHub Desktop.

About

This 🚧 work-in-progress 🚧 playbook for developing and delivering webinar content, with a focus on delivering live demos...

πŸ“š Playbook

  1. I develop the narrative, e.g. as a high-level outline, using the team as a sounding board to get feedback / inputs early on!
  2. I try and write the least amount of code possible in the amount of time available! I can always fake it, e.g. I just started building this app, the important part is the narrative.
  3. Pre-recorded demos are great, they buy predictability but at the cost of prolonged preparation time, and they allow me to speed up boring parts, like waiting for builds to complete.
  4. My preference is to use ScreenFlow to screen-record my demos.
  5. When recording my screen:
    • I use my laptop's retina display exclusively, for the best possible results.
    • Any code snippets I use are pre-prepared and available on my second monitor so I can copy and paste at the appropriate moment.
    • I turn off stafftools, so any pre-release features aren't visible (use the backtick character, `, to disable stafftools)
    • I try to keep to the browser, to minimize context-switching
    • I use a private (incognito) session, so bookmarks, pinned tabs, extensions etc are all hidden
    • I make sure the date/time isn't visible in the screen-recording, so the content doesn't become dated, and so that I can easily re-record edits in the future
  6. After recording my demos, I share them with the team as early as possible to solicit feedback
  7. I edit my demos down using ScreenFlow again, erasing mistakes, and fast-forwarding through the boring parts (e.g. waiting for builds etc)
  8. I slice my demos up into individual files, each lasting a few seconds, and then drop each file into a separate slide in Keynote:
    • This helps me pace the presentation, I'm not rushing to keep up with the video, I can control when to advance to the next part of the demo.
    • Keynote also has controls to fast-forward (L), or jump to the beginning (I) or end (O) of the playing video -- which is helpful if your delivery is faster than when you recorded the demo
  9. I use presenter notes pretty heavily, essentially using these as a transcript.
  10. I record myself doing a dry-run, e.g. using Zoom, and then watch and critique, modifying the material / timing as I see fit! πŸ€”
  11. I prepare some seed questions in advance, so that I have something for the Q&A.
  12. When it's time to deliver... I relax, smile, enjoy it! I put my trust in all the hard work I've done up until this point! πŸ€—
  13. When it's over... I preserve the material to facilitate re-use,.
    • I use Git LFS to preserve large files, especially that Keynote file containing all that video!
  14. Finally, I consider sharing results appropriately, e.g. in an internal post.

πŸ‘€ See also

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment