Conception et evaluation d’ IHM Pourquoi. Comment

Présentation au sujet: "Conception et evaluation d’ IHM Pourquoi. Comment"— Transcription de la présentation:

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

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 IHM et la diversité des supports
Des supports variés avec des capacités d’interaction Différentes : bornes – tables – vitrines – murs interactifs Taille des écrans – multi touch ou non – utilisateur experts ou non Environnement bruyant – sombre …

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

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

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

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 l’utilisation 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 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 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 Comment y répondre ? Faciliter l’adaptation des IHM
Comprendre les techniques d’interaction : Module NMI Savoir développer : exemples continuité de services (avec prise en compte du contexte et de la collaboration) ET VERIFIER L’UTILISABILITE de L’Interface

11 Utilisabilité des interfaces
Critères à mettre en œuvre : Faciliter l’apprentissage et l’usage Informer : donner des retours d'information rassurants, utiles et immédiats Des moyens Concevoir les IHM La conception doit répondre aux besoins, connaissances et caractéristiques des utilisateurs 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 Utilisabilité des interfaces
conception, évaluation, prototypage au cœur du cycle de vie des IHM

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 d’interactions adaptées ou en présence En entrée, En sortie Mono ou multi modales ?

14 Rôles et Acteurs Utilisateurs - Ergonomes – Designers - Développeurs
y s e d b o i C c p t g T U r ’ é u Evaluation ergonomique Boîtes à outils Mécanismes généraux Modèle d’architecture logicielle Espace de conception Propriétés ergonomiques

15 Etapes de l’evaluation ergonomique : Modeles d’architecture
Etapes du cycle de vie Etapes de l’evaluation ergonomique : Conception Evaluation Prototypage ETAPES Logicielles : Modeles d’architecture Boites à outils Tests unitaires

16 Zoom sur Modèles d’Architecture Logicielle
Etapes Logicielles Zoom sur Modèles d’Architecture Logicielle

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

18 Architecture Logicielle et IHM : Pourquoi ?
Séparation possible –Code pour IHM –Code «Métier» •Exemple –IHM différente pour une Gestion d’un 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

19 Un problème classique

20 Des architectures logicielles
utilisateur Système interactif Système interactif 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.

21 Des architectures logicielles
Système interactif utilisateur 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).

22 Des architectures logicielles : modèles architecturaux
Retour sémantique direct Seeheim utilisateur NF 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.

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

24 objets de présentation objets du domaine objets d'interaction objets du domaine 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.

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

26 les systèmes interactifs = une hiérarchie d'agents.
utilisateur 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 PAC modèle à agents PAC (Présentation, Abstraction, Contrôle) [Coutaz, 1987] = hiérarchie d'agents. 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. PAC

28 Modèles à agents PAC/Amodeus = Arch + Pac avec hiérarchie PAC dans le contrôleur PAC 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

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 s’abonne à M •C s’abonne à V •C modifie M et V

30 Le contrôleur au centre de la communication

31 Plusieurs vues – 1 modèle

32 Exemple

33 Mise en garde La mise en œuvre de MVC dans une application n’est 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 l’application Conseillée pour les moyennes et grandes applications amenées à être maintenues, étendues et pérennes 33

34 Mise en place Exemple assez simple d’une 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 public class VolumeModel { private int volume;
public VolumeModel(){ super(); volume = 0; } public int getVolume() { return volume; public void setVolume(int volume) { this.volume = volume; 35

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 l’event 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; 37

38 Implémentation du système d’écouteurs dans le modèle (1/2)
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(); } 38

39 Implémentation du système d’écouteurs dans le modèle (2/2)
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())); 39

40 Ce que l’on a maintenant
Le modèle est maintenant capable d’avertir tous ses écouteurs à chaque changement de volume En fonction de l’application, il est possible d’imaginer plusieurs listeners par modèles et d’autres é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 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(); 41

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é d’utiliser plusieurs contrôleurs 42

43 Les vues Nous supposons 3 vues (dans le cadre du cours, nous n’en 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 à l’aide d’une 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) 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); 44

45 Contrôleur (2/2) 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); 45

46 Les vues Nous allons faire 3 vues (dans le cadre du cours, nous n’en 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 à l’aide d’une 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) 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); 47

48 JFrameField (2/3) frame = new JFrame(); contentPane = new JPanel();
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(); } 48

49 JFrameField (3/3) public void close() { frame.dispose(); }
@Override 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())); 49

50 Vous avez compris MVC ? Un exemple simple

51 2 vues parmi d’autres L’exemple du login IHM en Anglais
IHM en français

52 Un modèle 3 variables d’instances Des méthodes log, password, check
logCheck passwordCheck connect

53 Cas d’interaction 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 jusqu’au moment de l’utilisation du bouton Action : connexion ou un message d’erreur

54 Cas d’interaction 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 jusqu’au moment de leur validation par un retour charriot Actions : connexion ou un message d’erreur Les champs de saisie sont bloqués après retour charriot

55 Cas d’interaction 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 d’erreur connexion au moment par click sur le bouton

56 Etapes de l’evaluation ergonomique : Modeles d’architecture
Etapes du cycle de vie Etapes de l’evaluation ergonomique : Conception Evaluation Prototypage ETAPES Logicielles : Modeles d’architecture Boites à outils Tests unitaires

57 Conception : Modélisation de l’utilisateur
Objectifs identifier le(s) type(s) d’utilisateurs 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 Conception : Formaliser
Modélisation des utilisateurs Technique des Personas Modélisation des besoins utilisateurs Description des taches HTA, UAN, CTT

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 d’Oz Implémentation d’un scénario

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

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

62 Dimensions de l’espace problème
Trois axes d’étude Techniques d’interaction Collaboration Contexte

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

64 Dimensions de l ’espace problème prise en compte du Contexte
Techniques d’interaction Collaboration Contexte

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

66 Système interactif sensible au contexte
capable d’identifier les circonstances qui entourent l’action utilisateur en vue d’offrir des services contextualisés offre sélective d’information décoration contextuelle pour recherche ultérieure Contexte : ensemble de propriétés de phénomènes physiques qui peuvent être captées

67 Identification des dispositifs d’interaction
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 + Prise en compte de la localisation
Situer sur un plan et fournir des informations Profiter d’un dispositif de sortie plus adapté

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

70 Dimensions de l’espace problème Gestion du collaboratif
Selon trois axes Techniques d’interaction Collaboration Contexte

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

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

73 Mobilité : nouveau découpage spatial
Etude selon les lieux d’interaction et non la distance CONFINE : lieu de l’interaction délimité VAGABOND : lieu de l’interaction n’importe où Localisée : Les participants sont ensemble Non localisée : Les participant sont dispersés

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

75 Dimensions de l ’espace problème Prise en compte et mise en place de techniques d’interaction
Collaboration Contexte

76 Une définition du terme technique d’interaction
Une technique d’interaction Une technique qui permet de récupérer les données via un dispositif d’entrée auprès d’un 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 Un peu d’historique : Plate-forme Magic
Casque + Ecouteurs Stylos Tablette + Extenseur de port Réseau sans fils Capteur d’orientation Camera + Micro

78 Expérience Interface « Baby face » : multimodalité
Go to the middle of the message Technique = <d, s> T = <caméra-doigt, gestes> T = <micro, pseudo LN> T = <ordinateur, gestes> T = <stylet, manipulation directe>

79 Interface « Baby face » Technique du magicien d’Oz
Compère Sujet observé

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

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 Travaux de recherche Utilisation des techniques : Tilt Interaction for mobile Museum guide for Blind users De nouvelles techniques de visualisation : ATTENTION !

83 Illustration par l’exemple
MINI PROJET POLYTECH ANNEE 2005

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 POINT FORT Evaluation coopérative de l’existant et du prototype final
Définition des scénari Maquette basse résolution Utilisation adaptée du modèle de taches

86 Scénarios de l’existant
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 Scénarios de l’existant
Pré-tests des scénarios Évaluation du temps nécessaire à la passation Amélioration des scénarios

88 Scénarios de l’existant
Tests des scénarios Enregistrement vidéo et papier des réponses Types d’utilisateurs : experts et novices Nombre de participant : 5 Types de mosaïques : CanalSat et Freebox

89 Modèles de tâches

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 d’information sur les programmes en cours Difficile de distinguer les chaînes payantes des gratuites …

91 Proposition d’amélioration
Réalisation d’un maquette de bas niveau Conçue en fonction des besoins des utilisateurs

92

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 Scénarios de la maquette
Modèle de tache de la maquette de bas niveau Modèle de tache de l’existant

95 Ce cours ne serait pas ce qu’il 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 Videos : Migration continuité de services adaptation execution De quoi réfléchir :