Final project: a documented jsPsych prototype
Weight: 60 course points. Due: 14 days after Meeting 5, 23:59 Europe/Warsaw. Expected work: about 23 hours across design, implementation, testing, and revision. Work individually; acknowledge assistance.
Goal and scope
Build a small behavioral task whose code, instructions, design, and data agree. Choose a feasible question you can explain. A carefully tested two-condition task is sufficient. Mouse tracking, eye tracking, custom plugins, and complex statistics are not required for a high mark.
Your task must have understandable instructions, at least two meaningful conditions or trial categories, repeated trials with a justified order rule, explicit response handling, identifiable task rows, and a working data export/save path. Include practice where task understanding requires it; a simple rating task may justify omitting criterion practice. Match the response and inclusion rules to the task rather than copying them mechanically.
Choose a small teaching item set (typically 12-24 test trials) and justify the counts. It must exercise the design, not claim sufficient power for a research conclusion. Code may extend a class starter if the change is meaningful and documented. Repeating a reference solution without an adaptation does not demonstrate independent design.
Deliverables
- Runnable source package: HTML, JavaScript, dependencies, assets, and launch instructions. Include all required files; a hosted link alone is insufficient. Verify the archive on extraction into a fresh directory.
- Study README (800-1200 words): question and prediction; conditions/design; trial flow; responses and deadlines; randomization/allocation; expected data and filters; source/asset credits; limits; how to run locally and on the selected runner. Use the template.
- Data dictionary: define fields, types, allowed values, units, and missing-value behavior. Include task/block filters needed for summaries.
- Pilot evidence: small synthetic/self-test CSV and JSON, a hand-check of at least two rows, a completed pilot log, and one screenshot of the participant view. Mark generated/test data as such. Do not collect a research sample.
- Deployment evidence: a private classroom runner link where available, plus evidence that one complete pilot was retrieved from the runner and includes the final trial. If the instructor cannot provide a runner, submit a local reproducible package with the runner adaptation and an explicit untested-server checklist; this infrastructure fallback can earn full marks when agreed for the class.
- Change and assistance note: changes since the pilot; known limitations; third-party code and asset sources; AI/collaboration disclosure.
For the course, demonstration tasks should use non-sensitive stimuli and voluntary self/classroom testing. Real recruitment or personal-data collection needs the relevant institutional process beyond this coding assignment. A public site is not required; keep classroom pilot links private.
Rubric
| Criterion | Full-credit evidence | Points |
|---|---|---|
| Design and reasoning | Clear question, coherent manipulation and response, justified counts/order, realistic limitations | 12 |
| Implementation | All intended paths run; correct trial structure, mappings, conditions, and responses; suitable practice/branching | 15 |
| Data integrity | Complete labeled rows, correct scoring if relevant, missing-response handling, usable export and dictionary | 12 |
| Testing and reproducibility | Normal and edge cases, independent answer checks, fresh-extraction run, documented save verification | 9 |
| Participant experience | Readable instructions/layout, suitable assets/preload, clear completion/failure messages, accessible route where needed | 6 |
| Documentation and attribution | Clear README, sources, change log, assistance disclosure, deployment evidence or agreed fallback | 6 |
| Total | 60 |
Partial credit follows the assessment guide. A complex feature earns credit only if it supports the design and works. A null or reversed descriptive result is not a grading failure. Do not remove incorrect/slow observations merely to make an expected effect appear.
Final self-check
Can another student run the archive without asking you where files are? Can they explain what one row means? Can you show which trials enter your summary? Can you demonstrate what happens after no response and after a save failure? Can you name one methodological claim your prototype cannot support? If yes, you have addressed the central goals of the course.
Submit through the course website. This local copy is for reading and preparation.