Dégradation harmonieuse d'interfaces utilisateur - UsiXML

5.7 Description du fonctionnement des modules et des structure de données retenues
pour l’application des règles de dégradation
De manière à rester fidèle à la démarche suivie pour la hiérarchie en couches de notre
architecture, nous décrirons chaque structure de données utilisée et algorithme de notre
application par couche et par module, en commençant par la plus basse.
5.7.1 La Couche Description des interfaces utilisateur
Pour l’unique module qui compose cette couche, nous nous contenterons de décrire la
manière de représenter les éléments pertinents qui seront utilisés par la suite.
Les modèles de la tâche et du domaine
Nous utiliserons pour modéliser les modèles de la tâche et du domaine une structure unique,
permettant de résumer l’information utile et nécessaire à l’application des règles de
dégradation harmonieuse que nous avons retenues, ceci permettant également de réaliser dans
la foulée un mapping entre ces deux modèles. Ainsi, nous gagnons en rapidité, toute
l’information restant concentrée en un seul modèle. Bien entendu, le fait de vouloir tout réunir
dans une seule structure peut introduire une certaine limitation dans les possibilités de
l’application mais nous allons montrer que ce n’est pas le cas en ce qui concerne la nôtre.
Voici de manière plus détaillée la manière dont nous représenterons notre modèle :
Notre modèle consistera en un modèle de tâche prioritaire (voir point 5.4.2.1), pour lequel
chaque tâche comportera, en plus des informations qui s’y rapportent, le type de données
manipulé (et donc des éléments du domaine). Pourquoi inclure ces données dans le modèle de
tâche plutôt que de consacrer un modèle dédié aux éléments du domaine ? Simplement car
dans le cadre de notre travail, il n’est pas nécessaire de connaître toute l’information sur le
domaine manipulé. Seul le type de donnée et les valeurs possibles sont utiles.
Ceci pourrait introduire quelques inconvénients car, ne disposant plus que de l’information
sur les attributs et non plus sur les classes, il nous est alors impossible de mettre en liaison
deux tâches manipulant le même attribut. On peut citer par exemple, une tâche de consultation
dans une liste de sélection qui serait suivie d’une tâche de sélection sur le même objet
interactif. Néanmoins, nous sommes partis de l’heuristique qu’une tâche interactive
manipulait un unique objet interactif. De plus, il est très simple de contourner ce problème en
fusionnant les deux tâches de l’exemple en une seule.
Le problème serait plus difficile à résoudre si les tâches n’étaient pas adjacentes. Cependant,
on peut se convaincre qu’une application d’un tel type n’est franchement pas ergonomique car
elle suggère à l’utilisateur de revenir sur un objet interactif déjà « visité ». A moins que cet
objet ne se répète sur plusieures présentations séparées, il est réellement peu crédible
d’imaginer un tel cas.
En réalité, le seul inconvénient de ce modèle transparaît si nous décidions d’appliquer une
règle de dégradation sur le niveau Tâches & Concepts. Si nous supprimons une tâche, il n’y a
pas de problème. Par contre, si nous décidons de supprimer une classe ou un attribut, il n’y a
pas moyen de retrouver quelle tâche supprimer. Ceci pourrait néanmoins être résolu en
spécifiant, en plus du type de donnée manipulé, le nom de la classe ou de l’attribut cible.
82