Table des matières
- 1 Project Proposal
- 1.1 Project Proposal
- 1.1.1 Enoncé du problème
- 1.1.2 Caractéristiques de l’utilisateur
- 1.1.3 Participants au projet (évaluation du design)
- 1.1.4 Description initiale du design
- 1.1.5 Intégration avec le Nabaztag
- 1.1.6 Limitations
- 1.2 Team Members
- 1.2.1 Boris Fritscher
- 1.2.2 Ulysse Rosselet
- 1.2.3 Tomas Stastny
- 1.1 Project Proposal
- 2 Requirements and Scenarios
- 2.1 Root Concept
- 2.1.1 Teaching Evaluation Concept
- 2.2 Interview
- 2.3 Information Gathering
- 2.3.1 Information Administrative
- 2.3.2 Cours
- 2.3.3 Conclusion
- 2.4 Personas
- 2.5 Task List
- 2.6 Problem Description and Claims
- 2.6.1 Problem description
- 2.6.2 Problem claims
- 2.7 Scenarios
- 2.8 Requirements Synthesis
- 2.1 Root Concept
- 3 Task Analysis
- 3.1 Project Scope
- 3.2 Task Decomposition
- 3.2.1 Evaluation cours
- 3.2.2 Interrogation des étudiants
- 3.2.3 Signalisation étudiomètre
- 3.3 Input Output
- 3.3.1 Evaluation cours & Signalisation étudiomètre
- 3.3.2 Interrogation des étudiants
- 3.1 Project Scope
- 4 Activity Design
- 4.1 Activity Scenario
- 4.2 Conceptual Metaphors
- 4.3 System Technology Options
- 4.4 Use Cases
- 4.4.1 Evaluation cours
- 4.4.2 Interrogation des étudiants
- 4.4.3 Signalisation étudiomètre
- 4.5 Activity Claims
- 4.6 Activity Synthesis
- 4.1 Activity Scenario
- 5 Information Design
- 5.1 Information Metaphors
- 5.2 Information Technology Options
- 5.3 Information Scenarios
- 5.4 Information Claims
- 5.5 Sketches and Screens
- 5.5.1 Interrogation
- 5.5.2 Autres
- 5.6 Services and Functions
- 5.6.1 Application ONE
- 5.6.2 3rd Party
- 5.6.3 iLearn
- 5.7 Information Synthesis
- 5.1 Information Metaphors
- 6 Interaction Design
- 6.1 Apple iPhone Resources
- 6.2 Interaction Resources
- 6.3 Interaction Metaphor
- 6.4 Interaction Technology Options
- 6.5 Adopted Patterns
- 6.5.1 Usability Engineering
- 6.5.2 iPhone Human Interface Guidelines for Web Applications (src)
- 6.5.3 Interaction Patterns in User Interfaces
- 6.6 Sequences Diagrams
- 6.7 Interaction Claims
- 6.8 Interaction Synthesis
- 6.1 Apple iPhone Resources
- 7 Paper Prototype
- 7.1 Web Paper
- 7.1 Web Paper
- 8 Usability Specifications and Tests
- 8.1 Introduction
- 8.2 Prototype
- 8.2.1 Tâche : répondre à une question
- 8.2.2 Tâche : indiquer la vitesse du cours
- 8.2.3 Tâche : évaluation du cours
- 8.3 Method
- 8.4 Measurements and observations
- 8.5 Results of the tests
- 8.1 Introduction
- 9 Interactive Prototype
- 9.1 Documentation
- 9.1.1 Demo
- 9.1.2 Schema
- 9.1.3 Fonctionnalités
- 9.1.4 Limitations connues
- 9.1.5 Technique
- 9.2 Intégration avec le Nabaztag
- 9.2.1 Description
- 9.2.2 Limitations
- 9.3 iPhone Simulator
- 9.3.1 Prototype
- 9.1 Documentation
- 10 Usability Tests
- 10.1 Introduction*
- 10.2 Prototype*
- 10.2.1 Tâche : Répondre à une question
- 10.2.2 Tâche : Remplir une évaluation
- 10.2.3 Tâche : Indiquer la vitesse du cours
- 10.2.4 Autres fonctions de l'application
- 10.3 Method*
- 10.4 Measurements and observations*
- 10.5 Results of the tests*
- 10.1 Introduction*
- 11 Interactive Prototype 2
- 11.1 Comment
- 11.1 Comment
- 12 Final Comments
- 12.1 Conclusion
- 12.1.1 Pertinence
- 12.1.2 Méthode et matériel
- 12.1.3 Réactions des étudiants
- 12.1 Conclusion
Project Proposal
Enoncé du problème
A l’heure actuelle, une étudiante ou un étudiant qui désire s’informer chaque jour sur ses cours, ses horaires, les avis officiels, les menus des cafétérias, ses e-mails unil, etc. doit visiter manuellement chacun de ces services. Il n’existe actuellement que le portail my.unil.ch qui regroupe certains de ces éléments, mais principalement pour les étudiants qui ne sont pas en HEC.
L’idée est donc de créer un portail pour unifier l’information, et l’étendre avec des aspects collaboratifs.
Caractéristiques de l’utilisateur
Principal: Étudiantes et étudiants de l’université
de Lausanne
Jeunes, mobiles, pressés, parfois organisés à la dernière minute, etc.
Secondaire: Professeurs et service administratif de l’université
(Principalement une mise à jour des services en arrière-plan)
Désire que l’information soit reçue par les étudiantes et les étudiants le plus
rapidement possible et avec une grande couverture.
Participants au projet (évaluation du design)
Etudiants de 1ère, 2ème, 3ème et master de HEC
Description initiale du design
Plateforme principale
L’idée est de créer un portail regroupant et unifiant les services utilisés par l’étudiant, ainsi que de lui en offrir des nouveaux, ou des extensions pour faciliter la collaboration.
S’il le désire, la configuration et la personnalisation de son profil se ferait principalement sur un grand écran (ordinateur normal, par exemple les bornes Situnil). Ensuite, quand l’utilisateur est en mobilité, il peut accéder à une page tableau de bord grâce à son « small device ». Cette page affiche les « widgets » qu’il ou elle a configurés préalablement. Il est ainsi possible d’embrasser en un clin d’œil toute l’information qui l’intéresse : disponibilité de nouveaux documents de cours (qu’il peut aller imprimer), cours déplacé, menu des cafétérias, argent restant sur sa campuscard, savoir si Alice va au Mad ce soir, résumé des notes de Bob dans sa boîte e-mail, devoir à faire pour le lendemain.
Remarquons que l’utilisateur n’est pas limité qu’à de l’information très récapitulative : grâce à des fonctionnalités « drill-down » des widgets, il peut avoir plus d’informations, répondre à des sondages, transmettre l’information /document à ses amis, ou encore cocher l’information pour la consulter plus tard sur un ordinateur personnel ou public.
Nous avons répertorié les services suivants :
| Groupes/Services | Aspect Collaboratif* | Extension avancée** |
|---|---|---|
Information Administrative
|
Envoyer nouvelle à un ami | Inscription aux examens Gestion du budget |
Cours
|
Création de groupe Partage de documents, commentaires, système de flashcards Evaluation des cours en continu |
Vidéo, notes des cours, possibilité de créer ses propres résumés***,etc. |
Autre
|
Evaluation des menus Rsvp |
Intégration avec opensocial Profil personnel de calories |
* nouveaux services
** fonction qui sont largement en dehors du champ de notre prototype
*** www.gotuit.com
Evidemment, dans le cadre de ce projet, il faudra nous limiter fortement, et nous proposons donc de nous concentrer sur l’affichage principal du tableau de bord/portail et d’explorer les interactions détaillées d’un ou deux widgets, principalement l’évaluation du cours.
Intégration avec le Nabaztag
Concernant le Nabaztag, nous le destinons à deux fonctions comme « device » ambiant de classe. D’une part, pour afficher avec un code de couleur le feedback du cours précédent, et d’autre part pour servir comme timer/montre afin d'indiquer le temps qu’il reste avant la fin d’un exercice, d’une séance, ou la pause.
Limitations
N'ayant aucun accès aux données des différents services de l’université, nous devrons nous contenter d’un jeu de données exemples pour le prototype.
Team Members
Boris Fritscher
Ulysse Rosselet
Tomas Stastny
Root Concept
Le concept racine regroupe les aspects principaux de notre application "One Nabaztag experiment".
| Component | Contributions to the Root Concept |
|---|---|
| High-level vision | Students use a touch screen portable device to give quick feedback and access aggregated information regarding the university. |
| Basic rationale | Students have access to the Wi-Fi throughout the whole campus thank to their portable wireless device. So, they do not need to use a fixed computer to interact. Everyone has a different need for information. Therefore personalization must be supported. |
| Stakeholder group
- UNIL Student - Teachers - Administration |
Provide feedback to multiple type of requests and access information without having to use a PC Push information to students (course material, schedule, assignments) Push information to students (exam schedule, classroom changes, conferences) |
| Starting assumptions | Every student has access to such a device, and is familiar with basic browser manipulation. If in production, the final product will have access to all necessary resources (university databases) |
Teaching Evaluation Concept
| Component | Contributions to the Teaching Evaluation Concept |
|---|---|
| High-level vision | Students use their device to provide feedback and answers during and after lessons. |
| Basic rationale | Facilitate communication between teachers and students. |
| Stakeholder group
- UNIL Student - Teachers - Administration |
Signal when teaching speed is not adapted, when they need a break, when something is not understood. Improve interaction with students in large auditoriums, Adapt teaching speed, Continously improve teaching quality Support the teacher's evaluation system |
| Starting assumptions | Students are shy when in class Teacher are not always aware of the students' state during class |
Interview
Les informations nécessaires à la conduite du design ont été obtenues par des interviews conduites grâce au guide d'interview suivant. Les réponses obtenues sont résumées ci-après.
Guide d'interview
Depuis combien de temps étudiez-vous à l'UNIL ?
Avez-vous déjà utilisé des technologies afin d'interagir avec un professeur durant le cours ? Si oui, de quelle manière et à quelle fin ?
Evaluez-vous l'enseignement autrement que par les questionnaires distribués en classe?
Si vous disposiez d’un appareil (type « iPod touch » connecté au réseau de l’université par Wi-Fi), quelles applications trouveriez-vous intéressantes ou utiles d’avoir dessus?
Trouveriez-vous utile de pouvoir interagir avec le professeur pendant le cours avec ce type d’appareil ?
Comment imagineriez-vous une telle interaction ?
L’utiliseriez vous pour poser des questions plutôt que de lever la main ?
L’utiliseriez vous pour répondre à des questions du professeur ?
Grâce à ce type d’appareil, quel genre d'informations trouveriez-vous utiles de pouvoir communiquer au professeur durant le cours ?
Grâce à ce type d’appareil, quel genre d'informations trouveriez-vous utiles de pouvoir communiquer au professeur après le cours ?
S’il y avait la possibilité de donner une évaluation à la fin de chaque cours, voudriez-vous que ce soit anonyme ou est-ce que ça vous serait égal?
Prendriez-vous le temps pour cela ?
Résumé des interviews
Les étudiants interrogés vont des premières années du bachelor aux étudiants de master.
Quelques uns ont déjà pu utiliser des "zapettes" pour répondre à des sondages ou des questionnaires pendant les cours.
Parmi les personnes interrogées, aucunes n'ont donné d'évaluation du cours autrement que par l'intermédiaire des questionnaires distribués en fin de semestre.
Parmi les applications souhaitées par ces étudiants, certains aimeraient avoir accès aux slides des cours, à leur e-mail ou aux horaires.
Un étudiant aimerait pouvoir voir qui sont les autres étudiants présents à l'uni et pouvoir communiquer avec eux.
Certains souhaiteraient pouvoir payer à la cafetéria grâce au device. Un autre voudrait pouvoir utiliser des applications de support pour les cours (calculatrice, traducteur, dictionnaire).
Parmi les répondants, peu verraient de l'intérêt à utiliser le device pour communiquer avec le professeur ou pensent que cela serait très limité.
Par contre plusieurs pensent que plus d'étudiants répondraient aux questions posées par les professeurs s'il leur était possible de répondre par l'intermédiaire de leur device.
Pendant le cours, les étudiants voudraient pouvoir transmettre au professeur les éventuelles erreurs du cours ainsi que certaines questions sans l'interrompre.
Après le cours, les élèves aimeraient pouvoir poser des questions relatives au cours, faire des demandes de rendez-vous ou donner leur avis sur le cours. Paradoxalement, aucun ne voudrait y consacrer du temps ou de façon épisodique.
Concernant l'anonymat, c'est 50/50, mais la majorité pensent qu'en restant anonyme, les avis et commentaires seraient plus sincères. Ce dernier résultat nous laisse supposer que la question n'était pas formulée de manière adéquate : nous cherchions à savoir si le fait d'être identifié lors du questionnaire les dérangerait quand bien même ils seraient anonymes pour le professeur.
Information Gathering
Information Administrative
-
InfoTV: Information concernant HEC affiché sur des téléviseurs dans le bâtiment Internef -
Sytème de paiement et de validation de CampusCard (source -
Possibilité de vérifier les transactions de la carte sur le portail my.unil.ch -
Service de portail de l'UNIL surtout pour les étudiants non HEC (pour HEC seul l'intégration webmail et docunil fonctionnent) -
Menus des restaurants de l'UNIL
Cours
-
Horaire pour les étudiants de HEC (site www.hec.unil.ch) -
Horaire pour les étudiants de l'UNIL (site my.unil.ch) -
Site de documentation pour cours HEC accès avec login HEC ou spécifique aux cours -
Nouvelle version des sites de documentation HEC -
Variante plus interactive et avec plus de fonctionnalités, utilisation du portail Moodle -
Exemple de questionnaire pour l'évaluation des cours -
source: Centre de soutien à l'enseignement -
Bornes d'accès à internet (© Silvano Prada /CAV/UNIL) -
Impression : login intermédiaire depuis les bornes UNIL -
Login final pour débloquer l'impression
Conclusion
Nous constatons que les nombreuses ressources en ligne utilisent des adresses différentes et des informations d'authentification différentes. Pour le moment, il n'y a pas de convergence vers une solution harmonisée.
Les étudiants de HEC et des autres facultés de l'UNIL n'utilisent pas les mêmes services, ces derniers ayant un accès centralisé à une majorité de leurs ressources via le portal my.unil.ch.
Personas
Edouard De La MotteStefania Mazanti
Yann Baumgartner
Hélène Aimée Yaoundé
Edouard De La Motte
Etudiant de première HEC, Edouard a grandi à Coppet, et vient d’obtenir son baccalauréat au lycée français de Genève. Habitué à une dimension plus humaine de l’enseignement, Edouard est intimidé par l’université. Le nombre d’étudiants, les professeurs renommés et l’étendue du campus sont autant de nouveautés face auxquelles il se sent désemparé. Par exemple, il n’est pas encore habitué aux nombreux services d’informations de l’UNIL et ne sais pas quel login utiliser pour quel service. Friand de gadgets, il a reçu un iPhone comme cadeau de sa grand-mère – il n’a pas eu la chance de Pierrick, son meilleur ami, qui a reçu une voiture.
Edouard loue un petit studio près de Malley et utilise les transports publics pour se rendre aux cours. Durant les cours, lorsqu’il n’arrive plus à suivre ou qu’il s’ennuie, il visionne des vidéos et envoie des messages à ses amis grâce à son iPhone.
Objectifs
Etre informé en tout temps des changements de salles, d’horaires, des exercices à faire, des différents délais à respecter.
Disposer d’un point d’accès unique à toutes les informations nécessaires relatives à la vie estudiantine.
Justification
Edouard représente assez bien certaines caractéristiques et certains besoins des étudiants de première année HEC. Il ne sait pas encore dans quelle voie professionnelle il va s’engager mais s’intéresse à la vaste palette de possibilités qui s’offre aux étudiants HEC.
Stefania Mazanti
Stefania est originaire du Tessin où elle a fait un diplôme d’employée de commerce. Après avoir travaillé une année comme secrétaire dans une fiduciaire, Stefania a décidé de passer sa maturité commerciale afin d’obtenir, à terme, un Master en Comptabilité. Elle est actuellement en deuxième année de bachelor et connaît déjà bien l’UNIL. Peu à l’aise avec l’informatique, Stefania imprime ses documents de cours à son domicile pour éviter les mauvaises surprises. D’un naturel studieux et organisé, elle souhaite disposer des documents du professeur afin de suivre le cours dans les meilleures conditions possibles. Elle regrette que certains professeurs postent leurs documents à la dernière minute ou même, après le cours.
Stefania profite de la pause de midi pour faire ses séries d’exercices et mange un repas qu'elle a préparé la veille et réchauffé dans son tupperware.
Après les cours, elle reste à la bibliothèque jusqu’aux alentours de 20h pour réviser ses cours et faire ses résumés. Elle peut ainsi réserver ses soirées à son club de boccia.
Objectifs
Pouvoir imprimer les cours à la maison en avance.
Pouvoir tirer le meilleur parti du cours et du savoir de l’enseignant.
Se rendre à la borne d’impression si un document est posté à la dernière minute.
Justification
Stefania représente bien une catégorie d’étudiants qui ont déjà un but professionnel et qui souhaitent tirer un profit maximum des enseignements de HEC. Elle représente aussi la part des étudiants qui ne sont pas familiers avec certaines technologies interactives.
Yann Baumgartner
Yann est en première année de Master en management et envisage de se spécialiser en ressources humaines. Il a fait tout son cursus à Lausanne et connaît toutes les ficelles de la maison. Yann fait partie d’une association d’étudiants active dans le développement durable. Par principe, il ne souhaite pas imprimer les cours mais consulte les documents à l’écran. Il emporte son ordinateur portable avec lui et prends ses notes directement sur les documents.
Yann a de nombreuses connaissances qu’il retrouve à midi ou après les cours, pour prendre une bière au Zelig. Comme il va bientôt quitter l’université pour la vie professionnelle, Yann aime profiter de ces moments avec ses amis. En tant qu’habitué, Yann connaît les menus à éviter et se renseigne sur l’offre des différentes cafétérias avant d’organiser le dîner avec ses amis.
Yann est à la recherche d’un stage en management et aimerait pouvoir faire son stage au sein d’une ONG partageant ses valeurs afin de réaliser un mémoire en gestion de projet en milieu humanitaire. Il consulte quotidiennement les sites dédiés aux stages et au placement.
Objectifs
Connaître l’offre de restauration du campus afin de s’organiser avec ses amis.
Etant à la fin de son parcours, Yann cherche à recevoir le plus d’informations possibles sur les implications professionnelles des savoirs qu’il acquiert en cours.
Etre au courant des dernières offres de stages afin de pouvoir déposer sa candidature aussi vite que possible, si une opportunité se présente.
Justification
Yann représente l’étudiant « baroudeur » qui a su gérer son parcours académique avec décontraction et maîtrise biens les moyens à sa disposition.
Hélène Aimée Yaoundé
Après un doctorat à l’université Paris Dauphine, Hélène a obtenu un poste de Professeure-assistante en prétitularisation en gestion du risque à l’Institut des Sciences Actuarielles de HEC. Hélène poursuit sa deuxième année d’enseignement à Lausanne. Elle est notamment en charge du cours de gestion du risque de deuxième année bachelor. Bien que l’effectif soit réparti en deux groupes, Hélène n’arrive pas à construire une interaction satisfaisante avec les étudiants. Elle ne sait pas comment changer cela. De plus, les évaluations des étudiants sont importantes car elles font partie des critères déterminant la poursuite de son contrat de professeur-assistante.
Objectifs
Proposer des cours les plus adaptés possibles.
Connaître la perception que les étudiants ont de ses cours afin d’améliorer son enseignement. Pour avoir une bonne évaluation dans son dossier pédagogique.
Anticiper et améliorer son enseignement de manière continue.
Justification
Ne pas uniquement se focaliser sur les étudiants
Présenter l'enseignement du point de vue de l'enseignant.
Task List
| Tâches/Importance pour l’acteur | Edouard | Stefania | Yann | Hélène |
|---|---|---|---|---|
| Consulter menus | M | L | H | |
| Connaître horaire | H | H | L | |
| Disponibilité documents | L | H | ||
| Evaluation cours | L | H | M | H |
| Interrogation des étudiants | L | M | H | |
| Signalisation étudiomètre | H | H | M | M |
L = Low, M = Medium, H= High
Problem Description and Claims
Problem description
Les informations recueillies durant les interviews nous permettent de formuler les problèmes suivants, rencontrés par les utilisateurs potentiels de notre système :
Accès aux services d'information généraux
Actuellement, il n'existe pas de point d'accès unique aux différents services informatisés de l'université (informations administratives, académiques et offres de services). De plus tous ces services (sites de cours, courriel, dossier administratif) utilisent des logins différents. Cette lacune, perçue par les étudiants, confirme la pertinence d'offrir, au sein de notre application ONE, un portail regroupant les services en lien avec les tâches des utilisateurs (courriel, horaires et documents de cours, etc.).
Enseignement
Durant les cours ex cathedra, le nombre d'étudiants répondant aux questions du professeur est extrêmement faible. Ceci rend le cours moins dynamique et constitue un problème connu de l'enseignement magistral avec des effectifs importants. Nous déduisons des interviews que l'utilisation d'un appareil permettant aux étudiants une réponse indirecte stimulerait l'interaction et pourrait aussi conduire à plus d'interaction directe par la discussion des résultats.
Concernant l'évaluation de l'enseignement, la fréquence annuelle des évaluations fait qu'une amélioration continue des cours et adaptée aux apprenants est difficile. Nous imaginons que la possibilité d'obtenir un feedback plus fréquent et en rapport direct avec l'enseignement actuel serait un outil d'amélioration pour les enseignants. Notons qu'il est souvent difficile pour les étudiants de faire des commentaires aux professeurs sur leur enseignement car ce sont ces derniers qui leur feront passer les examens. Notre application entend répondre à ce problème grâce à un système anonyme d'évaluation des cours.
Les étudiants souhaiteraient aussi pouvoir pousser plus d'informations vers le professeur : erreurs dans le cours, questions. Nous pensons qu'il est aussi possible de mettre à disposition du professeur des indicateurs relatifs au rythme du cours et à sa structure. Les étudiants pourraient ainsi signaler lorsqu'ils jugent nécessaire de faire une pause ou lorsqu'ils sont "perdus". Notre application comprendra un service permettant aux étudiants de signaler ces paramètres.
Problem claims
| Situation Feature | Possible Pros (+) or Cons (-) of the Feature |
|---|---|
| Point d'accès unique aux services | (+) Facilité d'accès, pas de logins multiples (+) Visibilité de l'information (-) Risque de surcharge d'informations (-) Single point of failure, problèmes de sécurité potentiels |
| Evaluation fréquente des cours |
(+) Plus de possibilités d'amélioration pour les professeurs (+) Enseignement mieux adapté aux étudiants (-) Surcroît de travail pour les professeurs, ils risquent d'ignorer l'évaluation (-) La capacité de traitement des évaluations est actuellement insuffisante |
| Poser des questions, faire des remarques via le device |
(+) Possibilité d'interactions pour les étudiants "timides" (+) Le professeur peut adapter son enseignement (+) les éventuelles erreurs ou imprécisions sont détectées très tôt (-) Risque de dissiper l'attention du professeur et de ne pas le laisser mener à bien son cours (-) Certains étudiants vont abuser de ce système en demandant tout et n'importe quoi (-) Risque de conduire à une focalisation du cours sur des points de détail |
| Suggérer des pauses |
(+) Meilleure concentration des étudiants, "fraîcheur" intellectuelle (-) Perturbe la structure du cours prévue (-) Certains étudiants pourraient abuser de ce système |
| Indiquer le rythme perçu de la leçon |
(+) Adaptation du rythme à la perception des étudiants (+) Meilleure compréhension du cours, donc peut-être plus de participation (+) Passer plus rapidement sur les notions déjà acquises et se focaliser sur les concepts nouveaux ou difficiles (-) Suivant le plan décidé par le professeur, risque de ne pas couvrir la matière prévue (-) La disparité au sein des étudiants fait qu'il est certainement difficile de trouver le rythme adéquat |
Scenarios
Ecran principal, point d'accès, informations
Edouard a eu une panne d'oreiller -- hier, après le test intermédiaire de statistiques, c'était la soirée du comité HEC -- et arrive à l'université avec 35 minutes de retard. Lorsqu'il sort du métro et entre dans la zone de couverture WiFi, il consulte son application ONE et apprend que son cours de macro-économie n'a pas lieu à Dorigny comme à l'accoutumée mais qu'il a été déplacé au bâtiment Amphimax, à la Sorge, à cause des career days qui mobilisent les grands auditoires de l'Internef.
Comme le métro est déjà parti, il fait un crochet par la cafétéria de l'Anthropole, histoire de manger un morceau, car il n'a pas eu le temps chez lui afin de pouvoir sauter dans le premier TSOL. Tout en mangeant, il vérifie si de nouveaux documents de cours sont disponibles à l'impression -- les imprimantes ne sont qu'à deux pas et doivent être désertes à cette heure-là -- grâce au point d'accès unique vers les différentes plateformes (moodle, etc.) utilisées pour les différents cours. En terminant son café, l'agenda de son iPhone émet une sonnerie de rappel : c'est ce jour-même que s'achève le délai pour l'inscription aux examens. Une fois à la salle des imprimantes, il remplit cette formalité de manière classique, imprime le formulaire en deux exemplaires, et peste de devoir se rendre au bureau 300 et quelques pour remettre la feuille. Il se connecte ensuite sur l'interface web de son compte ONE et télécharge directement les documents sans devoir visiter chaque site séparément. Une fois toutes ses copies imprimées, il se rend à l'Internef pour déposer son inscription.
Interrogation des étudiants, évaluation de l'enseignement
13h10 à l’auditoire 273 de l’Internef, les étudiants s’installent. Le cours de gestion du risque de madame Yaoundé va commencer. Hélène répond aux questions de deux étudiantes tessinoises qui n’ont pas compris le calcul d’une prime de risque dans la série d’exercices. Afin de vérifier la compréhension d’ensemble, Hélène décide de procéder à un sondage auprès des étudiants. Elle écrit sa question au tableau et programme un sondage simple "oui/non/je ne sais pas" dans l'interface ONE. les étudiants qui sont inscrits au cours reçoivent automatiquement une notification de ce sondage via l'application ONE. Nos deux tessinoises, qui viennent de poser la question directement à l'enseignante, ne savent pas quoi répondre. Elles décident de répondre qu'elles ont compris, vu que c'est effectivement le cas. Lorsque Hélène juge le nombre de réponses reçues suffisant elle clôture le sondage -- comme elle peut voir le compte des votes en temps réel. Il s'avère que 38% des 179 étudiants n'ont pas réussi ce calcul. Elle décide donc de prendre 5 minutes pour expliquer le raisonnement correct.
Une fois cette digression terminée, Hélène commence la séance de cours à proprement parler. Elle lance sa présentation et explique la théorie aux étudiants. Arrivée à un point précis de sa présentation, Hélène pose une question qu'elle avait préparée à l'avance et à laquelle les étudiants répondent en utilisant ONE. La professeure avait configuré -- le soir précédent, alors qu'elle terminait la préparation de son cours -- le type de question et les choix de réponses proposés aux étudiants. Les étudiants cochent la réponse qu'ils jugent correcte et soumettent leur vote. Une fois qu'Hélène est satisfaite du taux de réponse, elle clôture le vote (les résultats sont affichés), commente les résultats et explique la solution.
A la fin du cours, les cinq dernières minutes sont consacrées à l'évaluation de la séance du jour. Madame Yaoundé demande aux étudiants de remplir le questionnaire à choix multiples -- une version allégée de celui proposé à la fin du semestre. Les informations sont directement envoyées au service de support à l'enseignement qui gère la consolidation et l'analyse du feedback. Une synthèse des résultats sera envoyée à madame Yaoundé dans les prochains jours.
Signalisation, étudiomètre
Yann est en cours d'"advanced brand management". Le professeur, issu du monde professionnel, a tendance à user les étudiants jusqu'à la corde -- 2h30 de cours ex cathedra sans pause -- et se confond en excuse lorsque les premiers étudiants se lèvent et qu'il réalise alors que l'heure est largement dépassée. Comme son attention se relâche et qu'il a soif, Yann indique grâce à son application ONE qu'il souhaiterait faire une pause le plus tôt possible, il en profite aussi pour signaler que le rythme est un peu lent à son goût.
Le Nabaztag, placé aussi bien à la vue des étudiants qu'à celle du professeur, module l'orientation de ses oreilles et ses signaux lumineux en accord avec les indications de rythme et de découpage temporel proposées par les étudiants. Le professeur a donc un indicateur de l'état de l'audience.
Requirements Synthesis
Après analyse des "requirements", nos hypothèses de bases (exprimées dans la proposition de projet) sont confirmées : du point de vue des activités des étudiants, un point d'accès unique concentrant les services les plus utiles à la vie académique est nécessaire et pertinent. Le nombre important de sites de cours (hec docs, moodle, sites spéciaux) et de logins correspondants est un problème qui rend la consultation du matériel de cours fastidieuse.
Du point de vue de l'enseignement et des "requirements" touchant aux cours en eux-mêmes, nous constatons que la réponse des personnes interrogées à la question concernant la pertinence d'un système supportant les interactions avec l'enseignement illustre le "tradeoff" 1.4 [Rosson, 2002] p. 22 :
Nous en concluons que les étudiants ne réalisent pas le potentiel qu'offre une interaction supportée par un device mobile et une application spécifique car la nouveauté de cette fonctionnalité fait que les gens n'en ont pas une représentation qui leur permette d'appréhender la manière dont cela pourrait transformer leurs activités.
Nous allons donc développer l'interaction avec le professeur au moyen de l'iPhone/iPod touch et du Nabaztag afin de transformer certains aspects de l'apprentissage à l'université.
Project Scope
Comme annoncé dans la proposition de projet, et au vu la complexité et le temps à disposition, nous avons décidé de concentrer notre analyse sur un seul élément.
Pour cela nous avons choisi le module de support à l'enseignement qui -- en plus de son caractère innovant -- nous paraît intéressant du point du vue de ses possibilités d'interactions multiples et selon différents modes : bidirectionnelle, instantanée ou différée, synchrone ou asynchrone.
Nous avons identifié trois activités distinctes à travers les trois scénarios vus précédemment:
- Evaluation cours: unidirectionnelle (pas d'action clairement directe sur le feedback), interaction asynchrone et différée
- Interrogation des étudiants: bidirectionnelle, interaction synchrone et instantanée
- Signalisation étudiomètre: bidirectionnelle, asynchrone et instantanée
Task Decomposition
Evaluation coursInterrogation des étudiants
Signalisation étudiomètre
Evaluation cours
(voir use case)
Interrogation des étudiants
(voir use case)
Signalisation étudiomètre
(voir use case)
Input Output
Evaluation cours & Signalisation étudiomètre
Input (Les entrées nécessaires)
Tâche considérée
Pouvoir donner un feedback:
1) pendant le cours,
2) après le cours.
L'utilisateur
Tous les étudiants qui suivent un cours, ainsi que le professeur qui le donne
Le poste de travail
Gadgets mobiles tels le iPhone ou iPodTouch, ainsi que le Nabaztag
Le domaine d'activité
Education interactive
Output (les résultats attendus)
Contexte de travail
La tâche doit pouvoir être effectuée rapidement sans perdre l'attention dirigé au cours. Les contraintes techniques de l'équipement font que les méthodes d'input doivent être limitées à des options à cocher, étant donné qu'il est fastidieux d'introduire du texte.
Stéréotype de l'utilisateur
L'utilisateur connaît son appareil et sait l'utiliser. Il a également de l'expérience de navigation sur internet et est habitué à remplir des questionnaires online (comme ceux de facebook, par exemple).
La motivation principale est d'améliorer ses conditions d'études, d'optimiser la vitesse du cours ainsi que la compréhension du sujet.
Critères d'utilité & d'utilisabilité
Les critères les plus importants sont la rapidité d'exécution de la tâche qui est secondaire au cours, et la satisfaction qu'il en retire, afin de le motiver à répondre.
Paramètres de la tâche interactive
Pré-requis: modérés (appareil)
Productivité: moyenne
Environnement objectif: non existant
Reproductivité de l'environnement: praticable
Organisation de la tâche: élevée
Importance de la tâche: faible
Complexité de la tâche: faible
Interrogation des étudiants
Input
Tâche considérée
Faire participer les étudiants de façon interactive au cours:
1) de manière spontanée (ou)
2) avec des questions préparées
L'utilisateur
Le professeur qui pose les questions et les élèves qui doivent y répondre.
Le poste de travail
Gadgets mobiles tels le iPhone ou iPodTouch, ainsi que un ordinateur de bureau (pour préparer les questions)
Le domaine d'activité
Education interactive
Output
Contexte de travail
Il doit être facile d'initialiser le vote, ainsi que de voir les résultats sans perdre trop de temps sur la durée du cours.
Stéréotype de l'utilisateur
Le professeur doit avoir les compétences pour préparer les questions ou d'initialiser/configurer un vote.
La motivation principale est d'améliorer l'interactivité et donc l'attention des étudiants suivants le cours.
Critères d'utilité & d'utilisabilité
Les plus importants sont la rapidité d'exécution de la tâche et sa simplicité afin de ne pas dissiper l'attention du professeur ou de l'audience. Ceci afin de motiver le professeur à poser des questions avec le système ONE le plus spontanément possible.
Paramètres de la tâche interactive
Pré-requis: modérés (appareil)
Productivité: moyenne
Environnement objectif: non existant
Reproductivité de l'environnement: praticable
Organisation de la tâche: élevée
Importance de la tâche: faible
Complexité de la tâche: faible
Activity Scenario
Nous considérons que le scénario concernant l'évaluation des cours et l'enseignement, présenté dans l'analyse des "requirements", correspond bien à un scénario d'activité, comme précisé dans l'introduction.Conceptual Metaphors
| Project Activity | Real World Metaphor | Implications for Project Activities |
|---|---|---|
| Evaluation cours | Vote par sms ou à l'urne | Réponse agrégée, anonyme |
| Remplir feuille d'évaluation | Temps disponible pour réfléchir | |
| Interrogation des étudiants | Quiz show | Réponse rapide |
| Vote à main levée | Feedback en temps réel Le groupe voit ce que vote l'individu |
|
| Signalisation étudiomètre | Mesure des précipitations | Indicateur qui montre l'accumulation d'eau (dans notre cas personnes perdues,...) |
| Thermomètre | Montre la température de l'audience, seuil de fièvre |
System Technology Options
| Project Activity | Information Technology | Implications for Project Activities |
|---|---|---|
Evaluation cours Interrogation des étudiants |
Remplir un sondage sur internet | Cocher des options, indication de la progression |
| Remplir et envoyer un formulaire sur internet | Remplissage des champs, valider, indications des champs manquants | |
| Signalisation étudiomètre | Chat | Chacun donne son avis, information non structurée |
| Marché de prédiction | Une solution basée sur une logique de marché émerge |
Use Cases
Evaluation coursInterrogation des étudiants
Signalisation étudiomètre
Evaluation cours
Nom
Evaluation cours
Objectif
Il s'agit de pouvoir donner une évaluation à la fin de chaque cours.
Acteur principal
L'étudiant
Parties prenantes
Le professeur, le service académique
Pré-condition
L'étudiant a déjà créé son profil et configuré ses cours.
Il a également assisté au cours qu'il évalue.
Post-condition
L'étudiant rend le questionnaire.
Cas normal
- 1. Accéder à l'évaluation
- 1.1 L'étudiant lance l'application
- 1.2 L'étudiant s'authentifie dans l'application
- 1.3 L'étudiant choisit le cours à évaluer
- 1.3.1 L'application affiche la liste des cours qui sont disponibles pour évaluation
- 1.3.2 L'étudiant choisit le cours qu'il désire évaluer
- 2. L'étudiant remplit le questionnaire.
- L'étape 2.1 peut être répétée
- 2.1 Répondre à la question affichée
- 3. Valider l'évaluation
- 3.1 Le système affiche un récapitulatif des réponses de l'étudiant
- 3.2 L'étudiant valide sa réponse
Extensions
- 1.3.2a Si le cours n'a pas encore eu lieu (5min avant la fin du cours)
- 1. Afficher un message d'erreur; le cas se termine en échec
- 2.1a Les questions ne sont pas obligatoires
- 1. Continuer la tâche
- 3.1a L'étudiant peut décider de ne pas envoyer son questionnaire
- 1. Le cas se termine en échec.
Interrogation des étudiants
Nom
Interrogation des étudiants
Objectif
Le professeur doit pouvoir poser des questions aux élèves pendant le cours et ceux-ci y répondre par l'intermédiaire de leur device.
Acteur principal
Le professeur
Parties prenantes
Les étudiants
Pré-condition
Le professeur désire intéragir avec les élèves pendant le cours.
Post-condition
Le professeur peut voir les réponses à ses questions.
Cas normal
- 1. Le professeur prépare les questions
- 2. Le professeur pose une question
- 2.1 Le professeur pose une question préparée à l'avance
- 2.2 Le professeur pose une question spontanée
- 3. Les étudiants répondent à la question
- 4. Le professeur termine le sondage
- 4.1 Le professeur attend que le nombre de répondants soit suffisant
- 4.2 Le professeur clôt le vote
- 4.3 Le professeur donne la réponse
Extensions
- 4.1a Les étudiants ne répondent pas à la question; le cas se termine en échec.
Signalisation étudiomètre
Nom
Signalisation étudiomètre
Objectif
Les étudiants doivent pouvoir signaler au professeur leurs besoins pendant le cours.
Acteur principal
Les étudiants
Parties prenantes
Le professeur
Pré-condition
Les élèves participent au cours.
Post-condition
Le professeur répond aux attentes des étudiants.
Cas normal
- 1. Accéder à l'étudiomètre
- 1.1 L'étudiant lance l'application
- 1.2 L'étudiant s'authentifie dans l'application
- 1.3 L'étudiant sélectionne l'étudiomètre
- 2. L'étudiant choisit l'indicateur qu'il veut utiliser
- 2.1 L'étudiant indique qu'il aimerait faire une pause
- 2.2 L'étudiant donne son avis sur le rythme du cours
Extensions
-
Activity Claims
| Situation Feature | Possible Pros (+) or Cons (-) of the Feature | Scenarios |
|---|---|---|
| Questionnaire d'évaluation prédéfini | (+) Analyse et consolidation facile (+) Temps de préparation minime (-) Peut limiter les possibilités |
Evaluation de l'enseignement |
| Evaluation durant les 5 dernières minutes du cours |
(+) Présence des étudiants (+) Feedback régulier (-) Les étudiants risquent de s'en aller sans répondre (-) Consomme 5 minutes de la leçon |
Evaluation de l'enseignement |
| Authentification lors de l'évaluation |
(+) Fiabilité de l'évaluation (-) Réponses biaisées |
Evaluation de l'enseignement |
| Sondage rapide/spontané |
(+) Avis d'ensemble de l'auditoire (+) Pas de temps de préparation (+) Aide à recibler le cours (-) Risque de demander tout et n'importe quoi |
Interrogation des étudiants |
| Accès à l'application depuis un appareil iTouch |
(+) Portabilité, accès non-stop (-) Interactions limitées à des cases à cocher |
Général |
| Visibilité des indicateurs sur l'application ONE |
(+) Possibilité de se coordiner (-) Risque de biaiser les votes (lobbying) |
Signalisation étudiomètre |
| Relayage des informations par le Nabaztag |
(+) Indicateur de déviation permet l'action corrective (+) Visibilité globale de l'information agrégée (+) Visualisation simple (mouvements des oreilles et couleurs des leds) et signaux immédiatement interprétables (-) Risque de distraction (-) Connaître le code représentant les différentes informations |
Signalisation étudiomètre |
Activity Synthesis
Durant notre analyse d'activité, nous nous sommes intéressés à l'ensemble de la situation, prenant en compte les caractéristiques physiques et sociales de l'environnement.
Comme énoncé par le "tradeoff" 3.1 [Rosson, 2002] p. 82 :
Nos scénarios mettent en évidence la manière dont notre application ONE peut transformer les activités existantes. Nous remarquons que les activités que nous avons identifiées peuvent apporter beaucoup en terme de support à l'enseignement. Toutefois, comme il s'agit d'une approche de l'enseignement en rupture avec la conception traditionnelle des cours universitaires, un enjeu de notre système sera de motiver les utilisateurs futurs à adopter le système -- notamment en regard de l'intérêt limité que ces fonctionnalités de support à l'enseignement ont rencontré dans les interviews.
Afin d'inciter les utilisateurs à utiliser l'application ONE, il est indispensable de bien cerner les informations et interfaces pour réaliser ces activités.
Information Metaphors
Nous avons utilisé les métaphores suivantes pour concevoir la représentation et l'organisation des informations contenues dans notre système.
| Project Activity | Real World Metaphor | Implications for Project Activities |
|---|---|---|
| Le questionnaire d'évaluation ressemble à... | une check-list | Structure claire et directe Pas d'omission lors de l'évaluation |
| un bulletin de vote | Réponse à un nombre restreint de sujet Tout ou rien |
|
| une feuille de statistiques sportives | Enregistrement de diverses actions/caractéristiques de l'enseignement au moyen de critères précis | |
| Les questions ressemblent à... | un questionnaire à choix multiples | Possibilités de réponse sous les yeux Facilité d'interaction, direct |
| L'indicateur pour fixer la pause ressemble à... | une horloge | Simple, intuitif et direct |
| une échelle | Position relative de la pause par rapport à la leçon | |
| L'indicateur pour le rythme ressemble à... | une jauge | Simple, indique la déviation |
| une balance | Intuitif, pousse à chercher l'équilibre |
Information Technology Options
| Project Activity | Real World Metaphor | Implications for Project Activities |
|---|---|---|
| Le questionnaire d'évaluation ressemble à... | un formulaire d'inscription en ligne | Une liste d'options paramétrables et préstructurée |
| un assistant d'installation | Des pages ou les options par défaut peuvent être modifiées Possibilité de faire l'évaluation réduite ou complète |
|
| Les questions ressemblent à... | un courriel | Affichage des questions par date et expéditeur |
| un pop-up d'alerte | Non-sollicité, demande une action immédiate | |
| une notification de mise à jour | Répondre immédiatement ou "Rappelez-moi dans 5 minutes" | |
| L'indicateur pour fixer la pause ressemble à... | un curseur de volume | Position relative de la pause par rapport à la leçon |
| un agenda électronique | Vue de la période, simple et intuitif | |
| L'indicateur pour le rythme ressemble à... | une fonction de zoom | Zoom-in pour plus de détails, zoom-out pour aller plus vite |
Information Scenarios
Interrogation des étudiants
Hélène décide de procéder à un sondage spontané.
Sur l'interface professeur de l'application ONE, Hélène accède à l'écran des questions, et choisit de créer une nouvelle question. Elle sélectionne les choix possibles pour les étudiants -- comme il s'agit d'une question rapide, elle choisit de ne pas lui donner de titre -- et valide son entrée. Le système lui montre un aperçu qu'elle confirme.
Les étudiants répondent à la question.
Stefania, inscrite au cours de Madame Yaoundé, est automatiquement notifiée de cette nouvelle question. Elle reçoit un avertissement sous forme de pop-up qui lui propose de répondre immédiatement ou de repousser sa réponse. Stefania choisit de répondre. L'écran où elle peut donner sa réponse s'affiche alors. Elle coche la case "oui", puis valide sa réponse.
Hélène collecte les résultats.
Au fur et à mesure que les étudiants répondent, l'interface professeur d'Hélène lui montre le nombre de votes reçus. Elle peut clôturer le sondage en tout temps -- ce qu'elle fait lorsqu'elle juge le nombre de réponses suffisant. A ce moment, une page de résultats s'affiche montrant le nombre de vote et le pourcentage pour chaque réponse possible. Hélène peut décider de projeter le résultat du sondage ou non. Dans ce cas, comme elle cherchait à savoir qui avait compris un concept, elle considère qu'il n'est pas nécessaire de projeter ce résultat.
Hélène pose une question préparée.
Plus tard durant la séance, Hélène arrive à une question qu'elle avait préparée le soir précédent, alors qu'elle élaborait son cours. Pour cela, elle a dû configurer convenablement les différents paramètres offerts par l'application ONE. Après avoir déterminé le cours auquel appartient cette question et la séance à laquelle elle sera posée, Hélène a défini un titre pour la question et le texte de la question elle-même. Ensuite, elle a configuré les réponses possibles qui seront affichées comme un QCM aux étudiants et elle a enregistré cette question.
Dans la liste de ses questions favorites, le système lui propose automatiquement celle qui correspond à la séance de cours actuelle. Hélène diffuse la question.
Les étudiants reçoivent cette question de la même manière que lors du sondage et y répondent. Une fois le nombre de réponses suffisant, Hélène clôture la question et affiche les résultats. Elle les commente et explique la réponse correcte. Les étudiants reçoivent alors un message contenant la réponse correcte ainsi que les résultats.
Information Claims
| Scenario Feature | Possible Pros (+) or Cons (-) of the Feature |
|---|---|
| Donner la possibilité de reporter une question | (+) Offre de la flexibilité (+) Permet de bien y réfléchir (-) Risque d'oublier de répondre (-) La réponse peut être trop tardive et perd de l'intérêt |
| Répondre à un questionnaire de type QCM | (+) Rapidité de réponse (+) Facilité d'utilisation (+) Analyse des réponses rapide (-) Perte de détail |
| Envoyer la réponse seulement une fois validée (bouton envoyer, double check) |
(+) Permet de confirmer son choix (-) Sentiment d'une étape superflue |
| Enregistre chaque page de feedback séparément et automatiquement |
(+) Permet de revenir sur une question (+) Permet d'arrêter le questionnaire et de revenir dessus (+) Même si le questionnaire est abandonné certaines données peuvent être récupérées (-) Donnée incomplète => moins de signification statistique (-) Les étudiants ne peut pas valider le questionnaire par un bouton (à moins d'en mettre un fictif) pour indiquer qu'ils ont finis |
| Utilisation d'une liste déroulante affichant les réponses possibles et permettant de les sélectioner |
(+) Facilite l'utilisation, car l'input texte n'est pas évident sur un petit device (-) Les réponse prédéfinies limitent les opinions personnelles |
| Trier la liste des questions par default par cours |
(+) Permet de facilement filtrer dans une liste déroulante (-) Certains préfères par date |
Sketches and Screens
Première recherche d'écrans: en vert les services utilisés, en rouge les commentaires et le titre d'écran et en noir, les écrans
InterrogationAutres
Interrogation
Vision d'une interface web pour écran normal pour le professeur afin qu'il puisse préparer ses questions et les prévisualiser.
Fonctions/services utilisées par les écrans du device pour afficher les informations permettant au professeur de poser ses questions et voir les résultats.
Question: écran qui permet de choisir si on veut voir d'ancien résultats, poser une question spontanée ou poser une question préparée à l'avance par le professeur.
New Question: permet de poser des questions spontanées en proposant des questions de type générique, par exemple : oui/non, vrai/faux, appréciation -- - 0 + ++, réponse 1-5
Afin de faciliter la vision, trouver des icône représentatives de ces type de questions. Une fois sélectionné, montrer un exemple avant que le prof envoie la question.
Favorite Question: permet de sélectionner les questions préparées et stockées dans les favoris du profil en faisant défiler horizontalement droite-gauche avec des boutons.
En dessous, les réponses possibles préparées sont affichées et on peut encore choisir des options (durée du questionnaire par exemple) si c'est nécessaire.
Un bouton permet de démarrer/envoyer/annoncer le questionnaire aux étudiants inscrits aux cours.
Results: Il n'est pas encore clair quel format permettra l'affichage le plus clairement les résultats à l'écran, il faudra tester sur un prototype de taille réel. Nous supposons deux modes en fonctions de l'orientation de l'appareil, soi les résultats et le graphiques l'un à côté de l'autre, soi des onglets.
Il doit être possible de voir le nombre de personnes qui ont répondu, ainsi que de forcer l'arrêt du questionnaire.
Partie écran vue par l'utilisateur étudiant, ainsi que les services requis.
Misc.Widget: Exemple d'une notification avertissant l'étudiant qu'une nouvelle question a été posée. Donner la possibilité de répondre tous de suite (accepter la question) ou de la remettre à plus tard.
Question: Exemple d'une question où l'utilisateur peut choisir la réponse, changer d'avis et confirmer sa réponse avec un bouton
Question List: Affichage d'un historique des questions, par cours, afficher les questions ouvertes au début, et les questions fermés(passé) d'une autre manière.
Question List Filter: exemple d'interface de list avec le menu de filtre activé qui permet de filtrer avec des listes déroulantes. Mise à jour de la liste de manière instantanée sans devoir confirmer
Autres
Feedback: Ecran d'un formulaire de feedback de fin de cours à plusieurs questions réparti sur des pages avec un système d'onglets.
le dernier onglet est un récapitulatif des réponses et contient un bouton pour envoyer sa réponse.
ONE (première colonne): Ecran principal de l'application qui affiche deux "widgets"
Speed: Ecran pour l'étudiomètre "slider" pour mesurer la vitesse subjective resenti par l'étudiant
Break: List de choix pour indiquer ses préférence par rapport à la prochaine pause.
ONE: Ecran principal idée comment gérer les widgets les cacher en mode icone et les faire venir avant les autres quand ils sont agrandis comme le fait TiddlyWiki. Il faudra tester la préférence des utilisateurs par rapport à la position des icônes.
Possibilité d'utiliser l'effet de zoom/dézoom et de déplacement avec la main de la partie visible de l'écran sur l'iphone dans safari pour afficher le différents "widgets" et passer de l'un à l'autre.
Services and Functions
Nous analysons ici les différents services, composants, sous-composants et leurs fonctions respectives. Concernant l'interaction entre ceux-ci, voir les diagrammes de séquences.
Application ONE
La partie principale de notre application est le premier écran affiché après démarrage de l'application. Nous appellerons cet écran le dashboard, celui-ci sert à afficher des modules (widgets) qui regroupent l'information des différents services dont l'utilisateur (l'étudiant ou le professeur) aura besoin le plus fréquemment.
Il faut donc pouvoir gérer des profils et la personnalisation du dashboard.
3rd Party
La gestion des utilisateurs et leur authentification pourrait être gérées par un service d'annuaire existant. Nous créerons simplement une fonction de login générique pour notre prototype.
Les différents widgets utilisent principalement des ressources externes tel les flux RSS unil-menu, la page HEC Info TV, l'accès à la base de donnée Moodle pour les devoirs, les documents récents, ainsi que le système de gestion des horaires de l'Unil.
Etant donné que nous développerons uniquement un prototype et que nous ne nous focalisons pas sur ces widgets nous n'allons pas plus parler de l'interaction avec ces services, ainsi que des fonctions nécessaires pour leur réalisation.
iLearn
iLearn est le nom du module d'aide à l'enseignement que nous approfondissons au long de ce projet.
Nous posons une première hypothèse simplificatrice et nous supposons que les utilisateurs ont configuré dans leur profil les informations nécessaires pour que l'on puisse savoir à quels cours ils sont inscrits. Nous ne traitons donc pas des fonctions pour gérer un planning de cours, mais supposons que l'information existe.
Comme présenté dans les scénarios, iLearn est décomposé en trois grandes activités (évaluation des cours, interrogation des étudiants et étudiomètre). Toutefois, la pré-condition la plus importante s'applique à tout le module et consiste à n'afficher et traiter que les questions, feedbacks, et autres événements liés aux cours pour lesquels l'utilisateur est effectivement inscrit, et donc autorisé à interagir.
Evaluation de l'enseignement
Comme pré-condition, l'état à tester pour cette partie est de savoir si le cours a eu lieu, et d'assurer que l'élève n'a pas déjà rempli le questionnaire.
Il n'y a pas de post-condition à vérifier étant donné que nous autorisons des questionnaires remplis partiellements.
Question
Il y a deux types de questions, mais il faut vérifier que la question est encore ouverte quand l'étudiant veut y répondre dans le cas où il l'aurait reportée à plus tard.
Etudiometre
Pour les indications de l'étudiomètre: vitesse et pause, il faut traiter l'intervalle de temps entre les réponses de l'étudiant afin d'éviter des abus et il faut que l'on soit pendant une heure où le cours a lieu.
Information Synthesis
En réalisant l'analyse d'information, nous avons cherché des métaphores et des représentations des informations manipulées par l'utilisateur qui exploitent au mieux les réprésentations et modèles mentaux existants des utilisateurs. Comme il nous est impossible d'observer directement ces modèles, nous avons dû faire des hypothèses sur la base des entretiens.
Au niveau de l'affichage de l'information, nous nous heurtons à l'éternel dilemme consistant à déterminer s'il faut mettre un bouton pour valider ou si chaque réponse est enregistrée lorsque la case correspondante est cochée. Le tradeoff doit se faire entre l'homogénéité et la diminution des erreurs. Que cela soit Windows (avec) contre OsX (sans) ou KDE (avec) contre Gnome (sans), le débat persiste. Dans notre cas, nous optons -- dans la mesure du possible -- pour une interface sans boutons de confirmation, avec le problème de savoir si l'utilisateur a effectivement terminé de remplir le questionnaire. Toutefois, dans le cas d'une question unique, nous préférons mettre un bouton de validation pour diminuer le taux d'erreur.
Nous mettront cette configuration à l'épreuve auprès des utilisateurs lors des essais du prototype afin de déterminer l'option la plus appropriée.
Apple iPhone Resources
Design
- Apple Developer Connection - Web Apps Dev Center - Designing Content- iphone.wikidot.com
Frameworks
- iui - User Interface (UI) Library for Safari development on iPhone- jpint
- How to eclipse & aptana iPhone
iPhone Simulator
- iphonetester.com- testiphone.com
- marketcircle.com/iphoney/
Interaction Resources
* humanized.com/reader/ "River of news" défilement infini à la place de naviguer de page en page (loading ajax)
* socialhelix.com navigation dans un calendrier grâce à du zoom-dezoom avec des cliques ou mouvements (contre-)rotations de la souris
* worrydream.com/Scrolltabs/ prototype d'alignement de tabs verticalement
source: Google TechTalk de Aza Raskin - Don't Make Me Click
Interaction Metaphor
| Project Activity | Real World Metaphor | Implications for Project Activities |
|---|---|---|
| Le questionnaire d'évaluation ressemble à... | un formulaire d'inscription en ligne | Les points sont organisés en listes et activés avec des boutons |
| un assistant d'installation | Les pages sont préconfigurées et peuvent être modifiées en touchant aux endroits adéquats | |
| Les questions ressemblent à... | un courriel | Toucher le titre pour afficher la question, toucher la date pour trier par date, l'expéditeur pour trier par expéditeur |
| un pop-up d'alerte | appuyer sur le message pour ouvrir la question | |
| une notification de mise à jour | appuyer sur le message pour ouvrir la question, appuyer sur le bouton correspondant pour repousser | |
| L'indicateur pour fixer la pause ressemble à... | un curseur de volume | glisser le curseur pour fixer le moment souhaité |
| un agenda électronique | Toucher l'heure souhaitée | |
| L'indicateur pour le rythme ressemble à... | une fonction de zoom | Pinch-in pour aller plus lentement, pinch-out pour aller plus vite |
Interaction Technology Options
| Project Activity | Real World Metaphor | Implications for Project Activities |
|---|---|---|
| Le questionnaire d'évaluation ressemble à... | une check-list | Toucher les cases à cocher pour répondre |
| un bulletin de vote | Cocher la réponse puis toucher le bouton envoyer | |
| une feuille de statistiques sportives | remplir les champs pertinents grâce à des boutons préconfigurés | |
| Les questions ressemblent à... | un questionnaire à choix multiples | Remplir en touchant les réponses choisies |
| L'indicateur pour fixer la pause ressemble à... | une horloge | Toucher pour indiquer l'heure souhaitée |
| une échelle | ajuster la position pour déterminer l'heure | |
| L'indicateur pour le rythme ressemble à... | une jauge | déplacer le curseur de la jauge avec le doigt pour indiquer le rythme |
| une balance | appuyer sur le côté de la balance que l'on souhaite faire pencher (+vite/+lentement) |
Adopted Patterns
Usability Engineering
by Rosson & Carroll
Icons vs words
Tradeoff 4.3BUT familiar terms are usually less distinctive and precise, and what is familiar for one person may not be familiar for another
Solution: Afficher des icônes et du texte.
Où: liste des nouvelles questions spontanées, soit l'icône, soit le texte devrait donner une idée à l'utilisateur de ce qui se cache derrière et sinon il y a encore le pattern de "preview" (voir ci-dessous).
iPhone Human Interface Guidelines for Web Applications (src)
by Apple Inc.
The iPhone User Interaction Model
Problème: L'interaction se fait par les doigts.
Solution: Utiliser la notion de zoom ("Pinch"), et de déplacement de la vue ("Drag/pan").
Où: écran principal, écran avec grandes images (graphique,..)
Minimize Required Input & Provide Fingertip-Sized Targets
Problème: L'interaction se fait par les doigts.
Solution: Ne pas demander une entrée manuelle, mais proposer des choix, créer des boutons suffisamment grands.
Où: choix multiple pour les questions, liste déroulante pour les filtres dans la liste des questions.
Consider the List Approach
Problème: L'interaction se fait par les doigts et l'écran est petit, dans la plupart des autres applications l'information est sous forme de liste
Solution: Utiliser des listes là où c'est possible
Où: écran de choix des options, ...
Navigation
Problème: La navigation se fait dans Safari (un "browser"), il faut donc considérer le pattern du bouton retour dans notre application.
Solution: Utiliser le bouton back du "browser" ou proposer un bouton retour en haut à gauche qui respecte le pattern de navigation des autres applications iPhone.
Où: tous les écrans.
Interaction Patterns in User Interfaces
by Martijn van Welie
Navigating between Spaces
Problème: La place disponible pour l'affichage est très limitée et le nombre d'information à afficher est grand.
Solution: Utilisation d'onglets pour augmenter la place. Création de raccourcis pour atteindre facilement une section plus bas dans le défilement vertical.
Où: questionnaire d'évaluation pour le cours, ...
Preview
Problème: L'utilisateur cherche un objet en naviguant à travers un petit ensemble.
Solution: Afficher un aperçu des objets.
Où: sélection de questions.
Favourites
Problème: Il faut trouver la question à poser parmi un nombre de plus en plus grand de question.
Solution: Permettre à l'utilisateur de créer des favoris pour les questions les plus utilisées.
Où: organisation des questions préparées à l'avance par le professeur.
Command Area
Problème: L'utilisateur doit savoir comment trouver facilement les commandes qu'il cherche et comment les activer.
Solution: Placer les commandes dans une région facilement identifiable.
Où: barre de menu dans l'application principal.
Continuous Filter
Problème: L'utilisateur doit trouver un objet parmi une liste triée
Solution: Proposer un composant de filtre qui permet de filtrer en temps réel et afficher les objets qui ont un intérêt pour l'utilisateur.
Où: liste des questions ouvertes, passées.
Sequences Diagrams
A la place de refaire un scénario encore plus détaillé sur les interactions nous avons préférés dessiner des diagrammes d'activités pour la partie e-Learning de notre application.
Comme le temps à disposition est limité, nous avons réduit notre analyse à l'interaction avec le device mobile et ne traitons pas l'interaction sur grand écran pour la création de questions personnalisées par le professeur. Nous avons également exclu de notre analyse toutes la partie détaillée sur la création/configuration des profils d'utilisateurs ainsi que leurs préférences et supposons simplement que celles-ci sont présentes. C'est à dire qu'il est possible de savoir à quels cours l'étudiant est inscrit et on peut ainsi lui fournir des informations dans le contexte de son planning journalier et faire de même pour les cours enseignés par le professeur.
Certaines interactions se font en local (afficher/cacher plus d'informations), afin d'accélérer l'interactivité des pages. D'autres se font en AJAX, afin de ne devoir charger qu'une partie de la page. Pour différencier ces interactions des chargements de pages normaux nous avons un objet ClientJS dans nos diagrammes.
Interactions sur la partie principal de l'application (Dashboard)
Interactions sur le module (widget) iLearn
les trois tâches sont traitées
Interaction Claims
| Scenario Feature | Possible Pros (+) or Cons (-) of the Feature |
|---|---|
| Icônes plutôt que des mots |
(+) Prend de moins de place, pratique pour un petit device (-) Peu ne pas être compréhensible par tous |
| Fonction de zoom |
(+) Permet de pouvoir lire des choses illisibles en vue normale (-) une fois zoomé, on ne voit plus le reste |
| Interaction avec les doigts |
(+) Eviter de devoirs utiliser un stylet (+) Plus directe et immédiat (-) Moins précis précision (-) Plus difficile à écrire du texte (-) Sali l'écran |
| Utilisation de listes |
(+) Facilite la navigation (+) Pas besoin d'utiliser un clavier pour entrer du texte (-) Limite les choix de l'utilisateur |
| Menus déroulants |
(+) Permet d'économiser de l'espace (-) Doit toucher le menu pour voir toutes les options possibles |
| Utilisation d'onglets |
(+) Economie d'espace (-) Cache de l'information |
| Preview (aperçu avant d'appliquer) |
(+) Vue d'ensemble des informations principales (-) Ralenti l'habitué |
| Favourites |
(+) Permet de classer les éléments par préférence (-) Oublie de certains éléments |
| Menu area |
(+) Regroupe toutes les commandes à disposition (+) Permet d'accomplir rapidement une fonction (-) Ce que va faire la fonction n'est pas forcément clair |
| Continuous Filter |
(+) Permet d'afficher les objets qui ont un intérêt particulier pour l'utilisateur (-) Oublie d'autres objets pouvant avoir de l'utilité |
Interaction Synthesis
La question de l'utilisation d'un bouton pour confirmer évoquée dans l'analyse d'information nous pousse à nous interroger sur la manière dont l'utilisateur peut corriger ses erreurs de saisie. Ceci nous ramène au TRADEOFF 5.9 [Rosson, 2002] p. 176 :
D'après des utilisateurs potentiels, un bouton de validation ne serait pas gênant, car ils retrouvent ce genre de fonction sur un nombre important de sites web et autres programmes. Le bouton de validation ne permet pas l'annulation, mais autorise l'utilisateur à modifier son choix jusqu'à ce qu'il soit sûr de ce qu'il envoie. Ainsi, il ne risque pas de transmettre par erreur une information non voulue.
Par rapport à la manière d'indiquer les fonctions à l'écran, la décision d'utiliser des icônes plutôt que du texte est modérée par le TRADEOFF 5.2 [Rosson, 2002] p. 163 :
A travers les entretiens, nous constatons que les étudiants ont l'esprit d'apprentissage et de découverte et ne verraient pas des icônes comme un obstacle ou un frein à l'utilisation de l'application. Du point de vue des professeurs, nous devons tenir compte du fait que leur expérience et leur aisance avec les applications utilisant fortement les icônes n'est pas si prononcée que celle des étudiants.
Afin de permettre aux utilisateurs une focalisation sur la tâche à accomplir, l'utilisation de favoris ou de filtres peut nous rapprocher du TRADEOFF 5.10 [Rosson, 2002] p. 178 :
Les utilisateurs n'avaient pas considéré cet aspect du problème. L'utilisation d'un filtre leur faciliterait la vision à l'écran en affichant uniquement les choses qui leur sont importantes, mais ils pourraient en négliger d'autres. Tous comme pour les favoris : en utilisant uniquement ceux-ci, les utilisateurs pourraient laisser de côté d'autres fonctions qui leur seraient utiles à d'autres moments.
L'affichage et les interactions imaginés pour la partie dashboard doivent en premier lieu être testés sur un mini-prototype, car étant donné le manque d'expérience avec des appareils comme l'iPhone, nous ne savons pas s'il y a assez de surface d'affichage pour les réaliser de manière satisfaisante.
Dans le futur, nous imaginons sélectionner les étudiants qui reçoivent les messages par un système basé sur la localisation et souscription (location based publish subscribe).
Web Paper
le prototype semi-interactif web paper
Introduction
Nous avons fait tester note prototype papier à plusieurs étudiants afin de pouvoir observer les réactions, les manières d'agir, les difficultés rencontrées face aux différentes fonctionnalités ainsi que le caractère intuitif de l'interface. Nous nous sommes concentrés sur la fonction "iLearn" de notre application et n'avons pas testé ce qui concerne les horaires, les menus de la cafétéria, les informations, etc...
Pour se faire, nous avons proposé aux étudiants de réaliser certaines tâches que nous avons filmées:
- - Répondre à une question envoyé sur le device pendant le cours
- - Remplir une évaluation du cours
- - Signaler au professeur que le cours va trop vite
Pour rendre notre application plus complète, nous avons aussi rajouter d'autres fonctionnalités telles que les menus de l'UNIL, les diverses informations à disposition, les horaires de cours et un agenda. Mais celles-ci ne sont pas testées.
Prototype
Le prototype testé est celui du point 7. Il permet à l'utilisateur de se faire une idée de la fonction "iLearn" de notre application qui permet de répondre à des questions, d'évaluer l'enseignement ou de mesurer le cours. Ci-après, certains extraits vidéos du prototype testé par différentes personnes.
Tâche : répondre à une question
Testé par Nadine
Testé par Benjamin
Tâche : indiquer la vitesse du cours
Testé par Nadine
Testé par Benjamin
Testé par Benedikt
Tâche : évaluation du cours
Testé par Nadine
Testé par Benjamin
Testé par Benedikt
Method
Participants
Pour le test de notre prototype nous avons choisi des étudiants de HEC au hasard à différents stades de leurs études (bachelor et master).
Le scénario proposé aux participants est le suivant:
L'étudiant est en cours et le professeur décide de poser une question à laquelle les étudiants doivent répondre dans la semaine à venir (avant la prochaine séance). Un pop-up apparaît sur le device et l'étudiant peut:
- - Répondre directement à la question
- - Différer sa réponse en refusant la question
Par ailleurs, l'étudiant aimerait pouvoir indiquer au professeur que le cours va trop vite et qu'il serait bien de ralentir la cadence.
A la fin du cours, le professeur voudrait que les étudiants remplissent une évaluation sur la session passée afin de pouvoir adapter son cours.
Spécifications d'usage et procédures
Nous avons cherché à rendre la navigation la plus intuitive possible. Pour se faire, les participants ont été laissés libre de se débrouiller comme ils le pensaient avec le prototype. Nous avons juste dû leur indiquer ce que voulait dire le terme "étudiomètre" que nous avons inventé, car son sens n'était pas forcément clair lors d'une première navigation.
- L'utilisateur doit pouvoir se déplacer dans la l'application sans devoir tester toutes les possibilités avant de trouver.
- L'utilisateur doit savoir où il se trouve dans le site.
- L'utilisateur doit pouvoir savoir ce que fait le bouton retour; annule-t-il l'action effectuée ou fait-il simplement un retour à la page précédente?
- L'utilisateur utilise-t-il le bouton de validation à la fin de sa tâche?
Le point suivant observé est la présentation de l'information. Nous avons regardé si:
- L'information souhaitée a été trouvée.
- L'utilisateur a utilisé les filtres.
- L'information était présentée de manière logique pour l'utilisateur.
- La correspondance entre les représentations et les objets du monde réel a été claire (curseur).
Le prochain critère concerne la structure de l'interface:
- Si la disposition des fonctions associée aux tâches est logique.
- S'il n'y a pas de surcharge d'information ou de l'information non pertinente.
- S'il y a un équilibre entre l'information de l'écran principal et les écrans secondaires
Finalement nous avons observé la clarté du format des questionnaires, si:
- La notion d'onglets était claire.
- Les boutons (par exemple: envoyer) étaient pertinents.
Measurements and observations
Afin de mesurer l'impact de notre design sur les activités des utilisateurs, nous avons utilisé le questionnaire d'usefulness and ease of use développé par Todd Zazenlenchuck dans son application Datalogger.
Nous obtenons les résultats suivants :
Aisance d'utilisation et utilité perçue, résultats généraux
Aisance d'utilisation et utilité perçue, résultats détaillés
Results of the tests
Résultats du test
Mis à part le soucis avec la définition de "l'étudiomètre" (souvent ignoré au profit de l'évaluation du cours), la navigation a parue très intuitive pour nos utilisateurs. Le bouton retour, a été utilisé par les participants pour revenir à la page précédente sans valider ce qui a été fait. Concernant la validation par bouton, en ayant mis à certains endroits et pas à d'autres, les participants au test ont été un peu perdu quand il n'était pas là. Leur suggestion était de le mettre à chaque endroit, comme ça ils sont sûr que leur choix a bien été enregistré. Lorsqu'une question reçue par pop-up était reporté, les utilisateurs n'ont pas eu de difficulté à la retrouver ultérieurement. Enfin, sur le dernier point observé, il paraissait logique de devoir déplacer le curseur vers la gauche (en direction du "-") pour faire passer le message que le cours va trop vite et qu'il faudrait ralentir la cadence.
Discussion
Bien que les personnes testées avaient de la peine à s'imaginer être en face de quelque chose qui deviendrait une application concrète, nous observons grâce au questionnaire de satisfaction que le design ainsi que l'apprentissage de l'application est apparu facile d'utilisation.
Futur
La première chose à améliorer est l'uniformisation du bouton de validation, c'est à dire de le mettre partout où il est attendu. Ensuite, nous allons devoir changer l'interface prévue car nous utiliserons l'interface iPhone standard ce qui réduit l'espace d'affichage et nécessite un certain formalisme de menu. Nous allons aussi modifier les pop-up afin qu'ils intègrent déjà la question. Enfin, notre système de filtre pour les questions n'ayant pas trouvé vraiment d'intérêt, nous allons moins le développer.
Documentation
Demo
login:password
- Etudiants: s1:1, s2:2, ...
- Professeurs: t1:1, t2:2, ...
Schema
La zone Prototype Admin permet d'accéder aux différentes tables, ainsi qu'au service de Nabaztag et à notre Nabaztag virtuel.
Users: Etudiant ou professeur
Un professeur donne des cours.
Type: direct: question d'instantanée, perso: question préparé, feedback: questionnaire d'évaluation.
Session: instance de questions d'un certain type. A un statut "open" ou "closed" (quand le professeur l'a cloturée).
Question: contient le texte de la question lié à des questions items pour les réponses.
Un étudiant peut donner une réponse (answer) à une session qui est encore ouverte (open).
Messages: sont des messages à afficher à l'étudiant, quand une nouvelle session est créée (action="notification", value= id de la session). Aussi utilisé pour passer les messages au service Nabaztag (action="stop"), (action="speed, value = int speed). Ce service fait respectivement le total et la moyenne, puis gère l'affichage.
Fonctionnalités
Sans login
- UNIL MENU: affiche le flux RSS du menu du jour.
- Informations: affiche les flux RSS des différents informations de l'unil et de HEC, ainsi que des informations de HEC INFO TV transformées en flux RSS.
- Documents: (nouveaux documents pour les cours) statique non approfondi dans ce prototype.
- Agenda: (nouveaux questionnaires par cours/horraire) statique non approfondi dans ce prototype.
- Horaires: statique non approfondi dans ce prototype.
Avec login
- Campus card: affiche le total de la campus card et les derrnières transactions (données d'exemple, pas approfondi dans ce prototype.)
- Profil: permet de changer le mot de passe.
Mode étudiant
- iLearn > Questions: affiche les questions personnelles qui sont encore ouvertes et non répondues.
- iLearn > Feedback: permet d'accéder aux questionnaires d'évaluation ouverts, qui n'ont pas encore été complètement remplis. Si le questionnaire est interrompu au milieu de la saisie, on peut reprendre depuis la dernière question répondue.
- iLearn > Etudiomètre: permet d'indiquer la vitesse et de demander une pause.
Mode Professeur
- Annuaire: permet de rechercher l'annuaire HEC avec photo
- iLearn> Poser une question: permet de créer une nouvelle session de question. En fonction du type sélectionné, la liste de questions disponibles change.
- iLearn> Résultats: permet de voir les sessions fermées et ouvertes (et de les fermer le cas échéant).
Limitations connues
- Certains flux RSS dans la partie informations ont des problèmes d'encodage.
- Poser une question: pas de fonctionnalité de favoris pour le professeur dans cette version.
- Les vues de professeur ne sont pas filtrées par professeur dans cette version.
Technique
Php/MySQL avec le framework cakephp, et le framework JS iui largement modifié pour la mise en page du prototype.
Intégration avec le Nabaztag
Description
Nous avons testé et réalisé la communication avec le Nabaztag pour la partie étudiomètre de notre composant iLearn. Le but est d'utiliser les capacités ambiantes de celui-ci, c'est à dire lumières et positions des oreilles, pour donner du feedback au professeur.
Les trois lumières horizontales sont utilisées pour indiquer la vitesse perçue par les étudiants (le professeur va trop vite ou trop lentement), la led du nez en combinaison avec les oreilles sont utilisées pour indiquer si les élèves désirent une pause.
Les codes de couleurs:
- bleu = trop lent
- vert = ok
- rouge = trop vite
- vert oreilles II = ok
- rouge oreilles -- = stop-> pause
Pour faciliter, l'interaction et le développement nous avons tout d'abord créé un service virtuel qui affiche les lumières comme si elles étaient envoyées à l'api réelle. Ensuite nous avons développé le vrai service qu'il faut laisser ouvert tant que l'on veut que les messages soient envoyés à l'api Nabaztag de chez Violet.
Dans un second temps nous voulions augmenter l'interaction avec le lapin et permettre la remise à zéro des compteurs, par exemple après la pause, en bougeant ses oreilles manuellement. De même que de les mettre dans une autre position pour signaler la fin du cours et déclencher l'envoie du questionnaire de feedback.
Limitations
La récupération de la position des oreilles bougées manuellement ne fonctionne pas, on ne reçoit que la valeur stockée sur le serveur. Il faut donc se contenter pour l'instant des boutons pause et fin du Nabaztag virtuel pour simuler l'interaction
Un autre problème provient du fait que l'on ne peut pas fixer les lumières à une couleur indéfiniment dans le temps. On peut uniquement envoyer une "chorégraphie" et une fois celle-ci terminée, le lapin se remet dans un mode autonome.
iPhone Simulator
A regarder avec safari!
ouvrir dans une nouvelle fenêtre (moins de bug).
Prototype
Etudiant: login: s1 password: 1
Professeur: login: t1 password: 1
Introduction*
Comme pour le prototype papier, nous avons fait tester la version interactive à plusieurs étudiants de divers niveaux afin de pouvoir observer leurs réactions, leurs manières d'agir, les difficultés rencontrées face aux différentes fonctionnalités ainsi que le caractère intuitif de l'interface. Nous nous sommes concentrés sur la fonction "iLearn" de notre application.
Pour se faire, nous avons proposé aux étudiants de réaliser certaines tâches (les mêmes que pour le prototype papier) que nous avons filmées:
- - Répondre à une question envoyé sur le device pendant le cours
- - Remplir une évaluation du cours
- - Signaler au professeur que le cours va trop vite
Cette fois-ci nous avons aussi laissé nos testeurs naviguer dans le prototype sur les autres fonctionnalités comme les horaires, les menus de la cafétéria, les informations, etc... Ceci afin de recevoir aussi un avis plus global sur notre prototype et ses différentes possibilités.
Prototype*
Tâche : Répondre à une question
HCI - Usability test interactive prototype - Question
Tâche : Remplir une évaluation
HCI - Usability test interactive prototype - Feedback
Tâche : Indiquer la vitesse du cours
HCI - Usability test interactive prototype - Speed
HCI - Usability test interactive prototype - Speed (2)
Autres fonctions de l'application
HCI - Usability test interactive prototype - Other functions
Method*
Participants
Pour le test de notre prototype nous avons choisi des étudiants de HEC à différents stades de leurs études (bachelor et master) et nous leur avons aussi demandé quel était leur niveau de familiarité avec l'iPhone (iPod touch). De cette manière, nous souhaitions toucer différents types d'utilisateurs potentiels.
Le scénario proposé aux participants reste le même:
L'étudiant est en cours et le professeur décide de poser une question à laquelle les étudiants doivent répondre dans la semaine à venir (avant la prochaine séance). Un pop-up apparaît sur le device et l'étudiant peut:
- - Répondre directement à la question
- - Différer sa réponse en refusant la question
Par ailleurs, l'étudiant aimerait pouvoir indiquer au professeur que le cours va trop vite et qu'il serait bien de ralentir la cadence.
A la fin du cours, le professeur voudrait que les étudiants remplissent une évaluation sur la session passée afin de pouvoir adapter son cours.
Spécifications d'usage et procédures
pour tester l'intuitivité de notre prototype, nous avons laissé les participants de se débrouiller comme ils le pensaient avec le prototype. Nous avons juste dû leur indiquer le but de l'application "iLearn" et la signification du terme "étudiomètre" que nous avons inventé, car son sens n'était pas forcément clair lors d'une première navigation.
- L'utilisateur doit pouvoir se déplacer dans l'application sans devoir tester toutes les possibilités avant de trouver.
- L'utilisateur doit savoir où il se trouve dans le site.
- L'utilisateur doit pouvoir savoir ce que fait le bouton retour; annole-t-il l'action effectuée ou fait-il simplement un retour à la page précédente?
- L'utilisateur utilise-t-il le bouton de validation à la fin de sa tâche?
Le point suivant auquel nous avons fait attention est la présentation de l'information. Nous avons observé si:
- L'information souhaitée a-t-elle été trouvée.
- L'information était présentée de manière logique pour l'utilisateur.
- La correspondance entre les représentations et les objets du monde réel a été claire (curseur).
Le prochain critère concerne la structure de l'interface:
- Si la disposition des fonctions associée aux tâches est logique.
- S'il n'y a pas de surcharge d'information ou de l'information non pertinente.
- S'il y a un équilibre entre l'information de l'écran principal et les écrans secondaires
Finalement nous avons observé la clarté du format des questionnaires, si:
- La notion d'onglets était claire.
- Les boutons (par exemple: envoyer) étaient pertinents.
Measurements and observations*
Afin de mesurer l'impact de notre design sur les activités des utilisateurs, nous avons utilisé le questionnaire d'usefulness and ease of use développé par Todd Zazenlenchuck dans son application Datalogger.
Nous obtenons les résultats suivants :
Aisance d'utilisation et utilité perçue, résultats généraux
Aisance d'utilisation et utilité perçue, résultats détaillés
Results of the tests*
Résultats du test
La navigation a parue plutôt intuitive pour l'ensemble de nos utilisateurs. Pour les habitués d'Apple, ils se sont sentis comme des poissons dans l'eau. La validation par bouton a été claire et bien comprise, ce qui n'avait pas été le cas avec le prototype papier. La raison était le manque d'uniformisation que nous avons réglé. Lorsqu'une question reçue par pop-up était reportée, les utilisateurs n'ont pas eu de difficulté à la retrouver ultérieurement.
Enfin, il était toujours logique de devoir déplacer le curseur vers la gauche si l'utilisateur estimait que le cours allait trop vite. Mais ici, nous avons rencontré un problème dû à l'iPhone qui ne supporte pas le "drag-and-drop". Nos testeurs ont essayé à plusieurs reprises de tirer le curseur sur la gauche sans succès. Nous avons dû leur dire qu'il fallait cliquer à l'endroit désiré sur la barre afin de le déplacer. todo:insert videoDiscussion
Les étudiants ont été surpris par notre application. Un peu désemparés au premier abord, ils se sont vite accommodés et ont pris du plaisir à naviguer dans l'iPhone et de retrouver les divers services offerts sur internet de manière centralisée. Par contre, lorsqu'il fallait entrer du texte, l'expérience s'est avérée peu évidente, voire frustrante, sur l'écran tactile (sûrement une question d'habitude en rapport avec la petite taille du device).
La comparaison des scores de perceived ease of use and usefulness montre un niveau légèrement plus bas pour le prototype interactif que pour le prototype papier. Nous trouvons une facilité d'utilisation moyenne de 4.8 contre 5.0 et une utilité perçue de 5.3 contre 6.1. Nous expliquons cette différence par certaines contraintes liés aux fonctions de l'Ipod Touch (drag-n-drop et saisie de texte) et aussi car les utilisateurs se montrent moins cléments face à un prototype fonctionnel haute fidélité que face à une ébauche comme la version papier.
Comment
Malheureusement, à cause de la complexité du projet et du temps nécessaire pour le développement du prototype et l'intégration avec le Nabaztag, nous n'avons pas effectué deux itérations complètes. Cependant, suite à la réalisation d’une première version du prototype, nous avons fait des choix qui auraient été sans doute fait durant la deuxième itération. Par exemple, faire passer plus d’information à travers le message (boîte de dialogue) qui apparaît lors d’un nouvel évènement. La question peut apparaître directement sans nécessité de cliquer sur un lien pour y accéder.
Conclusion
Pertinence
Activités
En regard des commentaires des futurs utilisateurs, la centralisation des services d'information de l'université remporte tous les suffrages. En revanche, nous remarquons que la fonction iLearn dédiée au support à l'enseignement a un succès mitigé. Les utilisateurs ne réalisent pas bien le potentiel de ces fonctionnalités. Cette fonction iLearn fait l'originalité de notre projet et c'est l'innovation que nous proposons. Pour cette raison, les utilisateurs n'ont pas de points de repère auxquels comparer cette solution. Les "zapettes" (utilisées de façon très sporadique) s'en rapprochent, mais présentent des désavantages logistiques (le professeur doit les emporter avec lui à chaque cours) alors que l'hypothèse à la base de ce projet est que les utilisateurs disposent chacun d'un device iTouch. Notre application offre notamment des possibilités beaucoup plus flexibles par rapport au type de questions et d'intervalles de temps de réponse. Bien évidemment, la possibilité pour les étudiants d'indiquer le rythme au professeur et de lui suggérer des pauses remet en cause la conception communément admise des cours ex-cathedra : il ne s'agit plus pour le professeur de donner son exposé magistral de manière unilatérale mais d'opérer un changement de point de vue pour se mettre au service des étudiants dans l'intention de produire un apprentissage de qualité. C'est aussi cette intention qui sous-tend la fréquence plus élevée des questionnaires d'évaluation. Par rapport au "tradeoff" 3.1 [Rosson, 2002] p. 82 :
BUT incremental changes are easier to understand and adopt.
Nous en déduisons que notre proposition iLearn provoque probablement une disruption dans la tâche qui remet en cause les besoins actuellement perçus par les utilisateurs.
C'est aussi pour intégrer le Nabaztag aux activités du projet que nous avons mis au point les possibilités d'indication de rythme et de pause, le lapin étant le reflet de l'état moyen de l'audience.
Méthode et matériel
Nous remarquons, après avoir accompli les différentes étapes qui ont abouti au design des versions papier et haute fidélité du prototype, que cette méthode - et notamment l'élaboration des scénarios - permet de se poser les bonnes questions et de les confronter ensuite à la vision des utilisateurs.
Dans l'idéal, nous aurions souhaité faire plus d'itérations entre les différentes phases, ce qui nous a été impossible compte tenu de la courte durée du projet. Nous avons aussi dû nous résoudre à certains compromis à cause de contraintes techniques liées à la technologie utilisée. Par exemple, le problème d'usabilité posé par le slider aurait pu être résolu dans une application native codée avec le SDK iPhone (avec tous les autres problèmes, par exemple le déploiement). Nous nous heurtons ici aux limites imposées par l'application web.
Réactions des étudiants
Nous avons rencontré de l'enthousiasme et éveillé la curiosité des étudiants qui ont participé aux tests. L'idée leur paraît bonne et les différentes options centralisées sont un plus pour eux. Plusieurs soulèvent la question de l'investissement que représente un iPhone ou un iPod touch : ils n'en ont pas tous les moyens, ni forcément l'envie.