By Software Sustainability Institute Fellow Matt Williams, University of Bristol
This post first appeared on Matt Williams' blog.
Last Friday we ran the first online-version of our successful software engineering, data analysis and machine learning workshops. Previously, our workshops were three-hour in-person events. Attendees would work at their own speed through self-guided web-based material. The workshop lead would present short sections of live-coding, while helpers would walk the class to make sure everyone was ok and to solve problems. All in all, these workshops went really well when we ran them in person. We had developed a large menu of workshops that fitted together into a coherent program, and were teaching ~1500 training spaces per year across the university.
Events mean that we now have to run our workshops online. We wanted to preserve the same dynamic as in-person as much as we could. This meant having a single presenter doing occasional live-coding, and having helpers virtually “walk the class” to keep everyone engaged and to solve any problems.
To achieve this, we chose the following technologies:
- Course web pages
- We retained our existing web-based course webpages, as these were already online and self-guided, and we thought it was better to not put effort into changing these now.
- Video conference
- We chose Microsoft Teams for the actual video conferencing. We chose this as testing earlier in the week showed that this would be stable and could scale, and that the chat would work well for gaining immediate feedback from attendees. Another major benefit was that Teams gave us a single URL that attendees could click to connect, and that this worked in their web browser. There was no need for them to pre-register or download additional software.
- Breakout rooms
- We set up a series of Google Docs to act as a scratchpad for the class and also to provide a set of breakout rooms. These were used if we wanted to pull an attendee out of the chat and provide a 1-to-1 or 1-to-some space for solving problems. Google docs was chosen as it works well for real-time collaboration and it made it easy for attendees to upload screenshots from their computer for discussion. Most importantly, we chose a Google product to provide some resiliency in case MS Teams went down. We reasoned that if MS went down, then we could redirect to Google Docs, while if Google went down then we could keep things in Teams. If both Google and MS went down simultaneously then this was an internet problem that was bigger than we could handle ?
- Back channel
- We set up a private Slack channel that the presenter and helpers on the workshop used to keep in contact. We set up our phones so that a DM on Slack would give a notification, in case anything urgent needed to be communicated. The back channel was on a third platform again for resiliency, plus also because we all had it on our phones.
For setup, most helpers only had a single laptop screen plus a phone. Ideally a second screen each would have been helpful but we didn’t have any to use when we ran the workshop. I led the workshop and was the only person who had their video and camera on. All other attendees were muted and had cameras switched off. I shared my desktop so that everyone could see me presenting and live-coding in the same way that I normally do during an in-person workshop. I had two full-time helpers (Christopher Woods and Chris Edsall) and two helpers who dropped in and out as work allowed (Alastair Tanner and Gareth Jones). The helpers connected to the workshop using the same technology as the attendees, so that they could quickly report to me on any technical problems. The helpers also had the Teams chat visible, and quickly responded to any requests for help as they were reported there. In addition, Christopher acted as a narrator and wrote into the chat key points as I raised them, e.g. short text summaries of what I presented, links to material, quick summaries and attempts to generate audience participation (e.g. questions).
To keep track of everything during the session I had my laptop on which I was logged into Teams and was sharing my screen to do the live-coding and broadcast my voice. A tablet was perched next to it to allow me to follow the notes without having to be switching my screen between two views. I also had my phone on which I was connected to the Teams chat to keep up with what people were saying and also to the backchannel Slack so I could converse with the helpers.
I started the workshop with a full description of the online system and clear instructions on how to ask for help etc. I introduced myself and each of the helpers and also gave time for attendees to make sure they were ready. I then let attendees know that we wanted to record the workshop. I reassured attendees that, as their microphones were muted and cameras off, that they were not going to be included in the video. Unfortunately, the recording didn’t work (or, at least, Microsoft Teams hasn’t yet sent us the processed file ?). Next time we plan to use local screen recording, perhaps using something like OBS.
The workshop went really well. A sense of community learning built up, especially as attendees started asking questions. Many questions were quickly answered in the chat for all to see. However, some were more technical, so one of the helpers instead posted a link to one of the Google Docs breakout rooms and had a more in-depth one-to-one discussion there. This included having the attendees post screenshots to make it easier to debug issues.
We had a “coffee break” at 3.30pm, which fell about half way through the three hour workshop. This provided time for bathroom breaks, time to get a drink, plus also time when we could catch-up late starters. Interestingly, the workshop started small (just six out of 30 sign-ups initially), but a further four joined after 15 minutes. Reassuringly, everyone stayed to the end. We expect as word gets out, that the numbers will quickly increase.
We have a standard feedback survey that we use after all workshops. We adapted the question about the quality of the teaching room to instead ask about the quality of the online experience. We had five responses to the survey, so not enough to draw strong conclusions. However, from those responses we scored;
- “How useful was the workshop on a scale of 1–6?” 3×6 and 2×5
- “How knowledgeable was the tutor on a scale of 1–6?” 5×6
- “Would you recommend the workshop?” 5 × yes
- “How would you rate the virtual classroom on a scale of 1–6?” 2×6 and 3×5
Anonymous comments included:
Doing it online still worked very well. Some slight lags between screen and speech but apart from that all worked very smoothly.
It was awesome being able to tidy my room during the break and even go to the toilet without missing out on content^^
I think it could be easier to resolve doubts when we are in the same room, but that would not be necessary if we had more time to answer questions in between the exercises
Really enjoyed the course. I have used parallel programming before but not really understood what was going on, so was very useful to get this insight into what was actually going on a bit more.
For this class, we had a very high helper to attendee ratio. Our plan for future classes is to have a minimum of one presenter and one permanent helper, with extra helpers rotated into the workshop for 1.5 hour shifts (switchover at the “coffee break”). We think that we would need one helper per 10-15 attendees, and that we could scale up to hold classes of 30-45 people.
As mentioned, we plan to record entire sessions in the future and intend to edit these down so that we can gradually supplement our online workshop notes. We’d like to add live-coding video snippets linked to each concept in the notes. This would allow attendees to learn the material in their own time, or to provide links we can send during a live workshop to attendees who arrive late, or who need to move through the material more slowly than the bulk of the workshop.
The major difficulty from holding the workshop this way was to gauge the right pace. We deliberately went through the material much more slowly than normal, and spent a lot of time asking people if they were ready to move on. We let faster attendees know that they could move ahead to later material and ask questions in chat / breakout rooms if needed. Still, it was a challenge to judge where everybody was. In person we know because we walk around and can see which sections people are working on. We need to find something similar for online workshops, and may switch to using more polls or other feedback-generating tools to judge the mood of the class. On that topic, we’re really interested if anyone knows how to get polls working in Teams ?. We also think that running an ice-breaker exercise at the beginning would be useful to get attendees used to how the whole system works. Also, we miss the red and green sticky notes - an app in MS Teams that provides virtual sticky notes would be really useful ?.
In all, we are very happy with how the workshop ran. It was almost as good as an in-person workshop and the attendees definitely got something out of the experience. We will be running another workshop on Friday (“Best Practices in Software Engineering” - Bristol-based people can sign up here) and then expect to run workshops every Monday, Wednesday and Friday afternoon. While initially these will be for Bristol-based attendees, we aspire to open these up to the wider UK community in coming weeks, assuming experiences of having larger numbers of participants at Bristol are good.
The course we have planned for the next few weeks are:
- Friday 27th March: Best Practices in Software Engineering (Bristol University sign-ups at Eventbrite)
- Monday 30th March: Beginning Python
- Wednesday 1st April: Beginning Python
- Friday 3rd April: Introduction to Data Analysis with Python
- Monday 6th April: Intermediate Python
- Wednesday 8th April: Introduction to Data Analysis with Python
Assuming that all keeps going well, we plan on putting on more after Easter. The full program in the future, along with links to sign up for these will be announced via @BristolRSE.
Want to discuss this post with us? Send us an email or contact us on Twitter @SoftwareSaved.