6 Key UX elements to consider when getting started with WebRTC

The AT&T Developer Program has teamed with &yet on a series of guest blogs that cover Best UX Practices for WebRTC.This series of guest blogs written is by Lynn Fisher who is the head of UX at &yet.At the end the guest blog series, we will make an eBook available for download that is compiled from Lynn’s blogs.

Ever since the web was invented in 1989, more and more capabilities have been added to the web platform: CSS, JavaScript, animated images, dynamic content, Flash, and much more. However, it’s always been difficult to build immersive audio, video, screen sharing, and other real-time communication experiences directly into web applications. That is now changing with an emerging standard called WebRTC.

WebRTC reduces the number of obstacles standing in a user’s way and separates itself from many proprietary platforms because it doesn’t require users to download and install the same software to get started. Without the need for internal or external plugins, it requires less to establish a connection between people. While older voice and video technologies like Flash required a server to send realtime media, WebRTC favors a peer-to-peer model. At a minimum, Traditionally, the user would need a supported browser, a network connection, a device microphone (for voice calls), and a device camera (for video calls). No additional software or equipment needed (though in practice, some backend infrastructure is needed for call setup and NAT traversal). Unlike proprietary platforms and apps, which allow users to communicate only within their communities, the general philosophy behind WebRTC is that real-time communication and the web should be as open, decentralized, and accessible as possible.

So how does it work? There are three major pieces of WebRTC: getUserMedia, RTCPeerConnection, and RTCDataChannel. The first, getUserMedia, does as it sounds and allows the browser to capture media through your device’s microphone and camera. RTCPeerConnection creates the connection between browsers, or peers, so a video or voice call can take place. The final, somewhat more experimental piece is RTCDataChannel, which enables the transfer of data such as files between peers, but it is not as central as getUserMedia and RTCPeerConnection. These three APIs form the foundation of WebRTC applications, upon which intuitive and useful experiences can be built.

Using WebRTC to Enhance Your Application

Not all applications using WebRTC provide dedicated video conferencing or voice calls. While WebRTC seems perfect for apps like Google Hangouts or &yet’s Talky service, it can improve all sorts of web apps and experiences.

One popular application is web software focused on teaching and training. In addition to tutorials and pre-recorded materials, more and more educational apps are offering students the opportunity to hop on a voice or video call with instructors. This real-time communication enhances users’ experiences with the software by eliminating obstacles and providing help within context.

In fact, context is the name of the UX game. Because WebRTC is implemented in the browser, knowing the user’s context (what part of a site they happen to be on) and keeping them in context (still interacting with their web browser) can make the subsequent interactions feel as smooth and seamless as possible.

Ecommerce is another opportunity for WebRTC to enhance the user’s experience. Online retailers can use voice and video calling and click-to-call features to assist customers on their websites. Within the context of their shopping session, they can speak to a customer service rep with questions or to troubleshoot a problem. Removing obstacles for the user can increase conversions. Clicking a button on the page you’re already visiting takes less effort than finding a phone number and making a call from a different device. There’s also significant value for the merchant because the customer’s context (shopping history, items in their cart, premium status, etc.) can be automatically communicated to a customer service representative. A high-touch interaction such as voice or video then can be offered only to high-value customers.

With WebRTC, online collaboration is easier and more powerful than ever. It’s not just remote software companies video conferencing from across the country, though workplace productivity is a common and important use case. Online real-time communication can power a variety of industries, many of which were very recently bound by the limits of physical location. Remote health care allows physicians and researchers to collaborate across the globe and for patients to meet with their doctors from anywhere. Worldwide gaming can grow and thrive on the back of real-time collaboration. Private communities can create secure voice and video calling or peer-to-peer file sharing on their internal network. There’s incredible potential in what WebRTC can do for collaboration on the web.

Planning Your User Experience with WebRTC

We’ll talk more in-depth about the mechanics and UX of WebRTC features specifically in the next few chapters, but first let’s consider your context. You may be starting from scratch or adding WebRTC to an existing, active project. Either way, your user experience can benefit from looking at your application holistically. Of course, the solutions will vary depending on your unique needs and goals. Here are six essential questions to ask as you design your WebRTC experience.

How does it fit into the user workflow?

At what point, within your app, would you want or expect a user to start a voice or video call? For an anonymous video conferencing app, it could be immediately: the first thing they do when they arrive at your homepage. For a tutoring app, the user would likely first sign up for an account, begin a lesson or submit payment, and then be given the option to start a connected session with a tutor.

Are there existing obstacles?

Can your users begin a voice or video call session at any time or only during specific, scheduled hours? Are there limitations around specific views or only during certain tasks? Can all users start a call or only ones with the correct permissions? There are many conditions that could affect a user’s ability to use these WebRTC-enabled features. Which conditions affect which users? This will vary wildly from app to app, but the most important part is to ensure these conditions are clear to the user.

How is the experience shared?

Once a connected session has been created, how are users notified of the session or invited to participate? If your app has a notification system already, it could make sense to use this familiar pattern. However, even if the notifications are familiar, the feature may not be. Should these new types of notifications be distinct visually or in some other way? What if the user has disabled notifications?

If your app doesn’t already support notifications (maybe it’s anonymous, for example), users will invite others outside the context you control. You can, however, make that interaction as smooth as possible by providing clear instructions, one-click URL copying, and medium-specific sharing buttons (e.g. click to share via email, Twitter, Facebook, a team chat app, etc).

Where are users sent?

Consider where the user ends up at each step in the process. A new browser window will be required for a call, but users will likely want to refer back to the content on the page where they left off. How can you design your interface to make that back and forth easier? If the user resizes each of the browser windows, are they still usable? Is all of the information and context still accessible?

Also, think about where the user goes after a call ends. A common pattern is to return the user to the page/view from which they left off. Another is to send them to the location where they’ll perform another task (e.g. giving user feedback). This part of the workflow can easily be forgotten, but it’s the perfect time to make an impression and encourage users to continue using the feature or your app.

And it’s important to think about where the user is sent if a call ends unexpectedly. This point leads into the next question to ask yourself.

What if something goes wrong?

As well-designed as our interfaces and experiences are, we must plan for things to happen that we don’t expect. If a call ends unexpectedly or unintentionally, what does the user see and where do they end up? Is it clear how they can get back on the same call or that a new call will need to be initiated?

Another example to consider is the browser-default prompt that asks the user’s permission to access their microphone or camera. It’s something we can’t edit or disable, so what happens if they click “Block” instead of “Allow”? How can we prepare the user for this question? Changing a browser setting will be outside the context of your application, but how can you help make that process as painless as possible?

Is the experience consistent?

Although a voice or video call might feel like a specific, separate view, it should still look and feel consistent with the rest of your application. Button styles, navigational patterns, fonts, colors, icons, sound effects, and animations should feel familiar and fit within the larger experience.

Your brand or web style guide will likely cover most of the components a WebRTC feature would introduce (e.g. buttons, forms, icons, etc.) and will help keep things consistent with the rest of your experience. If you don’t already have a style guide, creating and maintaining one is highly recommended. You can read more about style guides at http://styleguides.io, a great resource that covers how and why to implement one.

In this blog post, we’ve looked at some of the basic considerations for adding voice and video to an existing application or building an entirely new app with WebRTC. Keeping these considerations in mind will help you stay on track. In the next few chapters, we’ll delve into the details of how to make the voice and video experience as effective and effortless as possible for the users of your application.