La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Conception et evaluation d IHM Pourquoi ? Comment ? Une sensibilisation à la problématique Anne-Marie Déry -

Présentations similaires


Présentation au sujet: "Conception et evaluation d IHM Pourquoi ? Comment ? Une sensibilisation à la problématique Anne-Marie Déry -"— Transcription de la présentation:

1 Conception et evaluation d IHM Pourquoi ? Comment ? Une sensibilisation à la problématique Anne-Marie Déry -

2 – Page 2 Quelques définitions CHM Communication Homme Machine Etude de la conception des systèmes informatiques contrôle aérien, centrale nucléaire : sécurité bureautique : productivité jeux : engagement Des utilisateurs IHM Interface Homme Machine (1970) contact utilisateur système = langage d'entrée + de sortie + gestion de l'interaction Interaction Homme Machine (1980) Discipline englobant la conception, l'évaluation et le développement de systèmes interactifs

3 – Page 3 IHM et la diversité des supports Des supports variés avec des capacités dinteraction Différentes : bornes – tables – vitrines – murs interactifs Taille des écrans – multi touch ou non – utilisateur experts ou non Environnement bruyant – sombre …

4 – Page 4 IHM et la diversité des supports Des supports variés avec des capacités dinteraction Différentes : des supports dédiés Utilisateurs experts – efficacité sécurité mobilité

5 MÊMES USAGES MÊMES SERVICES IHM et supports mobiles

6 – Page 6 IHM, utilisateurs et usages Complexification de la conception ergonomique et logicielle Continuité de service

7 – Page 7 Problématique actuelle Prendre en compte les avancées technologiques nouveaux supports matériels masse de données sur net et intranet nouveaux moyens d'interactions multimédia : son, images Prendre en compte la diversité des utilisateurs : des novices aux experts Assurer le succès de lutilisation des logiciels : les interfaces ? facilité d'utilisation même si le service offert est complexe voiture vs électroménager téléphone : nouvelle gamme

8 – Page 8 Les enjeux de la mutation De nouveaux problèmes à résoudre Prendre en compte le contexte dans l'interaction Perception/modélisation/adaptation Prendre en compte la mobilité Prendre en compte la continuité de service Des solutions à des problèmes anciens à revoir les techniques d'interaction : windows, icons, menus, pointing Caméras, doigts, gestes : quand ? Pourquoi ? Des problèmes classiques prennent une importance particulière concevoir pour plusieurs plates-formes assurer la sécurité et la confidentialité

9 – Page 9 Les enjeux de la mutation CONSTAT : Ingénierie au cas par cas insuffisante Technicité accrue Exigences utilisateurs croissantes Coûts de développement et de maintenance Cohérence ergonomique entre versions Objectif non avoué Augmenter fiabilité, efficacité, productivité

10 – Page 10 Comment y répondre ? Faciliter ladaptation des IHM Comprendre les techniques dinteraction : Module NMI Savoir développer : exemples continuité de services (avec prise en compte du contexte et de la collaboration) ET VERIFIER LUTILISABILITE de LInterface

11 – Page 11 Utilisabilité des interfaces Critères à mettre en œuvre : 1.Faciliter lapprentissage et lusage 2.Informer : donner des retours d'information rassurants, utiles et immédiats Des moyens 1.Concevoir les IHM La conception doit répondre aux besoins, connaissances et caractéristiques des utilisateurs 2.Evaluer les IHM Lévaluation doit permettre de vérifier la bonne adéquation entre ce qui est fourni et les attentes des utilisateurs 3. Prototyper Le prototypage doit valider des solutions logicielles adaptées

12 – Page 12 Utilisabilité des interfaces conception, évaluation, prototypage au cœur du cycle de vie des IHM

13 – Page 13 Démarche Appliquer le cycle de vie des IHM Identifier les rôles : Ergonome, Designer, Développeur, Déterminer les utilisateurs visés Identifier la complexité des applications Prise en compte du contexte (lieu, temps, environnement) Collaboration (en mobilité ou non, synchrone / asynchrone) Identifier les techniques dinteractions adaptées ou en présence En entrée, En sortie Mono ou multi modales ?

14 – Page 14 Rôles et Acteurs Utilisateurs - Ergonomes – Designers - Développeurs

15 ETAPES DE LEVALUATION ERGONOMIQUE : CONCEPTION EVALUATION PROTOTYPAGE ETAPES LOGICIELLES : MODELES DARCHITECTURE BOITES À OUTILS TESTS UNITAIRES Etapes du cycle de vie

16 Etapes Logicielles ZOOM SUR MODÈLES DARCHITECTURE LOGICIELLE

17 Organiser le code (rangement) Simplifier (diviser régner) Organiser le travail Modifier (une partie) Ré-utiliser Notions : modularité, évolutivité, flexibilité Architecture Logicielle et IHM : Pourquoi ?

18 Séparation possible –Code pour IHM –Code «Métier» Exemple –IHM différente pour une Gestion dun stock de chaussures ou de bibelots ? –Linux sous gnome ou kde, le système change-t-il ? Objectif : éviter de tout modifier si on change la partie fonctionnelle ou la partie IHM Architecture Logicielle et IHM : Pourquoi ?

19 – Page 19 Un problème classique

20 Des architectures logicielles Tous les modèles partent du principe : un système interactif comporte une partie interface et une partie application pure Cette dernière est souvent appelée noyau fonctionnel. Le noyau fonctionnel est considéré comme préexistant, et les modèles de systèmes interactifs décrivent essentiellement la partie interface, ainsi que ses relations avec les objets du domaine. Système interactif utilisateur Système interactif

21 Des architectures logicielles La plupart des modèles identifient au moins trois types d'éléments : un ``coté utilisateur' (présentations), un ``côté noyau fonctionnel' (interfaces du noyau fonctionnel, abstractions, modèles), et des éléments articulatoires (contrôleurs, adaptateurs). Système interactif utilisateur

22 Des architectures logicielles : modèles architecturaux Seeheim Premier modèle (groupe de travail à Seeheim en 1985) - destiné au traitement lexical des entrées et sorties dans les interfaces textuelles – a servi de base à beaucoup d'autres modèles. Retour sémantique direct utilisateur NF

23 Des architectures logicielles : modèles architecturaux Arch utilisateur Le modèle Arch [1992] composants et 3 types de données objets du domaine objets du domaine objets de présentation objets d'interaction

24 Arch utilisateur Composant d'interaction - ensemble des widgets (objets interactifs) + communications avec les périphériques physiques – Composant de présentation - représentation logique des widgets indépendante de la plate- forme. Contrôleur de dialogue - responsable du séquencement des tâches et du maintien de la consistance entre les vues multiples. Adaptateur du domaine - responsable des tâches dépendantes du domaine qui ne font pas partie du noyau fonctionnel mais qui sont nécessaires à sa manipulation par l'utilisateur. Noyau fonctionnel représente la partie non interactive de l'application. objets du domaine objets du domaine objets de présentation objets d'interaction

25 Modèles à agents utilisateur Le modèle MVC (Modèle, Vue, Contrôleur) Smalltalk [Goldberg and Robson, 1981].Goldberg and Robson, 1981 modifiabilité + conception itérative + compatibilité avec les langages à objets.

26 utilisateur les systèmes interactifs = une hiérarchie d'agents. Un agent MVC = un modèle, une ou plusieurs vues, et un ou plusieurs contrôleurs modèle = noyau fonctionnel de l'agent. (entier, chaîne de caractères ou objets) Le modèle notifie les vues à chaque fois que son état est modifié par le noyau ou par ses contrôleurs. La vue (constituée d'objets graphiques) maintient une représentation du modèle pour l'utilisateur, mise à jour à chaque notification d'état. Le contrôleur reçoit et interprète les événements utilisateur, les répercutant sur le modèle (modification de son état) ou sur la vue (retour instantané).

27 PAC utilisateur modèle à agents PAC (Présentation, Abstraction, Contrôle) [Coutaz, 1987] = hiérarchie d'agents.Coutaz, 1987 présentation = comportement en entrée et en sortie de l'agent pour l'utilisateur. Abstraction = la partie sémantique de l'agent. Contrôle = consistance entre la présentation et l'abstraction,. Abstraction : équivalent modèle de MVC, présentation : fusion des composants vue et contrôleur. Le composant contrôle n'a pas d'existence explicite dans le modèle MVC.

28 Modèles à agents PAC le modèle PAC peut être appliqué à plusieurs niveaux d'un système interactif. Une application interactive peut ainsi être décrite comme une hiérarchie d'agents disposés sur plusieurs couches d'abstractions PAC/Amodeus = Arch + Pac avec hiérarchie PAC dans le contrôleur

29 – Page 29 Zoom : Architecture MVC Smalltalk[Goldberg et Robson ] –Model : modélisation (données et comportement) –View: représentation manipulable de l'objet –Control : interprétation des entrées Séparer dans le code –les données (le Modèle), –La ou les Vues, –Le Contrôle V sabonne à M C sabonne à V C modifie M et V

30 – Page 30 Le contrôleur au centre de la communication

31 – Page 31 Plusieurs vues – 1 modèle

32 – Page 32 Exemple

33 Mise en garde La mise en œuvre de MVC dans une application nest pas une tâche aisée : Introduit un niveau de complexité assez élevée Implique une bonne conception dès le départ Peut prendre du temps au développement En faire gagner lors de lévolution de lapplication Conseillée pour les moyennes et grandes applications amenées à être maintenues, étendues et pérennes 33

34 Mise en place Exemple assez simple dune application qui permet de modifier un volume. Plusieurs vues pour représenter le volume et après toutes modifications, toutes les vues devront être synchronisées. Conseils : dans une grosse application, il est important de faire différents packages pour les différentes préoccupations 34

35 Le modèle : la base 35 public class VolumeModel { private int volume; public VolumeModel(){ super(); volume = 0; } public int getVolume() { return volume; } public void setVolume(int volume) { this.volume = volume; }

36 Pour la notification Pour permettre la notification de changement de volume, on utilise des listeners On crée donc un nouveau listener (VolumeListener) et un nouvel événement (VolumeChangeEvent) 36

37 Le listener et levent 37 import java.util.EventListener; public interface VolumeListener extends EventListener { public void volumeChanged(VolumeChangedEvent event); } import java.util.EventObject; public class VolumeChangedEvent extends EventObject{ private int newVolume; public VolumeChangedEvent(Object source, int newVolume){ super(source); this.newVolume = newVolume; } public int getNewVolume(){ return newVolume; }

38 Implémentation du système découteurs dans le modèle (1/2) 38 import javax.swing.event.EventListenerList; public class VolumeModel { private int volume; private EventListenerList listeners; public VolumeModel(){ this(0); } public VolumeModel(int volume){ super(); this.volume = volume; listeners = new EventListenerList(); } public int getVolume() { return volume; } public void setVolume(int volume) { this.volume = volume; fireVolumeChanged(); }

39 Implémentation du système découteurs dans le modèle (2/2) 39 public void addVolumeListener(VolumeListener listener){ listeners.add(VolumeListener.class, listener); } public void removeVolumeListener(VolumeListener l){ listeners.remove(VolumeListener.class, l); } public void fireVolumeChanged(){ VolumeListener[] listenerList = (VolumeListener[]) listeners.getListeners(VolumeListener.class); for(VolumeListener listener : listenerList){ listener.volumeChanged( new VolumeChangedEvent(this, getVolume())); }

40 Ce que lon a maintenant Le modèle est maintenant capable davertir tous ses écouteurs à chaque changement de volume En fonction de lapplication, il est possible dimaginer plusieurs listeners par modèles et dautres événements dans les listeners (par exemple quand le volume dépasse certains seuils) Remarque : le modèle peut devenir très vite conséquent 40

41 Pré-requis pour le contrôleur Pour éviter dêtre dépendant de Swing, on va créer une classe abstraite représentant une vue de volume 41 public abstract class VolumeView implements VolumeListener{ private VolumeController controller = null; public VolumeView(VolumeController controller){ super(); this.controller = controller; } public final VolumeController getController(){ return controller; } public abstract void display(); public abstract void close(); }

42 Le Contrôleur Manipulera des objets de type View et non plus de type Swing Un seul contrôleur sera créé dans un soucis de simplicité puisque les 3 vues font la même chose. Dans le cas de vues complètement différentes, il est fortement conseillé dutiliser plusieurs contrôleurs 42

43 Les vues Nous supposons 3 vues (dans le cadre du cours, nous nen montrerons qu une) : Une vue permettant de modifier le volume avec un champ de texte et valider par un bouton Une vue permettant de modifier le volume à laide dune jauge + bouton pour valider Une vue listant les différents volumes Toutes ces vues sont représentées par une JFrame 43

44 Contrôleur (1/2) 44 public class VolumeController { public VolumeView fieldView = null; public VolumeView spinnerView = null; public VolumeView listView = null; private VolumeModel model = null; public VolumeController (VolumeModel model){ this.model = model; fieldView = new JFrameFieldVolume(this, model.getVolume()); spinnerView = new JFrameSpinnerVolume(this, model.getVolume()); listView = new JFrameListVolume(this, model.getVolume()); addListenersToModel(); } private void addListenersToModel() { model.addVolumeListener(fieldView); model.addVolumeListener(spinnerView); model.addVolumeListener(listView); }

45 Contrôleur (2/2) 45 public void displayViews(){ fieldView.display(); spinnerView.display(); listView.display(); } public void closeViews(){ fieldView.close(); spinnerView.close(); listView.close(); } public void notifyVolumeChanged(int volume){ model.setVolume(volume); }

46 Les vues Nous allons faire 3 vues (dans le cadre du cours, nous nen montrerons qu une) : Une vue permettant de modifier le volume avec un champ de texte et valider par un bouton Une vue permettant de modifier le volume à laide dune jauge + bouton pour valider Une vue listant les différents volume Toutes ces vues sont représentées par une JFrame 46

47 JFrameField (1/3) 47 import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.text.NumberFormat; import javax.swing.*; import javax.swing.text.DefaultFormatter; public class JFrameFieldVolume extends VolumeView implements ActionListener{ private JFrame frame = null; private JPanel contentPane = null; private JFormattedTextField field = null; private JButton button = null; private NumberFormat format = null; public JFrameFieldVolume(VolumeController controller) { this(controller, 0); } public JFrameFieldVolume(VolumeController controller, int volume){ super(controller); buildFrame(volume); }

48 JFrameField (2/3) 48 private void buildFrame(int volume) { frame = new JFrame(); contentPane = new JPanel(); format = NumberFormat.getNumberInstance(); format.setParseIntegerOnly(true); format.setGroupingUsed(false); format.setMaximumFractionDigits(0); format.setMaximumIntegerDigits(3); field = new JFormattedTextField(format); field.setValue(volume); ((DefaultFormatter)field.getFormatter()).setAllowsInvalid(false); contentPane.add(field); button = new JButton("Mettre à jour"); button.addActionListener(this); contentPane.add(button); frame.setContentPane(contentPane); frame.setTitle("JFrameSpinnerVolume"); frame.pack(); }

49 JFrameField (3/3) public void close() { frame.dispose(); public void display() { frame.setVisible(true); } public void volumeChanged(VolumeChangedEvent event) { field.setValue(event.getNewVolume()); } public void actionPerformed(ActionEvent arg0) { getController().notifyVolumeChanged(Integer.parseInt(field.getValue().toString())); }

50 Vous avez compris MVC ? UN EXEMPLE SIMPLE

51 – Page 51 Lexemple du login 2 vues parmi dautres IHM en Anglais IHM en français

52 – Page 52 Un modèle 3 variables dinstances log, password, check Des méthodes logCheck passwordCheck connect

53 – Page 53 Cas dinteraction Cas no 1 le bouton Log in implique la vérification login et password à partir des données saisies. Les données peuvent être modifiées jusquau moment de lutilisation du bouton Action : connexion ou un message derreur

54 – Page 54 Cas dinteraction Cas no 2 le bouton Log in implique la vérification login password à partir des données saisies. Les données peuvent être modifiées jusquau moment de leur validation par un retour charriot Actions : connexion ou un message derreur Les champs de saisie sont bloqués après retour charriot

55 – Page 55 Cas dinteraction Cas no 3 : La saisie des données est validée au premier retour chariot Actions : vérification des données faite au fur et à mesure pour le login puis pour le password ce qui peut entrainer un message derreur connexion au moment par click sur le bouton

56 ETAPES DE LEVALUATION ERGONOMIQUE : CONCEPTION EVALUATION PROTOTYPAGE ETAPES LOGICIELLES : MODELES DARCHITECTURE BOITES À OUTILS TESTS UNITAIRES Etapes du cycle de vie

57 – Page 57 Conception : Modélisation de lutilisateur Objectifs identifier le(s) type(s) dutilisateurs en présence Identifier les besoins des utilisateurs Identifier leurs compétences et leurs habitudes Comment faire ? Technique des questionnaires Technique des entretiens Tri Focus Group

58 – Page 58 Conception : Formaliser Modélisation des utilisateurs Technique des Personas Modélisation des besoins utilisateurs Description des taches HTA, UAN, CTT

59 – Page 59 Prototypage Maquette basse fidélité Minimum de design pour se concentrer sur la navigation et les taches Maquettage papier à vos papiers et à vos ciseaux Fonctionnalités simulées Technique du magicien dOz Implémentation dun scénario

60 – Page 60 Evaluation Evaluation coopérative Évaluation centrée utilisateurs Evaluation heuristique Evaluation par analyse Grille Xerox

61 – Page 61 Prototypage V2 Mise en œuvre Charte graphique Graphisme / animation Fonctionnalités Architecture Logicielle

62 – Page 62 Dimensions de lespace problème Trois axes détude Techniques dinteraction Collaboration Contexte

63 – Page 63 Illustration Une définition Des exemples Scénari Vidéo

64 – Page 64 Dimensions de l espace problème prise en compte du Contexte Techniques dinteraction Collaboration Contexte

65 – Page 65 Une définition du terme contexte 3 axes pour mesurer un changement de contexte Lutilisateur (novice, avancé, handicapé,...) Le device (smart phone, grand écran, vocal, tactile…) Lenvironnement (luminosité, bruit, ….) En situation de mobilité le plus souvent Découverte de lenvironnement physique – reconnaissance de capteurs Adaptation de lapplication au nouveau contexte par rapport au besoin de lutilisateur Quelle situation ? Avec qui ? Avec quoi ? Où ?

66 – Page 66 Système interactif sensible au contexte capable didentifier les circonstances qui entourent laction utilisateur en vue doffrir des services contextualisés offre sélective dinformation décoration contextuelle pour recherche ultérieure Contexte : ensemble de propriétés de phénomènes physiques qui peuvent être captées

67 – Page 67 Identification des dispositifs dinteraction Le dispositif du dépanneur reconnait le matériel Le dépanneur peut accéder à la fiche technique et à la dsiponibilté des pièces….

68 – Page 68 + Prise en compte de la localisation Profiter dun dispositif de sortie plus adapté Situer sur un plan et fournir des informations

69 – Page 69 Travaux de recherche Migratory User Interface videos 1 et 2 1.Achat à distance dun mobile vers une télévision 2.Réservation de voyage Vidéo Multi device User Application : Home Applications

70 – Page 70 Dimensions de lespace problème Gestion du collaboratif Selon trois axes Techniques dinteraction Collaboration Contexte

71 – Page 71 Une définition du terme collaboration Une application collaborative : application qui permet datteindre un but à plusieurs Plusieurs utilisateurs travaillent ensemble pour réaliser une ou plusieurs taches. Quels utilisateurs ? Quand ? Comment ?

72 – Page 72 Collaboration et mobilité : découpage spatio-temporel Déplacement dans lespace Variation dans le temps : synchronisme/ asynchronisme local distant asynchrone synchrone

73 – Page 73 Mobilité : nouveau découpage spatial Etude selon les lieux dinteraction et non la distance CONFINE : lieu de linteraction délimité VAGABOND : lieu de linteraction nimporte où Localisée : Les participants sont ensemble Non localisée : Les participant sont dispersés

74 – Page 74 Vidéos Vidéos ScrapBooking et Echange de cartes de visite

75 – Page 75 Dimensions de l espace problème Prise en compte et mise en place de techniques dinteraction Techniques dinteraction Collaboration Contexte

76 – Page 76 Une définition du terme technique dinteraction Une technique dinteraction Une technique qui permet de récupérer les données via un dispositif dentrée auprès dun utilisateur pour les transmettre à une application et de fournir des résultats à un utilisateur via un dispositif de sortie Quel type de dispositif ? Pour quel utilisateur ? Pour quel usage ?

77 – Page 77 Un peu dhistorique : Plate-forme Magic Camera + Micro Casque + Ecouteurs Capteur dorientation Stylos Tablette + Extenseur de port Réseau sans fils

78 – Page 78 Expérience Interface « Baby face » : multimodalité Technique = Go to the middle of the message T =

79 – Page 79 Interface « Baby face » Technique du magicien dOz Magicien d oz CompèreSujet observé

80 – Page 80 Interface « Baby face » : analyse des résultats Usage des modalités par les sujets Toutes commandes / Toutes sessions Vocale Tactile Gestuelle Embodied

81 – Page 81 Interface « Baby face » conclusion ? Usage des techniques d interaction par les sujets Variabilité inter-individuelle importante dans l usage (fréquence, préférences variées) Spécialisation Peu de redondance et de complémentarité

82 – Page 82 Travaux de recherche Utilisation des techniques : Tilt Interaction for mobile Museum guide for Blind users De nouvelles techniques de visualisation : ATTENTION !

83 MINI PROJET POLYTECH ANNEE 2005 Illustration par lexemple

84 – Page 84 Mosaïques de télévision Analyse des mosaïques de télévision (CanalSat ou Free) peu intuitives mal conçues Objectif : construire un système de navigation plus intuitif. Public visé : Adolescents & adultes

85 – Page 85 POINT FORT Evaluation coopérative de lexistant et du prototype final Définition des scénari Maquette basse résolution Utilisation adaptée du modèle de taches

86 – Page 86 Scénarios de lexistant Conception des scénarios Scénarios conçus en fonction des problèmes soulevés par les utilisateurs lors de la passation du questionnaire Conception de 5 scénarios accès à une chaîne par son nom accès à une chaîne par son numéro modification du volume sonore accès à une chaîne par son thème navigation au sein des écrans de la mosaïque

87 – Page 87 Scénarios de lexistant Pré-tests des scénarios Évaluation du temps nécessaire à la passation Amélioration des scénarios

88 – Page 88 Scénarios de lexistant Tests des scénarios Enregistrement vidéo et papier des réponses Types dutilisateurs : experts et novices Nombre de participant : 5 Types de mosaïques : CanalSat et Freebox

89 – Page 89 Modèles de tâches

90 – Page 90 Bilan des scénarios Résultats des tests utilisateurs Utilisateurs insatisfaits Principales raisons : Mosaïque = chaîne 1 (a changé en janvier : chaîne 8 …) Manque dinformation sur les programmes en cours Difficile de distinguer les chaînes payantes des gratuites …

91 – Page 91 Proposition damélioration Réalisation dun maquette de bas niveau Conçue en fonction des besoins des utilisateurs

92 – Page 92

93 – Page 93 Scénarios de la maquette Conception de nouveaux scénarios à partir de la maquette de bas niveau En réadaptant les scénarios précédents Mise en place de 6 scénarios Navigation au sein des écrans de la mosaïque Accès à une chaîne par son thème Accès aux films prochainement diffusés Accès à une chaîne par le nom de la chaîne Ajout de chaînes dans la catégorie « mes favoris » Achat d'une chaîne

94 – Page 94 Scénarios de la maquette Modèle de tache de lexistant Modèle de tache de la maquette de bas niveau

95 – Page 95 Ce cours ne serait pas ce quil est sans … Mes collègues chercheurs en IHM, la richesse de nos discussions et de leurs sites web Mes anciens étudiants, leurs retours instantanés et leurs mini projets Mes contacts industriels avec les collaborations recherche et les encadrements communs détudiants du parcours

96 – Page 96 Videos : Migration continuité de services adaptation execution De quoi réfléchir :


Télécharger ppt "Conception et evaluation d IHM Pourquoi ? Comment ? Une sensibilisation à la problématique Anne-Marie Déry -"

Présentations similaires


Annonces Google