This blog post looks at the impact the pandemic has had on the delivery of Carpentry lessons. For those unfamiliar with The Carpentries, it provides a very hands-on way of learning new basic computing and data skills while establishing good practice through a focused set of lessons, usually spread over a couple of days. An instructor typically stands in front of a class with their computer screen projected onto a screen, and learners type along with the instructor on their own machines. Any necessary troubleshooting is done by a set of helpers milling among the attendees. The feedback we have obtained for such events has been very positive, but the pandemic put a temporary end to this type of teaching. However, there was still a need and a desire to deliver this type of training so an alternative means of delivery had to be found.
Choosing a platform
A number of virtual platforms were tried but a lot of these were found wanting for the agile delivery required by Carpentry workshops. Other issues also had to be taken into account, such as the platform's ability to cope with non-uniform bandwidths of participants.
On the plus side location ceased to be an issue with instructors and helpers being sourced from different parts of the UK with no travel required, and participants being able to attend regardless of where they lived. Savings were made on travel and accommodation and the overall carbon footprint was reduced.
In the end, Zoom seemed to meet most of our requirements despite the fact that there were security and privacy issues voiced by many (also see this BBC article). Video-conferencing platforms are not a static playing field - many improvements have been made to Zoom and the other virtual delivery platforms since the pandemic started.
What we learned
We have previously identified some good practice tips for running online training. Here are some new observations and suggestions we have identified and can offer.
Before the workshop:
Plan the format of the workshop. When running workshops online, things could take longer than for an in-person setting so you can expect to cover less material. For example, troubleshooting issues on people’s machines is harder, you need longer breaks, later start and earlier finish times. You should experiment with the format used for running your workshops - instead of running it over two intensive days, do it over 4-5 half-days, and consider giving participants some consultancy for their own problems. This will also give the added bonus of giving people more time to assimilate the material in between the sessions and see how newly acquired skills may be applied to solve real-world problems.
If you intend to record any of the sessions get written consent from participants to be able to share the recordings on platforms such as YouTube. Perhaps build this into the registration process.
Set up a backchannel for communication before and during the workshop between the training team members, separate from the workshop chat. We have used Slack for this with success.
Run installation and familiarisation sessions to do any troubleshooting and check that things have been installed properly (possibly give them a post-install task to check this), and to familiarise with the virtual platform that will be used. This will save you time at the workshop, but from our experience these have unfortunately not been well attended.
If a course relies on data or template files, make sure you have an alternative way of delivering them to the attendees in case they become unavailable on the day. This has happened in the past where third party file repositories and lesson material repositories have gone offline.
Share contact details for instructors, such as mobile phone numbers, among the delivery team in case they drop off a session and do not immediately reconnect. This allows you to establish whether their situation is recoverable or not. Have a back-up plan in case this happens.
During the workshop:
Make sure participants download the data into an expected location. This will reduce errors and confusion during the workshop. You can also do this as part of the setup session.
Start coding from a blank script and build it up - try not to show pre-populated and commented out code so as not to confuse learners.
Remind participants that they should be coding along with the instructor, not just observing.
Dedicate a helper to type content to the shared document/chat to help attendees keep up with any content they may have missed.
Show the text for each exercise on the shared screen - people get lost as to what they are supposed to do. Use a countdown timer for exercises and show this in the shared screen - it will help put time limits on activities. A number of free countdown timers are available for Windows or Mac platforms, including online (e.g. BigTimer, Cuckoo online timer, Smart timer for Macs and PCs).
Make sure to check often if participants are lost or if they need help. Be friendly and helpful. Leave no learners behind.
Ensure that helpers keep an eye on the chat and respond in a timely manner to provide help (if you designate chat as means of signalling an attendee problem). A better alternative may be to invite participants to speak up and seek help directly from the instructor so they do not fall behind while helpers type answers in the chat. We have openly invited participants to do so but they have preferred chat for asking for help, possibly not to draw too much attention to themselves. Break out rooms may be used to fix intractable problems but this will interrupt the flow for the participant - if the problem can wait, deal with it during the next break.
Learners’ screen setup is very important. On one hand, having multiple devices (one to connect to Zoom and one for working) is good as they do not have to flick between screens all the time. The disadvantage is that sharing the learner’s screen with their work becomes impossible as well as copying the commands/links from the Zoom chat (which is on a different device in this case).
Zoom now allows screens to be shared by multiple participants at the same time (this has to be set by the host) - this can help helpers with any troubleshooting while allowing the instructor to carry on.
If teaching is reliant on a terminal or shell, you can provide an alternative means for delivering content through Shellshare, which provides live terminal broadcast capabilities.
After the workshop:
Have a post-workshop discussion with the delivery team to go through feedback. Use the team’s communication channel during the workshop to catch anything that can be improved immediately in the following sessions. Record these as lessons learned.
Make video recordings available, if any, and notify participants.
These heuristics have evolved in conjunction with the advance in technology and as we gain in experience from running more workshops. We hope that you will find these useful and be able to use them in your own teaching - if you have any tips you would like to share with The Carpentries community we would love to hear them.