3d-interface-rapport/rapport/userstudy.tex

\part{É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.