Versions de présentations et diapositives partagées

Lorsque Sébastien souhaite préparer ou modifier un cours, il procède souvent en assemblant des parties contenues dans différents documents. Il prend l'exemple d'un cours d'IHM pour la promotion « IENAC S ». Sébastien ouvre alors le document contenant l'introduction. Ce document est formaté selon un certain style, et surtout contient un plan, il s'agit du plan général que Sébastien doit rappeler à chaque début de cours (des cours de 2h dans la majorité des cas) mais aussi au milieu d'un cours lors d'un changement de partie. Par exemple, Sébastien souhaite donner un cours sur la sémiologie graphique, dans la catégorie représentation graphique du cours Modèle pour l'ergonomie. Seulement ce cours est contenu dans un autre document, alors que le plan est contenu dans l'introduction. Donc pour pouvoir rappeler le plan, Sébastien a deux solutions, soit il ouvre les deux documents l'un après l'autre, soit il recopie le plan dans le cours. Ceci pose deux problèmes : les styles appliqués ne sont pas forcément les mêmes, ce qui peux nuire à la mise en page, et surtout, si Sébastien modifie le plan, il lui est très difficile de savoir où il est répliqué afin de mettre à jour toutes ses copies. Illustre : Le problème inhérent à la duplication de diapositive dans plusieurs documents ; la mise en forme est altérée, il devient vite difficile de savoir dans quels documents sont présentes les copies, et surtout, l'impossibilité de modifier toutes les copies en une seule action.

Parfois, Sébastien décide d'assembler tous les cours en un seul document. Seulement, il apporte très fréquemment des modifications à ce document (corrections orthographiques, réagencements...) qu'il aimerait voir répliquées dans le document

original. Mais les mêmes informations sont contenues dans deux fichiers différents, qu'il s'agisse de dessin (Sébastien pouvant modifier les formes, leurs position...), de contenu (modifier le texte)... Le problème étant que toutes les modifications faites ne sont pas répliquées dans tous les cours partageant ces mêmes informations. De plus, Sébastien souhaiterait pouvoir garder le contrôle sur ces modifications dans le sens où la répercussion sur les copies ne devrait être faite que lorsqu'il le souhaite, car il n'a pas forcément envie de tout modifier dans l'immédiat.

Illustre : Le fait que les diapositives présentes dans plusieurs documents soient considérées comme des entités différentes, de fait les modifications que l'on souhaite faire sur une diapositive ne sont jamais répercutées sur les copies. Cela engendre une grande viscosité à chaque modification.

Au final, Sébastien se retrouve avec des duplicatas du cours « Paradigme d'interaction » dans de nombreux autres documents (cours d'introduction, de Conception Participative, etc...), ce qui l'oblige à se rappeler quelle était la dernière version de cours et surtout où elle se trouve.

Illustre : Il n'existe pas de moyen de savoir où se trouvent les copies d'un élément ainsi que leur nombre.

De plus, ces problèmes se retrouvent au niveau des cours qui diffèrent d'une promotion à l'autre. Par exemple, Sébastien construit un cours complet d'IHM pour le Master IHM, et, en supprimant certaines informations, il construit une version plus « légère » pour des IENAC. Là encore, Sébastien souhaiterait que les modifications faites dans le cours plus léger puissent être répercutées dans l'original.

Illustre : A nouveau le problème de la modification faite sur une copie qui n'est pas répercutée sur l'original.

2. Omnigraffle

Dans ce scénario, Simon souhaite réaliser plusieurs illustrations ayant pour objet les tableaux de « paper strips » du contrôle aérien. Il souhaite notamment concevoir et illustrer un nouveau design de strips, avec des gradients colorés. La (Figure 108) montre le résultat final. Simon commence par dessiner un strip « simplifié », en prenant pour modèle un strip réel. Il utilise un rectangle horizontal, contenant des lignes verticales servant de séparateurs. Il ajoute des informations textuelles spécifiques au strip imité: identifiant de vol, altitude, nom de balises, temps de passage aux balises. Il sait qu’il aura à modifier ces informations lorsqu’il créera d’autres strips, mais ne

sachant pas encore quelles informations vont varier, il préfère utiliser des informations véridiques.

Il duplique à plusieurs reprises le premier strip et superpose les copies afin de faire des tableaux de strips. Simon modifie ensuite les informations textuelles. En réfléchissant au nouveau design avec gradients, il élabore un autre design, basé sur le précédent, en alignant les balises à droite plutôt qu’à gauche (conception exploratoire). Aussi, il copie le tableau précédent, et modifie chacun des strips de la copie pour aligner les balises à droite (Figure 108). Cependant, en essayant de montrer l’intérêt d’utiliser des gradients, il s’aperçoit qu’il doit modifier le texte de certains temps de passage aux balises, afin que deux vols soient en conflit. Il s’exécute d’abord sur le tableau en cours de conception. Afin de limiter les différences entre tableaux aux informations importantes, il doit répéter ces actions sur le premier tableau. Il commence par rechercher les éléments qui doivent être changés (recherche). Cette action de recherche se fait en parcourant l’ensemble des objets graphiques, et en essayant de repérer les éléments candidats au changement, et au risque d’en oublier. Quand il en trouve, il exécute les actions nécessaires à la modification.

Illustre : Quand le nombre d’objets graphiques augmente, il est plus difficile de rechercher avec un simple parcours visuel des objets particuliers. Chaque modification devient plus coûteuse, non seulement à cause du nombre d’actions à répéter, mais aussi à cause de l’effort de recherche nécessaire.

3. iCal

Sébastien se sert du calendrier pour prévoir les évènements à venir, mais aussi pour faire des rapports d'activité à sa hiérarchie. Toutes les activités se voient donc attribuer un tag par Sébastien (« ens » pour enseignement, « rech » pour recherche etc...) dans le but de catégoriser ces activités et d'en sortir des statistiques (par exemple, la somme des heures d'enseignement pour une semaine donnée). Sébastien se rend compte qu'il faudrait décomposer certaines catégories en sous catégories : par exemple, la catégorie enseignement pourrait être divisée en cours et préparation de cours, mais aussi divisée en enseignement par promotion (IENAC, IHM...). Ce que Sébastien souhaiterait faire, c'est modifier tous les évènements correspondant à des préparations de cours, et changer le tag « ens » en « ens/prepa ». Pour cela, le seul moyen est de modifier tous les cours un par un ce qui est long et fastidieux (Figure 109).

Illustre : L'absence de moyen pour considérer des entités partageant une propriété commune comme une entité unique, afin d'agir sur l'ensemble de ces entités en une seule fois.

Le cours d'IHM apparaît plusieurs fois sur le calendrier, et il s'agit à chaque fois de la même chose. Sébastien aimerait pouvoir les lier, afin de pouvoir changer le titre ou bien la durée pour tous en une seule action. Concrètement, Sébastien aimerait pouvoir dire que le titre de tel évènement puisse dépendre d'une seule entité.

Illustre : A nouveau l'absence du concept de propriété commune à un ensemble d'élément.

Figure 109. Vue de l’agenda, l’utilisateur doit modifier un par un les évènements marqués d’une flèche.