Construction des IHM

35
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

Transcript of Construction des IHM

Page 1: Construction des IHM

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

[email protected]

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

Page 2: Construction des IHM

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

Page 3: Construction des IHM

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…

Page 4: Construction des IHM

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

Page 5: Construction des IHM

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

Page 6: Construction des IHM

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 ?

Page 7: Construction des IHM

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

Page 8: Construction des IHM

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)

Page 9: Construction des IHM

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

Page 10: Construction des IHM

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

Page 11: Construction des IHM

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

Page 12: Construction des IHM

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

Page 13: Construction des IHM

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

Page 14: Construction des IHM

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é

Page 15: Construction des IHM

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

Page 16: Construction des IHM

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

Page 17: Construction des IHM

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

Page 18: Construction des IHM

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") ;

Page 19: Construction des IHM

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

Page 20: Construction des IHM

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

}

Page 21: Construction des IHM

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

Page 22: Construction des IHM

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…

Page 23: Construction des IHM

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

Page 24: Construction des IHM

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

}

}

Page 25: Construction des IHM

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é

Page 26: Construction des IHM

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…

Page 27: Construction des IHM

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 ?

Page 28: Construction des IHM

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

Page 29: Construction des IHM

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

Page 30: Construction des IHM

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

Page 31: Construction des IHM

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

Page 32: Construction des IHM

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

Page 33: Construction des IHM

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)

Page 34: Construction des IHM

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

Page 35: Construction des IHM

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.