User Tools

Site Tools


ipm:tech-conception

Conception de l'interaction

Lors de la phase d'analyse on détermine un ensemble de besoins et de contraintes : quelles tâches doit-on pouvoir faire ? Pour quels utilisateurs ? Dans quel contexte ? Le but de la conception de l'interface est d'arriver à un design concret d'interface qui corresponde bien à ces besoins et contraintes.

Comme pour tout travail de conception, il n'existe a pas d'algorithme qui conduise infailliblement à une bonne interface à partir d'une spécification de l'application ou du système. Cependant, le concepteur d'interface peut s'appuyer sur un ensemble de modèles d'interface, de composants concrets ayant fait leurs preuves (fenêtres, boutons, menus, icônes, etc.) et de principes ergonomiques.

Nous étudierons ici le problème consistant à passer des résultats d'analyse à un design d'interface qui permet de réaliser les tâches prévues. Ce design devra ensuite être raffiné par l'application de critères ergonomiques.

1. La réalisation des tâches dans l'interface

L'analyse des tâches répondait à la question «quoi faire avec le système?» La conception s'attaque au comment. L'analyse des tâches a mis en évidence les tâches à prendre en charge, leur éventuelle décomposition en sous-tâches et des scénarios concrets d'utilisation. Il s'agit maintenant de

  • prendre des décisions sur la réalisation concrète des tâches dans l'interface. Par exemple, si l'analyse de la tâche A a montré qu'elle se décompose en B et C, qui peuvent se dérouler en parallèle, on peut décider qu'en pratique l'utilisateur devra faire C avant B.
  • décomposer les tâches jusqu'au niveau des actions considérées comme élémentaires dans l'interface (cliquer un bouton, saisir un texte, sélectionner un élément de menu, etc.)

Réalisation des tâches dans UML: les scénarios et les séquences

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.

Exemple. Scénario: Chercher dans le catalogue

  • 1. l'utilisateur clique le bouton “chercher”
  • 2. le système affiche un champ de saisie de texte
  • 3. l'utilisateur entre un ou plusieurs mots clés dans ce champ
  • 4. l'utilisateur valide l'entrée en cliquant le bouton “OK”
  • 5. 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

ou bien

tant que condition faire séquence .

Exemple. Scénario: retirer des billets à un distributeur

  1. l'utilisateur entre le montant désirée avec le clavier
  2. l'utilisateur presse 'OK'
  3. la machine vérifie si le montant est réalisable avec les billets à disposition
  4. tant que somme non réalisable faire :
    • le système propose un autre montant
    • l'utilisateur peut changer le montant
    • si l'utilisateur presse “STOP” alors terminer la transaction
    • l'utilisateur presse 'OK'
  5. la machine prépare les billets
  6. la machine éjecte la carte de l'utilisateur
  7. l'utilisateur prend les billets
  8. la machine affiche un message de fin de transaction

Réalisation des tâches avec TRIDENT: graphes d'enchainement d'activités

Le système et la méthodologie TRIDENT ont été conçus pour développer des application de gestion hautement interactives. Le processus de conception comprend les étapes décrites dans le diagramme ci-dessous. Ce processus présente plusieurs caractéristiques intéressantes :

  • il prend comme point de départ un analyse des tâches, centrée sur l'utilisateur, et une analyse des besoins fonctionnels, centrée sur le domaine d'application du système d'information. On retrouve ici la séparation entre interface et noyau fonctionnel
  • la définition de la présentation (unités de présentation) se base sur un graphe liant tâches, fonctions et données
  • les choix d'objets d'interaction interviennent à la fin du processus et sont pilotés par des critères ergonomiques, tels les chartes de Vanderdonckt.

Contrairement à l'analyse des tâches, qui est tournée vers l'utilisateur, l'analyse des besoins fonctionnels concerne le système technique. Elle a pour but de définir quelles fonctions doivent être implémentées dans le système. L'idée est qu'à chaque action élémentaire identifiée dans l'analyse des tâches doit correspondre une fonction interne du système (également appelé noyau sémantique). La spécification des fonctions s'appuie sur une modélisation des données sous forme de diagramme du type entité-relation (similaire aux diagrammes de classe UML). Pour chaque fonction on spécifie les les types d'entités et de relation en entrée et en sortie. Par exemple, une action Enregistrer_coordonnées_client aura besoin en entrée d'un nom, d'un prénom et d'une adresse et produire en sortie un identifiant_de_client.

Le graphe d'enchainement des activités est le point de connexion entre les concepts orientés utilisateur (tâches, actions, …) et les concepts orientés application (information et fonction). Il définit un contrat entre le responsable du noyau sémantique et le responsable du dialogue.

Il y a deux sortes de noeuds dans le graphe, représentant les activités d'une part et les types de données d'autres part. Les arcs connectent les données d'entrée aux activités et les activités à leurs données de sorties. De plus, un opérateur booléen indique si toutes les données sont nécessaires en entrée (AND) ou seulement l'une d'entre elles (OR) ou l'une à l'exclusion des autres (XOR). De même l'opérateur de sortie indique si l'activité produit toutes les données indiquées (AND) ou seulement l'une d'entre elle (XOR). Des noeuds intermédiaires permettent de combiner les opérateurs de manière plus complexe.

Dans l'exemple ci-dessous on voit que l'activité Validate_Cust_fl a besoin du nom (LastN) et du prénom (FirstN) et produit soit une erreur soit un identifiant de client valide (Valid_Cust_id) et un numéro de client, rue, numéro, code postal et ville (Cust_id, etc.). De même, l'acitivé Modify_Address a besoin d'une rue (Street}) ou d'un numéro (Number) ou … et d'un Valid_Cust_id qui provient soit de Validate_Cust_fl} soit de Validate_Cust_id (mais pas des deux).

2. Conception du dialogue et de la navigation

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éroport 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 figure suivante montre une page web qui regroupe 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.

Storyboard

La manière la plus informelle de présenter le flux d'interaction est le storyboard. Dans ce type de diagramme, chaque boîte représente une vue d'interaction (fenêtre, page web, …). Les flèches indiquent quelle action va déclencher la passage d'une vue à une autre. Le diagramme suivant présente un storyboard partiel de l'interface d'un agenda sur téléphone mobile.

L'intérêt du storyboard est de donner une vue globale de l'interface. Il met en évidence la topologie de la navigation (linéaire, arborescente, graphe acyclique, cyclique, etc.) et permet de l'adapter en fonction du degré de liberté à donner à l'utilisateur.

Les assistants de configuration ou d'installation de logiciels ont souvent une organisation linéaire : à chaque étape l'utilisateur doit saisir un certain nombre de données puis il a le choix entre avancer à l'étape suivante ou revenir à l'étape précédente (ou abandonner), car l'objectif est de guider l'utilisateur dans l'exécution de sa tâche. Certains sites web on une organisation arborescente : on peut monter ou descendre d'un niveau dans l'arbre des pages, mais pas naviguer horizontalement. L'utilisateur n'a pas une grande liberté de navigation mais en échange il se repère mieux dans le site.

Graphe de dialogue

La figure ci-dessous 1) montre un graphe de dialogue plus sophistiqué qu'un simple storyboard. 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.

Unités de présentation et graphe d'enchainement

Dans la méthode TRIDENT les vues sont appelées unités de présentation, elles sont définies en délimitant des zones du graphe d'enchaînement d'activités.

Une unité de présentation est un espace d'entrée et d'affichage composé d'une ou plusieurs fenêtres logiques pour effectuer une sous-tâche. On représente les UP sur le graphe d'enchaînement simplement en entourant les fonctions et informations liées à la sous-tâche.

3. Choix des objets d'interaction

Une interface est toujours composée d'un ensemble d'objets d'interaction tels que fenêtres, boutons, menus, zones de texte, barres de défilement, cadrans, graphiques, etc. Pour sélectionner les objets d'interaction les plus appropriés pour un tâche on peut procéder en deux étapes

  1. choix abstrait (types d'objets)
  2. concrétisation (caractéristiques précises)

Au niveau abstrait on définit la composition de l'interface : quels types d'objets d'interaction employer. .

Le choix peut être guidé par des critères ergonomiques établis pour chaque type d'objet. On sait, par exemple, que pour effecteur l'action « choisir entre deux options » il vaut mieux utiliser des boutons radio plutôt que de saisier le nom de l'option dans un champ de texte. Pour les actions de type «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.

Les objets concrets sont ceux que l'utilisateur va percevoir et manipuler. On peut les considérer comme des objets abstraits pour lesquels on a précisé tout ce qui est nécessaire à leur présentation : position, taille, couleur, etc.

La conception des objets concrets 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 :

FIXME

  • 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, …).

À nouveau, ces choix peuvent être guidés par des principes ergonomiques de mise en page ( séquence horizontale/verticale; justifications (G/D/H/B); centrage horizontal, vertical; uniformisations horizontal, vertical; équilibre diagonal, horizontal, vertical, proportionnel, total)

Une fois les objets concrets définis on peut générer un prototype de l'interface.

1) Peter Forbrig, Anke Dittmar, Daniel Reichart, Daniel Sinnig. From Models to Interactive Systems Tool Support and XIML
ipm/tech-conception.txt · Last modified: 2013/03/09 23:04 by gilles