Training pointers for running virtual events
Here are some technical guidelines for people helping to run online events with Zoom, showing how to work around the major snags that I've seen us all running into. The usual deficiency with training newer technicians only in "lecture format" using screenshares or static documents is that it's generally difficult to share live Zoom screens into another running Zoom meeting, so there are parts of the workflow that trainees rarely see until they have their own hands on the controls. If that isn't until the live event and something unexpected happens and the host doesn't know how to handle it, that's basically a disaster and a failure on the part of the trainers.
This attempts to illustrate some of those states and what to avoid, albeit still using a still-image format. At least it shows what the gotchas look like. The only real way for trainees to learn the full workflow is to set them up to start and stop sessions as hosts, bring in secondary participants using a second computer or device, and play with all the knobs well in advance of the event. Self-instruction meetings can easily be set up as recurring with no set schedule time, no waiting room, join-before-host enabled, and with simple passcodes. Trainees can start these up any time they want just by connecting to the meeting ID, and use a member account's "host key" to claim host and then explore the in-session controls. That's not the same as the sign-in password, and does not compromise the login itself. But to provide the full soup-to-nuts experience, the sign-in passwords must eventually be divulged to the tech staff. As a trainer and/or Zoom account manager, strike your own balance for what information to release and when. You do need to be able to trust your run crew, after all.
[Clarification: In "pro" or business-class Zoom setups, an "account" usually refers to the master billing entity, not the email-address based sub-users we sign into for hosting sessions. While the term "user" is insufficiently clear by itself, this explanation indicates the term "member account" to mean the credentials we use as hosts. These get set up and verified by the administrator of the master account, and each member is able to run one meeting or webinar at a time. Hereinafter, I loosely use the terms "member", "sign-in", "login" etc to indicate the entities that we generally work with.
Here is what the main Zoom client window looks like when it is signed in under member credentials -- it's the window on the right here; ignore the browser session to the Zoom website itself on the left. The window may look a little different for other operating systems and devices; the point is that whatever shows these four large buttons is what you see on a signed-in startup. The client is on the "Home" section, which is also accessible by clicking the icon under the pink arrow. There may also be some extra text about upcoming sessions. Except that we don't want this screen if we're looking to start a specific event session. Never use the red "New Meeting" button -- that would launch some random meeting-ID that nobody else could possibly know about.
|Instead, click the small Meetings icon [lower pink arrow] to move to the Meetings section. On this screen we now see the full list of upcoming [or even recent past] sessions that are actually scheduled under the member account. Hover the mouse near the right of each block to make the "Start" and other buttons appear. [Yes, hidden buttons is a stupid UI decision by Zoom, and it nonetheless pervades their client apps and website, so be aware of that.] Find the correct session for the timeslot you're hosting in, and start it.|
|Tech hosts need to coordinate with each other, so that only ONE person is signed in as a given member at a time. If two clients sign in under the same email/password creds, the Zoom servers detect that and we start getting these scary warning screens and pop-ups.|
Now, this is not the show-stopping disaster that it may look like, because
if a host who's already running a session sees this, it will *not*
kill the session in progress or disable the host's control of it.
The problem is that it looks all scary, and if a novice hosting tech hasn't
seen it before they can get freaked out and think the whole thing has
failed and they need to start over, or go ask for help, or whatever.
That is not the case -- it's just mildly annoying, and recovery is easy.
You just dismiss the warning and keep hosting the running session.
Sometimes a tech supervisor *has* to come into a meeting under its running
username to arrive as a co-host and fix a problem, so even if people never
conflict with each other under *normal* running conditions, it's essential
to know about this.
Here is Zoom's rationale for the behavior, which I finally got one of their support reps to admit to and detail via email.
|Zoom hosts are often asked to enable the closed-captioning capability, which provides an AI-based automatic text transcription capability for the hard of hearing. This used to be done via Rev or 3Play or other third-party services, but Zoom has developed their own built-in captioning service and all we have to do now is enable it. All desktop clients as of Zoom version 5.7.x should be able to do this now. [Linux lagged behind the other platforms for a while, but can now handle managing the transcriptions.] The host must enable the captioning, by clicking the CC button and selecting the "Enable auto-transcription" item shown below. Once that is running, any participant can click the CC button and disable the display of captioning *in their own view* -- thus its display is individually user-selectable once enabled for the session. [For the host, it's the little upward caret that appears *next to* the CC button.]|
|It is also up to the Zoom host to start any live-streaming of the meeting content. This is less common, but some events do run on the basis of a few participants in a Zoom together and then the audience watching the whole thing on some streaming service. Sort of the "poor man's webinar", and it is generally nice to provide some kind of side-channel service for chat and questions, such as Discord. For a recent event I set up a self-training scenario for our techs, with a set of throwaway Youtube streams ready to go so they could connect up and see the results of what they were doing. There is some understandable bias against Youtube as a "professional-level" streaming service but bottom line, it does work plenty well enough and gives an almost unlimited distribution factor. [See some more detail from that event.]|
Outside of Zoom itself,
tech coordination is often done in a Discord-based backchannel.
This is where hosts can hand off who is logged in as which member in their
Zoom clients, report problems, get help finding panelists, check in and
out for duty, etc.
While there is a lot to learn about Discord, one thing that may help
organizers is to have their staff actually use the Discord status to show
if they're "present" and available for duty or not.
Click your own icon/avatar at the way lower left of your Discord client, and then one of "online" or "invisible" to reflect your status. Even if you stay in "online" mode, When you kill your Discord app or browser window you will "go dark" automatically and pop back on the next time you connect. If you want to continue appearing "offline" and thus implicitly off-duty, just set yourself back to "grey" and it'll stay that way.
|For experienced techs and new folks alike, here is a simple text checklist for steps to perform while hosting meetings and webinars. It embodies many of the lessons we've collectively learned, over our pandemic year and a half of running online events by necessity. While we nominally hope to need far less of this in the future, some aspect of the technology will undoubtedly continue being part of many production events and continue to evolve for a long time to come.|