Webinar Wire

Underpinnings Of Web Conferencing

Posted by Ken Molay October 27 2008 9:04 PM EST

1 comment

Joe at Omnovia sent me a short email saying "We've been getting feedback from conference users that the newer browsers (i.e. IE8, Safari, Firefox) are increasingly becoming less tolerant of allowing plug-ins."

Interesting. I hadn't heard that, but I did a quick internet search and found that Internet Explorer 8 (which is still only in beta) is changing some features in the way that it lets ActiveX controls install on a Vista operating system. You can install them for the current user, rather than needing administrative control and affecting all users on a computer. This should actually make it a little easier, rather than harder, to install many plug-ins.

Joe might have been thinking of the IE7 "enhancement" (harrumph) that forced an explicit confirmation before any ActiveX control is allowed to run, which can disturb some users. And there's the problem of users who don't have administrative authority on their PC not being able to run an ActiveX control.

But this got me thinking about the topic of how web conferencing software vendors choose to architect their solutions. No matter what they do there are tradeoffs, and some client or prospect will be unhappy.

Let's review some of the major approaches (in a highly oversimplified manner... I don't pretend to understand all the details, nor is this a programming forum).

A vendor can choose to follow one of these broad approaches:

1. Run in a browser using only pure HTML without any downloaded code other than the HTML page source.
2. Run in a browser, relying on ActiveX controls, Java applets, or other temporary code snippets that enable interaction.
3. Run in a browser, relying on Adobe's Flash Player or some other third party program to handle the interactions.
4. Use a downloaded and installed program on the user's PC to handle interactions.

Scenario #1 is completely universal. There are no barriers to any user seeing the information. Unfortunately, raw HTML is primitive as heck. You can display a static image and that's about it. So your slides get converted to a static image that doesn't scale as the user changes the window size. You lose animation effects. Implementing any kind of feedback (like chat) is cumbersome at best, since you have to rely on clunky input forms that are supported in the basic HTML specification. You end up with a product that always works, but fails to impress when compared with glitzier competitors.

Scenario #2 lets the vendor do real computer language programming. The "program installation" is hidden to the user (Or used to be... As Joe pointed out, hackers using hidden code have now forced the browser designers to make code installation explicit). And it doesn't leave programs installed on disk and in the registry. Drawbacks include the fact that some companies or security setups can block the installation of the necessary code, there is a pause before every meeting while the code downloads, and users are probably presented with confirmation messages that force them to make administrative decisions.

Scenario #3 can greatly reduce the pre-meeting load time for users, since the underlying program code (let's assume Flash Player as the most common example here) has probably already been downloaded and installed at some point in the past. The pieces needed to run the meeting are much smaller and most users won't see a confirmation message. It's also possible to implement some very fancy interactions by using the capabilities of the third-party program. Unfortunately, security settings can bite you in this situation as well. Some companies don't allow Flash on employee computers because it can be abused by hackers. Users without Flash pre-installed before the meeting need to download and install the software, which takes a while and requires confirmations. And if someone can't install Flash, they can't attend your meeting - period. There is no work-around.

Scenario #4 gives the vendor the most control over their software. Every attendee must download the entire program code and install it like any other application on their hard drive. Once installed, it can support just about any interactions or features desired by the vendor. And subsequent meetings can start very quickly, since there is no need to download the software again. But program downloads and installations can be massive (Microsoft Live Meeting requires a 15.8MB file download as one example). Cross-platform support is difficult, if not impossible. Company security may not allow users to install programs on their hard drives.

So each vendor is left with their own fundamental decision on which tradeoff they will accept. And once that decision is made, it is impossible to change without a complete rewrite of their entire code base from scratch. Pity the poor software manufacturer.