Hello there, my name is Carlos Elmadjian, I’m a PhD candidate at the University of
São Paulo, Brazil, and one of the authors of GazeBar: Exploiting the Midas Touch in
Gaze Interaction.
We know that one of the central issues in gaze interaction is the Midas Touch problem.
The name is a reference to the greek myth of king Midas, who turned everything he touched
into gold.
The analogy is that, although it is tempting to perform a selection just by looking at a
target, after a while it becomes clear that the user cannot look anywhere without issuing
a command.
Therefore, because of the Midas Touch problem, all gaze interactive techniques have some
sort of “clutch” or safety mechanism to prevent it.
With dwell-time selection, for example, we require the user to look at a target for a
certain time threshold before issuing a command.
There many other alternatives to trigger a selection, like following a moving target
with the eyes or performing a set of gaze gestures along a certain path.
And of course, when multimodal interaction is an option, we can combine gaze pointing
with manual input for selection.
In the end, we argue that these safety measures are a source of disruption in user flow, since
they either add additional latency or require unrelated eye movements to reach a task goal.
GazeBar came forth as an attempt to get rid of these safety measures in gaze interaction
without falling into the Midas Touch problem.
We soon realized that we could come up with selections that are perceived as just-look-to-select
and are generally safe if we used the gaze paths that users make to perform selections
in a task.
We designed GazeBar to be a hierarchical toolbar containing mode options, as a part of a more
complex interactive scenario.
We decided to focus on mode switching because many applications such as digital painting
require constant mode changes and present an extensive set of options, which can be
very challenging for non-expert users.
Also, in mode switching people are expected to navigate through menus and submenus, but
mode selections are generally quick.
In our design, we assume the user is always performing the primary task in the central
area of the screen using a different input, like touch.
So, to change a mode, the user only has to look at an option in GazeBar and then back
again to central area.
In practice, selection is triggered by using a goal-crossing mechanism to determine when
the eyes get in and out of the bar.
The primary bar is always located at the bottom of the screen, while secondary bars are placed
at the remaining edges.
Because eye tracking data is typically noisy, we use a threshold for when the focus over
a button starts and another one for when it ends.
Whenever focused, a mode button changes its color and size to indicate which option is
being gazed, but while in the bar area, no selection is possible, so the user can navigate
safely there.
The only restriction we pose in terms of free interface exploration is if the user gives
up on switching a mode when already inside the bar.
In this case, he or she has look at the current active mode before exiting the bar.
In order to assess our design, we implemented a prototype on top of the digital painting
application Krita.
In this proof of concept, an eye tracker below the monitor captures eye data that is processed
by GazeBar in order to provide state changes in visual feedback and mode selection.
Communication between Krita and GazeBar is done through mapping of hotkeys.
Although we could not perform a user study due to the pandemic crisis, we experimented
with our prototype and investigated a few theoretical performance models to draw some
insights.
Based on these models, a conservative estimate is that mode switches with GazeBar should
take, on average, 500 ms.
Note, however, that because GazeBar’s selection mechanism is based on the actual path that
users make, it can only be slower than other methods if users make more mistakes with GazeBar
on average.
But based on our own experience so far, it is unlikely that we will see a large number
of errors, but because GazeBar is very fast, error recovery has low cost.
It is also important to notice that GazeBar is not a general-purpose solution like many
other techniques, such as dwell-time selection.
The most important message here is that it is possible to improve flow and gaze interaction
efficiency with a just-look-to-select mechanism.
And though we cannot apply the exact same solution of GazeBar for every interactive
scenario, we can derive its principles to devise similar approaches everywhere.
In a future work, we intend to evaluate user experience and performance with GazeBar.
Thank you all for watching.