Unintended consequences is how I’d call it.
If you are a purist when it comes to WebRTC then move on – this post isn’t for you.
WebRTC was meant to enrich the browser. Make it more capable. Comparable to the desktop. We’ve already seen how it suits mobile apps like a globe (I have a report specifically about WebRTC in mobile). But what about some other types of devices and uses?
I want to share with you two vendors that came into my radar during April. If they are really using WebRTC or not is debatable to some degree, but they certainly fit within the WebRTC ecosystem. The vendors? Mailbird and KioWare (expect interviews with both soon).
Mailbird
If you are looking for an email client on your Windows machine and you’d rather not use Microsoft Outlook, then Mailbird is an interesting enough choice. Just like any other PC app, you download and install it. I can’t really say why in this day and age someone would want a PC client for email, but I am probably a minority in my thinking here.
So we have an email client. What does it have to do with WebRTC? Nothing.
Until you understand that the rendering engine that it uses is Chromium, through a project called CEF – Chromium Embedded Framework. Why use Chromium? For starters, it enables you to go to the browser at a future date. But my guess is that in the case of Mailbird it had more to do with rendering HTML emails on the screen, and the fact that there was a need for integrating third party services. And most useful services today are web based. For that, you need a browser, and what better browser do you have today to embed than Chrome?
You have a Chrome browser engine in your application. You focus on integrating with third parties. Then why not integrate with a WebRTC based third party? That’s exactly what Mailbird did, partnering with Veeting Rooms.
A PC application of an email client with an embedded WebRTC video conferencing service inside it. Who would have thought?
KioWare
Kiosks in businesses have been with us for many years. They use embedded operating systems in the most part, and now some are making the switch towards Android. The issue with the open operating systems such as Android are their openness – they don’t fit well into kiosks. So you have companies like KioWare who work on offering a locked-down version of Android for kiosks. In the case of KioWare, the target is at locking down a web based service, which means what you get is a user interacting with a browser on an Android device – without the ability to go anywhere else.
To do that, you can’t just use Chrome – that’s too open. You need to use a Webview, which is essentially a browser renderer inside a window inside an app. KioWare have the single app on the device that the user gets to see and interact with directly, and that app is a window towards a boiled down version of the web that the Kiosk owner wants the user to see.
Back to the question – where does WebRTC fits into all this?
Being Android, running the latest version, means that the Webview provided comes complete with WebRTC support. So without any “real” additional work, you can actually offer WebRTC capabilities in the Kiosk. Users can interact with self service type of flows and when needed, they can contact with humans via voice or video – and do all that by using WebRTC.
The great thing about it – without ever saying that a “protocol” has been selected and a full fledged client was developed for the device, anyone who relies on WebRTC can integrate with such a Kiosk offering. Interoperability has never been easier to solve.
Why is this important?
- WebRTC comes in different shapes and sizes
- The fact that Google tucked it in so nicely into Chrome and Android enable many non-obvious uses of WebRTC where Chrome or Android are adopted by a third party
- WebRTC isn’t confined to a desktop browser, and now has a life of its own in practically any conceivable device