Projet C IG (1A)

IHM (2A)


VR/AR/Post-WIMP (3A)


Projet image (2A)


HCI (MoSIG 2)


Test Logiciel


Projects Docs

Questions fréquentes

Sur cette page, nous recensons les questions-réponses sur les cours et/ou projets. N'hésitez surtout pas à nous solliciter. Nous devons tous ensemble surmonter cette période compliquée tout en assurant votre montée en compétences en IHM.

Nous ne voyons pas très bien comment écrire le doc des spécifications externes ?

Le principe du doc des spécifications externe est de décrire précisément le layout (avec des maquettes dessinés à la main, ou faites sous paint ou autre), et le comportement de votre application (en expliquant ce que fait chaque bouton, a quoi sert chaque entrée, etc (ça peut être malin de légender la maquette pour aider la compréhension). Imaginez que votre travail est de concevoir une appli, mais ni de l’implémenter (travail du dev), ni de la texturer (travail du designer). Ce doc est la seule chose que vous leur transmettez et il doit donc contenir toutes les infos qui leur permettent d'instancier votre conception : si vous dessinez un bouton dans la maquette et que vous ne décrivez pas sa fonctionnalité, le dev sera bien embêté!

En terme de plan, vous pouvez commencer par une brève intro qui peut par exemple remettre très rapidement en contexte, présenter la structure générale de votre appli, comment vous organisez la suite du document.

Pour la suite vous devez donc présenter votre appli : chaque vue doit être représenté (idéalement avec une maquette), le comportement de chaque widget doit être expliqué ET les choix marquant de conceptions doivent être expliqués ("ce bouton est très important : on lui met une grande taille et dans un endroit accessible", ...). Pour représenter des comportements, un / des diagrammes de tâches sont bienvenus.

Pour l'organisation du document faites comme il vous semble le plus pertinent. Ça peut être un diagramme de tache puis les maquettes puis comportement puis justifications. Ou alors chaque vue l'une après l'autre avec maquette+comportement+ petit diagramme de tâche en rapport si c'est pertinent, ou un mix des deux.

Existe-t-il des outils pour modéliser simplement nos différents écrans avec des liens entre eux ?

Je ne connais pas personnellement d'outils spécifique pour modéliser des vues et leur relations. A mon avis, vous pouvez faire beaucoup de choses jolies rapidement en dessin vectoriel (inkscape, gimp, paint.NET, photoshop) ou même avec les outils de présentation (powerpoint, libreoffice, keynote). Ces outils permettent de faire facilement des rectangles, des ronds, mettre des textes et des flèches, ...

Faut-il faire un diagramme de classe / un modèle de domaine dans le doc de spécification externes ?

Non. Dans le cadre du projet, on ne vous demande pas de faire de modèle de domaine pour le DSE. Pour moi, le modèle de domaine représente plus les spécifications internes de votre application et non externes. Ça pourra vous être utile lors du prototypage mais pas pour ce document.

Que faut il faire pour attaquer la phase de prototypage et d'évaluation du projet ?

Dans un premier temps, il va falloir que vous vous mettiez d’accord entre vous sur comment vous allez vous organiser, quelle techno vous allez utiliser, et surtout comment avancer tous ensemble malgré la distance.

Pour la techno, choisissez ce que vous voulez. Pour ceux qui font un projet mobile ou sur interface tactile, je vous conseille vivement d’utiliser android studio, qui permet de mettre en place facilement un projet android, de le tester sur votre smartphone ou sur émulateur directement sur votre PC. Ne sous estimez pas le temps nécessaire pour mettre en place votre projet, ne serait ce que pour avoir un hello world qui fonctionne avec la techno que vous souhaitez utiliser.

Pour le protocole d’évaluation, il s’agira d’identifier comment vous pourriez tester la pertinence de vos choix de conception vis à vis des utilisateurs finaux. C’est à dire : quels aspect de l’interface est le plus important à tester (l’efficacité pour réaliser telle ou telle tâche, l’intuitivité de l’interface, …), comment le tester (expliquer l’interface aux utilisateurs au préalable ou non, leur demander de réaliser une tâche précise ou au contraire les laisser explorer, …), et comment mesurer les retours utilisateurs (avec un questionnaire, en mesurant des performances, ...)

Pour l’organisation, il est nécessaire de 1) prioriser les différentes étapes du développement (qu’est ce qui doit être développé en premier, qu’est ce qu’on fera après) et 2) identifier qui fait quoi. Il y a encore beaucoup de chose à faire dans ce projet en plus du développement brut : faire des test au fur à mesure et proposer des modifications si nécessaire, réfléchir et préparer le protocole expérimental (même si vous ne pouvez pas faire tester votre appli par des participants neutre, on va quand même réfléchir au protocole expérimental que vous auriez du mettre en place), communiquer entre vous, communiquer avec moi, répartir le travail, travailler sur le design, … Ce n’est pas indispensable donc que tout le monde mette les mains dans le code. Vous pouvez aussi vous répartir les différentes vues entre vous, ou vous mettre à 2 par partie de développement. Organisez vous au mieux en fonction de vos contraintes.

Dans un premier temps, il faut identifier :

  • quelle techno vous choisissez pour le développement
  • la liste des tâches à faire par ordre de priorité
  • qui est assigné à quelle tâche précisément. Il est important que vous vous répartissiez le travail le plus équitablement possible entre vous.

Quel est le travail attendu pour les soutenances finales du projet ?

  1. Vous rappelez (rapidement) le contexte : le problème abordé, son importance, votre approche.
  2. Vous présentez votre prototype, et pointez en particulier ses forces (conformité à votre conception) et faiblesses (non conformité).
  3. Vous présentez votre évaluation :
    • Les questions auxquelles l’évaluation devait répondre.
    • Votre protocol expérimental.
  4. Vous concluez sur :
    • Votre appli : pensez vous que les besoins identifiés en début de projet ont été traités, votre proto est il conforme à votre dse, quels sont les défauts de votre solution actuelle, quelle serait la prochaine itération pour améliorer votre projet ?
    • ce que vous avez appris en ingénierie de l’interaction humain-machine : processus, produit et organisation du travail : la démarche vous a-t-elle semblée pertinente ? Pourquoi ? Quelle leçon en retirez vous ?

Comment se dérouleront les soutenances finales du projet ?

Compte tenu de la situation, il n’y aura pas de soutenance physique, mais une soutenance à distance. Etant donné les difficultés que chacun peut rencontrer, nous vous laissons le choix dans le format que vous préférez parmi les 3 formats suivants :

A – soutenance en direct avec tous les membres du groupe par skype
B – soutenance vidéo que vous enregistrez et que vous m’envoyez
C – soutenance par documents (proche des soutenances précédentes).

Dans tous les cas, il faudra que vous filmiez, à minima, une courte vidéo de démo pour présenter votre prototype. Dans tous les cas, votre document complet ou vos slides (que vous utiliserez dans votre soutenance) devront m’être envoyées également.

Voici le détail des soutenances en fonction de chaque option : Les rendu sur teide seront à rendre pour le 30 avril. Il n’y aura pas de format favorisé ni pénalisé : choisissez au mieux en fonction de vos contraintes.

A – Il faudra rendre sur teide :

  • la vidéo de démo de votre proto
  • les slides que vous utiliserez pendant votre soutenance.

Il faudra également prendre un rendez vous avec moi pour une date de soutenance début mai. Vous devrez absolument être capable d’assurer une qualité de communication suffisante : testez en avance que vous avez tous un micro et une webcam qui marche bien, et que votre connection est capable de maintenir une visio à 5 personnes pendant une demi heure.

B – Il faudra rendre sur teide :

  • la vidéo de démo de votre proto (peut être incluse dans le montage final de la vidéo de soutenance)
  • les slides que vous utiliserez pendant votre soutenance.
  • La vidéo de votre soutenance (entre 20 et 30 min).

Il faut voir la vidéo de soutenance comme une vrai soutenance mais en retransmission. Il faut vous filmez pendant que vous présentez votre travail. L’intêret ici est que vous pouvez chacun filmer votre partie de votre côté puis monter la vidéo regroupée. Si vous choisissez cette solution, il faudra absolument que vous vérifiez que l’on comprend bien ce que vous dites dans la vidéo. Il faudra aussi que vous explicitiez où vous en êtes dans vos slides, soit en disant a voix haute quand vous changez de slide, soit en vous filmant avec les slides à côté de vous, soit en faisant une incrustation dans le montage final. Il faudra absolument que tous les membres du groupe présentent une partie.

C - Il faudra rendre sur teide :

  • la vidéo de démo de votre proto
  • le document final

Le document final ressemble aux documents que vous avez rendu jusque la, il est donc largement plus complet et plus détaillé que des slides de soutenance, car vous n’avez pas recours à l’oral. Cette solution est peutetre la plus simple à mettre en place à distance mais elle demande un gros travail écrit par rapport aux autres solutions.

A cause du confinement, nous ne voyons pas vraiment comment nous pourrons faire tester notre prototype ?

Effectivement, vous ne pourrez pas faire d'évaluation à cause du confinement. Ce que nous vous demandons c'est de néanmoins réfléchir à ce que vous auriez pu tester, et comment (incluant le protocole expérimental). Il y a donc une partie de la soutenance qui consiste à dire "voila ce qu'on avait prévu d'évaluer, comme ci comme ça et pour telles raisons". Mais il n'y aura pas de présentation de résultats ou d'analyse d'évaluation puisque les évaluations n'auront pas pu avoir lieu.

Edit - History - Upload - Print - Recent Changes - Search
Page last modified on March 24, 2021, at 07:14 AM