• Aucun résultat trouvé

La délégation de propriétés

b) Édition d’agenda et de trajectoires4D 

C. La structuration explicite

1. La délégation de propriétés

Nous avons exploré des techniques d’interaction qui permettent aux utilisateurs de structurer leur scène explicitement, en s’inspirant du principe de délégation des langages à prototypes (Lieberman, 1986). Les utilisateurs peuvent spécifier qu’une propriété d’un objet (dit clone) dépend de celle d’un autre objet (dit prototype). Un prototype est une entité similaire au master de Sketchpad (Sutherland, 1964) : si l’utilisateur modifie une propriété d’un objet, cela propage le changement à tous les objets clones qui en dépendent (R1.3 modifier les ensembles, R2.3 portée des actions). La délégation dans Self (Ungar & Smith, 1987) repose sur ce type de fonctionnement (Figure 57). Si l’on modifie un prototype qui délègue des propriétés à d’autres objets, ceux-ci peuvent refléter les mêmes changements. Cependant les changements ne sont

pas visibles immédiatement car les objets ne sont pas notifiés explicitement, il faut cliquer sur chaque objet pour le mettre à jour ou bien rafraichir la fenêtre (Figure 58 à Figure 59) (R2.4 percevoir les conséquences).

Figure 57. Scène graphique dans Self contenant trois morphes (objets graphiques) et leurs prototypes : un label, un cercle, et un agrégat de morphes (un rectangle contenant deux carrés).

Figure 58. La couleur du label était déléguée par un prototype « peinture » détenant la propriété couleur noire. Le lien de délégation a été déplacé par manipulation directe sur le prototype codant

Figure 59. Le prototype « peinture » qui codait la propriété « couleur verte » à été modifié pour coder la couleur bleue. Les trois objets qui dépendaient de ce prototype sont modifiés.

a) Interactions 

Nous souhaitions permettre aux utilisateurs de créer leurs structures avec facilité, en favorisant des outils conçus pour être utilisés avec de la manipulation directe, plutôt que via des boîtes de dialogues ou des commandes à saisir. De fait, cliquer sur un objet de la scène en utilisant l’outil « binder » de la palette d’outils dévoile ses propriétés autour de lui (Figure 60).

Figure 60. Les propriétés du cercle sont présentées en cercle autour de l’objet.

L’utilisateur peut alors cliquer sur l’une de ces propriétés et tracer un lien élastique qu’il va pouvoir déposer sur un autre objet, de la même manière qu’il déposerait un échantillon de valeur sur un objet (Figure 61). Cet objet devient alors un clone du premier, puisque la valeur de sa propriété devient dépendante de celle de l’objet

qui est déléguée, la modification se propage et affecte le clone. L’apparence de l’objet clone reflète immédiatement la dépendance dès lors que la propriété concernée est représentée visuellement (R2.4 percevoir les conséquences).

Les liens de dépendance sont visibles, pour tous les objets, en partant de la propriété vers l’objet. Un lien vert indique que la propriété est déléguée à l’objet et un lien violet qu’elle est dépendante de l’objet (Figure 62). Il est possible de supprimer des liens en cliquant dans un espace vide de la scène et en traçant un trait coupant les liens à supprimer (Figure 63). Les liens en intersection avec la ligne de suppression sont grisés (feedforward (Vermeulen et al., 2013)) indiquant à l’utilisateur quels seront les liens supprimés lors de la validation de l’action.

Figure 61. L’utilisateur trace un trait de la propriété du premier rectangle vers le second. Celui-ci devient vert afin d’indiquer à l’utilisateur que l’opération est possible.

Figure 62. A gauche, le lien vert signifie que la propriété est déléguée à l’objet, tandis qu’à droite, le lien est de couleur violette pour indiquer que la propriété est déléguée par l’objet.

Figure 63. L’utilisateur peut tracer un trait en cliquant dans le vide, et couper des liens qu’il désire supprimer. Tous les liens en intersection avec le trait tracé sont grisés afin d’indiquer qu’ils seront

supprimés au relâchement du bouton de la souris.

b) Clonage 

Le système propose deux façons de créer de nouveaux objets à partir d’objets existants : soit en copiant l’objet, soit en le clonant. Copier un objet consiste en l’opération classique de copie des éditeurs graphiques : les propriétés de l’objet copié sont totalement indépendantes de l’objet source. Le clonage a pour effet de créer un clone dont presque toutes les propriétés sont déléguées par l’objet source (entre autre : couleur, forme, taille ainsi que titre, heures et jour de la semaine pour un évènement d’agenda). Seules les propriétés définies explicitement ne sont pas déléguées, telles que la position du nouvel objet qui est généralement différente du prototype. Créer un clone minimise le nombre d’actions requises pour spécifier une seule différence entre un clone et le prototype : s’il était copié au lieu d’être cloné, cela demanderait d’établir des liens un par un pour chacune des propriétés.

Par ailleurs, le système mémorise quels sont les objets « sources » dont est issue une copie simple. L’utilisateur peut alors décider ultérieurement de transformer l’objet copié en objet cloné, en déposant un instrument « clone » sur celui-ci (Figure 64). L’intérêt réside dans le fait que cela permet de créer des liens a posteriori (R3.5 structurer a posteriori) : l’utilisateur n’est pas obligé de prendre prématurément la décision de créer un objet délégué ou indépendant, ce qui limite l’engagement prématuré (T.  R.  G.  Green,  1989). Il peut choisir d’effectuer une simple copie et de prendre cette décision plus tard. Cette opération de transformation de copie en clone n’affecte que les propriétés qui n’ont pas été déléguée explicitement par l’utilisateur.

Figure 64. L’utilisateur copie un objet (a) la copie n’a aucun lien de dépendance avec l’original (b). L’utilisateur dépose l’instrument « clone » sur la copie (c), celle-ci est transformée en clone de l’objet

original (d).