5 ms·
Confirmed, much cleaner now — thanks again. Quick context since you clearly care about getting this right: this test is part of a bigger project, training a bo
by zefparis 1mo ago
Confirmed, much cleaner now — thanks again.
Quick context since you clearly care about getting this right: this test is part of a bigger project, training a bot-detection model that currently has 22k+ verified bot sessions but only a handful of real human ones. Classic data-starvation problem: the model knows what a bot looks like, barely knows what a human looks like. Every real person who plays through honestly (like you did, bugs and all) helps balance that out.
Appreciate you taking it seriously enough to actually find the rough edges.
- gus_massa 1mo agoA few more comments: In the last test, 1->2->3->4->5 the lines are not aligned with the dots. Are you tracking the mouse? In the yes/no test I move the mouse to the correct position before the buttons appear.
- zefparis 1mo agoGood catch again, found it and fixed: the node dots were positioned by their top-left corner instead of centered, so the connecting lines were terminating ~24px off from the visual center of each dot. Just shipped a one-line CSS fix (missing transform: translate(-50%, -50%), dots and lines should now line up correctly. On the mouse tracking: no, free cursor movement isn't tracked at all, the only pointer data captured is during active drag (touch/click-held), not hover position. So your pre-positioning isn't logged as a signal one way or the other. Fair UX point though: the buttons always render in the same fixed left/right position, so a user who's learned the layout can anticipate it. For this specific test the display window is long enough (2s) that it shouldn't meaningfully skew results, but it's a reasonable thing to randomize in a future pass. Really appreciate the depth here,three rounds of testing and you've caught two real bugs and one solid UX observation.