M2 RVA

NIHM: Nouvelles Interactions Humain-Machine

TP User Performance Modelling

Informations:

Important:

Les fichiers nécéssaires à ce TP sont trouvables ici. TP à faire individuellement (pas de binomes). Lire en intégralité le sujet du TP avant de le commencer et/ou poser des questions.

Format du rendu

Le TP doit être rendu sous la forme d'une archive Zip contenant: le code source du TP (directement executable sur n'importe quel ordinateur), les données collectées lors de l'experimentation, et un document compte rendu au format PDF répondant aux questions posées ci-dessous et discutant les resultats obtenus. En théorie, le code source pourra être dans le language que vous souhaitez, mais Javascript est fortement recommandé. Gardez surtout à l'esprit que le code doit pouvoir s'executer tel quel sur n'importe quel ordinateur, sans avoir à installer de dépendance explicitement (auquel cas une pénalité lourde sera appliquée à la note).

Articles à consulter

Vous êtes fortement encouragés à regarder l'article original présentant le modèle SDP et l'article Why it's quick to be square qui l'applique à des menus matriciels pour vous inspirer de comment modeliser la performance utilisateur.

Process de rendu

Envoyer l'archive .Zip par mail à sylvain point malacria @ inria point fr au plus tard le 31 Décembre 2023 à 23h59. Le sujet du mail doit-être [M2RVA-IHMA] Votrenom_Votreprenom (remplacer bien entendu avec vos noms et prenoms). Ne pas vous y prendre à la dernière minute.

Penalités

Un point de pénalité sera appliqué à la note par tranche de 2h de retard. Un point de pénalité sera appliqué à la note si le sujet du mail n'est pas correct. Deux points de pénalité seront appliqués à la note si je dois installer une dépendance pour executer le code. Deux points de pénalité seront appliqués si le code ne s'execute pas tel quel (e.g. les chemins de fichiers ne sont pas en relatif et je dois les corriger).

L'objectif de cet exercice est de modéliser la performance utilisateurs pour selectionner des commandes daans différentes interfaces graphiques. Pour cela, il faudra décomposer la tâche de selection de commande dans ces interfaces en sous-taches, modéliser la performance de chacune de ces sous-taches dans différents contextes, implémenter une interface graphique permettant de mettre en situation l'utilisateur, collecter des données avec des utilisateurs, et confronter les resultats obtenus avec les resultats du modèle.

Différentes interfaces de sélection de commande

La sélection de commande en pointant à la souris consiste à déplacer le pointeur souris au dessus d'un composant graphique et cliquer dessus pour activer la commande correspondante. Une interface courante de selecton de commande est la barre à outil à onglet (tab-based) comme le Ribbon (illustré ci-dessous) des applications de la suite Microsoft Office (MS Ribbon). Les commandes d'une même catégorie sont contenues par un onglet, et l'utilisateur peut cliquer sur un autre onglet pour afficher les catégories d'une autre commande. En pratique, selectionner une commande dans le MS Ribbon est relativement facile, mais peut demander d'avoir à changer d'onglet pour pouvoir le faire lorsque la commande désirée est d'une autre catégorie.

Une autre interface de selection de commande consiste à afficher toutes les catégories en même temps, "à plat" (Flat interface). Cette interface a donc pour avantage de ne pas nécessiter de changer d'onglet, mais occupe trop d'espace à l'écran pour être affiché en permanence. Par conséquent, l'interface est cachée par défaut et l'utilisateur doit l'afficher en appuyant sur une touche spécifique (maintenir la touche Ctrl)

Comparer la performance utilisateur avec chacune de ces interfaces

L'exercice consiste à

  • Modéliser la tache de selection de commande avec chacune de ces interfaces
  • Utiliser ce modèle pour modéliser la performance estimée de selection de commande (le temps moyen de selection de commande) avec chacune de ces interface
  • Implementer une interface pour simuler la tache et collecter des données
  • Analyser les données et les comparer à la performance estimée
  • Modéliser la tâche de selection de commande avec les interfaces

    Comme expliqué ci-dessus, il y a deux interfaces différentes: MS Ribbon et Flat.


    Q1: Modéliser la tache de selection de commande avec chacune de ces interfaces, que la commande soit contenue dans une autre catégorie que la précédente ou non.

    Modéliser la performance estimée

    Avec le modèle de tâche élaboré ci-dessus, modéliser la performance estimée utilisateur. Dans ce but, il faudra utiliser les modèles prédictifs présentés pendant le cours. Pour rappel, nous partirons des postulats suivants:

  • Les commandes sont situées dans N groupes differents
  • La selection de commande démarre avec le curseur souris situé au centre de l'espace de travail
  • Les onglets font XXXX pixels de large
  • La selection de commande se fait sans erreur
  • Q2:Il faudra modéliser la performance pour un utilisateur peu entraine (ne connaissant pas vraiment l'interface), experimenté (connaissant bien l'interface), et en fonction du pourcentage de commandes sélectionnées qui sont d'une catégories différentes de la précédente. Produire des graphiques illustrant ces modèles.

    Implementer les interfaces de selection de commande

    Dans le but de collecter des données pour vérifier la performance estimée, implementez une interface de test. Cette interface pourra être implémentée avec le language que vous souhaitez mais gardez bien à l'esprit les risques encourus (voir ci-dessus).

    Q3:Implementer une interface de type MS Ribbon.

    Pour cela, télécharger cette archive zip qui contient divers fichier *.png nommés ribbon0*.png qui seront affichés pour simuler l'interface. Un fichier csv widgetsCoordinates.csv contient les coordonnées de chaque commande dans ces fichiers png. Developper une interface (par exemple dans un canvas html) qui dessine l'interface, permet de passer d'un onglet à l'autre en cliquant sur le nom des onglets (modifiant donc le png affiché) et permet de selectionner une commande en cliquant dessus.

    Q4:Implementer une interface de type Flat.

    Faites de même pour une interface Flat. La difference majeure provient du fait que toute les commande sont affichées au même moment, quand la touches Ctrl du clavier est enfoncée. Les images pour l'interface sont nommées flat*.png

    Implementer un moteur d'experimentation

    Q5:Implementez un moteur d'experimentation qui va afficher une des deux interfaces, demander à l'utilisateur de selectionner la commande affichée en bas de l'écran (cible).

    Pour cela l'utilisateur devra cliquer dans un rectangle affiché au centre de l'interface puis selectionner la commande. Une fois la commande selectionnée, la cible disparait et l'utilisateur doit à nouveau cliquer dans le rectangle situé au centre pour afficher la commande suivante.

    Pour cela, vous avez dans l'archive file.zip des fichiers targetlist1.csv et targetlist2.csv que vous pouvez utiliser comme listes de cibles à selectionner par l'utilisateur.

    Q6:Votre moteur d'experimentation doit permettre de telecharger à la fin de l'experimentation un fichier de log avec pour chaque commande, l'identifiant de la commande, si elle était d'une catégorie différente de la précédente, le temps nécessaire à la selection, et si il y a eu des erreurs.

    Collecter et analyser des resultats

    Faire passer au minimum 6 utilisateurs pour collecter des données. La moitié d'entre eux devra commencer par l'interface MS Ribbon, l'autre moitié par l'interface Flat. Contre-balancez également les fichiers targetlist1.csv et targetlist2.csv.

    Q7: Analysez les resultats et confrontez les à vos predictions.