Some Tips for Running Online Training

Last week I ran a remote training course for a client. It went surprisingly well. Some things went well because of planning; some things went well because of luck. Some things went poorly in spite planning; some things went poorly because of luck. This article is based on Twitter thread I wrote about the experience and discussions I have had since.

The course was supposed to be a 4-day onsite course. It was converted into a 4-day online course as that is the duration that was promised. I would not recommend this duration for an online course. A 2-day course run over 2 days or 4 half-days is kind of the limit. Short durations and small numbers of participants are to be preferred to full days and many people. Online learning has an intensity and focus that can be exhausting, both for trainer and for participants. Appreciate that, if they're at home, they may also have family commitments. To accommodate all these concerns, start late (e.g., 09:30 instead of 09:00) and finish early. Note that squeezing the day (or making it a half-day) also better accommodates people in different time zones, if that is a need.

Stick to a schedule — the situational looseness you have in a classroom does not work as well in a virtual class room — and take scheduled breaks of fixed duration. Break every hour for 10 or 15 minutes, and take a full hour for lunch, unless your days are short enough that it's better to reach the end of day sooner by taking half an hour.

Use a countdown timer on screen so that everyone knows how long the current break is. Importantly, this should be a countdown timer not a clock: people may be in different time zones; your local clock may be a couple of minutes different to someone else's; there's less room for human error when someone glances at a countdown than when they work off time of day.

I'm not going to recommend a specific classroom or meeting platform. Partly because I lack the experience, but also because, up to a point, you can pretty much make anything work with even the simplest of tools: talking head of presenter, screen sharing and a chat window. Other tools may be found within environments or supplemented using external tools (e.g., for coding, consider cyber-dojo.org).

That said, I will pass on my experience in this case: The client preferred to use Adobe Connect. So I did. Don't. I was peripherally aware of this product, but I thought this was a legacy product from Adobe (e.g., use of Flash and what felt like a UI still in the prototype stage). Apparently it's not, but it's not one they're taking seriously, so you shouldn't either.

There will be connection and software problems. That is inevitable. If there are serious problems, reschedule and replan accordingly. As you go, check back with people to see that everything's OK. They will normally tell you quickly if it isn't. People may drop out because of connection problems, so let them know it's OK to ask for a recap of anything they've missed.

It can be worth running a separate device as a canary to check what other people are seeing. Likewise, have a window/console open with an ongoing ping lets you observe any connection issues as they happen (and resolve), so you can correctly determine whether it is you or someone on the course who is experiencing a connectivity problem. It is definitely worth having a second screen on your main device, so you can share a whole screen that is under your control, and not just rely on app sharing. Also worth using a headset and a mic (or better, if you have it available).

Interactive exercises can be more awkward, so more careful scripting and preparation makes sense. I normally use a whiteboard a lot. I switched to preparing slides for the things I would normally write out, and also using a stylus on screen to create hand-drawn slides (I'm using Microsoft Surface Book).

Add your extra materials to a PDF that you update and share with participants. This is a technique I use in some of my existing workshops and courses, where I update slides with photos of whiteboard content, plus extra links and new slides that are relevant.

For example, I use this on my Architecture with Agility course, which I guess is self-referentially an example of agility: you have a general plan, but your content is not fixed, and it evolves, elaborates, refines and detours as you are giving the course. At the end, participants have something they can go back to that reflects the experience they had, rather than a slide dump of a generic course.

Take advantage of your unique situation. It's easier to show web pages you find useful — you're at your keyboard to start with! But it goes further than this: I'm in my office at home, which means that when I refer to a book, I can grab the book itself and show it — but if you can't find it immediately, don't waste time looking for it: look for it again during the next break or before the next and come back to when you restart.

Recognise that not everyone can be present all the time and, even when in theory present, many will undoubtedly be second-screening. In practice, what this means is that recaps are more valuable than usual. Don't schedule critical info or activity for beginning of a session, especially at the start of the day or just after lunch.

Not all courses and workshops will be suitable for an online approach, but I suspect this is something we are going to get better at given the current situation! My experience so far has me comfortable with lecture-style courses (e.g., software architecture) and coding hands-on style courses (e.g., TDD).

Speaking of code, a couple of further thoughts on presenting code during a course, workshop, talk, etc., some of which also apply more generally to conference talks.

Your normal development set-up is most likely entirely unsuitable for use when presenting: font size too small; poor foreground/background contrast; screen cluttered with tools; build/pipeline filled with noisy and distracting output. I see this all the time at conferences — and no, it doesn't work there either.

Use or create a distraction-free editing set-up — large font, no tools, different colours. If you can work outside an IDE, do so (I find Sublime is just right for most needs).

If your code is simple example code, with few dependencies, online compilers can be a surprisingly good option. And, depending on what you're doing, they can be useful for participants as well — eliminates a large number of setup problems/differences!

If you are doing a full course, it can make sense to do a full live coding demo, but in many cases (especially for shorter sessions and conferences), resist this.

Watching someone else coding slowly can be as dull as it sounds. And yes, unless your examples are sufficiently simple, it will be slow. No amount of auto-completion or IDE-fu will save you: all that happens is that it just looks more distracting as people can't tell what you're doing. The speedy automagic just becomes a flickering annoyance. In other words, aim for simple examples and, where you need something more complex, prepare as much as possible in advance, copying and pasting in as necessary, or go back to the code later and revisit it, walking through it for the participants, when you've had a chance to complete it.

My thanks to those who have commented on and contributed to this discussion, in particular Dave Nicolette, Rob Smallshire, Yves Hanoulle, Kate Gregory, James Grenning, Dan Terhorst-North, Emily Webber and Joseph Pelrine.