mvpt_figure1[1]

Multiple Stimuli

In the QRTEngine it is possible to display multiple stimuli at the same time, even though the default behaviour is that of only showing one stimulus at a time. The aim of this tutorial is to show exactly how to do that and how to handle the complexities that arise from this (which aren’t that many). We’ll do this by implementing a cued go/no-go task, which will, next to multiple stimuli on a single page, also feature conditional stimuli and show a way to implement go/no-go tasks concurrently.

All required files, the .qsf task file and the trial data spreadsheet can be found in the following Google Docs folder: Tutorial – Multiple Stimuli No-Go. It is recommended to import the .qsf file found in the google docs folder, so that you can check out the set-up of the task while reading this tutorial.

Task set-up

Since we mainly care about displaying multiple stimuli, the task will be based off the QRTE Skeleton Task, which can be found here. This task, as you may or may not know, is a Flanker task, which can easily be adjusted to feature as a go/no-go task.

The paradigm will look something like this for go trials:

Go trial: Start Fixation ( + )  -> Cue ( <<><< ), 2000 ms-> Feedback ( Correct/Incorrect ), 1000 ms -> End Fixation ( +)

For no-go trials, we will display the cue as is normal for flanker tasks, but then with a 300 ms delay, we will display a red X underneath it, which tells respondent NOT to respond, regardless of what the correct response would be for the Cue. So a no-go trial would look like this:

No-go trial: Start Fixation ( + )  -> Cue ( <<><< ), 2000 ms; 500 ms delay No-go Cue ( X )-> Feedback ( Correct/Incorrect ), 1000 ms -> End Fixation ( +)

We have two different types of trials, but our trialData doesnt allow us to distinguish between those two types yet. For this reason, a fourth column has been added to the Loop & Merge data of the standard skeleton task, letting the system know whether it is a no-go (value == 1) or go (value == 0) task.

Adding Stimuli

As the Engine goes through the list of stimuli available to it, it assumes that each stimulus has to be displayed on its own, on a single page.  That assumption however, is false for this specific task (and also many others).  For that reason, a parameter for the Stimulus has been defined that specifically counteracts this one stimulus per page behaviour, which can be added to questions tagged as Stimulus. If the parameter ‘stimContinue’ is set to true (defaults to false), the Engine will scan for another stimulus, unless the end of the trial has been reached (the so-called Exit stimulus). For more information on stimContinue and other Stimulus parameters, please check this tutorial: .

Cue

As we want the to be displayed after (or beneath) our cue, we have to let the QRTEngine continue upon finding the Cue, and close off the page after the X stimulus. Only a slight change in the JavaScript associated with the Cue is necessary, which will make it look like this:

 

CueNoGo

As can be seen from the trial set-up above, only one stimulus has been added, a red X.  The red X id is CueNoGo and contains the following JavaScript:

 

It uses a conditional to check whether the current trial is a no-go trial or not, if yes, this stimulus is displayed. There is a tutorial on conditionals available <here> for those who would like to know more.

Considering we want to display the CueNoGo stimulus with a slight delay (300 ms), we add the following line to the Init JavaScript in the OnLoadFn function:

QRTE.setConfig("CueNoGo", "delay", 300);

No other JavaScript needs to be added to the Init question, but the following line is good to have, just to store the information from the fourth column:

QRTE.setTrialData('isNoGo','${lm://Field/4}');

Bonus

We have shown how to easily display multiple stimuli on a single page.  By adding an extra parameter controlling the behaviour of the Engine as it loops over each stimulus, we have generated a powerful and flexible way of displaying any amount of stimuli on a single page.

However! One key part is missing, which falls somewhat outside of the scope of this tutorial, but is a part that I simply can’t leave out. How do we check for no keys having been pressed, all the while keeping the correct/incorrect responses on go trials in tact? We can do it through some JavaScript (hopefully soon no longer to be) magic!

Cue JavaScript

You might have noticed that the JavaScript for the Cue Stimulus in the Task advertised up top looks slightly different from the JavaScript in this tutorial. This is because the extra JS checks and stores correct responses to no-go trials. The full JS (the one in the actual task has some explanatory comments interspersed with the code and also nicer make-up):

 

Let’s break it down. First off, note that a new parameter has been added to the Stimulus, onHideFn. It defines a function that should be called upon the Stimulus in question being hidden, or rather, any code contained in the onHideFn is ran upon the stimulus being hidden. The perfect moment to check whether a response has happened at all! Because regardless of the type of trial, stimuli have to be hidden at some point. If you’d like to learn more about specifics of Stimulus parameters, (including onHideFn and onShowFn) please read the following guide: On QRTEngine JavaScript, part 2: Stimuli

How do we know if the current trial is a no-go trial? Think back to our trialData set up, the fourth column contained whether this trial was a no-go (value == 1) or a go trial. The following line checks exactly that.

if ( '${lm://Field/4}' === '1' )

Qualtrics ends up replacing ‘${lm://Field/4}’ with ‘1’, or ‘0’, depending on the value of the fourth L&M field column and it’ll resolve to true or false when run. If true, the following line is ran:

if ( QRTE.getTrialData(ele.userId + '[RT]') === '')

For most, the major problem will be ‘how to check for non-responses?’. That is exactly what the preceding line does. By Default, RT (or Reaction Time) of a stimulus is set to ” (the empty string), because no reaction has been given, no reaction time can be calculated. This allows us to check whether any allowable key has been pressed, and thus we can determine whether the no-go trial was correctly *not* responded to, which is exactly what the following lines do. If RT === ”, then set the accuracy to 1, if not, set it to 0.

Conclusion

that concludes the tutorial on how to display multiple stimuli on a single page, and also how to build a go/no-go task with the QRTEngine.