Over the past few months, I’ve started transitioning my slide decks to GitPitch. I’ve used reveal.js for years and enjoyed being able to put together presentations in HTML format. I can run these slides in any browser (or even phones) and don’t have to worry about Power Point messing up when I go to presentation mode. I also get the ability to transition up and down as well as left and right, which lets me “drill into” topics. For example, from my Genetic Algorithms talk:
If I want to go into a topic, I can slide down; if I need to skip it for time, I can bypass the section.
GitPitch also uses Reveal, so many of the skills that I’ve built up still work for me. But there are a few compelling reasons for me to migrate.
Reasons For Moving To GitPitch
So why did I move to GitPitch? It started with an offer to Microsoft MVPs where they offer a free year of GitPitch Pro. For transparency purposes, I am taking advantage of that free year. After the year is up, I’m going to start paying for the service, but I did get it for free.
So why did I make the jump? There are a few reasons.
Background Images
One of the best features of GitPitch (and a reason I went with Pro over the Free edition) is the ability to use a background image and set the transparency level. This lets me add flavor to my slide decks without overwhelming the audience:
There are a number of good sources for getting free images you can use for these purposes, including Unsplash, Creative Commons Search, and SkyPixel for drone photos. I’m also working to introduce my own photography when it makes sense.
Markdown
Reveal.js uses HTML to build slides, but GitPitch uses Markdown. Markdown is a fairly easy syntax to pick up and is a critical part of Jupyter Notebooks.
To build the slide above, the markdown looks like this:
---?image=presentation/assets/background/Background_13.jpg&size=cover&opacity=15 ### Outlook |Outlook|Yes|No|P(Yes)|P(No)| |-------|---|--|------------| |Sunny|2|3|2/9|3/5| |Overcast|4|0|4/9|0/5| |Rainy|3|2|3/9|2/5| |Total|9|5|100%|100%|
No HTML and it’s pretty easy to make changes. Because it’s a text-based format, major changes are also pretty easy to find-and-replace, something hard to do with Power Point.
Math
Recently, I did a presentation on Naive Bayes classifiers. To display math, we can use MathJax. Here’s an example slide:
---
### Applying Bayes' Theorem
Supposing multiple inputs, we can combine them together like so:
`$P(B|A) = \dfrac{P(x_1|B) * P(x_2|B) * ... * P(x_n|B)}{P(A)}$`
This is because we assume that the inputs are **independent** from one another.
Given `$B_1, B_2, ..., B_N$` as possible classes, we want to find the `$B_i$` with the highest probability.
And here’s how it looks:
I’m definitely not very familiar with MathJax, but there are online editors to help you out.
Code Samples
Another cool feature is the ability to include code samples:
What’s really cool is the ability to walk through step by step:
---
```r
if(!require(naivebayes)) {
install.packages("naivebayes")
library(naivebayes)
}
if(!require(caret)) {
install.packages("caret")
library(caret)
}
data(iris)
set.seed(1773)
irisr <- iris[sample(nrow(iris)),]
irisr <- irisr[sample(nrow(irisr)),]
iris.train <- irisr[1:120,]
iris.test <- irisr[121:150,]
nb <- naivebayes::naive_bayes(Species ~ ., data = iris.train)
#plot(nb, ask=TRUE)
iris.output <- cbind(iris.test,
prediction = predict(nb, iris.test))
table(iris.output$Species, iris.output$prediction)
confusionMatrix(iris.output$prediction, iris.output$Species)
```
@[1-4](Install the naivebayes package to generate a Naive Bayes model.)
@[5-8](Install the caret package to generate a confusion matrix.)
@[12-14](Pseudo-randomize the data set. This is small so we can do it by hand.)
@[16-17](Generate training and test data sets.)
@[19](Building a Naive Bayes model is as simple as a single function call.)
@[22-25](Generate predictions and analyze the resulting predictions for accuracy.)
I haven’t used this as much as I want to, as my talks historically have not included much code—I save that for the demos. But with the ability to walk through code a section at a time, it makes it easier to present code directly.
Up On GitHub
Something I wasn’t a huge fan of but grew to be okay with was that the markdown files and images are stored in your GitHub repo. For example, my talk on the data science process is just integrated into my GitHub repo for the talk. This has upsides and downsides. The biggest upside is that I don’t have to store the slides work anywhere else, but I’ll describe the downside in the next section.
Tricky Portions
There are a few things that I’ve had to work out in the process.
Handling Updates
Testing things out can be a bit annoying because you have to push changes to GitHub first. Granted, this isn’t a big deal—commit and push, test, commit and push, test, rinse and repeat. But previously I could save the HTML file, open it locally, and test the results. That was a smoother process, though as I’ve built up a couple of decks, I have patterns I can follow so that reduces the pain quite a bit.
Online Only (Mostly)
There is an offline slideshow mode in GitPitch Pro and a desktop version, but I haven’t really gotten into those. It’s easier for me just to work online and push to my repos.
When presenting, I do need to be online to grab the presentation, but that’s something I can queue up in my hotel room the night before if I want—just keep the browser window open and I can move back and forth through the deck.
Down Transitions And Background Images
One thing I’ve had to deal with when migrating slide decks is that although I can still use the same up-down-left-right mechanics in Reveal.js, when using transparency on images, I’ve noticed that the images tend to bleed together when moving downward. I’ve dealt with the problem by going back to a “classic” left-right only slide transition scheme.
Wrapping Up
I’ve become enough of a fan of GitPitch to decide that I’m going to use that as my default. I think the decks are more visually compelling: for example, there’s my original data science process slide deck and my GitPitch version. As far as content goes, both decks tell the same story, but I think the GitPitch version retains interest a bit better. As I give these talks in the new year, I’ll continue transitioning to GitPitch, and new talks will go there by default.
