One of the most challenging aspects of revamping Userplane’s technology and building the SDK was the move from flash to javascript. While the change has been worth it, there have definitely been some unforeseen pitfalls that I am very proud we have worked through. Our products deliver with an attention to detail that provides a better user experience then any other solution out there. In this post I will highlight some of the more challenging details we never expected to run into and overcame.

The modern web

As browsers have evolved so to have user’s expectations of how a web page should behave and respond. Users expect the web to work like a desktop (installed) application responding instantly to their input. While there have been huge gains over the last 5 years with the introduction of the html5 spec being established and formalized, it’s just not possible to create that desktop user experience for everything. We certainly made this our goal where possible and we did capitalize on some very progressive experiences. We have spent seemingly endless time iterating over our caching strategy with both local shared objects and localStorage on the client to ensure that the users’ experience while interacting with one another is as instant as possible.

Real-time push connections in a stateless environment

With very few exceptions most all of our publisher’s sites involve a page navigation to move between content on their site. This means that from the time a user clicks a link to the time everything finishes loading the user is effectively not connected for a period of time. Given that fact we were immediately challenged with the need to not make it look like your users were going offline and online every few minutes every time they navigate to another page. That use case was immediately followed by the need to buffer messages in an offline delivery queue so if a message is sent while the other users is navigating that it is delivered immediately upon re-connecting. These challenges are the more obvious to the user but there were a series of performance and scalability items that tied to these behaviors and the nature of a web user’s experience with a real time connection that is constantly being destroyed and re-created as page navigation occurs.

Expected usage is far different in reality

When tabs were added to browsers it meant there was a great new way for end users to multi-task on the web efficiently. This went largely unnoticed for most web developers when it was first added to browsers year ago. That said when you start opening real-time connections on the browser to a server you run the risk of a single user opening multiple connections to your server. But really how often is that going to happen right? We were amazed when we started looking at the data and saw that some people have many as 20 tabs open with active connections to our servers. Yup, that’s one user with 20 connections, one in each tab. This proves costly not only in terms of performance on our servers but also to your bottom line cost. Since chat services like Userplane operate on per-seat licensing (how many people are connected at once) that one user has all the sudden turned into 20 connections potentially affecting your bottom line or chat availability if your using a service that caps connections like many of our competitors do. How to solve? A large effort to the tune of synchronizing user data and application data between tabs combined with a clever trick where we can pause the UI state and connection in tabs that are not currently focused. This means a user can switch between tabs with a fluid seamless experience without thinking twice about their conversation being left behind.

The devil is in the details

We often hear complaints about the nature of our cost structure or the inability to take our software and install it themselves for a flat rate. This is the nature of a software as a service but truly believe the value driven in having a team dedicated to these types of details is a huge plus for any company interested in real-time communication as it’s a totally different process both technically and experience wise.