There is a settings screen in the dashboard that looks like a list of cosmetic preferences and is not. It decides whether your chat opens inside the page or in a separate browser window, which of two chat interfaces renders it, and what happens on a phone. Each of those is a different decision, and the screen presents them as five similar-looking switches with similar-looking labels.
This guide explains what each switch actually changes, what the values default to when you have never touched the screen, and why the most common mistake is assuming the settings are consistent with each other.
Three decisions on one screen
Underneath the switches there are three distinct questions being answered.
Where does the chat open? Either the widget expands in place on your page, or a separate popup window opens. This is the decision visitors notice most, because it determines whether they lose sight of your page.
Which interface renders the chat? There are two chat interfaces in the product, and this screen chooses between them for the window that opens. This is presented as a theme choice, which undersells it considerably.
What happens on a phone? A separate switch overrides the in-page behaviour on mobile, and a separate dropdown can give phones a different layout template from desktop.
Keeping those three separate in your head is most of the work. The labels do not.
Two entry points, two separate switches
Visitors can start a chat from more than one place: the floating chat widget, and a chat button or text link you have placed in your own page markup. Those are two entry points, and the screen gives each its own popup switch.
That is a reasonable design, and it is also the single most common source of inconsistency on this screen. Turning on the popup for the widget and leaving the button switch alone gives you a site where the corner widget opens a separate window and the link in your footer expands in the page. Both behaviours are supported; having both at once on the same site is almost never deliberate.
The values are stored as plain text, and only the exact value for on counts as on. In practice this means a switch that has never been saved is off rather than defaulted to something clever, so if you have never opened this screen, both entry points expand in the page rather than opening a window.
If you use a text link or a no-script link as a chat entry point, the guide on chat links in your text and footer covers where those get placed; this screen decides what happens when one is clicked.
The theme switch changes more than the theme
Two of the five switches are labelled as window theme, and both choose between a modern interface and a classic one. It is worth being precise about what that choice does, because the word theme suggests colours and spacing.
It is not a skin. When the classic interface is selected for a path, the server sends the visitor to a different chat application entirely — a separate, older codebase with its own layout, its own feature set, and its own behaviour. Features that exist only in the modern interface are simply not present there. This is the same distinction covered in which widget version you are running, applied to one specific window rather than to your whole account.
The practical consequence is that a widget customisation you made for the modern interface may appear to have no effect, because the window your visitors are opening is being rendered by the other one. If something you configured is visible in a preview and absent in the live window, this switch is the first thing to check — before you go looking at CSS, which is where most people go first.
The defaults, which surprise people
Because these settings are stored as text and read with a fallback, an account that has never saved this screen still has effective behaviour. It is worth knowing what it is, and the two theme switches do not default the same way.
The path used when a visitor maximises the embedded window — the arrow at the top right that expands it into a full window — defaults to the modern interface. The path used when a visitor clicks the chat button, link or widget to open a separate window defaults to the classic one.
Read that twice, because it means the same account can serve both interfaces depending on which control the visitor pressed, without anyone having configured anything. If your team has been reporting that the chat window sometimes looks different, this is very likely the reason, and it is not a bug in the sense of something being broken.
What phones get
A fourth switch governs mobile chat behaviour: on a phone, use a popup window rather than expanding in the page. Unlike the desktop switches, this one defaults to on when it has never been saved.
That default is defensible. An expanding panel sized for a desktop layout can render wider than a phone viewport and push part of the chat form off the left edge of the screen, which is a real failure that has been observed on live sites. Opening a dedicated window sidesteps the sizing problem entirely.
It also means that if you deliberately want the in-page experience on phones, you have to turn something off rather than on, and you should test the result on a real device rather than assuming the panel will fit. Chat for mobile visitors covers the wider set of things worth checking on a phone.
The mobile template is decided by the browser, not the screen
The last control is a dropdown that gives phones a different layout template from the one your desktop visitors get. Its first option means inherit — use whatever the general embedded chat uses — and that is what it does if you leave it alone.
The important detail is how the product decides that a visitor is on a phone. It is not a screen width test and it is not a media query. It is a match against the browser identification string, checked against a fixed list of mobile platform names. That has two consequences worth planning around.
First, narrowing your desktop browser window to phone width will never show you the mobile template. Responsive-design habits do not apply here, and a designer checking their work by resizing a window will conclude the setting does nothing. You need a real device or a browser feature that changes the reported identification string, not just the viewport.
Second, the list of recognised platform names is fixed rather than open-ended, so an unusual or newer device that does not identify itself with one of the familiar names is treated as desktop. This is a reasonable trade-off, but it means the mobile template is a best-effort override rather than a guarantee, and the desktop layout still needs to be survivable on a small screen.
One more thing about the template numbers themselves: the runtime checks the template you asked for against the set it actually has installed, and where a template has been retired it substitutes the layout that replaced it. So the number you select is a request rather than a promise. This is not something to worry about — it is what keeps old settings working after a template consolidation — but it does mean you should confirm the result by looking at a real chat window rather than by re-reading the dropdown.
Testing it properly takes four checks
Because the behaviour depends on which control was clicked and on what kind of device is asking, one test proves very little. Four quick checks cover the real matrix.
Open a chat from the floating widget on a desktop browser. Open one from your in-page chat button or text link, if you have one. Maximise an embedded window using the arrow control. Then do the first of those again on an actual phone. Note in each case whether the chat expanded in the page or opened a window, and whether the interface looked the same each time.
If any of the four surprises you, you have found a setting that does not match your intent, and you have found it before a customer did. That is the entire value of the exercise.
Put it into practice
- Decide popup or in page once and set both entry-point switches the same way, unless you have a specific reason not to.
- Treat the theme switches as an interface choice, not a skin, and set both consistently so visitors get one product.
- Check the maximise path separately. It defaults to the modern interface while the button path defaults to the classic one.
- Leave the mobile popup default alone unless you have tested the in-page panel on a real phone.
- Only set a mobile template if you have a device to test on, since resizing a desktop window will never trigger it.
- Re-run the four checks after any widget or template change, because this screen is where an inconsistency hides quietest.
None of these settings are difficult. What makes them worth half an hour is that they are invisible from the outside: nothing on the screen tells you that two of the switches send visitors to different chat applications, or that the defaults for those two switches disagree. Fifteen minutes of clicking your own chat from every entry point you offer is the cheapest quality check available on this part of the product.