The Second Question: What Changes When an Explainer Can Be Asked Again

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, and the next section is explicit about where that line falls, before the argument rather than after it.

The first answer is a dictionary. The bubble that reopens for the follow-up is the whole point.

1. Scope, standing, and what would falsify this

This is a design account, not a study, and I would rather say so plainly than let the footnotes further down imply otherwise.

What it argues from. Three things. First, direct, dated use: I built an in-place explainer, shipped it as a browser extension, used it as my own primary reading tool for several months, then rebuilt the conversational half as a web application and have used that daily since. Second, the mechanism argument made in the companion paper, The Panel Is Also a Tab, which this paper takes as established and extends rather than re-argues. Third, a body of information-science research on how people actually ask questions, which turns out to predict the central finding of this paper by about forty years — specifically Belkin, Oddy and Brooks' 1982 account of the "anomalous state of knowledge" and Bates' 1989 model of berrypicking search behaviour, both introduced properly in §3.¹²

What it does not argue from. No usage analytics. The extension is retired and its telemetry, such as it was, is gone with the source code — a loss recorded honestly in §7 rather than papered over. No controlled comparison between a one-shot explainer and a conversational one; I have used both, in sequence, as the same person, which is the weakest possible design for separating "the tool got better" from "I got used to it." No claim about how many users behave the way I did. Where this paper says "users route around it," read that as the first-person claim it actually is — I routed around it — and the same correction applies wherever else the plural creeps in, including the claim walked back in §8.

What would falsify it. Stated in full in §12, in decreasing order of how much damage each would do to the paper's claim. The headline version: if a one-shot explainer, tested against a conversational one with real readers, shows no difference in comprehension or return-to-tool behaviour, the central claim of this paper — that the follow-up carries the value, not the placement — is wrong, and I would want to know that before anyone else adopts the conversational design on my say-so.

2. 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.

3. 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.

What I did not know, when this became obvious from use, is that it had already been described — not in product terms, but as a property of information need itself. Belkin, Oddy and Brooks' 1982 "ASK" hypothesis holds that a person seeking information frequently cannot specify what they want, because the want is itself a gap in their knowledge, and a system that demands a well-formed query up front is demanding a specification the user is not yet in a position to write.¹ Transpose that from a 1980s information-retrieval system to a reading tool and the finding is exactly this paper's: the first answer is not a failure to satisfy the need, it is the thing that makes the actual need expressible for the first time. A one-shot explainer meets the ASK-type gap with a single retrieval and then closes the door on the question that gap was always going to produce next.

Bates' 1989 model of "berrypicking" search adds the dynamic version of the same point: a searcher's information need evolves continuously across a search session as each result is read, rather than existing complete and fixed from the start, which is why real search behaviour looks like a sequence of small, locally-triggered moves rather than one well-aimed query.² An inline explainer that permits exactly one move per selection is, by Bates' account, built for a theory of information-seeking that the field had already dropped before this product category existed. I did not set out to test either paper. I re-derived, from usage, a finding information science had already made, which is a humbling way to discover you were right.

4. 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.

There is a mechanism-level reason this matters more for the follow-up specifically than it does for the first answer, and the companion paper's sources make it explicit rather than leaving it as intuition. Altmann and Trafton's activation-based model of goal memory treats resuming a suspended task as a retrieval problem: the goal's activation decays once you stop attending to it, and what reactivates it is an associative cue in the environment — in a reading task, that cue is the sentence itself, still on screen and still in the state you left it.³ A first answer that displaces the sentence, even briefly, removes exactly the cue the second question would need in order to be asked well. Trafton, Altmann, Brock and Mintz's study of task resumption found that perceptual availability of the primary task — being able to still see it, not just remember it — measurably aids re-encoding the goal when an interruption ends.⁴ A follow-up box that covers the paragraph is reintroducing the interruption the first answer was supposed to have avoided, directly at the moment a reader is forming the question that depends most on having the paragraph still in view.

None of this proves a specific number — neither of those papers measured an in-document, self-initiated lookup, and I am not going to borrow their effect sizes for a different task than the one they studied. What they establish is the mechanism: the reason the follow-up has to stay anchored is not a design preference, it is that the thing being asked about is also the cue the asking depends on.

5. 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.

There is a second cost to the gap that I only noticed because I lived inside it for months: the switching itself leaves a residue. Leroy's work on attention residue describes a measurable, lingering drag on performance of a resumed task after switching away from an unfinished one, driven by incomplete attentional disengagement from the task you left.⁵ Applied here: a reader who hits a term inside a PDF, where the tool is absent, has to consciously decide whether to break flow and go find the explainer elsewhere — and the moment of deciding that, even when the answer is "not worth it, keep reading," is itself a small tax on the sentence they are trying to hold in mind. An inconsistent tool does not fail gracefully to zero; it imposes a decision cost even in the readings where it is never invoked.

6. 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:

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.

7. 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.

One correction is owed here: an earlier internal description of this work claimed the current web surface already "feels like" the standalone product for returning users. Re-reading §6's own table against the shipped product shows that claim does not survive — the current surface is "summon, act" for a question you type, not "persist alongside" a selection you made. The claim is withdrawn here, plainly, because the whole argument of this paper is that honest gaps are worth more than comfortable ones.

8. 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.

9. Objections I take seriously

"This is one person's workflow, generalised." The strongest objection, and I have already conceded the shape of it in §1: everything here is first-person, sequential rather than controlled, and drawn from someone who was motivated to find the conversational design valuable because he had just built it. I do not have a way to rule out that I simply got better at using my own tool over time, and mistook practice for a property of the interface. §12 states the study that would settle it.

"A longer first answer would have done the same job, more simply than a follow-up turn." Worth taking seriously because it is cheaper to build. I think it fails for a reason §3 already supplies: the real question — "yes, but why does that apply here" — frequently cannot be anticipated by the system before the reader asks it, because it depends on which sentence the reader is actually confused by, not the word in isolation. A longer answer that tries to pre-empt every follow-up produces a wall of text nobody reads fully, which is a worse outcome than a short answer and a cheap second turn. But I have not tested a long-answer variant against the conversational one, and a fair reader should weight this objection accordingly.

"Admitting the product is not built yet undercuts the paper." It should undercut a pitch. It should not undercut an argument about mechanism, and §7 is written the way it is specifically so the paper's claims and the product's current state cannot be confused for each other. A design argument that is only credible while the product also happens to be finished is not a design argument; it is marketing with footnotes.

"Flux has a commercial interest in this conclusion." Flux sells AnswerTab, and this paper argues for exactly the design AnswerTab is trying to become. That is a real conflict and worth naming rather than disclaiming once in small print. The mitigation I can offer is in §7 and §8: this paper's most prominent claims are the ones most damaging to a sales pitch — the extension is gone and unrecoverable, the current product does not yet meet the paper's own bar, a pricing tier quietly became unsellable, and an earlier internal claim about how close the current build is had to be withdrawn once checked against this paper's own table. A paper written to sell the product would not include any of those four admissions.

10. What standalone has to be

Stated as commitments rather than features, so they can be checked:

1. Selection is the input. Wherever text can be selected, the explainer can be raised on it, with the surrounding context captured automatically.
2. The answer does not displace the source. Anchored, non-reflowing, dismissible without residue.
3. The thread persists and stays anchored. Follow-ups are free and remain attached to the original passage.
4. It is available everywhere reading happens, or it does not get to claim that you never have to leave.
5. 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.

11. 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. In my own use, the point at which I stopped trusting a one-shot version and started routing around it to a separate chat window was a matter of days, not months — fast enough that a team optimising the presentation first will ship something that fails for this reason before they find out why.

The presentation is what makes the product feel right. The follow-up is what makes it worth returning to.

12. What would falsify this

Stated as commitments, in decreasing order of how badly each would damage the paper's claim.

A controlled comparison finds no difference in comprehension, task completion, or voluntary return-to-tool rate between a one-shot inline explainer and a conversational one, for the same readers and the same passages. That contradicts the central claim directly — that the follow-up carries the value — and I would withdraw it rather than look for a narrower reading that survives.

A shipped standalone product that meets all five conditions in §10 fails to outperform the current gated web surface on retention or depth of use. That would mean the first-condition gap identified in §7 was not actually costing anything, and the coherence argument in §5 would need to be abandoned, not just qualified.

Someone ships a genuinely successful "continue in chat" affordance — one that does not measurably cost users the re-entry §4 predicts it should. That would falsify the anchoring argument specifically, while leaving the second-question finding in §3 intact; the two claims are separable and this would only take down the second.

A longer, pre-emptive first answer, tuned over time, closes most of the gap that a follow-up turn currently closes. That would not falsify the second-question observation, but it would falsify the design conclusion drawn from it — that the fix has to be conversational rather than written better.

13. What one person's workflow can't settle

The conversational design has not been validated against a one-shot design in any controlled sense. Every comparison in this paper is before-and-after, in one person, who built both versions.

The five commitments in §10 are not claimed to be sufficient — only that violating any one of them reproduces a failure already observed. There may be others not yet discovered, because the standalone product has not shipped long enough to surface them.

The argument does not generalise past reading, either. It is about explanations requested mid-document; it says nothing about conversational interfaces for tasks that are not interruptions of something else being read.

Nor does it resolve the tension named in §9, between an argument made in Flux's own commercial interest and an argument that happens to be true. That tension does not go away because it is stated. It is reduced, a little, by how much of this paper's content actively works against a sales pitch — and a reader should judge that reduction for themselves rather than take my word for its size.

Appendix A — Evidence table

Sourced rows are cited in the footnotes. The unverified rows are measurements this argument would benefit from and does not have; they are left empty rather than estimated.

Row 9 is the single measurement that would most directly connect this paper's companion mechanism claim to real numbers, and it is the same open row carried in The Panel Is Also a Tab's own Appendix B — no study in the literature I have found measures it.

Appendix B — Citation register

CITATION-NEEDED — comprehension/completion delta, one-shot vs. conversational in-place explainer. Appendix A row 8. This is the study specified in §12 as most damaging to the paper's thesis if it comes back null. It has not been run by the author or, as far as I can establish, by anyone else.

CITATION-NEEDED — resumption lag for a self-initiated in-document lookup. Appendix A row 9. Carried forward from the companion paper's own register rather than re-derived; the task-resumption literature cited in §4 measures externally imposed interruptions, not a lookup the reader chooses to make mid-sentence, and the two are not interchangeable without evidence that they behave the same way. The widely circulated "minutes to refocus" figure sometimes quoted for interruptions generally is not used anywhere in this paper because it was not measured under these conditions.

CITATION-NEEDED — standalone build vs. current gated web surface, retention and depth of use. Appendix A row 7. Cannot exist until the standalone product in §10 ships; flagged here so the comparison is specified before the product is built rather than fitted to whatever the product turns out to do.