Correcting in a batch after writing costs more than confirming character by character; people tend to rely on the latter

What it is

Fixing recognition after a whole page is written means rebuilding context at every site: which word this is, what was meant, whether the ink is still in view. Glancing at a character as it is written, and swapping if it is wrong, keeps context in working memory and keeps the edit small. If post-editing only offers a “whole-page proof mode”, people either live with errors or want per-character confirm while writing—even though that belongs to the recognition loop, the demand leaks past commit.

Why it happens

Batch proofing costs locate + recall + act. Locate means finding a red or doubtful span in a long string; recall means matching ink or intent; act may still switch between keyboard and pen. Per-character confirm squeezes those three into the second after writing, gaze still in place. People empirically refuse the batch: when error density is high the page looks like homework, so they skip convert and archive as ink. If the system forces write-then-convert and forbids seeing results mid-way, batch becomes the only path and abandonment rises. Per-character confirm is not a tap of “OK” on every glyph—interrupt only on low confidence, pass high confidence silently, which is what “tend to rely on the latter” means. Batch still suits a later pass (a hand-in, a legal read), but it is an extra pass, not a substitute for the writing-time pass.

Studying it

Compare: results visible and editable mid-way, versus full text only after the page, then a proof list. Log time to correct, missed fixes, and choosing not to convert.

Independent variables: feedback timing (per character / whole page), interrupt threshold, whether the proof list previews ink. Dependent measures: total correction time, missed-fix rate, convert abandonment, “feels like homework”.

Where it stops holding

Copying from print, with intent on paper, a batch match-up can be faster. Near-perfect recognition drops batch cost and the preference can flip. Accessibility users who proof by keyboard read-through may prefer one pass. Live results that flicker disturb writing; per-character confirm must be stingy with interrupts.

Applying it

• Show editable results while writing; ask for confirm only at low confidence. Do not schedule the first sight of results after the whole page.
• Keep whole-page proof as a second pass with ink preview, not the only entry.
• Allow not converting, archiving as ink, so a proof wall cannot force people to clear errors.
• How to check: at the same error density, the mid-way-editable group should take less total time and miss fewer fixes than write-then-fix. Turn mid-way results off; convert abandonment should rise.

Related

• Same group: C5.15.1 Recognised text stays editable like typed text · C5.15.2 Keep ink–text correspondence to revert to the original · C5.15.4 Reflow after convert can wreck spatial layout
• Adjacent: C5.05 Handwriting Recognition and Correction · C5.14 Handwriting Recognition
• Search: batch correction · incremental confirm · proofreading cost