Jumping Position of my Stimuli

[visto2001]

Hi everyone,

I’m currently building an experiment in FindingFive that combines aspects of the Stroop and Flanker tasks. In this setup, I need to display two stimuli side by side—one on the left and one on the right. It’s crucial that these stimuli stay fixed in their positions throughout the experiment to avoid any visual shifts that might affect participants’ attention or reaction times.

I’ve already tried using the "location" and "fixed_location" options, and the positioning looks almost right. However, I’m still seeing a slight “jumping” or shifting of the text stimuli between trials, which is a problem for the design.

Does anyone know how to make sure the stimuli remain completely stable in their assigned left/right positions across all trials?

Any help would be greatly appreciated!

Thanks so much in advance!

Best,
Vivienne

Here is my code from my trial template so far: 

{
  "match":{
  "type":"basic",
  "stimuli":[
    {"which": ["BLAU_black", "GRÜN_blau_match"], "location": [4, 6]},
    {"which": ["BLAU_black", "ROT_blau_match"], "location": [4, 6],
    "fixed_location": true}],
  "stimulus_pattern":{"order":"fixed"},
  "responses":["response_matching"], "location":[8]
  },
 
  "mismatch":{
  "type":"basic",
  "stimuli": [
    {"which": ["BLAU_black", "GELB_lila_mismatch"], "location": [4, 6]},
    {"which": ["BLAU_black", "ROT_grün_mismatch"], "location": [4, 6],
    "fixed_location": true}],
  "stimulus_pattern":{"order":"fixed"},
  "responses":["response_matching"]
  }
 
}

[Ting]

Hi Viviene,

Thanks for the clear description! Hmm...normally, if the match and mismatch trial templates have the same setup, and it does look like they do, the image stimuli should be in the same locations. My guess is that the images may be ever so slightly different in sizes (measured by pixels). This is especially hard to notice if there is some white border/padding around an image.

Can you double check? If you don't think that's the issue, you are always welcome to add "[email protected]" as a collaborator so that we can take a look!

Ting

[visto2001]

Hi Ting,

Thanks so much for your quick response and for pointing that out!

You’re right — the trial templates are set up identically, and I double-checked that everything is positioned using "location" and "fixed_location". However, I’m not using image stimuli, these are all text stimuli in different colors (e.g., the word BLAU in black, GRÜN in blue, etc.).

Since it’s just text, I don’t think it’s a size or padding issue related to images, but it’s possible that differences in text width or character rendering might be causing the slight shifting effect I’m seeing.

I’ve just added [email protected] as a collaborator so you can take a closer look. I’d really appreciate any insight you might have, as it is a distracting factor in my experiment. 

Thanks again for your help.
Vivienne

[Ting]

Got it. Yeah you're quite on point: it's because the text stimulus uses a "variable-width" by default, so its overall width changes across trials. Let us think a bit about what to do in your case. I'll be in touch!

[visto2001]

Hi Ting,
Thank you so much for the clarification — that makes sense! I hadn’t realized that the default text width behavior could lead to such subtle shifts. I really appreciate you looking into it and taking the time to think through a solution.
I’ll stay tuned and am happy to try out any suggestions or adjustments you might have.
Thanks again for your support!
Vivienne

[Ting]

You’re very welcome, Vivienne!

Here’s the plan: we’ll add a feature that lets researchers specify the width of a text stimulus, similar to how it works for images. What happens is we’ll create a “text box” around the text. The specified width controls the size of this box. While the text appearance won’t change, the container will now have a fixed width across trials. As a result, the text boxes will not shift around across trials visually.

I’m still a bit concerned this might not fully solve your issue. Even with a fixed-width text box, the position of the text within could shift slightly depending on its length. For example, if one trial shows "BLUE" and the next shows "RED," the shorter word ("RED") will sit slightly differently within the box. I don’t think this can be avoided—will that work for you?

[visto2001]

Hi Ting,
Thank you so much for the detailed explanation and for planning to add that new feature, that sounds really helpful and definitely a step in the right direction!
I understand your concern about the text alignment inside the fixed-width box. I think as long as the overall position of the stimulus on the screen stays stable, and any internal shifting is minimal, that should absolutely work for my purposes. I'm mainly trying to avoid the distracting “hopping” effect between trials, so a consistent container would already be a big improvement.
Would it be possible for you to help me add that feature to my current experiment once it’s available? I’m not entirely sure where or how I’d need to implement it.

Thanks again for your support, I really appreciate it!

Best regards,
Vivienne

[Ting]

Sounds like a plan then! We are working on it now and will give you an update on how to test it early next week. Stay tuned.

[Ting]

Hi Vivienne,

We have something for you to test. If you go to our beta server in the EU: https://eu-beta.findingfive.com and log in, and add a "width" parameter to the text stimuli so that they look like this:

Code:

{
  "type": "text",
  "content": "<b>BLAU</b>",
  "alignment": "center",
  "color": "black",
  "size": "300%",
  "width": "200px"
}

I think all problems should be magically resolved. You can tweak the "200px" value to find the best setting for you, but 200px should be a good value already.

Let us know if this is a good enough solution for your design. If so, we can make it available on the production server.

[visto2001]

Hi Ting,

Wow, that works perfectly! The stimuli are now completely stable, and the “hopping” effect is gone. Thank you so much for implementing that and making it so easy to test; it really makes a huge difference for the clarity of the task!

If you’re already a little familiar with what I’m doing, I have a follow-up question regarding the response setup. I’m trying to capture both reaction times and accuracy for a Stroop-style task, where participants respond by pressing C if the stimuli mismatch and M if they match.

Initially, I used the keypress response, but I realized that the reaction time there is calculated as the time since the last keypress, not from the start of the trial, which seems less accurate for my design.

That’s why I switched to a choice response, where RT is based on the time from the presentation of the stimuli to the participant’s response. However, the choice response shows on-screen buttons, and I really want participants to respond only via the keyboard, ideally with no visible response buttons.

Is there a way to use the choice response with keyboard input only, but hide the on-screen buttons? Alternatively, can the keypress response be adjusted to record RT from stimulus onset instead?

Thanks again for your fantastic support, I’m really grateful for your help!

Best regards,
Vivienne


so far my code looks like this:

{
"type": "choice",
"choices": [
"Ja",
"Nein"
],
"key_mapping": [
"c",
"m"
],
"instruction": "",
"timeout": 10,
"feedback": false
}