Pointage au regard (PWIMP 2020-2021)
Le but de ce projet est de pouvoir sélectionner des cibles à l’écran avec le regard, avec un système de sélection en cascade en cas d’ambiguïté.
Sommaire
Membres de l’équipe
- Ulysse RIGAUT (MMIS)
- Alexis SONOLET (MMIS)
- Jules SAGOT-GENTIL (MMIS)
- Clément MALLERET (MMIS)
Contexte et objectifs
Nous avons choisi ce sujet tout d’abord car les technologies d’eye-tracking nous intéressent particulièrement. Nous pensons par exemple que cette technologie permettrait une navigation internet plus efficace, car cela permettrait de sélectionner des liens très rapidement. Un des problèmes que l'on peut rencontrer avec l'eye tracking est son manque de précision par rapport à la souris (on ne pointe pas un pixel de l'écran mais une zone vers laquelle il est probable que l’œil regarde). C'est pourquoi nous avons choisi d'implémenter une sélection en cascade, c'est à dire une sélection qui prend en compte les différentes cibles contenues dans la zone du pointage de l'eye-tracker et qui permet à l'utilisateur de choisir interactivement la cible à cliquer.
Solution proposée
Au départ, nous voulions utiliser l'API fournie par Tobii pour récupérer la position approximative de l’œil. Mais après avoir installé l'eye-tracker, il était possible de déplacer la souris sur la zone pointée par le regard en appuyant sur une touche. Nous avons donc choisi de programmer un prototype d'interface qui implémente le choix de cible avec escalade.
Spécification technique
Notre prototype d'interface doit être capable de:
- Afficher des cibles à l'écran : Des cibles de différentes tailles et de différentes couleurs doivent être affichées à l'écran comme défini dans un fichier de configuration des cibles
- Affichage d'un pointeur adapté : L'eye-tracker ne fournit pas réellement un curseur, mais plutôt une zone vers laquelle on regarde. Cette zone doit être modélisée par un pointeur rectangulaire
- But de l'exercice : Le but du joueur est de cliquer sur toutes les cibles
- Clic sur cible : Quand il n'y a pas d’ambiguïté sur l'interface que l'on doit choisir, l'interface doit éliminer la cible. Quand il n'y a plus de cibles, l'exercice est terminé et on affiche le temps
- Clic sur cibles multiples : Quand il y a ambiguïté sur le choix de cible, l'interface doit réaliser un zoom progressif sur la zone sélectionnée (escalade) afin de pouvoir choisir précisément la cible
- Affichage de la couleur à sélectionner : Chaque cible a une couleur et un nombre unique, on doit pouvoir indiquer à l'utilisateur quelle est la cible qu'il doit sélectionner. La numérotation des cibles permet d'éviter les ambiguïtés de couleurs trop proches.
Problèmes rencontrés
- Clarté de l'escalade :
Au début, lors de l'escalade, nous faisions un simple zoom instantané. Cela pose problème au niveau de la compréhension de l'utilisateur, quelle cible se retrouve où après le zoom : l'escalade était trop brutale. Pour pallier à ce problème, nous avons opté pour un zoom progressif (voir vidéo dans la section suivante). Cela permet de voir l'évolution de la position des cibles, ce qui ne perturbe pas l'utilisateur.
- Pertinence des données :
Étant donné le contexte particulier de cette année, les tests n'ont pu être réalisé que par une poignée de personnes pour le pointage au regard. Cela peut donc mener à des biais dû au faible nombre de données, et les données avec l'eye tracker en particulier peuvent ne pas être représentatives.
- Ambiguïté des cibles :
Nous avons d'abord différencié les différentes cibles seulement avec leurs couleurs. Cependant, avec un nombre de cibles élevés, cela a vite posé problème : plusieurs couleurs étant trop proches, on se trompait non pas sur une erreur de ciblage mais sur une erreur de reconnaissance de la cible, ce qui pouvait fausser les mesures. Pour résoudre ce problème, on a rajouté des numéros pour identifier chaque cible. Cela ne rend pas l'information de couleur totalement inutile : en effet, les numéros étant distribués aléatoirement, avoir l'information de la couleur permet d'accélérer la recherche, en ne regardant que les numéros des cases ayant une couleur proche.
Ce qui a été réalisé
Dû aux circonstances particulières du COVID, les mesures pour l'eye tracker n'ont pu être réalisées que sur 5 personnes. Ce manque de données sera pris en compte dans leur interprétation.
Interface de test
Afin de tester notre escalade, nous avons développé une interface simple consistant de plusieurs boutons. Une cible est désignée en haut à gauche de l'écran. A chaque fois qu'une cible est atteinte, elle est supprimée de l'interface, et une nouvelle est désignée. On continue ainsi jusqu'à avoir éliminé toutes les cibles.
Remarque : Le fichier ci-dessus est une vidéo accessible ici. Malheureusement, seule la prévisualisation de cette vidéo peut être affichée sur cette page.
Un éditeur a aussi été fait, afin de pouvoir créer facilement de nouveaux scénarios de tests.
Scénarios de tests
Le but ici est de comparer les performances d'acquisition de cibles par rapport à un système clavier-souris classique. La difficulté est de choisir des scénarios et une métrique adaptés afin de comparer les performances. Nous avons opté pour une mesure du temps total d'acquisition d'un certains nombre de cibles. En effet, calculer le temps d'acquisition 1 cible par 1 cible n'a pas de sens ici, car le système repose sur l'escalade, qui nécessite d'avoir plusieurs cibles proches, qui agissent comme des distractions pour la cible principale.
Ainsi, la principale variable ici est la densité des cibles : en effet, plus elle sera élevée, plus le ciblage au regard sera incertain. On peut ainsi essayer de voir à partir de quelle densité le ciblage au regard devient trop peu précis pour être réellement utile. On mesure aussi le temps passé dans des escalades, afin de voir le temps perdu à cause des incertitudes. Ce temps perdu va notamment permettre de voir l'évolution possible de la vitesse d'acquisition de cible avec un meilleur eye tracker : plus il sera précis, plus le temps passé en escalade diminuera, avec 0 pour minimum.
Dans ce but, on va donc utiliser divers scénarios de test :
- Des grilles de boutons régulièrement répartis : En effet, leur densité est facile à contrôler et évaluer, et cette disposition permet de bien mettre à l'épreuve le ciblage au regard. Ce cas se rapproche par exemple à une navigation sur des pages internet, ou l'on va chercher à cliquer sur des liens répartis sur la page.
- Des cibles espacées: Ici, on écarte grandement les boutons, afin de comparer le temps d'acquisition de cibles dans le cas où il y a un grand parcours à faire entre 2 cibles à la souris (ou au regard).
- Des cibles type "Liens hypertextes": Cibles rectangulaires longues, dans le cadre d'une navigation internet par exemple, quand on cherche à sélectionner un lien hypertexte dans une liste.
- Type texte: On utilise ici de nombreux petits rectangles, simulant du texte. Cela permet de se mettre dans des situation où par exemple on cherche à insérer du texte à un endroit précis.
Résultats
Temps moyens de pointage
Valeurs
On peut observer les résultats dans ces tableaux (tous les temps sont en secondes):
| Pointage à la souris | Pointage au regard | Temps passé en escalade | |
|---|---|---|---|
| Temps moyen type "texte" | 43 | 59 | 14 |
| Temps moyen grille 32px de largeur/bouton | 149 | 218 | 39 |
| Temps moyen grille 48px de largeur/bouton | 87 | 143 | 24 |
| Temps moyen grille 64px de largeur/bouton | 131 | 187 | 25 |
| Temps moyen grille 96px de largeur/bouton | 96 | 121 | 9 |
| Temps moyen type "lien hypertexte" | 43 | 56 | 10 |
| Temps moyen scénario espacé | 35 | 36 | 0 |
| Temps de pointage au regard - temps passé en escalade | Différence avec pointage à la souris | |
|---|---|---|
| Temps moyen type "texte" | 45 | +2 |
| Temps moyen grille 32px de largeur/bouton | 178 | +29 |
| Temps moyen grille 48px de largeur/bouton | 119 | +32 |
| Temps moyen grille 64px de largeur/bouton | 162 | +31 |
| Temps moyen grille 96px de largeur/bouton | 112 | +16 |
| Temps moyen type "lien hypertexte" | 46 | +3 |
| Temps moyen scénario espacé | 36 | +1 |
Visualisation des données
Pour chaque test effectué, nous avons créé un nuage de points. Chaque point représentant une personne ayant participé au test. En abscisse, on place le temps effectué à la souris, et en ordonné, celui effectué à l'eye tracker. On trace aussi la courbe Y = X, permettant de savoir lequel des deux temps est supérieur à l'autre. En effet, lorsque les points vont être au dessus de la droite, cela veut dire que le temps à la souris est inférieur, tandis que lorsque les points sont au dessous de la droite, le temps à l'eye tracker est inférieur. Cela permet donc de séparer les cas où l'eye tracker est mieux que la souris, en observant un ensemble de données plus large que seulement la moyenne de tous les participants.
Interprétation
La première observation frappante est que le temps de pointage au regard est grandement supérieur au temps à la souris. Une différence était attendue : en effet, on doit compter le temps des escalades. On peut cependant aller plus loin. En effet, si l'on soustrait le temps passé dans une escalade au temps d'acquisition au regard, on devrait s'attendre à retomber proche du temps à la souris : en effet, enlever le temps passé hors de l'escalade lors de l'acquisition au regard correspond aux mouvements de l’œil que l'on ferait avant de cliquer sur une cible à la souris.
En calculant ceci, on remarque qu'en réalité, un écart - assez conséquent - est présent. Cela peut s'expliquer par plusieurs facteurs :
- Manque de données et de variété de ces données : en effet, l'expérience n'ayant pu être réalisée que sur 5 personnes, les résultats sont possiblement biaisés. Notamment, étant tous les 5 étudiants à l'ensimag, nous sommes naturellement très habitués à utiliser une souris, mais peu familiers avec l'eye tracking. Cela entraine une acquisition rapide à la souris dû à l'habitude, mais le manque de pratique avec l'eye tracker entraîne des erreurs, comme par exemple effectuer une sélection alors que l'on regardait légèrement à coté, ce qui entraine un zoom inutile, et une perte de temps notable.
- Désorientation dû au zoom : si le zoom permet d'avoir une continuité durant l'escalade, ce qui permet de ne pas perdre de vue les éléments à l'écran après le zoom, cela nécessite tout de même un temps d'adaptation, et nécessite de suivre ce qu'il se passe. Le même problème se produit lors du dézoom, ou l'on doit se refamiliariser avec les éléments globaux.
- Imprécisions du regard : en effet, on a pu remarquer le long des expériences que parfois, notre regard se situe légèrement à coté de ce que l'on veut cibler : même si l'eye tracker à raison sur la position réelle du regard, nous ne concentrons parfois pas notre regard pile au bon endroit, ce qui peut entrainer des incertitudes et des pertes de temps.
On peut aller plus loin, en s'intéressant aux graphes de temps à l'eye tracker par rapport au temps à la souris. On voit notamment que dans le cadre du scénario espacé, l'eye tracker est aussi performant, voir plus, que la souris, ce qui s'explique facilement du fait qu'il n'y a pas d'escalades dans ce scénario : on ne souffre donc pas de ses inconvénients.
Cependant, dans tous les autres cas, on voit un net avantage de la souris sur l'eye tracker, dû, justement, à ce zoom. On peut aussi comparer les scénarios entre eux : on voit que pour la grille de cases de taille 96px, les points sont plus proches de la droite Y = X que dans des grilles plus petites par exemple. Comme on pouvait s'y attendre, l'eye tracker fonctionne mieux dans des densités faibles, avec moins d’ambiguïtés. Quand on regarde des tailles de boutons plus faibles, on observe aussi l’apparition de points plus irréguliers et éloignés, témoignant des difficultés de sélection dans ce genre de cas. Ces irrégularités disparaissent cependant pour le scénario "texte", malgré ses cibles petites et rapprochées, ce qui peut s'expliquer par le fait que l'on ne simule ici qu'une seule ligne, ce qui limite le nombre d’ambiguïtés par rapport à un cas ou l'on aurait aussi des lettres au dessus et en dessous. Ce cas est cependant réaliste et représentatif : en effet, on peut imaginer coupler notre dispositif d'escalade à un script qui augmente l'espacement entre les lignes, ce qui réduit les incertitudes à une seule ligne.
Ainsi, il reste préférable de limiter l'eye tracking à des cas où il y a relativement peu de cibles rapprochées, ce qui est le cas pour des tâches telles que la sélection d'un résultat pour une recherche internet par exemple.
Conclusion
Nous observons ainsi que globalement, le pointage au regard semble moins performant qu'un pointage classique à la souris. En effet, des problèmes de désorientations, de distractions, et de pertes de temps dus au zoom sont ici à blâmer, en plus de problèmes de focus de l’œil, quand on regarde légèrement à coté de ce que l'on cherche à cibler. Cependant, l'escalade s'est avérée très efficace malgré son coût en temps pour lever les ambiguïtés : il est extrêmement rare d'avoir besoin de recourir à un deuxième niveau d'escalade, et la sélection se fait très facilement et naturellement. Ainsi, le zoom parait être une solution acceptable, mais qui a ses défauts.
Cependant tout n'est pas noir, les performances restent honorables : ce dispositif est environ 1.5 fois plus lent que la souris dans les pires cas, ce qui en fait une bonne alternative pour des personnes en situation de handicap. Il pourrait ainsi être envisagé de continuer des tests avec des personnes dans ce cas, qui pourraient confirmer ou non l'ergonomie globale du système. De plus, après une période pour leur permettre de se familiariser à l'eye tracking, cela pourrait permettre d'avoir des résultats de meilleurs qualités dans le cadre d'une utilisation prolongée, qui pourrait contrer le biais dû à l'aisance que nous avons à la souris. Finalement, une amélioration de la précision du tracker pourrait mener à une baisse du temps passé en escalade, ce qui améliorera les performances.
