Construction des IHM Spécification - Modèles - Outils Prise en compte des utilisateurs GLI – Master 2 Informatique GL, Mitic et Miage IHM – ESIR 2 LSI Thierry Duval ISTIC / IRISA - Bunraku [email protected]2 Plan I. Introduction – Généralités II. Modèles d’architecture logicielle III. Outils pour construire des IHM IV. Conception centrée sur l’utilisateur V. Conclusion... 3 I : Introduction - Généralités Du langage de commande aux gestionnaires de fichiers interactifs… Objectifs et besoins Différents types d’applications interactives Comment couvrir nos besoins Séparation application IHM Notion de contrôle du dialogue 4 5 6 Cadre de travail Applications graphiques interactives : produire des dessins, des images agir sur ces dessins ou ces images échanges utilisateur application : • interactions homme-machine • dialogue homme-machine Interface utilisateur : doit être facile à utiliser ! jusqu’à 80% du code total de l’application ! coût très et trop important : il faut le réduire ! 7 Problématique des IHM Comment : analyser spécifier concevoir implémenter tester valider maintenir les IHM ? Comment couvrir leur cycle de vie ? et celui des applications interactives en général ? 8 Validation Conception générale Tests d’intégration Conception détaillée Implémentation Tests unitaires Analyse - Spécification Rappel : cycle en cascade
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Construction des IHMSpécification - Modèles - OutilsPrise en compte des utilisateurs
GLI – Master 2 Informatique GL, Mitic et MiageIHM – ESIR 2 LSI
! Interface utilisateur :" doit être facile à utiliser !" jusqu’à 80% du code total de l’application !" coût très et trop important : il faut le réduire !
! Actions : désignations d’objets de l’application" puis exécution de commandes sur ces objets…
16
17
Applications à manipulations directes
! Action : manipulation directe des objets applicatifs
! Manipulation directe :" représentation continue des objets" actions physiques sur les objets" opérations rapides, incrémentales et réversibles" impact sur les objets manipulés visible aussitôt
! Démo…
18
Tentative de classification…
! …des applications interactives…
! Selon 2 critères :" le niveau de visualisation" le niveau de rétroaction
19
Niveaux de visualisation
! 1 : Absence d’illustration des objets de l’application" shells, IHM limitée aux objets de dialogue, …
! 2 : Impossible d’agir directement sur une illustration" xdvi : type « visionneuse », pour informations, …
! 3 : Désignation d’une illustration" gestion graphique de fichiers (KDE, …) :
• pour obtenir un menu contextuel• pour la désigner comme argument d’une commande
! 4 : Manipulation directe d’une illustration" gestion graphique de fichiers (KDE, …) :
• pour exprimer la commande via cette manipulation
20
Niveaux de rétroaction (1/3)
! A l’aide d’un exemple...
! Syntaxe imposée : commande argument" la commande : détruire" les arguments à disposition :
• dir1 (un répertoire, pas du bon type pour la commande détruire)• fich1 (indestructible, du bon type mais pas dans le bon état)• fich2 (destructible, du bon type et dans le bon état)
21
Niveaux de rétroaction (2/3)
! 1 : absence de rétroaction :" daitruiere f1
• shells sans complétion des mots, …
! 2 : rétroaction lexicale :" dir1 détruire
• shells avec complétion, menus avec mots existants, …
! 3 : rétroaction syntaxique :" détruire fich1
• gestionnaires de fichiers, …
! 4 : rétroaction sémantique :" détruire fich2
• bien peu d’applications… 22
Niveaux de rétroaction (3/3)
! Autre exemple :" résolution interactive du problème des tours de Hanoï" démonstration…
23
Visualisation et rétroaction
Visualisation
Rétroaction
aucune lexicale syntaxique sémantique
aucune
visible
désignable
manipulable
L’objectif !!!
24
Visualisation et rétroaction
! Les niveaux les plus élevés sont :" difficiles à atteindre car complexes à implémenter" parfois indésirables à cause des temps de réponses !
! Exemple interactif : l’explorateur de fichiers…" offre un niveau de visualisation maximum" n’offre au mieux que des rétroactions syntaxiques" comme par exemple l’écriture sur un support matériel…
25
Objectifs du cours…
! Couvrir tout le cycle de vie du logiciel interactif! Être capable d’analyser, spécifier, concevoir,
implémenter, tester, valider et maintenir :" des interfaces 2D classiques « WIMP » (Window, Icon,
Menu, Pointer)
! Types non (ou peu, ou indirectement) abordés :" IHM 3D" IHM multimodales" Collecticiels (GroupWare, CSCW)" Réalité Virtuelle" IHM pour dispositifs mobiles
26
Besoins
! Méthodes :" pour ne pas faire n’importe comment…
• analyser, spécifier les besoins• prendre en compte les utilisateurs• concevoir le logiciel (et le dialogue !)
! Outils :" pour utiliser les méthodes plus facilement" pour aller plus vite
! Mise au point des applications interactives :" processus itératif intégrant les utilisateurs
! Les IU doivent être modifiables :" facilement" rapidement
! Séparation et mise au point :" la modification de l’application n’affecte pas l’IU" la modification de l’IU n’affecte pas l’application" mise au point facilitée" maintenance facilitée 30
Besoin de nouvelles compétences
! Nouveau dialogue (interne) :" entre application et IU
! Besoin d’une spécification formelle du dialogue :" pour garantir l’indépendance application ! dialogue avec
l’utilisateur
! Nouveau rôle :" celui du spécialiste en IHM !
31
Bilan de la séparation (1/2)
! Avantages pour tout le cycle de vie du logiciel :" application plus modulaire, plus réutilisable" prototypage du dialogue plus rapide" développement de l’IU :
• indépendant de celui de l’application• en parallèle de l’application• par des experts en IHM
" plusieurs interfaces pour une application" une interface pour plusieurs applications
32
Bilan de la séparation (2/2)
! Inconvénients :" chute de l’efficacité des interactions" duplication d’informations
! Conclusion :" il faut séparer !" mais comment ?
! Il faut s’intéresser à la structure du dialogue…" c’est ce qu’on appelle aussi le contrôle du dialogue
33
Contrôle du dialogue (1/2)
! Organisation, gestion, initiative :" du dialogue avec l’utilisateur" des composants de l’application" du séquencement des événements (dialogue et calcul)" des communications internes
34
Contrôle du dialogue (2/2)
! Différents types (évolution au cours des âges) :" absence de contrôle" contrôle interne :
• dominé par l’application
" contrôle externe :• dominé par le dialogue
" contrôle mixte :• partagé entre l’application et le dialogue
" contrôle équilibré :• un composant de contrôle domine l’application et le dialogue
35
Approche non structurée (1/2)
! Application = { procédures } dépourvu de structure
! E/S physiques utilisées directement par l’application
! Appels aux E/S dispersés dans tout le code
! Application peu lisible, peu portable et peu maintenable
! Pas de séparation dialogue ! application !36
Application
Approche non structurée (2/2)
37
Contrôle interne (1/3)
! Le contrôle réside dans l’application
! Dialogue = { procédures } assurant la gestion des E/S
! Appeler le dialogue à des endroits appropriés de l’application
38
ApplicationDialogue
Contrôle interne (2/3)
39
Contrôle interne (3/3)
! Avantage :" simplicité d’utilisation/réalisation : forme très répandue
dans un passé récent…
! Inconvénients :" séparation seulement entre présentation du dialogue et
application" compromet la modularité de l’application" contraignant pour l’utilisateur" IU non modifiable sans changer l’application" seul le réalisateur est apte à effectuer ces modifications
40
Contrôle externe (1/3)
! Application = { tâches } que le dialogue invoque en réponse aux actions de l’utilisateur
41
ApplicationDialogue
Contrôle externe (2/3)
42
Contrôle externe (3/3)
! Avantages :" meilleure décomposition modulaire" dialogue réalisable par un spécialiste en IHM" dialogue à l’initiative de l’utilisateur" plusieurs interfaces pour une même application
! Inconvénients :" impose au réalisateur un style de programmation
particulier" applications décomposées en « atomes »
" pas de communication directe application ! utilisateur
43
Contrôle mixte (1/3)
! Similaire au contrôle externe
! Application = { procédures } intelligentes" communiquer avec l’utilisateur" envoyer des messages asynchrones au dialogue
44
ApplicationDialogue
Contrôle mixte (2/3)
45
Contrôle mixte (3/3)
! Une nécessité dans certains cas :" signalement d’événements asynchrones" obtention de renseignements complémentaires" réutilisation d’applications existantes
! Un compromis :" contrôle externe simulant un contrôle mixte
46
Contrôle équilibré (1/2)
! Contrôle externe
! Dialogue séparé en deux parties :" présentation :
• gestion physique de l’interaction avec l’utilisateur
" contrôle :• gestion des événements venant de l’application et de l’utilisateur
! Décomposition en 3 parties (Seeheim)
47
ApplicationDialogue
Présentation Contrôle
Contrôle équilibré (2/2)
48
Conclusion I : généralités
! Construction des IHM : un problème complexe…" surtout pour les IHM « intéressantes »
! Certaines solutions techniques existent…" mais comment les implémenter ?" quelle méthodologie appliquer ?" quels outils utiliser ?" les outils aident-ils vraiment ?
! Et les utilisateurs dans tout cela ?" quelle méthodologie pour les prendre en compte ?" à quel moment les prendre en compte ?
49
II : Modèles d’architecture logicielle
! Approche « Génie Logiciel » de la conception d’IHM! Volonté de :
" mettre en oeuvre la séparation" faire du contrôle équilibré
! Un modèle, pour quoi faire ?" classification d’applications" test de conformité d’architecture logicielle
• évaluation du coût de maintenance…
" aide à la construction des IHM
! Présentation de quelques modèles…
50
Aide à la construction d’IHM
! Conseils sur la manière de structurer les applications interactives
! Comment les construire correctement :" comment séparer au mieux l’IHM de l’application" comment faire du contrôle équilibré
! Fournir la description :" des données échangées entre utilisateur et application" des étapes de transformation des données" de l’agencement des composants qui assurent ces
transformation
51
Utilisation d’un modèle
! Qui utilise un modèle ?" le concepteur de l’interface utilisateur
! Comment ?" à l’aide d’un environnement intégrant le modèle :
• dans un cadre formel pour la construction « automatisable » d’une application interactive, avec la possibilité de disposer d’outils permettant d’instancier et de remplir les composants du modèle
" sans outil d’intégration dédié au modèle :• on s’efforce de respecter au mieux les structures des modèles,
bien qu’on ne soit pas aidé par un environnement
52
- ++-+- 20120
Exemple : l’entier borné interactif
! Présentation = reflet de la sémantique :" valeur" opérations réalisables (ou non)
! Accès par voie logicielle :" valeur" 2 opérations : incrémenter et décrémenter" pré-conditions des opérations
! Rôle :" gérer les entrées en provenance de l’utilisateur et les
transmettre à son responsable" réagir selon son état (actif ou inactif)" refléter l’état d’une fonctionnalité associée
! Primitives :" permettre à un client de modifier son état" gérer les entrées d’un utilisateur" afficher son état" communiquer à un client qu’il a été désigné
55
Construction de l’entier borné
! Rôle :" communiquer avec les objets qui le composent" être manipulé par voie logicielle" assurer la cohérence entre données et présentation" visualiser sa valeur
! Primitives :" fonctionnalités logicielles" pré-conditions des fonctionnalités" communication avec les objets composants
56
Le code du bouton (1/2)
type Bouton
actif : booléenresponsable : entierBorné
traiterDésignationdébut
si (actif) alorsclignoter // code graphique…responsable.traiterBouton (this)
fin sifin
57
Le code du bouton (2/2)
activerdébut
si (non actif) alorsdessinerActif // code graphique…actif <- vrai
fin sifin
désactiver …
fin type
58
Le code de l’entier borné (1/3)
type EntierBorné
valeur, minimum, maximum : entier
boutonPlus, boutonMoins : bouton
autoIncrémenter : booléendébut
retourne (valeur < maximum)fin
59
Le code de l’entier borné (2/3)
incrémenterdébut
si (valeur < maximum) alorssi (valeur = minimum) alors
boutonMoins.activerfin sivaleur <- valeur + 1affichage graphique de valeur // code graphique…si (valeur = maximum) alors
boutonPlus.désactiverfin si
fin sifin
60
Le code de l’entier borné (3/3)
traiterBouton (unBouton : Bouton)début
si (unBouton = boutonPlus) alorsincrémenter
sinon si (unBouton = boutonMoins) alorsdécrémenter
fin sifin
autoDécrémenter …
décrémenter …
fin type
61
Le modèle Seeheim (1/3)
! Congrès sur les SGIU, Seeheim, 1983! Contemporains : Ada, C, Pascal, GKS, PHIGS! 3 composants pour décrire une IHM
PrésentationContrôle
du dialogue
Utilisateur
InterfaceApplication
Application
62
Le modèle Seeheim (2/3)
! Présentation :" présentation externe du système à l’utilisateur" gestion de l’écran, affichage de l’information" gestion des dispositifs d’entrée" gestion des modes d’interaction" responsable de la rétroaction lexicale
63
Le modèle Seeheim (3/3)
! Application :" partie applicative indépendante du dialogue
! Interface avec l’application :" application du point de vue de l’IU" descriptions des structures de données et des procédures
de l’application accessibles à l’IU" pré-conditions et post-conditions
! Contrôle du dialogue :" médiateur entre présentation et interface avec l’application
64
Seeheim et l’entier borné (1/3)
! Présentation :" gestion des événements d’entrée" affichage de la valeur et des boutons
! Interface avec l’application :" description des fonctionnalités de l’application" pré-conditions des fonctionnalités
! Application :" attributs (bornes et valeur de l’entier)" implémentation des fonctionnalités (+1 et -1)
65
Seeheim et l’entier borné (2/3)
! Contrôle du dialogue :" gestion d’événements logiques de présentation" vérifications sémantiques (interface application)" mise à jour des dispositifs de présentation" interface logicielle vers l’extérieur
! Boîte à outils :" responsable de l’interaction physique avec l’opérateur
81
Le modèle PAC (1/3)
! J.Coutaz, 1987
! Contemporains : langages objets
! Première interprétation multi-agents de Seeheim
! IU = hiérarchie d’agents PAC à 3 composants" les agents communiquent uniquement via leurs contrôles
! Perte de distinction entre application et interface avec l’application 82
A P
C
Abstraction Présentation
Contrôle
A P
C
A P
C
Le modèle PAC (2/3)
83
Le modèle PAC (3/3)
! Présentation :" définit la syntaxe concrète de l’application :
• le comportement, en entrée comme en sortie, de l’application par rapport à l’utilisateur
" ne communique qu’avec son contrôleur
! Abstraction :" sémantique : les fonctionnalités de l’application" ne communique qu’avec son contrôleur
! Contrôle : " maintien de la cohérence entre présentation et abstraction" peut communiquer avec d’autres contrôleurs
84
PAC et le bouton
! Présentation :" réception de la désignation physique" appels au contrôle" primitives de dessin
! Abstraction :" primitives de gestion de l’état du bouton
! Contrôle :" réception des messages de la présentation" assure la rétroaction immédiate" signale les désignations au contrôle de l’objet client" reçoit des messages d’activation et de désactivation
! Mike Potel, Taligent (Apple – IBM – HP), 1996! Model – View – Presenterhttp://www.wildcrest.com/Potel/Portfolio/mvp.pdfhttp://msdn.microsoft.com/en-us/library/ff647543.aspxhttp://msdn.microsoft.com/fr-fr/magazine/cc188690(en-us).aspxhttp://msdn.microsoft.com/en-us/magazine/dd458800.aspx
119
Le modèle MVVM
! John Gossman (Microsoft), 2005! Lié à Silverlight et XAML! Model - View – ViewModelhttp://msdn.microsoft.com/en-us/magazine/dd419663.aspxhttp://msdn.microsoft.com/en-us/magazine/dd458800.aspx
120
ApplicationContrôle
Présentation
Le modèle SPA (Seeheim - PAC - Arche)
! T. Duval, 1992! Synthèse de Seeheim, PAC et Arche! Réparti à 6 composants par objet
121
Le modèle SPA (Seeheim - PAC - Arche)
! Présentation :" interaction physique avec l’utilisateur
! Contrôle :" cohérence application présentation" communication avec les autres objets du système
! Application :" application proprement dite, indépendante de l’IU
! Interfaces :" spécifications des autres composants :
• définissent des protocoles de communication :présentation ! contrôle ! application
" plus grande indépendance entre ces composants 122
SPA : l’interface application (1/2)
! Simple spécification du composant application
! D’avantage qu’une simple spécification :" application incomplète du point de vue de l’interface
utilisateur" application écrite dans un autre langage que celui utilisé
pour écrire le composant contrôle
123
Application
InterfaceApplication
Application
SPA : l’interface application (2/2)
124
SPA : l’interface présentation (1/2)
! Simple spécification du composant présentation
! D’avantage qu’une simple spécification :" langage utilisé pour la présentation différent de celui utilisé
pour le contrôle" personnalisation du composant présentation pour disposer
de primitives de présentation plus efficaces ou plus simples
125
PrésentationInterface
Présentation
Présentation
SPA : l’interface présentation (2/2)
126
SPA : 2 interprétations
! Raffinement de PAC :" composants spécifiés clairement" adapté pour construire objets et applications interactifs
! Arche distribué :" plus adaptée à la création d’applications interactives avec
la volonté de réutiliser des applications déjà existantes, qui peuvent être incomplètes, non interactives, …
" est à Arche ce que PAC est à Seeheim… ?
127
SPA : conclusion…
! Intérêt du modèle SPA :" 3 composants, spécifiés de façon précise " 3 composants à développer indépendamment" 3 composants à échanger facilement" importance renforcée du contrôle
128
Retour sur l’interface contrôle (1/2)
! Décomposable en trois parties : " interface pour l’application " interface pour la présentation " interface pour les contrôles des autres objets SPA
! Restriction exportation des primitives : " souhaitable car contexte bien précis " permet de régir de façon très stricte les échanges entre
composant
129
Contrôle
Retour sur l’interface contrôle (2/2)
130
Conclusion II : modèles d’architecture
! Une aide à la conception technique d’une IHM! Approche « génie logiciel » de la conception d’IHM! Peuvent garantir la séparation application ! IU
" cas des modèles de type Seeheim
! Sont parfois un peu abstrait, ou flous…" besoin d’être intégrés :
• à un outil• à une démarche méthodologique
! Utiliser les modèles les plus connus/reconnus :" PAC, PAC-Amodeus" MVC
131
III : Outils pour les IHM
! Expression des besoins" rôle des outils
! Catégories d’outils" outils de base" frameworks" environnements de haut niveau
132
Expression des besoins
! Faciliter le cycle de développement des IHM :" outils d’analyse et de spécification" outils de conception" outils d’implémentation" outils de test et d’intégration" outils de documentation et de maintenance
! Pour développer du logiciel de qualité :" centré sur l’utilisateur" respectant un modèle d’architecture logicielle
133
Pourquoi des outils ?
! Pour créer des IU de meilleure qualité :" avec moins de défauts de structuration
! Pour créer des IU plus efficaces :" en ayant essayé plusieurs styles d’interactions
! Pour créer des IU plus facilement :" voire automatiquement…
! Pour créer des IU plus rapidement :" dans un but de prototypage
! Pour créer des IU plus faciles à maintenir :" pour une meilleure évolution
134
Grâce aux outils…
! Prototypage et implémentation rapide de l’IU :" avant la réalisation totale de l’application" possibilité de tester différents styles d’interactions" incorporation de changements dus aux premières
utilisations" possibilité de proposer plusieurs IU pour une application,
destinées à différentes catégories d’utilisateurs
! Possibilité de laisser la charge de la conception de l’IU à des professionnels des IHM, qui ne sont pas informaticiens :" artistes, psychologues, ergonomes, …
! Cohérence des IU créées avec un même outil
135
Développement et maintenance…
! Code de l’IU mieux structuré et plus modulaire car séparé de l’application :" le concepteur d’interface peut changer l’IU sans affecter
l’application" le programmeur d’application peut changer l’application
sans affecter l’IU
! Représentation, validation et évaluation plus aisées des spécifications de l’IU
136
Que demander à un outil ?
! Fonctionnalité (ce qu’un outil permet de faire)" pour offrir la possibilité de créer des interfaces variées
! Utilisabilité (facilité d’utilisation)" pour donner satisfaction aux utilisateurs des outils
! Extensibilité" car { IU possibles } illimité
! Echappabilité" si outil inadéquat, réaliser l’IU par programmation
! Manipulation directe" pour utiliser l’outil plus facilement
! Intégration dans un environnement" un seul style d’interface pour l’accès à tous les outils
137
Différentes catégories d’outils
! Logiciels graphiques de base, systèmes de fenêtrage
environnements de développement d’interfaces (SGIU) :" interactifs, à manipulation d’objets de dialogue" à langage de spécification du dialogue" automatiques à partir de spécifications des fonctionnalités
d’une application138
Logiciels graphiques de base
! GKS, PHIGS, X-Lib...
! Bibliothèques couvrant tous les niveaux fonctionnels d’un logiciel interactif :" fenêtrage" affichage (dessin) " rares objets de présentation " rares objets de dialogue
! Habillages d’un logiciel graphique de base : " de niveau d’abstraction supérieur" souvent « orientés objet »" proposent de nombreux composants interactifs
! Utilisation :" appeler des primitives graphiques à partir de l’application
! Avantage :" très puissants, permettent de tout construire !
! Inconvénients :" utilisation très complexe ! (perte de temps)" il faut savoir programmer (le graphique !)" exclusion des experts en IHM non informaticiens" problèmes de portabilité d’une boîte à outils vers une autre
" pas de séparation formelle IU ! application" applications à contrôle interne
167
Applications extensibles
! Apex, MacApp…
! Squelettes d’applications qui assurent :" la gestion du dialogue" la présentation des objets de dialogue
! Construits au-dessus de boîtes à outils ou de bibliothèques graphiques
! De plus en plus rarement rencontrés telles-quelles
168
Applications extensibles
! Utilisation :" greffer les modules applicatifs" étendre éventuellement la présentation
! Création interactive de l’apparence de l’IU" définition de la présentation par « drag and drop »
! Edition des propriétés des composants de dialogue" inspecteurs (Ilog)" éditeurs de propriétés de widgets (UIM/X)" ...
! Intégration des objets de l’application :" par programmation" en créant de nouveaux objets d’interface (Widget Factory)" en intégrant des bibliothèques d’objets (IlogViews)" ...
180
Générateurs : le squelette produit
! C ou C++, Motif et X" UIM/X, XFaceMaker, IlogBuilder, ...
! C et OpenWindow ou Xview" DevGuide
! Lisp et Aïda" Masaï
! C++ et X ou Windows" IlogViews
! Java et Swing" Forte4j, NetBeans, IlogJViews, JBuilder
181
Générateurs : l’application
! Ajouter les appels aux fonctionnalités de l’application dans le squelette généré :" modifier directement le squelette (DevGuide) :
• en cas de reprise de l’IHM par le générateur, tout le travail est à refaire…
" insérer les fonctionnalités à l’aide d’outils fournis par le générateur (Ilog, UIM/X) :
• en cas de reprise de l’IHM par le générateur, tout est récupéré
! Langages de développement recommandés :" LISP, FORTRAN, C (Masaï)" C, C++ (IlogBuilder, UIM/X, XFaceMaker, …)" Java (IlogJViews, NetBeans, …)
182
Générateurs : le contrôle (1/2)
! Non traité par les premiers générateurs…
! Programmer directement à l’aide du langage de la boîte à outils sous-jacente :" pour obtenir du dialogue avec rétroaction sémantique" pour avoir un comportement dynamique de l’IU
183
Générateurs : le contrôle (2/2)
! Nouvelles possibilités offertes :" définition de nouveaux objets de dialogue, avec un
comportement propre (Widget Factory)" définition de méthodes associées aux objets de dialogue,
création d’objets (héritage, composition (UIM/X)" association de comportements à des objets existants (Ilog)" description de règles d’enchaînement entre des écrans
statiques, interactivement ou par programmation (Masaï)" spécification interactive d’envois de messages entre objets
pour les activer, les inhiber (devGuide)" association interactive d’objets de dialogue, de variables
(Interface Builder, vrStudio)184
Avantages des générateurs
! Faciles à utiliser (applications conversationnelles)
! IU faciles à modifier
! Obtention rapide de prototypes
! Interfaces qui se ressemblent (cohérence)
! Excellent rapport gains / prix
185
Inconvénients des générateurs
! Interfaces qui se ressemblent (originalité ?)
! Statiques :" permettent rarement (sans aucune programmation) de
définir des objets de dialogue qui évoluent dynamiquement au cour de la manipulation de l’IU
! Ne permettent pas encore tout à fait de visualiser facilement les objets complexes des applications (pour applications à manipulation directe)
! Il faut encore connaître les mécanismes de la boîte àoutils sous-jacente… 186
Entier borné avec NetBeans
! Dessin de l’interface avec l’éditeur :" beaucoup de code « laborieux » généré automatiquement
! Structuration PAC manuelle :" 3 classes Abstraction, Présentation et Contrôle" mise en place d’un protocole de communication entre
composants" besoin de connaître les mécanismes Swing
187
AbstractionEBI.java (1/2)
public class AbstractionEBI {
protected int minimum, valeur, maximum ;
public AbstractionEBI (int min, int val, int max) {if ((min <= val) && (val <= max)) {
minimum = min ;valeur = val ;maximum = max ;
} else {minimum = 0 ;valeur = 12 ;maximum = 20 ;
}}
public int getValeur () {return valeur ;
}
188
AbstractionEBI.java (2/2)
public boolean isIncrémentable () {return (valeur < maximum) ;
}
public void incrémenter () {if (isIncrémentable ()) {
valeur ++ ;}
}
public boolean isDécrémentable () {return (valeur > minimum) ;
}
public void décrémenter () {if (isDécrémentable ()) {
private javax.swing.JLabel afficheur ;private javax.swing.JButton moins ;private javax.swing.JButton plus ;
private void initComponents () {moins = new javax.swing.JButton () ;afficheur = new javax.swing.JLabel () ;plus = new javax.swing.JButton () ;
moins.setText ("Moins") ;moins.setToolTipText ("décrémente la valeur") ;moins.setPreferredSize (new java.awt.Dimension (75, 25)) ;moins.addActionListener (new java.awt.event.ActionListener () {
public void actionPerformed (java.awt.event.ActionEvent evt) {moinsActionPerformed (evt) ;
}}) ;
add (moins) ;
191
PrésentationEBI.java (3/4)
afficheur.setBackground (new java.awt.Color (204, 255, 255)) ;afficheur.setToolTipText ("affichage de la valeur") ;afficheur.setHorizontalTextPosition (javax.swing.SwingConstants.RIGHT) ;afficheur.setName ("afficheur") ;afficheur.setPreferredSize (new java.awt.Dimension(30, 25)) ;
add (afficheur) ;
plus.setText ("Plus") ;plus.setToolTipText ("incrémente la valeur") ;plus.setPreferredSize (new java.awt.Dimension(75, 25)) ;plus.addActionListener (new java.awt.event.ActionListener () {
public void actionPerformed (java.awt.event.ActionEvent evt) {plusActionPerformed (evt) ;
}}) ;
add (plus) ;}
192
PrésentationEBI.java (4/4)
public void setActionIncrémenter (ContrôleEBI.ActionIncrémenter i) {incrémenter = i ;
}
public void setActionDécrémenter (ContrôleEBI.ActionDécrémenter d) {décrémenter = d ;
}
public void activerActionIncrémenter (boolean state) {plus.setEnabled (state) ;
}
public void activerActionDécrémenter (boolean state) {moins.setEnabled (state) ;
}
public void setValeur (int valeur) {afficheur.setText ("" + valeur) ;
public ContrôleEBI (int min, int val, int max) {abstraction = new AbstractionEBI (min, val, max) ;présentation = new PrésentationEBI () ;présentation.setActionIncrémenter (new ActionIncrémenter ()) ;présentation.setActionDécrémenter (new ActionDécrémenter ()) ; mettreAJourPrésentation () ;
public static void main (String args []) {java.awt.EventQueue.invokeLater (new Runnable () {
public void run () {new EBI ().setVisible (true) ;
}});
}
}
197
Constructeurs à langage de spécification (1/2)
! Produits universitaires et commercialisés" Serpent, Aïda, Humanoïd, …
! S’appuient en général sur un environnement de développement de style boîte à outils
! Définition de la présentation de l’interface utilisateur! Expression de certaines contraintes géométriques
dynamiques entre les objets de présentation! Langage spécialisé de description du contrôle du
dialogue, permet de distinguer la nature des objets de présentation de leurs relations dynamiques
198
Constructeurs à langage de spécification (2/2)
! Avantages :" plus simples à utiliser que les boîtes à outils" fournissent des abstractions qui facilitent la spécification
des connexions entre les objets graphiques et les structures de données de l’application
! Inconvénients :" lien application ! IU parfois très fort" langage de spécification (C, LISP, …)" limités par les objets de présentation disponibles" pouvoir d’expression limité
! Génèrent des interfaces utilisateur pour des applications à base de commandes (conversationnelles) :" à partir de la spécification de l’interface avec l’application" créent présentation et contrôle du dialogue
! Présentation prête à l’emploi et cohérente! Heuristiques ergonomiques câblées dans le
générateur! Reste à programmer l’application proprement dite
200
Constructeurs automatiques (2/2)
! Avantages :" interface utilisateur obtenue automatiquement : il suffit de
se plier à des règles et le générateur produit l’application" interfaces qui se ressemblent (cohérence)
! Inconvénients :" interfaces qui se ressemblent (originalité ?)" mauvaise finition des interfaces utilisateur produites" très difficile de faire évoluer ces interfaces" limités à des dispositifs physiques particuliers, à un seul
style d’interaction" limités à certaines classes d’applications : manquent de
généralité
201
Conclusion III : outils pour les IHM
! Les outils sont encore loin d’être parfaits :" ne couvrent pas toutes les phases du cycle de vie
• souvent seulement l’implémentation
" obligent à recourir à de la programmation• pour obtenir des interfaces dynamiques• pour visualiser ses propres structures de données
" sont souvent très coûteux :• " 12 k€ pour un produit commercial
! Mais possèdent des caractéristiques intéressantes :" bon rapport gain/prix
! Il faut les utiliser à bon escient…
202
IV : Conception centrée sur l’utilisateur
! Pour obtenir un dialogue de qualité, il faut prendre en compte les utilisateurs :" dès l’analyse des besoins" dès la spécification des IHM
! Il faut alors :" essayer de modéliser l’interaction homme-machine…
• modéliser le comportement de l’usager• modéliser ses buts (les tâches à remplir)• modéliser son activité
" essayer de suivre des règles d’ergonomie…
203
Spécification d’IHM
! Spécification :" de ce que l’on doit trouver dans les applications
interactives" de comment il faut concevoir les applications interactives" de comment il faut construire les applications interactives
! Recommandations ergonomiques :" normes AFNOR…
! Aides à la construction des IHM :" guides de style" psychologie cognitive
204
Limitation des outils dédiés aux IHM
! 3 points de vue possibles sur un système interactif :" celui de l’utilisateur du système" celui du programmeur du système" celui du concepteur (ou analyste) du système
" prendre en compte les caractéristiques des utilisateurs :• leurs besoins• leurs capacités physiologiques• leurs capacités sensorielles• leurs capacités cognitives
! Quand ?" dès la phase de conception du dialogue
! En résumé :" il faut adapter le dialogue à l’usager ! Et non le contraire !!!
! Pour dimensionner les systèmes interactifs :" GOMS (Goals, Operators, Models, Selection rules), Card,
Moran, Newell, 1983• pour hiérarchiser des tâches simples
" Keystroke (en association avec GOMS…)• pour prédire les performances dans l’exécution de tâches
élémentaires et répétitives
" CLG…
213
Approche orientée scénarios
! Utilisation de scénarios :" entre concepteurs et usagers" pour expliciter la façon dont sera utilisé le logiciel" en sessions de travail avec plusieurs usagers" individuellement
! Pour répondre à des questions :" quels dispositifs d’interaction doivent être créés ?" comment seront-ils utilisés ?" ...
214
Questions à poser…
! Pour expliciter :" ce que les concepteurs comprennent des tâches de
l’utilisateur" comment ils pensent aider à les réaliser" la façon dont ils envisagent la réalisation du système
! Tirées d’un procédé de construction d’aide en ligne :" quels sont les problèmes et besoins de l’utilisateur ?" quelles sont les meilleures solutions pour résoudre ces
problèmes et ces besoins ?" comment les rendre disponibles et opérationnelles ?
215
Définition des problèmes et besoins
! Quels sont les problèmes et besoins de l’utilisateur ?" quel est le domaine d’application ?" quelle est la nature du travail dans ce domaine ?" qui sont les acteurs ?" quel rôle jouent-ils ?" quelles tâches doivent-ils réaliser ?
216
Définition des solutions
! Quelles sont les meilleures solutions pour résoudre ces problèmes et ces besoins ?" quelle est l’application ?" comment cette technologie va-t-elle affecter le domaine ?" qu’est-il possible de faire avec cela ? (dans quels buts)" à quoi l’application peut-elle être utile ?" quels sont les avantages de cette application ?" quel environnement informatique est-il envisagé pour le
déploiement de cette application ?" que doit savoir l’utilisateur afin de pouvoir l’utiliser ?" quelles activités peut-on mener dans cet environnement ?" quelles sont les options disponibles dans cette version ?
217
Définition de leur mise en œuvre
! Comment les rendre disponibles et opérationnelles ?" quelle analogie de base utilise-t-on pour l’interaction ?" comment et quand peut-on réaliser des actions ?" où se trouvent les actions dans l’application ?" comment refaire ou défaire une (partie de) tâche ?" quels sont les pré-requis pour effectuer une tâche ?" qui est ou n’est pas affecté par une tâche ?" que fait-on après avoir réalisé une tâche ?" comment sait-on qu’une tâche est réalisée avec succès ?
218
Guides de style
! Énumérations de techniques de dialogue sans référence à leur mise en œuvre par rapport à des critères ergonomiques :" leur utilisation ne garantit pas l’adéquation du logiciel aux
caractéristiques de l’utilisateur et aux besoins de sa tâche" ils ne permettent pas au concepteur d’effectuer des choix
! Norme AFNOR Z67-110, Janvier 1988" Traitement de l’information" Ergonomie et conception du dialogue homme-ordinateur" Concepts généraux
! Norme AFNOR Z67-133-1, Décembre 1991" Traitement de l’information" Évaluation des produits logiciels" Partie 1 : définition des critères ergonomiques de
conception et d’évaluation des interfaces utilisateurs
220
Norme AFNOR Z67-110
! Des recommandations générales concernant la qualité des IHM :" structuration du dialogue" commandes et validation" enchaînements" temps de réponse" structuration des écrans" messages d’erreur, aide" densité de visualisation" attributs de visualisation" style et codage
221
Structuration du dialogue (1/3)
! But :" minimiser le temps d’apprentissage en facilitant le
cheminement de l’utilisateur dans le dialogue
! On doit pouvoir accéder à l’information rapidement
! Différences selon le type de l’utilisateur :" novice : dispositif de guidage" expert : raccourcis
222
Structuration du dialogue (2/3)
! Présentation des informations :" si les informations à saisir arrivent toujours dans le même
ordre, le dialogue doit respecter cet ordre" sinon, le dialogue doit laisser l’initiative de l’ordre d’entrée
des informations à l’utilisateur : l’utilisateur doit être situépar rapport à sa tâche
! Enchaînement des opérations :" tâche = ensemble de sous-tâches" si ces sous-tâches doivent suivre un certain ordre, le
dialogue doit le respecter" sinon, il doit permettre à l’utilisateur de réaliser ces sous-
tâches comme il l’entend
223
Structuration du dialogue (3/3)
224
Commandes et validation (1/5)
! But :" adapter les fonctions d’un système à la tâche à réaliser et
au propre rythme de l’utilisateur
! Le langage de commandes :" doit comporter un guidage" doit posséder une aide complète pour chaque commande" doit être concis et précis plutôt que naturel et ambigu" doit être aussi précis que possible" doit regrouper les commandes par groupes cohérents de
fonctions et par niveau de complexité" doit proposer une syntaxe cohérente
225
Commandes et validation (2/5)
! Le mode d’utilisation :" localisation des commandes identique pour chaque page
d’écran" séquences de commandes dictées par l’utilisateur et non
imposées par le système" ne pas changer l’intitulé des commandes au cours d’une
tâche" actions fréquentes faciles à exécuter (raccourcis)" actions destructives nécessitent une confirmation" pouvoir répéter (again) et annuler (undo) une action" système réactif à toute commande (exécution + compte-
rendu)226
Commandes et validation (3/5)
! Intérêt des touches de fonction :" si le nombre de choix possible est très réduit" pour cheminer dans le dialogue (retour au menu initial ou à
l’écran précédent, raccourci, abandon)" pour appeler de l’aide contextuelle" pour valider, confirmer, annuler" pour des commandes fréquemment utilisées
227
Commandes et validation (4/5)
! Utilisation des touches de fonction :" elles doivent être assignées de façon cohérente tout au
long du dialogue" les fonctions inutiles ou inutilisables doivent être
désactivées ou rendues indisponibles" la signification des touches doit être précisée" l’action sur une touche doit faire l’objet d’un retour
d’information" les touches de fonction doivent être faciles d’accès
228
Commandes et validation (5/5)
229
Enchaînements (1/2)
! But :" faciliter l’accès à une tâche et le passage d’un écran à un
autre à l’intérieur d’une tâche
! Types d’enchaînement en fonction de la tâche :" l’enchaînement des écrans doit refléter la pratique de
l’utilisateur" il faut éviter de découper des tâches simples
! Possibilités d’enchaînements :" par choix d’une option dans un menu" par action sur une touche de fonction" l’utilisateur doit toujours pouvoir revenir à l’état précédent
230
Enchaînements (2/2)
231
Temps de réponse
! But :" permettre aux utilisateurs de réguler une séquence de
travail
! Les temps de réponse :" doivent être les plus courts possibles (<= 4s)" si (>= 4s), il faut afficher un message, renouvelé toutes les
10s" doivent être stables et identiques pour des actions
identiques de l’utilisateur
232
Structuration des écrans (1/3)
! But :" faciliter la localisation de l’information par l’utilisateur
! Structuration spatiale, différentes zones possibles :" zone de travail (saisie)" zone de préparation des données" zone de diagnostic (messages)" zone de proposition de choix (menus)" zone de commandes
! Ce choix de découpage en zones est fonction de l’application, mais doit rester constant dans l’ensemble de l’application
233
Structuration des écrans (2/3)
! Organisation :" l’organisation des informations sur l’écran doit respecter
l’ordre dans lequel l’utilisateur a besoin de ces informations" il ne faut pas afficher ensemble des informations sans
rapports" il faut respecter les relations sémantiques entre les
données
234
Structuration des écrans (3/3)
! Typographie :" il faut structurer l’information" il faut la rendre lisible (minuscules accentuées)" il faut choisir un mode de représentation adapté (tableaux,
schémas si traitement complexe, phrases courtes si traitements simples)
235
Messages d’erreur, aide (1/3)
! But :" informer l’utilisateur sur l’état du système et l’orienter vers
une action correctrice qui soit efficace
236
Messages d’erreur, aide (2/3)
! Les messages d’erreur doivent :" être concis et précis" être compréhensibles par l’utilisateur" indiquer le lieu, la cause, et comment corriger l’erreur" être interruptibles" apparaître dans une zone fixe prévue à cet effet" permettre le positionnement automatique sur l’erreur
! Les messages d’erreur peuvent :" être mis en valeur à l’aide d’attributs de visualisation" parfois renvoyer à une documentation complémentaire
237
Messages d’erreur, aide (3/3)
238
Densité de visualisation (1/2)
! But :" faciliter la prise d’information par l’utilisateur sur la page
d’écran
! Conseils :" limiter les informations présentes aux seules informations
utiles à l’utilisateur" trouver un compromis entre un faible nombre de pages
écran et une faible densité d’informations par page :• ce compromis est fonction des exigences de la tâche à remplir par
l’utilisateur
239
Densité de visualisation (2/2)
240
Attributs de visualisation (1/3)
! Buts :" faciliter le repérage de l’information par l’utilisateur
" les codes de couleur peuvent être liés à la tâche" éviter les couleurs trop vives, saturées :
• saturation visuelle trop importante
" éviter le bleu et le rouge pour l’affichage du texte
242
Attributs de visualisation (3/3)
! Autres :" pas plus de 2 valeurs différentes d’intensité lumineuse" éviter le clignotement, surtout si l’utilisateur ne peut pas
l’arrêter" utiliser l’inverse vidéo pour des messages d’erreur ou
d’alerte, mais seulement pour des petites surfaces" utiliser des lignes ou des cadres pour séparer des zones
distinctes en cas d’écran saturé" ne pas utiliser plus de 2 attributs de visualisation à la fois :
• risque de saturation• visibilité moindre
243
Style et codage (1/4)
! But :" rendre les informations présentées directement intelligibles
par l’utilisateur
! L’écran ne doit contenir que les informations utiles àla réalisation de la tâche…
244
Style et codage (2/4)
! Termes :" utiliser les termes habituels de l’utilisateur" les termes nouveaux pour l’utilisateur doivent :
• être significatifs• être non ambigus
" il faut éviter :• les mots pouvant avoir plusieurs sens (éditer, modifier)• l’emploi de synonymes (gommer, effacer)• les racines communes (copier, couper, coller)• de donner un sens différent de celui que connaît l’utilisateur
" proches des verbes (orientés actions) pour des fonctions" proches des substantifs pour des rubriques (titres)
245
Style et codage (3/4)
! Abréviations :" doivent permettre une reconstitution spontanée du mot
entier" préférer les contractions pour les mots courts
• Omission des lettres internes
" préférer les troncatures pour les mots longs• Omission des lettres finales
" un code mnémonique est meilleur qu’un code numérique" un code numérique est meilleur qu’un code
alphanumérique
246
Style et codage (4/4)
247
Norme AFNOR Z67-133-1
! Une étude de la facilité d’utilisation des IHM en 7 critères :" compatibilité" guidage" homogénéité" souplesse" contrôle explicite" gestion des erreurs" concision
! Ces critères permettent d’estimer une notion très importante pour la conception : la charge de travail
248
Charge de travail
! Représente l’ensemble des sollicitations des capacités :" de perception" de mémorisation" de traitement de l’information
d’un utilisateur pendant qu’il effectue son travail! Surcharge :
" les activités mentales de l’utilisateur sont sur-utilisées
! Sous-charge :" les activités mentales de l’utilisateur sont sous-utilisées
249
Prise en compte de la charge de travail
! Pour optimiser la prise de décision de l’utilisateur en lui présentant l’information la plus brève et la moins ambiguë possible
! Pour minimiser le nombre d’actions ou d’opérations à effectuer ainsi que le temps de manipulation
! L’optimisation de la charge de travail concourt àl’augmentation de l’efficacité du dialogue
250
Compatibilité (1/5)
! Capacité du logiciel à s’intégrer dans l’activité des utilisateurs
! Prend en compte :" les concepts" les informations" les représentations" les procédures
Qui font partie de l’univers de travail réel de l’utilisateur et de sa culture (professionnelle et personnelle)
251
Compatibilité (2/5)
! Il faut étudier l’univers de l’utilisateur :" la représentation qu’ils ont de leurs tâches" leurs habitudes de travail (procédures et vocabulaire)" leurs connaissances des systèmes informatiques
! Pour concevoir l’interface :" structurer et organiser les fonctionnalités (entrées et
sorties)" définir les procédures d’utilisation" définir le traitement des informations" définir la navigation dans l’application
252
Compatibilité (3/5)
! Objectifs :" établir la correspondance entre les connaissances, les
besoins des utilisateurs et les possibilités offertes par le logiciel
" permettre à l’utilisateur de retrouver un univers familier et habituel
" faciliter l’apprentissage" rendre efficace la communication homme-machine" rendre l’information directement utilisable
253
Compatibilité (4/5)
! Exemples :" procédures d’utilisation conformes à la logique de
l’utilisateur" organisation des fonctions conforme à la représentation de
la tâche" ordre des items lié à la tâche" valeurs par défaut" vocabulaire et codes repris de l’univers du travail
254
Compatibilité (5/5)
255
Guidage (1/4)
! C’est l’ensemble des moyens mis à disposition de l’utilisateur qui lui permettent :" de connaître l’état du système informatique" d’établir les liens de causalité entre ses actions et l’état du
système" d’évaluer et d’orienter son action sur le système
informatique
! Explicite : présenté formellement , à la demande de l’utilisateur
! Implicite : relève de la présentation et de l’organisation des informations affichées
256
Guidage (2/4)
! Objectifs :" faciliter l’apprentissage" aider l’utilisateur à se repérer" aider l’utilisateur à choisir ses actions" prévenir les erreurs
" guidage implicite :• structuration de l’affichage• format adéquat pour les entrées
258
Guidage (4/4)
259
Homogénéité (1/3)
! C’est la capacité d’un système informatique àconserver une logique d’usage constante dans une application ou d’une application à l’autre, tant au niveau des procédures qu’au niveau de la présentation des informations
! Objectifs :" rendre le comportement du système (donc son utilisation)
prévisible par l’utilisateur" diminuer le temps de recherche d’une information" faciliter la prise d’information
260
Homogénéité (2/3)
! Exemples :" attributs de visualisation" stabilité de la présentation des informations" un seul endroit pour l’affichage d’une même information" un seul nom pour une seule fonction" une même procédure conduit toujours au même résultat" respect de standards de présentation
261
Homogénéité (3/3)
262
Souplesse (1/3)
! C’est la capacité de l’interface à s’adapter aux différentes exigences de la tâche, aux diverses stratégies, aux habitudes et niveaux de connaissances des différents utilisateurs
! Distinguer la souplesse :" de fonctionnement, qui correspond à la capacité
d’adaptation du logiciel à diverses populations différentiables selon leur niveau d’expérience
" d’utilisation qui correspond au nombre de procédures, options et commandes différentes mises à la disposition de l’utilisateur pour atteindre un même objectif
263
Souplesse (2/3)
! Objectifs :" s’adapter à la diversité des utilisateurs" permettre à l’utilisateur d’obtenir un résultat identique par
plusieurs procédures
! Exemples :" mode débutant = guidage renforcé" mode expert = procédures raccourcies" possibilité de paramétrer ou de chaîner des commandes
fréquemment utilisées" paramétrage des ressources (couleurs, son, vitesse de
souris, …)" accélérateurs 264
Souplesse (3/3)
265
Contrôle explicite (1/3)
! C’est l’ensemble des moyens du dialogue qui permettent à l’utilisateur de maîtriser le lancement et le déroulement des opérations exécutées par le système informatique
! Cela implique :" la sémantique des commandes rende bien compte de
leurs effets" les effets de la commande soient entièrement prévisibles
par l’utilisateur
266
Contrôle explicite (2/3)
! Objectifs :" respecter l’autonomie de l’utilisateur dans ses interactions
avec le système informatique" favoriser la prévision des réactions de l’interface" favoriser l’apprentissage" diminuer les risques d’erreurs
! Exemples :" prévoir une action explicite de validation" signaler les options actives dans les menus" boîtes de messages" pouvoir interrompre une impression
267
Contrôle explicite (3/3)
268
Gestion des erreurs (1/4)
! C’est l’ensemble des moyens destinés à :" aider, guider l’utilisateur dans l’identification et la correction
de ses erreurs" conserver l’intégrité de l’application (éviter l’altération des
données et des traitements)
269
Gestion des erreurs (2/4)
! Objectifs :" rassurer l’utilisateur" éviter les perturbations (blocage, anxiété, …) associées à
la difficulté de corriger des erreurs commises" favoriser l’exploration et l’apprentissage par un système
tolérant à divers modes de saisie, tolérant à des changements de décision de l’utilisateur, …
" permettre à l’utilisateur de localiser précisément l’erreur, d’en comprendre la nature et de disposer immédiatement des moyens de la corriger
270
Gestion des erreurs (3/4)
! Exemples :" annulation des effets de la dernière commande (undo)" messages d’erreur" clarté du codage utilisé pour les messages d’erreurs" désactiver l’effet d’une fonction non utilisable dans le
contexte de l’application" aperçu avant impression
271
Gestion des erreurs (4/4)
272
Concision (1/3)
! C’est l’ensemble des moyens qui, pour l’utilisateur, contribuent à la réduction de ses activités de perception et de mémorisation et concourent àl’augmentation de l’efficacité du dialogue
! Objectifs :" optimiser la prise d’information et de décision de
l’utilisateur en lui présentant l’information la plus brève et la moins ambiguë possible
" minimiser le nombre d’actions ou d’opérations à effectuer ainsi que le temps de manipulation
273
Concision (2/3)
! Exemples :" accélérateurs" options par défaut" icônes" structuration de l’affichage
274
Concision (3/3)
275
Conclusion sur ces recommandations
! Que faut-il faire ?" mettre en œuvre ces recommandations…
! Toujours ?" …peut provoquer des conflits de faisabilité
! Et alors ?" il faut trouver le meilleur compromis possible entre :
• les exigences du système• les exigences de la tâche• les exigences de l’utilisateur
276
Conclusion IV : et les utilisateurs ?
! Une bonne réalisation passe par la prise en compte du travail effectif (travail de l’utilisateur) au cours des différentes étapes de la conception du logiciel
! Ne pas hésiter à utiliser des outils pour formaliser" UML…
! Suivre les recommandations ergonomiques
! Prototyper itérativement en incluant l’utilisateur dans la boucle
277
Conclusion générale
! Il ne reste plus qu’à s’y mettre…
278
Bibliographie
! Coutaz J. “Interfaces homme-ordinateur, conception et réalisation”. Dunodinformatique, 1990.
! Coutaz J., Nigay L. “Seeheim et architecture multi-agent”. IHM 1992.! Duval T. “Construction des interfaces homme-machine : modèles et
outils”. Thèse de doctorat de l’ECN, 1993.! Duval T. “Modèles d’architecture pour les applications interactives : la
famille Seeheim”. Revue de CFAO et d’infographie, 1994.! Nigay L., Coutaz J. “Interfaces multimodales et architecture : fusion et
parallélisme”. IHM 1993.! Paris C., Tarby J.C., Vander Linden K. “A Flexible Methodology and
Support Environnment for Building Task Models”. IHM-HCI 2001.! Selbach Silvera M., Barbosa S., Sieckenius de Souza C. “Augmenting the
Affordance of Online Help Content”. IHM-HCI 2001.! Turner P., Turner S., MacCall R. “Getting the Story Straight”. IHM-HCI