In the Experiment this week ( Rudert et al. (2017) ), participants were presented with pictures of faces that had been manipulated so that they differed in judged warmth and competence. They were then asked to rate how appropriate it would be for a group to exclude this person. Half of participants were told that they belonged to the group (ingroup), while the other half were told it was a different group (outgroup), excluding the person.
There is actually nothing new to learn for this task, you have already dealt with presenting picture stmuli (WPA 3 & 6), timing stimuli presentation (all weeks), collecting responses using a likert scale (WPA 6), and assigning participants to conditions (WPA 3 & 4). Therefore the new tasks we will cover this week are:
However, before we can deal with these points, you’ll need to program the basic experiment. Given that all the features are ones you have dealt with before, I will not give you answers in this WPA for the sections on programming the Experiment. You will get the answers after class. Therefore you will have to use your own knowledge, the previous weeks, and help files (or ask me questions) to troubleshoot issues with your code. This should give you the opportunity to:
It will also give me an idea of how well people are handling the material.
Like every week we are going to start a new Inquisit file for this weeks exercises. Call this file surname_wpa8.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.
The Experiment you will program should work as follows:
The 4 face pictures can be downloaded here from the subfolder. The names should be self explanatory.
Tell Inquisit what your stimuli are (i.e. where it can find the image files). An important question to consider is whether you’ll need to be able to access different groupings (e.g. all the warm images), at any point during the Experiment, or wether you will only ever need to call all face types.
Now specify how the faces should appear when they are presented on the screen. Make sure they are presented in the middle of the screen and take up about half the height of the screen. This is also the point where you determine what oprder the stimuli should be displayed in.
Now we will create the trial(s) where our stimuli will be displayed. We’ll break this in to sub-tasks.
First we will create a trial where a random face is displayed on the screen and Likert scale is also shown. Have the face appear at the start of the trial, but add a pause of 500ms between each trial (don’t do this in stimulustimes). Remember that there is a aspecialised type of trial element particularly designed for collecting responses vai a Likert scale.
Now you have botha face and likert scale displayed on the screen simultaneously. However we want the face to only be displayed for 2 seconds, and for the Likert scale to appear only after the face has dissapeared. Remember that to erase a stimuli in Inquisit you need to cover it with another object (like a shape) that is the same colour as the background. Create an object to cover up the face and add it to your trial so that it covers the face after 2 seconds. Does this also solve the isssue of the Liker tscale appearing immediately?
Now you should have a face shown for 2 seconds, then a (mostly) blank screen with a likert scale shown. However the liker scale looks fairly ugly, it just has 5 points, clustered in the middle of the screen with no labels apart from the numbers. The next step is to make the scale into the 4 point rating scale with appropriate labels (1 = Completely Unacceptable, 2 = Somewhat Unacceptable, 3 = Somewhat Acceptable, 4 = Very Acceptable). Make sure it is displayed in the middle of the screen and that the points are spread out.
Change the attributes of the likert scale so that there are only 4 points, rather than the default 5.
Add labels (also called anchors) to the four points.
By default Inquisit spreads the anchors so that the labels don’t overlap. However also try setting this manually to 30% of the screen between anchors. You may also want to adjust the font size of the labels.
Now the Likert scale itself should be correct. However we also need to give people the prompt question for the scale of either: a) Ingroup:“How acceptable do you think it is for your group to exclude this memeber?” OR b) Outgroup:“How acceptable do you think it is for the group to exclude this memeber?”
This prompt is essentially another stimuli we want to have presented on the screen at the same time that the likert scale is presented/ at the same time as the blank stimuli covers the face. Create the appropriate stimuli element for each of the two questions. Then add them to the trial (remember you can have 2 stimuli appear at the same time).
How many liker trial elements shoudl you know have?
Finally we want the Likert scale to only be displayed for a maximum of 4 seconds. In previous weeks we covered how to make the trial timeout after a specified amount of time has passed from the last stimulus display. Use this to remove the Likert scale after 4 seconds if the participant fails to respond.
Finally we want to display a check question after all trials have been completed. We are going to create a trial where the following is displayed:
“Were you a member of the group yourself in the situation you imagined?” “Press Y for YES and N for NO”
First create a text element that specifies what we want to be displayed (the above), the size of the text (4%) and where (top middle of screen). If you want to insert a line break between sections of text then you need to have the line break inside the quotation marks in the code. For example: *“This will be displayed on the first line.*
*This will appear on the second.“*
Now create a trail where this text is displayed and only presing keys Y and N are acceptable/valid responses. Participants should have unlimited time to respond.
The final step is to create bloks for our two conditions. Create two blocks, one for each condition. For the ingroup block display all four stimuli once, with the likert prompt referring to your group, then display the check question. For the outgroup do that same except with the likert prompt stating the group instead.
If you have time add an instruction page to the start of the block (you can copy the text from the appendix of the paper).
In the next section we will go through several different ways you can control condition assignment. We will then cover briefly how to control what is recorded in the data file.
The first way to assign groups we have already covered in the categorisation experiment in WPA3, when we controlled the order of hard and easy trial presentation between subjects. For this type of condition assignment, you merely need to create two separate expt elements, one for each condition, each of which lists the blocks that should be displayed (and their order) in that condition. You can then use the subjects attribute to determine when each Experiment should be run.
The first step is to create an expt element that will run the Ingroup block and a separate expt element that runs the outgroup blocks. Make sure you have named the blocks clearly.
<expt>
/blocks = [1=Ingroup]
</expt>
<expt>
/blocks = [1=Outgroup]
</expt>
Now we need to specify the subjects attribute to control when each Experiment is run. By default the subjects attribute checks whether the subejct ID (which you are prompted to enter when you rn the experiment) meets a criteria, and runs that version of the Experiment if it does. For examples /subjects = (2 of 2) would run that version of the Experiment for every even subject ID (i.e. every second subject in 2). Set the subjects attributes so 1 runs for even subject IDs and the other for odd IDs.
<expt>
/blocks = [1=Ingroup]
/subjects = (1 of 2)
</expt>
<expt>
/blocks = [1=Outgroup]
/subjects = (2 of 2)
</expt>
You are also prompted to enter a group number at the start of each Experiment. You can also use this number to control condition assignment, instead of the subject ID. To do this you need to tell Inquisit that the subjects attribute is referring to the group number, not the subejct ID. You can do this by specifying the groupassignment attribute of the Experiment element.
<expt>
/blocks = [1=Ingroup]
/subjects = (1 of 2)
/groupassignment = groupnumber
</expt>
<expt>
/blocks = [1=Outgroup]
/subjects = (2 of 2)
/groupassignment = groupnumber
</expt>
Both these methods require us to manually control the condition assignment, by entering the appropriate subject ID or group number. This isn’t always desirable, for instance often you would like the person running the Experiment to be blind to the condition the participant is in. To make assignment random we can simply set the groupassignment attribute to random, then it will randomly pick an experiment o run (you still need to include the subjects attribute with the correct breakdown into conditions).
<expt>
/blocks = [1=Ingroup]
/subjects = (1 of 2)
/groupassignment = random
</expt>
<expt>
/blocks = [1=Outgroup]
/subjects = (2 of 2)
/groupassignment = random
</expt>
The next method for condition assignment is very similar to the expt method, but instead we create multiple batch elements. expt elements specify which blocks should be run during the experiment, and their order. batch elements instead specify which inquisit scripts should be run during the experiment, and in what order they should be run. To us the batch element for assigning participants to different versions/conditions of your experiment, you need to have the separate versions saved in separate script files. This can be useful when the versions/conditions are very different from each other with little overlap in code.
Create 2 new script files. Call the first wpa8in and the second wpa8out. Each script should contain all the code necessary to run either the ingroup or outgroup version of the experiment. The create a third script file called wpa8batch. This is where we will put our condition assignment by batch.
In our new batch file we are going to now create 2 batch elements (just like we had 2 expt elements in the old script). In the first we will load and run wpa8in for all participants with an odd numbered ID. In the second we will run wpa8out for all the even numbered IDs. batch takes subjects and groupassignment attributes which behave identically to these attributes in the expt element. It also has an attribute called file which specifies which script file should be loaded and run. Specifying a script file is similar to specifying an image file in the item element. You need to give the name of the script file (including the file extension), and the location of the script file relative to the location of the batch file.
<expt>
/file = "wpa8in.iqx"
/subjects = (1 of 2)
/groupassignment = subjectnumber
</expt>
<expt>
/file = "wpa8out.iqx"
/subjects = (2 of 2)
/groupassignment = subjectnumber
</expt>
This assumes that all 3 script files are saved in the same location. Further you could also set assignment to random or by group as you did with expt.
A third way to (kind of) do condition assignment is to instead place all the blocks/conditions in one version of the Experiment, but selectively skip the blocks that aren’t relevant to the condition the participant is in. We will first show how to do this for manually assigned group IDs. Then for custom random value.
The first step is to create a version of our experiment where both our ingroup and outgroup blocks are run in a single expt element. To start with we’ll create it so that first the ingroup block is run, then the outgroup block.
<expt>
/blocks = [1=Ingroup; 2=Outgroup]
</expt>
Because we want this to run for every participant wedo not want to specify a subjects attribute.
Block elements have an attribute called skip, which allows you to specify a conditon under which the block should be skipped. This is the same as the skip element for trials that we used in WPA 5. we are going to use this skip to skip the Ingroup block whenever the group id of the participant is 2, and the outgroup block whenever it is one. So we need to come up with an expression that will evaluate as TRUE when group ID is 1, and a second that evaulates to TRUE when group ID is 2. This means we need to retrieve the group ID for a participant while we are running their code.
Fortunately group id is one of the variables Inquisit stores. This is stored at the level of the script, so if you reference script.groupid in your code, this will return the group id entered for that participant at the start of the Experiment.
<block Ingroup>
/trials = [1-4=in; 5=check ]
/skip = [script.groupid == 2]
</block>
<block Outgroup>
/trials = [1-4=out; 5=check ]
/skip = [script.groupid == 1]
</block>
Just as before, we might instead want to do this randomly, rather than based on a variable we enter. This requires only a small modification to our code. All we need to do is replace script.groupid == 1 or 2, with an expression that evaluates to TRUE or FALSE based on a random value.
First we need to generate and store a random number. To do this we are going to create a custom value/variable (call it grp) like we have in previous weeks and we will set the intial value of this variable to randomly generated number between 0 and 1. To generate this number we ill use the rand(x, y) function. This function accepts as its input two numbers, a lower bound (x) and an upperbound (y) and generates a random number between these two. For a list of function, look at the functions helpfile. Create your random variable. I suggest displaying this value in the text of your check question so that you can see whether it is generating properly (i.e add <% values.grp %> to your text string for check)
<values>
/grp = rand(0,1)
</values>
Now we simply change our skip expressions so that the ingroup block is skipped if values.grp is less than 0.5, and the outgroup is skipped if values.grp is greater than or equal to 0.5.
<block Ingroup>
/trials = [1-4=in; 5=check ]
/skip = [values.grp < 0.5]
</block>
<block Outgroup>
/trials = [1-4=out; 5=check ]
/skip = [values.grp >= 0.5]
</block>
Every time you run your script Inquisit automatically saves the result into a datafile. This file has the extension .iqdat but it is essentially a tab delimited text file. So if you want to open this file outside Inquisit I recomment importing it into excel (or other spreadsheet software), just like you would a .txt file. If you have issues you might need to change the file extension to .txt. Often I’ll use excel to save my .iqdat files as .csv then import them into R or whichever statistical program you use from their.
We wont go through how to look at your data in other programs, but we will cover how you can specify what data Inquisit should be storing. We’ll use the latest version of your Experiment, where both conditions are in a single experiment, but skipped based on a random number generator.
At this point most of you have run through your Experiment a few times. Each time you have done so Inquisit has updated a single data file. If you open this file now you’ll see something like this
Example of a datafile
This stores a range of default variables for every trial shown to participants (including surveypages, instruction pages etc.). Different variables are shown in different columns. Some of these varialbes are quite useful (e.g. response is the reponse they made on the trial, subject is the subject id etc.), while some are probably not important to you (for example we haven’t set a posttrialpause, so its not very useful). Below I will go through how you can change which variables are stored, so that variables you think are important are captured.
Each row however has the data for a single trial for a single participant, stored in sequential order. Furthermore this datafile contains the data for all participants who have done the Experiment on this machine (in this case each time you ran part of tyhe experiment you would be a separate participant). This has a few problems. Firstly, if you use the same subject ID for multiple participants these will all be stored together in the same file and it can be hard to tell which participant is which (in my example above you see that time various quite a lot, this is the separate times I ran the code, but they almost all have the same subject ID).
Now that you have opened the data file, I want you to leave it open and run your Experiment again. When you get back to the Inquisit window the data file won’t contain the data from the Experiment uo just ran (which makes sense because its the old version open). However if you double click on the datafile in the message list at the bottom of the screen, to reopen it, you might (depending on versioning) notice that it still doesn’t display the latest data. To see this data you need to close the current data tab before reopening your data file.
If you scroll to the right of your datafile you might notice several columns of data that don’t have names. This is because the columnnames are set the first time that you run an Experiment (i.e. the first time the datafile is created an saved). If later you add more features to your Experiment that have variables which fall within Inquisits default storage (for instance if you add a second or third stimuli during a trial, like the blank shape, or the text stimuli), it will add columns to the file to store these but not give them names. The only way I have found to get around this is to delete the data file (or close it and rename it), so that a new file is created next time we run the experiment.
Example of a blank columns
This is important for what we are about to do. Before you go any further create a new copy of the data file, but don’t delete the old one.
If we want to specify exactly what variables should be saved, we can use the data element. This controls what and how the data file is saved. The only attribute of this element we will discuss in depth is the columns attribute. However some others are useful to know.
separatefiles- while by default Inquisit stores all participants in a single datafile (when on a single computer), you can instead create separate files for each participant by setting this to true. labels- Setting this to false gets rid of the column lables, storing only the data. format- specifies how the file is delimited (e.g. tab (default), comma etc.).
To change which variables are stored you need to set the columns attribute of the data element. This attribute takes a list ( in [ ] ) of variables that you want to store, with each variable name separate by a space. The values for all variables will be stored for every trial at the end of the trial, regardless of whether they change or not. It is important to remember that they are stored at the end of the trial if you do any processing of variables during the trial (e.g. update a custom value using ontrialend).
To change our datafile then we just need to know what the names are of the variables we want to store. Fortunately there is a help file calles columns that gives you a list of possible column names. Define your data element so that only the trial type, block type, stimulus item shown, response, subject id and group id are stored. Use the columns help file to find the appropriate column names.
<data>
/ columns = [subject group blockcode trialcode response stimulusitem]
</data>
Make sure the current data tab is closed, then run the Experiment and look at the data file. Did it work as expected (look at point aii.)
If you looked at the help file you would see that in addition to the named columns you can also store any property (i.e. variable) that is recorded during the experiment in the data file as well. In our case it would be really useful to have a record of the random number that was generated and used for defining condition assignment. Add this to our data file. Just use the same naming convention you have used when callign tis value elsewhere.
<data>
/ columns = [subject group blockcode trialcode response stimulusitem values.grp]
</data>
Returning to the issue of condition assignment, there is literally only one word different between the two conditions of our Experiment (your vs. the when the scale is displayed). Given this do you think there is a way you could create the two versions of the Experiment, but with only a single text/trial/block element, rather than the two of each we currently have? Think about the expressions involving groupid/grp, creating and displaying custom values, and the onend and onbegin attributes that you have used previously. Try to program it.