Updating regression on mouse move should be optional about webgazer

[Skylion007]

I was actually thinking the same thing. However, it can be correct under certain circumstances. For instance, if you are playing a game where the mouse acts as the player, then you would be looking at the mouse. As such we might want to include a toggle. Additionally, I think we need to be more intelligent about how we handle mouse movements. For instance, dragging the mouse might have a different behavior. We should also differentiate between slight movements of the mouse and large movements. I think the issue with ignoring mouse movements completely is that it takes much longer to train the model otherwise as clicking provides fewer points of data.

We could also try to make it train using the mouse trajectory to the target or other heuristics. This is definitely an open question and we'd love feedback.

Sent from my iPhone

On Jun 18, 2016, at 10:53 AM, Alex Puschinksy [email protected] wrote:

The tracker regression data is updated on mouse click and mouse move under the assumption that the user is looking at the mouse pointer while performing those action. I think that for mouse movement this assumption is wrong. IMO in most cases the uses looks at the target of movement, instead of the mouse pointer.

What do you think?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[alexpapster]

Alex, your concern is not baseless, indeed the cursor movements are not
that strongly correlated with the gaze. This is the reason that they only
contribute for 1-2s in our model and not permanently as clicks do. Even if
there is a looser relationship between cursor movements and gaze there is
still intention when the user moves their mouse. If you check our paper we
have ran a long user study that showed improvement in the accuracy when
using this model.

What Aaron suggests is one of the things I want us to explore next. We
already know that different users interact differently with certain pages,
e.g. search engine result pages. It's worth investigating those patterns
and perhaps personalize WebGazer based on what type of user we detect.

On Sat, Jun 18, 2016 at 11:34 AM, Aaron Gokaslan [email protected]
wrote:

I was actually thinking the same thing. However, it can be correct under
certain circumstances. For instance, if you are playing a game where the
mouse acts as the player, then you would be looking at the mouse. As such
we might want to include a toggle. Additionally, I think we need to be more
intelligent about how we handle mouse movements. For instance, dragging the
mouse might have a different behavior. We should also differentiate between
slight movements of the mouse and large movements. I think the issue with
ignoring mouse movements completely is that it takes much longer to train
the model otherwise as clicking provides fewer points of data.

We could also try to make it train using the mouse trajectory to the
target or other heuristics. This is definitely an open question and we'd
love feedback.

Sent from my iPhone

On Jun 18, 2016, at 10:53 AM, Alex Puschinksy [email protected]
wrote:

The tracker regression data is updated on mouse click and mouse move
under the assumption that the user is looking at the mouse pointer while
performing those action. I think that for mouse movement this assumption is
wrong. IMO in most cases the uses looks at the target of movement, instead
of the mouse pointer.

What do you think?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#39 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AGGopKY3bZCqZBiNQXKSruobw30SfluQks5qNBARgaJpZM4I49no
.

---

Alexandra http://cs.brown.edu/people/alexpap

[ct-martin]

For anyone finding this issue later, I had this issue and was able to address it by using the following code. In my case, the mouse movement was adding a lot of noise/drift which was impacting feeding the gaze data to another library; as mentioned above, this may not be appropriate for all applications.

// Trimmed down version of webgazer's click listener since the built-in one isn't exported
// Needed so we can have just the click listener without the move listener
async function clickListener(event) {
  webgazer.recordScreenPosition(event.clientX, event.clientY, 'click'); // eventType[0] === 'click'
}

function setup() {
  // Don't use mousemove listener
  webgazer.removeMouseEventListeners();
  document.addEventListener('click', clickListener);
  // ...
}