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):
- le contrôle par défaut, niveau de contrôle d'une application «sans ICON»;
- le contrôle générique de surface, au plus haut niveau des widgets d'une boîte à
outils;
- 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;
- 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.
|
On peut donc définir deux grandes tendances pour réaliser une application avec ICON:
- 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.
- 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:
- 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.
- 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:
- un dispositif d'interaction, dans le cas d'une technique d'interaction;
- une nouvelle classe d'objet graphique, et donc son manipulateur associé;
- un dispositif de comportement;
- ou un outil interne.
Ces dispositifs deviennent alors réutilisables pour toutes les applications.
- 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