What’s the most important thing that you can do to make your live video application successful? Anything you can do to improve call quality! This will certainly make your users more satisfied with your app and therefore make you more successful.

However, optimization can only get us so far. This is because we can’t always control call quality, no matter how much tweaking we do on our media servers. And the biggest factor in call quality is the internet connection our users have. If they are using a poor internet connection, then they will most likely have a poor call quality experience. 

There are other reasons, too, that someone may have a poor call quality experience. Maybe they are behind a firewall and unable to reach your media servers. Or perhaps their camera or microphone is not working properly. When these things happen, users tend to first blame your application, even though it’s not your fault!

This is why building in a pre-call test is the most important thing you can do to make your live video application successful.

In a recent WebRTC Tip video, I discussed the importance of pre-call tests, and I’m going to show you an example pre-call test from our telehealth starter kit SimplyDoc in this blog post.

In the video, I show some code examples towards the end of how different platforms offer you pre-call test functionality. For this blog post, I will focus on the UX of a pre-call test and show you the elements to build into your application.

An example pre-call test

The screenshot below shows you a pre-call test in our SimplyDoc tool, broken into two images. I’ve highlighted key areas that I’ll discuss below each image.

The first part of our pre-call test screen is what you see most often in a video conferencing tool before joining the call – a preview of your own video. This is important to fix your hair and check your teeth for lunch leftovers, but mainly to see that your camera is working.

In this example from SimplyDoc, we are “on hold” waiting for a doctor. Having messaging at the top indicating this to the patient is important as well. Since the patient has initiated this call, we also give them a cancel or exit button if they no longer want to talk to the doctor. Your use case will vary, but consider what messaging you need to give your users before they join the call, and how they can cancel their attempt to join the call.

Now let’s scroll down on the pre-call test screen and see some very important information that’s happening (while our user checks their hair) in the video:

Most importantly, the user can see which camera and microphone their browser has selected for them to use by default. If they have multiple cameras or microphones, we have given them a way to change those before the call starts.

The video preview will make it obvious if the camera is working or not, but how do you know if your microphone is working? Some sort of visual indicator that moves when the user talks is the way to go. In our case, the light blue bar next to the microphone icon will bounce as the user talks, assuring them that their microphone is working. No more “can you hear me?” as the call starts!

Beneath that, you see a green bar labeled “Connection”. The pre-call test page is doing a connectivity check, which was complete when I took this screenshot. The connectivity check has shown us several important bits of information.

First, the Network Check passed. Since SimplyDoc is built on Vonage, this check confirmed that we can connect to Vonage’s media servers (ie, we’re not behind a restricted firewall that prevented us from reaching them.)

Second, we’ve made an assessment if the video and audio quality will be sufficient for a quality call. In this case, my video will be fair, which is good enough to get started. We could also show the user the actual speed of their internet connection here. However, for many users that won’t mean much. They don’t know if, for example, 1MB is enough for a good quality video call. (Generally speaking, I would say 1MB is not good enough for a reliable call!)

Finally, we offer a backup plan. What if your connection is not strong enough? Many business conferencing tools offer a dial-in for audio option, and we do something similar here based on Vonage’s Voice API. We have a link that says “Switch to Phone Call,” which allows the user to type in their phone number and our system will dial out to them as soon as the doctor joins the call so they talk old-school if it is preferable or necessary.

What happens after the call starts?

So, your users got into the video call and all is going well? Excellent! But the work is not done. It’s a good idea to store some of the metrics you collected during the call in your database. If there is a customer service issue that comes up, your team can go back to the data and see what speed of connection the users had before the call, what browsers they were using, etc.

You could also use other tools to track the connection speed throughout your call and record additional metrics. In the WebRTC Tips video on pre-call tests, I briefly show a code sample of how you can do that with Vonage or with Twilio Video.

Are you interested in making your live video application more successful? Do your users complain about poor call quality? The first step is to build in a pre-call test – and we can help! Contact us today to build your live video application.