Réalisation Savoir réaliser une IHM Savoir concevoir une IHM Savoir évaluer une IHM Cedric.Dumas@emn.fr contrat Creative Commons Paternité-Pas d'Utilisation Commerciale- Partage des Conditions Initiales à l'Identique 2.0 France License

Réalisation - dld Styles d’interactions Dispositifs d’Entrée/Sortie Périphériques de Sortie : écrans Périphériques d’Entrée périphériques de localisation Interaction multimodale Gestion : des Entrées des Fenêtres 2

Écrans Périphériques Type : Écrans bitmap : cathodique LCD résolution : pixels per inch (ppi) profondeur : bits par pixel rafraîchissement : images par seconde taille mémoire Périphériques cathodique : deflection d'un faisceau d'électrons surun écran recouvert de phosphore. rafraichissemnent à chaque trame. LCD: utilisation des priopriétés de polarisation de la lumière par les cristaux liquides. exemple 1024x768 : 1 bit / pixel 98 ko 24 bits / pixel 2,3 Mo alpha component : +8 double buffer : x2 Z-buffer : + 16/32 bits / pixel stencil buffer : +1/32 bits/pixel etc... cmoposant spécialisé déchargent le CPU, en 2D, en 3D. 3

Écrans Périphériques Couleurs directes Tables de couleurs et les autres Buffers ! Périphériques beaucoup de bits / pixel = bcq mémoire = importance de la vitesse du bus mémoire = cher couleur directe : relation fixe entre pixel et couleur table de couleur : 8 bits / pixel -> 256 couleurs différentes parmi 16 millions. -> si on change une couleur dans la table, tous les pixels associés changent -> on affecte pas la structure, utile pour certains effets spéciaux -> Web, taille réduite, transparence, animation, cycling de couleurs 4

Périphériques physiques Retour de toucher capteur piézzo dispositif mécanique Retour d’effort joystick souris bras etc... Périphériques 5

Périphériques d’entrée tablette : - selectrique - sonore - résistif souris : - mécanique - optique crayons : detection au passage du spot de l'écran, fatiguant, peu précis. LOGIQUES : pour faire abstraction des particularités des P. physiques, certaines librairies introduisent la notion de P. logiques. Grace a cette notion, une application peut etre rendue pratiquement indépendante de son environnement matériel, et donc plus facilement portable. GKS et PHIGS distinguent les périphériques logiques suivant : P val Locator position 2D Pick identificateur de l'objet affiché à l'écran Choice entier représentant le choix dans une liste Valuator nombre réel String chaine de caracteres Stroke séquence de points (un tracé) implémantés par des périphériques physiques ou simulés, par exemple : Locator souris Pick souris Choice clavier spécial, touches de fonction, menu à l'écran Valuator bouton rotatif (physique) ou potentiomètre à l'écran String clavier (entréee de caracteres jusqu'a RETURN) Stroke souris (clic - drag -clic) périphériques logiques PHIGS et GKS == taches élémentaires d'interaction (teme plus récent) Xwindows, Mac Toolbox, etc tendent à ne plus faire de distinctions aussi fine et restent + proche du niveau physique. -> parce que ce n'est pas pratique pour cetains type de périphériques -> parce que ce systeme prejuge du style d'interaction Périphériques d’entrée Périphériques physiques claviers, boîtes à boutons potentiomètres (rotatifs, linéaires) souris, tablettes, manche à balai, boules écrans tactiles, crayons optiques capteurs de position, d’orientation Périphériques simulés Périphériques logiques Périphériques virtuels Périphériques 6

Périphériques de localisation Absolu / Relatif tablette, écran tactile, crayon otique souris, joystick, trackball Direct / Indirecte écran tactile, stylo optique tablette, souris, joystick, trackball Discret / Continu Position / Taux de contrôle Position / Force (physiquement) Périphériques relatif psa adapté au dessin a main levée. -> mais le programme peut repositionner le programme n'importe ou. Direct / Indirecte à rapprocher de isotonique (capteur de position), isométrique (trackball 3D), élastique (joystick) direct plus naturel, mais généralement plus fatiguant et moins précis. Discret/Continu = numériques / analogiques Position vs. Rate control. Moving a mouse changes the position of the cursor; moving a rate-control joystick changes the speed with which the cursor moves. Physical property sensed: Position or Force. A mouse measures position; an isometric joystick, force. For a rotary device, the corresponding properties are angle and torque. + nbr de degrés de libertés + type de déplacement (lineaire, rotation, etc) 7

Périphériques de localisation Control-to-Display Ratio Loi de Fitts t = 0.1 log (2D / L) Périphériques Control-to-Display Ratio = rapport entre les mouvements de la main et les mouvements du curseur dP= déplacement réel dc = K.dP = deplacement à l'écran Mac = bonne précision pour un petit déplacement (dP petit) X = il y a un seuil entre deux ratio différents grand rapport = bon pour la précision, mauvais pour la rapidité (petit rapport = l'inverse) le rapport peut être ajusté dynamiquemnt en fonction de la vitesse des mouvements (= accélération de la souris) loi de Fitts : temps de pointage d'une cible de taille L à une distance D constante = 100 ms L D 8

Périphériques de localisation Multimodalité Bi-latéralisation main dominante : situe le contexte main non-dominante : agit dans le contexte Périphériques une application graphique dispose de plusieurs périphériques d'entrée -> chaque périph peut etre caractérise par un état : position et état des boutons de la souris, état de chaque touche du clavier, etc. -> les caractérisitquent physiques de chaque périphériques déterminent ses états possibles (par ex, certains claviers ne peuvent avoir qu'une touche appuyée à la fopis, touche de CTRL, MAJ, ... mis à part) -> gestion des entrées consiste à fournir les moyens à l'application de récupérer l'état et/ou les changements d'état des périphériques. Gestion des entrées ! 9

Type d’entrée gérer les entrées Requête Echantillonnage Événement attente bloquante réponse immédiate file d ’attente gérer les entrées mode requete = l'apli attend un chgt d'etat du periph (appli bloquée pendant ce temps la) -> un seul périph géré a la fois ech = etat du périph recuperable à tout moment -> attente active : l'appli boucle sur sur l'echantillonage sur un ou + de periph jusqu'a avoir un chgt d'etat -> bcq de ressoruces CPU pour rien mode principal actuel = mode évènement evt = file d'evt décrit les chgt d'etat des periph. evt contient : date de son occurence / le perph concerné (ID de periph physique) / l'état (et/ou le changt d'etat) du périph -> placetment dans la file d'attente par les couches basses -> l'appli peut (demander à) filtrer pour éviter de charger la file d'attente inutilemenbt. -> prbl : appli peut prendre du retard sur les evts ! (cas ideal = file vide) 10

Interaction directe : Modèle à base d'événements Création, propagation, réception, traitement Boucle d’événements Détection Détermination de la cible / liste des objets Synthèse des événements Ex : Drag = Click + Move Machine à état : Down Move Move Move Move Up 11

Modèle à base d'événements gestion Bouche de scrutation Gestion de la file d’attente des événements système Construire le dialogue à partir de ces événements Comportement lié aux objets graphiques 12

Gestion d’évènements gérer les fenêtres Terminaux virtuels une fenêtre appartient à une application une application dessine dans ses fenêtres une application reçoit les évènements qui se produisent dans ses fenêtres Notion de focus la fenêtre qui reçoit les évènements d’un périphérique à l’instant t gérer les fenêtres output : ecran partagé entre plusieurs applis grace aux fenetres input -> modele de fenetrage doit egalement permettre le partage des entrées position de la souris relative à une fenetre (coin sup gauche ou inf droit) et pas a l'ecran -> fenetre de réference = focus de la souris a tout instant, le clavier ET la souris sont associés à une fenetre, envetuellement la meme. evt transmis a la fenetre en focus -> demultiplexage des entrées. focus peut etre implicite (fenetre sous la souris) ou explicite, avec mise en avant des autres fenetres (Mac) ou non. -> une appli peut indiquer quels evenements l'interesse, via un masque d'evenements, global à l'appli ou a chaque fenetre (impose un parcours de l'arbre). 13

Types d’évènements gérer les fenêtres Liés aux périphériques changement de focus entrée/sortie du curseur dans une fenêtre Liés aux fenêtres demande de ré-affichage création, destruction, … etc... gérer les fenêtres 14

Bilan Interaction directe Objets liés à la manipulation directe : 10 % ? Différencié l’interaction directe sur les objets d’intérêts, les documents de l’interaction dans les menus, etc. Évolution de Manipulation Directe vers Interaction Instrumentale Un utilisateur pilote un instrument physique pour manipuler un instrument logique 15

Fenêtrage Modèles graphiques Architecture Logicielle

Systèmes de fenêtrage gérer les fenêtres Structurer l’espace d’affichage Partager la ressource écran Gestionnaire de fenêtres interface utilisateur système de fenêtrage Fenêtre = zone autonome pour l’affichage pour les entrées systeme de fenetrage -> structure l'espace d'affichage -> plusieurs applications en meme temps (multi plexage de l'ecran) Fenêtre = zone autonome vis à vis de l’affichage des entrées vue d'une application, une fenetre est comme un écran fenetre rectangulaire ne general, visible de l'utilisateur manipulable pas l'utilisateur = role du window manager NE pas confondre : - systeme de fenetrage : couche logicielle qui s'interpose entre les applications et le systeme graphique, et qui fournit notamment la notion de fenetre aux applications - gestionnaire de fenetre : module logiciel qui fournit une interface de manipulation des fenetres à l'utilisateur Il est : - integre au systeme de fenetrage (win) - appli séparée (X) - a la charge de chaque application (Mac Toolbox) Communication entre appli et systeme a fenetre : - envoyer des requetes graphiques : creer, detruire, déplacer, changer de taille (base commune) afficher des objets graphiques dans la fenetre (boutons, etc) - récupérer des évènements entrées de l'utilisateur evt liés au systeme de fenetrage : fenetre déplacée, etc (note : le gestionnaire de fenetre peut representer une fenetre sous différente forme, c'est independant du systeme de fenetrage) gérer les fenêtres 17

Modèles de fenêtrage gérer les fenêtres Sans superposition Avec superposition Hiérarchique gérer les fenêtres sans superspoition : le plus simple avec : 2D 1/2 (<> feuilles sur le bureau) chaque fenetre a un rang zone de clip = union des zones visibles (rectangles) de la fenetre hiérarchiques : deux niveaux avant : ecran + fenetre si hierarchique, chaque fenetre peut contenir d'autres fenetres. coherance : il faut qu'une fenetre fille ne soit visible que sur l'espace de sa fenetre mere. racine de l'arbre = ecran lui meme. X utilise intensivement l'imbrication de fenetres. 18

Systèmes de fenêtrage X-windows et ses window managers window manager  desktop environments  working environments X-windows et ses window managers Motif/Motif CDE/Motif OLWM/Openwin AfterStep Fvwm Enlightenment GNOME (Sawfish), KDE (Kwm), Qt Explorer de Windows (MFC) Finder de MacOS (QuartzExtreme) 19

Librairies graphiques Modèles de dessin : dessin direct : peinture de formes dessin structuré : arbre d’objets Définitions des objets graphiques attributs géométriques attributs graphiques Librairies graphiques Xlib, OpenGL, Direct Draw, etc... gérer les entrées 20

Modèle de dessins gérer les fenêtres Dessin direct Dessin structuré Problème : ré-affichage des parties cachées par le système de fenêtrage (nécessite de mémoriser le contenu des fenêtres) par les applications (nécessite de communiquer des demandes de réaffichage aux applications) Dessin structuré quelque soit le modèle de fenétrage, on peut avoir deux modèles pour la gestion du contenu des fenêtres. direct : (le plus repandu) application emet des requetes graphiques qui sont executés par le systeme de fenetrage, mais celui ci ne garde pas mémoire (autre que la mémoire ecran) de ce qui a été dessiné. Il est donc incapable de reconstituer le contenu d'une fenetre, par exemple si elle est fermée puis ouverte. -> il doit faire appel à l'application pour qu'elle redessine le contenu de la fenêtre. => par un systeme de CALLBACKs (ou fonction de rappel) => ou par un evenement dessin structuré : le systeme de fenetrage gere pour chaque fenetre une liste d'affichage (ou une structure + complexe) qui représente le contenu de la fenetre. Il est donc capable de ré-afficher le contenu d'une fenetre en toute circonstance. L'application dispose alors de focntions permettant de gérer cette liste d'affichage : insertion, destruction, changement d'attributs d'un éléments. dessin direct avec mémoire : == direct mais le systeme de fenetrage sauve dans des pixmaps hors ecran le contenu des fenetres, de maniere à pouvoir faire le réaffichage si nécessaire -> couteux en mémoire et en temps (il faut dessiner dans la fenetre et dans sa sauvegarde) gérer les fenêtres 21

X Portable Transparent vis à vis des réseaux Architecture client/serveur Solaris, Irix, Linux (XFree86) tous les OS séparation des composants  window manager 22

Boîtes à Outils X11/Motif X11/GTK Tcl/Tk MFC Swing 23

Architecture logicielle systèmes de fenêtrage boîtes à outils librairies graphiques Décomposition modulaire gérer les entrées 24

Pourquoi une architecture spécifique? Interfaces graphiques WIMP Standardisation de l ’aspect (look) et du comportement (feel) Nouvelle philosophie de programmation Contrôle utilisateur Séparation Interface et Noyau fonctionnel Architectures de type Arch 25

Architecture conceptuelle Développement d’applications interactives Spécifications liées au Modèle Arch Domaine Adaptateur Contrôle de Dialogue Présentation Interaction Contrôleur de dialogue lié à l ’analyse de tâche Standards des systèmes de fenêtrage Hiérarchie des objets Diffusion des événements à travers cette hiérarchie Classes d’Applications formulaires Web graphiques interactives 26

Outils de construction d’interfaces Catégories d’Outils Outils correspondants à différents niveaux de codage : Composant de base Boîte à outils Générateur de présentation Squelette d ’applications Saut Application (Squelette d’application) (Générateur de présentation) Boîte à outils Composant de base 27

Catégories d’outils de construction d’interfaces Composants de base Accès au système de fenêtrage (dit graphique) X, MacOS, Windows Sémantique graphique Fonctions graphiques Évolution par enrichissement ou par extension Compatibilité ascendante Ex de système graphique : OpenGL État des périphériques d ’entrée Boucle de gestion des messages et des évènements ++ Gestion du copier-coller 28

Composants de base Système de fenêtrage Niveau primitif des applications graphiques interactives Différentes catégories de fonctions offertes : gestion de session (ouverture, fermeture, gestion du temps) gestion des évènements gestion du graphique écran communication avec le gestionnaire de fenêtres communication entre les applications utilitaires (gestion de ressources, formats de fichier) 29

Générateurs d’interfaces Squelettes d ’applications Catégories d ’outils de construction d’interfaces Trois niveaux de construction Boîtes à outils Générateurs d’interfaces Squelettes d ’applications 30

1er niveau de construction d’interfaces Boîtes à Outils … natives Couche de programmation la plus basse du système de fenêtrage Conventions de bas niveau * plateformes Boucle de traitement des évènements Accès au système graphique + performance, abstraction spécifiques — temps d ’apprentissage et de construction Ex : jeux vidéo 31

Boîtes à outil natives Description Bibliothèque d’accès au Système de Fenêtrage Bibliothèque d’objets de contrôle : Widgets Mécanismes d’extension des objets de contrôle Mécanismes de communication entre les objets Application Boîte à Outils : Bibliothèque Système de fenêtrage Système d ’exploitation 32

Boîtes à outil natives Caractéristiques + Couverture de l’ensemble de l’arche, de l ’interface au noyau fonctionnel . Appels fonctionnels, callbacks, gestion des évènements - Plusieurs mois d’apprentissage -- Temps de développement important pour une application complète . Peu de méthodologie de construction préconisée ++ Tous les modèles graphiques sont supportés + Modularité des widgets - Modularité de l’ensemble de l’application dépendante du programmeur - Extensibilité de l’ensemble dépendante du programmeur - Code rarement compact ==> Méthodologie de développement 33

Point commun de toutes les plateformes 1er niveau de construction d’interfaces Boîtes à Outils … multiplateformes Pour éviter de développer une version de l ’application pour chaque plateforme Point commun de toutes les plateformes Primitives les plus simples Évènements nombreux Composants natifs vs composants spécifiques Ré-implémentation des composants natifs par plateforme : Java Swing (99), IlogViews (94) 34

Boîtes à outil multiplateformes Encapsulation Encapsulation des mécanismes spécifiques à chaque plateforme + Bonne extensibilité - Difficultés à respecter le “look and feel” natif - Difficultés à exploiter les utilitaires de communication entre applications Application Boîte à Outils générale Système de fenêtrage Système de fenêtrage Système d ’exploitation Système d ’exploitation 35

Boîtes à outil multiplateformes Machine virtuelle Abstraction des mécanismes primitifs (modèle abstrait générique) Exemples : IlogViews, Java - Production du plus petit dénominateur commun + Portabilité et respect du “look and feel” natif sont garantis Application Boîte à Outils Générique Adaptation Adaptation Système de fenêtrage Système de fenêtrage Système d ’exploitation Système d ’exploitation 36

2ème niveau de construction d’interfaces Générateurs d’interface Générateurs de la partie Présentation de l’application Éditeurs graphiques à manipulation directe La partie générée peut être : du code natif (C, C++, Java), rapide mais difficile à modifier du code intermédiaire, fichier de ressources interprété par l’appli, modifiable mais lent un mélange des deux : code intermédiaire et “talons” de communication entre adaptateur de noyau fonctionnel et fonctions natives Générateur Présentation Domaine Bibliothèque Système de fenêtrage Système d ’exploitation 37

Générateurs d ’interface Gestion du placement Placement statique des composants en wysiwyg Fenêtres d ’application de taille fixe Résultat fidèle mais qualité d ’usage dépendante des tailles et des résolution d ’écran Placement implicite dans des conteneurs invisibles Retaillage difficile Lisibilité et hiérarchisation des informations Placement sous contraintes / description de relations Rataillage à évaluer à l ’usage Nécessité de connecter les composants obtenus à l ’application Difficultés à décrire la dynamique de l ’interface telle que apparition progressive et déplacement des composants 38

Générateurs d ’interface Caractéristiques ... Construction isolée de la présentation Temps d ’apprentissage court … sauf pour la connexion au reste de l ’application Temps de construction court … pour le standard Méthodologie recommandée : 1° Interface 2° Connexion au noyau sémantique Extensibilité et modularité restreintes 39

Générateurs d ’interface … Caractéristiques . Seule la Présentation est générée + Enrichissement des mécanismes de la BAO sous-jacente . Générateurs dédiés à un certain type d’interfaces, exemple : Formulaire + Temps d’apprentissage court si on suit les stéréotypes . Talons de communication efficaces si on reste proche des modèles génériques - Le modèle graphique reste celui du SDF natif - Seules les entrées souris et clavier sont prévues - Difficultés à réutiliser des composants inter-applications et des talons existants . Les applications générées sont compactes en code sous condition d’utiliser des bibliothèques dynamiques 40

3ème niveau de construction d’interfaces Squelettes d’application Application Frameworks : Découpage en objets coopérants d’une application graphique interactive Factorisation des parties de code récurrentes Développement d’une application spécifique par Dérivation des classes abstraites d’un squelette Spécialisation des méthodes Présentation Générateur Système de fenêtrage Système d ’exploitation Domaine Boîte à Outils 41

Squelettes d ’Application Exemples Exemples historiques MacApp : classes Application, Document, View NextStep sur station NeXT —> Éditeurs de texte, de dessin Exemples contemporains Java Swing : Boîte à outils ET squelettes génériques MFC Microsoft OpenStep Apple GNUstep 42

Squelettes d ’Application Caractéristiques ... Peuvent construire toute l ’application Programmation objet, design pattern Temps d ’apprentissage long / squelettes abstraits Temps de développement court / stéréotypes Méthodologie incrémentale Description progressivement raffinée des méthodes Connexions simples avec d ’autres protocoles BdD, web Extensibilité et modularité limitées aux stéréotypes 43

Squelettes d’application … Caractéristiques ++ Extensibilité : grande richesse dans les dérivations -- Grande complexité : trop modifiables ++ Modularité : utilisation rigoureuse des protocoles, pas de spécialisation Ex : éditeur de texte, de graphe sous NextSTEP + Les squelettes peuvent aider à construire toutes les parties de l’application. . Les composants communiquent par invocation de méthodes ou par callback . Certains formalismes sont très compacts (interacteurs) . D’autres sont de très bas niveau (gestion du graphique interne) + Construction (relativement) rapide d’applications collant au modèle du squelette - Long temps d’apprentissage (= Fonction du degré d’abstraction des squelettes) . Méthodologie de développement : dériver les classes abstraites définir les méthodes requises - Seules les entrées souris et clavier sont prévues 44

Outils de construction d’interfaces Perspectives Langages spécialisés Langages dédiés à la construction d ’application graphique interactive Mécanismes de communication entre composants Exemples Visual Basic Tk avec Tcl , PERL ou Scheme Facilités syntaxiques Facilités sémantiques : Contrôleur de dialogue Communication entre Noyau fonctionnel et Présentation 45

Outils de construction d’interfaces Perspectives Méthodologie de conception des interfaces “Design Pattern“, Motifs de conception Abstraction des squelettes d’applications Découpage de l’application en composants autonomes Schémas de programmation But : améliorer la qualité du logiciel en robustesse, modularité, réutilisabilité Démarche : Identification de Patrons à partir des spécifications Développement orienté objet avec communication par messages 46

Questions ? 47