Extend plugin architecture to better handle data-generating overlays
See original GitHub issueThis is for things like eye-tracking, mouse-tracking, and mouse-view features, which all aren’t standard ‘trials’ like other plugins, but instead involve additional code and data collection on top of ‘normal’ jsPsych trials. Once one of these ‘overlay’ features is initiated during an experiment, it should be able to run arbitrary code in response to trial events (on_start, on_finish etc.) and save its own data to the trial data. This way, any arbitrary code that is needed in response to trial events can be handled in the overlay feature’s code, rather than requiring the researcher to add anything to the trial’s event-related callback functions.
Here’s an example of what the trial definition might look like:
var trial = {
type: 'image-button-response',
...,
extensions: ['mouse-view']
}
Note that we probably wouldn’t be able to guarantee that plugin overlay extensions don’t interfere with one another, so it might be risky to allow multiple extensions on the same trial. If multiple extensions are allowed, then we should probably at least warn the user about this.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (3 by maintainers)
You may want to look into MediaWiki’s solution which uses hooks. It’s very similar to Josh’s solution, but the event handlers would pass an object (probably
plugin.trials
) back and forth tocore
which extensions can use to prevent collisions through locks.I’m looking into designing a web-based eye tracking study using WebGazer. I can’t guarantee any code since the project is still in planning, but I can report back with ideas for how to support that workflow.
Got it, thanks for the update @jodeleeuw !