I think for the moment we do the best we can, and try to use breakouts to support individual learners as check-ins. However:
Heresy below - but please hear me out!
If this becomes a teaching format we plan to use long-term, we should probably have an alternative version of our materials, which allow for collaborative code editing. This retains the core benefits of peer learning that make our in-person classes so special.
- We replace our live coding with a script that learners can execute on their own machine.
- We don’t ask them to type (I realise this sounds like heresy, but the bazillion screens and windows are a nightmare for even more experience learners: I tried to edit the code in the zoom window several times, because I didn’t realise it was your RStudio, not mine. was one of my intermediate learner’s comments). It is likely to be a disaster for beginners.
- The instructor still live-codes the materials, and explains all of the steps/mistakes/intermediate outputs generated as (s)he goes along.
- We then add a whole bunch of formative assessment/challenge tasks, that start with faded examples and build up to fully writing small scripts/tidyverse “pipelines”, which learners work on in breakout rooms as a group. These are commented out in the original script we give them, and which we uncomment and get them to work on throughout the course.
- We break them out into rooms (with a helper in each), and get them to use a plain-text website to paste their code snippet into and collaboratively edit (so copy edit on local machine execute and play around with then paste back into the online code editor when it’s working).
Also, for the above to work, we’d need:
- A good, Google Docs-like collaborative code editing platform
- A pre-workshop flight check for installation issues