C.1 Extension du modèle des dispositifs

Comme nous l'avions déjà évoqué dans le chapitre 6, le modèle ICOM définit quatre niveaux de contrôle des applications et des boîtes à outils graphique (voir figure C.1):
  1. le contrôle par défaut, niveau de contrôle d'une application «sans ICON»;
  2. le contrôle générique de surface, au plus haut niveau des widgets d'une boîte à outils;
  3. le contrôle générique de modèle, spécifique à un type de widget, court-circuitant les méthodes d'entrée de la boîte à outils;
  4. le contrôle dédié, la stratégie la plus puissante décrivant le contrôle complet d'une application par des dispositif d'application dédiés.

Figure C.1: Niveaux de contrôle d'un système interactif avec ICON.
\includegraphics[width=350pt]{controle}

On peut donc définir deux grandes tendances pour réaliser une application avec ICON:

  1. concevoir une application avec une boîte à outils graphique, ou en modifier une existante. Il faut alors utiliser des dispositifs de boîte à outils graphique, définis comme des dispositifs «situés à mi-chemin entre la catégorie des dispositifs utilitaires et celle des dispositifs d'application, (ils) permettent un contrôle générique de ces dernières»  [Dragicevic et Fekete2004]. Le niveau de contrôle est alors générique, de surface ou de modèle. Des exemples de telles applications ont étés fournis par Pierre DRAGICEVIC en utilisant les boîtes à outils graphiques Swing ou Jazz.
  2. concevoir une application originale, à partir d'un environnement graphique de bas niveau (Java2D, par exemple) et externaliser les outils, les tâches de cette application sous forme de dispositifs d'application. Le contrôle est alors au niveau le plus profond, il est dédié.
Le premier point facilite le développement de l'application, en permettant l'utilisation d'une boîte à outils graphique. Par contre, il implique des concessions au niveau du contrôle de ses entrées et de ses interactions, ainsi qu'un lourd travail de développement de dispositifs si la boîte à outils utilisée n'est pas encore supportée par ICON.
Le second point offre un niveau maximal de contrôle, permettant au développeur de rendre contrôlables et configurables toutes les interactions de l'application par l'intermédiaire des configurations d'entrée. Toutefois, cela demande un gros travail de programmation au niveau de l'application (pas ou peu d'abstractions et de composants des boîtes à outils graphique) mais surtout une bonne connaissance de la conception de dispositifs ICON.

Grâce au modèle des graphes combinés et de sa réalisation dans MAGGLITE, nous proposons une autre alternative: utiliser une boîte à outils graphique dont les applications sont entièrement contrôlées par ICON, avec les points d'accès à l'interaction. Ce sont donc des dispositifs d'application, mais génériques. Nous étendons cette notion et l'intégrons dans le modèle ICOM par la définition suivante:

Définition C..1   Les dispositifs génériques d'application forment une sous-classe des dispositifs d'application du modèle ICOM. Ce sont des dispositifs d'application réutilisables, permettant le contrôle dédié d'un type d'applications donné.

De tels dispositifs permettent donc d'atteindre le niveau de contrôle maximal (contrôle dédié) dans des applications, en utilisant des dispositifs de boîte à outils (jusqu'alors limités aux contrôles génériques de surface et de modèle). Leur première réalisation dans la boîte à outils MAGGLITE offre une granularité encore plus fine au modèle ICOM, permettant de séparer à un niveau encore plus bas les interactions du noyau fonctionnel de l'application.

Du point de vue du développeur, cette séparation en deux niveaux des dispositifs d'application implique il est vrai une certaine réflexion dès lors qu'il doit réaliser des fonctionnalités particulières en utilisant MAGGLITE:

  1. Est-il possible à partir des dispositifs déjà disponibles de réaliser ces fonctionnalités en composant une configuration d'entrée avancée ?
    Si tel est le cas, il n'est pas nécessaire d'avoir recours à la programmation.
  2. Sinon, ces fonctionnalités peuvent-elles être séparées de l'application pour laquelle elles ont été pensées ?
    Si tel est le cas, elles peuvent être introduites dans la boîte à outils comme dispositifs génériques d'application sous différentes formes:
    1. un dispositif d'interaction, dans le cas d'une technique d'interaction;
    2. une nouvelle classe d'objet graphique, et donc son manipulateur associé;
    3. un dispositif de comportement;
    4. ou un outil interne.
    Ces dispositifs deviennent alors réutilisables pour toutes les applications.
  3. enfin, si ce sont vraiment des fonctionnalités propres à l'application, elles doivent être implémentées lors de la réalisation de l'application, et rendues accessibles par des dispositifs d'application (ou par l'intermédiaire du dispositif de l'application que propose le modèle des graphes combiné).

Pour le concepteur d'interfaces, cette notion de dispositifs génériques de l'application offre un grand pouvoir d'expression. Il peut en effet très rapidement prototyper de nombreux styles d'interaction en conjuguant les dispositifs disponibles de plusieurs manières possibles. Il peut ainsi explorer divers paradigmes pour une même interface: gestes, reconnaissance vocale, mais aussi instruments en association directe avec des composants graphiques, etc.

stuf
2005-09-06