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).