Conception et evaluation d’ IHM Pourquoi. Comment Conception et evaluation d’ IHM Pourquoi ? Comment ? Une sensibilisation à la problématique Anne-Marie Déry - pinna@polytech.unice.fr

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

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 …

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é

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

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

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

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é

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é

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

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

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

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 ?

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

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

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

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é

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

Un problème classique

Des architectures logicielles http://tel.archives-ouvertes.fr/docs/00/04/82/79/HTML/2_2modelesinterface_referen.html 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.

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).

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.

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

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.

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

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é).

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

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

Zoom : Architecture MVC •Smalltalk[Goldberg et Robson1979-1983] –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

Le contrôleur au centre de la communication

Plusieurs vues – 1 modèle

Exemple

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vous avez compris MVC ? Un exemple simple

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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ù ?

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

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….

+ Prise en compte de la localisation Situer sur un plan et fournir des informations Profiter d’un dispositif de sortie plus adapté

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 http://giove.isti.cnr.it/videos/8

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

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 ?

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

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

Vidéos Vidéos ScrapBooking et Echange de cartes de visite http://atelierihm.polytech.unice.fr

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

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 ?

Un peu d’historique : Plate-forme Magic Casque + Ecouteurs Stylos Tablette + Extenseur de port Réseau sans fils Capteur d’orientation Camera + Micro

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>

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

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

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é

Travaux de recherche Utilisation des techniques : Tilt Interaction for mobile Museum guide for Blind users http://giove.isti.cnr.it/videos/8 De nouvelles techniques de visualisation : http://iihm.imag.fr/demo/hcpmobile/ ATTENTION ! http://mail.google.com/mail/help/motion.html

Illustration par l’exemple MINI PROJET POLYTECH ANNEE 2005

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

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

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

Scénarios de l’existant Pré-tests des scénarios Évaluation du temps nécessaire à la passation Amélioration des scénarios

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

Modèles de tâches

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 …

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

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

Scénarios de la maquette Modèle de tache de la maquette de bas niveau Modèle de tache de l’existant

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

Videos : Migration continuité de services adaptation execution http://giove.isti.cnr.it/videos/8 http://www.usixml.eu/effective-ie-done/media http://atelierihm.polytech.unice.fr http://iihm.imag.fr/demo/ De quoi réfléchir : http://www.youtube.com/watch?v=vyUXEbe7Fxs