Web conferencing software can be broadly split into two categories… Those that require users to install software on their device (PC/Mac/Tablet/Smartphone), and those that run in a web browser without requiring local software installation.
As with everything in the tech world, there are added complexities… Browser-based platforms may require presenters to install an add-in or a local executable in order to do screen sharing. Install-based platforms may offer the option of a limited-functionality web version for attendees.
To help with the rest of this discussion, let me throw a piece of terminology at you… The program that gets installed on your computer is often referred to as "client software" which communicates with the "host application" (the brains of the web conferencing system managing the communications with all the participants - running on some other big computer out there).
Products that use locally installed client programs include familiar names such as GoToWebinar and Zoom. There's one small inconvenience and one big problem with this kind of approach. The inconvenience is that the vendor has to make versions of their software for the different kinds of computers that people might use. They'll typically make a program for Windows PCs, a different program for Macs, one for Android mobile devices, and another for Apple mobile devices. It's a hassle for the vendor to keep all those versions synchronized with the same functionality and to keep up with periodic changes to the operating systems they run on. But that's a well-understood necessity for any software maker and vendors know how to deal with it.
The big problem, and the one that the vendors can't do a thing about, is that many large companies with the most employees (and the biggest pocketbooks) prohibit their employees from downloading and installing programs on company computers. It's just too much of a security risk and support problem for their IT departments.
Imagine hosting a webinar and finding out that your biggest, most important clients and prospects in fields such as banking, pharmaceuticals, and insurance can't attend because they can't load the client program necessary to participate in your event. They're frustrated, you're furious, and the webinar vendor is powerless when you start screaming at them. The webinar vendors don't like it either… They can't sell their webinar platform to those deep-pocket companies.
So to get around the "prohibited install" issue, you can go with a platform that runs entirely within a web browser. Problem solved and life is easy, right? Not so fast, buster.
My personal experiences across many different technologies and many different webinars points to nearly every aspect of browser-based technologies being just a little less convenient, a little more confusing, a little less reliable, and a little worse in performance than I see with client-based platforms. Let's run through the list:
- Browser preference. The current trend for browser-based webinar technologies is to rely on HTML5, a protocol supported in all the major, modern web browsers. So most vendors will tell you that users can join via Chrome, Safari, Firefox, or Edge. But HTML5 implementations vary a little bit from one browser to another. I cornered a tech rep from one vendor recently who finally admitted that they vastly prefer users to join via Google Chrome because it has some "special helpers" built in that help improve performance. They didn't like Safari and didn't recommend it, even though it is the default web browser for most iOS and Mac devices. So all modern browsers may be equal, but it's worth trying to discover for your webinar technology whether some are more equal than others.
- Browser version. The average computer user is notorious for never upgrading their software. So you will find participants trying to join a webinar in a web browser that is woefully out of date. I still get occasional folks using Internet Explorer, a browser that was obsoleted and replaced by Microsoft Edge years ago. This can cause problems with webinar applications that expect the latest fixes and performance improvements to be available while running.
- Audio/video device access. Web browsers do not maintain tight integration with webcams, microphones, and speakers. They use a pass-through protocol for selecting and authorizing those devices when users join a web meeting. In most cases, this is just a wee bit less smooth than with installed client software that can remember your local device settings and grab direct access to your camera and microphone when needed.
- Leaving a session. Client software can tell when its local user closes the program and can take a final action step if necessary. When you close a web browser, it's simply gone. The software can't interrupt the shutdown or do anything else. Why is this important? One huge reason… If you configure a post-webinar survey to pop up when a user finishes the webinar, client programs can display the survey for people who leave early. Browser-based platforms can only show the survey for people still actively in the browser tab and running the application. You lose negative feedback from people who are dissatisfied and close the browser. This can artificially skew survey results to look more favorable, since the only people who see the survey are the ones who stay all the way to the end (or the few who elect to press a button and leave "programmatically" rather than by closing their browser).
- Audio/video performance. Aaaand now we come to the biggest and most contentious issue. This is something I can't prove… It's my anecdotal impression, built up over a long time. Overall, I don't think browser-based webinar technologies handle high load situations as well as installed software technologies. Add more simultaneous webcam windows and open microphones from a panel of presenters, and things can get screwy. In browser-based technologies, I see more mysteriously dropped video streams, more audio/video synchronization issues, more audio glitches that appear and disappear at random. The neophyte presenter then tells you in a wounded voice, "It's not me. This setup worked perfectly on my last Skype call (or Zoom meeting)." We live in an imperfect world, where users are often on slow, weak, overloaded wireless internet connections. I think browser-based communications are more sensitive to those imperfections than locally-running programs. This is most likely a fault that is inherent in the way the browser technology works, rather than being a result of shoddy design by the webinar vendor.
Is there a solution to our frustrations? In the best possible case, your webinar vendor makes a download & install client available and you recommend that to your participants as the connection method of choice. The vendor also provides browser-based access for those who are unable to install the client version. With any luck, they make the interfaces similar enough between the two versions that you can definitively tell participants how to type in questions or answer polls no matter how they joined. (Seems obvious, doesn't it? It's actually a common frustration.)
You'll still have frustrated and confused users. As far as they are concerned, if you offer two options, they should both work, and they should be free to select whichever they find most convenient. But it's all we can do for now. If your webinar platform offers only a single connection methodology, maybe this article will give you some clues on what to look out for and what you should be prepared to address when somebody reports problems.
Best of luck!
