A visual reaction-time test looks simple: wait for a cue, respond, and display a duration. For a frontend developer, the more interesting problem is defining which input is valid in each state.
I run Reaction Time Test, a browser-based tool with a five-round visual test and additional clicking, memory and aiming activities. This article describes a general design approach for similar interfaces; it is not a claim about the site's private implementation.
Define the states before the timer
Start with five named states: idle, waiting, ready, result and finished. In idle, the user can begin. Waiting accepts an early-response outcome but does not accept a valid score. Ready accepts the first valid response. Result shows the recorded attempt and offers the next round. Finished shows the complete session.
The important design rule is that one input should cause one transition. Once a valid response has moved the interface from ready to result, a second rapid input should not append another attempt.
Handle reset as a real transition
A reset should clear both the displayed results and any pending work that could reveal the cue later. Consider this sequence in your manual checks: begin a round, reset before the cue, then wait. An old callback should not turn a fresh idle screen into a ready screen.
A useful implementation technique is to give each round a generation identifier. A pending callback checks whether it still belongs to the current round before changing state. This is a design suggestion, not a substitute for reviewing how your own callbacks are scheduled and cancelled.
Separate a timestamp from a physical measurement
MDN's performance.now() reference documents a monotonic timestamp in milliseconds. It is useful for measuring an interval within a page. Choosing a high-resolution clock alone does not demonstrate that a website measures the full physical delay between a visible change and a person's movement. Keep product claims aligned with what your implementation actually measures.
Make the results inspectable
Store each valid attempt before computing a session summary. Show the average and the fastest attempt with clear labels, and retain the individual values so the user can inspect variation. Decide what happens to early responses and interrupted rounds instead of silently treating them as ordinary results.
A compact manual review
Try an early input, two rapid inputs after the cue, reset during waiting, reset after a result, and a full session from start to finish. Check the expected state and attempt count after each step. Also record the input event you intend to support so mouse and touch behavior have a deliberate definition.
Small interactive tools benefit from explicit transitions because the edge cases are easier to discuss. A clean result screen is helpful, but a clean definition of a valid attempt is what makes that result understandable.
Disclosure: written with AI assistance for the website owner.
Top comments (0)