Aim Throughput and Fitts's Law: How Fast Aiming Is Measured

A target blinks into existence. Your crosshair snaps across the screen, clicks it, and the next one is already up. It feels instant. It feels clean. But did you actually get faster this week, or did it just feel good? Your reaction time test answers a narrower question — how fast you respond to one cue — and it stays your cleanest baseline. Aiming asks for more: cross the distance, land on the target, and don't sail past it. To measure that, you need more than a stopwatch.

For a separate simple-response baseline, take the visual reaction test. Neither score alone establishes improvement in a game.

Aiming is a measured skill, not a vibe

Flicking to a target is the most-studied movement in motor science. In 1954, Paul Fitts showed that the time to hit a target follows a strikingly simple rule: the smaller and farther the target, the longer it takes — and the cost scales with the logarithm of the distance-to-size ratio, not the raw distance (Fitts, 1954). Decades later, that relationship was reframed in the language of information theory — aiming as a communication channel with a bitrate (MacKenzie, 1992). That "aim as a channel" idea is exactly how a flick can be scored.

What "aim throughput" actually measures

Throughput expresses a flick in bits per second: target difficulty divided by acquisition time. Flick Grid uses the configured, nominal target diameter in that difficulty calculation and averages throughput over hit targets. It does not estimate effective width from the spread of your clicks. Effective-width variants exist in the research literature, but they are not this implementation. Read the headline beside hit rate and the path breakdown; throughput alone does not summarize accuracy.

A single trajectory hides a lot of detail, and each piece is its own story:

Throughput is the headline; the breakdown tells you where the time went. Slow to start is a reaction problem, lots of corrections is a stopping problem, low precision is a control problem.

How to read your throughput

The number that matters is your throughput trending up over your own sessions. These training games have no validated benchmark bands yet, so there is no honest "good aim is X bits per second" line to print — and we won't invent one. Compare yourself to your past self and to players on similar hardware, then let the in-app score card show the exact figure. Your simple-RT bands live on the reaction time test; they don't transfer to an aim metric.

Because a training game puts your mouse, sensitivity, and monitor inside the score, it has more moving parts than the simple test, not fewer — which makes it richer to train and, honestly, noisier to measure. For the difference between raw reaction speed and aim execution, read reaction time vs aim speed. Flicking is only half of aiming — its moving-target cousin is tracking aim and time on target.

The honest limits

Path detail depends on the pointer samples the browser captures. The score card reports an estimated sample rate; sparse capture can miss movement and inflate the sampled path ratio above 100%. Flick Grid does not provide a metric confidence interval or widen one automatically when samples are sparse. Treat path breakdowns as coarse, same-setup feedback, not device-independent measurements. We timestamp the browser-observed stimulus and your event.timeStamp response — never a photon on your retina, a nerve firing, or a muscle contracting. This is a training tool with real telemetry, not a lab-grade instrument.

Want to put a number on your own flicks? Open Flick Grid setup, review the controls, and start deliberately. Compare like-for-like sessions rather than treating one higher score as evidence of game-performance gains.

Sources & context

Paul Fitts's original paper on the speed-accuracy law is Fitts, 1954, and the information-theoretic "throughput" reformulation used here is MacKenzie, 1992. Those studies use controlled apparatus, not a browser and a gaming mouse, so treat them as the model behind the metric, not a promise of a fixed number for your setup. The cursor path itself comes from the browser's pointer events (MDN documents getCoalescedEvents and Event.timeStamp). For how WiredReflex timestamps browser-observed events and explains timing limits, read how we measure. Those timing limits do not establish confidence intervals for aim throughput or path metrics.