suivant: 5.4 Perspectives monter: 5. Discussions et perspectives précédent: 5.2 Finalisation du système Table des matières Index
Des modes implicites
Dans un premier temps, les feuilles d'interaction peuvent être vues comme les différents modes du
système: un mode de dessin et de création (la feuille de dessin), un mode d'interprétation et de
précision des éléments du dessin (la feuille augmentée) et un mode de visualisation et de
manipulation de l'objet de la conception (la feuille 3D). Un avantage certain concerne la
représentation de ces modes: une représentation verticale, basée sur la superposition des
feuilles semi-transparentes. Cette approche évite les problèmes habituels des environnements
multi-fenêtrés tels qu'une gestion délicate de l'espace de travail et des occlusions.
De plus, nous avons proposé un changement de mode implicite d'une feuille à l'autre, piloté par les actions de l'utilisateur et ses besoins. Les feuilles apparaissent et disparaissent selon les actions (dessin, manipulation 3D, etc.) et même lorsque toutes les feuilles sont présentes sur l'espace de travail, elles restent visibles par superposition et transparence.
Un lien entre les fonctions du dessin
En allant plus loin, cette superposition en transparence présente un autre avantage. Elle permet la
mise en relation implicite des données supportées par chacune des feuilles. Il est ainsi aisé de
voir les parties correspondantes de la feuille augmentée, de la feuille de dessin et de la feuille
3D. Cette notion de vue superposée des différentes données des feuilles d'interaction permet de
comprendre le fonctionnement du système. Si l'on prend par exemple le cas de l'interprétation du
dessin sur la feuille augmentée, sa superposition avec le dessin original permet de comprendre les
mécanismes d'interprétation du système, et donne donc un retour précis de ses actions mais aussi de
ses éventuelles erreurs.
D'un point de vue plus conceptuel, ces feuilles peuvent être associées aux différentes fonctions de la représentation figurative, notamment en conception architecturale: spéculatif (la feuille de dessin), prescriptif (la feuille augmentée) et descriptif (la feuille 3D). Bien que notre système ne soit pas conçu pour la production de plans de construction précis, il constitue toutefois une première approche vers l'intégration de ces trois «modes» d'une manière efficace (utilisation du dessin spéculatif pour construire les deux autres, possibilité de concevoir des interactions plus adaptées pour la saisie de plans, etc.).
Notre utilisation de ces périphériques ne se contente pas d'en faire des «souris avancées». Nous avons construit les instruments de l'application en étroite relation avec leurs capacités. Ainsi, s'il était évident que les six degrés de liberté du Magellan s'imposeraient pour la manipulation de l'objet 3D, notre proposition de manipulation des calques avec toutes les fonctionnalités du Shuttle a nécessité plus de réflexion et d'itérations: quel dispositif utiliser pour manipuler les calques de manière naturelle et comment tout faire sur les calques avec ce dispositif. Mais aussi comment utiliser toutes les capacités du dispositif afin d'optimiser la bande passante en entrée. Cette démarche nous a permis de concevoir des interactions a priori naturelles entre l'utilisateur et l'instrument de gestion des calques (le pliage direct, la navigation entre les calques).
Il s'ensuit alors une connexion complète entre les dispositifs et les outils de l'application pour composer des instruments. Dans ce sens, cette instrumentation physique de l'interface rappelle la notion d'outils physiques, non ambiguë pour le concepteur. Nous pensons que ce principe favorise la prise en main et la mémorisation des fonctionnalités du système (bien que nécessitant tout de même un apprentissage et une description des associations que nous évoquerons plus loin). De plus, c'est une réalisation efficace de la manipulation directe par le modèle d'interaction instrumentale [Beaudouin-Lafon1997,Beaudouin-Lafon2000], améliorant son efficacité en réduisant le coût d'activation des instruments de l'interface, ne nécessitant ni pointage ou sélection préliminaire et permettant des interactions bimanuelles naturelles.
Finalement, ce paradigme des feuilles d'interaction peut être vu comme une réalisation étendue du modèle multi-couches [Fekete et Beaudouin-Lafon1996,Fekete1996]. Il en reprend l'aspect modulaire et flexible pour son implémentation et son utilisation ainsi que les possibilités de décomposition sémantique et d'organisation pratique et fonctionnelle. Toutefois, il permet en plus un contrôle fin des interactions au niveau de chaque couche, rendant possible l'association de périphériques d'entrée et d'outils, ainsi que la description du comportement dynamique des feuilles.
Dispositifs spécifiques
En effet, nos propositions reposent autant sur des interactions avancées et adaptées que sur leur
association avec des périphériques d'entrée non standard qui ne sont pas toujours présents sur
toutes les configurations matérielles.
Ce problème de la disponibilité et de l'adaptation à différentes configurations a été pris en compte dés le début de la conception de SVALABARD, notamment en utilisant des boîtes à outils et une architecture logicielle modulaire et flexible. Dès lors, le système est complètement indépendant des dispositifs et peut être rapidement adapté à des configurations plus standards ou même plus avancées. Bien sur, utiliser un clavier et une souris pour interagir avec SVALABARD brise une grande partie de la métaphore de la table à dessin, construite aussi bien par les interactions que les dispositifs utilisés. Mais cela est tout de même envisageable.
Visibilité et apprentissage des fonctionnalités
Du point de vue de l'utilisation du système, et de sa prise en main, il est clair que nous devons
nous poser la question du temps et des moyens nécessaires à l'apprentissage de ses
fonctionnalités. Car nous sommes conscients qu'une telle approche n'est pas en tous points
écologique, les outils ne signifiant pas toujours d'eux-mêmes ce qu'ils permettent de réaliser. Par
exemple, s'il va être évident de comprendre que le stylet sur la tablette écran permet de
dessiner, il sera moins sûr que le Shuttle permette de manipuler les calques. De la
même manière, rien n'indique a priori à quoi sert la zone de reconnaissance de gestes, et même
lorsque sa fonction est connue, il faut connaître les gestes et les fonctions correspondantes. Ce
problème de «visibilité» des actions est récurrent dans les interfaces basées sur la
reconnaissance de marques [Baudel1995]. L'emploi des «marking menus» peut permettre de
remédier à cela, en fournissant un rappel des gestes, mais rien n'indique non plus explicitement
comment ils sont activés (le bouton latéral du stylet dans notre cas).
Nous pensons toutefois qu'une courte explication des fonctionnalités du système, assortie d'une présentation des dispositifs d'entrée suffit à se faire une idée de son utilisation. De plus, le regroupement des outils logiques en espaces d'interaction, souvent sur un même dispositif, peut permettre une meilleure mémorisation de ces fonctionnalités. Il serait même envisageable d'introduire un mécanisme d'aides contextuelles, basées sur des macros ou des vidéos, qui signifierait les actions possibles à l'utilisateur lors de la première apparition d'une feuille d'interaction (dans l'esprit de l'image que nous avons réalisée pour la figure 4.12, présentant en vignette la manipulation du Shuttle pour plier les calques).
Ce ne sont que des propositions, et il est évidemment indispensable de les évaluer afin de les confirmer, mais il nous semble que le temps d'apprentissage (et d'éventuelles erreurs) induit par une approche non standard telle que la nôtre sera minime par rapport aux gains qu'elle peut apporter, particulièrement en termes d'intégration dans une démarche créative.
Or, dans les approches actuelles, révision et amélioration sont plus assimilables à de la gestion de versions, car trop liées à l'emploi de structures de données précises et globales (primitives de haut niveau). Certes, cette approche offre un avantage certain en terme de gestion de projet, mais n'est pas vraiment en accord avec les structures manipulées par l'utilisateur. Notre démarche se démarque sur ce point, car axée autour du trait comme donnée commune à l'utilisateur et au système, dans un contexte de dessin libre. Il est vrai que l'utilisation et l'interprétation du dessin comme médium entre le concepteur et le système informatique n'est en rien une nouveauté. Toutefois, notre approche se distingue par la notion de dessin libre, sans contrainte ni de vue (grâce aux possibilités du noyau de reconstruction utilisé) ni de qualité du dessin (vectoriel, limitation à la saisie de l'objet d'intérêt, etc.). Ainsi, même si dans les traitements le système d'interprétation va transformer ces données pour les exploiter, leur transformation et leur évolution vers des solutions plus précises aura toujours pour support le croquis et ses traits, associé à l'utilisation de calques.
Filtres et traitements du dessin
Les filtres de traitement du dessin prennent une place importante dans la façon dont le système va
s'intégrer dans la démarche de conception: ils déterminent les possibilités de transformation des
traits saisis vers une structure de données exploitable par le système. Ils sont aussi intimement liés à la tâche et au domaine d'utilisation et doivent être développés
dans un contexte particulier. C'est ce que nous avons tenté de réaliser par nos proposition,
notamment par les filtres de détection des phases de dessin et de fusion des segments
dans le cadre du croquis d'architecture en perspective.
Tout en conservant la démarche libre du concepteur en architecture, et notamment la révision grâce à la fusion des segments, nous pouvons produire en temps réel une structure vectorielle du dessin, un graphe 2D, utilisable pour des interprétations de haut niveau et la reconstruction 3D. Il convient toutefois de mesurer ce discours, de par le fait que ces traitements n'ont pas encore été évalués dans des conditions réelles d'utilisation, et ne s'appliquent pas non plus pour la production d'autres structures de données telles que des courbes. Toutefois, ils sont adaptés à la fois à la notion de démarche libre et itérative et à la finalité de notre système, son noyau mathématique.
Calques de dessin
Enfin, le principe des calques de dessin que nous avons proposé est aussi un atout pour le support
de la conception et de sa démarche. En effet, outre leur apport à la métaphore des outils habituels
de conception, les calques offrent dans notre système la même capacité de «mémoire» et de
révision que leurs équivalents réels. C'est un autre point sur lequel notre système reproduit et
emprunte ses outils aux méthodes de conception pour favoriser la démarche libre et créative. Il reste
toutefois, comme nous l'avons souligné dans le chapitre précédent, à clarifier le mode de connexion
des interpréteurs aux calques de dessin afin d'en améliorer la pertinence.
Amélioration des filtres bas niveau
Nos algorithmes originaux de fusion de segments et de détection des phases de dessin
d'architecture sont essentiellement basés sur des heuristiques et des analyses issues de notre
étude. Bien que fiables dans le cas général, il n'en demeure pas moins quelques singularités
entraînant des erreurs parfois pénalisantes pour le traitement du dessin, telles que la fusion
erronée de segments (cas des «écrasements» dus à la vue perspective) ou un mauvais filtrage de
traits.
Pour ce qui est de la détection des phases du dessin, il nous semble impératif de rendre ce traitement adaptatif à l'utilisateur de manière à prendre en compte les spécificités de ses méthodes et ses habitudes. L'étude de cette notion de profil utilisateur est une voie qui suffirait probablement à identifier et trouver les limites de notre approche.
Dans le cas de la fusion des segments, la principale limite est due à une considération locale du problème. Il serait intéressant d'envisager une méthode plus globale, associant les heuristiques que nous avons proposées à une analyse de la topologie du graphe 2D formé par les points et segments détectés (recherche de pendants5.1, de cycles, etc.). Nous reviendrons plus en détail sur cette approche dans l'annexe A.
Finalement, même si il est indispensable d'approfondir les travaux que nous avons engagés sur les filtres et traitements du dessin, notre approche offre surtout une architecture logicielle permettant cette amélioration et cette évolution. La décomposition du traitement en plusieurs modules, qui peuvent être connectés dynamiquement, induit la flexibilité nécessaire à l'amélioration, l'insertion ou le remplacement de traitements sans pour autant remettre les autres en question.
Saisie des contraintes
Actuellement, la saisie des propriétés de haut niveau nécessaires à la reconstruction 3D est
réalisée par l'utilisateur. Il est évident que cette saisie est fastidieuse, en particulier dans le
cas d'un dessin important et complexe. Mais elle n'est toutefois pas si intrusive du point de vue de
la démarche de conception, pouvant être réalisée à n'importe quel moment (au cours du dessin, ou à
la fin). Bien entendu, cela pose tout de même le problème d'une longue tâche supplémentaire à
réaliser, et ne permet pas de tirer tous les avantages de l'outil informatique. En particulier, si
la saisie de ces propriétés est effectuée en fin de conception, le concepteur ne bénéficie pas de la
construction d'un modèle 3D en parallèle à sa démarche.
Si l'on revient aux hypothèses originales du projet GINA, l'idée de départ était une saisie simultanée du dessin et des contraintes en utilisant plusieurs modalités: le stylet pour le dessin et la parole pour les contraintes. Ainsi, l'utilisateur décrirait son dessin au fur et à mesure du tracé. Nous n'aborderons que de loin les problèmes techniques de ce principe (mise au point d'un vocabulaire de description et fusion multimodale), nous nous concentrerons essentiellement sur la démarche qu'il engendre.
Dans le cadre de la modélisation 3D dans les premières phases de la conception architecturale, un
tel principe n'est à notre avis pas adapté. En effet, il est tout d'abord important de définir un
vocabulaire de description adapté au domaine. Or dans le cadre de l'architecture, le vocabulaire est
tout de même d'un niveau assez élevé, posant à notre avis un problème de fusion multimodale trop
délicat (beaucoup de traits du dessin, qui de plus ne seront pas forcément tracés consécutivement,
vont représenter une caractéristique architecturale déclarée). Il serait alors nécessaire de
contraindre fortement la démarche du concepteur. En l'obligeant, dans un premier temps, à ne
dessiner en séquence que ce qu'il vient d'énoncer (ou l'inverse, expliquer ce qu'il vient de
dessiner). Mais aussi en le contraignant à préciser peut être trop tôt ses choix de
conception. Toutefois, si l'on fait abstraction de la contrainte qui consiste à obliger le
concepteur à «penser tout haut», cette approche multimodale serait un atout pour délimiter les
phases de conception associées à des objets d'intérêt [Leclercq et al.2004], plutôt que pour leur
description précise (et géométrique).
Ce principe de description précise nous semble bien plus adapté à la modélisation 3D dans un cadre
géométrique ou pour la saisie de modèles 3D déjà conçus; en bref, lorsque la géométrie est bien
définie. Le vocabulaire peut alors être de plus bas niveau, basé sur les points, droites,
parallélismes, etc., facilitant alors la fusion avec le dessin (mais à notre avis incompatible avec
les concepts que manipule l'architecte).
Il est selon nous important de s'orienter vers une collaboration entre l'utilisateur et le système pour l'interprétation du dessin et son élévation en 3D, notamment au niveau de la détection des propriétés. Bien que ce principe puisse paraître en contradiction avec notre proposition de dessin et de démarche libre, il nous semble un compromis nécessaire pour éviter d'ajouter des tâches « annexes» à la conception trop lourdes pour le concepteur, ainsi que pour éviter des interprétations erronées par le système.
Retours, corrections et collaboration à l'interprétation
Du fait de l'imprécision des données traitées dans les premières phases de la conception, il est
inévitable que des traitements automatisés aboutissent à plusieurs solutions possibles au terme de
leurs analyses. Ils doivent donc être vus comme des outils d'aide à la génération de solutions,
comme nous l'avions évoqué dans le premier chapitre de ce mémoire, sans pour autant que ce soit le
système qui fasse le choix d'une solution. Le problème majeur est alors la présentation de ces
interprétations et solutions à l'utilisateur, de manière ni contraignante, ni intrusive.
Nous sommes d'avis qu'un principe d'interface suggestive, dans l'esprit de celle proposée par Takeo IGARASHI dans [Igarashi et Hughes2001], est une solution efficace. Cette technique, proche du principe des «What-if Tools» de Ben SHNEIDERMAN [Shneiderman2000] présente différents avantages, le plus important étant de ne pas interrompre la tâche de l'utilisateur tout en lui permettant de suivre et guider le système. Mais l'impact n'est à notre avis pas négligeable non plus sur sa démarche, lui offrant la possibilité de concrétiser plus rapidement des solutions ou de poursuivre à son propre gré.
Un tel mécanisme de suggestions serait un atout certain dans notre système pour la présentation des retours du système d'interprétation, permettant de conserver la notion de démarche libre. Dans notre paradigme des feuilles d'interactions, ces suggestions pourraient être présentées sur la feuille augmentée sous forme de vignettes interactives contenant une représentation graphique des propositions, renforçant ainsi l'aspect non-intrusif de cette technique (la feuille augmentée n'apparaît que lorsque l'utilisateur ne dessine plus). Cette approche est un bon compromis pour une collaboration entre le système et l'utilisateur, à plusieurs niveaux: interprétation bas niveau du dessin, détection des propriétés et proposition de solutions.
Nous ne développerons pas plus avant ces notions dans ce chapitre, celles-ci étant largement exposées dans la deuxième partie de ce mémoire où nous proposons un nouveau modèle d'architecture logicielle pour la conception des interfaces, implémenté dans la boîte à outil MAGGLITE (voir chapitre 8). Nous reviendrons précisément dans la section 8.4.3 sur le développement de SVALABARD avec ces outils.