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

\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.