Meeting 5 reference: Pointer measurements and deployment
What you should be able to do
Four-decision pointer pilot, a verified local save, and a project completion plan. Explain the logic and verify at least one normal and one edge case, using the actual saved data.
Concepts in context
An extension is registered at jsPsych initialization, then enabled on the trials that need it. Tracking only the decision avoids confusing the return-to-start movement with the decision trajectory. The supplied center Start button standardizes the starting action before every item; it does not guarantee identical physical hand position or device behavior.
The mouse extension stores event coordinates relative to the viewport and event times relative to the tracked trial. Target rectangles make the coordinates interpretable. We explicitly request mousemove, mousedown, and mouseup; the default is only movement. A minimum sample interval limits event density but does not create a regular sampling clock. A stationary pointer can produce no movement samples, and the click that ends a trial may mean not every release event is captured.
Buttons record zero-based numeric indices. Compare response to correct_choice, not to a key string. Keep word, category, item, viewport, and target geometry with the trajectory. JSON is the primary teaching format for nested event arrays. Coordinates alone do not establish gaze, mental conflict, or a validated psychological measure.
The local completion panel downloads results on the current computer. For JATOS, the exported entry page loads jatos.js, starts inside onLoad, and calls startNextComponent with the result JSON in on_finish. This sends the final data and advances or finishes the study. Cognition handles saving through its platform workflow. Students do not implement custom retry or upload interfaces. Retrieve a complete pilot in the actual platform before distributing the task.
Cognition.run uses its own platform workflow. Do not assume JATOS-specific code applies there. Whichever runner is used, retrieve the saved pilot and check the final trial rather than relying on a finished screen.
WebGazer is optional methodological literacy: initialization, calibration, validation, and a justified task. Community extensions need checks of compatibility, permissions, units, and measurement quality. Neither is required for a strong final project.
What to check in your implementation
Four pointer-start rows and four decision rows in the workshop, plus instructions and summary (10 total). The live demo has one of each (4 total). Correct choice is 0 for cat/oak and 1 for hammer/lamp. Empty movement data is possible without motion; target metadata should still exist.
Use the live exercises and workshop sheet as the practical sequence. Compare with the released reference solution after an attempt. The debugging guide provides a symptom-to-check table. Try one editable example and its practice check before the full task.
Questions to answer without copying the code
- Does minimum_sample_time=16 guarantee 62.5 Hz?
- What proves the researcher received results?
- Does calibration validate webcam gaze?
Check your reasoning by running a small example; the instructor guide contains the expected explanations.
Reading (about 15 minutes)
Read mouse tracking and the course deployment guide. Optional: eye-tracking workflow and the two local extension worksheets.
Preparation for the next checkpoint
Explain local download versus submission versus confirmed stored result; state your next project fix. See assessment and deadlines.