Millisecond Forums

Is there any way to allow a response from a keyboard AND mouse on a given trial?

Thanks!
Derek

Derek,

Inquisit does not currently allow responses from different input devices on a given trial. This is certainly something we will consider for a future release.

For clarification, do you wish to allow either a mouse or keyboard response on a given trial, or would your task require a combination of mouse and keyboard signals.

Cheers,
Sean

I needed to allow a given trial to accept mouse and keyboard input. While this functionality would seem like a good feature to have, I was inquiring about it for a less obvious reason.

Basically, I needed to allow Inquisit to expose the mouse cursor during trials that accept keyboard input. My research requires participants to respond by simply moving the mouse up, down, left, or right - without ever clicking a mouse button or pressing a key. Since Inquisit does not support this type of directional-based mouse input for a response, I wrote a program that hooks into the mouse and keyboard at a low, system-wide level. This program sends keyboard presses when the mouse is moved. However, I initially couldn't get it to work with my Inquisit script (which simply shows a random "slide show" of video clips and takes a keyboard response). After exploring different things, it turns out that my little program WAS in fact working, but that the mouse was apparently disabled by Inquisit when my script ran. I discovered this after finding out that my program was able to send keys to trials that allow the mouse to be on-screen (e.g, Likert scale trials). In the end I was able to get it to work by converting all my trials to Likert trials and changing my program to send a number plus the enter key when the mouse was moved: Up=1+Enter, Down=2+Enter, Left=3+Enter, Right=4+Enter. I also hid the text labels that the Likert trials show to a position off-screen. Now everything seems to work well and I can gather data for my dissertation!

Got it. It would probably be easier to enhance Inquisit to support directional mouse movements than simutaneous keyboard and mouse.

We could allow you to specify a direction in degrees along with distance. For example, 0 degrees at 200 pixels would equate to moving the mouse 100 pixel upward (including any left or right drift).

Or, we could allow you to define screen regions, and define a response as movement to that region.

Would either of these meet your requirements. Any preference?

Thanks,
Sean

Both these options sound like they could work. I guess from a usability standpoint I like the degrees method better. I say this because drawing invisible regions on the screen may be hard for the user to do. For example, I would need to set up 4 quadrants along the edges of the screen for my experiment, however, I would want not want these regions to stand out at all during the study. Thus, it would be hard to know exactly where the borders of these areas are without some way to see them while writing and testing the script. I suppose the disadvantage of the degrees method is that it is less flexible than the screen region method. For example, I *suppose* you could design several regions that would allow you to detect curvilinear mouse movements. Nonetheless, my gut reaction is that I would like working with the degrees method better.

I would also need a couple other important options: 1) To be able to have the mouse cursor return to the center of the screen at the start of every trial (I guess this would only matter if we were using the screen region method though). 2) I would also need to be able to completely hide the mouse cursor during each trial. Luckily, I was able to implement both these things in the program I wrote.

Here's my 2 cents on this feature:
I found the problem of converting mouse movements to keypresses to be trickier then I thought. I had to take several things into consideration:

* How far the mouse has to move in order for it to register a response.
The key was only sent after the mouse moves a certain distance. Thus, my reaction time data will be a bit inaccurate relative to when the mouse was initially moved.

* The "error tolerance" for registering a response.
This has two parts. First, people do not move the cursor in a straight line. Second, people do not move the mouse with a constant velocity and sometimes they stop for a movement and then continue again (e.g., to move the mouse to the center of the mouse pad). I solved the first part of the problem by looking at the absolute distance moved along the X and Y axes. I solved the second problem by tweaking the speed of the mouse cursor and the distance it had to move to register a response.

* Constraints of the screen size.
If the mouse cursor ever ended up on an edge of the screen, my program could no longer detect a mouse movement in that same direction. To solve this I first tried to lower the mouse speed to super-slow, which worked okay but wasn't ideal. I eventually was able to move the mouse cursor to the center of the screen after each response was registered-this solved the problem.

* "Carryover" mouse inputs
I found that participants often skipped through multiple trials with a single mouse movement. Basically, they would continue to move the mouse after the trial had ended and thus it would register that same movement as a response for the next trial(s). I ended up solving this by putting a "timeout" timer in my program so that no keys would be sent until 1 sec had passed (which is my ITI).

Thanks for the feedback.

Note that you can hide the mouse cursor in Inquisit by setting the input device to touchscreen as opposed to mouse. That's basically the only difference between the two modes.

Also, could you solve the carry over problem by requiring subects to move the mouse a center region on the screen (could be a circle, square, etc.)?

Cheers,
Sean

Thanks for the touchscreen tip! That will really be a big help as my method to hide the mouse cursor was sort of tedious to do.

As for the cary over problem, I can imagine circumstances where having the user return the mouse to the center of the screen would not be ideal. This wouldn't work well in my study for a couple of reasons. First, I have to hide the mouse so this would be impossible. Second, I will be asking participants to respond as quickly as possible, basically trying to capture their reflexive reaction to on-screen stimuli moving in different directions. I would rather not have the participant have to think about carefully moving the mouse back to the center of the circle after every trial.