A note is a piece of text. That much we agree on. What that text is for changes by the hour: a half-formed thought you're writing into existence; a research dump you're skimming for one specific phrase; a meeting agenda you're projecting on a wall; a thirty-page brief you're proof-reading on a flight.
Every one of those wants a different reading surface. For most of last year, Vist gave you exactly one: a 720-pixel-wide centred column, comfortable for writing, mediocre for everything else. This post is about the four modes Vist now offers instead, why each exists, and the trade-offs that fell out.
The four modes
Every note has a View Options menu in the editor header. From there, four modes:
- Normal — the default. Centred, comfortable, balanced for writing.
- Full-page — the sidebar and notes list collapse, the editor fills the viewport. Toggle with
Cmd+\. The right call when you've stopped consulting and started writing. - Presenter — fullscreen API, large type, a soft blue cursor dot to guide an audience's eye. Designed to be read from three metres away.
- Focus — typewriter-style. The paragraph you're in stays in the middle of the viewport; everything else dims. The hardest of the four to specify in words, the easiest to feel after thirty seconds.
The shortcuts overlap usefully. Cmd+\ for Full-page. Cmd+Shift+P for Presenter. Cmd+. for Focus. Esc exits any of them and drops you back to Normal. All four are also reachable through the command palette — type "presenter" and hit return.
Why each mode exists
Full-page is the cheap one to justify. People kept maximising their browser, kept asking for a way to hide the panels, kept pasting screenshots into Slack of Notion's "full screen" view as the thing they wanted. It got the most prominent shortcut for that reason.
Presenter is less obvious. I almost cut it twice. The pattern that saved it: people were exporting notes as PDFs to project them in stand-ups. A presentation mode in the same tool, with the same shortcut affordances, beat the round trip every time. The blue dot cursor isn't decoration — it's a guide for the audience's eye when the presenter's mouse is otherwise invisible against the dark surface.
Focus mode is the one I went back and forth on the longest, and the one with the least obvious return. It pays off only if you write long-form. If you do, you already know what iA Writer feels like, and you can stop reading this paragraph. If you don't, it's a feature you'll forget exists for six months and then need at 11 p.m. with a deadline.
How the editor hands modes off
Mode state persists in localStorage and is picked up by a Stimulus controller attached to the editor frame. The interesting bit isn't the toggle itself. It's FOUC prevention.
If you read mode preference from localStorage after the page renders, you get a half-second of Normal-mode flash before the mode you actually want settles in. The fix is to read it before — in a blocking script that runs ahead of the first paint and sets the mode class on the document root. CSS keys off that class from the start. The mode is correct on first paint, every time.
The fullscreen-API call (for Presenter) is a separate concern. Browsers require it be invoked from a user gesture — you can't auto-enter fullscreen on page load. So Presenter mode has two states: "armed" (CSS applied, but not yet fullscreen) and "active" (browser fullscreen request fulfilled). The Esc handler tears down both atomically.
Per-note reading width
Width is a per-note preference, not a global one. A research document wants wide; a journal entry wants narrow; a hand-typed brief might want full-bleed. Three settings — Narrow (~580px), Wide (~960px), Full (no max) — picked from a small chooser in the editor header.
The preference is stored server-side, keyed per note. Switching devices keeps your width — which sounds trivial until you realise you've been silently re-setting it on every new machine for months on every other notes tool.
Mermaid, when you want it
A fenced code block tagged mermaid renders as an inline SVG diagram. Click to edit the source; click away to re-render. The Mermaid library loads lazily — the chunk is gated behind a dynamic import() that fires only when the first mermaid block is detected. If you never use them, you never download them; the editor stays sub-second on a five-year-old laptop.
One thing worth testing before shipping: nested code blocks. If your note has both a mermaid block and a javascript block, both highlight correctly without one stomping on the other. That's not automatic — the syntax highlighter needs to handle multiple block types in a single document without conflict.
What's next
The modes themselves are stable. The next layer of work is interaction during reading — annotations, in-line comments, share-as-PDF-with-presenter-notes. None of those are shipping this quarter, but the surface area exists for them now.
The bigger pattern, if you're building something similar: don't treat read and write as the same UI. Most editors do. The two jobs share a buffer; they don't share an affordance set.