Advanced
Here, we look at some advanced topics when it comes to designing eye tracking UI:
Locking vs Non-locking
When it comes to gaze aware UI, we talk about two different types: non-locking UI and locking UI. Locking to UI elements allows the user to make visual changes to other elements, but comes at a learning cost. A non-locking UI is simple and intuitive but does not allow for this. The controller design and layout also plays a role in this.
Non-Locking
The simplest and most intuitive approach when designing the interaction of your UI elements is to make them react to the user’s gaze and only work if the user maintains gaze on them. When the user looks away from them, the interaction will stop. This can be problematic though, if the user wants to make a continuous change to another element that changes its appearance. Let’s say that by sliding a slider, a cube in the user’s periphery changes its size. Due to the nature of our eyes - that we use them to take in information and that they are not fully controllable but act subconsciously - our eyes will be drawn to the visual changes occurring in our field of vision. If the user then makes visual changes to an object with the help of a UI element, the eyes will subconsciously be drawn away from the UI element and towards the object that is changing. This will then stop the interaction in a non-locking UI and quickly becomes frustrating for the user.
Locking
One way to solve this problem is to introduce a lock-on mechanism to the UI. This allows users to be able to lock on to UI elements and then freely look around while updating its values. One example for how to design this lock-on mechanism is to use a button press down as a lock-on state. If the user looks at a UI element, for example a slider, and presses down a button on the controller and holds it down, the user is locked on to the slider. The user can now freely look around while moving the controller left and right to update the slider’s value.
This is less intuitive than a non-locking UI and users might not be aware that they are locked on to a UI element.
Controller Design
Our initial approach for a lock-on mechanism was to use the touchpad on the VIVE controller because we felt that using the touchpad to interact with UI required the least amount of hand movement and was very satisfying. We quickly discovered a problem with this approach; some users, we called them “resters”, naturally rested their thumb on the touchpad. This made them be stuck in a lock-on state by default. Since we didn’t wish to tell users that they were holding the controller the wrong way (from our perspective), we changed the lock-on mechanism to the trigger button on the VIVE controller. Users could now interact with UI by clicking and holding down the trigger button and move the controller left and right.
Depending on how the controller is designed, different approaches on how to design the lock-on mechanism are available but with the VIVE controller, we recommend using touchpad for non-locking UI and trigger click for locking UI.
You can try this out in our UI Code Example, where there is a Touchpad Menu using non-locking UI and a Trigger Menu that uses locking UI.
Slider Affordances
Most sliders on mobile, desktop or in VR can be updated by clicking anywhere in the slider, for example 80%, and the slider instantly updates to that value. This doesn’t work that well with eye tracking because it should not be considered as a pixel perfect pointer. If the user looks somewhere on the slider and clicks a button, the user expects it to jump to the place where they look, not roughly there, and if it doesn’t go where the user expects it to jump, we break the user’s expectation and the experience feels bad.
To avoid this issue, we either have distinctive steps where the user can look and click, as long as there is enough space between each, or the user selects the whole slider by looking anywhere on it and sliding the touchpad or clicking and moving the controller to update its value.
In this video, the UI slider grows and lights up when the user looks at it and first when the user touches the touchpad, the handle shows up.
It’s important for the slider to not have affordances, incentivizing the user to look anywhere on the slider to be able to instantly update its value there. If the slider handle is shown or if the slider has visible steps, the user might believe that they can do this. By displaying these, first when the user have started to interact with the slider, e.g., touched the touchpad, the affordance tells a story of how the interaction is done by sliding or dragging the handle, rather than it jumping to specific values.
You can try this out in our UI Code Example.