Couple Lesson Video Playback to the Move a Learner Is Solving

A lesson video that plays straight through teaches at the video's pace, not the learner's. So on a chess learning platform we stopped letting the video run end to end. We linked admin-uploaded lessons to puzzle moves, and let the move the learner is on decide what plays. The frontend then shows progress from the linkage between video and puzzle — not from a playback bar ticking on its own.

The argument is small and, we think, general: couple the media to the interaction. Tie what a learner watches to what they are actively solving, and the video stops being a lecture playing in the background and becomes part of the exercise.

The platform already had two good things that didn't talk to each other. Admins could upload video lessons. Learners could work through puzzles move by move. But the video was just a video: it played from start to finish on its own timeline, and the puzzle sat next to it on a separate one.

That split creates passive watching. A learner presses play, the lesson runs ahead of where they actually are in the puzzle, and the "solving" turns into "watching someone else solve." The two most valuable moments — the move the learner is deciding on, and the explanation of that move — were never aligned. The video would explain move four while the learner was still stuck on move two, or spoil move two before the learner had a chance to find it.

The cost is engagement that looks fine and teaches poorly. Watch time goes up. Understanding doesn't. A learner can finish a lesson video without ever having their own move be the thing that moved the lesson forward.

The obvious fix is better controls: chapter markers, a scrubber, "jump to the next tip." Let the learner manually line the video up with where they are.

That fails for the same reason the original setup failed — it keeps the two timelines separate and asks the learner to reconcile them by hand. Now the learner has a third job on top of reading the board and choosing a move: babysitting a video player. Manual sync is still passive; it just adds friction. And it breaks constantly, because the moment the learner makes a move the board changes and any manual alignment they set up is stale.

The other tempting fix is to autoplay the right clip and hope the pacing matches. But a video has no idea which move the learner is on. Pacing that is right for one learner is a spoiler for a fast one and a lag for a slow one. Guessing at the learner's position from a clock never matches the actual position on the board.

The constraint underneath both dead-ends: the video's timeline and the learner's progress are different things, and no amount of player UI makes one follow the other. Something has to make the board the source of truth.

We linked video to moves. An admin uploading a lesson associates segments of that video with specific moves in a puzzle. That linkage — this move maps to this stretch of video — is the whole feature.

Once the link exists, we invert who is in charge. The video no longer plays straight through on its own clock. The move the learner is on controls playback. When the learner is deciding a move, the segment tied to that move is what's available; when they make the move and advance, playback advances with them. The board drives the video, not the reverse.

The tradeoff we accepted: this only works for content an admin has taken the time to link. A video that isn't linked to moves is just a video again. We chose that deliberately — the value comes entirely from the coupling, so we made the coupling something a human authors on purpose rather than something we try to infer automatically.

Three pieces:

• The link. Admins upload a lesson and attach video segments to puzzle moves. Each link says: this move corresponds to this part of the video. This is the data that ties the two timelines together.
• Move-driven playback. The frontend tracks which move the learner is on. Instead of running the video on its own timeline, it plays the segment linked to the current move. Advancing to the next move is what advances playback to the next segment. The learner's action is the transport control.
• Progress from the linkage. The progress the frontend shows is computed from the video-to-puzzle linkage, not from raw seconds played. Progress means "how far through the linked moves have you gone," so a filling progress indicator reflects real advancement through the exercise rather than time spent watching.

Put together: the learner faces a move, the linked explanation is what plays, they solve, and solving is what moves the lesson forward. Watching and solving become the same loop instead of two loops running side by side.

The surprise was how much the mental model had to flip on the frontend. Our instinct — everyone's instinct — is that a video is a thing that plays, and progress is how far it has played. That assumption is baked into every player component you've ever used. Here it's wrong. Progress is a property of the puzzle-video linkage, not of playback. We had to stop asking the player "how far are you" and start asking the linkage "how many linked moves are done." Anywhere we let the old assumption leak back in, the progress indicator drifted out of step with the board.

The change is qualitative, and we'll report it as such rather than invent a number we didn't measure. What changed is the shape of the interaction: playback is now controlled by the move the learner is on instead of running end to end, and the progress the frontend shows comes from the video-to-puzzle linkage instead of the playback clock. Watching and solving are one loop. A learner can no longer finish a lesson passively, because the only way to move the video forward is to make the next move themselves.

That's the outcome we were after — not more watch time, but watching that is welded to solving.

• Couple the media to the interaction. When a learner is doing something, tie what they watch to what they're doing. Media on its own timeline teaches at its pace, not theirs.
• Make the interaction the transport control. Don't add player UI and ask the learner to sync it by hand — let their action (the move) drive playback. Manual sync is just passive watching with extra chores.
• Define progress by the coupling, not the clock. If watching is meant to serve solving, measure progress by how far through the task the learner is, not by seconds played. The two will otherwise drift apart.
• Put the control where the authoring is. The feature's value came from links a human makes on purpose. Choosing authored coupling over inferred pacing kept the quality in the right hands.
• It generalizes past chess. Any place a lesson video sits next to an interactive task — a tutorial beside an editor, a walkthrough beside a form — the same move applies: let the task the learner is on decide what plays.