Session 13 — Reaction Time Test (Touch-Based)

M4 — Test Development April–May 2026 @default

What I Did

Built the Reaction Time Test using touch events. 10 rounds: a visual prompt appears, user taps as fast as possible, time from prompt to tap is measured in milliseconds. Clean, simple, aligned to GAME_STANDARD from the start. No camera, no microphone — touch events are the right tool for measuring response latency.

AI Interactions

Built the test with Claude. The architecture was clean because GAME_STANDARD was already in place. The main implementation question was precision: how to measure reaction time to the millisecond accurately.

Used performance.now() for millisecond-precise timing — records the timestamp when the visual prompt appears, and calculates delta when the touch event fires. This is the same approach used in the Session 2 Reaction Time prototype, now implemented properly in the GAME_STANDARD architecture.

@default — Touch Over Camera for Reaction Time

The obvious tool for reaction time is touch events — direct, low-latency, no preprocessing required. Camera-based reaction detection would add ~16ms of MediaPipe inference latency to every measurement, which is significant when you're measuring human reaction times in the 200–700ms range. Touch events are the right choice here. I noticed I reached for this without much deliberation — which is fine, but worth noting as a default assumption.

What I Learned

Sensor choice determines measurement precision. Touch events: ~1ms precision, direct measurement. Camera-based detection: ~16–20ms precision, indirect measurement. For reaction time, 16ms of latency is ~5% of the measurement range — that's a meaningful source of error to avoid.

The right tool isn't always the most technically impressive one. Touch events are boring. They're also exactly right for this measurement.

Quarter Question Connection

The Reaction Time Test uses the most mundane everyday device input — a tap on a screen — to measure something clinically meaningful: visual response latency. The simplicity of the input is the point. "Everyday devices" doesn't mean complex inputs; it means using what's already there, chosen for the measurement it enables.

What's Next

Bilateral Coordination Test refinements. Ensure the breaking/stretch test plan stresses the bilateral aspect specifically, not just hand tracking generally.

← Session 12 Session 14 →