You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is having the changeable stuff be a list of arguments scaleable → maybe just like the plugins some functions need to be called and those will have their own standard versions too → have to find some way to make these all easily readible + comprehensive + transparent to users → just docs or embedded in the code too
(submodules) what the classification structure looks like: could you nest modules like have a general template for traditional memory vs visual perception experiments; or would the grouping be more at the level of required functionality → what kinds of "display" or interaction each experiment needs, like experiments that need users to focus on different parts of screen thru clicking on different zones vs answering questions (but thats kinda handled by the existing plugins); or just simply each experiment is a single unit and they're all at the same flat level ungrouped
this might just be me but i think another reason why it feels icky to do it very similarly to how importing e.g. a jsPsychHtmlKeyboardResponse is that there's 1) more stuff happening in a timeline (within it contains jsPsychHtmlKeyboardResponse instances, spans multiple pages etc.) and 2) the nature of it is more sequential → it contains info of a whole experiment procedure whereas something like jsPsychHtmlKeyboardResponse means one thing: display an html script that interacts with user keyboard; so as a user I would wanna understand the general flow of the timeline im importing conceptually when im tweaking its parameters, which i dont think is captured by the way the importing works now. i guess this can the burden of clear documentation but i also feel like the code should roughly stand on its own in this way..?
Make a tree of what the common parameters across experiments look like
The text was updated successfully, but these errors were encountered:
Is having the changeable stuff be a list of arguments scaleable → maybe just like the plugins some functions need to be called and those will have their own standard versions too → have to find some way to make these all easily readible + comprehensive + transparent to users → just docs or embedded in the code too
(submodules) what the classification structure looks like: could you nest modules like have a general template for traditional memory vs visual perception experiments; or would the grouping be more at the level of required functionality → what kinds of "display" or interaction each experiment needs, like experiments that need users to focus on different parts of screen thru clicking on different zones vs answering questions (but thats kinda handled by the existing plugins); or just simply each experiment is a single unit and they're all at the same flat level ungrouped
this might just be me but i think another reason why it feels icky to do it very similarly to how importing e.g. a jsPsychHtmlKeyboardResponse is that there's 1) more stuff happening in a timeline (within it contains jsPsychHtmlKeyboardResponse instances, spans multiple pages etc.) and 2) the nature of it is more sequential → it contains info of a whole experiment procedure whereas something like jsPsychHtmlKeyboardResponse means one thing: display an html script that interacts with user keyboard; so as a user I would wanna understand the general flow of the timeline im importing conceptually when im tweaking its parameters, which i dont think is captured by the way the importing works now. i guess this can the burden of clear documentation but i also feel like the code should roughly stand on its own in this way..?
Make a tree of what the common parameters across experiments look like
The text was updated successfully, but these errors were encountered: