Semaine 6
Activité 2
Prototypage Hi-Fi
Les prototypes Lo-Fi permettent de faire évoluer la conception très rapidement. Par contre, ils présentent quelques lacunes que peuvent très bien combler les prototypes Hi-Fi.
Voici quelques désavantages des prototypes LO-FI :
– la reconnaissance des éléments est parfois difficile;
– l’esthétique/équilibre est difficile à juger (c’est aussi un avantage!);
– il est impossible d’évaluer le temps que prend l’accomplissement d’une tâche;
– il est difficile de modéliser les glisser-déplacer.
Pourquoi utiliser les prototypes Hi-Fi?
– ils permettent de mieux tester la vitesse de réponse du système;
– ils permettent d’aller plus loin dans les détails (p. ex., glisser-déplacer (Drag Drop);
– ils permettent de mieux juger de la finition du logiciel.
À cette étape, il convient très bien d’utiliser les outils de prototypage ou de construction d’interface (« UI Builder »). Par contre, il est très important de ne pas entrer dans l’implémentation du système. On traite ici seulement de l’interface. Encore à ce stade, il est possible que de gros changements dans l’interface surviennent et nécessitent des changements majeurs dans le code.
Il existe une multitude d’outils de prototypage (ils vont des outils de construction d’interface au langage script pour animer les objets). Chacun a ses avantages et ses inconvénients. Encore une fois, il ne faut surtout pas entrer dans le code de l’application [1].
Figure 1 Source [2]
Itération du prototypage [1]
Une fois nos prototypes testés (Lo-Fi et Hi-Fi), il ne reste qu’à itérer. L’itération consiste à modifier nos prototypes puis à les tester de nouveau avec d’autres sujets. Pour les prototypes Lo-Fi, les itérations étant peu coûteuses, plus on fait d’itérations, plus on améliore le design. Lorsque la majorité des problèmes sont résolus, il est temps de passer à l’étape suivante, c’est-à-dire le prototype Hi-Fi ou l’implémentation des fonctionnalités.
Pour ce qui est des coûts, le bénéfice des prototypes est sans équivoque. Plusieurs études ont examiné la question, et il a été démontré que les économies de temps sont considérables : de l’ordre de 60 à 90 %.
De plus, une fois le produit distribué au public, les corrections du produit sont extrêmement coûteuses, car il faut recommencer toutes les étapes de tests (AQ), Lisez-moi, documentation, etc.
La technique du Magicien d’Oz [2]
Cette technique est utilisée durant les essais par les utilisateurs. La technique du Magicien d’Oz permet aux utilisateurs d’interagir avec une interface qu’ils croient autonome, mais qui est partiellement ou totalement contrôlée par un humain. L’utilisateur est placé dans une salle avec une interface vocale d’ordinateur. Dans une salle adjacente, une personne (appelée le magicien) crée une « voix » par traitement de texte qui est transformée en flux audio. Cette personne supplée aux lacunes du prototype et permet de simuler le futur système. Le « magicien » peut observer et interpréter les entrées de l’utilisateur en direct. Il peut contrôler le comportement du système. L’utilisateur a la sensation d’utiliser un vrai système. Néanmoins, cette technique est peu utilisée aujourd’hui en raison des logiciels de prototypage d’interface. Cette technique est par ailleurs difficile à mettre en place, car les systèmes sont lourds et difficiles à développer.
Figure 2 Source [2]
Exemple avec le projet DIALORS, un système de dialogue pour réserver un billet de train en langage naturel. Expérimentations réelles en 1984 : une opératrice simule les réponses du système. Voici l’une des constatations faites : face à la machine, les utilisateurs ont adopté – contrairement aux attentes des concepteurs – un langage haché.
Bibliographie :
- Bouchard, F. (2007) IFT515 – Interfaces et multimédia – note de cours, Sherbrooke, Québec, Canada.
- Colombi, T. (2011) Prototypage IHM – LudoTIC.