Interactive essays need state, not screenshots

An interactive essay earns its name when the reader can change the thing being explained.

A screenshot records one output. State exposes the relationship that produced it. Give the reader a parameter, an input, or a choice, and the explanation has to survive the resulting change.

The controls should be modest. A slider that changes the variable under discussion is useful. Six decorative toggles that do not alter the argument are interface noise. The current values should remain visible, and the essay should have a meaningful default state so a reader can understand the first result before experimenting.

There is also a useful test: can the reader return to an interesting state later? If the answer is no, the piece may be showing an animation rather than teaching a system.

maintenance is part of the choice

Interaction adds obligations that a static page does not have. Dependencies change. Layouts collapse on narrow screens. Keyboard and screen-reader users need a path through the controls. JavaScript can fail to load. A demo can become misleading when its initial data no longer matches the prose.

That cost is not an argument against interactive work. It is a reason to reserve it for ideas that need manipulation. If the concept is linear, write the explanation. If one image makes the relationship obvious, use the image. If a table is enough, use the table.

Build the interaction when the reader needs to probe the system. Then test the boring states as seriously as the impressive one: reset, invalid input, a small viewport, and a missing script.

the point

The strongest interactive essays make a claim that can be challenged. The prose says a parameter matters. The reader changes it. The system responds, including in ways that may complicate the explanation.

That exchange is the teaching mechanism. The reader is not admiring a captured result; they are checking whether the argument still works when the state changes.