Embed Size (px)
Citation preview
Prototypage
Sortes de prototypes• Servent à la conception, et au tests avec les
utilisateurs• Sortes de prototypes:
– Prototype statique / dynamique– Prototype de haute fidelité / basse fidelité– Prototype horizontal / vertical
Système complet
Prototype vertical
Prototype horizontal
Prototypes en papier• Basse fidelité• Vites à faire et à modifier• Peuvent utiliser le papier, les transparences,
les collants (“post-its”), les cartes en carton, les ciseux, ruban gommé, crayons, stylos, ...
Le bureau d’un concepteur
Studio de design IDEO (pris de l’article de Guimbretière, Stone, Winograd, UIST 2001)
Exemples …• can create pre-made interface components on paper• eg, these empty widgets were created in visual basic and printed out:
buttons menu alert box
combo box
tabs
entries
list box
Des outils flottants ou optionnels ...
Storyboarding• a series of key frames
– originally from film; used to get the idea of a scene– snapshots of the interface at particular points in the
interaction
Example frame from a movie Storyboard
Storyboard of a computer based telephone
Computer Telephone Last Name: First Name: Phone:
Place Call Help
Help->
Computer Telephone
Last Name: Greenberg First Name: Phone:
Place Call Help
Dialling....
Cancel
Call connected...
Computer Telephone
Last Name: Greenberg First Name: Phone:
Place Call Help
Connected
Hang up
Call completed...
Return
Help Screen You can enter either the person's name or their number. Then hit the place button to call them
Call by name->
Computer Telephone
Last Name: Greenberg First Name: Phone:
Place Call Help
Establishing connection->
Prototypage en papier• Avantages:
– “Un maximum de feedback pour un minimum d’effort” (Snyder)
– Vites à faire et à modifier– Ne demande pas d’expertise– Aspect informel encourage la créativité– Ne donne pas l’impression au client que l’interface est presque finie– Évitent que les concepteurs soient attachés à la conception et qu’ils
hésitent de la changer– Évitent que les utilisateurs hésitent de suggérer des gros changements– Permettent les utilisateurs à participer dans la conception
• Exemples: PICTIVE (“Plastic Interface for Collaborative Technology Initiative through Video Exploration”, Muller 1992), une technique de conception participatoire (“participatory design”)
Exercise en classe !• (distribuer les descriptions des exercises)• Pourquoi garder des détails secrets de votre
participant eventuel ?• Dessiner vos …
– Fenêtres– Dialogues– Menus– Curseur(s)– Messages d’erreur– Images “vidéo”
• N.B.: pas un “storyboard”, mais plutôt montrer l’écran de départ et ensuite montrer la réaction aux entrées du participant
Exercise en classe ! (suite)• Tester avec un utilisateur• Rappelez à votre participant de penser à haute voix (la
technique “think aloud”)• Montrer ce qui arrive en réponse aux actions du
participant• Expliquer le moins possible ce qui arrive ou pourquoi, à
moins que le participant soit bloqué ou complètement “dans le champ”
• Prenez en note les problèmes rencontrés par l’utilisateur (exemples: erreurs, sources de confusion)
• À la fin de la session, échangez des commentaires et des suggestions librement
Exercise en classe ! (suite)
• Avez-vous observé beaucoup de problèmes ?– Plus de problèmes que vous aurez pensé au
départ ?• Est-ce que vos deux participants ont eux des
problèmes différents ?– Donc, vaudrait-t-il la peine de tester avec encore
plus d’utilisateurs ?• Si vous aviez à refaire cet exercise, qu’est-ce
que vous auriez fait différemment ?
D’autres techniques de prototypage• Pages web (HTML) statiques• Images
– Visio– Adobe PhotoShop, GIMP, Adobe Illustrator, Paint.NET
(permettent de travailler avec des couches (“layers”))• (Démonstration de GIMP)
• Outils de présentation– Director
• Du code exécutable, sans fonctionalité– VisualBasic, Java, C++ (Qt), etc.– Il existe des outils glisser-déposer pour créer une interface graphique
avec des widgets standards (Exemple: NetBeans pour le Java)
• Questions: lesquels de ces techniques sont statiques / dynamiques, basse / haute fidelité, horizontal / vertical ?
Le « napkin look-and-feel »• http://napkinlaf.sourceforge.net/
D’autres techniques de prototypage (suite)
• Le prototypage par la technique du “Magicien d’Oz”(“Wizard-of-Oz”)– Exemple: simulation de reconnaissance de la voix parfaite
• Le prototypage par vidéos– Utiles pour montrer une vision– Exemples (montrer les vidéos):
• KnowledgeNavigator de Apple– Questions: haute ou basse fidelité? Horizontal ou vertical?
• Interfaces pour écrans volumiques• Wearable interface: « 6th sense »• Nokia Morph• Microsoft 2019
Systèmes de prototypage expérimentaux
• SILK (Sketching Interfaces Like Krazy)Landay et Myers 2001
Systèmes de prototypage expérimentaux (suite)
• DENIM (http://dub.washington.edu/denim/)– Montrer la vidéo
AppSeedhttp://www.kickstarter.com/projects/appseed/appseed-turn-sketches-into-functioning-prototypes http://www.wired.com/design/2013/09/appseed-transforms-your-sketches-into-app-prototypes/
Prototypage physique• Pour les interfaces matérielles• Exemple: Les phidgets – “physical widgets”
www.phidgets.com / Greenberg et Fitchett 2001(montrer la vidéo)
Exemple Phidget: Un capteur “RFID”+ téléphone cellulaire
Exemple Phidget:Jeu d’exercise avec Tetris et des poids
Prototypage physique (suite)• Exemple:
BUG (buglabs.net)
Quels sont les avantages de prototyper plusieurs alternatives en
parallèle ?• Permet d’explorer plus de possibilités et peut-
être d’en combiner• Permet d’éliminer une mauvaise idée de
départ• Séparation de notre égo des idées conçues –
on accepte mieux les critiques• Encourage la comparaison de différentes
possibilités
Exemple de SIGA(logiciel pour accéder aux comptes
financiers)
Fenêtre impossible à redimensionner. De plus, le scrollbar vertical fait un rafraîchissement seulement au relâchement.(Et, encore pire, anciennement, la colonne “solde” était complètement à l’extrémité droite.)
Pourquoi ai-je besoin de saisir une intervalle de temps et lancer une requête ? Par défaut je devrais voir toutes les activités récentes.
Ce n’est pas évident de savoir quel bouton appuyer.
Que veut dire “Réel” ? Ah, ça veut dire “dépenses à date”. Pourtant, il y a suffisamment d’espace pour afficher une déscription explicite.
Les 6 premières colonnes me sont inutiles. Je dois perdre du temps à scroller.
Rendu ici, j’ai compris que “paie” veut dire “bourse”. Cela m’a pris 14 clics pour savoir à quel étudiant j’ai donné cette bourse. Impossible de savoir le montant total donné à cet étudiant (sur plusieurs bourses) à date sans ouvrir chaque paiement un-par-un et faire la somme moi-même.
Les 4-5 premières colonnes me sont inutiles. Je dois perdre du temps à scroller.
L’onglet “Référence interne” est vide; pourquoi alors le montrer par défaut ?L’onglet “Ventilation” semble prometteur …
Chiffres qui ne veulent rien dire pour moi. Comment comprendre la raison derrière chacun des montants? Les loupes à côté de chaque montant sont grisées. J’essaie alors les loupes à droite.
Aucune information supplémentaire. Pourquoi alors m’offrir la loupe ?
Le système que nous venons de voir a été développé post-2005, et a coûté des dizaines (centaines?) de milliers de dollars à l’Université du Québec, et a été déployé à l’interne avec de cours pour former les employés. Pourtant, il m’est tellement inutilisable, que je m’en sers uniquement pour voir le solde actuel dans chacun de mes comptes de recherche. Sur mon laptop, je garde en local un fichier privé qui contient une liste de mes dépenses et des bourses que j’ai émises, en ordre chronologique inverse (comme un relevé bancaire), regroupées par compte de recherche. Je garde ce fichier à jour de façon réligieuse, et je serais perdu sans ce fichier. Et je sais que je ne suis pas le seul employé à utiliser un tel “système parallèle” pour me retrouver.
Certains employés ont même rebaptiser le logiciel “SIGA” avec le nom semblable d’une maladie contagieuse …
L’interface utilisateur pour SIGA a peut-être été généré par un système de base de données (peut-être Oracle Forms?). Cela donne une interface centrée sur le modèle de données. En théorie, une telle interface permet de voir toutes les données, mais n’est peut-être pas du tout optimisée pour les tâches typiques des utilisateurs.
Une deuxième approche partirait des tâches des utilisateurs. Prenons, par exemple, juste les tâches d’un seul intervenant: moi-même (un professeur). Mes tâches sont:- Voir une vue d’ensemble de mes comptes, pour voir le solde de chacun (pour m’aider à planifier des dépenses et des bourses)- Voir l’historique des dépenses+bourses venant d’un compte- Voir une vue d’ensemble de mes étudiants, avec peut-être le total des bourses qu’ils ont eu de moi à date, et peut-être la date et le montant de leur prochaine bourse de moi- Voir, pour un de mes étudants en particulier, l’historique des bourses qu’il/qu’elle a reçues de moi- Faire un transfert d’un montant d’un compte vers un autre- Donner une bourse à un étudiant (notez: la bourse peut venir de plusieurs comptes en même temps)
Cette deuxième approche, centrée sur les tâches, pourrait proposer une interface avec un menu principal qui permet de choisir la tâche:
Vue d’ensemble des comptes …
Historique d’un compte …
Vue d’ensemble des étudiants …
Historique d’un(e) étudiant(e) …
Transfert entre comptes …
Donner une bourse …
On aurait alors une “fenêtre” ou un “wizard” pour chaque tâche, montrant seulement les informations nécessaires pour chaque tâche. Malheureusement, cela empêche à l’utilisateur de voir facilement une vue d’ensemble des données. De plus, seulement les tâches simplistes seront permises, et l’utilisateur pourra avoir de la difficulté à changer de tâche ou d’idée en cours de route. De plus, les mêmes informations peuvent être affichées dans plusieurs fenêtres, rendant le modèle conceptuel plus compliqué et difficile.
Une troisième approche propose de partir d’une liste des tâches, mais de concevoir des fenêtres autour des informations nécessaires pour une ou plusieurs tâches. On peut distinguer entre 3 étapes de conception dans cette approche:-Le “information design” : décider quelles informations seront affichées, et où-Le “interaction design” : décider quels seront les widgets, menus, boutons, etc. permettant de lancer les fonctionnalitées nécessaires dans chaque fenêtre-Le “graphic design” : décider des couleurs, polices, style visuel
L’approche des “fenêtres virtuelles” de Lauesen et Harning (2001) est une manière (parmi d’autres) de prendre cette 3e approche, et de faire le “information design” avant le “interaction design”.
La méthode des fenêtres virtuelles(Lauesen et Harning 2001)
LOG350 A2006 Analyse, vision et domaine 71
Fenêtres virtuelles Introduction
• Lauesen propose de concevoir l'interface utilisateurs en deux étapes– Concevoir des fenêtres virtuelles, montrant les données,
en fonction des tâches• Correspond à la conception d’information (« information
design »): on s’occupe de l’information qui sera présentée à l’utilisateur, et non de la façon d’interagir avec
• On ne met pas de boutons, menus, etc. dans ces fenêtres
– Ajouter les fonctionnalités (widgets) par la suite
LOG350 A2006 Analyse, vision et domaine 72
Fenêtres virtuelles Processus de construction des fenêtres
1. Partir des tâches les plus fréquentes et les plus importantes
2. Regrouper les données dans quelques fenêtres virtuelles
3. Continuer les étapes 1 et 2 pour d'autres tâches
4. Si les données sont dans une fenêtre déjà existante, essayer d'accomplir cette tâche avec la même fenêtre
5. Si des données manquent à une fenêtre, augmenter celle-ci, si possible
LOG350 A2006 Analyse, vision et domaine 73
Fenêtres virtuelles Règles de construction• Utiliser le moins de modèles de fenêtre possible• Utiliser le moins d'instances de fenêtre possible pour une tâche
– Surtout pour les tâches importantes/fréquentes– Évitez les séquences étape-par-étape extrèmes
(exemple: les « Wizard »)• Essayer d’avoir chaque donnée affichée dans une seule fenêtre,
surtout quand les données seront modifiables– Sinon, ça peut nuire à la formation d’un bon modèle conceptuel
• Les fenêtres virtuelles peuvent être plus petites que la taille réelle de l'écran
– Plus tard, elles pourront être combinées
LOG350 A2006 Analyse, vision et domaine 74
Fenêtres virtuelles Règles (suite)
• Une vue d'ensemble aide énormément l'utilisateur:– à savoir où il est rendu– à réduire le nombre d'étapes de navigation– à prendre plus rapidement une décision
… donc, essayer de donner des vues d’ensembles des données dans vos fenêtres!
LOG350 A2006 Analyse, vision et domaine 75
Fenêtres virtuelles Règles (suite)
• Baser les fenêtres sur des objets, pas sur des actions. Commencer par nommer les fenêtres par des noms d'objets plutôt que des nom de fonctions– "chambre", "dossier client", "profile"– pas: "entrer une réservation de chambre", "consulter un
dossier client"
• Une tâche peut correspondre à plusieurs fenêtres virtuelles, et une fenêtre virtuelle peut permettre plusieurs opérations de base
LOG350 A2006 Analyse, vision et domaine 76
Conception des fonctionnalités (widgets, interactions)
• On repart avec chaque tâche, en ordre d'importance– On identifie des « boutons » (peut-être, en fait, des
commandes de menu) pour les différentes opérations (traitement) à effectuer
• recherche, création, ajout, sauvegarde, efface, calcul, envoie, …
– Les actions plus importantes / fréquentes, et moins dangeureuses (!) -> des boutons plus faciles à accéder
LOG350 A2006 Analyse, vision et domaine 77
D'écrans virtuels à Réels Passage au réel
• On procède à l'assemblage fenêtres virtuelles en écrans réels
• On peut regrouper plusieurs fenêtres dans un seul écran, gardant des séparations visuelles (encadrement, couleurs, distance, …)– Regrouper les fenêtres virtuelles d'une même tâche– Regrouper les fenêtres virtuelles séquentielles – Optimiser les transitions/navigations
Revenons à l’exemple de SIGA et mes 6 tâches:- Voir vue d’ensemble des comptes- Voir historique d'un compte- Voir vue d'ensemble des étudiants- Voir historique d'un(e) étudiant(e)- Transférer entre deux comptes- Donner une bourse
Et les données qu’on pourrait montrer:
Liste de comptes
Historiqued’un compte
Liste d’étudiant(e)s
Historiqued’un(e) étudiant(e)
Et notons les données nécessaires pour chaque tâche:- Voir vue d’ensemble des comptes- Voir historique d'un compte- Voir vue d'ensemble des étudiants- Voir historique d'un(e) étudiant(e)- Transférer entre deux comptes- Donner une bourse
Liste de comptes
Historiqued’un compte
Liste d’étudiant(e)s
Historiqued’un(e) étudiant(e)
Et notons les données nécessaires pour chaque tâche:- Voir vue d’ensemble des comptes- Voir historique d'un compte- Voir vue d'ensemble des étudiants- Voir historique d'un(e) étudiant(e)- Transférer entre deux comptes- Donner une bourse
Liste de comptes
Historiqued’un compte
Liste d’étudiant(e)s
Historiqued’un(e) étudiant(e)
Et notons les données nécessaires pour chaque tâche:- Voir vue d’ensemble des comptes- Voir historique d'un compte- Voir vue d'ensemble des étudiants- Voir historique d'un(e) étudiant(e)- Transférer entre deux comptes- Donner une bourse
Liste de comptes
Historiqued’un compte
Liste d’étudiant(e)s
Historiqued’un(e) étudiant(e)
Et notons les données nécessaires pour chaque tâche:- Voir vue d’ensemble des comptes- Voir historique d'un compte- Voir vue d'ensemble des étudiants- Voir historique d'un(e) étudiant(e)- Transférer entre deux comptes- Donner une bourse
Liste de comptes
Historiqued’un compte
Liste d’étudiant(e)s
Historiqued’un(e) étudiant(e)
Et notons les données nécessaires pour chaque tâche:- Voir vue d’ensemble des comptes- Voir historique d'un compte- Voir vue d'ensemble des étudiants- Voir historique d'un(e) étudiant(e)- Transférer entre deux comptes- Donner une bourse
Liste de comptes
Historiqued’un compte
Liste d’étudiant(e)s
Historiqued’un(e) étudiant(e)
Comment alors décider des fenêtres réelles ?
Une solution, permettant de réduire le nombre de fenêtres, serait de fusionner les informations concernant les comptes en une fenêtre, et les informations concernant les étudiants en une autre fenêtre. Ceci réduit le nombre de modèles de fenêtres. De plus, pour naviguer vers un historique de compte (ou un historique d’étudiant), l’utilisateur peut se servir de la liste de comptes (ou d’étudiants) comme point d’entré.
Liste de comptes
Historiqued’un compte
Liste d’étudiant(e)s
Historiqued’un(e) étudiant(e)
Seul problème restant: comment permettre facilement d’effectuer la dernière tâche, de donner une bourse? (N’oubliez pas qu’une bourse peut impliquer plusieurs comptes.)Solutions possibles:-Demander à l’utilisateur de passer à travers les deux fenêtres ci-dessous, en un mode spécial ?-À partir d’un étudiant dans la deuxième fenêtre, cliquer sur un bouton ou un lien “Donner une bourse” qui nous amène vers une troisième fenêtre ?
Liste de comptes
Historiqued’un compte
Liste d’étudiant(e)s
Historiqued’un(e) étudiant(e)
Comparons à un site bancaire:
- Une page donnant une vue d’ensemble des comptes, avec une section (en haut à droite) pour les transferts (remarquez aussi le menu déroulant contenant les soldes de chaque compte!)
- Des liens amenant vers l’historique de chaque compte
Remarques
• L’exemple précédent est simpliste, car il y a seulement un intervenant, quelques tâches simples, et nous n’avons pas analysé la fréquence des tâche.
Observation
• Si on avait à reconcevoir SIGA, les comptes bancaires et les relevés bancaires seraient de bons métaphores à utiliser
• Malheureusement, actuellement, un relevé historique dans SIGA n’est pas possible, et même le mot “compte” n’a pas le sens attendu
• Pour un autre exemple de conception avec des “fenêtres virtuelles”, voir l’article de Lauesen et Harning (2001) (http://uregina.ca/~sarsharn/ENSE471/VW.pdf , http://dx.doi.org/10.1109/MS.2001.936220 ) qui prend l’exemple d’un logiciel de réservations hôtelier
Points à retenir• Il n’y a pas de solution unique• Il y a parfois des compromis à faire (minimiser le nombre de
modèles de fenêtres versus minimiser le nombre d’étapes dans chaque tâche) et dans certains cas la justification d’un choix de conception peut sembler ad hoc
• Le plus important est d’essayer de commencer par le “information design”: concevoir les fenêtres autour des l’informations qu’elles vont afficher, et seulement plus tard rajouter les boutons, menus, widgets, etc. Éviter l’approche “wizard” avec des fenêtres servant à seulement une tâche, à moins que ça soit pour une tâche compliquée et/ou rarement effectuée (exemple: guichet bancaire; configuration compliquée) où on veut maximiser la facilité.
• Cette approche ne s’applique pas à toutes les interfaces (exemples: jeux, joueurs de médias, logiciels de création de dessins, …)
Question
• Est-ce que l’approche “information design” / “fenêtres virtuelles” vous aurait aidé dans votre exercise de conception papier de tantôt ?
