Starting A Video Call On-Time
I do prefer video conferencing over audio-only meetings, and I find myself increasingly annoyed with audio-only forums. The audio-only call remains popular, but the excuses are getting weaker, like bad hair day.
However there is one frequent complaint that actually does carry some legitimacy: Meetings don’t start on-time.
I’ve been using video very heavily for the past few months – moving between several services including Hangouts, LifeSize Cloud, Lync, Vidyo, and Webex. I can confirm that the “delay of game” problem is indeed real. The problem is a matter of familiarity, and it goes away with recurring usage. Video is more complex, but that is not the reason why the meetings don’t start on time. The reason is simple: It is A/V settings. It sounds trivial, but I assure you it is not. The problem goes away for regular users because they learn how to adjust the A/V settings. The rest of us get so annoyed, that we fight becoming regular users.
Every video client requires the user to select or adjust their A/V settings. The defaults are frequently wrong. The reason meetings don’t start on time is because figuring out this trivial task requires a monumental effort. There’s also a myth that this only needs to be done once. Like phones, sometimes we prefer handset/headset and sometimes we prefer speaker. Similarly, I have a headset and speakers on my computer. I also have two cameras with different angles and purposes that require manual selection.
This is not a set it once and leave it thing. So why is the procedure to set these devices so non-obvious? Technically it isn’t, the hard part is figuring out 1) if there’s a problem, and then 2) figuring out where to make the change. For example, a non working microphone setup is typically not detected until the participant attempts to speak. The solution is simple, yet elusive. The A/V settings need to be in your face – ideally before the conference even begins. Unfortunately, the vendors disagree. Let’s take a look.
WebEx: Actually WebEx is one of the better ones. Before the meeting begins it pops up the audio settings and test feature. This helps a lot. Once the meeting begins, the audio controls are fairly accessible under a root menu called Audio (upper left). The story gets rougher with video – click the camera icon and a camera goes on. Wrong camera? Select the gear icon (upper right) This occurs in the meeting, not before it.
Lync: Controls are not even in the meeting widow, but back in main client window. Look for the gear icon (upper right) to access separate options for Audio and Video Device settings. There is a test capability on the menus. However, guest attendees cannot access these options until the meeting starts (late). It’s a shame because the waiting room would be an ideal place to do it.
Vidyo Desktop: The settings are accessible before and during the conference, and users have the option to enter a conference with their mic and video off. Once in the meeting, the gear icon (bottom right) is only visible if you mouse over the video (assuming the window is active). All A/V controls are on a single ‘Devices’ tab, no testing capability.
LifeSize Cloud: Select File (top left) > Preferences and then there are separate tabs for audio and video settings. There is no gear icon on the soft client.
Acano Client: There is a user settings icon on the top right, clicking this opens a self-view and also reveals a gear icon. Then, with the gear icon the user can access audio and video settings. All settings can be tested.
Browser-Based/WebRTC: These solutions have the additional challenge that the settings are in the browser, not the application. Although some applets can open the settings page. Many WebRTC applications offer no guidance on this (no gear icon) and instead figure the user will just know it’s part of the browser itself. Browsers are more important than many realize because they are most commonly used with guests – and guests are even less familiar with the app. Browser-based applications can easily add another 5 minutes on top of the 15 minute delay.
It is also worth noting that my Logitech webcam resets its settings with each reboot. Easily forgotten until the conference is supposed to begin. Adds more delay.
None of the above solutions are unreasonable or overly complex, but because they are all different it takes 15 minutes to get things sorted. Just finding where the settings are located can be tricky. Repeated use of the same client does solve the problem.
Here’s how to fix it:
There needs to be an intuitive way to both set and test controls before the meeting begins. Upon starting the app or entering a meeting lobby, the A/C controls should just pop-up. Advanced users can click the box that says “don’t show this on start-up.” Within the conference, there also needs to be visible, direct controls for A/V settings. Key here: visible at all times during a conference. The conference vendors have largely agreed on the gear icon, but they have not agreed to make it always visible or where to put it.
And on more thing… mute needs a bigger indicator. Almost as common as the 15 minute delay, there is the issue of someone talking and not realizing they are on mute. This is also common on audio calls, but with audio calls it is more understandable because we don’t stare at the phone. With video calls, there should be a very visible mute indicator.
It’s that simple. Make the A/V controls intuitive (or familiar), and the 15 minute delay will go away.
You’re so right, there’s a requirement for user intervention that imposes a knowledge burden. Trivial for some, but near insurmountable for others.
With respect to browser WebRTC-based apps Google there has been a sort of false start along the path to simplification. Initially the browser prompted the user for camera and microphone selection, but did not address speaker (audio playback) selection. That actually made matters worse since it resulted in a disjointed control of the settings; some in the browser others in the OS.
Google has said that device selection, including audio playback device, is going to be possible from the Javascript application layer. That will allow smart developers to better own the control of device settings, and so better control the user experience.
This is predominately a problem with desktop clients, Tablets have less of a problem because you don’t get as much of a choice in what AV peripherals to use. Vendors like Zoom, and Faceme have integrated AV testing into their offerings so you can test your mic and camera before you enter the conference.
While these are helpful they also enforce with users that the risk of something not working with video is greater which may limit takeup
This is very related to my concern with WebRTC for call center communications. The last thing you want after waiting on hold, is to fumble the A/V settings when the agent is finally ready. And from the perspective of the call center perspective, this is a nightmare… they measure time-per-call down to the second. Wasting minutes with the “can you hear me now?” tango will wreak havoc with the metrics.