Teaching Shiny Workshop at SatRday Johannesburg

Eating the cake first and playing games!

This month three SatRdays took place on the same day around the world. I was invited to one of them, SatRday Johannesburg, to give a training and a talk at. I was excited about it because it was my first #rstats event in Africa and I wanted to contribute to events in the region where few conferences are held relative to Europe or the US. The workshop I gave was about Building Web Applications in Shiny. And this is what I will focus on in this post.

My history with learning and teaching Shiny

I previously taught or helped others use Shiny, but this was the first full-day workshop I gave on Shiny. I hope some of the participants will also transfer what they learned to others. And that’s what I had in mind two years ago when I was granted a spot at the Intermediate Shiny workshop at Rstudio::conf 2017 which was taught by Joe Cheng. At this time, I went to learn more about Shiny but I also had another objective; I wanted to learn how to teach this material in an effective way. So I was focusing on the workshop design, observing how Joe Cheng and his assistants facilitated it, and imagining what I’d do in the future.

Two years later, the chance came to teach a full-day workshop, where I started to prepare my material. I already had an idea about how I’d setup the workshop but I luckily had additional resource about teaching Shiny made available by Rstudio on the Shiny Train-the-Trainer Workshop website, which is something everyone can benefit from. The sample curricula and the flow adopts Mina CetinkayaRundel approach of Let them eat the cake (first). I like this top-down approach and I got positive feedback about it in several occasions so my workshop was also designed that way.

The Interactivity Game

In addition, I had in mind a sort of a game about interactivity I wanted to experiment with during the workshop. The idea is to:

  • write a simple Shiny App with inputs, reactive elements and outputs.
  • make each participant play the role of an input/reactive element/output and take its name.
  • have a participant to play the role of a user who would change the value of inputs (here players).
  • ask players to raise their hands whenever they are affected by a change in an input/reactive value.

The point is to make participants understand dependencies and imagine the propagation of changes under the reactivity paradigm. I had a quick trial with this but the application was so simple we didn’t have many scenarios. So I’d like to try a more complex application with lots of dependencies while playing the game in the future.


I am glad I had this opportunity to meet such motivated participants from different backgrounds where everyone of us learned something by the end of the workshop. I’d also like to thank the committee who organized the event and brought us all together.


R  Shiny  SatRday 

See also