If you are moving from the Legacy Chat widget to the integrated Chat in the Web Widget experience, you can expect to see some changes in your end users’ experiences, as well as your own widget configuration process.
The following features may have new options, or function differently, in the new Web Widget. Click the links to jump to a table or text describing the changes for each feature:
Minimized chat button launcher
The minimized chat button launcher appears on both desktop installations and mobile devices. The move to the integrated Chat experience may change the launcher’s appearance, placement, and label text.
If you want to make changes to the minimized chat button launcher beyond the general configuration options listed in the table below, you can build a custom launcher and use the Web Widget javascript APIs to control it as described in this tutorial.
| Feature | Old Chat widget | New integrated widget (default) | Configuration options |
|---|---|---|---|
| Appearance (desktop) |  |
 |
Use the launcher API to customize the launcher label or build a custom launcher. |
| Appearance (mobile) |  |
 |
Use the labelVisible API to make the label visible on both desktop and mobile launchers. |
| Launcher placement | Fixed to the bottom of the browser window. | Floating. | Use the position
setting and offset
setting APIs to move the widget to the optimal placement. |
| Label text | Customized text entry. | Select text from predefined strings in Support UI. | Use the chatLabel APIs to customize label text. |
Chat badge launcher
The chat badge launcher design is still available with integrated Chat if Chat is the only channel enabled in the Web Widget. See Starting chats from the chat badge.
Chat appearance customizations
Several customization options previously available in the Appearance tab of the Chat dashboard will not be available with integrated Chat. These have been intentionally deprecated to remove outdated design elements and simplify the configuration options for customers.
| Feature | Old Chat widget | New integrated widget (default) | Configuration options |
|---|---|---|---|
| Theme | Simple or Classic options | Simple theme only | See Advanced customization of the Web Widget for options. |
| Window size | Customizable | Standard size only | See Advanced customization of the Web Widget for options. |
| Mobile widget | Popout or overlay | Overlay only | See Advanced customization of the Web Widget for options. |
| Message style | Speech bubble or simple lines | Simple lines only | See Advanced customization of the Web Widget for options. |
Draggable chat window
Users could drag the standalone Chat window around the web page. However, the Web Widget is not draggable. Instead, the popout feature is available.
| Feature | Old Chat widget | New integrated widget (default) |
|---|---|---|
| Chat window mobility | Draggable by end user | Popout option opens widget in a new browser window |
Chat APIs
The majority of the $zopim.livechat APIs have been ported over to the Web Widget so you can continue to customize the Chat experience and route chats as before.
If you are already using the $zopim.livechat APIs, We have aliased the legacy $zopim.livechat syntax, so it will continue to work without the need to update any code.
Zendesk will eventually deprecate the old syntax, however this is not expected for at least 12 months. When we do, we will follow standard EOL procedure and provide customers with ample warning and communicate steps to mitigate impacts.
Legacy Chat APIs that will not be supported in the Web Widget are listed here, including notes on reasoning why we have chosen not to support them going forward.
This table describes the Chat APIs that are immediately unavailable, the reason(s) why they are no longer supported, and your replacement alternatives.
| Feature | Reason(s) | Configuration options |
|---|---|---|
setNotes and appendNotes
|
Posed a security risk for customers. |
|
Cookie law APIs
The legacy standalone Chat widget provided two APIs relating to cookies, setDefaultImplicitConsent and comply.
We have mapped the integrated Chat cookies setting API to $zopim.livechat.cookieLaw.setDefaultImplicitConsent(). This means that if you were previously using setDefaultImplicitConsent to disable cookies, this will continue to work without the need to modify your code. To enable the use of cookies again ( i.e. the use of Chat), you will need to add code to call the updateSettings API to allow cookies when the user accepts their use. You can find a code sample illustrating how this could work in the developer documentation here.
If you were using $zopim.livechat.cookieLaw.comply(), this will not be mapped, and will not disable cookies with integrated Chat.
Setting languages
Language detection and setting for end users changes when moving from the Chat widget to the Web Widget.
| Feature | Old Chat widget | New integrated widget (default) | Configuration options |
|---|---|---|---|
| Language setting | Auto-detect based on page content and lang parameter in the page header, or manually set a specific language. | Language is automatically set by the user’s browser settings. | Use the setLocale API to override the visitor’s browser settings. |
7 Comments
In how far are
setNotesandappendNotes posing security risks? Especially since setName, setEmail,... are all text fields too and still supported
This is super useful to get additional info about the page the user is on
Also getName, getPhone and getEmail shouldn't be removed - their setters (setName) are still supported, so it makes sense to also have a getter.
e.g. if ( getName() === '' && login cookie exists ) { setName( some value from cookie ) }
So logged in users immediately have a better user experience, but we won't overwrite their name if they have manually input it already.
Hi Maria,
The risk is more around social engineering and that notes can be used to influence workflow, for example causing an agent to process something that shouldn't be processed. Most agents have controls in place to validate the customers name/email information. This article details the available workarounds for Notes.
In regards to getName/Phone/Email we plan to support those. No ETA just yet but i'll update here when I can.
But how would I get the chat_id? It's not exposed anywhere in the zendesk chat widget, so how would I be able to target the currently running chat using the API? Obviously, the chat_id is a requirement for all calls to update a specific chat.
Hey Daniel, still waiting for a reply on how to get the chat_id?
At the moment there is no alternative for setNotes/appendNotes, as the suggested method of:
>Set notes for the user at the backend using the
REST APIsIsn't working, since there is no way to get the current chat_id
Hi Maria,
There isn't currently a way to get the chat_id as it's not surfaced to the Web Widget. Visitor notes are tied to the user rather than the chat session, so what you'd actually want to look for is the visitor_id.
For more information, see this documentation on the Apps Framework API: https://developer.zendesk.com/apps/docs/chat-api/chat_sidebar#visitor-object
Can I also hide the label for lancher in desktop mode?
Hey Hengly Ever,
I was able to check and confirm, that there is no option to remove/hide the chat label at the moment, it can only be replaced with a different one. But another option that you can try is to use a custom image as your chat widget button:
I hope this helps! :)
Please sign in to leave a comment.