using cursor_roi to collect mouse responses results in two different screen layouts

mgade

Dear all,

I want to use mouse responses to collect reactions in a a flanker task (i.e. categorize central letter as consonant or vowel) which should be clicked and it looks fine in the programming (see below).

However, when I run it in Google Chrome, something odd happens (i.e. screen using different coordinates)

Mousetest.osexp

I attached the code (sorry for not translating the intro and informed consent) - any suggestions are welcome.

I also worked with the java script roi definition which solved the problem partially but did not yield the expected coordinated in the result file and the experiment does not advance as expected (which it does when using the cursor_roi in the code added)

MouseTest_resultswithjavascript_noadvancementinexperiment.xlsx

Fab

Hi @mgade,

I had a go at fixing your task. You'll probably have to do some adjustment (especially checking that all you need is stored in the data log), but I've got something that shuld allow you to move forward building your experiment.

This task is structured to present a visual display where participants must click on one of two labeled rectangles (“vocal” or “consonant”) and ensures that only valid clicks on these regions are accepted. The logic is designed to avoid accidental or irrelevant clicks while keeping the participant’s experience seamless.

Each trial begins with a fixation screen, followed by two sketchpads that serve distinct purposes. The first sketchpad, named Rectangles, contains only the clickable rectangles. It is invisible to participants but plays a crucial technical role: it defines the Regions of Interest (ROIs) that the mouse response object will use to detect valid clicks. The second sketchpad, TargetDisplay, is the one the participant actually sees. It includes the same rectangles in the same positions, but also the target stimulus and the labels (“vocal” and “consonant”).

This separation is important. If the visible sketchpad were used directly for click detection, the text items (“vocal”, “consonant”, or even “target”) would also register as clickable elements, because OSWeb treats any named or unnamed text as a potential ROI. By linking the mouse response to the “Rectangles” sketchpad instead, only the rectangle shapes are recognized as valid click areas, while the visible display remains uncluttered and accurate.

After the target display is shown, the experiment enters a new_loop, which contains a short sequence. This sequence includes three elements:

1. The mouse_response object, which waits for a mouse click and checks whether it lands within the ROIs defined by the Rectangles sketchpad.
2. An Inline JavaScript item (processes_click) that processes the response, extracting the clicked element’s name (cursor_roi) and setting variables such as choice and a Boolean flag valid_click. If the participant clicked on “vocal” or “consonant”, valid_click is set to 1; otherwise, it’s 0.
3. A repeat_cycle object that decides whether the same sequence should be repeated.

The repeat_cycle uses a simple condition:

valid_click == 0

This means the loop repeats until a valid click is made. If the participant clicks outside the designated rectangles, the sequence restarts, waiting again for a proper response. Once the click is valid, the loop exits and the trial proceeds to data logging.

This design elegantly combines visual clarity with strict response control. The dual-sketchpad setup isolates the clickable zones from the visible text, preventing unwanted ROI overlaps, while the repeat mechanism ensures that only deliberate, valid responses are recorded.

If you open your browser's console, you'll see that I'm logging there what is being clicked on so that you can check what is going on (to make your browser's console visible, hit CTRL + SHIFT + I (or the equivalent on a Mac if you're using Mac).

Right after a mouse click, javascript code processesi it:

// store the choice
vars.choice = vars.cursor_roi; // 'vocal' or 'consonant'

// Store what was clicked
vars.choice = vars.cursor_roi;

// Determine if the click was on a valid ROI
// Numeric flag for the loop condition (OSWeb-friendly)
vars.valid_click = (vars.choice === 'vocal' || vars.choice === 'consonant') ? 1 : 0;


// if you have a variable 'correct_response' per trial:
vars.correct = Number(vars.cursor_roi === vars.correct_response);

// Print the clicked region and coordinates in the browser console
console.log('Choice:', vars.cursor_roi);
console.log('X position:', vars.cursor_x);
console.log('Y position:', vars.cursor_y);

I tested it in Chome on my computer and the task runs smoothly, things appear where they are supposed to.

Hopefully this should give you the basis you need to carry on developing your task.

Here it is:

Mousetest Fab.osexp

I programmed it using the latest version of Open Sesame: 4.1.3 , running OsWeb 2.2).

Best,

Fabrice.