The widget editor

A widget's own page is a single workshop, not two: there's no separate Editor page and Performance page to switch between. Performance and Experiment are the sixth and seventh tabs in the panel described below, right after Versions; five of the seven tabs (General, Design, Display, Content, and Versions) are covered on this page, Performance gets its own page for its funnel and version-over-version comparison, and A/B testing a widget covers Experiment.

The editor itself is a two-column workshop. On the left, the widget standing on a page-sized storefront at the offsets you set. On the right, a panel of seven tabs. Across the top, a bar carrying the widget's name, which version you are editing, whether shoppers can see it, and the two buttons that change either of those.

The action barCopy Anchor Link

It shows two things side by side, because they answer different questions: a version badge (which configuration you are editing, and whether it is a draft, live or archived) and a status (what shoppers get right now). A widget can be live on v2 while you write v3.

The write actions live here too: Save draft, Publish, and Preview link. On a view-only role, all three are simply absent rather than present-but-greyed, a line says the page is read-only, and every tab, the version history and the whole preview stay readable.

The seven tabsCopy Anchor Link

General, Design, Display, Content, Versions, Performance, then Experiment, in that order across the top of the panel.

General: everything here applies immediatelyCopy Anchor Link

• Active (the on/off switch) and Name are properties of the widget itself, not of a version. They take effect the moment you change them: switching a widget off stops it now, not once you remember to publish. The name is how the list tells your widgets apart, so make it say what the widget is for: "Sales help (desktop)", "Checkout question bar". A new widget arrives named after its format; replace it.
• Delete this widget sits at the bottom. See Delete a widget.

Because everything on this tab applies at once, changing it never marks your draft as having unsaved work, and discarding draft edits never reverts it.

Design: the format, then the look and the placementCopy Anchor Link

• Format is at the top, because it decides which of the fields below you even get. Changing it goes into the draft like every other setting. See Changing a widget's format.
• The appearance fields: background colour, icon and text colour, size, corners, shadow, and a chat bubble's icon. See Appearance and placement.
• Chat bubble placement: Position (Left/Right; see below), Bottom offset and Side offset in pixels (0–200, default 20 each).
• Question bar placement: Bottom offset only: it is always horizontally centred.
• Button placement: none here. An inline button has no offsets and no docked side; where it goes is decided on the Display tab.

The two floating formats keep narrow-screen offsets and stacking order behind an Advanced block, collapsed by default: they matter, but most widgets never need them.

Display: where it is allowed to showCopy Anchor Link

Show on all pages, and, when that is off, Show on these page types. See Page-type targeting.

For a button this tab carries the placement too, because a mount point is its position: the three ranked mount modes, the fields the chosen mode needs, Width and Alignment, and a mount check that reports what the tag found on a page you previewed. Show on all pages isn't offered. See Place an inline button on your pages.

Content: the shopper-facing text, and the starter-questions switchCopy Anchor Link

One row per language enabled on your site, with a dot showing which languages are still empty. A chat bubble's or a button's Text, or a question bar's Placeholder. It comes after Display because translating is a separate pass, often by someone else, once the widget's shape is settled. A button's text is the one that is required (its draft won't save with every language empty), and a button carries a second, optional row here: the first message its click sends.

Below the text field, Show starter questions decides whether this widget renders chips from the site's starter-question library above itself: off on a new widget, versioned like every other field here, so it reaches shoppers when you publish. Manage questions opens the library; the questions themselves aren't listed or edited here, because they belong to the site, not to this widget, and editing one applies immediately everywhere.

Versions: what is served, what is waiting, what came beforeCopy Anchor Link

See Drafts, publishing and versions.

Performance: how this widget is actually doingCopy Anchor Link

Unlike the other five, this tab is a read action, not an edit: it stays usable on a view-only role, and picking a date range never touches the draft. See Widget performance.

Experiment: run your draft against your live version with real trafficCopy Anchor Link

Sits outside the edit-gating that covers General through Content, the same way Performance does: a view-only role sees the same figures an editor does, with the start/stop/promote actions simply absent. See A/B testing a widget.

Why a new widget isn't live yetCopy Anchor Link

A widget needs three things before it can appear anywhere: it has to be Active, it has to have somewhere to show (at least one page type checked, or Show on all pages on), and it has to have been published at least once. A newly created widget already has the first two (it arrives active, and already targeting a sensible default: Show on all pages for a chat bubble or question bar; every page type for a button, the closest an inline format gets to "everywhere"), so publishing is the one thing standing between it and your shoppers.

While any of the three is missing, the Display tab carries a "This widget isn't live yet" notice. It names one thing at a time, the one to act on first:

• Never published: "This widget has never been published, so there is nothing to serve. Publish the draft to put it live." This is what a freshly created widget sees.
• Switched off: "It's ready to show, but inactive. Turn on Active to put it live."
• No page type: "It's active, but no page type is selected. Pick at least one, or turn on Show on all pages."
• An inline button left in all-pages mode: "An inline button needs specific page types. It cannot show on every page, because its position only exists on the pages that have it." You only see this on a widget switched to the button format while that mode was on; the switch itself isn't offered to an inline format.

Being switched off outranks the rest, and never-published outranks no-page-type: telling you to pick a page type for a widget you have not turned on, or not published, would be advice about the wrong step. A newly created widget is already turned on and already targeted, so it skips straight to the never-published notice: nobody is told to flip a switch that would not help.

The notice follows the switches as you flip them, before you save, and disappears once none of the three holds. It can't be dismissed: it reports the widget's current state rather than announcing something.

Publish says the same thing at the moment it matters. Publishing a widget that is inactive, or that targets nothing, is allowed, but the surface tells you first that it will not make the widget visible, and names which condition is unmet.