| Reference | Downloads | Github

Repeating Stimuli with Different Response Types: Multiple Blocks or One Loop?

Hi all,

This is my first post. I’ve been lurking for awhile but came across a problem that I haven’t been able to resolve.

About my study:
Stimuli are 30 written scenarios, with 3 types (so 10 of each type of scenario). I have a conditions file with two parameters: ScenarioType (which indicates which type the scenario in that row is) and Scenario (which is the wording of the scenario).

In the experiment, subjects will proceed through 4 blocks (conceptually speaking):
Block 1. Subject sees 15 scenarios in random order, 5 of each type (i.e. balanced random sample without replacement), makes forced choice about each of them
Block 2. Subject sees remaining 15 stimuli, 5 of each type (i.e. balanced random sample without replacement), makes forced choice under time pressure
Block 3. Same as 1, but subject makes continuous rating
Block 4. Same as 2, but subject makes continuous rating under time pressure.

Block order should be random (1234, or 3142, etc). Importantly, subjects rate each scenario twice - once with forced choice, once with continuous ratings. Said another way, blocks 1&2 share the same stimulus pool as blocks 3&4, and the stimuli seen in say, block 1, need to be different from block 2 (balanced random sample without replacement), while block 3 needs to be different from block 4, but after completing all four blocks, subjects will have seen all stimuli twice (once in block 1 or 2, once in block 3 or 4).

I also need instructions to go with each block: if Block 2 gets called, the subject should see instructions regarding forced choices under time pressure, and so on.

I thought about making 4 actual blocks in the builder view, each comprised of the instructions and the a loop set to repeat 15 times. Forced choice - time Pressure, for example, would consist of the instructions routine for Forced Choice -Time Pressure, then a looped routine for 15 forced choices. I’d put a loop around those two routines, which would make a block, of which there would be 4 in the end. Then enclose those four blocks within a single loop, and randomize the blocks. I have a picture of this attached below.

However, I’ve seen that you guys discourage looping several routines like this and prefer that one routine be looped over and over again with coding elements stipulating how each set of 15 trials will behave (that is, which response type will be called, which time pressure condition will be called, which instructions will be called, etc. for each set of 15 trials).

So I guess my main question is: Is this best done in a single routine?
In other words, is there is a way to repeat a stimuli with a different response type within the same routine, while ensuring a balanced random sample without replacement while every scenario is seen once per response type?

Or am I in over head?!

I realize this isn’t a very interesting question, but while I can easily solve individual problems (like subsetting conditions from a condition file) I’m unsure of where to begin given I need to make sure these stipulations are integrated in an efficient way.

Thanks for your time!

No need to apologise, these are interesting and important questions.

You can define an experiment in whatever way works for you, but some ways are better than others. As well as how the experiment runs, you need to consider the structure of the data it produces. With multiple serial loops, the data can require quite a bit of processing to get into a convenient form for analysis. And for example if you have multiple different routines that collect the same information (say a reaction time), then that variable gets split into different columns when it would be easier if they were in the same column.

The decision as to whether you should have one or more routines comes down to whether they are functionally identical (e.g. show instruction text and then wait for a keypress to continue). If so, then rather than containing static text, that text content can be included in a conditions file and controlled dynamically across blocks or trials as required. The question here is whether your continuous and forced choice ratings are functionally different, and similarly whether your time constraint element also requires a different set-up. If so, they might require separate routines. But they could be specified serially within the same loop, with a code component that determines which one runs on each iteration, depending on whether this is a continuous or forced choice block.

If you want to control the order of blocks, then that requires having multiple loops and routines in serial, each containing a little code component that checks if it is this routine’s turn to run on this iteration of some containing loop. It can be much more efficient to just control that directly from the loop itself. i.e. the inner loop connects to a conditions file, expressed as a variable name. An outer loop connects to a smaller conditions file that just contains names of the conditions file to be used by the inner loop (and perhaps also contains block-level instruction text).

That way, your random block ordering happens automatically.

My gut feeling is that you could do this with just two loops, and 2–5 routines . The inner loop would encompass your task routine(s): there could be 1–4 of these depending on task differences. If multiple ones, then there would need to be a small code component snippet to determine which one runs.

The outer loop would encompass that inner loop but also a preceding interaction routine.

This was very informative and just the insight I needed - thank you!