A good WebRTC application is like a great orchestra performance

Learn about the qualities that define an exceptional WebRTC application and why user experience matters.

[In this list of short articles, I’ll be going over some WebRTC related quotes and try to explain them]

There’s something to be said about great WebRTC applications. Something about them is simply better than the rest when you bump into them. We’ve all seen them. For each of us it might even be a different application.

What do they all have in common?

• Their user experience works for you (instead of you working for it)
• You don’t need to think about calls not connecting (they might not connect, but somehow, you’re going to understand why – and it will happen less often)
• Media quality will be good enough (you won’t find yourself comparing it to other experiences you’ve had)

Getting there requires a certain commitment. A need to look at the various parts of the application, the whole design, the implementation. And then to lovingly optimize it over and over again. Iterating in each stage to polish another piece of it.

Somehow, I wanted to compare a good WebRTC application to a great orchestra performance in this quote, but I find myself drawn to another conclusion immediately – the one that says that WebRTC is a marathon and not a sprint.

For Engineers

Getting WebRTC properly tuned like a great orchestra requires finesse and a lot of understanding of how WebRTC works.

There are a lot of moving parts in WebRTC – clients, browsers, media servers, TURN servers, …

And they all need to work together properly:

Cover all your bases

Just recently I sent out my tip & offer email to my subscribers, where I mentioned that a media server cannot work in vacuum and needs a client side SDK.

Fast forward a few weeks, and Cloudflare acquires Dyte because its SFU was missing … a client SDK. I’ve written about Cloudflare as part of my previous article – go check it out.

The same is true for the other bits and pieces of WebRTC:

• Yes. TURN servers are rather independent and the first thing I’d suggest to my clients is to “outsource” these to third party managed services if possible. But you still need to focus here on where your users are, their types, the need for custom installations at times, etc.
• Media servers need to have client SDKs. I mentioned that already above
• You need to figure out the source of truth in the whole deployment – and if you even have one – or do you have media servers and application servers communicate independently directly with the clients that pass JWT tokens with their permissions
• Scaling has multiple dimensions here: scaling a group call, scaling on the client’s UI, scaling specific server types, scaling a global session across servers, …
• How do clients and media servers “negotiate” the dynamic capabilities and limitations of the client’s device?
• Where does the UI and UX on the device play a role to “hide” certain limitations of the system – such as the latency, mute signals, low CPU, poor networks, …

The list here is endless…

An ongoing effort

An orchestra? It has a conductor. His role is to decide in real time what takes place. And for that he looks and listens to the musicians.

With a WebRTC application, we need observability – a way to understand what users feel in real time as it relates to the media being sent and received. And then we need to adapt.

This adaptation is done dynamically. But also as an optimization effort that takes place over time.

For Product Managers

Here are a few immediate insights to draw from this:

1. It isn’t that simple and obvious what makes up a good application
2. Good applications require attention to detail
3. Since WebRTC is built out of many moving parts, you need to orchestrate and tune how they work together to reach the type of an experience you want
4. This is going to take time. Longer than what your developers or your outsourcing vendor is promising you. And not because they don’t know – but because getting from a WebRTC application to a good WebRTC application isn’t obvious (or even factored in the requirements)

So. Where does that lead you?

• Look at WebRTC projects as an ongoing investments
• Plan for generous “technical debt” time
  • 20% of engineering effort around the communications piece should be fine
  • Split this between actual technical debt and small tweaks and improvements that are targeted at tuning your WebRTC orchestra
  • Have a Product Manager guide and prioritize these tuning initiatives
• Compare your application to the market leaders every 6 months or so
  • WebRTC moves fast, and so are the leading vendors
  • Knowing what they do and “feeling” their apps will give you insights

For Customer Success and Support

An orchestra has lots of different musical instruments. Each giving his own unique sound to the final composition.

With WebRTC applications, we must not forget Customer Success and Support functions.

While we may have the best implementation of WebRTC. The best infrastructure is in place. At the end of the day, what is going to matter is the here and now. The session the user is on, and the experience he is having.

And as I always say, things are out of our control, and some of the reasons for that are the user’s own device and the network.

In such cases, we will need to front user complaints and requests, and be able to handle them properly. This is part of the overall experience. Part of the “orchestra performance” that we’re putting out there in our WebRTC application.

Take care of all your WebRTC instruments – even the non-technical ones.

Need help?

👉 Be sure to follow this blog, as it is the most up to date resource out there about WebRTC

👉 Subscribe to WebRTC Weekly to get a picture of what others are publishing about WebRTC out there

👉 The WebRTC Insights service takes care of a lot of what goes on in the market for you, as well as the progress made by browsers with WebRTC support

👉 I can assist with comparisons to market leading apps, as well as in prioritizing efforts