Preview
A real preview at real offsets, beside every tab of the editor, with a sample store or your own storefront behind it, a page-type simulator, a full-size view, and a short-lived link that shows a version on your live site.
The right-hand column of the editor is a real preview, not a decoration. It stays beside every tab, and stays in view while you scroll the tab's content. It renders from the same resolver your storefront uses, at the offsets you configured, on a page-sized surface, so an 88-pixel bottom offset looks like 88 pixels instead of being reported as a number beside a picture that ignores it.
Because both the preview and the public site config read the same resolver, the preview structurally cannot show a colour, size, corner radius or shadow your shoppers would not get. It approximates one thing only: the font. In production a widget's text uses your storefront's own font, which the dashboard can't know, and the footer under the sample store says so ("Your site's font may differ").
The controls change what you look at, never the widget
A row of controls sits above the scene, wrapping onto a second line rather than scrolling when space runs out, in the order you set the context: which page, which device, which language, then which store. None of them makes your draft unsaved.
- Simulated page: which page the shopper is on, one of the five page types (Home, Product, Category, Content, Blog) or Page type not declared, a page with no type. It decides two things: whether your targeting would show the widget there (if it's excluded, the scene says so and names the page types it does target, instead of drawing a widget that would not be there, using the same rule the tag applies) and, on the Sample store, which page is drawn (see below). It only simulates the type you pick: it doesn't look up what your site's Pages hold for an address. It stays usable even with Show on every page instead on, since it still changes the page drawn. The preview opens on a page the widget targets: the first of Home, Product, Category, Content and Blog it targets, or Home when it shows on every page or targets nothing yet. Changing the targeting afterwards doesn't move it.
- Desktop / Mobile, shown as two icons (hover one for its name): the mobile frame applies your narrow-screen offsets when you have set them, at the same breakpoint the tag uses.
- Language: which language's text to render, from the languages enabled on your site, each named in the language of your dashboard profile. It starts on your site's default language. This is deliberately not your dashboard's interface language, which bears no relation to your shoppers. A site with only one language shows no language control.
- Sample store / Your site: Sample store is a drawn storefront, shaped like the page type you're simulating (see below). Your site loads your own storefront behind the widget. See below. A site with no storefront URL recorded shows no source control: the sample store is all there is.
A question bar adds one more control, Rest / Engaged / Folded, beside Desktop / Mobile. See The question bar's three states.
Expand preview, the arrows icon at the end of the row, opens the same preview at full size, with the same controls and the same settings. Close it and you're back in the editor with nothing lost, unsaved edits included.
A floating widget sits on a page that scrolls
For a Chat bubble or a Question bar, the sample store is drawn as a full page of the type you're simulating: a home page with a hero and product rows, a category page with filters and a grid, a product page with a gallery, price and add-to-cart, or the plain generic page for Content, Blog and when no type is declared. The footer under it names the page it stands for, for example "Sample store, product page". Each one is taller than the frame, ends with a site footer, and scrolls inside the frame, because a page that exactly fits the frame can't show the one thing that matters most: whether your widget ends up sitting on top of something on the real page, like a sticky add-to-cart bar or your footer. On the Mobile frame, the product page's add-to-cart stays pinned to the bottom, as it does on most mobile product pages.
Scroll the page and a floating widget stays exactly where it's docked. That's the point, since that's how it behaves on your real storefront too.
An inline widget sits on a page excerpt
A Button or Starters widget raises no such question: the preview doesn't claim where it lands on your page (see An inline widget needs page types). So on the Sample store it is drawn on a short excerpt of the page, exactly as tall as the frame, and you see the whole widget as soon as the preview opens, without scrolling.
The excerpt has four parts, top to bottom: the site's navigation, one hint of the page above the widget, the widget itself, in a dashed box on a plain white ground, and one faded hint of the page below it. The dashed box is the preview's own scaffolding, not a slot your page provides, so it carries no label. The notice under the scene says it instead: "Appearance only, not placement", followed by "This shows how the widget looks, not where it lands." It is shown on the Sample store only. Only the two hints change with the simulated page:
| Simulated page | Above the widget | Below the widget |
|---|---|---|
| Home | the hero, reduced to a band with its call to action | a row of product tiles |
| Category | a breadcrumb, the category title and filter controls | a row of product tiles |
| Product | one row: thumbnail, title, price and add-to-cart | lines of description |
| Content | a page title and two lines of text | lines of text |
| Blog | a section label, an article title, an author line | lines of text |
| Page type not declared | faded product tiles | a row of product tiles |
Content and Blog have hints of their own here, while the full page drawn for a floating widget still uses the generic page for them.
When the preview is too short for the widget, for example in a small browser window, the hint above shrinks away first. If the widget still doesn't fit, the frame scrolls, and the widget scrolls with the page. Nothing of the widget is cut off.
There is no control to put an inline widget on the full page, or a floating one on the excerpt. Your site is not affected: it always shows your own storefront.
When the draft has Show starter questions on, the scene also draws the starter-question chips above the widget: the actual three the storefront would serve for the simulated page type and the previewed language, resolved by the same code the public site config uses. Change either control and the chips change with it; on Page type not declared there are none, exactly as on a page with no type.
On a question bar, the chips are drawn only in the Engaged state, because that is the only state in which a shopper sees them.
Every one of these is available on a view-only role. Only the preview link needs edit access, because it mints a credential.
The question bar's three states
For a question bar, a second segmented control, Rest / Engaged / Folded, sits next to Desktop / Mobile. Other formats don't show it. It opens on Engaged, so a draft with Show starter questions on shows its chips straight away.
- Rest: the bar with no chip. Its field shows the first of the page's starter questions as text, standing in for the typewriter, or your placeholder when there is no question to show.
- Engaged: the chips above the bar, the shadow one step up, and on the Desktop frame the wider bar.
- Folded: the round bubble, as tall as the bar, at the bar's right edge, in the send button's colours with the folded bubble's icon. It is only available on the Mobile frame: on Desktop the option is disabled, and switching to Desktop while it is selected moves the preview to Engaged. Picking an icon under Folded bubble on the Appearance tab switches the preview to Mobile and Folded for you.
These are stills. The preview doesn't play the typewriter, the reveal or the fold. The send button is drawn at 50% opacity, as on the storefront while the field is empty. The Desktop frame stands for a 1512px window: the bar takes the share of the frame that its size gives it in such a window. Resting, that is about 24% (Small), 25% (Medium) or 27% (Large) of the frame, and engaged about 31%, 34% or 41%. It can't show how the width changes with a smaller or larger window. The Mobile frame never widens it. See The question bar for how each state behaves for a shopper.
Your site's other widgets, and overlaps
When you edit a floating widget, the scene draws your site's other live widgets as dashed, non-interactive outlines: floating ones at their real geometry, so you are adjusting offsets against what your shopper's page actually contains rather than against an empty page, and inline ones (Button, Starters) as an outline in the page's dashed band.
When you edit a Button or Starters widget, the scene draws no other widget. An inline widget claims no position in the preview, so it has nothing to collide with there.
They are read from what is published, never from their drafts. Another widget's unpublished draft is not on the shopper's page, and drawing it would invent a collision that doesn't exist. A widget that has never been published isn't drawn at all.
When the widget you are editing would land on top of a floating one, the footer warns and names the other widget. It updates live as you change offsets, and it never blocks a save: two widgets deliberately stacked is your call. The footer's right side states the resolved geometry: size, corner radius, and both offsets.
Your own storefront behind it
Switch the scene to Your site and your storefront loads behind the widget. The framed URL is editable and defaults to your site's recorded URL, so you can preview the page type you are actually targeting rather than only the home page. With no URL recorded for the site, the source control isn't shown and the preview stays on the sample store. Add your storefront URL in Site settings → Website to get it.
The framed URL carries the tag's own disable parameter, so if you already have the tag installed you don't see your published widget next to the previewed one.
Whether your site allows being framed is checked server-side, from its response headers (X-Frame-Options, or the Content-Security-Policy frame-ancestors rule), not by loading it and waiting for a timeout. When it refuses, the scene falls back to the sample store.
The preview link
For the cases a dashboard preview cannot settle (does the bubble sit on top of your cookie banner?), Preview link, under the preview after its caption, creates a short-lived link that shows one version of this widget, at its latest saved state, on your real storefront, with the real tag.
- The link shows the version that was on screen when you made it, and it follows that version: a save made after the link was made is what the link shows. Only someone with the link sees it. Your shoppers keep getting the published version, and every other widget on the page renders from its published version too, so the page is otherwise exactly what a shopper sees.
- It is scoped to one widget. It exposes no other widget's draft, no dashboard access, and no way to write anything.
- It expires after an hour, enforced on the server. Revoke kills it immediately, from the next request.
- There is one link per widget at a time: asking for a new one replaces the old.
- The editor shows the link only on the version it was made for. Open another version and no link is shown there. A link made before versions had saved states shows the widget's pending draft instead.
- While a link is outstanding, the editor's header shows a Preview link active badge, so you don't generate one and forget it exists.
A link that is expired, revoked, malformed or aimed at the wrong widget is treated as no link at all: the published configuration is served, exactly as for any shopper, with no error shown to whoever opened it.
Drafts, publishing and versions
A version (V1, V2…) is a line of saved states. Saving never changes what shoppers see, Go live puts the latest saved state of a version online, Save as a new version starts the next V number, and only a version tested in an A/B test is locked.
Appearance and placement
Style each part of a widget on its own (fill, text, border, corners in pixels, label weight, icon), with your brand colours as the default, plus size, shadow, offsets, narrow-screen offsets, position and stacking order.