Introduction to collaboration layers
Unblu’s collaboration layers allow conversation participants to view the content of a website, a mobile app or an application together. They make communication more effective and provide a richer experience for your visitors.
Unblu offers five different collaboration layers, each serving a different purpose and often using different technology:
-
Embedded co-browsing
-
Universal co-browsing
-
Document co-browsing
-
Screen sharing
-
Whiteboard
-
Mobile co-browsing
This article describes the collaboration layers. It presents each collaboration layer and explains the differences between the layers.
For information on how to work with collaboration layers, refer to the Floating Visitor UI guide and the Agent Desk guide.
The article Configuring and manipulating collaboration layers provides information on the various ways you can customize the configuration of each collaboration layer.
Embedded co-browsing
The embedded co-browsing collaboration layer allows collaboration on web pages instrumented with the Unblu JavaScript snippet. It does so using a technique called DOM capturing, which runs in the visitor’s browser. The visual state of the visitor’s browser is cloned and transferred to the agent. Additional resources like images or CSS files that the agent’s browser needs to replicate the visitor’s view of the page are retrieved separately, not from the visitor’s browser.
Unblu doesn’t persist any of the data transferred from a page during an embedded co-browsing session. It merely holds it in memory on the Unblu server during the collaboration session. The only data persisted in the Unblu database is metadata relating to the various types of session involved in an embedded co-browsing collaboration session during a conversation. Once the collaboration session ends, the data transmitted, including any data transferred to the resource history, is removed from the Unblu server.
As mentioned above, each page you want to enable embedded co-browsing on must contain the Unblu JavaScript snippet. Without it, the state of visitor’s view of a page can’t be forwarded to the agent. You can add the JavaScript snippet to the <head> section of the pages you want to instrument. Alternatively, you can have the snippet injected dynamically by the SecureFlow Manager or a tag management system.
Embedded co-browsing allows access to the full set of collaboration tools: mark mode, remote control, and scroll lock.
Since you have control over the pages that are instrumented for embedded co-browsing, you can also take advantage of other features, such as the ability to hide page elements from agents. For further information, refer to Configuring and manipulating collaboration layers.
Embedded co-browsing allows in-context sessions. This means that the visitor’s current browser information is kept intact. For example, suppose a visitor has logged in to your website and requests a co-browsing session. All the visitor’s context information, such as their login information and browsing history, carry over into the embedded co-browsing session. Agents thus have access not just to the web page the visitor was on but to the whole context of what they were doing, such as completed form fields.
Although a powerful tool, embedded co-browsing does have some technical limitations. For an in-depth discussion, refer to Limitations of embedded co-browsing.
Universal co-browsing
|
Universal co-browsing requires the Unblu Rendering Service. For information on how to configure the Rendering Service, refer to Configuring the Rendering Service. |
In a universal co-browsing session, participants in the conversation can view websites together that haven’t been instrumented for use with Unblu. For example, if a relationship manager recommends that a client invest in a particular company, they may wish to view that company’s website together.
Universal co-browsing makes this possible by using the Unblu Rendering Service. * Each universal co-browsing session launches a new Rendering Service in a Docker container. The Rendering Service is an application based on a Chromium browser running in headless mode. * All of the participants in the session interact with this browser instance, and the same graphical output is streamed to all of the participants. * The view of the browser is transmitted to all participants via the WebRTC API. Check our browser requirements page to see which browser versions support WebRTC. * Interaction with the browser—mouse clicks, marking, editing and the like—takes place via the Collaboration Server, which forwards the interaction to the Rendering Service via gRPC.
The participants in a universal co-browsing session can’t see anything that’s on another participant’s computer. This is a significant difference from embedded co-browsing and screen sharing sessions, where all participants view the contents of a particular participant’s browser. It also means that, unlike with embedded co-browsing, it isn’t possible to hide part of a page from some participants and show to others.
Like embedded co-browsing, universal co-browsing comes with collaboration tools that aren’t available in screen sharing sessions: mark mode, remote control, and scroll lock.
Document co-browsing
|
Document co-browsing requires the Unblu Rendering Service. Refer to Configuring the Rendering Service for information on how to configure the Rendering Service. |
Document co-browsing allows the participants of a conversation to view a single copy of a document together. With the appropriate settings enabled, participants can also highlight sections of the document or edit it.
To co-browse a document, a conversation participant must upload it to the conversation. Any participant with the required permissions can then initiate a co-browsing session of the document. As with universal co-browsing, the interaction between participants and the software displaying the document takes place over the WebRTC API.
When a document is edited in the course of a co-browsing session, the modified document must be uploaded to the conversation to save the changes. If the document isn’t uploaded to the conversation, the changes made to the document are lost. The Rendering Service doesn’t store a copy of the document.
You can also integrate third-party electronic signature solutions such as DocuSign. This allows you to complete the entire contract negotiation process online, from the advisory stage to the final signature.
Supported file types
Unblu allows you to co-browse PDF files, plain text (.txt) files, and images. PDFs that require special plugins aren’t supported.
It is possible to enable co-browsing of other file types, too. To do so, you will need access to software such as ONLYOFFICE or Microsoft Office Online Server that allows you to view and possibly edit these file types.
| If you don’t have an on-premise solution such as Microsoft Office Online Server, using document co-browsing with files of a type other than PDF requires third-party services and involves uploading the files to the servers of those third parties. |
Screen sharing
In a screen sharing collaboration session, the participants in a conversation all have access to the screen, or part of the screen, of one of the participants.
This is useful if, for example, a relationship manager wishes to share a view of a spreadsheet in Microsoft Excel to show a client some calculations they made without giving the client access to the Excel file itself. In the Agent Desk, that would look like this:
The client in the conversation would see this:
When initiating a screen sharing session, the participant sharing their screen is usually asked which content they wish to share.
| This isn’t a feature of Unblu but a security measure built into modern browsers. |
Most browsers offer the following choices:
-
The entire screen
-
An application window
-
A browser tab
This flexibility lets people share a view of their own computer without the need to share files or programs with the other participants in a conversation. If a customer is experiencing technical difficulties printing a contract, they could allow your support agents to view their printer settings.
However, screen sharing also has disadvantages compared to universal or embedded co-browsing:
-
There are no collaboration tools available in screen sharing sessions. Screen sharing isn’t a remote desktop solution.
-
It’s easier to share content inadvertently that you didn’t want other participants to see.
-
The view being shared is captured by the browser of the participant sharing their screen. As a result, screen sharing may exhibit inconsistent behavior across different browsers.
-
Screen sharing uses the Screen Capture API to access the video and audio stream of a participant’s screen. This API is only available in relatively modern browsers.
-
Screen sharing relies on the page that the screen sharing session was launched from to remain available. If the visitor navigates to a different page instrumented with Unblu, the screen sharing session stops and must be re-initiated.
| The specific browser versions that permit screen sharing are listed on the browser requirements page. |
Whiteboard
The whiteboard collaboration layer provides your agents and visitors with a blank canvas. On the canvas, conversation participants can draw diagrams as well as add text, shapes, and arrows. This is particularly useful if one of the participants has joined the conversation using a tablet.
The whiteboard canvas looks like this:
The main controls are positioned at the bottom of the canvas. Style controls are in the upper right-hand corner.
Users can export the canvas to the conversation as a PNG file. This gives participants access to the image from the archived conversation. You can also configure Unblu’s conversation recording feature to record how the whiteboard is used during the conversation.
Mobile co-browsing
Mobile co-browsing refers to the possibility for your agents to join users of your mobile apps as they use them. This requires you to integrate Unblu into your mobile apps using the Unblu mobile SDKs for iOS and Android.
Mobile co-browsing takes a screenshot whenever the content displayed in your app changes and transmits the screenshot to the other conversation participants. It does so by iterating over the view tree of each window that belongs to the application. The screenshots are taken with standard APIs provided by the operating system (Android or iOS, respectively) and require no special permissions.
This all takes place in memory. The screenshots aren’t stored anywhere temporarily before being transmitted to the Collaboration Server. They’re only kept in memory on the Collaboration Server, too.
The file size of each screenshot depends on the resolution of the screenshot taken, but is commonly 10—60 kB. The maximum screenshot resolution is configurable.
The following features are available in mobile co-browsing sessions:
-
Co-browsing all your app’s content
-
Interactions of the user with the device screen can be seen remotely
-
Orientation changes are displayed on the agent side
-
Lock the screen displayed in the Agent Desk if the visitor puts the app into the background
-
Areas of the app can be marked remotely
Collaboration tools
Unblu includes various tools to make working with collaboration layers more effective:
- Mark mode
-
Allows conversation participants to mark an area of the view being shared in the conversation.
- Remote control
-
Allows a conversation participant to take control of the pointer
- Scroll lock
-
Locks the section of the page displayed in place. Even if another participant scrolls the page, what’s displayed on the screen of whoever activated scroll lock remains the same.
The controls for these three tools are grouped together. In the Agent Desk, they’re in the collaboration layer’s action bar. For visitors, they’re located in the collaboration layer controls at the top of the collaboration space.
Enabling collaboration tools
Not all tools are available in all collaboration layers. If a tool is available in a particular collaboration layer, there will be a configuration property to enable it.
The configuration properties that enable collaboration tools are defined on conversations or conversation templates. This provides for fine-grained configuration possibilities. You might, for example, decide that relationship managers should be granted full control of the collaboration layer in conversations with their clients. In conversations between support agents and visitors, on the other hand, agents should only be allowed to mark sections of the layer.
As a rule, you can specify which categories of participant may enable a tool.
In addition to enabling collaboration tools, you can define whether using the tools requires the explicit approval of the visitor or agent (depending on the tool).
For more information on configuring collaboration tools (and other aspects of collaboration layers), refer to Configuring and manipulating collaboration layers.