suivant: Conclusion monter: 9. Positionnement et discussions précédent: 9.6 Techniques d'interaction avancées Table des matières Index
Ces apports font de MAGGLITE un outil adapté au prototypage et à la conception d'interfaces innovantes et d'interactions non-standard. Notre approche ne se veut pas exhaustive en terme de problèmes résolus et d'intégration de techniques d'interaction. Par contre, son ouverture et sa flexibilité permettra de juger de sa pertinence et de ses limites.
Pierre DRAGICEVIC a déjà évoqué ce problème dans sa thèse [Dragicevic2004b] et a proposé des pistes pour une hybridation de son modèle en flot de données avec des approches orientées contrôle:
Notre modèle des graphes combinés pourrait apporter une nouvelle solution à un niveau intermédiaire: un système de transition configurable graphiquement tel que Pet Shop [Bastide et al.2002] contrôlerait la connexion dynamique des IAPs aux composants du graphe de scène et des objets d'intérêt de l'application, sans briser la cohérence des graphes d'interaction (deconnexions et reconnexions des flux d'interaction).
Actuellement, les différents niveaux de programmation d'applications interactives avec notre boîte à outils sont:
Au niveau des graphes d'interaction, la modularité et la décomposition fine en de nombreux dispositifs montre ses limites pour la réalisation de techniques complexes. Ce n'est pas le modèle en lui-même qui est en cause, mais surtout la complexité visuelle et la compréhension de configurations d'entrées complexe. Il est alors nécessaire de se poser la question de la réalisation de nouveaux dispositifs pouvant «généraliser» et «factoriser» la technique à décrire. Bien que cette approche nécessite un retour à la programmation traditionnelle, elle demeure selon nous indispensable. Nous n'y voyons toutefois pas une régression de notre approche, le principe des dispositifs IAPs encourageant et facilitant d'ailleurs cette démarche dans un cadre de réutilisabilité et de généricité. Il est toutefois important de considérer le problème du choix du niveau de granularité lors de la création de nouveaux dispositifs et de proposer des principes de conception pour aider les développeurs dans cette optique.
Outre la nécessité d'améliorer les outils qu'elle propose pour permettre la création de graphismes avancés (gradients de couleurs, effets, ombres, etc.), la création interactive de composants graphiques pose aussi le problème de la définition d'objets du domaine ou composants métier. Actuellement, les objets graphiques de la boîte à outils sont essentiellement des vues, n'offrant pas un modèle de description et de communication de haut-niveau. La partie métier nécessite donc d'être programmée au niveau de l'application ou dans de nouvelles classes d'objets graphiques (composites, par exemple). Cette notion n'était pas notre préoccupation première, et les composants actuels suffisent à valider notre modèle, en particulier du point de vue de la liaison graphique/interactions.
Il serait maintenant nécessaire d'étudier l'intégration et la réalisation de tels concepts de haut niveau dans notre modèle sans en briser la cohérence et les avantages pour le prototypage interactif. L'extension des Manipulateurs pour le contrôle des objets du domaine est une première piste pour externaliser leur communication dans le même formalisme et le même langage de description que le comportement des objets graphiques. Mais nous pensons aussi à une représentation graphique interactive du graphe de scène qui, associée à des modules métier dépendant du contexte de développement permettrait de les mettre simplement en relation.
Il nous parait alors essentiel d'étudier les points nécessaires à son évolution vers un système plus complet de prototypage d'IHM. En effet, de telles approches de séparation des descriptions commencent à être utilisées dans un contexte industriel pour le développement d'applications à grande échelle. La société INTUILAB, par exemple, a développé la boîte à outils IntuiKit dans cette optique, prouvant ainsi l'efficacité de cette approche pour la prise en compte et l'intégration des divers acteurs de la conception d'interfaces tout au long d'un projet [Chatty et al.2004]. Alors que les concepteurs graphique utilisent leurs logiciels habituels pour produire les graphismes de l'interface, les développeurs construisent l'application et ses interaction de manière indépendante. La liaison entre les modules s'opère par une architecture proche de nos graphes combinés.
Notre modèle offre en plus un aspect dynamique permettant à notre avis d'aller plus loin dans l'unification dans un même environnement des différentes compétences impliquées dans la conception d'interfaces et le prototypage d'interactions. L'introduction d'une approche orientée contrôle et d'une représentation graphique d'objets du domaine permettrait la construction d'un Atelier de Génie Logiciel pour le prototypage en IHM reposant essentiellement sur des techniques interactives, le rendant alors accessible aux graphistes, ergonomes et programmeurs. Mais cette proposition implique d'étudier la qualité du modèle en terme de robustesse et de performances, ainsi que d'améliorer les outils actuels (outils de dessin du constructeur d'interfaces, documentation, etc.)
Ensuite, la modularité et la flexibilité de notre approche en fait une plateforme adaptée au prototypage d'interactions. Nous souhaitons d'ailleurs en tirer parti pour nos recherches futures dans ce domaine. Mais nous envisageons aussi d'améliorer son implémentation dans un souci de robustesse, puis d'enrichir la documentation et les exemples fournis afin de permettre sa diffusion à une plus grande échelle dans les domaines de la recherche et de l'enseignement. C'est peut-être une perspective ambitieuse, mais MAGGLITE pourrait alors permettre la réalisation, la diffusion et l'utilisation de techniques innovantes qui restent trop souvent à l'état de prototypes faute de possibilité d'intégration dans des environnements standards.
Car si l'architecture des ordinateurs n'a pas vraiment évoluée depuis ses débuts, comme le souligne Jean-Daniel FEKETE dans [Fekete2005], la manière dont nous les utilisons et les projections que nous faisons de leur utilisation a par contre beaucoup changée. Dès lors, si nous devions donner une seule cause à la relative pauvreté des systèmes actuels en termes d'interaction, nous l'expliquerions par une préoccupation de standardisation plutôt que d'unification. Et c'est justement sur un souci d'unification que se sont penchés nos travaux: une architecture tendant à unifier l'utilisation de diverses techniques d'interaction et par conséquent de différents modèles d'architectures logicielles et modèles d'interaction.
L'on peut alors se poser la question de savoir qui des boîtes à outils ou des systèmes informatiques doit évoluer pour mieux correspondre à l'autre et pour mieux prendre en compte les besoins. Même si les premières ont parcourus plus de chemin que les seconds vers ce point de rencontre, il s'avère toutefois que des plateformes matérielles dédiées à une seule utilisation existent et prouvent leur efficacité (des PC Media Center aux consoles de jeux), bien que ne changeant pas d'architecture physique.
Mais nous pensons surtout que l'avenir des systèmes interactifs passe par deux points cruciaux:
Si la première de ces propositions est plus qu'envisageable au vu du chemin actuellement parcouru par la recherche en IHM, la seconde est plus utopique, mais à notre avis nécessaire pour un passage de la standardisation à l'unification.