\mypart{Évaluation des interfaces\label{userstudy}} \paragraph{} Pour tester le comportement des utilisateurs face aux recommandations, nous ne pouvons pas nous contenter d'observer le comportement des utilisateurs puisqu'ils ne sont pas nécessairement intéressé par nos scènes. Ils se contenteraient probablement de se promener un peu dans la scène puis partiraient. \paragraph{} Pour palier à ce problème, nous avons ajouté des \emph{pièces} à chercher dans la scène. L'objectif est basé sur l'hypothèse que si un utilisateur a ramassé toutes les pièces rouges, il aura parcouru l'intégralité de la scène. \begin{figure}[H] \centering \includegraphics[scale=0.275]{new/04.png} \caption{Une pièce rouge} \end{figure} \paragraph{} Pour éviter de biaiser les utilisateurs, il est nécessaire d'éviter la dépendance entre les recommandations et les pièces. En effet, si les recommandations mènent toujours aux pièces, l'utilisateur va croire que les recommandations sont là pour trouver les pièces, alors qu'elles ne doivent être là que pour aider la navigation. Pour cela, nous avons mis en place un système de tirage aléatoire des pièces parmi plusieurs positions possibles (ceci sera détaillé dans la section \ref{coins}). \section{Déroulement de l'expérience} \subsection{Première page} La première page présente rapidement l'expérience. Elle vérifie aussi le navigateur : si le client est sur Google Chrome ou Firefox, un lien apparaîtra pour passer à la suite, sinon, un message d'erreur s'affichera. \subsection{Identification} Cette page nous permet d'en savoir un peu plus sur l'utilisateur : nous allons demander l'age, le sexe et les habitudes en terme de jeux vidéo de l'utilisateur (nous avons fait l'hypothèse que la capacité des utilisateurs à manier notre interface allait dépendre fortement de leur habitude aux jeux vidéo). Nous leur demandons notamment de noter leurs capacités en terme de jeux vidéo (entre 1 et 5 étoiles). \subsection{Didacticiel} Ensuite, nous demandons à l'utilisateur de suivre un didacticiel : c'est une expérience normale mais guidée. Des messages indiquant les interactions à faire aideront l'utilisateur à s'habituer à cette interface. On y présente les moyens de déplacer la caméra, puis les recommandations et les différents boutons de l'interface. \subsection{Les trois vraies expériences} C'est ensuite que la \emph{vraie} partie de l'étude utilisateur commence : à 3 reprises, l'utilisateur doit remplir dans une scène avec certaines pièces rouges à trouver, et un certain style de recommandations\footnote{aucune recommandation sera considéré comme un style de recommandation, de sorte à comparer la présence à l'absence de recommandation pour la navigation} pour l'aider. Nous expliquerons dans la sous-section \ref{selection} comment le choix de la scène et du style de recommandation sera fait. \paragraph{} Dans chacune des expériences, l'utilisateur devra chercher des pièces rouges, en s'aidant (ou pas) des recommandations. L'expérience se terminera soit quand l'utilisateur aura trouvé les huit pièces rouges, soit une minute après avoir trouvé la 6\up{ème} pièce rouge. Pour éviter que l'utilisateur soit \emph{frustré} de ne pas avoir trouvé toutes les pièces, nous n'indiquons pas clairement le nombre de pièces qu'il a, ou qu'il lui reste à trouver. Simplement, une \emph{vague} idée de sa progression (voir figure \ref{interface-schema} - élément 6). \subsection{Le \emph{feedback}} Après avoir fini ces expériences, l'utilisateur se retrouvera sur un formulaire lui demandant son avis quand à la difficulté de l'interface, et l'utilité des recommandations pour se déplacer dans la scène. \section{Génération des expériences} \subsection{Choix de la scène et du style de recommandations\label{selection}} \paragraph{} Il y a trois scènes disponibles, et sur chaque scène, nous avons placé des pièces dans de nombreuses positions. Lorsqu'un utilisateur commence une expérience, l'algorithme de selection fonctionne de façon à faire des expériences sur les mêmes scènes avec les mêmes dispositions de pièces mais des styles de recommandations différents pour des utilisateurs de même niveau, de sorte à pouvoir comparer l'efficacité des recommandations. \paragraph{} Parmi les paramètres qui varient, nous avons : \begin{itemize} \item le niveau du joueur \item la scène \item la disposition des pièces rouges \item le type de recommandations \end{itemize} \paragraph{} Le système que nous avons fait cherche les joueurs qui ont le même niveau pour leur donner les mêmes scènes avec la même disposition de pièces mais avec des styles de recommandations différents, de sorte à pouvoir les comparer. \subsection{Positions possibles des pièces\label{coins}} Pour choisir les positions possibles des pièces dans chaque scène, trois outils ont été développés. \subsubsection{Coin-creator} Cette interface permet de naviguer dans une des scènes possibles, et de cliquer sur une paroi pour créer une pièce. Cliquer sur un pièce la détruit, et un bouton permet d'envoyer les pièces par mail à mon adresse. \paragraph{} J'ai ainsi envoyé ce mail aux encadrants qui ont eux même pu créer les pièces, et j'ai ensuite fait un programme qui rassemble les pièces et élimine les pièces trop proches les unes des autres. \subsubsection{Coin-editor} Cette interface a été conçue pour corriger les imprécisions provenant de l'interface décrite précédemment. En effet, parfois, une pièce peut intersecter un mur. Coin-editor permet de cliquer sur une pièce pour pouvoir accéder à ses propriétés depuis la console JavaScript, et modifier sa position, puis renvoyer un mail avec les positions corrigées. \subsubsection{Coin-checker} Cette interface a été conçue lorsque nous nous sommes aperçus que certaines pièces étaient passées de l'autre côté du modèle. Il était ainsi difficile de les trouver et cette interface permet de chercher les pièces parmi toutes celles qui existent. On peut cliquer sur les pièces pour les récupérer et un compteur indique le nombre de pièces restantes. \section{Collecte des informations} Ces expériences n'auront d'interêt que si nous sommes capables de les analyser par la suite et de comprendre comment les utilisateurs interagissent avec les recommandations. Nous avons donc mis en place un système de collecte des actions de l'utilisateur basé sur les XmlHttpRequests de JavaScript. Côté serveur, il y a quelques urls qui permettent d'enregistrer des informations dans des tables prévues à cet effet. Chaque évènement contient la date à laquelle il a été envoyé par le client ainsi que l'id du client et de l'expérience qu'il est en train de faire (ces deux derniers sont stockés dans la session sur le serveur). Les évènements enregistrés sont les suivants : \paragraph{ArrowClicked} : créé quand l'utilisateur clique une recommandation, accompagné de l'id de la recommandation cliquée. \paragraph{CoinClicked} : créé quand l'utilisateur récupère une pièce rouge. \paragraph{KeyboardEvent} : créé quand l'utilisateur appuie ou relâche une touche du clavier, accompagné de la position courante de la caméra et d'un booléen indiquant si elle a été appuyée ou relâchée. Dans le cas du \emph{drag-n-drop} ou du \emph{pointer lock}, aucun évènement (autre que les \emph{mouse-move} qui ne sont pas stockés en base de données parce qu'ils sont trop nombreux) n'est envoyé. Ainsi, pendant toute la durée du mouvement de l'orientation de la caméra, on n'aura aucune information. Pour palier à ce problème, nous enverrons régulièrement des \emph{KeyboardEvent} factices pour sauvegarder l'état de la caméra. \paragraph{ResetClicked} : créé quand l'utilisateur réinitialise la position de la caméra. \paragraph{PreviousNextClicked} : créé quand l'utilisateur clique sur les boutons précédente ou suivante, on stockera la position finale en base de données. \paragraph{Hovered} : créé quand l'utilisateur survole ou sort d'une recommandation avec le curseur. \paragraph{PointerLocked} : dans le cas où l'utilisateur utilise l'option \emph{pointer lock}, il sera créé au moment où le pointeur sera capturé et où il sera libéré. \paragraph{SwitchedLockOption} : créé quand l'utilisateur change d'option entre \emph{pointer locked} et \emph{drag-n-drop}. \paragraph{FpsCounter} : chaque seconde, cet évènement est créé pour connaître le \emph{framerate} du client, de sorte à savoir si les performances de sa machine ont pu lui poser problème dans ces expériences. \section{Replay} Afin de nous assurer que toutes les informations nécessaires étaient bel et bien récupérées en base de données, nous avons mis en place un programme permettant de rejouer les expériences stockées. \paragraph{} Pour le replay, nous avons simplement considéré les évènements \texttt{ArrowClicked}, \texttt{CoinClicked}, \texttt{KeyboardEvent}, \texttt{ResetClicked} et \texttt{PreviousNextClicked}, les autres évènements n'ayant pas d'influence sur la position de la caméra. \paragraph{} La génération du chemin de la caméra est faite de manière assez simpliste. En fait, nous accordons peu d'importance aux touches appuyées, mais plutôt aux positions de la caméra au moment de ces évènements. Nous interpolons entre les \texttt{KeyboardEvent}, le \texttt{ResetClicked} réinitialise la position de la caméra brutalement et les autres évènements utilisent les polynômes de Hermite comme pour le suivi des recommandations lors d'une expérience. \section{Déploiement} Pour l'instant, cette étude a été faite par des collègues (étudiants, chercheurs...), mais nous pensons ensuite le déployer vers une plateforme de crowd-sourcing (MicroWokers) où nous paierons les utilisateurs afin d'avoir plus de résultats à analyser.