Millisecond Forums

Methods to verify Subject ID with Inquisit Lab

https://forums.millisecond.com/Topic14385.aspx

By lakeside - 9/25/2014

Hi again,

Are there clever (or brute force) mechanisms available to ensure the respondent has entered a Subject ID that verifies against an external ID pool with Inquisit Lab? We are considering writing our own application that requests the Subject ID and Group ID, verifies them against those found in a database, and then passes the SID/GID to the command shell to open Inquisit. On a similar note, I noticed when we batch several tasks together, the user is prompted before every task for a SID/GID. As we want to link the NC data to survey data, this introduces a lot of opportunities for mistyped SIDs.

Thanks!
By Dave - 9/25/2014

> We are considering writing our own application that requests the Subject ID and Group ID, verifies them against those found in a
> database, and then passes the SID/GID to the command shell to open Inquisit.

Unless you include the entire list of valid SIDs/GIDs in the Inquisit script(s), that's the way to go. Inquisit scripts themselves have no way to query external databases.

> On a similar note, I noticed when we batch several tasks together, the user is prompted before every task for a SID/GID.

It's unclear what exactly "batch together" means here. When using Inquisit's own <batch> elements, users will be prompted for SID/GID only once -- same SID/GID will be used for all scripts administered by the <batch>.

Similarly, when batching scripts via command line scripts or the like, you will not be prompted for SID/GID if you include those properly as command line parameters (see the "How to Launch Inquisit Using Command Line Parameters" topic in the documentation for details).
By lakeside - 9/26/2014

Unless you include the entire list of valid SIDs/GIDs in the Inquisit script(s), that's the way to go. Inquisit scripts themselves have no way to query external databases.


Can you expand a bit on this approach? Looking at the available operators, the only solution I can think of would be an IF statement for each valid Subject ID which runs the experiment when a match with scrip.subjectID is found. At the end of these IF statements would be an ELSE statement that would bring another pop-up window asking the respondent to re-enter their Subject ID.
By Dave - 9/26/2014

That would be one way to do it. I'd probably prefer a different approach using string functions (see the functions reference in the documentation). Simple example:

<values>
/ validsids = "Alice,Bob,"
</values>

<expt>
/ stop = [!contains(values.validsids,script.subjectid)]
/ blocks = [1=myblock]
</expt>

<block myblock>
/ trials = [1=mytrial]
</block>

<trial mytrial>
/ stimulusframes = [1=mytext]
/ validresponse = (57)
</trial>

<text mytext>
/items = ("Blurb...")
</text>

In the real world, you'll need more elaborate / robust  validation logic, but you get the idea.
By seandr - 9/26/2014

Note that if you put the validation in the script, the script will just abort if the subject ID isn't found in the list rather than prompting the participant to enter their ID again.

Another approach would be to create an Inquisit <batch> script that launches the set of scripts as Dave suggested, and write a simple external app that handles entering and validating the subject ID and then launches Inquisit from the command line, passing the ID and the path to the <batch> script.

Also note that you'll need to pass a Group ID to the command line to avoid Inquisit's prompt. In some scripts, the group ID is used for counterbalancing, in others it isn't used at all. If your scripts don't use it, you can just set it to "1" or any other number. If some of the scripts do use it, you can change them to randomly assign by setting / groupassignment = random on the <expt> and <batch> elements. Or, you could also have the external launching application assign the group.

-Sean