198 lines
9.8 KiB
TeX
198 lines
9.8 KiB
TeX
\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.
|