Why a play should be data, not a picture

Most playbooks are pictures. A coach opens a whiteboard app, drags five circles and some arrows onto a court, exports a PNG, and drops it in a shared folder. It works — right up until you need that same play in a different form.

The problem with pictures

A picture answers exactly one question: what does this look like at the moment it was drawn. It cannot tell you the order the cuts happen in. It cannot show a player what the timing feels like. It cannot be renamed program-wide when you decide “Fist” is now “Chin”.

So programs end up with parallel copies. Varsity has one folder. JV has another, drawn by a different assistant, with different arrows. The youth progression is a Google Doc. Nothing is wrong with any of them individually, and none of them agree.

What changes when a play is structured

Store the same play as data — positions, actions, sequence, timing, reads — and every one of those problems becomes a rendering question instead of a re-drawing question.

• The diagram is one renderer.
• The animation is another, walking the same sequence over time.
• The practice sheet is a third, with the reads written out.
• The player’s phone is a fourth.

Change the underlying play once and all four update. Rename an action and every play that references it follows.

Where this actually pays off

The payoff is not the animation, which is the part everyone notices first. It is consistency across levels. When a sophomore comes up to varsity and hears the same terminology attached to the same action they learned two years earlier, you skip a month of teaching.

That is only possible if there is a single source of truth. A folder of PNGs cannot be one. Structured data can.