Cours ISI - Conception de l'interaction
From Isiwiki
| ← Principes ergonomiques | ^ Cours ISI | → Prototypage et test |
Comme pour tout travail de conception, il n'existe a pas d'algorithme qui conduise infailliblement à une bonne interface à partir d'une spécificiation de l'application ou du système. On peut distinguer deux manière d'attaquer le problème de la conception.
- Dans une approche orientée prototypage on privilégie le développement rapide de prototypes, suivi de tests, suivi d'une amélioration du prototype, de nouveaux tests, et ainsi de suite.
- Dans une approche orientée modèle on construit des modèles (de tâches, de données, de dialogue, etc.) qui permettent de constuire ou de générer une interface adéquate.
Le prototypage sera traité dans un chapitre à part, nous présenterons ici l'approche orientée modèle.
Notons que la conception, quelle que soit l'approche, doit se baser sur l'analyse préalable des tâches, des utilisateurs, du contexte.
Contents |
[edit] Les modèles
Dans les approches orientées modèle on trouve en général
- un modèle de tâches
- un modèle de dialogue
- un modèle d'interface abstaite (objets d'interfaces générique)
- un modèle d'interface concrète (incluant en particulier le placement des objets, leur taille, couleur, etc.)
D'un point de vue méthodologique on commencera par définir les modèles de tâches puis le modèle de dialogue, et enfin les modèles d'interface abstraite et concrète, qui découlent du dialogue et mettent en oeuvre les principes ergonomiques. Dans ce qui suit nous présenterons différents manières (notations) de créer ces modèles.
[edit] La conception des tâches
L'analyse des tâches répondait à la question "quoi faire avec le système?" La conception s'attaque au comment.
Partant d'un résultat d'analyse des tâches qui aura mis en évidence les tâches à prendre en charge, leur éventuelle décomposition en sous-tâches et des scénarios concrets d'utilisation, la conception de l'interaction consiste à
- décomposer les tâches jusqu'à un niveau jugé suffisamment élémentaires (actions)
- fixer des choix, par exemple des contraintes de précédence entre tâches
[edit] Conception des tâches dans UML: les scénarios
UML ne propose que peu d'outils de modélisation de l'interaction et des interfaces. Après la phase d'analyse des besoins qui a mis en évidence les cas d'utilisation, la conception de l'interaction consiste essentiellement à définir les scénarios associés à chaque cas.
Un scénario décrit une séquence d'interactions entre l'utilisateur et le système (un flux d'évènements), soit en langue naturelle, soit en pseudo langue naturelle.
Scénario: Chercher dans le catalogue
- l'utilisateur clique le bouton "chercher"
- le système affiche un champ de saisie de texte
- l'utilisateur entre un ou plusieurs mots clés dans ce champ
- l'utilisateur valide l'entrée en cliquant le bouton "OK"
- le système affiche une liste d'articles pertinents.
Un scénario n'est pas forcément linéaire, il peut contenir des alternatives et des répétitions. Dans ce cas il est préférable d'utiliser des constructions semi-formelles du type
- si Condition alors Séquence sinon Séquence
- tant que Condition faire Séquence
Scénario: retirer des billets à un distributeur
- l'utilisateur entre le montant désirée avec le clavier
- l'utilisateur presse 'OK'
- la machine vérifie si le montant est réalisable avec les billets à disposition
- tant que somme non réalisable faire :
- le système propose un autre montant
- l'utilisateur peut changer le montant
- l'utilisateur presse 'OK'
- la machine prépare les billets
- la machine éjecte la carte de l'utilisateur
- l'utilisateur prend les billets
- la machine affiche un message de fin de transaction
[edit] Conception des tâches avec un modèle formel
Les modèles formels de tâche permettent de définir avec une syntaxe et une sémantique précise les relations temporelles entre tâches. Ces modèles sont en général basés directement ou indirectement sur des formalismes biens connus tels que les automates à états ou les réseaux de Petri ou encore les diagrammes d'états.
Le formalisme utilisé dans TRIDENT, l'un des grands précurseurs de l'approche orientée modèle, est proche des réseaux de Petri. Le graphe d'enchaînement des activités fait intervenir les données nécessaires aux tâches (données d'entrées avec opérateurs AND ou OR) et les données produites en sorties (avec AND et XOR) et qui serviront à d'autres tâches. Ce graphe détermine les contraintes temporelles qui vont exister entre les tâches.
→ Lire l'article sur TRIDENT
Concur Task Tree (CTT) est un modèle hiérarchique de tâches dans lequel les contraintes temporelles (séquence, alternative, parallèlismen, etc.) entre tâches sont basées sur l'algèbre de processus LOTOS.
→ Lire l'article sur CTT
L'avantage des modèles formels réside dans la possibilité de
- tester automatiquement certaines propriétés (par exemple l'atteignabilité de certains états)
- exécuter une simulation (interactive) du déroulement de l'interaction.
- générer automatiquement un prototype fonctionnel d'interface, à condition d'enrichir les descriptions de tâches avec les types de données traitées et d'autres paramètres
[edit] Conception du dialogue
Avec la conception du dialogue on s'approche de la réalisation de l'interface. La notion de dialogue est basée sur le concept de vue de dialogue, qui regroupent plusieurs tâches élémentaires et qui vont s'enchaîner au cours de l'utilisation de l'interface. Dans une interface de type WIMP une vue sera une fenêtre ou un conteneur d'objets d'interface (une zone d'une fenêtre, un panneau, un formulaire, etc.). Dans une interface Web une vue sera essentiellement une page HTML et l'enchaînement des vues se fera en cliquant des ancres de liens hypertextes.
Le but d'une vue est de regrouper les objets d'interface qui participent à une tâche ou à un ensemble de tâches fortement liées. Par exemple, dans un système de réservation de billets d'avion on pourra avoir une vue qui regroupe les sous-tâches sélectionner aéroport de départ, sélectionner aéropoert d'arrivée, sélectionner jour et heure de départ, sélectionner jour et heure d'arrivée, définir le nombre de personnes, etc. La page web ci-dessous montre un exemple de regroupement de ces tâches
Le résultat de la conception du dialogue est en général un graphe dont les noeuds sont des groupes de tâches et les arcs des possibilités d'enchaînements. Dans la méthode TRIDENT les vues sont des unités de présentation définies en délimitant des zones du graphe d'enchaînement d'activités (Voir dans l'article TRIDENT).
La figure ci-dessous montre un graphe de dialogue pour l'interface d'un magasin électronique. Chaque vue contient sa liste de tâches. Les transitions entre vues peuvent être séquentielles (flèche noire) ou concurrentes (flèches blanches). Une transition séquentielle ferme la vue de départ alors qu'une transition concurrente la laisse ouverte.
Peter Forbrig, Anke Dittmar, Daniel Reichart, Daniel Sinnig. From Models to Interactive Systems
Tool Support and XIML
[edit] Objets d'interaction abstraits
Pour faciliter la conception et la programmation des interfaces il est vite apparu intéressant de décomposer une interface en objets d'interaction élémentaires tels que les boutons, menus, zones de texte, barres de défilement, etc. La programmation orientée-objet a du reste connu ses premiers succès dans le domaine du développement des interfaces, avec Smalltalk pour les machines Xerox puis Object Pascal pour le Macintosh ou encore Objective-C pour le Next.
D'un point de vue méthodologique, un concepteur a tout intérêt à retarder le plus longtemps possible les choix qui l'engagent dans une voie plutôt qu'une autre (delaying commitment). Ce principe, appliqué aux objets d'interaction, a conduit à distinguer l'aspect abstrait et concret des objets d'interaction. Un objet d'interaction abstrait est essentiellement défini par son type (fenêtre, menu, bouton, barre de défilement, etc.), sans préciser la forme définitive qu'il aura dans l'interface.
Au niveau abstrait on définit donc la composition de l'interface (de quels types d'objets elle est faite). Ce choix doit bien entendu être guidé par des critères ergonomiques. On sait, par exemple, que pour choisir entre deux ou trois options il vaut mieux utiliser des boutons radio plutôt que de saisier le nom de l'option dans un champ de texte. Pour tout ce qui relève du choix d'une ou plusieurs valeurs parmi un ensemble on peut se référer aux critères ergonomiques pour les objets de sélection établis par J. Vanderdonckt.
[edit] Objets d'interaction concrets
La conception des objets conrets consiste à fixer, pour chaque objet abstrait, tous les attributs nécessaires à son apparence dans l'interface : taille, position, couleur, police de caractères, volume sonore, etc. Ce travail peut s'appuyer sur différents critères ergonomiques (voir le chapitre Cours ISI - Principes ergonomiques). On relèvera en particulier :
- pour le choix des couleurs : les problèmes de vision des couleurs, les questions culturelles, les problèmes d'interactions entre couleurs (voir Cours ISI - Texte)
- pour le placement : les principes de Gestalt sur la perception des alignements et des regroupements
- pour la taille : la loi de Fitt
On utilisera également les guides établis pour la ou les plateformes visées (Mac, Windows, Java, Gnome, KDE, ...).
[edit] Conception basée sur les données ... une fausse bonne idée
Dans les applications dites "data intensive", telles que la consultation d'un catalogue ou d'une base de données, il peut être tentant de concevoir l'interface à partir de la structure de données dont on dispose. L'expérience et la théorie prouvent que c'est rarement une bonne idée. Ceci pour les raisons suivantes
- la modélisation des données poursuit un but ontologique, elle sert à mettre en évidence et à catégoriser les objets à traiter, il n'y a pas de lien explicite avec les objectifs des utilisateurs, les structures de données sont plus près de l'être que du faire
- les structures de données sont faites pour permettre l'écriture d'applications, elles sont destinées aux développeurs, pas aux utilisateurs
- les structures de données évitent la redondance, au contraire, la redondance est nécessaire dans une interface
[edit] Exemple
Dans la modélisation des données d'une bibliothèque on distingue, à juste titre, la notion d'ouvrage (un livre écrit par un auteur) et la notion d'exemplaire (l'objet physique que l'on prête). Par contre un usager de la bibliothèque ne fait en général pas cette distinction, il veut savoir où trouver le livre sur les étagères.
Par exemple, dans le système RERO une recherche avec le mot clé "Dix" fournit
Si l'on veut savoir où trouver le livre il faut encore cliquer "Cotes et exemplaires" pour obtenir
L'interface suit le modèle de données plutot que le besoin de l'utilisateur qui est de voir immédiatement la cote du livre cherché.
