Conception et Architecture d’ IHM : Introduction Anne-Marie Déry pinna@essi.fr Merci tout particulièrement à Laurence Nigay, Gaelle Calvary de l’IMAG et au GT Mobilité et Ubiquité
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
Problématique actuelle Prendre en compte les avancées technologiques nouveaux supports matériels arrivée du net (masse de données + réseaux) nouveaux moyens d'interactions multimédia : son, images de plus en plus d'utilisateurs des novices aux experts Succès des interfaces ? facilité d'utilisation même si le service offert est complexe voiture vs électroménager téléphone : nouvelle gamme
Utilisabilité des interfaces Facile à apprendre et à utiliser Retour d'information rassurant, informatif et immédiat La conception doit répondre aux besoins, connaissances et Caractéristiques des utilisateurs Objectif avoué : fiabilité, efficacité, productivité 3 aspects étudiés à travers le module conception, évaluation, prototypage
Objectifs du module ETAPE 1 (décembre) Etude de marché et/ou réalisation de logiciels à la demande (constructeurs d’applications) Fournir un prototype adapté aux besoins clients Evaluer le coût de réalisation du produit final Mettre l’accent sur l’IHM pour le dialogue ETAPE 2 (février) Architecture logicielle pour la mise en œuvre réelle de l’application
Cycle de vie des IHMs
Plan à suivre (étape 1) Définir le modèle conceptuel de l’utilisateur Dégager le modèle de conception Charte graphique et contraintes ergonomiques Réaliser un prototype Evaluer le prototype
Plan à suivre (étape 2) Prendre en compte les retours de l’évaluation Préparer l’architecture logicielle : choix d’implémentation Réaliser un prototype plus finalisé
Motivations et exemples d’applications visées
IHM sur supports mobiles Complexification de la conception ergonomique et logicielle
IHM sur supports mobiles Complexification de la conception ergonomique et logicielle
IHM sur supports mobiles Complexification de la conception ergonomique et logicielle
Les enjeux de la mutation Ingénierie au cas par cas insuffisante Coûts de développement et de maintenance Cohérence ergonomique entre versions De nouveaux problèmes à résoudre prendre en compte le contexte dans l'interaction Perception/modélisation/adaptation Des solutions à des problèmes anciens à revoir les techniques d'interaction : windows, icons, menus, pointing Des problèmes classiques prennent une importance particulière concevoir pour plusieurs plates-formes assurer la sécurité et la confidentialité
Dimensions de l ’espace problème y s e d e s b e s o i n s Evaluation ergonomique T e s t s U t i l i s a t e u r s Espace de conception Propriétés ergonomiques C o n c e p t i o n T e s t s d ’ i n t é g r a t i o n C o n c e p t i o n l o g i c i e l l e Modèle d’architecture logicielle T e s t s U n i t a i r e s Boîtes à outils Mécanismes généraux C o d a g e
Dimensions de l ’espace problème Espace de conception : Plasticité Propriétés ergonomiques : Autonomie Poids Conception ergonomique Conception logicielle Outil de développement : Context Toolkit
Dimensions de l ’espace problème Selon trois axes Techniques d’interaction Collaboration Contexte
Dimensions de l ’espace problème Selon trois axes Techniques d’interaction Collaboration Contexte
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
Système interactif sensible au contexte
Système interactif sensible au contexte Exemple : Plate-forme MAGIC
Applicatifs envisagés Localisation de l’utilisateur Identification et localisation de dispositifs d’interaction
Applications de proximité centraux légers CEP Vendeurs Clients potentiels Centre hospitalier Serveurs BD, PC des secrétariats … Médecins : PDAs, PC portables Patients : carte vitale … Hospitalisation à domicile « HAN fixe » du patient Médecins : PDAs, PC portables …
Dimensions de l ’espace problème Selon trois axes Techniques d’interaction Collaboration Contexte
Mobilité : nouveau 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 IDENTIQUE (local) DIFFERENT (distant) CONFINE lieu de l’interaction délimité VAGABOND lieu de l’interaction n’importe où ENSEMBLE DISPERSE
Plate-forme Magic Casque + Ecouteurs Réseau sans fils Stylos Tablette + Extenseur de port Réseau sans fils Capteur d’orientation Camera + Micro
MAGIC : Travail sur le terrain de fouille Explorer le site (Mobilité) Travailler en groupe sur le site (Collecticiel) S’informer auprès d’experts distants (Collecticiel) Comparer des objets physiques avec des objets d’une base de données (Augmentation) Accéder aux objets enlevés du site (Augmentation)
MAGIC : vue d’ensemble Sur la tablette : A travers le casque: Communication (forum, mail, etc.) Coordination (carte) Production (outils d’édition) A travers le casque: Combinaison du physique avec l’informatique grâce à la passerelle
Terrain augmenté Un archéologue travaille Il trouve un objet La découverte est retirée du site L’objet est sauvegardé dans une base de données Un archéologue approche de où était l’objet La découverte est virtuellement disponible
TROC : Interface de la tablette tactile Menu Formules Liste Gestion des cubes Gestion du piège Historique Carte
Interface dans le casque Temps de jeu Autre objet visible Objet ciblé Niveau d’énergie magique Description de l’objet ciblé Formules actives Messages Œil magique
Dimensions de l ’espace problème Selon trois axes Techniques d’interaction Collaboration Contexte
Mobilité : Interface « Baby face » De très nombreuses techniques d ’interaction Technique d ’interaction : plusieurs perspectives psychologie cognitive : système sensoriel informatique : technique d’interaction Technique d’interaction : plusieurs niveaux d’abstraction dispositif physique clavier, souris, écran, haut-parleur, ... Système représentationnel langue pseudo-naturelle, manipulation directe, ... Système sensoriel Système cognitif
Interface « Baby face » Technique d ’interaction en sortie Son spatialisé : T = <haut- parleur, LN> RDV à 15h Soundbeam Neckset
Interface « Baby face » : multimodalité Plusieurs techniques ou modalités d ’interaction Apports de la multimodalité Flexibilité/adaptabilité (contexte d ’usage) Robustesse (complémentarité, redondance) Expressivité (complémentarité) Problèmes posés Validation empirique de ces apports Etude de l’usage des modalités (choix, appropriation, etc.)
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 » : multimodalité Magicien d ’oz Compère Sujet observé
Interface « Baby face » : multimodalité Usage des modalités par les sujets Toutes commandes / Toutes sessions Vocale Tactile Gestuelle Embodied
Interface « Baby face » : multimodalité 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é
Dimensions de l ’espace problème Interaction homme-machine Techniques d’interaction Collaboration Contexte
Les enjeux de la mutation Ingénierie au cas par cas insuffisante Coûts de développement et de maintenance Cohérence ergonomique entre versions Des problèmes classiques prennent une importance particulière concevoir pour plusieurs plates-formes assurer la sécurité et la confidentialité
Plasticité des interfaces Un peu d’histoire … Introduction du terme à Interact’99 Capacité d’une interface à s’adapter à son contexte d’usage dans le respect de son utilisabilité Contexte d’usage Plate-forme Environnement Utilisateur (2001)
Traducteurs XSL HTML XML VoiceML WML XML et XSL pour la présentation, UIML, SUNML, Xforms …. XSL HTML XML VoiceML WML
Langage de description d’interfaces
UIML « User Interface Markup Language » Langage multi-interface (graphique, voix, ...) Une norme : UIML (uiml.org) Des implémentations ou « renderers » Harmonia : Awt/Swing, HTML, WML, VXML, ... Rubico : Visual Basic, GUI builder TV Server, AG : C++ for embedded systems Jeremy Fierstone / Equipe Rainbow / 45
Document UIML <Head> : metadata (author, date, version, ...) Les 4 parties d'un document UIML: <Head> : metadata (author, date, version, ...) <Template> : réutilisation de fragments <Interface> : interface proprement dite <Structure> : arbre des « widgets » <Style> : styles (propriétés) des widgets <Content> : contenu (texte, image, son) <Behavior> : objet / événement / action <Peers> : mappings et liens vers l'extérieur Jeremy Fierstone / Equipe Rainbow / 46
De l’IHM abstraite vers l’IHM concrète Fichier SUNML (Spécification) IHM abstraite (Exécution) <sunml> <interface id="FicheClient"> <structure> <dialog id="MainDialog" sequence="true"> ... <field id="LabelFieldNom" mode="read"> <element type="String">Nom :</element> </field> <field id="FieldNom" mode="read-write"> <element type="String">Toto</element> </field> ... </dialog> </structure> </interface> </sunml> FicheClient HMI Réification MainDialog Dialog ... LabelFieldNom FieldNom Field Field Projection IHM concrète (Exécution) JFrame1 JFrame JPanel1 JPanel ... JLabel1 JField1 JLabel JTextField Légende Instance
Exemple de Liste de Clients Composition Représentant – Client (1-n) : Liste de clients Fichier SUNML (spécification) <sunml> <interface id="ListeClients"> <structure> <dialog id="MainDialog" sequence="true"> <list id="ListeClients" reference="FicheClient" select="Field[FieldNom]"/> </list> </structure> </interface> </sunml> Exemple en Swing
Les enjeux de la mutation Traductions automatiques insufisantes Ergonomie des versions Multiplicité des traducteurs
Espace problème Domaine de plasticité Seuil de plasticité Contexte couvert par l’IHM C2 Contexte non couvert
Cadre de référence : principes “Spécifier 1 fois -> N Interfaces” approche par modèles Trois groupes de modèles Domaine Contexte Adaptation Trois instanciations Ontologiques: Métadescriptifs, théorie Archetypes: spécifiques au contexte ciblé, phase “conception” Observés: exécutables, phase “exécution”
Cadre de référence : phase “conception” ARTStudio D. Thevenin Modèles archétypes Domaine Concepts Tâches Contexte User Plate-forme Environment Adaptation Evolution Transition Modèles ontologiques Config 1 Modèle Tâches et Concepts Modèle Tâches et Concepts Config 2 Concepts Concepts Tâches Tâches IHM abstraite IHM abstraite User User Plate-forme Plate-forme IHM concrète IHM concrète Environment Environment Evolution Evolution IHM finale IHM finale Transition Transition Réification, Factorisation, Traduction, Abstraction / Reconception, Crossing, Intervention Humaine
Cadre de référence : phase “conception” Config 1 Tâches & Concepts IHM abstraite IHM concrète IHM finale
Consensus et RIML (SAP) Même principe que ArtStudio : un moteur d'adaptation basé sur une catégorisation des devices (analyse d'utilisabilité donne un nombre de classes de devices limité qui représente des devices se comportant de façon similaire pour les utilisateurs) Avantages pour les programmeurs d'application Abstraction des devices Inutile d'apprendre de nouveaux langages, de connaître de nouveaux devices Facilité d'intégration Meilleure usabilité que les traducteurs libre choix de devices Rapidité de développement sur de nouveaux devices Ajout d'un render
Adaptation syntaxique En fonction du device Règles d'encodage Adaptation sémantique Filtrage des données Editeur RIML
Les enjeux de la mutation De nouveaux problèmes à résoudre prendre en compte le contexte dans l'interaction
Plasticité des interfaces : une nécessité Problème ? Exemple SI la batterie du PC faiblit ALORS passer sur PDA SI condition ALORS action Action Réaction
Espace problème
Cadre de référence : phase “exécution” Exécution de la réaction Identification du Identification Reconnaissance de situation changement de Des solutions Calcul d’une réaction contexte candidates Détection de Selection d’une solution candidate changement de contexte Capture du Exécution du contexte prologue Execution de Execution de la Exécution de la réaction L’épilogue reaction
Ingénierie : Capture de contexte Donnée captée et méta-donnée Précision Fréquence Stabilité Zone de couverture Complétude Ambiguïté Complémentarité Redondance Architecture logicielle
Contexte : Absence de consensus mais des leçons Leçon 1: Le contexte peut seulement être défini pour une finalité Leçon 2: Le contexte est un espace d'informations qui sert l'interprétation Leçon 3: Le contexte est un espace d'informations partagé Leçon 4: Le contexte est un espace d’informations infini et évolutif
Ontologie … Contexte (U,T) = ensemble de rôles et de relations entre entités pour la réalisation de T par U Changement de Contexte = l’ensemble des rôles change,et/ou l’ensemble des relations change Tâches et activités ont lieu dans un réseau de contextes Contexte (U,T) = un réseau de situations qui partagent le même ensemble de rôles et de relations Les tâches mettent en jeu des entités (ex.: une table, un crayon, une couleur) Entité = un regroupement d’observables Entités peuvent jouer un rôle = une fonction relative à une tâche, qui est satisfaite par une entité, (par exemple, une table satisfait la fonction « surface de dépôt ») Entités peuvent entretenir des relations Domaine (monde) = un réseau d’états reliés par des actions État = un prédicat sur des observables But = état souhaité Tâche = <état courant, but>, c.-à-d. absence de plan Activité = <tâche courante, {tâches de fond}>
Les enjeux de la mutation Des solutions à des problèmes anciens à revoir les techniques d'interaction : windows, icons, menus, pointing
Ordinateur, ubiquité et mobilité (utilisateur équipé) Ubiquité (environnement équipé)
Ordinateur Vestimentaire L ’ordinateur vestimentaire apparaît donc comme l’ordinateur de l’utilisateur mobile Encore souvent son téléphone, son ordinateur de bureau... Or la mobilité appelle d’autres applications pour l ’ordinateur : ordinateur de plongée, ... Il s ’agit souvent de systèmes Ad-Hoc, non ouverts, non flexibles
Mini Projets d'IHM Par groupe de 4 au plus Sujets accessibles à l'adresse : http://www.essi.fr/~pinna/MODULEIHM/ Choix par mail avant mercredi prochain A priori 1 groupe pour un sujet
Merci à … Laurence Nigay (IMAG) : Exposé de synthèse aux Asisses I3 Marie THILLIEZ (Université de Valenciennes) : LES APPLICATIONS DE PROXIMITE Gaëtan Rey, Joëlle Coutaz (IMAG) : LE CONTEXTEUR: UN MODELE COMPUTATIONEL POUR LE CONTEXTE Joelle Coutaz et Gaelle Calvary (IMAG) : Plasticité des interfaces Philippe Renevier, Laurence Nigay, Pascal Salembier, Jullien Bouchet, Laurence Pasqualetti (IMAG) SYSTEMES MIXTES MOBILES ET COLLABORATIFS TROC : UN JEU COLLABORATIF SUR SUPPORT MOBILE EXPLOITANT DES TECHNIQUES DE REALITE AUGMENTEE Jean-Yves Tigli (I3S) WCOMP : UNE PLATE-FORME EXPERIMENTALE OUVERTE D'ORDINATEUR VESTIMENTAIRE Anne-Marie Dery-Pinna et Jérémy Fierstone (I3S) : COMPOSANTS ADAPTABLES ET MOBILES Et tout le groupe : http://iihm.imag.fr/nigay/GTMOB/Dec2002/