Show me what changed.

Imagine a tool that helps prepare a community theater program. Someone pastes in a cast list, adds the performance details, and asks it to tidy the copy.

The preview looks lovely. The names line up. The punctuation agrees with itself. Somewhere in that tidy block, a performer’s credit has changed from “music director” to “musical director.”

Perhaps that is a welcome correction. Perhaps it changes an approved credit. Looking at the finished page alone does not tell you that a decision needs attention.

A preview has a harder job than presenting the proposed result attractively. It needs to explain what the tool is asking permission to change.

For the imaginary program editor, I would put the original wording beside the proposed wording for each changed passage. Keep the surrounding line visible. “Director” in isolation is ambiguous; a name and its credit make the edit understandable.

A rendered page is still useful for checking layout. It should accompany the comparison rather than replace it. One view answers whether the program looks right. The other answers whether it still says what you intended.

Make the important edits easy to inspect

Not all changes deserve the same attention. Adjusting repeated spaces is different from changing a name, a role, or a performance time. Separate mechanical cleanup from edits that affect meaning, and make the latter easy to find.

If the tool cannot reliably distinguish them, say so and leave all changes available for review. A label such as “formatting only” is a promise about the edits, not a cheerful description of the feature.

Avoid relying on color alone to show additions and removals. Use clear labels and text that identifies what changed. Give someone reviewing with a keyboard a sensible way to move between edits and accept or reject them.

Bulk acceptance can be convenient for repeated spacing fixes. It should not conceal a rewritten credit inside that same action. A summary that says “twelve improvements” tells a person very little about what they are approving.

There is also value in showing what stayed untouched. If the request was to clean up cast credits, the performance dates should remain outside the proposed edit. Visible scope makes the review less like proofreading the whole program from scratch.

Keep approval attached to the version reviewed

Suppose someone opens the comparison and then changes the original cast list in another window. The preview now describes an older version. Applying it as though nothing changed would make the approval misleading.

Rebuild the comparison against the current text, or stop and explain that the original has changed. Let the person review the new proposal. The exact wording they approved matters more than the fact that they clicked an approval button earlier.

Try this deliberately while reviewing the design. Change a name after generating the preview. Include a credit that looks unusual but is intentional. Reject one suggestion and check that the rest remain understandable.

The comparison does not need to expose every internal processing step. It needs to show the consequence for the person’s work.

For the theater program, that means someone can notice the altered credit, keep the approved wording, and still accept the spacing fixes. A tidy page is welcome. A tidy page with the wrong credit on it is a different problem.