Where the assistant appears
Olotalk is one assistant — it answers from your content, cites its sources, and declines when your content doesn’t cover the question. That never changes.
What changes is the shape it takes on your page. The same assistant can be a launcher in the corner, or a panel inside your own layout. You pick the shape by how you drop in the snippet; you don’t configure a different product.
The shapes available today
Three shapes are offered to new installs today — Corner bubble, Drawer and Select to ask. Everything else in this table still works and stays supported for assistants already installed in it; it is simply not handed out from the dashboard while the offering is focused. Launcher with starters is not a separate shape at all — it is what the corner launcher shows on hover.
| Shape | Looks like | Good for |
|---|---|---|
| Corner bubble | A floating launcher, bottom corner, that opens a chat panel | Every page, zero layout decisions |
| Launcher with starters | The corner launcher, offering suggested questions on hover | Sites where visitors don’t know what to ask — part of Corner bubble |
| Inline | A chat panel placed inside a container in your own markup | One high-intent page — pricing, contact, a doc — existing installs only |
| Drawer | Full height, flush to the edge, pushing the page aside when there is room for it | A deliberate “Ask AI” button you place yourself |
| ⌘K panel | Centred over a dimmed page, opened by a keyboard shortcut | Technical audiences who already reach for ⌘K — existing installs only |
| Corner panel | The corner bubble’s panel, with nothing on the page at rest | Sites that want the assistant reachable but invisible until asked — existing installs only |
| Centred panel | The ⌘K panel, opened by your own control instead of the key | The same centred experience without claiming a keyboard shortcut — existing installs only |
| Expand in place | A line in your copy that unfolds into the assistant | A FAQ or a doc, where a panel would be too much — existing installs only |
| Anchored | Beside one element, never covering it | A pricing tier or spec row, seeded with that element’s context — existing installs only |
| Full page | The assistant is the page | A dedicated /ask route — existing installs only |
| Docked sidebar | A fixed rail down one edge, always open | Documentation, where it is a companion rather than an interruption — existing installs only |
| Nav ask field | Your own nav field, wired to the assistant | Making it findable without adding chrome — existing installs only |
| Bottom ask bar | Your own bar at the foot of the page | Long documents — existing installs only |
| Select to ask | Nothing at rest — an offer appears where a visitor highlights text | Reference material, where the question is about this passage |
Every one of them is the same bundle, one line of config apart (~266 KB gzipped) — the same conversation, the same grounding, the same citations. Only the mount differs.
Most of them you install from the dashboard; six you wire up in code. The Install step generates a complete snippet for every shape that needs nothing from you but a script tag — corner bubble, launcher with starters, inline, expand in place, docked sidebar, full page, ⌘K and select to ask.
The other six attach to something only you can point at — including the two plain panels, corner and center, which draw nothing at rest and carry no trigger of their own: a drawer opens from a button you place, anchored needs to be told which element it is about, and the nav ask field and bottom ask bar are your own markup submitting to the assistant. A generated one-line snippet would be an install that does nothing, so the dashboard says so and sends you here instead. Pass mode and call open() yourself: see Assistant API → Shapes.
You never pick a mobile shape. At phone width the corner, drawer, ⌘K and anchored mounts all become the same bottom sheet; inline stays in flow where you put it. One embed covers both. The exception is Select to ask, which offers nothing on a touch device on purpose — selecting text there raises the operating system’s own Copy menu, and we do not compete with it.
What a shape decides
The table above lists the shapes. It is worth knowing the rule underneath it, because it explains the whole set and answers most “can I have…?” questions on its own.
Every shape answers three questions at once, and mode is how you settle all three in a single word:
- Where the panel sits when it is open — a corner, an edge, centred, beside one element, inside your own layout, or the whole page.
- What opens it — a button we draw, a keystroke, a highlight, your own code, or nothing at all because it is already open.
- What is on the page before any of that happens.
That third one is the one people do not expect, so here it is in full.
Only two shapes put a button on your page
| What a visitor sees before anything happens | Shapes |
|---|---|
| A floating launcher in the corner | Corner bubble · Launcher with starters |
| The assistant itself, always visible | Inline · Full page · Docked sidebar |
| One line inside your own text | Expand in place |
| Nothing of ours at all | Corner panel · Centred panel · Drawer · ⌘K panel · Nav ask field · Bottom ask bar · Anchored · Select to ask |
Half the family adds nothing to your page until someone asks for it. So if “no chat bubble in the corner” is a requirement — and for plenty of sites it is — you are choosing among eight shapes, not none — two of them, Corner panel and Centred panel, are exactly the corner and centred panels minus the button.
The three decisions come as a set
Picking a mode takes all three together. That is the point — one word instead of a configuration screen — and it is also the limit: choosing how a shape opens means accepting where it sits and what it leaves on the page.
Two consequences worth knowing before you plan around them:
reachadds ways in; nothing takes one away. You can give a corner bubble a ⌘K shortcut and select-to-ask on top of its launcher — see Combining shapes — but you cannot keep the bubble’s corner panel and drop its button.- Select-to-ask is a shape, not a setting.
mode="selection"means the highlight is the assistant, with nothing on the page at rest.reach="selection"means some other shape gains a highlight trigger and keeps whatever it already showed. The mode-versus-reach section spells this out — it is the easiest thing to mix up here.
Visitors can size it, and move it
Almost any panel that floats over the page can be resized by dragging its edges or corners, and the select-to-ask panel can also be moved by its header. There is nothing to configure: no attribute turns these on, and none turns them off.
The drawer is the exception. Its width is the amount of page it takes away — opening it already moves the site’s own layout aside — so letting a visitor drag that width would re-flow the page underneath what they are reading.
On a narrow window the drawer lays over the page instead of pushing it.
Pushing shifts your <body> by the drawer’s width, but your layout’s
breakpoints answer to the window, and they cannot see that the box they are
laying out in just got narrower. A desktop layout can end up drawing itself into
a tablet-sized column and overlapping — a nav bar running into its own logo is
the usual first sign. So when pushing would leave the page less than 1024px,
the drawer does what the phone sheet already does and covers the edge instead.
There is nothing to configure, the switch follows the window while the drawer is
open, and either way the page stays live and scrollable underneath.
| Shape | Resize | Move |
|---|---|---|
| Corner bubble · Launcher with starters · Corner panel · ⌘K panel · Centred panel | ✅ | — |
| Drawer | — | — |
| Select to ask · Anchored | ✅ | ✅ |
| Inline · Expand in place · Full page · Docked sidebar | — | — |
| Anything at phone width | — | — |
Moving is narrower than sizing on purpose. A corner bubble keeps its launcher on screen while it is open, so letting a visitor drag the panel away would leave the close button stranded in the corner. Select-to-ask has no launcher beside it and deliberately covers the passage it is about, so moving it is the only way to read the original words again.
The size a visitor picks lasts until they close it; the position never carries over. Press the launcher and the assistant is back in its corner — at the size they chose. Both are mouse gestures, with no keyboard equivalent.
The in-flow shapes are your layout, so we leave them alone entirely.
Select to ask keeps working while the panel is open. Highlighting a second passage raises the offer again and adds it to the conversation already running — the panel does not move, and anything half-typed is kept.
Which shape do I want?
Start with the corner bubble. One script tag, works on every page, no layout decisions. Most sites never need anything else.
Go inline when placement is the point. On a pricing page, a bubble in the corner is easy to ignore; a chat panel under the plan table is part of the decision. Same assistant, rendered into a container you control.
And you don’t have to choose just one way in. A page mounts one shape — that’s where the conversation lives — but extra triggers can be raised over it: add data-olotalk-reach="selection,commandk" to the snippet and your corner bubble also opens when a visitor highlights text or presses ⌘K. Your own buttons and fields can open it too. However many doors you add, it’s still one panel and one conversation — see Combining shapes.
Installing on a platform
If you’re on Webflow, Shopify, Ghost, Squarespace, WordPress, or another hosted platform, there are step-by-step guides that account for where each platform lets you inject scripts:
And if you can’t touch the site at all, the full-page shape is available with zero install as your assistant’s hosted page:
What every shape needs
Whichever you choose:
- An assistant ID. In the dashboard, open your assistant from Assistants — the ID is shown on its Install step (and in the page URL).
- Ingested content. The assistant can only answer from pages Olotalk has crawled. An empty corpus produces an honest but useless “I don’t have that.”
- Your domain on the allowlist. Requests are checked against the assistant’s allowed domains, so a copied snippet can’t be used on someone else’s site. Add every origin you serve from, or you’ll get
403 Domain not allowed. While developing, prefer a sandbox token over allowlisting your dev host (preview feature) — it keeps test traffic un-billed and out of your analytics.
To make the assistant match your site’s look — font, colours, corners — see Theming. It’s a few CSS variables and works the same in every shape.