Spécification - Modèles - Outils Prise en compte des utilisateurs › thierry.duval › Documents...

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]

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

6

Cadre de travail

Applications graphiques interactives :produire des dessins, des imagesagir 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 :analyserspécifierconcevoirimplémentertestervalidermaintenir

les IHM ?Comment couvrir leur cycle de vie ?

et celui des applications interactives en général ?

8Validation

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

Conception générale Tests d’intégration

Conception dé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

15

Applications à manipulations limitées

Actions : désignations d’objets de l’applicationpuis exécution de commandes sur ces objets…

17

Applications à manipulations directes

Action : manipulation directe des objets applicatifs

Manipulation directe :représentation continue des objetsactions physiques sur les objetsopérations rapides, incrémentales et réversiblesimpact sur les objets manipulés visible aussitôt

Démo…

18

Tentative de classification…

…des applications interactives…

Selon 2 critères :le niveau de visualisationle niveau de rétroaction

19

Niveaux de visualisation

1 : Absence d’illustration des objets de l’applicationshells, IHM limitée aux objets de dialogue, …

2 : Impossible d’agir directement sur une illustrationxdvi : type « visionneuse », pour informations, …

3 : Désignation d’une illustrationgestion graphique de fichiers (KDE, …) :

• pour obtenir un menu contextuel• pour la désigner comme argument d’une commande

4 : Manipulation directe d’une illustrationgestion 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 argumentla commande : détruireles 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


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


Autre exemple :résolution interactive du problème des tours de Hanoïdémonstration…

23

Visualisation et rétroactionVisualisation

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émenterparfois indésirables à cause des temps de réponses !

Exemple interactif : l’explorateur de fichiers…offre un niveau de visualisation maximumn’offre au mieux que des rétroactions syntaxiquescomme 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 3DIHM multimodalesCollecticiels (GroupWare, CSCW)Réalité VirtuelleIHM 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 facilementpour 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’utilisateurdialogue avec l’utilisateur = IHM, IU

28

Cas des grosses applications

Problèmes :flexibilitémaintenanceadaptabilité

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 :facilementrapidement

Séparation et mise au point :la modification de l’application n’affecte pas l’IUla modification de l’IU n’affecte pas l’applicationmise au point facilitéemaintenance 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éutilisableprototypage du dialogue plus rapidedé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 applicationune interface pour plusieurs applications

32

Bilan de la séparation (2/2)

Inconvénients :chute de l’efficacité des interactionsduplication 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’utilisateurdes composants de l’applicationdu 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ôlecontrô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


39


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 applicationcompromet la modularité de l’applicationcontraignant pour l’utilisateurIU non modifiable sans changer l’applicationseul 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


42


Avantages :meilleure décomposition modulairedialogue réalisable par un spécialiste en IHMdialogue à l’initiative de l’utilisateurplusieurs interfaces pour une même application

Inconvénients :impose au réalisateur un style de programmation particulierapplications 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 } intelligentescommuniquer avec l’utilisateurenvoyer des messages asynchrones au dialogue

44

ApplicationDialogue


45


Une nécessité dans certains cas :signalement d’événements asynchronesobtention de renseignements complémentairesré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

ApplicationDialoguePré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’IHMVolonté de :

mettre en oeuvre la séparationfaire du contrôle équilibré

Un modèle, pour quoi faire ?classification d’applicationstest de conformité d’architecture logicielle

• évaluation du coût de maintenance…

aide à la construction des IHMPré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’applicationcomment faire du contrôle équilibré

Fournir la description :des données échangées entre utilisateur et applicationdes étapes de transformation des donnéesde 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 :valeuropérations réalisables (ou non)

Accès par voie logicielle :valeur2 opérations : incrémenter et décrémenterpré-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 responsableréagir selon son état (actif ou inactif)refléter l’état d’une fonctionnalité associée

Primitives :permettre à un client de modifier son étatgérer les entrées d’un utilisateurafficher son étatcommuniquer à 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 logicielleassurer la cohérence entre données et présentationvisualiser sa valeur

Primitives :fonctionnalités logiciellespré-conditions des fonctionnalitéscommunication 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


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


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, 1983Contemporains : Ada, C, Pascal, GKS, PHIGS3 composants pour décrire une IHM

Présentation Contrôledu dialogue

Utilisateur

Interface Application

Application

62


Présentation :présentation externe du système à l’utilisateurgestion de l’écran, affichage de l’informationgestion des dispositifs d’entréegestion des modes d’interactionresponsable de la rétroaction lexicale

63


Application :partie applicative indépendante du dialogue

Interface avec l’application :application du point de vue de l’IUdescriptions des structures de données et des procédures de l’application accessibles à l’IUpré-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éeaffichage de la valeur et des boutons

Interface avec l’application :description des fonctionnalités de l’applicationpré-conditions des fonctionnalités

Application :attributs (bornes et valeur de l’entier)implémentation des fonctionnalités (+1 et -1)

65


Contrôle du dialogue :gestion d’événements logiques de présentationvérifications sémantiques (interface application)mise à jour des dispositifs de présentationinterface 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 : ApplicationincrémenterautoIncrémenter : booléendécrémenterautoDécrémenter : booléenvaleur : entier

1

1

1

1


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


désactiverBoutonPlus …

désactiverBoutonMoins …

dessinerPlusActif …

dessinerMoinsActif …

dessinerPlusInactif …

dessinerMoinsInactif …

clignoterPlus …

clignoterMoins …

69



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 composant

70

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


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


retourne interfaceApplication.autoIncrémenterfin

autoDécrémenter : booléen …

74


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


traiterBoutonPlusdébut

incrémenterfin

traiterBoutonMoins …


retourne interfaceApplication.valeurfin

fin composant

76

Gestionnaire de dialogue

Le Modèle Seeheim modifié (1/2)

Groupe de travail sur les supports d’exécution, 1987Pour plus de rétroaction sémantiqueS’inspire du modèle Seeheim4 composants

Agent de la station de travail

Support sé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’interactionindépendant de l’application et des dispositifs physiques

Support sémantique :interface avec l’application, sémantique incorporée à l’IUré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


80


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érateurcohé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 composantsles agents communiquent uniquement via leurs contrôles

Perte de distinction entre application et interface avec l’application

82

A PC

Abstraction Présentation

Contrôle

A PC

A PC


83


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ôleurAbstraction :

sémantique : les fonctionnalités de l’applicationne communique qu’avec son contrôleur

Contrôle : maintien de la cohérence entre présentation et abstractionpeut communiquer avec d’autres contrôleurs

84

PAC et le bouton

Présentation :réception de la désignation physiqueappels au contrôleprimitives de dessin

Abstraction :primitives de gestion de l’état du bouton

Contrôle :réception des messages de la présentationassure la rétroaction immédiatesignale les désignations au contrôle de l’objet clientreçoit des messages d’activation et de désactivation

85

Structure PAC du bouton

1 ContrôleBoutonresponsable :

ContrôleEntierBornéprésentation :

PrésentationBoutonabstraction :

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


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


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é

1 1

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)

11

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é



retourne valeur < maximumfin

autoDécrementer : booléen …

94

PAC : abstraction de l’entier borné (2/2)

incrémenterdébut


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


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


autoIncrémenterdébut

retourne abstraction.autoIncrémenterfin

autoDécrémenter : booléen …


retourne abstraction.valeurfin

98


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’interfaceSeeheim pour l’application globale

100


A PC

A PC

A PC

A PC

Contrôleur du dialogue

Adaptateurde noyau

fonctionnel

Noyaufonctionnel

Présentation

Objetsconceptuels

Objets deprésentation

101


Noyau fonctionnel :concepts propres au domaine d’application

Adaptateur de Noyau Fonctionnel :protocole noyau fonctionnel ↔ contrôleur de dialoguedéfinition d’objets conceptuelsaméliorations sémantiques et délégation sémantique

Contrôleur de dialogue :hiérarchie d’objets PAC, enchaînement des tâchescohé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


1 1

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)

11

Noyauvaleur : entierminimum : entiermaximum : entier

incrémenterdécrémenter

Adaptateur de NF

AbstractionEntierBorné

valeur : entierincrémenterdécrémenterautoIncrémenter : booléenautoDécrémenter : Booléen

noyauFonctionnel : Noyau

104


composant AbstractionEntierBorné

noyauFonctionnel : Noyau


retourne noyauFonctionnel.valeurfin


retourne valeur < noyauFonctionnel.maximumfin

105


incrémenterdébut

noyauFonctionnel.incrémenterfin

autoDécrémenter : booléendébut

retourne valeur > noyauFonctionnel.minimumfin

décrémenterdébut

noyauFonctionnel.incrémenterfin

fin composant

106


composant Noyau


incrémenterdébut


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

LangageSeeheim modifiéSeeheim étenduA couches orienté objetArchePACF-PACMotivaPAC-SeeheimPAC-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, 1979Adèle Goldberg (Smalltalk), milieu des années 80Model - View - Controller

Modèle

Contrôleur

Vue

112


Modèle :gère les aspects applicatifsmet à jour les vues enregistrées

Vue :se déclare auprès d’un modèlese charge de la visualisation en sortieredirige les entrées vers un contrôleur associé

Contrôleur :gère les événements d’entréeprévient le modèle associé

113


Très différent de PAC :pas de séparation nette Application ↔ Interface Utilisateurle modèle a connaissances des vues…

Complexe :utilise plusieurs Design Patterns…

Implanté dans Smalltalk 80c’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 MVCmais 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), 1996Model – View – Presenter

http://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), 2005Lié à Silverlight et XAMLModel - View – ViewModel

http://msdn.microsoft.com/en-us/magazine/dd419663.aspxhttp://msdn.microsoft.com/en-us/magazine/dd458800.aspx

120

Application Contrôle Présentation

Le modèle SPA (Seeheim - PAC - Arche)

T. Duval, 1992Synthèse de Seeheim, PAC et ArcheRé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ésentationcommunication 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 utilisateurapplication écrite dans un autre langage que celui utilisépour écrire le composant contrôle

123

Application

InterfaceApplicationApplication

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ôlepersonnalisation du composant présentation pour disposer de primitives de présentation plus efficaces ou plus simples

125

PrésentationInterfacePrésentation

Présentation

SPA : l’interface présentation (2/2)

126

SPA : 2 interprétations

Raffinement de PAC :composants spécifiés clairementadapté 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épendamment3 composants à échanger facilementimportance 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 IHMApproche « génie logiciel » de la conception d’IHMPeuvent garantir la séparation application ↔ IU

cas des modèles de type SeeheimSont 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-AmodeusMVC

131

III : Outils pour les IHM

Expression des besoinsrôle des outils

Catégories d’outilsoutils de baseframeworksenvironnements de haut niveau

132

Expression des besoins

Faciliter le cycle de développement des IHM :outils d’analyse et de spécificationoutils de conceptionoutils d’implémentationoutils de test et d’intégrationoutils de documentation et de maintenance

Pour développer du logiciel de qualité :centré sur l’utilisateurrespectant 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’applicationpossibilité de tester différents styles d’interactionsincorporation de changements dus aux premières utilisationspossibilité 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’applicationle 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 directepour utiliser l’outil plus facilement

Intégration dans un environnementun 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êtrageBoîtes à outilsApplications extensibles, frameworksConstructeurs, générateurs d’interfaces ; environnements de développement d’interfaces (SGIU) :

interactifs, à manipulation d’objets de dialogueà langage de spécification du dialogueautomatiques à partir de spécifications des fonctionnalités d’une application

138

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


/* 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


/* 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


/* 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


/* 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


/* boucle principale */

fini = 0 ;

while (! fini) {XNextEvent (affichage, &evt) ;switch (evt.type) {

148


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


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


case ButtonRelease :/* traitement de l'interaction */if (evt.xbutton.window == fFin) {

fini = 1 ;} else if (evt.xbutton.window == fPlus) {


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


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


} 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


if (! AutoDecrementer ()) {XSelectInput (affichage, fMoins,

NoEventMask) ;XDrawString (affichage, fMoins, GC2,

5, 30, "Moins", 5) ;}if (AutoIncrementer ()) {

XSelectInput (affichage, fPlus,ButtonPressMask | ButtonReleaseMask) ;


}}break ;

154


}}

/* 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érieursouvent « 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


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


if (! AutoIncrementer ()) {XtSetSensitive (((Donnees *)pDonnee)->fPlus,

FALSE) ;}if (AutoDecrementer ()) {

XtSetSensitive (((Donnees *)pDonnee)->fMoins,TRUE) ;

}}

159


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


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


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


/* 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


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


/* 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


/* 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 informaticiensproblèmes de portabilité d’une boîte à outils vers une autrepas de séparation formelle IU ↔ applicationapplications à contrôle interne

167

Applications extensibles

Apex, MacApp…

Squelettes d’applications qui assurent :la gestion du dialoguela 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’applicationsouvent un seul type de dialogue possible

169

Frameworks

IlogViews, Swing, MFC…

Boîtes à outils « de haut niveau » :dotées de structures d’organisationsparfois associées à des éditeurs interactifs

Couramment utilisés par les développeursefficaces 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’IUEnvironnement qui comprend des outils et des techniques pour l’implémentation des interfaces utilisateurEnvironnement qui permet de spécifier l’IU d’une application, à l’aide d’un langage de haut niveauEnvironnement (ensemble d’outils) destiné àaugmenter la productivité lors de la création d’IUOutil (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 interactifsCouverture 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, NetBeansVisual Editor d’EclipseWinterpXForms...

179

Générateurs : la présentation

Création interactive de l’apparence de l’IUdéfinition de la présentation par « drag and drop »

Edition des propriétés des composants de dialogueinspecteurs (Ilog)éditeurs de propriétés de widgets (UIM/X)...

Intégration des objets de l’application :par programmationen 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 XUIM/X, XFaceMaker, IlogBuilder, ...

C et OpenWindow ou XviewDevGuide

Lisp et AïdaMasaï

C++ et X ou WindowsIlogViews

Java et SwingForte4j, 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émantiquepour 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ôlemise en place d’un protocole de communication entre composantsbesoin 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


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


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


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


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


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ésSerpent, Aïda, Humanoïd, …

S’appuient en général sur un environnement de développement de style boîte à outilsDéfinition de la présentation de l’interface utilisateurExpression de certaines contraintes géométriques dynamiques entre les objets de présentationLangage 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 à outilsfournissent 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 fortlangage de spécification (C, LISP, …)limités par les objets de présentation disponiblespouvoir d’expression limité

199

Constructeurs automatiques (1/2)

Prototypes universitairesSyngraph, 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’applicationcréent présentation et contrôle du dialogue

Présentation prête à l’emploi et cohérenteHeuristiques ergonomiques câblées dans le générateurReste à 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’applicationinterfaces qui se ressemblent (cohérence)

Inconvénients :interfaces qui se ressemblent (originalité ?)mauvaise finition des interfaces utilisateur produitestrès difficile de faire évoluer ces interfaceslimités à des dispositifs physiques particuliers, à un seul style d’interactionlimité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 besoinsdè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 interactivesde comment il faut concevoir les applications interactivesde comment il faut construire les applications interactives

Recommandations ergonomiques :normes AFNOR…

Aides à la construction des IHM :guides de stylepsychologie 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èmecelui du programmeur du systèmecelui 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’humainstatiquedynamique

Modélisation de la tâche à accomplirformalismes 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

identificatio n de l’état

du système

exécution de la

procédure

observation des

informations

prédictions évaluations alternatives

définition de 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éaliserAnalyse 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, 1989SADT et réseaux de Petri, Abed, 1990CLG (Command Langage Grammar), Moran, 1981Diadem, Thomson-CSF, 1994 (spécifications formelles)UAN, Hix, Hartson, 1993DIANE+, Tarby, Barthet, 1996UML : 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 usagerspour expliciter la façon dont sera utilisé le logicielen sessions de travail avec plusieurs usagersindividuellement

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’utilisateurcomment ils pensent aider à les réaliserla 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âcheils ne permettent pas au concepteur d’effectuer des choix appropriés aux besoins des futurs utilisateurs

Exemples :Motif Style GuideOpenLook Graphical User Interface Application Style Guidelinesguides pour Macintosh, pour Windows

219

Recommandations ergonomiques

Norme AFNOR Z67-110, Janvier 1988Traitement de l’informationErgonomie et conception du dialogue homme-ordinateurConcepts généraux

Norme AFNOR Z67-133-1, Décembre 1991Traitement de l’informationÉvaluation des produits logicielsPartie 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 dialoguecommandes et validationenchaînementstemps de réponsestructuration des écransmessages d’erreur, aidedensité de visualisationattributs de visualisationstyle 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 guidageexpert : raccourcis

222


Présentation des informations :si les informations à saisir arrivent toujours dans le même ordre, le dialogue doit respecter cet ordresinon, 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âchessi ces sous-tâches doivent suivre un certain ordre, le dialogue doit le respectersinon, il doit permettre à l’utilisateur de réaliser ces sous-tâches comme il l’entend

223


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 guidagedoit posséder une aide complète pour chaque commandedoit être concis et précis plutôt que naturel et ambigudoit être aussi précis que possibledoit regrouper les commandes par groupes cohérents de fonctions et par niveau de complexitédoit proposer une syntaxe cohérente

225


Le mode d’utilisation :localisation des commandes identique pour chaque page d’écranséquences de commandes dictées par l’utilisateur et non imposées par le systèmene pas changer l’intitulé des commandes au cours d’une tâcheactions fréquentes faciles à exécuter (raccourcis)actions destructives nécessitent une confirmationpouvoir répéter (again) et annuler (undo) une actionsystème réactif à toute commande (exécution + compte-rendu)

226


Intérêt des touches de fonction :si le nombre de choix possible est très réduitpour cheminer dans le dialogue (retour au menu initial ou àl’écran précédent, raccourci, abandon)pour appeler de l’aide contextuellepour valider, confirmer, annulerpour des commandes fréquemment utilisées

227


Utilisation des touches de fonction :elles doivent être assignées de façon cohérente tout au long du dialogueles fonctions inutiles ou inutilisables doivent être désactivées ou rendues indisponiblesla signification des touches doit être préciséel’action sur une touche doit faire l’objet d’un retour d’informationles touches de fonction doivent être faciles d’accès

228


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’utilisateuril faut éviter de découper des tâches simples

Possibilités d’enchaînements :par choix d’une option dans un menupar action sur une touche de fonctionl’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 10sdoivent ê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éeszone 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


Organisation :l’organisation des informations sur l’écran doit respecter l’ordre dans lequel l’utilisateur a besoin de ces informationsil ne faut pas afficher ensemble des informations sans rapportsil faut respecter les relations sémantiques entre les données

234


Typographie :il faut structurer l’informationil 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


Les messages d’erreur doivent :être concis et précisêtre compréhensibles par l’utilisateurindiquer le lieu, la cause, et comment corriger l’erreurêtre interruptiblesapparaître dans une zone fixe prévue à cet effetpermettre le positionnement automatique sur l’erreur

Les messages d’erreur peuvent :être mis en valeur à l’aide d’attributs de visualisationparfois renvoyer à une documentation complémentaire

237


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’utilisateurtrouver 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é lumineuseinversion vidéoclignotementcouleursoulignement, italique, gras, …

241


Couleurs :ne pas utiliser plus de 4 (maximum 6) couleurs différentespenser 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


Autres :pas plus de 2 valeurs différentes d’intensité lumineuseéviter le clignotement, surtout si l’utilisateur ne peut pas l’arrêterutiliser l’inverse vidéo pour des messages d’erreur ou d’alerte, mais seulement pour des petites surfacesutiliser 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


Termes :utiliser les termes habituels de l’utilisateurles 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 fonctionsproches des substantifs pour des rubriques (titres)

245


Abréviations :doivent permettre une reconstitution spontanée du mot entierpré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ériqueun code numérique est meilleur qu’un code alphanumérique

246


247

Norme AFNOR Z67-133-1

Une étude de la facilité d’utilisation des IHM en 7 critères :

compatibilitéguidagehomogénéitésouplessecontrôle explicitegestion des erreursconcision

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 perceptionde mémorisationde traitement de l’information

d’un utilisateur pendant qu’il effectue son travailSurcharge :

les activités mentales de l’utilisateur sont sur-utiliséesSous-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 conceptsles informationsles représentationsles procédures

Qui font partie de l’univers de travail réel de l’utilisateur et de sa culture (professionnelle et personnelle)

251


Il faut étudier l’univers de l’utilisateur :la représentation qu’ils ont de leurs tâchesleurs 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’utilisationdéfinir le traitement des informationsdéfinir la navigation dans l’application

252


Objectifs :établir la correspondance entre les connaissances, les besoins des utilisateurs et les possibilités offertes par le logicielpermettre à l’utilisateur de retrouver un univers familier et habituelfaciliter l’apprentissagerendre efficace la communication homme-machinerendre l’information directement utilisable

253


Exemples :procédures d’utilisation conformes à la logique de l’utilisateurorganisation des fonctions conforme à la représentation de la tâcheordre des items lié à la tâchevaleurs par défautvocabulaire et codes repris de l’univers du travail

254


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 informatiqued’établir les liens de causalité entre ses actions et l’état du systèmed’évaluer et d’orienter son action sur le système informatique

Explicite : présenté formellement , à la demande de l’utilisateurImplicite : relève de la présentation et de l’organisation des informations affichées

256

Guidage (2/4)

Objectifs :faciliter l’apprentissageaider l’utilisateur à se repéreraider l’utilisateur à choisir ses actionspré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’utilisateurdiminuer le temps de recherche d’une informationfaciliter la prise d’information

260


Exemples :attributs de visualisationstabilité de la présentation des informationsun seul endroit pour l’affichage d’une même informationun seul nom pour une seule fonctionune même procédure conduit toujours au même résultatrespect de standards de présentation

261


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érienced’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 utilisateurspermettre à l’utilisateur d’obtenir un résultat identique par plusieurs procédures

Exemples :mode débutant = guidage renforcémode expert = procédures raccourciespossibilité de paramétrer ou de chaîner des commandes fréquemment utiliséesparamé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 effetsles effets de la commande soient entièrement prévisibles par l’utilisateur

266


Objectifs :respecter l’autonomie de l’utilisateur dans ses interactions avec le système informatiquefavoriser la prévision des réactions de l’interfacefavoriser l’apprentissagediminuer les risques d’erreurs

Exemples :prévoir une action explicite de validationsignaler les options actives dans les menusboîtes de messagespouvoir interrompre une impression

267


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 erreursconserver l’intégrité de l’application (éviter l’altération des données et des traitements)

269


Objectifs :rassurer l’utilisateuréviter les perturbations (blocage, anxiété, …) associées àla difficulté de corriger des erreurs commisesfavoriser 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


Exemples :annulation des effets de la dernière commande (undo)messages d’erreurclarté du codage utilisé pour les messages d’erreursdésactiver l’effet d’une fonction non utilisable dans le contexte de l’applicationaperçu avant impression

271


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ë possibleminimiser le nombre d’actions ou d’opérations à effectuer ainsi que le temps de manipulation

273

Concision (2/3)

Exemples :accélérateursoptions par défauticônesstructuration 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 formaliserUML…

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.

Spécification - Modèles - Outils Prise en compte des utilisateurs › thierry.duval › Documents...

Documents

Transcript of Spécification - Modèles - Outils Prise en compte des utilisateurs › thierry.duval › Documents...