Project

General

Profile

22022016

Présents:
Nabil Ouerhani
Carole Baudin
David Grunenwald
Claudia Gheorghe
Julien Roland
Laura Maillard
Pierre Roduit - skype
Alexandre Sierro –skype

Avancement technique :
  • Ajouter des questionnaires posttest (Google Forms)
  • Une première version de la base de données du Dashboard (qui permet de redessiner les chartes de chaleur et le scan-path)
Phase avant Test :
Environnement physique :
  • Important de définir une zone idéale pour le positionnement de l’eyetracker (distance de l’utilisateur, etc.)
  • Important de définir un environnement physique idéal (position, matériel, etc.) et dégrader sa qualité si le test est effectué hors labo. L’idéal est de réduire au maximum le champ des possibles en trouvant différentes stratégies : privilégier une chaise rigide, positionner le clavier proche de l’utilisateur (ce qui le pousse à se redresser), minimiser les déplacements du testeur, etc.
  • Possibilité d’enregistrer le bruit ambiant : possible avec la caméra ? - voir avec l’équipe Valais
  • Possibilité d’enregistrer la luminosité : compliquée ? - voir avec l’équipe Valais
  • Validation d’avoir un dispositif physique pour l’eye-tracker
  • Panel de testeur : éviter les gens à risques ? (myopie importante, etc.)
Calibration :
  • Possibilité d’afficher plus longtemps la zone verte entre deux calibrations - devrait pouvoir se faire (à voir avec Claudia)
  • Possibilité d’enregistrer les données de calibration (nombre, qualité, temps) - devrait pouvoir se faire (à voir avec Claudia)
  • Au niveau des visuels : vérifier pourquoi des points rouges s’affichent dans la calibration « perfect ». Possibilité d’ajuster la visualisation de la calibration en fonction de la qualité obtenue - Ok (à voir avec Claudia)
Phase pendant test :
Consignes :
  • Dans les délais et budgets impartis, pour faciliter l’analyse des données, il faut idéalement créer deux tests en Ogama : l’un « Consigne 1 » et l’autre « Consigne 2 » et gérer la randomisation manuellement - à voir en pratique ce que cela implique pour le testeur. Important de faire un seul test avec plusieurs consignes - pas prioritaires pour cette étape (on reste sur une preuve de concept)
  • Les infos recherchées + actions à réaliser peuvent être affichées en permanence/sur demande dans un bandeau en haut de l’écran. Il s’agirait de la meilleure position pour afficher la consigne.
  • Lorsque l’utilisateur regarde la consigne écran – et pour ne pas fausser les données récoltées – on peut envisager d’ajouter une AOI spécifique qui serait ensuite exclue des résultats. Une autre solution est de physiquement pose la consigne a cote de l’écran.
  • Ogama enregistre la perte du regard du testeur
Déroulement du test :
  • Fidélité de l’affichage Ogama : concernant le bandeau noir « tous les évènements » non visible dans l’analyse Ogama, il s’agit d’une erreur due au Javascript qu’Ogama n’arrive pas à analyser.
    Dans tous les cas, il sera important de vérifier que les visualisations d’Ogama sont fidèles aux visualisations du site réel avant de commencer les prochains tests.
    Succès :
  • Il est important de prévoir une action à réaliser en cas d’abandon du testeur
  • Difficile de demander d’entrer une donnée post-test pour vérifier le succès, car le testeur peut ne pas s’en souvenir.
  • Pour fiabiliser l’accès au succès, il est important de bien définir l’information synonyme de succès. Plusieurs informations peuvent définir un même succès.
  • Données exportées sur Ogama :

Temps de navigation global sur le site/ consigne/ utilisateur : donné directement par Ogama ?! (à voir avec Claudia)
Possibilité d’avoir des AOI multipages -> devrait être possible.
L’expert doit être capable d’identifier une même AOI dans des contextes (pages) différents - cette fonctionnalité serait implémentée directement sur le dashboard

Questionnaire :
  • Il est essentiel que les données objectives soient interprétées grâce au support des données objectives/ loud-thinking.
    Pour des raisons de délais/budget, on pourrait prévoir un « dashboard 1 » qui intègre les données objectives seulement, puis un « dashboard 2 » qui intègre en plus les données subjectives (avec possibilité d’analyse sémantique)
  • Concernant l’évaluation de la perception du site, en complément de l’analyse sémantique par le logiciel Tropes, il existe d’autres outils d’analyse:

Product reaction cards (microsoft) : choix de 10 adjectifs pré-définis (important de mettre 40% d’adjectifs « négatifs » et 60% de « positifs » car on a tendance à davantage mettre en avant les aspects négatifs)
X-core
Attract-dif (?)

Il serait donc envisageable de coupler l’analyse sémantique Tropes avec la méthode des 10 adjectifs prédéfinis, pour que les données soient plus robustes et traitées plus facilement.

Proposition de partage des tâches :
He-Arc TIC
  • Crée un squelette du dashboard (php + laravel, sqlite)
  • Structure de base de données du Dashboard en intégrant toutes les métriques valides et définir les visualisations de chaque une.
  • Améliorer Ogama avec les propositions de l’équipe CPCU
    He-Valais
  • Visualisation de carte de chaleurs et scanpath sur le Dashboard
    He-Arc Conception de produits
  • Continuer l’analyse des données
  • Définir des visualisations pour chaque métrique
  • Refaire des tests une fois qu’on implémenté les fonctionnalités qui manque en Ogama
Prochaine séance
  • Séance de travail avec l’équipe de Valais dans la semaine 7-11 mars