Today we are going to program a simple categorisation Experiment based on the design reported in Spiering & Ashby (2008). The most important difference between this type of task, and the choice task you programmed last week, is that participants recieve feedback on some trials about whether they were correct or not. In the type of categorisation task we will program, there will be a training phase, where participants see feedback after every trial about whether they made the correct categorisation, and a transfer phase, where no feedback is given.
The second feature from Spiering and Ashby (2008) that is novel, is that we will need to program multiple conditions into our Experiment as participants experienced 1 of 3 different training phases. By the end of today you should know how to:
If you are quick you will also learn how to:
We are going to simplify the design of Spiering and Ashby (2008) in several ways. Firstly, we are going to present each stimuli only once in the training phase and once in the transfer phase (rather than 15 and 5 times respectively). Secondly our version will only have the two ordered presentation conditions (i.e. easy-medium-hard and hard-medium-easy), without the mixed/random presentation condition. Thirdly, we will provide written feedback after responses, rather than audio feedback.
Like last week we are going to start a new Inquisit file for this weeks exercises. Call this file surname_wpa3.iqx. This is the file you will send me at the end of the class. I strongly recommend that you copy the defaults element from last weeks script into the top of this file, so that you have an easy way to terminate the Experiment.
Furthermore, I recommend keeping your wpa file from last week open, as it may be useful to check code from last week or copy segments.
In Spiering & Ashby (2008), they used sine-wave grating images as their stimuli. Inquisit has no means of natively generating these stimuli. However, what you can do in Inquisit is specify image files as your stimuli. To use pre-made image files as our stimuli we will need to use 2 elements in Inquisit, the item element, which we used last week for our text stimuli, and the picture element, which performs a similar function as the text element from last week.
Firstly we need to have some image files to use our our stimuli. I’ve stored 30 image files matching the 30 images used by Spiering & Ashby (2008), in the dropbox folder we used in week 1. The images are .png files stored in the week3stim subfolder.
Just like we used the item element to define our text strings last week, we can use the item element this week to load our image files. The way we do this is by specifying the filepath for each image, where we specified the text string last week. This filepath is from the location your Inquisit script is saved in. So if your image files are saved in the same location as your .iqx file you just have to give the file name. For example:
<item example>/1=“patch1.png”/2=“patch2.png”`
Last week we had a single item element. How many elements do you need this week? If you remember the paper, in our sine-wave gratings we have two categories of stimuli, category A and category B and 3 levels of stimuli difficult, Hard, Medium and Easy.
When trying to decide how to place these stimuli into item elements you need to think about how you want to present them in the Experiment (i.e. at the trial and block element). If you need to be able to identify which Category a stimuli is from at the block or trial level, then you will need to place different Categories in different item elements. Same for difficulty levels.
Try to create your stimuli lists. Give each list an informative name. To save you typing out all the stimuli there is a text file in the folder this week with a (single and untagged) list of the stimuli:
In our design we need to be able to provide feedback to participants on whether they were correct or not during the training phase of the Expeiment. This means that we need to be able to tell Iquisit which category each item is in, that it can provide the appropriate feedback based on the participants response. This requires seperate stimuli lists for A and B items.
Furthermore we also need to be able to specify when Hard, Easy and Medium items are presented, as this is the primary manipulation in the study. This requires us to pass this information to the block and trial level, therefore we also need separate item elements for each difficulty.
<item easya>
/1 = "patch1.png"
/2 = "patch2.png"
/3 = "patch3.png"
/4 = "patch4.png"
/5 = "patch5.png"
</item>
<item mediuma>
/6 = "patch6.png"
/7 = "patch7.png"
/8 = "patch8.png"
/9 = "patch9.png"
/10 = "patch10.png"
</item>
<item harda>
/11 = "patch11.png"
/12 = "patch12.png"
/13 = "patch13.png"
/14 = "patch14.png"
/15 = "patch15.png"
</item>
<item hardb>
/16 = "patch16.png"
/17 = "patch17.png"
/18 = "patch18.png"
/19 = "patch19.png"
/20 = "patch20.png"
</item>
<item mediumb>
/21 = "patch21.png"
/22 = "patch22.png"
/23 = "patch23.png"
/24 = "patch24.png"
/25 = "patch25.png"
</item>
<item easyb>
/26 = "patch26.png"
/27 = "patch27.png"
/28 = "patch28.png"
/29 = "patch29.png"
/30 = "patch30.png"
</item>Just like with the text elements, now that we have defined our stimuli, we need to specify how they should look when displayed on the screen. Because our stimuli are pcitures, not text, we can do this by defining a picture element. This element has an items attribute and a select attribute, just like the text element, as well as attributes for defining location, size etc. Based on your text code from last week, create the appropriate picture elements, so that the stimuli as displayed in the center of the screen (Use the help function if you want a reminder on wha the position, items and select attributes do). How many picture elements do you need?
We need as many picture elements as we have item elements, even though all pictures will be displayed in the same way. This is because trial calls stimulus level (i.e. picture, text etc) elements, not item level elements.
<picture easya>
/ items = easya
/ select = noreplace
/ position = (50%, 50%)
</picture>
<picture mediuma>
/ items = mediuma
/ select = noreplace
/ position = (50%, 50%)
</picture>
<picture harda>
/ items = harda
/ select = noreplace
/ position = (50%, 50%)
</picture>
<picture easyb>
/ items = easyb
/ select = noreplace
/ position = (50%, 50%)
</picture>
<picture mediumb>
/ items = mediuma
/ select = noreplace
/ position = (50%, 50%)
</picture>
<picture hardb>
/ items = harda
/ select = noreplace
/ position = (50%, 50%)
</picture>You can also change other attributes of the images being displayed. I recommend changing the size of the image as well.
For example:
<picture easya>
/ items = easya
/ select = noreplace
/ position = (50%, 50%)
/ size = (30%, 30%)
</picture>In general you could think of our task as having two types of trials, training trials (where feedback is given) and transfer trials (where it is not). While this is a useful distinction, and we can specify feedback at the trial level, we are not going to do this quite yet.
Instead for now, I want you to just create a trial element for each of our stimuli types, similar to the ones from last week. The valid responses for all elements should be A and B. Also in the paper there is a break of 1500ms between each trial. Build this into your trial elements.
For example:
<trial easya>
/stimulustimes = [1500=easya]
/validresponse = ("a", "b")
</trial>Last week we controlled how much time there was between each trial by using the stimulustimes attribute of the trial element (I’ve done this in the above code). This is useful if we want to display something during that time (for exampe a warning to get ready, or a fixation cross). However we can also explicitly tell Inquisit to pause between trials, using either the pretrialpause attribute or the posttrialpause attribute. The first of these prepares the trial, but then waits the designated time before beginning it. This can be advantageous if it takes Inquisit some time to prepare the next trial (e.g. it has to load large stimuli, or do calculations), because it insures that their is a consistent gaop between trials. Try setting the pause between trials using pretrialpause instead.
<trial easya>
/stimulusframes = [1=easya]
/validresponse = ("a", "b")
/pretrialpause=1500
</trial>
This example uses the stimulusframes attribute rather than the stimulustimes attribute. This is not necessary.Do this for all trials.
Now we will start to build the feedback element. The first step is to tell Inquisit, for each trial type, what counts as the correct response on that trial. This is similar to how we can define what counts as an valid response. Look at the help file for the trial element, and see if you can work out how to set this (Hint: it has correct in the attribute name).
Remember to set different correct responses for the different categories.
<trial harda>
/stimulusframes = [1=harda]
/validresponse = ("a", "b")
/correctresponse = ("a")
/pretrialpause=1500
</trial>
<trial harda>
/stimulusframes = [1=hardb]
/validresponse = ("a", "b")
/correctresponse = ("b")
/pretrialpause=1500
</trial>
The correct response is specified using the correctresponse attribute. The format is identical to the format used when specifying valid responses.Now when Inquisit displays a trial to participants it can tell whether the response given is correct, or incorrect (i.e. it was a validresponse but not a correctresponse). Inquisit can then use this information to display information to participants in several ways. The simplest is to display a message based on the response they gave. There are 3 main message attributes, correctmessage, errormessage and responsemessage. We will use the first 2. Each of these takes two pieces of information, the name of the stimulus that is displayed as the message, and the length of time for which it should be displayed.
This means we need to create some stimuli for Inquisit to display. We’ll just create text stimuli for both messages. When they get a category right, I want to display the word Correct! in large font coloured blue, when they get the category wrong, it should display Incorrect! in red instead. Create the text elements to do this.
<text right>
/items=("CORRECT!")
/position = (50%, 50%)
/hjustify = center
/fontstyle=("Arial", 10%)
/txcolor=(0,0, 255)
</text>
<text wrong>
/items=("INCORRECT!")
/position = (50%, 50%)
/hjustify = center
/fontstyle=("Arial", 10%)
/txcolor=(255,0, 0)
</text>
Just like with the get ready stimuli last week, we define the items directly in the text element. The only new part of this code is the txcolor attribute. Now use the correctmessage and errormessage attributes to tell each trial how to use these two text stimuli. You’ll need to do this for each trial type. Do you need to specify different messages for each trial type? Why or why not?
No. If we wanted out message to tell the participant which was the correct category (E.g. Incorrect, you should have said A), then we would need separate stimuli for A trials and B trials. However because we don not we can just display the same message for all.
<trial harda>
/stimulusframes = [1=harda]
/validresponse = ("a", "b")
/correctresponse = ("a")
/pretrialpause=1500
/errormessage = true(wrong, 500)
/correctmessage = true(right, 500)
</trial>
<trial harda>
/stimulusframes = [1=hardb]
/validresponse = ("a", "b")
/correctresponse = ("b")
/pretrialpause=1500
/errormessage = true(wrong, 500)
/correctmessage = true(right, 500)
</trial>Now that we have our trials defined we can create our training and test blocks. Last week we had a single block element, this week we will create a block called easyhard for the training block that progresses from easy to hard stimuli, hardeasy for the reverse block and transfer for the transfer section of the experiment.
First we’ll create a block element for the EasyHard condition, that only displays Category A trials.
Last week at the Block level we had to specify the trials attribute. This element set the number of trials that would be displayed in the block, and which trials element would be displayed on eachof those trials. Because we only had a single trials element, we only needed to specify that trials 1-21 were drawn from that trial element (e. /trials=[1-21 = choice]). we can do a similar thing this week to start, and specify that trials 1 to 5 should be from the easya trial element.
<block easyhard>
/trials = [1-5=easya]
</block>Now we need to specify what will happen for the other 10 training trials (i.e. medium and hard training trials for category A). One (bad) way to do this would be to specify a separate block element for each trial type, and deal with it at the Experiment level (there may be circumstances where you want to do this).
The easier way is to pass multiple relations to the trials attribute of the block. You can specify as many groups of trials as you wish in the trials attribute by making sure they are sequential and separated by a ; (e.g. /trials = [x-y=Trial1; (y+1)-z=Trial2]). Add the 5 medium trials and 5 hard trials for category A.
<block easyhard>
/trials = [1-5=easya; 6-10=mediuma; 11-15=harda]
</block>The final step in creating our training block is to add the category B trials. This is easily done at the block level. Each time you specified a trial element in the previous step (e.g. /trials=[1-21 = easya]), you could instead substitue a list of trial elements to be used. When doing this however you need to specify how Inquisit shoud sample/select from those two trials types when running those trials. This is similar to when you tell the picture or text element how it should sample/select from its item element by using the /select attribute (e.e.g you specify sequence, noreplace etc. Give it a try.
<block easyhard>
/trials = [1-10=noreplace(easya, easyb); 11-20=noreplace(mediuma, mediumb); 21-30=noreplace(harda, hardb)]
</block>
All you need to do is to replace easya with the selection method(e.g. sequence, no replace), then a list of the trials that should be selected from, in (). In this case on each of trials 1 to 10 it will select 1 stimulus from either easya or easyb without replacement. Importantly it will select equally from both trial types, so if one of them has fewer stimuli it will start repeating its selections from that trial type if there are still trials it needs to fill, even if there are remaining stimuli in the other trial. So if you had 8 stimuli in easy a, and 2 in easy b but wanted to display each stimuli only once you would need to include 4 times as many easya trials in the selction section (e.g. noreplace(easya, easya, easya, easya, easyb))You can alsu use this same method to have a single trial element use multiple different stimuli/text/picture elements, by specifying the same information in the stimulustimes attribute.
Do the same for the hardeasy block. The only difference is the stimuli order
<block hardeasy>
/trials = [1-10=noreplace(harda, hardb); 11-20=noreplace(mediuma, mediumb); 21-30=noreplace(easya, easyb)]
</block>Now we want to create the transfer block. This is actually easier than creating the training block, because we don’t care what order the stimuli are in. Using wat you’ve just learnt about selecting from multiple trial types, create a transfer block that shows all 30 trials in random order.
<block transfer>
/trials = [1-30=noreplace(harda, hardb, mediuma, mediumb, easya, easyb)]
</block>Try testing it. What is wrong?
Theproblem is that we are seeing feedback in the transfer block. This makes sense because we have defined the correct and error messages at the trial level, and the transfer block uses the same trials as the training block. SO does this mean we need to create a new set of trial elements for the transfer block?
The good news is no. Often in Inquisit you can define the same attribute at multiple levels. In this case we can also define these messages at the block level. Which seems great, but there is an issue.
Unfortunately (for this example), lower level setting override higher level settings. So even if we explicitly set the errormessage and correctmessage in the transfer block to false (.i.e don’t display anything), this will be overridden by the settings of the trials we are calling. So instead we need to remove the correct and error message attributes from the trial elements, and instead place them in the two training block elements.
Your trials and blocks should now look like this.
<trial easya>
/stimulusframes = [1=easya]
/validresponse = ("a", "b")
/correctresponse = ("a")
/pretrialpause=1500
</trial>
<block easyhard>
/trials = [1-10=noreplace(easya, easyb); 11-20=noreplace(mediuma, mediumb); 21-30=noreplace(harda, hardb)]
/errormessage = true(wrong, 500)
/correctmessage = true(right, 500)
</block>This shoudl solve the problem. It also has the advantage of removing some of the repetition in our code.
Currently we have 2 training blocks, one block runs from easy trials to hard, and the other the reverse version of our study Now we want to set it up so that half of our participants see the easy-hard block and other hard-easy, followed by the transfer block in both cases. There are several ways we can do this. We are going to use one that takes advantage of the fact that you always have to enter a Subject number at the start of every Inquisit study. This subject number can then be used by the subjects attribute of the expt element.
First we will create the easy-hard version of the Experiment, without worrying about condition assignment. This works the same as last week, except we will have two block, block 1 is the easyhard training and block 2 the transfer. You can pass multiple block elements to the /blocks attribute in the same way you passed multiple trial elements to the trials element in Exercise 3a
<expt>
/blocks = [1=easyhard; 2=transfer]
</expt>Now create a second experiment block that contains the other ordering.
Now we will set it up so that every subject with an odd subject number does block 1 and every subject with an even number does block 2. The way the subjects attribute works is that it defines a condition upon which the expt element should be run. In particular it divides the subject id by a number (defined by you) and runs the specified version of the experiment if the remainder of this division meets some criteria. To make condition assignment work, you will need to define a separate subjects attribute for each of your 2 expt elements.
<expt>
/blocks = [1=easyhard; 2=transfer]
/subjects = (1 of 2)
</expt>
<expt>
/blocks = [1=hardeasy; 2=transfer]
/subjects = (2 of 2)
</expt>Good work. You should now have a fully working Experiment
The original Experiment also only allowed participants 5 seconds to respond on each trial. If they took longer than this the trial ended and they were told to respond faster. We can also implement this feature.
For each trial element you can specify how long participants have to respond. Look at the attributes associated with the trial element to see how to do this (Hint: the name of the exercises is a hint).
<trial harda>
/stimulusframes = [1=harda]
/validresponse = ("a", "b")
/correctresponse = ("a")
/pretrialpause=1500
/timeout=5000
</trial>
The timeout attribute sets how many milliseconds the stimuli should be displayed for after the last stimuli passed to stimulitimes/frames is shown. So if the last stimulus is show 2seconds after the trial starts (e.g. /stimulustimes=[2000=harda]), then the timer would start after 2 seconds and the trial would run for 7 seconds.Above I mentioned a 3rd message attribute /responsemessage. Unlike the previous 2, this message can only be set at the trial level, and takes 3 inputs, namely;1) the response which triggers it (e.g. “a”, “b” etc.), 2)the message/stimulus to display (same as the first variable for correct/errormessage), and 3) the length of time (same as the second variable of correct/errormessage). If you look back at the help file for timeout you will see that there is a particular response variable that Inquisit uses when a participant runs out of time before responding. We can use this to trigger a response message.
For it to work though you’ll need to specify a new text element that contains the warning message.
<trial harda>
/stimulusframes = [1=harda]
/validresponse = ("a", "b")
/correctresponse = ("a")
/pretrialpause=1500
/timeout=5000
/responsemessage=(0, noresponse, 500)
</trial>
Make sure you define a test element called noresponse somewhere or it wont work.Sometimes it can be difficult for participants to remmber what the response keys are they need to use. I want you to create a reminder that will appear at the top of the screen on every trial of our block. This reminder should say “Press the A key for category A, press the B key for category B”. The first step to do this is to create another text element with this information (remember to set the position.)
<text reminder>
/ items=("Press the A key for category A, press the B key for category B")
/ position = (50%, 10%)
/hjustify = center
/fontstyle=("Arial", 3%)
</text>Now we need to determine where this should be displayed. What happens if you try to add it in at the trial level during using stimulustimes?
Because we want this to be displayed on every trial in the block the appropriate place to call this new text element is at the block level. At the block level you can set stimuli that you want to be displayed in the background of every trial by using the bgstim attribute. Give it a go.
<block hardeasy>
/trials = [1-10=noreplace(harda, hardb); 11-20=noreplace(mediuma, mediumb); 21-30=noreplace(easya, easyb)]
/bgstim = (reminder)
/errormessage = true(wrong, 500)
/correctmessage = true(right, 500)
</block>Try to implement the random order condition. Set it up so the Experiment will run all three versions. Its actually very easy. What is the least changes you need to make?
<block random>
/trials = [1-30=noreplace(easya, easyb, mediuma, mediumb,harda, hardb)]
/bgstim = (reminder)
/errormessage = true(wrong, 500)
/correctmessage = true(right, 500)
</block>
<expt>
/blocks = [1=random; 2=transfer]
/subjects = (3 of 3)
</expt>
#Don't forger to update the old EXPT elements to match the new number of conditions
<expt>
/blocks = [1=easyhard; 2=transfer]
/subjects = (1 of 3)
</expt>
<expt>
/blocks = [1=hardeasy; 2=transfer]
/subjects = (2 of 3)
</expt>