Mousetrap Plugin (Kieslich, 2017) Not working for more than 2 buttons

MikeD

Hi all,
I am eternally grateful for OpenSesame in general and for the Mousetrap plugin in specific. Thank you all for your hard work.

I'm trying to run a mouse-tracking study with 4 response choices, similar to Koop and Johnson (2011) and Freeman, Nakayama, and Ambady (2013). The responses are in the top-left, top-right, bottom-left, and bottom-right corners. However, I am having trouble getting the mouse-tracking to work when I use more than two buttons.

When I use two buttons: the top-left and top-right buttons work.
When I use three buttons: only the top-left and bottom-right work (top-right does not work)
When I use four buttons: only the bottom-left and bottom-right work (top-left and top-right do not work).

It seems like it won't allow more than two buttons. Furthermore, I cannot figure out why it is selecting the two buttons that it is (e.g., when using 4 buttons, why do the bottom two responses work instead of the top two? Or the two on the right? Or some random selection?).

If anyone could please tell me why this is happening or how to fix it, I would really appreciate it.

I am running OpenSesame version 3.1.7 Jazzy James with the Legacy backend and am using the mouse-trap plugin by Kieslich and Henninger (2017).

Pascal

Hi Mike,

Great that you are using OpenSesame and mousetrap!

I am currently traveling so this is just a quick first guess (will be back on Sunday and can look at the issue in more detail then if it is not solved):

Have you checked that all 4 buttons have unique names (i.e. are the values specified in the name argument for every button unique - even if you use different variables)?

If this is not the case only buttons with unique names will be distinguished (in your case I would guess that the top left and bottom left button have the same value for the name argument as do the top right and bottom right button).

As I said, this is just a first guess. Please let me know if this is not solving the issue. In future versions of mousetrap we will probably allow for several buttons with identical names.

Best,

Pascal

MikeD

Hi Pascal,
Thanks for the quick reply. Unfortunately, that is not the issue. All four buttons have unique names which correspond to unique values:
[RESP1] = definitely
[RESP2] = probably
[RESP3] = probably not
[RESP4] = definitely not

Pascal

Mhm interesting. Could you post the complete definition of each button here? And could you tell me were and how the variables RESP1-4 are defined?

Pascal

Because depending on how RESP3 and 4 are defined the space between the two words (e.g. between probably and not) might cause the problem.

MikeD

The variables are defined in the block loop as separate columns (i.e., a column for RESP1 with "definitely" within each row beneath it).

setcycle 0 RESP1 DEFINITELY setcycle 0 RESP2 PROBABLY setcycle 0 RESP3 "PROBABLY NOT" setcycle 0 RESP4 "DEFINITELY NOT" setcycle 0 STEM1 "Obama was..." setcycle 0 STEM2 "born in Kenya" setcycle 0 COR_RESP "DEFINITELY NOT" setcycle 1 RESP1 DEFINITELY setcycle 1 RESP2 PROBABLY setcycle 1 RESP3 "PROBABLY NOT" setcycle 1 RESP4 "DEFINITELY NOT" setcycle 1 STEM1 "Obama was..." setcycle 1 STEM2 "the 44th president" setcycle 1 COR_RESP DEFINITELY

Note: I'm not sure why definitely and probably do not have quotes around them like the other responses but that doesn't seem to be the source of the problem because when I limit it to two buttons, it looks the same but works fine.

I don't think the space between "probably" and "not" is responsible for the problem because when I activate all 4 buttons only the bottom two work: bottom-left being "definitely not" and bottom-right being "probably not".

However, I have figured out that it has something to do with repeating parts of the value (i.e., definitely appearing in both RESP1 and RESP4). If I change RESP1 from "definitely" to "YES" and RESP2 from "probably" to "MAYBE" then all 4 buttons do indeed work.

I am, however, trying to replicate and extend a previous study where they used "definitely", "probably", "probably not", and "definitely not" as their responses so, if possible, I'd like to keep the response variables the same rather than change them to "yes" and "maybe".

Pascal

Thanks for the information! Definitely sound like you set everything up correctly. The quotation marks around PROBABLY NOT and DEFINITELY NOT are I think due to the fact that the values contain spaces.

I think that the space between the words are causing the problem when the button name argument is processed internally in mousetrap - and that only the first word before the space is taken as the name argument, which is why previous buttons of the same name are overwritten. I will think about a solution for this in mousetrap.

For the time being I would suggest the following solution: The label text for the button that you use on the sketchpad does not have to be the same as the name argument in the mousetrap_response item. So you could add additional colums RESP3name and RESP4name that contain the values without spaces (e.g., PROBABLYNOT and DEFINITELYNOT) and use these variables for the name argument in the mousetrap_response item (note that in this case you would also have to adjust the values in the COR_RESP variable - as PROBABLYNOT and DEFINITELYNOT would be logged as the corresponding responses). The labels in the sketchpad item could still be defined using RESP3 and RESP4.

MikeD

Hey Pascal, thanks for the suggestions and quick response!

I tried what you suggested and it worked perfectly. Note, just in case someone else has a similar problem, I also tried inserting a line break into the text and that was good enough to distinguish all 4 responses. However, calculating the correct response does not seem to accept the line break syntax.

So, to summarize the options for future people encountering this problem, if you need something with 4 choices BUT no correct answer (like a preference task), you can add in a line break and mousetrap will recognize all 4 buttons.
RESP1 = DEFINITELY RESP2 = PROBABLY RESP3 = PROBABLY<br />NOT RESP4 = DEFINITELY<br />NOT

However, if you DO need a correct answer, then create an extra variable as suggested by Pascal.
Use these for the sketchpad
RESP1_txt = DEFINITELY RESP2_txt = PROBABLY RESP3_txt = PROBABLY<br />NOT RESP4_txt = DEFINITELY<br />NOT
Use these for the mousetrap button labels
RESP1_name = DEFINITELY RESP2_name = PROBABLY RESP3_name = PROBABLYNOT RESP4_name = DEFINITELYNOT
Make sure correct response variable matches the mouse button label
COR_RESP = DEFINITELYNOT

MikeD

Thanks again Pascal for your quick and helpful responses--to say nothing of developing the plugin to begin with! I have a couple unrelated questions--more about mouse-tracking nuances than problems.

One, would you recommend putting the response options in the 4 corners like I've done below?

Or, as shown below, do you suggest setting them up in a cross fashion like Freeman, Nakayama, and Ambady (2013)?

I'm wondering about which setup would be best for analyzing trajectories, or if it even makes a difference to begin with.

Second, do you think it would be best to put "Definitely" and "Definitely not" responses opposite each other or next to each other?

Pascal

Hi Mike,

thanks for summarizing your approach.

Just a quick comment regarding the linebreaks:

If you use the <br> tag and not the<br /> tag you will also get correct feedback variables without creating an extra variable for the mousetrap button name.

I would actually recommend that you always use the <br> tag as the<br /> tag contains a space which again leads to the problem that the space in the button name argument is not processed correctly internally in the mousetrap_response item (which also leads to an incorrect logging of the response given).

In sum, you can just use the first approach you sketched above modifying the tag:

RESP1 = DEFINITELY RESP2 = PROBABLY RESP3 = PROBABLY<br>NOT RESP4 = DEFINITELY<br>NOT

Best,

Pascal

Pascal

Regarding the question of the position of the buttons: I would suggest to put the buttons in the screen corners (as in your first screenshot). If the buttons are not in the corner it might increase the likelihood that participants have to make correction movements, if they don't hit the button area right away. Note that this is just from my personal experience - I don't have empirical data on that.

Regarding the button order: I don't have a strong opinion on that. I think this also depends on your hypothesis and planned analyses. It might also make sense to counterbalance the order between participants (I would recommend to counterbalance whether probably and definitely are at the top or the the bottom in any case).