Enhancements of the session parameter GUI

[pedmiston]

Current defaults for the session parameters are:

• session name (does not need to be unique; saved in the session variables)
• session code (must be a unique code; generates a session folder of the same name (if specified))
• (user defined params) (with syntax for check boxes and drop down boxes)

There may be a bit of redundancy here, as each new run of the experiment requires a unique code, but there is no way to unite two subsequent runs of the same participant. A parsimonious solution, at least in my lab, would be to include the following:

• session id (using new terminology just to distinguish it from name / code above)
• (user defined params) (...)

where "session id" was a string identifier of an individual participant. Instead of preventing duplicate session codes as above, a duplicate session id should pop up a simple dialogue identifying that the session id has already been used, and asking to continue or cancel/return to the GUI to enter a new session id.

Purposefully duplicating a session id could be used if something happens halfway through data collection and the experiment must be exited and restarted, or if an experiment is run at two different time points. The point would be to allow a participant identifier (session id) to link the two sets of data, and some internally generated index, to separate the runs.

Example ioDataStore representation: sessionID run data cols SUBJ1 1 1.234... SUBJ1 1 3.231... SUBJ1 2 2.342... # data is linked by sessionID, but separated by run SUBJ1 2 4.239...

The goal is largely to prevent more session id's (or session codes, from before) from being generated than are actually needed to represent the "number" of people. I don't think the run param needs to be handled by the user. In the case of running the same study at two time points, an additional userParam could be specified:

sessionID run userParam1 data cols SUBJ1 1 test1 1.234... SUBJ1 1 test1 3.231... ... SUBJ2 2 test1 5.241... SUBJ2 2 test1 6.234... ... SUBJ1 3 test2 2.342... SUBJ1 3 test2 4.239...

Again, these comments are biased by my own research approach so I'm sure there are many alternatives, but I imagine some others may benefit from this technique as well.

[isolver]

What if session name was used for what you are suggesting a session_id do. That way, no new field are added, it gives more of a 'purpose' to having the name and the code fields, and the check before duplicating logic could be added to the field as you have suggested. It could be an optional check defined by an experiment param maybe.

What do you think?

[pedmiston]

Seems reasonable to me. So we would essentially replace the existing fields for session name (no requirement for uniqueness) and session code (uniqueness required) with a single field for session name (uniqueness is checked and prompted; if non-unique, can continue or enter a new session name)? …………………… Pierce Edmiston [email protected] sapir.psych.wisc.edu

On Apr 14, 2013, at 3:28 PM, Sol Simpson wrote:

What if session name was used for what you are suggesting a session_id do. That way, no new field are added, it gives more of a 'purpose' to having the name and the code fields, and the check before duplicating logic could be added to the field as you have suggested. It could be an optional check defined by an experiment param maybe.

What do you think?

— Reply to this email directly or view it on GitHub.