Upload
vudiep
View
234
Download
4
Embed Size (px)
Citation preview
Construction des IHMSpécification - Modèles - OutilsPrise en compte des utilisateurs
GLI – Master 2 Informatique GL, Mitic et MiageIHM – ESIR 2 LSI
Thierry DuvalISTIC / IRISA - Bunraku
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 dialogue4
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
9
Validation
Conceptiongénérale
Tests d’intégration
Conceptiondétaillée
Implémentation
Tests unitaires
AnalyseSpécification
Rappel : cycle en V
10
Approche itérative : cycle en spiraleAnalyse détaillée
Réalisation
Conception
Intégration
Validation
Analysepréliminaire
V1 V2
11
Types d’applications interactives
! Applications conversationnelles
! Applications conversationnelles textuelles
! Applications conversationnelles étendues
! Applications à manipulations limitées
! Applications à manipulations directes
12
Applications conversationnelles
! Interaction = dialogue « civilisé »
! Succession d’échanges
! Réponses = répercussions pour l’utilisateur
! Textuelles : indication textuelle des commandes• barbux[17:53]%find . -name ihmsmo.sdd -print• ./tex/cours/ifsic/ihm/ihmsmo.sdd• barbux[17:53]%
! Etendues : utilisation d’objets de dialogue
13 14
15
Applications à manipulations limitées
! 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
• conception• implémentation, test, validation• documentation
27
Séparation application / dialogue
! Conseil prôné par tous les spécialistes en IHM :" il faut séparer :
• application proprement dite• dialogue avec l’utilisateur
" application proprement dite = application globale privée de toute la communication avec l’utilisateur
" dialogue avec l’utilisateur = IHM, IU
28
Cas des grosses applications
! Problèmes :" flexibilité" maintenance" adaptabilité
! Absence de séparation application / dialogue :" on ne s’en sort pas !" demande de nombreuses compétences…
! Séparation :" permet de répartir les tâches entre :
• concepteurs/développeurs d’applications• concepteurs/développeurs d’IHM
29
Mise au point itérative
! 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
! Exemple : entier borné entre 0 et 20
53
2
1
EntierBornévaleur : entierminimum : entiermaximum : entierboutonPlus : BoutonboutonMoins : Bouton
incrémenterdécrémenterautoIncrémenter : booléenautoDécrémenter : booléentraiterBouton (b : Bouton)
Boutonactif : booléenresponsable : EntierBorné
traiterDésignationactiverdésactiver
Construction globale
54
Construction d’un bouton
! 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
66
1
1PrésentationboutonPlusActif : booléenboutonMoinsActif : booléencontrôle : Contrôle
traiterDésignationactiverBoutonPlusdésactiverBoutonPlusdessinerPlusActifdessinerPlusInactifclignoterPlusactiverBoutonMoinsdésactiverBoutonMoinsdessinerMoinsActifdessinerMoinsInactifclignoterMoins
Contrôle
incrémenterdécrémenterautoIncrémenter : booléenautoDécrémenter : booléentraiterBoutonPlustraiterBoutonMoinsvaleur : entier
présentation : PrésentationinterfaceApplication : InterfaceApplication
Applicationvaleur : entierminimum : entiermaximum : entier
incrémenterdécrémenter
1
Interface Applicationapplication : Application
incrémenterautoIncrémenter : booléendécrémenterautoDécrémenter : booléenvaleur : entier
1
1
1
1
Seeheim et l’entier borné (3/3)
67
Seeheim : la présentation (1/3)
composant Présentation
boutonPlusActif, boutonMoinsActif : booléen
contrôle : Contrôle
activerBoutonPlusdébut
si (non boutonPlusActif) alorsdessinerPlusActifboutonPlusActif <- vrai
fin sifin
activerBoutonMoins …
68
Seeheim : la présentation (2/3)
désactiverBoutonPlus …
désactiverBoutonMoins …
dessinerPlusActif …
dessinerMoinsActif …
dessinerPlusInactif …
dessinerMoinsInactif …
clignoterPlus …
clignoterMoins …
69
Seeheim : la présentation (3/3)
traiterDésignationdébut
si (la désignation concerne le bouton plus) alorssi (boutonPlusActif) alors
clignoterPluscontrôle.traiterBoutonPlus
fin sisinon si (elle concerne le bouton moins) alors
si (boutonMoinsActif) alorsclignoterMoinscontrôle.traiterBoutonMoins
fin sifin si
fin
fin composant70
Seeheim : l’application
composant application
valeur, maximum, minimum : entier
incrémenterdébut
valeur <- valeur + 1fin
décrémenter …
fin composant
71
Seeheim : l’interface application (1/2)
Composant interfaceApplication
application : Application
incrémenterdébut
application.incrémenterfin
autoIncrémenter : booléendébut
retourne (valeur < application.maximum)fin
72
Seeheim : l’interface application (2/2)
valeur : entierdébut
retourne application.valeurfin
décrémenter …
autoDécrémenter …
fin composant
73
Seeheim : le contrôle (1/3)
composant Contrôle
interfaceApplication : InterfaceApplicationprésentation : Présentation
autoIncrémenter : booléendébut
retourne interfaceApplication.autoIncrémenterfin
autoDécrémenter : booléen …
74
Seeheim : le contrôle (2/3)
incrémenterdébut
si (autoIncrementer) alorssi (non autoDécrémenter) alors
présentation.activerBoutonMoinsfin siinterfaceApplication.incrémentersi (non autoIncrémenter) alors
présentation.désactiverBoutonPlusfin siprésentation.afficher (valeur)
fin sifin
décrémenter …
75
Seeheim : le contrôle (3/3)
traiterBoutonPlusdébut
incrémenterfin
traiterBoutonMoins …
valeur : entierdébut
retourne interfaceApplication.valeurfin
fin composant
76
Gestionnairede dialogue
Le Modèle Seeheim modifié (1/2)
! Groupe de travail sur les supports d’exécution, 1987! Pour plus de rétroaction sémantique! S’inspire du modèle Seeheim! 4 composants
Agent de la station de travail
Supportsémantique
Utilisateur
Application
77
Le Modèle Seeheim modifié (2/2)
! Agent de la station de travail :" rôle de présentation (utilise une boîte à outils)" gère les aspects physiques de l’interaction
! Gestionnaire de dialogue :" haut niveau d’abstraction pour les services d’interaction" indépendant de l’application et des dispositifs physiques
! Support sémantique :" interface avec l’application, sémantique incorporée à l’IU" rétroaction, visualisation, récupération d’erreurs
! Application :" ce qui n’a pas besoin de connaître l’IU et réciproquement
78
Le modèle Arche (1/3)
! Séminaire de développeurs de SGIU, 1991
! 5 composants, symétrise Seeheim
! Justifie Motif…
! Méta-modèle ?
! « Slinky »…
79
Domaine
Adaptateur deDomaine
Dialogue
Présentation
Boîte à Outils
Le modèle Arche (2/3)
80
Le modèle Arche (3/3)
! Domaine :" application indépendante de l’IU
! Adaptateur de domaine :" intermédiaire entre domaine et dialogue
! Dialogue :" séquencement des tâches de l’opérateur
" cohérence entre formalismes domaine ! IU
! Présentation :" { objets logiques }, intermédiaire dialogue ! boîte à outils
! 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
85
Structure PAC du bouton
1 ContrôleBoutonresponsable :ContrôleEntierBorné
présentation :PrésentationBouton
abstraction :AbstractionBouton
traiterDésignationactiverdésactiver
AbstractionBoutonactif : booléen
activerdésactiver
PrésentationBouton
traiterDésignationdessinerActifdessinerInactifclignoter
contrôle :ContrôleBouton
1
1
1
86
PAC : présentation du bouton
composant PrésentationBouton
contrôle : ContrôleBouton
traiterDésignationdébut
contrôle.traiterDésignationfin
clignoter …
dessinerActif …
dessinerInactif …
fin composant
87
PAC : abstraction du bouton
composant AbstractionBouton
actif : booléen
désactiverdébut
actif <- fauxfin
activer …
fin composant
88
PAC : contrôle du bouton (1/2)
composant ContrôleBouton
responsable : ContrôleEntierBorné
abstraction : AbstractionBouton
présentation : PrésentationBouton
traiterDésignationdébut
si (abstraction.actif) alorsprésentation.clignoterresponsable.traiterBouton (moi)
fin sifin
89
PAC : contrôle du bouton (2/2)
activerdébut
si (non abstraction.actif) alorsabstraction.activersi (abstraction.actif) alors
présentation.dessinerActiffin si
fin sifin
désactiver …
fin composant
90
PAC et l’entier borné
! Présentation :" visualisation de la valeur
! Abstraction :" attributs et fonctionnalités (+ pré-conditions) de
l’application
! Contrôle :" gestion des événements logiques en provenance des
boutons
91
Structure PAC de l’entier borné
11
ContrôleEntierBornéboutonPlus : ContrôleBoutonboutonMoins : ContrôleBoutonprésentation : PrésentationEntierBornéabstraction : AbstractionEntierBorné
valeur : entierincrémenterdécrémenterautoIncrémenter : booléenautoDécrémenter : booléentraiterBouton (b : ContrôleBouton)
AbstractionEntierBornévaleur : entierminimum : entiermaximum : entier
incrémenterdécrémenterautoIncrémenter : booléenautoDécrémenter : booléen
PrésentationEntierBorné
afficher (v : entier)
1
1
92
PAC : présentation de l’entier borné
composant PrésentationEntierBorné
afficherValeur (uneValeur : entier) …
fin composant
93
PAC : abstraction de l’entier borné (1/2)
composant AbstractionEntierBorné
valeur, maximum, minimum : entier
autoIncrémenter : booléendébut
retourne valeur < maximumfin
autoDécrementer : booléen …
94
PAC : abstraction de l’entier borné (2/2)
incrémenterdébut
valeur <- valeur + 1fin
décrémenter …
fin composant
95
PAC : contrôle de l’entier borné (1/4)
composant ContrôleEntierBorné
boutonPlus, boutonMoins : ContrôleBouton
abstraction : AbstractionEntierBorné
présentation : PrésentationEntierBorné
incrémenterdébut
si (autoIncrémenter) alorsabstraction.incrémentermettreAJour
fin sifin
96
PAC : contrôle de l’entier borné (2/4)
décrémenter …
traiterBouton (unBouton : ContrôleBouton)début
si (unBouton = boutonPlus) alorsincrémenter
sinonsi (unBouton = boutonMoins) alors
décrémenterfin si
fin sifin
97
PAC : contrôle de l’entier borné (3/4)
autoIncrémenterdébut
retourne abstraction.autoIncrémenterfin
autoDécrémenter : booléen …
valeur : entierdébut
retourne abstraction.valeurfin
98
PAC : contrôle de l’entier borné (4/4)
mettreAJourdébut
présentation.afficher (valeur)si (autoDécrementer) alors
boutonMoins.activersinon
boutonMoins.désactiverfin sisi (autoIncrémenter) alors
boutonPlus.activersinon
boutonPlus.désactiverfin si
fin
fin composant
99
Le modèle PAC-Seeheim (1/3)
! J. Coutaz, L. Nigay, 1992
! Solution hybride :" PAC pour l’interface" Seeheim pour l’application globale
100
Le modèle PAC-Seeheim (2/3)
A PC
A PC
A PC
A PC
Contrôleur du dialogue
Adaptateurde noyaufonctionnel
Noyaufonctionnel
Présentation
Objetsconceptuels
Objets deprésentation
101
Le modèle PAC-Seeheim (3/3)
! Noyau fonctionnel :" concepts propres au domaine d’application
! Adaptateur de Noyau Fonctionnel :" protocole noyau fonctionnel ! contrôleur de dialogue" définition d’objets conceptuels" améliorations sémantiques et délégation sémantique
! Contrôleur de dialogue :" hiérarchie d’objets PAC, enchaînement des tâches
" cohérence objets conceptuels ! objets de présentation
! Présentation :" image du système, objets de présentation
102
PAC-Seeheim et l’entier borné (1/5)
! Présentation :" visualisation de la valeur de l’objet
! Contrôle :" gestion des événements logiques en provenance des
boutons
! Abstraction = Adaptateur de NF :" pré-conditions, descriptions des fonctionnalités
! Noyau Fonctionnel :" attributs et fonctionnalités
103
PAC-Seeheim et l’entier borné (2/5)
11
ContrôleEntierBornéboutonPlus : ContrôleBoutonboutonMoins : ContrôleBoutonprésentation : PrésentationEntierBornéabstraction : AbstractionEntierBorné
valeur : entierincrémenterdécrémenterautoIncrémenter : booléenautoDécrémenter : booléentraiterBouton (b : ContrôleBouton)
PrésentationEntierBorné
afficher (v : entier)
1
1
Noyauvaleur : entierminimum : entier
maximum : entier
incrémenterdécrémenter
Adaptateur de NF
AbstractionEntierBorné
valeur : entierincrémenterdécrémenterautoIncrémenter : booléenautoDécrémenter : Booléen
noyauFonctionnel : Noyau
104
PAC-Seeheim et l’entier borné (3/5)
composant AbstractionEntierBorné
noyauFonctionnel : Noyau
valeur : entierdébut
retourne noyauFonctionnel.valeurfin
autoIncrémenter : booléendébut
retourne valeur < noyauFonctionnel.maximumfin
105
PAC-Seeheim et l’entier borné (4/5)
incrémenterdébut
noyauFonctionnel.incrémenterfin
autoDécrémenter : booléendébut
retourne valeur > noyauFonctionnel.minimumfin
décrémenterdébut
noyauFonctionnel.incrémenterfin
fin composant106
PAC-Seeheim et l’entier borné (5/5)
composant Noyau
valeur, maximum, minimum : entier
incrémenterdébut
valeur <- valeur + 1fin
décrémenterdébut
valeur <- valeur - 1fin
fin composant
107
Le modèle PAC-Amodeus (1/2)
! Laurence Nigay (93)
! Arche + PAC pour le composant central
! Aboutissement de PAC-Seeheim...
108
Le modèle PAC-Amodeus (2/2)
Composant technique de présentation
Adaptateur de noyau fonctionnel
Ensemble d’objets interactifs de haut niveau
Interface (bidirectionnelle) pour le noyau fonctionnel
Noyau fonctionnel
Spécifique au domaine d’application
Composant bas-niveau d’interaction
Système de fenêtrage
Contrôleur de Dialogue
Objets du Domaine Objets Interactifs
Objets dePrésentation
ObjetsConceptuels
:A :P:C
:A :P:C
:A :P:C
109
Les modèles de type Seeheim
! Langage! Seeheim modifié! Seeheim étendu! A couches orienté objet! Arche! PAC! F-PAC! Motiva! PAC-Seeheim! PAC-Amodeus! ... 110
Autres types de modèles
! MVC
! Mode
! A couches pour l’interaction
! IAMBUS
! ...
111
Le modèle MVC (1/3)
! Trygve Reenskaug, Xerox PARC, 1979! Adèle Goldberg (Smalltalk), milieu des années 80! Model - View - Controller
Modèle
Contrôleur
Vue
112
Le modèle MVC (2/3)
! Modèle :" gère les aspects applicatifs" met à jour les vues enregistrées
! Vue :" se déclare auprès d’un modèle" se charge de la visualisation en sortie" redirige les entrées vers un contrôleur associé
! Contrôleur :" gère les événements d’entrée" prévient le modèle associé
113
Le modèle MVC (3/3)
! Très différent de PAC :" pas de séparation nette Application ! Interface Utilisateur" le modèle a connaissances des vues…
! Complexe :" utilise plusieurs Design Patterns…
! Implanté dans Smalltalk 80" c’est une réalité !
! Utilisé également dans Swing (les JFC)" bien qu’on puisse aussi faire du PAC avec Swing…
! Délaissé au profit de Motif autour de 1990...! De nouveau très en vogue aujourd’hui...
114
Le modèle MVC selon Oracle/Sun (1/2)
! MVC Initialhttp://java.sun.com/blueprints/patterns/MVC-detailed.html
115
Le modèle MVC selon Oracle/Sun (2/2)
! Robert Eckstein, Mars 2007http://www.oracle.com/technetwork/articles/javase/mvc-136693.html
! MVC modifié (« Modified MVC »)
116
Le modèle MVC 2 (1/2)
! Une évolution web (J2EE) de MVC ?http://j2ee-firststep.blogspot.com/
! Comme MVC" mais un seul contrôleur (?)" et plutôt aussi une seule partie modèle (??)" et seul le contrôleur communique avec le modèle ! (???)
117
Le modèle MVC 2 (2/2)
! Struts MVC 2http://www.ibm.com/developerworks/library/j-struts/
118
Le modèle MVP
! 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
! Boîtes à outils! Applications extensibles, frameworks! Constructeurs, générateurs d’interfaces ;
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
139
X-Lib : EntierNoyau.h
void Initialiser (int, int, int) ;int Valeur (void ) ;int AutoIncrementer (void) ;void Incrementer (void) ;int AutoDecrementer (void) ;void Decrementer (void) ;
140
X-Lib : EntierNoyau.c (1/2)
#include "entierNoyau.h"
int valeur = 10 ;int minimum = 0 ;int maximum = 20 ;
void Initialiser (int min, int val, int max) {if ((min <= val) && (val <= max)) {
minimum = min ;valeur = val ;maximum = max ;
}}
int Valeur (void ) {return (valeur) ;
}
141
X-Lib : EntierNoyau.c (2/2)
int AutoIncrementer (void) {return (valeur < maximum) ;
}
void Incrementer (void) {valeur ++ ;
}
int AutoDecrementer (void) {return (valeur > minimum) ;
}
void Decrementer (void) {valeur -- ;
}
142
X-Lib : EntierX.c (1/13)
#include "entierNoyau.h"#include <stdio.h>#include <X11/Xlib.h>
int main (int argc, char ** argv) {
GC GC1, GC2 ;Display * affichage ;Window fenetre, fPlus, fMoins, fFin ;XGCValues valeurs ;int ecran ;XEvent evt ;char chaine [10] ;int fini ;unsigned long noir, blanc ;
143
X-Lib : EntierX.c (2/13)
/* initialisation de l'application */
if (argc != 4) { /* initialisation par defaut */ Initialiser (0, 10, 20) ;
} else {Initialiser (atoi (argv[1]), atoi (argv[2]),
atoi (argv[3])) ;}
/* ouverture du serveur d'affichage */
affichage = XOpenDisplay ("") ;if (affichage == NULL) {
printf ("Mauvaise connexion\n") ;exit (1)
}144
X-Lib : EntierX.c (3/13)
/* obtention de l'ecran et des couleurs */
ecran = DefaultScreen (affichage) ;noir = BlackPixel (affichage, ecran) ;blanc = WhitePixel (affichage, ecran) ;
/* creation de la fenetre principale */
fenetre = XCreateSimpleWindow (affichage,DefaultRootWindow (affichage),10, 10, 200, 100, 2, noir, blanc) ;
XStoreName (affichage, fenetre, "Entier v 4") ;
145
X-Lib : EntierX.c (4/13)
/* creation des sous-fenetres */
fMoins = XCreateSimpleWindow (affichage, fenetre,0, 0, 65, 50, 2, noir, blanc) ;
fPlus = XCreateSimpleWindow (affichage, fenetre,140, 0, 60, 50, 2, noir, blanc) ;
fFin = XCreateSimpleWindow (affichage, fenetre,0, 50, 200, 50, 2, noir, blanc) ;
/* initialisation des contextes graphiques */
GC1 = DefaultGC (affichage, ecran) ;valeurs.foreground = noir ^ blanc ;valeurs.function = GXxor ;GC2 = XCreateGC (affichage, fenetre,
GCForeground | GCFunction, &valeurs) ;146
X-Lib : EntierX.c (5/13)
/* initialisation des masques d'evenementts */
XSelectInput (affichage, fMoins,ButtonPressMask | ButtonReleaseMask) ;
XSelectInput (affichage, fPlus,ButtonPressMask | ButtonReleaseMask) ;
XSelectInput (affichage, fFin,ButtonPressMask | ButtonReleaseMask) ;
XSelectInput (affichage, fenetre,ExposureMask | ButtonPressMask | ButtonReleaseMask) ;
/* affichage des fenetres */
XMapWindow (affichage, fenetre) ;XMapSubwindows (affichage, fenetre) ;
147
X-Lib : EntierX.c (6/13)
/* boucle principale */
fini = 0 ;
while (! fini) {XNextEvent (affichage, &evt) ;switch (evt.type) {
148
X-Lib : EntierX.c (7/13)
case Expose : /* reafficher contenu fenetres */sprintf (chaine, "%d", Valeur ()) ;XDrawString (affichage, fenetre, GC1,
90, 30, chaine, strlen (chaine)) ;XDrawString (affichage, fFin, GC1,
85, 30, "Fin", 3) ;if (AutoIncrementer ()) {
XDrawString (affichage, fPlus, GC1,10, 30, "Plus", 4) ;
}if (AutoDecrementer ()) {
XDrawString (affichage, fMoins,GC1, 5, 30, "Moins", 5) ;
}break ;
149
X-Lib : EntierX.c (8/13)
case ButtonPress : /* faire clignoter */if (evt.xbutton.window == fMoins) {
if (AutoDecrementer ()) {XDrawString (affichage, fMoins, GC2,
5, 30, "Moins", 5) ;}
} else {if (evt.xbutton.window == fPlus) {
if (AutoIncrementer ()) {XDrawString (affichage, fPlus, GC2,
10, 30, "Plus", 4) ; }
}}break ;
150
X-Lib : EntierX.c (9/13)
case ButtonRelease :/* traitement de l'interaction */if (evt.xbutton.window == fFin) {
fini = 1 ;} else if (evt.xbutton.window == fPlus) {
XDrawString (affichage, fPlus, GC1,10, 30, "Plus", 4) ;
sprintf (chaine, "%d", Valeur ()) ;XDrawString (affichage, fenetre, GC2,
90, 30, chaine, strlen (chaine)) ;Incrementer () ;sprintf (chaine, "%d", Valeur ()) ;XDrawString (affichage, fenetre, GC1,
90, 30, chaine, strlen (chaine)) ;
151
X-Lib : EntierX.c (10/13)
if (! AutoIncrementer ()) {XSelectInput (affichage, fPlus,
NoEventMask) ;XDrawString (affichage, fPlus, GC2,
10, 30, "Plus", 4) ;}if (AutoDecrementer ()) {
XSelectInput (affichage, fMoins,ButtonPressMask | ButtonReleaseMask) ;
XDrawString (affichage, fMoins, GC1,5, 30, "Moins", 5) ;
}
152
X-Lib : EntierX.c (11/13)
} else if (evt.xbutton.window == fMoins) {XDrawString (affichage, fMoins, GC1,
5, 30, "Moins", 5) ;sprintf (chaine, "%d", Valeur ()) ;XDrawString (affichage, fenetre, GC2,
90, 30, chaine, strlen (chaine)) ;Decrementer () ;sprintf (chaine, "%d", Valeur ()) ;XDrawString (affichage, fenetre, GC1,
90, 30, chaine, strlen (chaine)) ;
153
X-Lib : EntierX.c (12/13)
if (! AutoDecrementer ()) {XSelectInput (affichage, fMoins,
NoEventMask) ;XDrawString (affichage, fMoins, GC2,
5, 30, "Moins", 5) ;}if (AutoIncrementer ()) {
XSelectInput (affichage, fPlus,ButtonPressMask | ButtonReleaseMask) ;
XDrawString (affichage, fPlus, GC1,10, 30, "Plus", 4) ;
}}break ;
154
X-Lib : EntierX.c (13/13)
}}
/* destruction des fenetres */
XDestroyWindow (affichage, fenetre) ;XCloseDisplay (affichage) ;
return (0) ;}
155
Boîtes à outils
! X-Toolkit + OSF-Motif, IlogViews, MFC, Swing...
! Habillages d’un logiciel graphique de base : " de niveau d’abstraction supérieur" souvent « orientés objet »" proposent de nombreux composants interactifs
156
Exemple : X-Toolkit + Motif (1/10)
#include <X11/Intrinsic.h>#include <X11/StringDefs.h>#include <Xm/Xm.h>#include <Xm/PushB.h>#include <Xm/RowColumn.h>#include <Xm/Label.h>#include "entierNoyau.h"
typedef struct {Widget fAfficheur ;Widget fPlus ;Widget fMoins ;
} Donnees ;
157
Exemple : X-Toolkit + Motif (2/10)
static void cbPlus (Widget w, XtPointer pDonnee,XEvent * e) {
char chaine [10] ;XmString chaineV ;Arg arguments [1] ;Incrementer () ;sprintf (chaine, "%d", Valeur ()) ;chaineV = XmStringCreate (chaine,
XmSTRING_DEFAULT_CHARSET) ;XtSetArg (arguments [0], XmNlabelString, chaineV) ;XtSetValues (((Donnees *)pDonnee)->fAfficheur,
arguments, 1) ;
158
Exemple : X-Toolkit + Motif (3/10)
if (! AutoIncrementer ()) {XtSetSensitive (((Donnees *)pDonnee)->fPlus,
FALSE) ;}if (AutoDecrementer ()) {
XtSetSensitive (((Donnees *)pDonnee)->fMoins,TRUE) ;
}}
159
Exemple : X-Toolkit + Motif (4/10)
static void cbMoins (Widget w, XtPointer pDonnee,XEvent * e) {
char chaine [10] ;XmString chaineV ;Arg arguments [1] ;Decrementer () ;sprintf (chaine, "%d", Valeur ()) ;chaineV = XmStringCreate (chaine,
XmSTRING_DEFAULT_CHARSET) ;XtSetArg (arguments [0], XmNlabelString, chaineV) ;XtSetValues (((Donnees *)pDonnee)->fAfficheur,
arguments, 1) ;
160
Exemple : X-Toolkit + Motif (5/10)
if (AutoIncrementer ()) {XtSetSensitive (((Donnees *)pDonnee)->fPlus, TRUE);
}if (! AutoDecrementer ()) {
XtSetSensitive (((Donnees *)pDonnee)->fMoins,FALSE);}
}
static void cbFin (Widget w, XtPointer pDonnee,XEvent * e) {
XtCloseDisplay (XtDisplay (w)) ;exit (0) ;
}
161
Exemple : X-Toolkit + Motif (6/10)
int main (int argc, char ** argv) {Widget fenetre, afficheur, rc1, rc2, plus, moins, fin;Arg arguments [1] ;char chaine [15] ;XmString chaineV ;int c = 1 ;char * v [1] ;Donnees donnees ;
/* initialisation de l'application */if (argc != 4) { /* initialisation par defaut */
Initialiser (0, 10, 20) ;} else {
Initialiser (atoi (argv[1]), atoi (argv[2]),atoi (argv[3])) ;
}162
Exemple : X-Toolkit + Motif (7/10)
/* creation de la fenetre principale */strcpy (chaine, "Entier v 2") ;v [0] = chaine ;fenetre = XtInitialize ("fenetre", "Fenetre", NULL,
0, &c, v) ;
/* creation des widgets de presentation */rc1 = XtCreateManagedWidget ("Rc1",
xmRowColumnWidgetClass, fenetre, NULL, 0) ;XtSetArg (arguments [0], XmNorientation,
XmHORIZONTAL) ;rc2 = XtCreateManagedWidget ("Rc2",
xmRowColumnWidgetClass, rc1, arguments, 1) ;moins = XtCreateManagedWidget ("Moins",
xmPushButtonWidgetClass, rc2, NULL, 0);
163
Exemple : X-Toolkit + Motif (8/10)
sprintf (chaine, "%d", Valeur ()) ;chaineV = XmStringCreate (chaine,
XmSTRING_DEFAULT_CHARSET) ;XtSetArg (arguments [0], XmNlabelString, chaineV) ;afficheur = XtCreateManagedWidget ("Afficheur",
xmLabelWidgetClass, rc2, arguments, 1) ;plus = XtCreateManagedWidget ("Plus",
xmPushButtonWidgetClass, rc2, NULL, 0);fin = XtCreateManagedWidget ("Fin",
xmPushButtonWidgetClass, rc1, NULL, 0);
/* specification des donnees transmises */donnees.fPlus = plus ; donnees.fMoins = moins ; donnees.fAfficheur = afficheur ;
164
Exemple : X-Toolkit + Motif (9/10)
/* specification des reflexes associes aux boutons */XtAddCallback (plus, XmNactivateCallback,
(XtCallbackProc)cbPlus, (XtPointer)&donnees) ;XtAddCallback (moins, XmNactivateCallback,
(XtCallbackProc)cbMoins, (XtPointer)&donnees) ;XtAddCallback (fin, XmNactivateCallback,
(XtCallbackProc)cbFin, NULL) ;
/* specification des sensibilites */if (! AutoIncrementer ()) {
XtSetSensitive (plus, FALSE) ;}if (! AutoDecrementer ()) {
XtSetSensitive (moins, FALSE) ;}
165
Exemple : X-Toolkit + Motif (10/10)
/* creation effective de l'interface */
XtRealizeWidget (fenetre) ;
/* boucle d'evenements */
XtMainLoop () ;
return (0) ;}
166
Outils de base
! 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
! Avantages :" application = { primitives }" structure à contrôle externe
! Inconvénients :" nécessité de connaître certains détails de programmation
graphique pour étendre la présentation de ce type d’application
" souvent un seul type de dialogue possible
169
Frameworks
! IlogViews, Swing, MFC…
! Boîtes à outils « de haut niveau » :" dotées de structures d’organisations" parfois associées à des éditeurs interactifs
! Couramment utilisés par les développeurs" efficaces quand bien maîtrisés
! Non utilisables par les non-informaticiens
170
SGIU : plusieurs définitions
! Environnement, utilisé par un spécialiste IHM, destiné à la construction d’IU
! Environnement qui comprend des outils et des techniques pour l’implémentation des interfaces utilisateur
! Environnement qui permet de spécifier l’IU d’une application, à l’aide d’un langage de haut niveau
! Environnement (ensemble d’outils) destiné àaugmenter la productivité lors de la création d’IU
! Outil (ou ensemble d’outils) qui aide(nt) à spécifier, àimplémenter, à tester et à maintenir une IU
171
SGIU : en résumé
! Outils d’aide :" à l’analyse" à la spécification" à la conception" à l’implémentation" à l’évaluation" à la documentation" à la maintenance
des systèmes interactifs! Couverture du cycle de vie du logiciel interactif
172
Rôle du SGIU, côté développeur (1/2)
! Fournir un support pour définir le dialogue homme-machine (sous forme d’un composant interactif)
! Fournir un support pour les sorties de l’application
! Imposer un contrôle équilibré à l’application
! Faciliter la mise au point
! Permettre d’obtenir des IU cohérentes pour différentes applications (« style maison »)
173
Rôle du SGIU, côté développeur (2/2)
! Fournir plusieurs niveaux d’aide ou d’assistance
! Fournir un support pour l’apprentissage des applications (pour l’utilisateur)
! Fournir un support pour permettre à l’utilisateur final de modifier l’IU (sans programmation)
! Fournir un support pour pouvoir étendre les applications (pour le développeur, par programmation)
174
Bilan de l’utilisation d’un SGIU (1/2)
! Cohérence d’IU entre les applications
! Facilité de changement d’IU
! Développement et réutilisation de composants logiciels
! Isolement de la complexité de l’environnement de développement (problèmes graphiques)
175
Bilan de l’utilisation d’un SGIU (2/2)
! Facilité d’apprentissage et d’utilisation des applications
! L’utilisation d’un SGIU permet de développer du logiciel de meilleure qualité, à moindre coût
! La plupart de ces avantages sont dus à la séparation interface utilisateur ! application
176
Différents types de SGIU
! 3 types de générateurs d’interfaces utilisateur :" 3 axes de recherche sur les SGIU :
• description de la présentation de l’interface• expression du contrôle du dialogue• spécification de l’interface avec l’application
! Empreinte du modèle Seeheim…
177
Générateurs interactifs (1/2)
! Produits commercialisés :" Interface Builder (Next)" Masaï, IlogBuilder, IvStudio (Ilog)" XFaceMaker (NSL)" UIM/X (Visual Edge)" Builder Xcessory (scientific Computers)" Open Interface (Neuron Data)" DevGuide (Sun)" XmTree (Celtis)" TeleUse (Alsys)" Editeur de Visual Basic, Visual C++ (Microsoft)" Workshop (Borland) 178
Générateurs interactifs (2/2)
! Produits gratuits :" forte4j, NetBeans" Visual Editor d’Eclipse" Winterp" XForms" ...
179
Générateurs : 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 ()) {
valeur -- ;}
}}
189
PrésentationEBI.java (1/4)
import java.awt.event.ActionEvent;import java.awt.event.ActionListener;
public class PrésentationEBI extends javax.swing.JPanel {
private ContrôleEBI.ActionDécrémenter décrémenter ;private ContrôleEBI.ActionIncrémenter incrémenter ;
private void plusActionPerformed (java.awt.event.ActionEvent evt) {incrémenter.exécuter () ;
}
private void moinsActionPerformed (java.awt.event.ActionEvent evt) {décrémenter.exécuter () ;
}
190
PrésentationEBI.java (2/4)
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) ;
}
}
193
ContrôleEBI.java (1/3)
public class ContrôleEBI {
protected PrésentationEBI présentation ;protected AbstractionEBI abstraction ;
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 () ;
}
protected void mettreAJourPrésentation () {présentation.activerActionIncrémenter (isIncrémentable ()) ; présentation.activerActionDécrémenter (isDécrémentable ()) ; présentation.setValeur (getValeur ()) ;
}
public PrésentationEBI getPrésentation () {return (présentation) ;
}194
ContrôleEBI.java (2/3)
public boolean isIncrémentable () {return abstraction.isIncrémentable () ;
}
public void incrémenter () {if (isIncrémentable ()) {
abstraction.incrémenter () ;mettreAJourPrésentation () ;
}}
public boolean isDécrémentable () {return abstraction.isDécrémentable () ;
}
public void décrémenter () {if (isDécrémentable ()) {
abstraction.décrémenter () ;mettreAJourPrésentation () ;
}}
195
ContrôleEBI.java (3/3)
public int getValeur () {return abstraction.getValeur () ;
}
public class ActionIncrémenter {public void exécuter () {
incrémenter () ;}
}
public class ActionDécrémenter {public void exécuter () {
décrémenter () ;}
}}
196
EBI.java
public class EBI extends javax.swing.JFrame {
public EBI () {ContrôleEBI ebi = new ContrôleEBI (0, 9, 20) ;getContentPane ().add (ebi.getPrésentation ()) ;initComponents () ;
}
private void initComponents () {setDefaultCloseOperation (javax.swing.WindowConstants.EXIT_ON_CLOSE) ;pack () ;
}
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é
199
Constructeurs automatiques (1/2)
! Prototypes universitaires" Syngraph, Mike, Mickey, Gustave
! 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
Représentationconceptuelle
Représentationexterne
Représentationinterne
vue du programmeur
vue du concepteur
vue de l’utilisateur
domained’utilisationdes outils deconstructiond’IHM
205
La qualité du dialogue dans IHM
! C’est un point crucial !! Comment l’obtenir ?
" 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 !!!
206
Adapter le dialogue à l’usager
! Aides :" étude des facteurs humains
• psychologie cognitive• psychologie expérimentale
" recommandations ergonomiques• guides de style• normes• …
" prototypage itératif• en incluant l’usager dans la boucle…
207
Psychologie cognitive et facteurs humains
! Démarche ergonomique de la spécification des IHM
! Modélisation de l’humain" statique" dynamique
! Modélisation de la tâche à accomplir" formalismes adaptés
! Outils de dimensionnement des systèmes interactifs
208
Modélisation statique de l’humain
! Card, Moran, Newell, 1983
! Définition d’une boucle d’interaction :" processus perceptif
• temps de cycle : 100 ms
" processus moteur• temps de cycle : 70 ms
" processus cognitif• temps de cycle : 70 ms
! L’humain fonctionne à 4 Hz…
209
Modélisation dynamique de l’humain
! Rasmussen, 1980
alarme ou détection d’un état anormal
identification de l’état
du système
exécutionde la
procédure
observationdes
informations
prédictionsévaluationsalternatives
définitionde la
procédure
définition des tâches, choix des
modifications
procédure
observationsalerte état du système
tâches stratégie objectifs
210
Modélisation de la tâche
! Modéliser le comportement externe de l’usager en analysant les tâches qu’il doit réaliser
! Analyse de la tâche :" objectifs à atteindre en fonction de procédures et d’outils à
disposition
! Analyse de l’activité :" utilisation des procédures et des outils pour atteindre les
objectifs fixés
! L’écart entre la tâche et l’activité entraîne la fatigue et le stress de l’usager
211
Formalismes de spécification de la tâche de l’usager
! Modélisation de l’interaction homme-machine par des hiérarchies de tâches et de buts :" MAD (Méthode Analytique de Description de tâches),
Scapin, Pierret-Golbreich, 1989" SADT et réseaux de Petri, Abed, 1990" CLG (Command Langage Grammar), Moran, 1981" Diadem, Thomson-CSF, 1994 (spécifications formelles)" UAN, Hix, Hartson, 1993" DIANE+, Tarby, Barthet, 1996" UML : cas d’utilisation, scénarios, diagrammes d’états…
212
Modèles prédictifs
! 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
appropriés aux besoins des futurs utilisateurs
! Exemples :" Motif Style Guide" OpenLook Graphical User Interface Application Style
Guidelines" guides pour Macintosh, pour Windows
219
Recommandations ergonomiques
! 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
! Attributs de visualisation (ou informatiques) :" intensité lumineuse" inversion vidéo" clignotement" couleur" soulignement, italique, gras, …
241
Attributs de visualisation (2/3)
! Couleurs :" ne pas utiliser plus de 4 (maximum 6) couleurs différentes" penser aux conventions traditionnelles :
• vert = OK, continuation• rouge = erreur, arrêt• jaune = avertissement
" 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
257
Guidage (3/4)
! Exemples :" guidage explicite :
• messages d’avertissement• message d’évitement d’erreur• aide en ligne• messages d’erreur
" 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
2001.