Blog

It’s been a while since my last blog post, but that’s not without good reason…I promise! Over the last few months, our engineering team has been working hard on the most significant performance improvement the Userplane SDK since its release. So, how did we get there? In a word: Flash. In a few words: it’s not there anymore.

Ever since we began overhauling Userplane by building the SDK, we’ve done so with an eye on the future and all the technological opportunities in front of us. Traditionally, Userplane and all of our competitors have used a Flash interface to render the chat experiences, making them heavy and not very flexible. With the removal of Flash from our 1.2.0 build, there are two areas where Userplane now runs circles around the competition: (1) file size, and (2) speed. First, let’s compare file size amongst competitors:

123FlashChat: 886 KB
AVChat: 330 KB
Flashcoms: 774 KB
Mango Chat: 529 KB
Userplane: ~120 KB

Every byte on your site impacts how your users perceive it. Google loads rocket-fast in pretty much any environment because its homepage is only 17 KB. So of course, a huge concern in adding a 3rd party feature to the site is how it will impact usability of the site as a whole. We already deferred the SDK loading until after the site had rendered with this in mind. But now, we’re also 2, 3, 4 or even more times lighter than most of our competition.

Page load of course impacts perception on your site. How long a feature takes to load once engaged also has a substantial impact on perception, so let’s take a look at how long experiences take to load amongst some of our competition:

123FlashChat: ~5 seconds
Flashcoms: ~6 seconds
Userplane: ~1 second

Now, consider that we’re testing in LA, with some of the fastest broadband speeds in the country (see this ‘Speed By State’ map), and you begin to understand why considerations like file size and launch time really do matter. Think of how often people are accessing the internet via their mobile browsers using 3G, 4G, Edge, etc. If your device is even capable of loading Flash, then see how long the load time becomes for our competition (hint: 5 seconds of loading time on broadband could mean up to 30 seconds on Edge)! And, according to this report, our competition neglects 28.7% of the US smartphone market by relying on Flash–the percentage represented by iOS users.

Like I said, the concept of the SDK was conceived–and continues to be built–with an eye focused on the future. Our removal of Flash, and the doors that opens up for iOS compatibility, is proof of that early foresight. As we continue to move forward, we have lots more in store, and a goal of reducing the files size of the SDK to below 100 KB. There will be more exciting milestones coming from us, so be sure to stay tuned. But today marks another exciting step, and we hope you think so, too!

If you’d like to view the complete release notes from our 1.2.0 build, please click here.

SDK Fixes

  • SDK-47 – After closing a Webmessenger window with active conversations, relaunching Webmessenger via a custom IM launcher does not focus the previously active conversation
  • SDK-134 – A requested user’s status displays as “undefined online” and then immediately changes to the requested user’s name
  • SDK-174 – Ensure that Webmessenger tabs are consistent with Webchat mocks
  • SDK-186 – Finish right-to-left (RTL) text support for Webmessenger
  • SDK-212 – sendPendingMessages – User can receive missed IMs at a later time
  • SDK-442 – Add right-to-left (RTL) text based on “lang” mapping, to add RTL CSS classes when using RTL based languages
  • SDK-488 – The Adobe Flash Player Settings pop-up is inaccessible in Firefox
  • SDK-587 – Can’t send offline messages
  • SDK-589 – Base presence information for roster onload is inaccurate
  • SDK-595 – Get History Called With Invalid UserID error is thrown when trying to use the Report Abuse form
  • SDK-596 – Add instructional language to the CSXML Tester page in the Dashboard
  • SDK-597 – Add password criteria to the Reset Password page in the Dashboard
  • SDK-598 – Change references from Company to Account for administrative area in the Dashboard
  • SDK-599 – The Send button does not send messages
  • SDK-601 – Badges do not render inline when no container ID is provided
  • SDK-603 – Loading and connections errors with Internet Explorer
  • SDK-604 – The confirmation dialog is visually hidden and the information appears to be empty. They also contain no buttons to act upon.
  • SDK-605 – Switching tabs in a Webmessenger window causes the entire message pane to minimize
  • SDK-609 – Clicking the Clear Text button clears the text in the UI but does not clear the chat history
  • SDK-610 – Closing the last, remaining Webmessenger tab fails to close the Webmessenger window
  • SDK-611 – The characters n, s, b, and p are being trimmed when they are the final character in a message
  • SDK-616 – Growl notifications no longer work for incoming IMs
  • SDK-622 – The message input grows a tiny bit with each character added in Internet Explorer 8
  • SDK-623 – Hide timestamps in the message pane, and only show a timestamp when hovering over a particular message
  • SDK-624 – Add a visible timestamp for last message sent/received to the bottom of the message pane
  • SDK-625 – Invalid skin names should default to a lower case skin name
  • SDK-626 – Invalid locale calls should default to English
  • SDK-627 – Add handling to badges to accommodate common case sensitivity issues with parameters (userid, diplayName)
  • SDK-631 – Style the AV buttons (start/stop)
  • SDK-636 – For new user sign-ups, update password validation to look for certain, special characters
  • SDK-653 – The resizing of the message header widget on AV launch is wrong
  • SDK-654 – Add an “av-open” class to the message pane header when AV is running
  • SDK-655 – Adjust CSS based on the message header component to be wide enough
  • SDK-656 – The message header does not shrink after the AV session is closed
  • SDK-657 – The content and appearance of the pop-up notifications for Copy Text need to be fixed
  • SDK-660 – Elements within Webmessenger fail to resize after an AV session has concluded
  • SDK-681 – A user’s avatar and profile information are not displaying
  • SDK-682 – The SDK is not loading in Internet Explorer 7
  • SDK-684 – When flash video is present in a background tab, it reveals by 1px at the left edge of the message pane
  • SDK-689 – The Webmessenger window loses and does not regain connection when refreshing the parent window in Internet Explorer 7
  • SDK-693 – Video for a remote user is not displaying
  • SDK-694 – The Stop Video button occasionally disappears during video chat sessions
  • SDK-700 – Adding or closing a tab with multiple tabs breaks the Webmessenger layout
  • SDK-704 – The Webmessenger window will not launch in Internet Explorer – Stack Overflow and Out of Memory errors
  • SDK-706 – The decorator is broken in Internet Explorer 7 and 8
  • SDK-724 – The Webmessenger interface collapses when the parent window is refreshed
  • SDK-725 – The reconnect dialog screen appears behind the Webmessenger interface

Dashboard Fixes

  • DASHBOARD-8 :: A new account login creation should see criteria for what constitutes a valid password
  • DASHBOARD-15 :: Additions and changes to the Dashboard homepage – Recent News, Developer Documentation, placing stats graph beneath Manage My Stats, text labels added to site management icons, link to CSXML tester, and overall styling tweaks
  • DASHBOARD-30 :: Auto-focus on first input field across account sign-up and dashboard pages
  • DASHBOARD-7 :: Add first and last name fields to first page of account sign-up
  • SDK-539 – Fix the Publisher Stats within the Dashbaord
  • SDK-596 :: Dashboard – Add instructional language to the CSXML tester page in the dashboard
  • SDK-597 :: Dashboard – Add password criteria to the Reset Password page in the dashboard
  • SDK-598 :: Dashboard – Change references from Company to Account in the dashboard
  • SDK-636 :: Update account password validation to not allow certain special chars
  • SDK-668 – Remove “Add Account Name” from Step 2 for new sign-ups
  • SDK-671 – The button for the billing step in new sign-ups should be labelled “continue” instead of “finish”

With the help of our publishers who jumped on the Webmessenger3 bandwagon early, we’re releasing a second hotfix for SDK 1.0.8. Here’s the rundown of what we’ve fixed with hf2:

  1. Resolved issue with action icons wrapping to a second line instead of remaining inline;
  2. Fixed the hover state of A/V icon so that it does not move right when user hovers;
  3. We’ve suppressed redundant on/offline notifications and messages;
  4. Blocked users will no longer receive messages from the user who blocked them.

This feedback came directly from our dedicated publishers. If you have ideas or believe you’ve found a bug, let us know by contacting us.

So you’re upgrading to Webmessenger3 (our new HELIX platform), and you need to know who is online in your database for a “members online” page (or a similar concept). With your Webmessenger2 integration, you’re using the existing feed API to accomplish this; and at the time of this writing, we are in process of testing a new presence feed API that works similarly.

In the interim, however, here is a very easy way to get around this until that functionality is officially released or available for beta:

The concept is simple–you allow both your HELIX legacy presence integrations to co-exist on your site. Your ability to call the existing presence feed API will not be compromised. There are some important notes and things to understand:

  • The site identifier between the legacy and HELIX platforms do not mingle. Even if the IDs are exactly the same they are completely separate by nature so that you can use both platforms simultaneous without hurting anything.
  • HELIX has its presence system built into the initial embed you place on your page whereas the legacy platform (WM2) uses a completely separate integration for presence.
  • Running HELIX’s presence with the legacy presence system is our goal and will not cause any issues for your integration.

So now that we are clear on those points lets begin with the step-by-step:

  1. If you already have presence embed on your site and functioning along with Webmessenger2 you will want to start by embedding Webmessenger3 using the HELIX embed code.
  2. By adding this embed code you have added the HELIX presence calls (which includes the ability to launch new IMs and receive notifications about incoming messages. Given this, all you need to do now is upgrade any existing calls to launch an IM on your site to use the Webmessenger3 ( see Custom IM Launcher or ideally the Badge Widget.
  3. Once you have removed all of the references to launching Webmessenger2 (all while maintaining the existing calls to f.js for legacy presence) you will be able to run the legacy presence system in the background of every page without impairing the new platform. Thus maintaining any integration you may have already done against the presence feed.

Not sure what the presence feed is? View the documentation here.

We’ve just released 1.0.8 to Production. In case you missed ‘em last time, here are the build notes.