Cours ISI - TRIDENT
From Isiwiki
Cette brève présentation de TRIDENT est basée sur l'article
François Bodart Anne-Marie Hennebert Jean-Marie Leheureux Jean Vanderdonckt. A Model-Based Approach to Presentation: A Continuum from Task Analysis to Prototype. In Proc. DSVIS conf. 1994.
Contents |
[edit] Introduction
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écrite dans le diagramme ci-dessous. Ce processus présente plusieurs points intéressants :
- 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.
[edit] Tâches
Le modèle de tâches est hiérarchique : les tâches se décomposent en sous-tâches, jusqu'au niveau des actions. Par exemple :
Application Product Management Application
Interactive task : Phone order
Sub-task 1 : Identification of a customer
Action 1 : modify the address of a customer
Action 2 : search a customer by identification number
Action 3 : search a customer by firstname and lastname.
Sub-task 2 : Definition of the order
Sub-task 3 : Record of the order
Une tâche est également décrite par des attributs tels que : quantité de pré-requis (pour l'utilisateur); productivité (fréquence d'occurrence); environnement objectif (existence d'objets pour accomplir la tâche); reproductibilité de l'environnement; niveau de structuration; importance; complexité (pour l'utilisateur)
[edit] Utilisateurs
On définit des stéréotypes d'utilisateur en spécifiant :
- expérience de la tâche
- expérience du système
- motivation facteur subjectif de satisfaction
- expérience de média à interactions complexes
[edit] Besoins fonctionnels
La spécificiation fonctionnelle indique 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 (noyau sémantique). On spécifie les besoins fonctionnels à l'aide d'un modèle de données de type Entité-Relation. Pour chaque fonction on indique 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.
[edit] Graphe d'enchainement des activités
Ce graphe 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 lea 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'exlcusion 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).
[edit] Sélection du style d'interaction
Chaque tâche peut être réalisée dans un style d'interaction différent (langue naturelle, langage de commande, langage de requête, questions/réponses, touches de fonctions, manipulation directe, interaction iconique,...). En général on combinera plusieurs styles.
TRIDENT propose de choisir le style à partir d' attributs de dialogue que l'on choisit en fonction du type d'utilisateur et de la tâche. Ces attributs sont :
- le contrôle du dialogue (internal, external or mixed;
- le mode de dialogue (sequential or asynchronous);
- le déclenchement
- automatic if the user interface has the initiative,
- manual if the user has the initiative,
- implicit if automatically deduced from the user actions (e.g. field exit),
- explicit if resulting from a dedicated user action (e.g. control manipulation)
- displayed if the action provides a visible feedback (e.g. an "Ok" pushbutton),
- undisplayed if the action does not have any visual cue (e.g. F10 function key);
- la métaphore (onversation ou interaction graphique)
Enuite, des tables peuvent fournir, pour chaque combinaison de valeurs d'attributs de dialogue le style le plus approprié.
[edit] Définition des unités de présentation
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.
Du point de vue de l'interface, une UP est composée, au niveau logique, d'objets d'interaction abstraits. Ces objets sont des abstraction des objets d'interaction concrets que l'on trouvera sur l'interface implémentée et que l'utilisateur pourra voir (entendre, ...) et manipuler. Les OIA se répartissent en plusieurs catégories :
| Catégorie | Exemples d'objets |
| action | menu, menu item, menu bar, pulldown menu, cascade menu |
| scrolling | scroll arrow, scroll cursor, scroll bar, frame |
| static | label, separator, group box, prompt, icon |
| control | edit box, scale, dial, check box, switch, radio box, spin button, push button, list box, drop-down list box, combination box, table |
| dialogue | window, dialogue box, expandable dialogue box, radio dialogue box, panel |
| feedback | message, progression indicator, contextual cursor |
Exemple de spécification d'une UP
DEFINE PRESENTATION-UNIT Customer_Identification;
CONSISTS OF Customer_Identification_Window; (* Only one window in this PU *)
DIALOGUE MODE IS ASYNCHRONOUS;
TRIGGERING MODE IS EXPLICIT MANUAL DISPLAYED;
CONTROL IS MIXED;
METAPHOR IS CONVERSATION;
DEFINE INTERACTION-OBJECT Customer_Identification_Window;
IS INSTANCE OF Window;
IS COMPOSED OF Customer_GroupBox, Address_GroupBox, Ok_PushButton,
Cancel_PushButton, Help_PushButton;
DEFINE INTERACTION-OBJECT Customer_GroupBox;
IS INSTANCE OF GroupBox;
IS COMPOSED OF Id_Label, Id_EditBox, Firstname_Label, Firstname_EditBox,
Lastname_Label, Lastname_EditBox, Search_PushButton;
IS COMPONENT OF Customer_Identification_Window; ...
[edit] Objets concrets
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.
À 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.
