Altamens

Altamens Research · Methods note · narrative evidence review

Before You Compare Reaction-Time Scores: A Measurement Checklist

A browser records a chain of events. A useful comparison starts by checking the task, device, response event and score summary.

Altamens7 min read

Abstract

A lower reaction-time score describes a shorter recorded interval on a particular task and setup. Interpreting that difference requires knowing where timing starts and stops, how trials are selected, and whether the comparison uses the same conditions. This methods note brings those questions into one practical checklist.

We connect primary timing research and the W3C timing specification with a source-code inspection of Altamens' current five-trial test. We collected no participant data, calibrated no hardware and estimated no training effect. The contribution is a comparison workflow and a downloadable blank record, not a new human experiment. This edition is published in English.

Key findings

  • Timer resolution, repeatability and physical timing accuracy answer different questions.
  • A device or input change deserves a separate comparison baseline.
  • A five-trial average describes that run; it does not establish a person's stable ability or an improvement threshold.

1What this review can answer

The question is practical: before comparing today's score with yesterday's, what needs to be comparable? We selected primary studies that measured browser presentation or response timing with external equipment, an author-hosted results table, and an official timing specification. We searched for online reaction-time timing accuracy, the timing mega-study, and realistic precision of online experiment platforms on 26 September 2026. This is a targeted narrative review, not a systematic search or meta-analysis.

Evidence dates matter. The experimental benchmarks below concern the software and hardware tested in their original studies. We use them to explain measurement questions; we do not rank today's browsers, estimate a universal phone penalty or reproduce those studies' results. Marketing percentiles and unverified latency corrections were not used.

2Follow the interval from software to response

The W3C High Resolution Time specification defines a monotonic clock suitable for elapsed-time measurement. It also permits reduced timer resolution for privacy and security. A timestamp from performance.now() is a software time reading: it does not itself verify when light changed on a screen or when a finger began moving. The version consulted here is a Working Draft, not a final recommendation.1

Figure 1A schematic timing chain
  1. Start timestampSoftware

    The program reads its clock and requests the ready state.

  2. Cue becomes visibleDisplay

    The screen presents the change; onset is not externally measured.

  3. Person respondsAction

    The person detects the cue and makes the instructed response.

  4. Input is deliveredEvent

    The input system and browser deliver the response event.

  5. End timestampSoftware

    The handler reads the clock and calculates the interval.

Conceptual stages for the inspected Altamens implementation, not measured delays. Display, human and input intervals are not separately estimated by the displayed score.

That chain makes the interpretation concrete. If the start timestamp precedes the visible cue, some of the recorded interval occurs before the person can respond. The end depends on which input event is recorded. A click handler and a physical button contact are different endpoints. Without an external reference, subtracting a guessed device delay would replace an unknown with an assumption.

3What the primary timing evidence contributes

Reimers and Stewart used external timing equipment to compare intended and recorded events across computer setups. Their design illustrates why a program timing its own events is not a complete test of screen-to-response accuracy. They also distinguish variability within a system from differences between systems. This is historical evidence about tested configurations, not a correction factor for current devices.2

The author-hosted online table accompanying Bridges and colleagues' timing mega-study reports response-time variability separately from lag. That distinction is central: measurements can cluster tightly while sharing an offset. We inspected the published table, not its raw runs, and do not claim a new replication or a present-day platform league table.3

Anwyl-Irvine and colleagues tested display timing and used a robot actuator to assess response recording across platforms and setups. Their findings support the feasibility of browser research while showing that no platform was best under every tested condition. Several authors declared commercial links to an experiment platform. Those affiliations and the historical versions limit a neutral buying recommendation, which this note does not offer.4

4A transparent example: Altamens' five-trial score

In the Altamens reaction-time test, the inspected implementation starts its clock immediately before requesting the ready state. An accepted click records the elapsed time, rounded to milliseconds. After five accepted trials, the saved score is the rounded arithmetic mean of those rounded intervals. The displayed best trial is a separate minimum. An early click triggers a retry and does not add an accepted interval.

These are implementation facts from the production source inspected on 26 September 2026. They are not observations of five people or evidence that five trials provide a reliable personal estimate. We found no external screen-onset measurement in this timing path. This review neither measured its hardware error nor changed its mechanics. The example explains what the number is; it does not certify laboratory equivalence.

5Eight checks before interpreting a difference

  1. Task: use the same test, cue, instructions and scoring version. Record an unknown version as unknown.
  2. Setup: record the device, display, operating system and browser. Treat a changed setup as a new comparison series until its comparability is established.
  3. Response: keep the same input method and action. A touchscreen tap, mouse click and keyboard response are not interchangeable measurement conditions.
  4. Session: note interruptions, backgrounded tabs and instruction changes. Keep these notes separate from explanations of why a score changed.
  5. Practice: distinguish familiarisation from recorded comparisons. Decide which runs count before seeing which are fastest.
  6. Trials: record accepted-trial count and any early responses or exclusions. A completed-run average does not reveal every failed or abandoned attempt.
  7. Summary: compare mean with mean, or another consistently defined statistic. Do not silently replace a run average with its fastest trial.
  8. Conclusion: describe the observed score change first. Leave its cause and the smallest meaningful personal change unresolved without suitable validation.

Our proposed decision rule is deliberately modest. If a task, setup or summary changed, label the comparison as changed conditions. If those details match, describe it as a within-setup comparison, while retaining uncertainty about practice, context and ordinary run-to-run variation. Matching details strengthens interpretability; it does not prove that training caused a change.

Download the blank comparison record (CSV) and methods and claim sheet (Markdown). These are a proposed documentation aid, not a validated instrument, participant dataset or medical record. No personal identifiers are needed.

6What stronger validation would require

A device-timing study would need an independent reference for visible cue onset and a known response, repeated on specified hardware, browser versions and input methods. It should report both systematic offset and variation, and document the event being timed. A personal-repeatability study is a different project: repeated human sessions with a defined sampling plan, trial rules and uncertainty analysis. Hardware calibration alone cannot establish personal repeatability.

For now, a useful statement is: my recorded average was lower in this run under these documented conditions. A claim about stable improvement needs repeated, suitably comparable observations; a claim that an intervention caused it needs a design that can address alternative explanations. This paper supplies neither a minimum useful trial count nor a threshold in milliseconds for genuine improvement.

7Limitations, provenance and review status

This note has no newly recruited participants, user records, trial dataset or simulated sample. Its sources concern measurement methods, not evidence that Altamens improves cognition, IQ, health or everyday performance. It does not establish age norms, population percentiles or diagnostic cutoffs. The checklist has not been empirically validated. Literature selection was targeted and can miss relevant work; browser and device behaviour can change.

Altamens publishes this note and operates the test discussed, creating a commercial interest. Research, drafting, source checks and publication preparation used an OpenAI automated assistant. No independent human methods review or journal peer review was performed. Altamens is the publisher label, not an invented institute or individual researcher. The downloadable methods sheet records the inspected source revision and claim provenance.

References

  1. 1.World Wide Web Consortium High Resolution Time, Working Draft, 1 September 2026. W3C, 2026. Sections 1 and 7.1; work in progress. Accessed 26 September 2026.. https://www.w3.org/TR/2026/WD-hr-time-3-20260901/
  2. 2.Reimers S, Stewart N Presentation and response timing accuracy in Adobe Flash and HTML5/JavaScript Web experiments. Behavior Research Methods 47, 309–327, 2015. https://link.springer.com/article/10.3758/s13428-014-0471-1
  3. 3.Bridges D, Pitiot A, MacAskill MR, Peirce JW The timing mega-study: comparing a range of experiment generators, both lab-based and online — author-hosted Table 3. PeerJ 8:e9414; table hosted by PsychoPy, 2020. DOI: 10.7717/peerj.9414. Published table inspected; raw data not reanalysed.. https://psychopy.org/timing/2020/table3.html
  4. 4.Anwyl-Irvine A, Dalmaijer ES, Hodges N, Evershed JK Realistic precision and accuracy of online experiment platforms, web browsers, and devices. Behavior Research Methods 53, 1407–1425, 2021. First published online 2 November 2020.. https://link.springer.com/article/10.3758/s13428-020-01501-5