WebRTC brings with it some unique challenges to web developers. It is time to suggest a solution to them.
[Time for another developer post by Chris Matthieu, founder of Twelephone, in what I hope will become a series of its own. This time, Chris elaborates more about the tight connection between WebRTC to Single Page Applications]
In our previous article, Node.js and WebRTC go Together Like Peanut Butter and Chocolate, we discussed just how effective Node.JS is for building single-page web applications. Single-page applications are all the rave now when it comes to building real-time web applications that feel like native apps. This is because most of the application logic is delivered to the client (web browser) and only small bits of JSON data move across the wire to the server making these applications very responsive for the user. HTML subviews are basically injected into divs or sections of the existing web page without refreshing or loading a new webpage on submits or clicked links.
In addition to the user experience and performance gains, there is another very important feature of a single-page application when it comes to running WebRTC video, voice, and chat. WebRTC allows you to establish a peer-to-peer video/voice chat session with another person or groups of people. Once this session is established it stays connected as long as the page stays loaded or until one of the people ends the session typically by pressing a hang-up button on the page. By design, single-page application pages do not refresh; therefore, your WebRTC session stays connected while you are able to continue working and clicking buttons and links on the website.
Twelephone, the social telephone, was completely rewritten several times. The first rewrite was to convert the application from a traditional web application to a single-page web application. The second rewrite was to leverage the Holla WebRTC library and improve chat support. Both rewrites were expensive but necessary for the communications platform to provide a better user experience with a clean, refactored codebase making it easier to implement new features in the future.
Here is a video demonstrating how Twelephone’s single-page application design allows a user to have a video chat with someone while having text chats with other users.
Over the course of Twelephone’s application rewrites, there were several lessons learned with respect to integrating WebRTC with a single-page application design. We would like to help others just now starting out on the WebRTC development journey as well as those thinking about converting their traditional WebRTC application to a single-page app. We hope these tips will save you from rework and improve your customers’ experiences on your site too.
- Incoming call notifications should not disrupt the existing application usage. Twelephone uses a Twitter Bootstrap modal window that overlays on top of the application. Favicon changes in the tab also help get the user’s attention when the page is not active in the browser. Twelephone uses Tinycon to add bubble alerts to the favicon indicating the number of missed chats or calls since the page was last active.
- Video placement is important. Your users will be staring at the video for a long time – much longer than interacting with your application. You may need to open a div and adjust content and navigation around the video when activated. Your site should look aesthetically pleasing with or without the video streaming.
- Support for HTML5 full-screen mode is also a simple but effective feature to add to your implementation. More information about HTML5 full-screen mode steps can be found at HTML5Rocks. Users sometimes like to focus on the video call without being distracted by other chats or real-time notifications.
- Adding a chat option is helpful for sharing links and media if appropriate for your application. You would be surprised how often someone talks about a website or link while on the phone. Allowing the users to pass data between each other (especially links and multimedia such as YouTube videos, images, HTML5 videos or audio files, etc.) while on the call add value to the user’s experience.
While I am in the domain of tips, here are a few more tips – these related to video calling user experience in general:
- You should only provide the call button if the likelihood of talking to someone is high. In other words if the calling party is not online, don’t display a call button. You should also have a backup plan such as the ability to leave a message should the call not get connected.
- An option for voice-only calls is important. Not everyone wants to be on video. Ideally, it would be nice to be able to upgrade a voice call to video or downgrade a call from video to voice as the user requests.
- You should use a dark background behind the video so that it’s easy on the user’s eyes. Most WebRTC implementations are using black backgrounds.
- Include picture-in-picture (PIP) or side-by-side video of your stream as it appears to the user. People like to see what they look like to the other party. When using PIP, you should consider flipping the video so that the caller’s video streams as a mirrored image. Users expect this behavior and notice if you do not transform the video. This feature can easily be accommodated using client-side javascript.
- Mute and unmute buttons while on the call are handy if appropriate for your application. These features are available on most phones and VoIP softphones. They are frequently used for putting someone on hold or even silencing sneezes. Simple features add to the overall favorable user experience.
- Conference calls are hard. Start with 1:1 WebRTC calls and work your way up to conferencing. You may also want to consider a third-party WebRTC solution such as TokBox or AddLive to help with conferencing. By default, WebRTC is implemented using peerconnections meaning that each person in the conference call is sending and receiving streams to/from all parties in the conference call. From past experience, more than four users in a conference call causes computer fans to start spinning and sometimes causes the browser to crash. You should ultimately reduce the pixel density of all video streams in the conference call and in the future consider using active speaker to increase the pixel density for the user speaking.
There are several popular single-page web application frameworks available including: BackBoneJS, AngularJS, KnockoutJS and EmberJS to name a few. You can find a great comparison tool of all single-page application frameworks at TodoMVC. Twelephone uses BackBoneJS along with Rivits for data bindings and Vein for moving JSON data between the client and server via websockets and remote procedure calls (RPC). Rivets and Vein are much faster data moving solutions over traditional AJAX requests because websockets do not require re-establishing connections or sending HTTP headers with requests plus websockets allow the servers to push data to the client without a request.
To learn more about single-page web application design, checkout this free ebook!
Can you please share your code
Hi,
Is the single page web application the only solution for integrating webRTC into web app? No other possibility to save webRTC session across multiple pages?
And no way for session (RTCPeerConnection etc) to stay alive when single app page reload? What confuses me,is a:
https://docs.oracle.com/cd/E40972_01/doc.70/e40978/wd_javascriptapis.htm
where I read something about recreating session when page reloads…
Thanks in advance…
Cvele,
If you end up going between pages, you will need to store the context in your backend, and then restore the connection (=recreating it).
What you’ve read in Oracle’s documentation is just that part – maintaining context and synchronizing if one side of the communications goes down.
Thank for response.
So, if I understand correctly, it is still possible to maintain peer connection between pages, or surviving single page refresh by recreating connection, as provided in Oracle doc?
Correct me if I am wrong, still pretty new to the webRTC 🙂
No. It is impossible.
What Oracle does is acting as man-in-the-middle for the session. Both sides connect to their server, so if one of the users refreshes – it doesn’t affect the other user.
Ok, so conclusion is – use just single page, and never refresh, is not?