Meeting your map as a stranger would
Once a map is published, it stops being yours in an important sense: it becomes something a complete stranger can open, with no account, no session, and no idea of the machinery behind it. To use the publishing platform well, it helps to step into that stranger's shoes and understand exactly what they encounter, because the reader's experience is the actual product. Everything you did in the producer flow was in service of this moment.
A reader arrives at a published map by following a link of the form /p/{token}. There is no sign-in wall, no cookie banner demanding consent, no Krataxis branding asking them to make an account. The page simply loads the map. This anonymity is not an accident of configuration; it is a designed property. The public viewer is a separate, self-contained application that knows nothing about your tenant, your identity, or the live platform — it knows only how to render a sealed public payload. That isolation is part of the safety story from the first chapter: there is no authenticated context for a reader to exploit, because the viewer never had one to begin with.
What the reader sees is the artifact you froze: the events, actors, and layers you selected, framed by the camera you composed, governed by the controls you chose, narrated by the captions you wrote. If you authored the map as a static moment, that is what they get — a considered view of a scene. But the platform's more expressive features come alive here too, and they are worth understanding from the reader's side.
Scrollytelling: a map that reads like an article
If you wrote a sequence of narrative captions, the reader experiences them as scrollytelling — a form that fuses the linearity of prose with the spatial power of an interactive map. As the reader advances through the narrative, the map responds: it moves to the place each beat is about, brings the relevant features into view, and lets the words and the geography reinforce each other. The reader is not handed a map and left to fend for themselves, nor handed an article that merely mentions places; they are walked through the situation, step by step, with the map doing the showing while the captions do the telling.
This is why the narrative stage of authoring mattered so much. Scrollytelling is only as good as the sequence of beats behind it. A well-built narrative gives the reader a guided path from "here is the situation" through the evidence to "here is the point," and the map's movements punctuate that path. From the reader's perspective it feels effortless — they simply scroll, and understanding accumulates — which is precisely the effect a good explanatory graphic should have.
Time reveal: letting the reader move through the chronology
Where scrollytelling moves a reader through a narrative, time reveal moves them through time, and the two often work together. If you enabled a timeline, the reader gets a control that lets the map express its chronology rather than dumping every event onto the screen at once.
Recall the three ways time can be presented, now seen from the reader's chair. Under a cumulative reveal, the map fills in as the reader advances — events appear and stay, so the reader watches the picture build and can feel the weight of accumulation. Under a windowed reveal, only events near the current moment are shown, so the reader watches activity move across the map like weather, with the past fading behind them. Under a static presentation there is no time control at all, because the moment is singular and asking the reader to scrub through time would only distract from it.
Each of these is a different argument about time, and choosing among them in the producer was choosing how you wanted your reader to reason about the chronology. A cumulative reveal argues "look how this added up." A windowed reveal argues "look how this moved." A static view argues "look at this one moment." The reader never has to think about any of that; they simply experience the chronology the way you decided to tell it.
Reports, context, and version banners
A published map rarely travels entirely alone. The platform lets you associate reports with a map — the textual, analytical products that give the spatial picture its written backing — and a reader can move between the interactive map and the prose that explains it. The relationship is flexible: a map can carry several reports, and a report can accompany several maps, because in practice a single analytical product often illuminates more than one view and a single view often deserves more than one written treatment. For the reader, this means the map is not a dead end; it is a hub that connects the spatial evidence to the reasoning about it.
The reader is also kept honest about which version of the map they are looking at, and this is where the versioning machinery from the first chapter surfaces in the interface. If a reader has arrived at a version that has since been superseded — perhaps an old link circulating in an email thread — the viewer shows them a banner telling them a newer version exists, so they are never misled into treating a stale snapshot as the current picture. Conversely, when they are looking at the latest version, the viewer reflects that too. The reader is thus always oriented in time: they know whether they are reading the current account or a historical one, and they are given the means to find the current one if they want it. This is the snapshot principle made visible — frozen artifacts, honestly labelled, with the freshest always within reach.
Embedding: carrying the map into someone else's page
Sharing a link is one way to distribute a published map. The other — often the more powerful one for journalists and analysts who write for an audience — is embedding: placing the live, interactive map directly inside another web page, so that a reader of that page can pan, zoom, scrub time, and follow the narrative without ever leaving the article they are reading.
It is worth being precise about what an embed is, because the word gets used loosely. An embedded Krataxis map is not a screenshot and not a copy. It is the very same published artifact, rendered live, displayed inside a framed region of the host page. The host page does not get a static image of your map; it gets a window onto the real, interactive viewer. This means an embedded map carries all the behaviour we have just described — scrollytelling, time reveal, reports, version banners — into the host page intact. And because it is the same frozen artifact behind the same token, every safety property holds: the embed exposes exactly what the published map exposes, nothing more, and it remains addressed only by its opaque token.
Getting the embed code
The producer makes embedding a copy-and-paste affair. On any live map in your list, the Embed action reveals a ready-made snippet. The snippet has two short parts: a framed region that points at your map's public address in its embeddable mode, and a small companion script. You copy the snippet and paste it into the host page's HTML, and the map appears.
Before you copy, you can choose a width that suits the host layout. The default is fluid — the map stretches to fill whatever column it is dropped into, which is usually what you want inside a responsive article. If the host needs a fixed size instead, presets offer common fixed widths. Whichever you choose, the embed keeps a sensible aspect ratio so the map is never squashed into an awkward shape; its height follows from its width rather than being something you have to guess at.
How the embed behaves once it is on the page
Two mechanisms make an embedded map feel like a native part of the host page rather than an awkward iframe bolted on, and both are worth understanding because they explain behaviour you will otherwise find slightly magical.
The first is the companion script, whose entire job is automatic height. A map embedded at a fixed height is a perennial annoyance: too short and it scrolls awkwardly within its little box, too tall and it leaves dead space. The script solves this by letting the framed map tell the host page how tall it actually wants to be for the width it has been given, and the host adjusts to fit. The result is an embed that sits flush in the layout, sized correctly, adapting if the column resizes. You do not configure any of this; including the companion script is all that is required.
The second is oEmbed, a quiet but valuable piece of plumbing. Many publishing platforms and content tools, when you paste a bare URL, try to "unfurl" it into a rich embedded card rather than leaving it as plain text — this is why pasting certain links into certain editors automatically produces an embedded player or preview. Krataxis published maps speak the oEmbed protocol, which means that on platforms that support it, simply pasting the map's public URL can be enough to produce a proper interactive embed, with no need to hand-place the snippet at all. Where a platform does not support oEmbed, the copy-and-paste snippet is always available as the reliable fallback.
Why embedding is safe to hand out
It is natural to feel a flicker of caution about putting your map onto pages you do not control. The platform's design is what should put that caution to rest. An embed is the same frozen, allow-listed artifact addressed by the same meaningless token as the public link; handing someone the embed code grants them no more than handing them the link does. The framing is scoped so the map is shown as a guest in the host page without surrendering anything to it, and the artifact has no live connection to your battlespace to leak through. In short, an embedded map is exactly as safe as a published map, because it is the published map — just displayed somewhere else.
With the reader's experience and the distribution tools understood, the only question left is the one every author eventually asks: is anyone actually out there reading this? That is the subject of the final chapter, Understanding Your Readership, which also explains the unusually principled way the platform chooses to answer it.