Contexte spécifique par utilisateur

Une des approches possibles relatives à la construction d’interfaces collaboratives est connu

sous le nom de WYSIWIS [Stefik & al., 1987]. Cet acronyme de langue anglaise correspond à

86 Citation tirée de [Gutwin & Greenberg, 1997, p. 1] et traduite de l’anglais : « workspace awareness helps people move between individual and shared activities, provides a context in which to interpret other’s utterances, allows

« What You See Is What I See », que l’on peut traduire littéralement en français par « Ce que vous voyez est ce que je vois ». Il décrit des interfaces qui permettent le partage d’un contexte graphique qui est garanti comme identique et qui apparaît donc de la même manière chez tous les participants. Une vue en miroir en quelque sorte, qui peut être rapproché d’une solution de partage d’écran. Les deux principaux avantages relatifs à ce type d’interface, pointés par Ellis, sont sa facilité de mise œuvre et le fait qu’elle permette un fort sentiment de partage du contexte, les participants pouvant par exemple se référer à un même élément grâce à leur position spatiale [Ellis & al., 1991]. Cette approche présente néanmoins l’inconvénient d’être très peu flexible et peu adaptable au contexte de visualisation et d’édition pour les utilisateurs. Toujours selon les mêmes auteurs, l’expérience montre que les utilisateurs veulent souvent avoir un contrôle indépendant sur des paramètres de vue tels que la position ou la taille de la fenêtre, mais aussi des informations personnalisées au sein de leur interface qui serait donc différentes selon les utilisateurs. Dans les logiciels Pure Data et Max les informations telles que la taille de la fenêtre du patch ou sa position sont stockées directement au sein du document [Figure 9, p. 60]. Ainsi, l'ouverture d'un patch créé par une tierce personne amène aussi à utiliser les réglages correspondant à la vue de cette personne.

Des approches plus flexible au principe stricte de WYSIWIS ont alors été proposées. Selon M.

Stefik, D. G. Bobrow, G. Foster, S. Lanning, et D. Tatar, ce principe peut être relâché suivant quatre dimensions [Stefik & al., 1987] :

• Espace d’affichage : l’affichage des éléments d’interface sur lequel le principe

WYSIWIS est appliqué.

• Temps d’affichage : à quel moment sont synchronisées les différentes vues.

• Sous-groupes : l’ensemble des participants impliqués ou touchés.

On parlera alors pour désigner ce genre d’interface d’un principe de WYSIAWIS ou « What

You See Is Almost What I See », que l’on peut traduire par « Ce que vous voyez est à peu près

ce que je vois ». Ce principe est adapté pour décrire des solutions logicielles qui permettent un partage de l’espace de production avec un contexte de rendu graphique qui peut être spécifique par utilisateur. Une illustration de ce principe se trouve par exemple dans l'application

collaborative d'édition de texte Google Docs qui permet à chaque utilisateur de visualiser des

parties différentes du même document ou encore d’afficher les sélections et les curseurs respectifs dans des couleurs spécifiques. Pour répondre aux différentes problématiques liées à la mise en place d’une conscience de groupe, une solution collaborative de patching audio devrait offrir des outils similaires permettant aux utilisateurs de visualiser des parties différentes d’un même patch et de différencier leurs propres sélections de celles des autres participants.

Cependant, tout ne doit pas forcément être partagé dans un logiciel multi-utilisateur. L’utilisateur peut certes disposer d’un espace commun (la représentation graphique de l’espace de production) dans lequel les données sont partagées avec les autres participants, mais il peut aussi avoir besoin d’un contexte qui lui est propre et qui ne sera donc pas partagé avec les

autres. Ce contexte local peut se situer en dehors de l’espace de production (eg. réglages

spécifiques de l’application, zone de travail locales) ou au sein même de cet espace (sélections

etc.). Comme nous l’avons déjà évoqué à l’occasion de l’étude de la solution peerdata, la mise

en place d’un contexte spécifique par utilisateur est aussi nécessaire pour le système d’undo/redo qui dans le cadre d’une application doit être spécifique pour chaque utilisateur [Prakash & Knister, 1992].

D’autre part, un patch n’a pas pour seule vocation d’être visualisé au sein de l’interface graphique, il fait aussi intervenir ce que l’on pourrait nommer une vue logique qui se charge de son exécution. L’application interprète le modèle d’un patch pour générer un rendu qui n’est

pas seulement graphique mais aussi sonore. On pourrait donc étendre le principe de WYSIWIS

dans le cas d’un logiciel de patching et définir ainsi d’autres notions du même ordre, telles

qu’un principe de WYHIWIH pour « What You Hear Is What I Hear » que l’on traduirait alors

littéralement par « Ce que vous entendez est ce que j’entends ». Par extension un relâchement

de ce principe correspondrait alors à « Ce que vous entendez est à peu près ce que j’entends ».

S’il est permis et même souhaité d’avoir un rendu graphique du patch qui puisse différer légèrement et s’adapter en fonction de chaque utilisateur, qu’en est-t-il du rendu sonore du patch ? Les utilisateurs cherchent-ils tout le temps à synchroniser le rendu sonore d’un patch ou veulent-ils aussi parfois pouvoir disposer de leur propre contexte d’exécution du traitement

sur leur machine ? Dans des solutions telles que peerdata c’est l’ensemble de l’application Pure

Data qui est partagé, il n’y a donc qu’un contexte d’exécution global, autrement dît et pour

reprendre la formulation liée au principe de WYSIWIS : ce que vous voyez, faites ou entendez

sur l’application a un impact direct et correspond automatiquement à ce que je vois, fait ou entends. Les messages postés dans la console, les sélections au sein du patch, les valeurs des paramètres de contrôle des différents patchs ou encore le fait que le traitement audio soit activé ou non au sein de l’application sont des éléments qui sont communs au groupe utilisant le collecticiel et ne peuvent pas être spécifiques pour chaque utilisateur. Or, lorsque l’on cherche à élaborer un traitement avec quelqu’un d’autre on peut vouloir par exemple disposer soi-même du choix d’entendre ou non son rendu sonore, ou encore vouloir disposer de ses propres valeurs de jeu pour tester le traitement mis en œuvre sans que cela ne vienne influencer l’exécution du patch chez un autre collaborateur. Si l’on considère que l’espace de jeu – celui des différents paramètres de contrôle – doit pouvoir être local au sein d’un patch dans le cadre d’un logiciel

de patching audio collaboratif synchrone, on doit alors aussi faire en sorte que l’architecture mise en place puisse supporter un contexte d’exécution spécifique qui puisse différer chez chacun des utilisateurs.