I built a tool that explains things where you are already reading them. Highlight a phrase, get an explanation on the spot — no new tab, no side panel, nothing displaced. Then I used it every day for months, first as a browser extension and later as a desktop application. What I learned was not about the feature I had built. It was about the question that arrived immediately after it.
The companion to this paper, The Panel Is Also a Tab, makes the argument about mechanism: what looking something up mid-document actually costs you is not the trip out, it is the trip back — and nearly every answer surface on the market shortens the trip out while leaving the trip back exactly where it was. This paper is the design account that follows. It is what happened once the thing existed and I had to live with it.
I am writing this as a first-person account because that is what it is. Where a claim rests on my own use rather than on anything measured, the paper says so.
The first answer is a dictionary. The bubble that reopens for the follow-up is the whole point.
What v1 was
Highlight some text, get an explanation where you highlighted it. One question, one answer, no follow-up. It met the four conditions the companion paper sets out: context taken from the selection rather than retyped, answer anchored at the selection, nothing displaced, clean dismissal.
It worked. And within a few weeks of real use the interesting failure was obvious, and it was not a failure of the mechanism.
The failure was that it could only be asked once
The first answer resolves the word. It very rarely resolves the confusion.
What actually happens is that the explanation lands, and it immediately raises the real question — yes, but why does that apply to this sentence, or is that the same sense of the term the author is using, or what would it mean if that were false. Those are the questions worth asking. They are also questions that cannot be asked before the first answer exists, which is precisely why a one-shot explainer cannot serve them.
So the usage pattern degraded in a specific way: I would take the inline answer, and then — for anything I actually cared about — open a chat somewhere else and restate the whole thing. The tool had removed the first tab and left the second. Every time that happened it was evidence that a single-shot inline explanation is not a smaller version of a conversation. It is a different, less useful thing.
This is the substance of the design change. The product is not "inline explanations." It is inline explanations you can keep asking about, and the second half carries most of the value.
Why the follow-up cannot be a link to somewhere else
The obvious cheap fix is a "continue in chat" affordance. It does not work, and the reason is the whole thesis: the moment the follow-up opens a panel or a new surface, you have paid the re-entry cost you were avoiding, and you have paid it at the worst possible time — after the tool has already demonstrated it could answer in place, which makes the switch feel like a bait.
The follow-up has to happen in the same anchored surface, retaining the original selection as context, without the document moving. That is harder than it sounds, because a growing thread wants vertical space and the one thing the surface must not do is displace the paragraph. That constraint — a conversation that grows without moving the thing it is about — is the actual engineering problem of this product, and it is not solved by any panel because panels are exempt from it by construction.
Why it had to leave the browser
An extension can only exist where the browser is. The moment the thing you are reading is a PDF in a native viewer, a document in a desktop editor, a message thread, a terminal, or a book in a reader application, the affordance simply is not there — and the reflex it was training in you fails silently. A tool that teaches you to expect an answer in place and then is absent for half of what you read is arguably worse than no tool, because it has replaced a reliable habit with an unreliable one.
That is the case for standalone, and it is a stronger case than "more platforms." It is a coherence argument. An in-place explainer has to be available everywhere you read, or the thing it is actually selling — that you never have to leave — is not true.
Spotlight is the obvious model and the wrong one
The default way to build system-wide is the launcher: a global hotkey, a modal overlay, a text field. It is well understood, users know it, and every desktop assistant reaches for it.
It is the wrong shape here, for the reason the companion paper gives. A launcher is built to take you somewhere. It appears over your work, expects a typed command, and clears. It has no relationship to what you were looking at — it cannot, because it was designed for a world where the input is a command and not a passage. Summoning a launcher to ask about the paragraph behind it means the paragraph is now behind a box, and you are retyping context you can no longer see.
A standalone in-place explainer inverts every one of those properties:
| Launcher | In-place explainer | |
|---|---|---|
| Input | A typed command | A selection already on screen |
| Position | Over your work | At the thing it is about |
| Relationship to context | None | The context is the input |
| Lifecycle | Summon, act, dismiss | Persist alongside, keep asking |
| Success condition | You went somewhere | You did not have to |
Same distribution mechanism, opposite interaction model. Building the launcher because it is the standard system-wide pattern would be shipping the pattern this product exists to argue against.
Where the build actually is, honestly
The extension is retired. Its source is not in a repository and not on the server; that is a real loss and it is not recoverable, so a standalone client is a rebuild rather than a port.
What exists today is a web application with a gated ask surface: you enter a question, optionally paste the passage it is about, and get an answer in a thread that takes follow-ups. That is the conversational half of the thesis working, and it is deliberately the half that was built first, because it is the half that carries the value.
It is also, plainly, not yet the product this paper describes. Pasting a passage is not taking a selection. A web page you navigate to is not in place — it is a tab, which is where this began. The current surface proves the second question matters; it does not yet deliver the first condition.
Saying that in public is uncomfortable and correct. The alternative is marketing copy describing a right-click affordance that no longer exists anywhere, which is what the site said for months after the extension was abandoned.
What the retirement cost, concretely
One consequence is worth recording because it is the kind of thing that is invisible until it bites. The original revenue model had two halves: a licence tier where users brought their own API key, and a credits tier proxied through the backend. Bring-your-own-key lived inside the extension — it was the extension that held the key and called the provider directly. When the extension went, that tier became unsellable, and it stayed on the pricing page anyway.
The lesson generalises past this product. A pricing tier is not a row in a table; it is a claim about a capability that some specific piece of software provides. Retire the software and the tier is a promise nothing can keep.
What standalone has to be
Stated as commitments rather than features, so they can be checked:
- Selection is the input. Wherever text can be selected, the explainer can be raised on it, with the surrounding context captured automatically.
- The answer does not displace the source. Anchored, non-reflowing, dismissible without residue.
- The thread persists and stays anchored. Follow-ups are free and remain attached to the original passage.
- It is available everywhere reading happens, or it does not get to claim that you never have to leave.
- The record of what you asked is treated as sensitive, on the argument already made in Your Knowledge Gaps Are the Most Intimate Data You Have — a log of everything you did not understand is not ordinary telemetry.
The fifth is not a design nicety. It follows directly from an argument this series made before the product existed, and it constrains the architecture: the more of this that stays on the user's machine, the less of that record there is to hold.
What I would tell someone building the same thing
Build the second question first. It is tempting to perfect the inline presentation — the anchoring, the animation, the dismissal — because that is the visible craft and it demonstrates well. But a beautifully placed answer that cannot be interrogated is a dictionary with good typography, and users route around it to a chat window within a week.
The presentation is what makes the product feel right. The follow-up is what makes it worth returning to.
