wiki:WYSIWYM

WYSIWYM (what you see is what you MEAN)

Cette page est basée sur un e-mail de Sylvain Spinelli de la mailing list scenari-modeller : http://scenari-platform.org/forum/viewtopic.php?p=853#853

Les limites du WYSIWYG (what you see is what you GET)

Le principe du WYSIWYG est d'avoir à l'écran dans l'outil d'édition très exactement ce qu'on obtiendra sur le papier ou sur l'écran du lecteur final. Cette approche séduisante et agréable pour l'auteur engendre certaines limites (attention : je ne sous-entends pas que Scenari lève toutes ces limites...) :

  • En WYSIWYG, on écrit pour un et un seul support majeur (une et une seule mise en forme papier ou un et un seul site web), les autres sont considérés comme secondaires et dégradés. Par exemple, lorsqu'un support papier et un support Web trouvent tous 2 un usage "important", le WYSIWYG est logiquement impossible.
  • En WYSIWYG, on écrit un seul contenu monolithique où tout est "vu" : cela ne permet pas d'écrire un contenu plus riche qui est ensuite filtré en fonction du contexte d'usage et du support désiré (exemple : contenu en slide-show présentiel, support apprenant, consignes tuteurs). Impossible donc de faire un contenu à profondeur variable, c'est aussi logiquement impossible.
  • Sans aller jusqu'à du contenu à profondeur variable, il très souvent nécessaire d'ajouter des informations non publiées : quelques meta-données, des commentaires pour l'orateur/tuteur, etc. Sur le plan ergonomique, il est très difficile de faire un éditeur WYSIWYG qui permette ce genre de choses. Des solutions ont néanmoins été trouvées par les éditeurs, au coup par coup : fenêtres de propriétés, bulles de commentaires superposées, etc. Ces solutions sont néanmoins très limitées et surtout dédiées à des usages prédéfinis car très difficile à rendre ergonomiquement acceptable.
  • Le WYSIWYG ne permet pas la production de contenu dynamique et interactif. Comment éditer un contenu riche qui apparait dans un "tooltip" ? Comment écrire un contenu de type "web-radio" c'est à dire dont l'apparition/disparition est pilotée par une ligne de temps ? Comment écrire un exercice interactif en précisant la ou les bonnes solutions, le mode du calcul de scoring, les différents feed-backs possibles en fonction des réponses de l'apprenant ? Le principe du WYSIWYG est ici encore logiquement impossible (les éditeurs dérogent donc à la règle pour y parvenir ou proposent des types d'exercices très simples).
  • L'approche WYSIWYG favorise donc la perception graphique du résultat final. Elle met donc en avant la forme et pas la structuration du contenu. De ce fait, il est encore moins acceptable pour l'auteur que l'outil le contraigne / le guide dans une démarche d'écriture. Le WYSIWYG "parfait" à la word laisse donc une liberté totale à l'auteur, ce qui est considéré comme mauvais dans une démarche d'industrialisation. Le WYSIWYG "limité" (wiki...) est un entre-deux dont les limites sont fixées par des contraintes techniques ou par des contraintes de chartes graphiques mais pas (ou très difficilement) par des contraintes éditoriales (ie de choix de modélisation et de structuration de l'information). En d'autres termes, l'édition WYSIWYG est étrangère aux concepts de structuration documentaire / modélisation / ligne éditoriale.
  • Enfin, l'approche WYSIWYG amène nécessairement l'auteur à se préoccuper de la forme et du résultat final. On connaît bien la surcharge cognitive et la perte de temps que cela entraîne, powerpoint étant un must en la matière. Là encore dans un entre deux comme dans certains programmes d'écritures de contenus de formation ou dans les wiki, cette perte est limitée du simple fait des limites de l'outil. Ainsi, la seule solution pour éviter ce phénomène, est de faire du WYSIWYG pauvre ce qui personnellement ne m'enthousiasme pas.

Pour conclure : cela fait 20 ans maintenant que l'approche WYSIWYG est mise en oeuvre (avec des moyens financiers colossaux), aboutissant à une très grande maturité et stabilité technologique. Mais des nouveaux besoins massifs de gestion/diffusion de l'information combinés à l'avènement de l'interactivité et du multimédia mettent en évidence les limites intrinsèques de cette approche. Ceci-dit, tout le monde n'a pas ce type de besoin ni ces velléités multimedia : dans les situations plus classique, il serait stupide de si se priver de l'efficacité du WYSIWYG !

L'approche WYSIWYM (what you see is what you MEAN)

Le WYSIWYM oppose sa démarche à celle du WYSIWYG en partant non pas du résultat graphique, mais de l'information à véhiculer, de sa signification et de l'intention auctoriale. Evidemment, cette démarche inhabituelle nécessite un travail d'abstraction de la part de l'auteur qui en fonction des situations peut-être :

  • contre-productive, car inutile compte-tenu du type d'information à produire (simple, linéaire et statique) et de son exploitation (un seul support associé),
  • bénéfique, car
    • contribuant à améliorer la qualité du contenu par une plus grande réflexion sur l'écrit (dans le deux sens du terme),
    • homogénéisant l'écriture (respect d'un modèle) et les mises en formes de publication
    • dépassant les limites intrinsèque de l'approche WYSIWYG : écriture multi-supports, multi-usages, à profondeur variable, imbriquant une écriture interactive et spacio-temporelle...

L'opposition s'arrête là ! Dans la mise en oeuvre, il est évident que la forme et le fonds sont intimement liés et qu'un contenu correctement mis en forme lors de l'édition aide considérablement l'auteur dans son écriture. WYSIWYG et WYSIWYM ne doivent pas être opposés comme le sont les éditeurs graphiques (word) aux éditeurs en ligne de commande (latex, vim, etc.). Un éditeur WYSIWYM peut être graphique, cependant, il n'a pas pour objectif de représenter au "pixel ou millimètre près" ce qui sera visible par "l'utilisateur final" mais simplement d'aider à exprimer le message à véhiculer. Le WYSIWYM doit proposer une représentation graphique pertinente de l'information, alors le WYSIWYG cherche à fournir lors de l'édition l'unique forme graphique cible.

Ainsi, avoir un éditeur qui met en forme en gras un texte qui a été déclaré comme "important" est simplement destiné à exploiter nos habitudes de présentation pour "faire sens" plus vite dans notre esprit : lire une balise <important> encadrant le texte est naturellement plus laborieux et surtout ne fait pas appel à nos "réflexes". De même pour la notion de paragraphe, de listes à puces, etc. Pourquoi ne pas exploiter la force de ces réflexes acquis ? Après, dans une publication donnée, que la puce de la liste soit un rond noir ou un carré rouge pour mieux se fondre dans une charte graphique, quelle importance pour l'auteur ? Le sens est là !

Pour conclure : le WYSIWYM est un concept émergent sur le quel nous avons encore peu de recul et peu de moyens ont été investis. Les précurseurs de cette approche sont les éditeurs historiques en ligne de commandes, mais la non exploitation de la force de la représentation graphique les cantonnent dans des milieux spécifiques où l'abstraction est reine : les math et l'informatique. Je crois profondément que WYSIWYM intégrant la dimension graphique est le ticket gagnant sur lequel il faut aujourd'hui investir !

L'ambition et la réalité de SCENARI

L'ambition de SCENARI est de fournir un outil qui permette de formaliser des "savoirs" pour mieux les exploiter dans tous leurs cycles de vie : les créer, les gérer et les diffuser. Ces "savoirs" doivent pouvoir se combiner et être de nature informationnelle, pédagogique, voire même être de simples données brutes (chiffres, etc.). Dans toute ambition, il y a une part de rêve...

Nous travaillons sur SCENARI depuis 1999, 7 ans déjà... L'outil est très jeune et mature à la fois. Mature car opérationnel et ayant déjà levé un grand nombre de verrous technologiques. Très jeune face à l'ambition qu'il a et aux champs qui lui restent à investir. Très jeune aussi car l'avènement de SCENARIbuilder qui est la clé permettant la diffusion/démultiplication de notre approche n'a même pas un an (la première version est sortie en janvier 2006)...

Si nous regardons les quelques primitives aujourd'hui disponibles dans SCENARIbuilder (en gros compositionPrim, textPrim et imagePrim pour caricaturer), on peut se demander pourquoi ne pas pousser dans une approche plus WYSIWYG, compte tenu du fait que ce sont des contenus statiques plus ou moins enchaînés linéairement. Qui plus est, cela correspond à la majorité des besoins exprimés ! Sauf que... Il est très difficile d'exprimer un besoin d'une offre qui n'existe pas déjà. Le jour où des interfaces graphiques performantes permettront de dépasser la simple édition d'une page blanche, je ne donne pas cher des outils qui auront fondé leur architecture technique sur une approche WYSIWYG. Car derrière ce débat WYSIWYG / WYSIWYM, se cache des fondements technologiques radicalement différents où fond et forme sont totalement imbriqués dans un éditeur WYSIWYG, ce qui simplifie considérablement les choses. Il est donc pour moi primordial (vital à terme) de garder technologiquement une approche WYSIWYM, tout en essayant d'aller toujours plus loin dans la qualité de l'environnement d'édition et dans sa capacité d'expressivité sémantique en exploitant la force de la représentation graphique, mais c'est beaucoup plus difficile techniquement.

Pour revenir à SCENARIbuilder, voici quelques exemples de ce qui est ou sera possible de faire dans les mois qui viennent et qui vont à l'encontre d'une édition WYSIWYG.

  • La recombinaison/réutilisation : avez-vous déjà essayé de créer une base de plusieurs documents word et de les recombiner entre eux par des inclusions dynamiques ? Tous ceux qui s'y sont vraiment frottés vous diront que c'est une galère infernale ! En effet, vous ne pouvez pas vouloir à la fois maîtriser votre publication (gestion des hauteurs, des sauts de ligne et page pour du papier, gestion de la taille écran pour du web) et bénéficier du principe d'un contenu modifié à un seul en droit qui se répercute à tous les endroits où il est exploité. Si la mise en page est manuelle, il faut alors vérifier dans tous les documents appelants. La vision simple du WYSIWYG interdit donc tout principe de recombinaison / réutilisation (Dommage d'un point de vue SCENARI !).
  • Assessment : éditer un exercice interactif en mode WYSIWYG est un contre-sens. Comment permettre à l'auteur de spécifier l'interactivité et les enchaînements voulus de l'exercice : affichage maîtrisé de l'énoncé, d'un indice supplémentaire, de la note obtenue, de la ou des solutions, des feed-backs, etc. ?
  • Scorm : les nouvelles normes SCORM vont permettre de créer des contenus en spécifiant des règles d'enchaînement et fonction de l'activité et des résultats de l'apprenant. Comment en WYSIWYG exprimer ces conditionnalités et règles d'enchaînements ?
  • Contenus temporels : avec le projet Ecoute, nous travaillons sur des primitives permettant d'associer/combiner des contenus temporels (audio) avec des contenus statiques pour enrichir les flux audio. Là encore le WYSIWYG n'a plus de sens.

Pour poursuivre sur ce dernier exemple (gestion de la dimension temporelle), certains diront qu'il lest impossible de faire beaucoup mieux qu'un environnement d'édition comme Flash et que cette idée de vouloir créer des contenus plus riches est nécessairement voué à l'échec car elle nécessite de trop fortes connaissances/compétences techniques. En d'autres termes, un utilisateur "normal" ne pourra jamais créer autre chose que du contenu simple, statique et linéaire. C'est juste et faux à la fois ! C'est juste si on pense à un éditeur classique, destiné à offrir un maximum de possibilités à un auteur pour faire exactement ce qu'il souhaite. C'est faux avec l'approche SCENARI qui segmente le processus en 2 étapes en passant par la phase de modélisation. Connaissant le contexte métier de l'auteur, le modélisateur peut spécifier l'environnement d'édition juste nécessaire pour permettre à l'auteur de produire son information. De ce fait l'outil s'adapte à l'auteur et non l'inverse, et ceci est un des points fondamental qui rend l'approche WYSIWYM réaliste.

De mon point de vue, SCENARI n'a pas pour but d'être d'un nouveau Word, ni un éditeur de site web ni un mélange des deux. Il faut d'ailleurs noter que faire un éditeur de site web WYSIWYG est très complexe et les résultats sont aujourd'hui peu concluants : pas assez souple ou trop complexes à utiliser, produisant un code HTML "hideux", et exploitant assez mal la réelle puissance du Web et de son interactivité. L'ambition de SCENARI est toute autre en s'intéressant à la formalisation des savoirs et à leur diffusion. L'édition n'est qu'une facette du problème et l'attaquer sous l'angle du WYSIWYG est tout à fait insuffisant face à cette ambition. Aujourd'hui nombreux sont les contextes où nous faisons aussi bien qu'un éditeur WYSIWYG. Nous faisons aussi nettement mieux lorsqu'il s'agit d'automatiser certaines tâches et lorsqu'il s'agit d'aider l'auteur à structurer son contenu. Nous faisons parfois moins bien.... Mais il faut bien commencer par le commencement : en un an SCENARIbuilder nous a permis de produire des contenus élémentaires. Progressivement nous permettrons de produire des contenus qui seront de plus en plus éloignés de ceux qui pourraient être produit avec un éditeur WYSIWYG. Autrement dit : SCENARI en a encore beaucoup sous le capot, alors que le WYSIWYG trouve déjà ses limites. Patience, ça vient...

Pour conclure : SCENARI est un outil très générique qui se paramètre très fortement pour pouvoir répondre à des contextes d'usage très spécifiques. Il est logique qu'un usage assez répandu se satisfera mieux d'un outil développé spécifiquement pour cet usage répandu. SCENARI est d'abord intéressant là où les usages sont trop peu répandus pour justifier l'investissement d'un développement informatique dédié.

Pistes de progressions…

Sans vendre notre âme et tomber dans l'édition et la modélisation "facile", je crois qu'il est tout à fait possible de continuer à progresser fortement. Plusieurs axes :

  • Comme je le proposais dans un précédant mail, améliorer les possibilités d'édition actuel pour notamment :
    • mieux faire prendre conscience à l'auteur de la "quantité" de texte (par exemple) qu'il est souhaitable d'écrire et de ne pas dépasser
    • exploiter le positionnement relatif des zones d'édition pour aider l'interprétation sémantique du modèle (une image est une illustration d'un texte, etc.)
    • créer des contenus qui sont structurés "graphiquement" : un tableau, un diagramme, une image commentée, etc.
  • Comme le propose Loïc, on pourrait pourrait proposer la pré-visualisation de chaque item conformément aux différents générateurs définis dans le modèle. Pour que soit intéressant et utilisé, je pense qu'il faudrait trouver une solution technique qui ne nécessite quasiment aucun travail supplémentaire de la part du modélisateur. Chaud, mais ça mériterait qu'on y réfléchisse.
  • Construire via SCENARIbuilder d'autres environnements d'exécution que SCENARIchain/client et les SCENARIapp:
    • J'ai déjà évoqué SCENARIeditor, je crois beaucoup à cette idée car cette approche a l'énorme mérite d'éliminer l'aspect effectivement compliqué pour un auteur à savoir de devoir gérer lui-même ses items (ie fichiers) indépendamment de la structuration de son contenu. Cette simplification ergonomique verrouille les possibilités de réutilisation / recombinaison, mais comme les contenus produits seraient compatibles avec SCENARIchain, rien n'empêche de basculer lorsque l'auteur ressent des besoins plus avancés de gestion de ses contenus.
    • Sur un aspect plus technique Julie insiste sur la dimension "online" de la saisie plutôt que dans une application dédiée installée sur le poste client. Nous ne l'avons pas encore fait, mais il faut savoir qu'il serait possible d'installer SCENARIclient comme une extension Firefox, donc accessible à partir de firefox. Cette possibilité d'"extension de firefox" me semble encore plus pertinente et indispensable avec un éventuel SCENARIeditor.
    • Julie parlait aussi d'une édition XForm ou de formulaires web classiques. Cette approche n'aurait de sens que dans une phase de création initiale de "draft" et/ou de contenus très simples. On pourrait imaginer un SCENARIstarter ou SCENARIform qui serait une forme "webisée" (produite automatiquement à partir de SCENARIbuilder) et qui pourrait s'installer dans un serveur PHP ou autre. J'ai peur que cette approche ne soit éternellement frustrante et insatisfaisante car elle ne permettra jamais de couvrir l'ensemble du spectre de nos possibilités et qu'elle s'avère chronophage.
Last modified 5 years ago Last modified on 03/06/09 18:35:12