\part{L'étude utilisateur} \paragraph{} Pour tester le comportement des utilisateurs face aux recommandations, nous avons dissimulé des pièces rouges à travers ces modèles, et nous avons demandé à des utilisateurs de les trouver. \begin{figure}[H] \centering \includegraphics[scale=0.275]{img/new/04.png} \caption{Une pièce rouge} \end{figure} \paragraph{} Pour éviter la dépendance entre les recomendations et les pièces rouges (si les recommandations visent les pièces rouges, il est évident qu'il sera très facile de les trouver avec les recommandations), un système de tirage aléatoire de pièces rouges a été fait. \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 video de l'utilisateur (nous avons considéré que la capacité des utilisateurs à manier notre interface allait dépendre fortement de leur habitude aux jeux video). Nous leur demandons notamment de noter leurs capacités en terme de jeux videos (entre 1 et 5 étoiles). \subsection{Tutoriel} Ensuite, nous demandons à l'utilisateur de suivre un tutoriel : c'est une sorte de réelle expérience 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 va se retrouver 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. \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{} Nous cherchons en fait des expériences qui permettraient de compléter les trio d'expériences avec des pièces identiques sur des scènes identiques mais avec des styles de recomendations différents. Si une telle expérience n'existe pas (les trios sont déjà complets, ou bien il n'existe pas d'expérience pour un niveau d'utilisateur donné), la scène, ainsi que les pièces à trouver et le style de recommandations seront choisi aléatoirement : on choisira une scène et un style de recommandations que l'utilisateur n'a pas encore effectué, et on choisira 8 pièces aléatoirement parmi les positions possibles que nous avons fixées au préalable. \subsection{Positions possibles des pièces} Pour choisir les positions possibles des pièces dans chaque scène, un petit outil à été développé permettant de se déplacer dans une scène et des créer des pièces en cliquant. Cliquer sur une paroie de la scène crée une pièce devant cette paroie, et cliquer sur une pièce la supprime. Un bouton permet d'envoyer la liste des pièces par mail, lorsque l'on a fini de créer des pièces. \section{Collecte des informations} Ces expérienes 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 cerniers sont stockés dans la session sur le serveur). Les évènements enregistrés sont les suivants : \paragraph{ArrowClicked} : crée quand l'utilisateur clique une recommandation, accompagné de l'id de la recommandation cliquée. \paragraph{CoinClicked} : crée quand l'utilisateur récupère une pièce rouge. \paragraph{KeyboardEvent} : crée 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}, on créera de temps en temps quelques évènements de type \texttt{KeyboardEvent} non associée à une touche de sorte à connaître l'angle de la caméra. \paragraph{ResetClicked} : crée quand l'utilisateur réinitialise la position de la caméra. \paragraph{PreviousNextClicked} : crée 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ée 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ée au moment où le pointeur sera capturé et où il sera libéré. \paragraph{SwitchedLockOption} : crée quand l'utilisateur change d'option entre \emph{pointer locked} et \emph{drag-n-drop}. \paragraph{FpsCounter} : chaque seconde, cet évènement est crée 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 fait 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.