2018 is a year of transition for many webinar technology vendors. Products that previously used Adobe Flash Player to handle two-way communications between webinar participants are being rewritten and re-released to use HTML5 and WebRTC as the underlying enabling platform. By the end of the year, you should not find any remaining Flash-based web collaboration products.
Webinar products that install a program on each participant's computer ("client software" in programming parlance) are mostly immune from this transition. Examples of those include GoToWebinar, Zoom, and the desktop-installed version of WebEx.
Products that run entirely in web browsers - with no download and install step - include names like Adobe Connect, Webinato, and ON24.
The single biggest difference in operation as browser-based products move to HTML5/WebRTC is in the "call and response" nature of two-way collaboration. Current implementations of WebRTC-based data/video/voice buffer the feed from the presentation side and then send it out to the consumers of the stream (webinar attendees). Attendees might hear a presenter's comments 5, 10, 15, or even 30 seconds after the presenter said them.*
Vendors typically shrug and say:
"As long as the audio and visual information stays in sync, who cares if it shows up a few seconds later as opposed to immediately?"
I care. And your guest speakers who don't do web presentations for a living are going to care. Because suddenly the way you interact with your audience changes.
As a webinar moderator or facilitator, I often start events by saying "I just want to check to make sure our audio is working properly. Would you type your first name to let me know you can hear me?" I wait a second until I see the first name or two come in, and then I know it's safe to jump into the content. But what if attendees receive a buffered stream? I ask my question and they don't hear it for 10 seconds or even 30 seconds. I see no responses in the chat window because my attendees don't even know I've asked a question yet.
Do I wait for a response until I know that people can actually hear me? Or do I plow ahead and if I don't see something within 30 seconds I know something is going wrong?
What happens when you get a good, experienced speaker who likes "working the room" and encouraging feedback and response from the audience? They keep asking for quick inputs and responses…
- "How would you deal with this?"
- "Is this making sense so far?"
- "Should I move on, or go into more detail?"
- "Click the 'raise-hand' icon if this has ever happened to you."
They naturally expect to get something back. They are ready to create a sense of interplay to show that they value the contributions and impressions of their attendees. But instead, they sit there, wondering what is happening. They don't know how to proceed, because the next thing they were going to say was dependent on the responses they saw. It's the dreaded "dead air" syndrome.
The effect then intensifies. Attendees were hearing a good presentation with things clipping along nicely. They heard a question and quickly typed in a response. Then nothing… complete silence after they responded. What has happened? Has the audio gone dead? Did their submission not go through? Maybe they should type another message. "Is something wrong with the audio?"
The presenter has finally seen the responses and starts talking again, but 30 seconds later, he sees a bunch of messages indicating there might be a problem with audio. He asks, "Uh oh… Can you hear me?" And again sees nothing for a while. Now panic sets in. "It looks like we have a problem… Oh wait. I see a bunch of responses now. Okay, it looks like audio is still working. Where were we?"
Of course this can all be avoided with proper training and expectation-setting. Presenters must be taught about the delay in seeing responses. They should learn to keep talking - to fill the gap until they get the feedback they were looking for. In many cases, it is best to let attendees know when you ask a question that you will come back to it in a minute to discuss the submissions once everyone has had a chance to contribute.
That small amount of presenter training is easy enough to imagine and easy enough to convey. But it's not natural. For many people, it stunts their natural speaking style and makes them even more uneasy about this artificial presentation environment where they can't see the people listening to them. "Now you're telling me that not only can't I see them, but I can't even ask them a quick question on the fly?!?" It's going to increase the tendency for people to speak "at" their audience rather than "with" their audience, killing the conversational nature of good communication.
If you work with guest presenters, you will need to let them know how "live" their live session actually is. You'll need to go over techniques with them to deal with question/response situations. If you are a webinar presenter, you'll need to know which technology you are using and what you should expect in terms of interactive latency. Then you'll need to actively practice this technique.
* I believe this is a temporary problem that WILL get a technical solution. People in the industry are already working on ways to reduce stream buffering and reception latency for large audiences. I recently read an interesting blog post from a vendor working on a plug-in designed to all but eliminate the lag and get it back to what we were used to from Flash. But it will take time to pivot and time to roll out new implementations. In the meantime, best practices for presentation style and technique are going to be dependent on the presentation technology being employed. Don't overlook this consideration.
