InputProbe
Input device testers that publish their own measured error
Took the methodology out into the world this month: I posted the placement-error model to RTINGS’ test-methodology board, using their CPI article as the reference point. The basic result is that repeatability alone can’t catch a fixed offset because the same bias gets repeated every time.
Reading through their current methodology also taught me something: their actuator rig already publishes per-run spread. That changed the question I wanted to ask from “would you publish the spread?” to “how is the actuator’s traverse calibrated?”
That’s really the kind of conversation I want these tools to enable: methods criticizing methods, in public.
Next up: launch prep, then open-sourcing the polling estimator after launch.
Most online mouse testers measure your monitor, not your mouse: they count one movement per drawn frame, so a 1000 Hz mouse reads 60 on a 60 Hz display. I found this out by testing my own mouse and getting confidently wrong answers, and it annoyed me enough to build inputprobe.
The premise: browser hardware testers that behave like measurement instruments. Every tool reads raw device events instead of counting frames, publishes the accuracy band it was actually measured to have (results on A4 paper repeat within ~3%, on a bank card within ~6%), and refuses to print a number when the capture can't support one. The DPI test needs no ruler, it measures against objects exact by international standard; every bank card on earth is 85.60 mm long.
It's free: no accounts, no ads, nothing uploaded, everything client-side. The goal right now isn't revenue, it's earning the first 20–40 referring domains in six months against incumbents that rank on domain age with tools that measure the wrong thing.
Ask: if you've grown a free tool against entrenched SEO incumbents, what actually earned you your first real backlinks?
-
1
The unusual part is that the product is making uncertainty visible in a category where most tools appear to compete by presenting a single confident number.
That choice seems likely to shape how users perceive the product, especially when the market already has established answers people are accustomed to trusting.
-
1
You've put your finger on the exact bet. A single confident number is the better demo, it feels authoritative, it screenshots well, and nobody asks follow-up questions. The problem in this category is that the confident number is often measuring the wrong thing entirely (usually the monitor's refresh rate), and the user has no way to tell from the outside. Confidence and correctness are unrelated here, which is the worst possible version of that trade.
The wager is that the audience splits. Casual users may genuinely prefer the tool that says "800 DPI" full stop, I'll lose some of them and I've accepted that. But most people who go looking for a DPI test are there because something already feels wrong, their aim, a new mouse, a driver update. They've been burned by a confident answer once. For them, "548 DPI, three passes within 1.3%" answers the question they actually have, which is "can I act on this?"
Two design choices try to soften the perception cost: the median still leads (big number first, band second, so it reads as a result rather than a shrug) and when the tool refuses to print a number it always says why and what to change, so uncertainty arrives as instructions instead of doubt.
The precedent that gives me some hope: weather apps normalized "70% chance of rain" and nobody reads that as weakness. Categories can learn to treat visible uncertainty as competence, usually right after enough people get burned by false confidence.
Out of curiosity, when you first saw the error band, did you read it as credibility or as hedging? That first-impression read is the one thing I can't measure from inside.
-
1
That’s helpful context. I appreciate you unpacking the thinking behind it.
I’d like to continue this conversation outside the thread. What’s the best email to reach you on?
-
1
Glad it was useful. Happy to, you can reach me at contact[at]inputprobe. What did you have in mind? Asking mostly so I can point us at the right thing, and if any of it is useful to other people building in public, I'm equally glad to keep it here in the thread.
-
1
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
-
-
-
-
Comment