Plate II · StoryWeave · 2026

Problem and context

StoryWeave is a desktop workspace for long-form fiction, built with Electron, React, TipTap and TypeScript. When a model rewrites a whole paragraph or replaces text loosely, it breaks what the author set up earlier: foreshadowing, rhythm, a character’s voice. I owned the editing interaction and the pipeline that turns model output into suggestions the author can compare.

User validation: chat window versus in-editor suggestions

Three contracted serial authors, covering mystery, science fiction and fantasy, each made two plot adjustments to the same unfinished 2,000-word chapter, once in each of two ways:

• A: an ordinary chat window, copying text back and forth by hand;
• B: StoryWeave’s in-editor workbench with local diff suggestions.

One author did A first and two did B first, to offset the learning effect. We recorded time, clipboard actions and a 1–7 self-rating of authorial control.

An excerpt from P3, who has published two mystery novels and did B first:

• 14:06 — asks StoryWeave to “heighten the suspense in the dialogue, keep the pocket watch and the line about the third door”. It returns 11 local suggestions.
• 14:08 — accepts the first two and stops at the third: “‘His heart sank’ — no. That’s assembly-line web-novel phrasing; my protagonist wouldn’t react like that.” Rejects it.
• 14:10 — suggestion 6 replaces “pocket watch” with “wristwatch”. “I explicitly asked to keep the pocket watch.” Rejects it and goes back over the suggestions already accepted. From here on, P3 spends twice as long on each change.
• 14:14 — accepts part of suggestion 9, deleting the added modifiers and keeping the new word order: “The reordering fits the rhythm I wanted; the filler words break the context.”
• 14:19 — finishes B in 13 minutes, slower than the 9 minutes P3 then needed for A: “A was faster because the chat returned a whole paragraph and I replaced it without checking line by line. I’ll still have to rewrite that draft.”

Measure	A: chat window	B: StoryWeave
Completion time	2 of 3 authors were faster with A	2 of 3 authors were slower with B (P3: 13 vs 9 minutes)
Authors faster with B	—	1/3 (both slower authors did B first)
Clipboard copy-paste actions (median)	5	0
Authorial control, 1–7 (median)	4	6

B produced 64 suggestions: 29 accepted as they were, 11 accepted and then edited by hand, 24 rejected. Authors often kept a suggestion’s sentence structure and rejected its choice of words.

The result: StoryWeave was slower. The extra time bought zero copy-paste actions and a higher sense of control, a median of 6 against 4. Individual task times were not kept, so I do not report a median time.

Three findings changed the product:

• A change to a locked element broke trust in every later suggestion (3/3 authors ran into it; P3 slowed down sharply). Suggestions that touch a locked word are now dropped before they are shown.
• Authors wanted to accept part of a suggestion (11 of 64 were edited by hand after accepting). Each diff now offers “accept word order only” and “accept deletions only”.
• Model output drifted into web-novel clichés and translationese (3/3 authors raised it on the spot). This went into the offline evaluation below.

Evaluation: full rewrite versus minimal edit

To choose the default strategy, I built a test set from 30 real manuscript passages authorized by the three authors. Each passage was annotated in advance with elements that must not change: names, key objects and time markers.

Measure	Full rewrite	Minimal edit (local diff output)
Changes outside the selected range	4/30	0/30
Changes to protected elements	7/30	2/30
Edit size (changed / original characters, median)	0.41	0.18
Blind author preference	9 passages	17 passages (4 ties)

A sign test on 17 wins against 9 gives a two-sided p of about 0.17, which does not reach the threshold for a statistical difference. The claim that holds is narrower: minimal edits break protected elements less often. It does not show that every author prefers them. Both remaining violations swapped a locked element for a near-synonym, such as “pocket watch” becoming “watch”. We now run an exact string match before rendering, instead of relying on the model to comply.

Team decision: the “accept all” button

Beta authors asked for one-click “accept all”, and engineering agreed that clicking through each change was tiring. A 6-week beta with 11 active authors gave us numbers. “Accept all” ran 214 times and was undone within 10 minutes 47 times, an undo rate of 22%. Single accepts ran 930 times and were undone 118 times, 12.7%.

We kept the button and added a prompt before it runs: “12 edits will be applied; 3 involve names or numbers.” Engineers objected that this added friction, so we agreed a rollback line in advance: if use of “accept all” dropped by more than 50% in the two weeks after launch, the prompt would be removed.

In those two weeks, “accept all” ran 96 times, about 135% of the previous average of 71 per two weeks. Use did not drop, the rollback line was not triggered, and the undo rate fell from 22% to 11.5% (11/96).

Limits

Three authors is a small sample. The two who used StoryWeave first were still learning the interface, which may have made B look slower. Authorial control is a self-rating and may include some novelty effect.

What I would do differently

I would record per-person task times from the start, so the time comparison can be reported properly. I would also ship the protected-element filter before the first user test: a single pocket-watch replacement was enough to make P3 re-check every suggestion already accepted.