Good 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.
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.