Project

General

Profile

16062015

Présents:
Uservalue: Julien Roland
EDANA: Carole Baudin, Chloé Lecomte
ISIC: Nabil Ouerhani, David Grunenwald, Claudia Gheorghe, Andreea Mihet

Excusés: Philippe Geslin, Gaëtan Bussy, Pierre Roduit, Alexandre Sierro

Prochaine séance:
10 septembre 10h00, Campus Arc 2, salle 257

Objectifs de la première étape du projet (qui se termine en décembre 2015)

  • Se focaliser sur une préanalyse.
  • Montrer qu'on peut faire gagner du temps à des experts.
Pour cela, on va:
  • choisir un site simple ou la navigabilité est bien pensée ou des mock-ups (à condition que tous les scénarios soient implémentés)
  • se concentrer sur une liste de métriques bien définie
Plutôt qu'un rapport imprimable, Julien propose un rapport interactif, comme un dashboard / cockpit intelligent qui:
  • donne un vision synthétique et aide à la décision
  • est simple et fiable (si on veut penser plus loin pour la partie "crowd" du projet)
  • facilite l’intégration et la visualisation des données
  • sépare les données de base et les interprétations

Cet outil devrait donner une vision globale et pourrait simplifier l'analyse faite par les ergonomes. Il ne s'agit pas d'un interpréteur automatique des données, on laisse le diagnostic final aux experts.

Un tel dashboard pourrait contenir:
  • le nombre de participants
  • un rappel de la consigne
  • la définition des zones d'intérêt (par page)
  • les métriques prises en compte (time-to-first-fixation, nombre de fixations...)
  • les données de base (bien séparées de l'interprétation)
  • des suggestions d’interprétations: des représentations visuelles relevantes (heatmap, scanpath, time-to-first-fixation avec les zones d'intérêt, camembert, histogrames...)
  • des données de performance: réussite, échec, hésitation (HEVS)(ce qui demanderait de définir l'hésitation) - émotions discriminantes
  • les séquences filmées (pour pouvoir faire par exemple une compilation des "best of" pour le client, pour pouvoir faire le marquage des vidéos...)

De manière générale, l’eyetrakcing n’est réalisé que lorsqu’on n’a pas d’autres moyens de faire autrement, du fait de sa complexité et du temps nécessaire.Ces tests ne sont faits que sur des sites déjà optimisés, donc «bien pensé», où l’expert ne peut plus préconiser des changements selon son expertise. L’Eyetracking sert alors à canaliser les stratégies, et n’enregistre pas des «randoms strategies» qui ne voudraient rien dire. Par exemple, quand on hésite entre un chemin A/B, on utilise l'eyetracking pour trancher.
Le faire sur un site comme neuchatel.ch n'apporterait rien sur le site en lui même, tellement les stratégies d'exploration sont chaotiques.

Avancement EDANA

Tests avec Ogama: 10 personnes, site www.neuchatelville.ch, limite de temps: 2 minutes, mission: trouver les disponibilités de la collégiale pour louer
  • Résultats: taux de réussite: 20%
  • Identification de quelques limitations d'Ogama (à voir la page Problèmes rencontrés)
TODO:
  • Rencontrer Marco Pedrotti, postdoctorant de l'UniNE (sciences cognitives et travaux sur l'eyetracking)
  • Faire un vrai protocole de test
  • Proposer une maquette du dashboard

Avancement ISIC

  • Installation de la nouvelle version d'Ogama, problème de scrolling partiellement résolu, ça prend en compte le scrolling sur des sites développés de manière classique
TODO:
  • A voir quel est le moteur de rendu des sites web dans Ogama
  • A améliorer Ogama pour prend en compte le "back", c'est un point important (les utilisateurs risquent d'être perturbés s'ils ne sont pas dans les conditions standards d'un navigateur web) Et aussi les fenêtres qui s'ouvrent dans un nouveaux onglet.

Séance préalable avec UserValue

Présents : Carole Baudin, Gaëtan Bussy, Claudia Gheorghe, David Grunenwald, Chloé Lecomte, Julien Roland

Objectif de la séance :
1. Validation et/ou complément du récapitulatif de l’état de l’art et synthèse de nos réflexions actuelles envoyé ci-joint.
2. Commentaires / analyse de premier résultats de tests sur le programme actuel OGAMA.
le second point de la séance a été finalement été traité lors de la séance plénière qui suivait.

A propos des métriques

  • pas de projection bijective entre les deux espaces «métriques» et «analyse». Par exemple, on ne saura pas si +de temps passé dans une région veut dire que la région est intéressante ou difficile à comprendre.
    Le diagnostic est toujours délicat à faire et doit se faire par rapport à la consigne, au site, au contexte...
  • Précision sur la Durée passée dans une région" (dwell time​ : somme totale des durées de fixations,​ ou nombre de fixations, dans le cas où toutes les informations sont les mêmes dans la région)
  • Enfin, on pourrait ajouter (si disponible) la "Durée moyenne de fixation" qui peut indiquer la quantité de traitement cognitif nécessaire ; mais cela peut également révéler un "effet émotionnel", comme p.ex. une image attractive et évocatrice.
  • Ces métriques sont les métriques standards qui sortent des logiciels sur le marché. C’est important de savoir comment sont calculés ces métriques : par exemple, le «gaze» ne veut rien dire si on ne sait pas comment il est calculé.

A propos du schéma générique

  • Consigne : bien vérifier que le testeur ait compris (faire un retour du genre : avez-vous bien compris la consigne, ou pouvez vous reformuler la consigne)
    Les mettre dans un «mood» où ils font sérieusement le test, et où ils se sentent impliqués
    Contrôle de la position par rapport au clavier : le contrôle de la qualité est essentiel !
  • Gros intérêt du projet ErgoCrowd sur le traitement des données (2 à 4 jours pour faire un rapport selon userValue)
  • Place du mandant : la proposition de faire intégrer le mandat dans la définition du test est mis en question. Pour UserValue, il y a un trop gros gap entre la formulation de la demande et la mise en place du protocole, qui nécessite des connaissances en expérimentation que le mandant n’a pas forcément.
  • Critères de succès : Pour UserValue, trois types de résultats – échec/succès/succès avec hésitation. Il faut donc définir l’hésitation (l’utilisation du temps est trop relatif. Nombre de clics ? Temps de découvrabilité ?)
  • Il est possible de définir les AOI en amont du test, mais souvent l’expert a besoin de reprendre les réglages des AOI pour être sur de récupérer les données des tests (trop petits ou trop grands
  • Questionnaire : On peut utiliser le single ease questionnaire qui évalue la perception de la difficulté à réaliser une tâche.
    Sans modérateur, il est extrêmement difficile de faire de l’autoconfrontation (les testeurs oublient vite ce qu’ils ont fait sur le site)
  • Prérapport : proposition d’interprétation et synthèse des données

Sur le workflow

  • Mise en place du test : Proposer des vidéos pour montrer comment se déroule un test utilisateur (genre de tutorial) ?
  • Récupération de vidéos . Les émotions restent encore intéressantes, surtout pour leur aspect démonstratif (au client)
    Proposition de UserValue : selon la consigne, retrouver la séquence individuelle qui montre un passage de difficulté ou d’ennui (en utilisant des marqueurs d’étapes)
  • Calibration de l’eyetracker : Uservalue vérifie en temps réel la calibration du dispositif et demande à recommencer si ça ne marche pas. Il faut trouver un autre moyen.
  • Test nav : Définir le début de la séquence (timesequence)
  • Calibration par l’expert . Sampling rate : peut être diminué. Selon Marco P, Eyetribe fait un sampling de 33Hz et Ogama de 60Hz. Il faut changer sur Eyetribe, mais on ne sait pas comment.
    Size of buffer : à définir en fonction de la plus petite capacité d’un vieil ordinateur que le testeur peut potentiellement utiliser
    Diameter of ratio : à définir à posteriori et pas en amont