Editeurs HTML
Coup de gueule...
Je suis convaincue de l'importance de produire des documents HTML respectant les standards, et je pense que le moyen le plus efficace, rationnel, et facile consiste à les produire "à la main".
Et ne serait-ce que pour des raisons philosophiques, je pense que si cela ne demande pas de travail supplémentaire (c'est même le contraire dans ce cas, à mon avis!), il vaut mieux éviter de dépendre d'outils et travailler directement dans la source. Je crois qu'il faut savoir additionner à la main avant d'utiliser une machine à calculer, orthographier correctement et utiliser un dictionnaire avant de se reposer sur un correcteur d'orthographe, et apprendre le HTML avant de choisir en toute connaissance de cause d'utiliser un outil comme DreamWeaver (ce qui, malheureusement, n'est pas le cas de la plupart des personnes qui dépendent de tels outils).
Il y a de longs mois, nous avons esquissé avec Karl et Pascale une discussion à ce sujet.
Malheureusement, il ne suffit pas d'être convaincu pour convaincre. On oublie que certains points de l'argumentaire qui paraissent être des évidences sont loin de l'être pour l'interlocuteur. Et régulièrement, dans différents milieux, je me trouve empruntée, à court d'arguments, face ceux qui ne jurent que par DreamWeaver (ou autre) et considèrent le balisage "à la main" que je pratique comme une lubie de technophile, voire un luxe de personne pinailleuse avec trop de temps à sa disposition.
Souvent, il s'agit de personnes dont la tâche première n'est pas de créer des documents web, mais qui se retrouvent à le faire dans le cadre de leur travail, ou bien qui le pratiquent comme "hobby". Je me trouve d'autant plus empruntée que ces personnes jouissent souvent dans leur entourage d'un statut de référence en la matière, de "guru du web design", et qu'ils ont parfois des connaissances (javascript, flash) que je n'ai pas (et qui sont cool). Arrivant avec dans mes baggages HTML-Kit et les recommendations du W3C, je dois faire l'effet soit d'un amateur, doit d'une originale qui ferait mieux de se mettre "à la page" et de voir le monde tel qu'il est (les gens sérieux utilisent DreamWeaver
).
WYSIWIG ou manuel?
Je trouve la lutte inégale. Un éditeur WYSIWIG comme DreamWeaver donne l'illusion de ne nécessiter qu'un minimum d'apprentissage, puisqu'il aborde la page web via une interface graphique et permet à l'utilisateur de manipuler directement le résultat visible de celle-ci, sans se salir les mains dans la source. Il permet également de faire en un tour de main une page qui "en jette" visuellement (du moins pour le néophyte).
Alors que moi, je préconise de travailler avec des lettres et d'apprendre un langage (oh horreur! nous ne sommes pas des informaticiens!), ce qui bien sûr demande une formation, un investissement de départ (du temps!), et bien évidemment, une productivité moindre pendant le "rôdage". Un éditeur WYSIWYG le nécessite également, si l'on veut être honnête, mais il y a cette illusion que c'est "plus facile" et "plus puissant", et surtout que cet horrible HTML est un "langage de programmation" obscur et difficile - pourquoi croyez-vous donc qu'on le cache derrière la jolie page que l'éditeur permet de manipuler avec sa souris?
Ne nous effrayons pas inutilement. Le HTML n'est pas un langage de programmation. C'est un système qui permet de baliser au fil du texte la structure du document, c'est-à-dire qu'au lieu d'indiquer que l'on a affaire à un titre en le mettant en gras, rouge, et 24pt (comme dans un éditeur de texte, que DreamWeaver mime peut-être mais qu'il n'est pas), on l'indique simplement en enfermant le texte du titre entre deux balises, comme ça: <h1>Titre de l'histoire</h1> - et de même avec tout le texte de la page. C'est comme si on mettait à notre texte des petites notes "ceci est un titre", "ceci est un paragraphe", "ceci est important".
Il suffit d'apprendre une dizaine de balises de base (les plus courantes) pour pouvoir "faire du HTML". Une fois qu'on les connaît, écrire un texte "en HTML" ne prend pas plus de temps que le temps qu'il faut pour taper le contenu - il suffit d'ajouter les balises au fil du texte, au fur et à mesure que l'on compose. Bien sûr, il faut un peu d'entraînement, c'est évident. Mais le principe est très simple, et à la portée de toute personne capable de rédiger un texte.
Différence entre documents texte et documents web
WYSIWYG est un acronyme signifiant What You See Is What You Get. Il qualifie à la base un éditeur de texte (comme Word) qui permet de visualiser son texte à l'écran exactement comme il sera imprimé (ce que l'on voit est ce que l'on obtient). Par extension, dans le domaine des éditeurs HTML, il qualifie un programme qui permet de travailler directement dans le résultat visuel de la page web. Malheureusement, le HTML sert à indiquer la structure d'un document, et pas juste à le présenter visuellement.
La plupart des gens n'ont pas conscience de cette différence, parce qu'elle ne semble pas les toucher dans leur utilisation du web. Pourtant elle est de taille.
En effet, un éditeur de texte comme Word est prévu pour imprimer des documents qui seront lus par des êtres humains. L'être humain qui lit le document va repérer les titres, les sauts de paragraphe, les phrases mises en exergue grâce à des marqueurs visuels (par exemple, le titre est en rouge, il y a de l'espace entre les paragraphes, des passages en gras) associés à la signification du texte (ce texte est en italique parce que c'est une citation, mais ce mot est en italique parce que c'est un terme technique, et celui-ci parce qu'il provient d'une langue étrangère).
Peu importe ensuite si le titre est rouge parce que l'auteur a simplement "colorié" en rouge les lettres en utilisant un des outils "visuels" de Word (mettre en gras, en rouge, plus gros, en telle police), ou bien si il a utilisé des outils plus "structurels" comme les feuilles de styles, indiquant que tel ou tel texte est un titre, et précisant ailleurs que tous les titres doivent apparaître en rouge. La personne qui lit le texte ne verra aucune différence, et l'utilisation de l'une ou l'autre méthode reste à la discrétion de l'auteur (les utilisateurs avancés préfèrent les feuilles de style, car c'est un système beaucoup plus puissant, flexible et pratique).
Un document HTML, par contre, n'est pas prévu pour être simplement affiché et lu à l'écran. Il doit pouvoir être imprimé. On doit pouvoir y accéder avec un lecteur braille, ou sur un Palm (qui a des capacitées graphiques très limitées). Et surtout (parce que dans nombre de cas, sur un intranet par exemple, l'accessibilité n'est pas vraiment un souci), il doit pouvoir être lu par une machine, comme par exemple un moteur de recherche ou un système d'archivage. Si je cherche des informations sur les Saint-Bernards, un document comportant comme titre principal "le Saint-Bernard" aura plus de chances d'être ce que je recherche qu'un document comportant "le Saint-Bernard" dans le corps du texte.
Structure
Lorsque je présente le HTML à quelqu'un, et que je désire souligner l'importance du respect des standards et les insuffisances de l'approche WYSIWYG, j'explique que le HTML doit baliser la structure d'un document et non son apparence. J'ai conscience que ce point est souvent mal compris. En effet, beaucoup de gens ne structurent pas leurs documents de façon consciente. Ils les structurent, mais sans se rendre compte qu'ils structurent.
Travailler en HTML demande à l'auteur de rendre consciente cette structuration du texte - c'est peut-être là-dessus qu'il faut insister avant toute chose. Utiliser du HTML lorsque l'on écrit, cela implique peut-être aussi de changer sa façon d'écrire. Pas au niveau du contenu, ni de la forme, mais au niveau du processus. Et personnellement, j'ai toujours trouvé que cela avait un effet positif sur le résultat: un texte bien structuré est plus facile à lire...
Cependant...
Mais de nouveau, je me heurte au même problème. Tout ce que je raconte est probablement bien juste, mais se situe à un niveau de discussion que je n'atteins souvent pas avec les personnes que je cherche à convaincre du bien-fondé de ma démarche. Ces arguments ne peuvent être utiles, entendus et compris que si la personne voit plus loin que l'immédiat, et est prête à entamer une réflexion sur l'information, son stockage et sa transmission - à utiliser aussi une méthode plutôt qu'un autre pour des bienfaits qui ne seront peut-être pas immédiatement visibles.
Il semblerait que les personnes auxquelles on parle "en chair et en os" ne soient pas réceptives aux mêmes arguments que les "web-people", ces personnes que l'on n'a jamais vu, et avec lesquelles on communique par emails, sites, newsgroups et chatrooms interposés.
Ce document va évoluer, j'y compte bien. Je voudrais qu'il soit une ressource utile, abordant le problème de la "guerre des éditeurs" sous un angle pratique: comment expliquer à une personne qui connaît un petit peu Internet et le HTML, qui pense (comme tout le monde, il s'agit du bon sens!) que les "pros" utilisent tous DreamWeaver, que baliser à la main est une pratique archaique (et lente, difficile, peu pratique et j'en passe) qu'il est important de produire des documents respectant les standards, que le travail dans la source (pour des documents textuels) n'est pas si difficile que ça, et qu'un outil peut devenir une prison dans laquelle on s'enferme?
Pour le moment, il fait surtout état des arguments que je pense avoir à disposition, ainsi que de mon découragement. J'attends avec beaucoup d'impatience que vous me fassiez part de vos expériences et réflexions sur cette question.
Nouveau
En vrac, parce que maintenant je n'arrive pas...
- L'importance du mode plan lorsque l'on crée des documents (savez-vous que la plupart des personnes "normales" qui utilisent Word n'exploitent pas les feuilles de styles?!
- Gros argument "pro-DW" pour les gens "d'en haut": interface graphique, donc facile à apprendre. Les gens vont se lasser et se fatiguer à travailler "dans la source", au cas où ils l'auraient appris.
- Je prétends qu'il n'est pas nécessaire d'investir plus de temps de formation pour apprendre un minimum de html, permettant de créer des pages simples (texte, images, un tableau par-ci par-là) utilisant une feuille de styles déjà existante, que d'apprendre à utiliser DW de façon efficace. Quel que soit l'outil choisi, l'investissement de départ est quasi-identique. (Est-ce que j'ai tort?)
- Claude me rappelle que même si les interfaces graphiques ont mis l'ordinateur à la portée de tous, peu de gens maîtrisent leur ordinateur (je le vois tous les jours dans le cadre de mon travail).
- Pointer-cliquer, pointer-cliquer, c'est souvent plus long que de taper sur des touches (pour autant que l'on sache taper) - et ça fait des tendinites (à propos, vous savez qu'on a obtenu de bons résultats en remplaçant les souris par des trackballs, dans les entreprises où les employés souffraient de "maladies-souris"? - si vous avez des sources, d'ailleurs, je les accepte volontiers...)
- Les personnes à "convaincre" ne font généralement pas de HTML... Il faut donc souvent leur expliquer tout le système.
- Est-ce que les avantages à "court terme" d'une interface graphique comme DW contre-balance réellement les avantages à long terme d'enseigner un peu de HTML aux employés concernés, et d'utiliser du code standard, avec CSS?
- J'ai l'habitude de débattre des standards dans le cadre du web, et non d'un intranet. Certains arguments (accessibilité, bande passante - quoique!) fondent comme neige au soleil... est-ce qu'il y en a de nouveaux?
- Je trouve qu'utiliser DW revient souvent à utiliser un trax pour renverser un piquet de tente dans un jardin...
Ce qui rend simple l'apprentissage du HTML...
Samedi 27 novembre 01
Un collègue de travail me faisait très justement remarquer il y a quelques jours que ce qui rendait mon approche du HTML simple, c'était qu'une feuille de styles CSS commune et des "includes" PHP étaient déjà en place. Et d'un coup j'ai compris! Justement, je parle d'apprendre le HTML pour l'utiliser dans un certain contexte.
En effet, je me tue à répéter à qui veut l'entendre qu'apprendre un peu de HTML est à la portée de tous, et qu'il n'est pas difficile d'enseigner à "l'employé moyen" de quoi produire des documents pour l'intranet ou le web. J'ai l'impression qu'on me prend souvent pour une rigolote, quand je dis ça.
Mais en fait, peut-être que je n'explique pas assez précisément ce que j'entends? Je ne prétends pas qu'il est facile d'apprendre toutes les techniques nécessaires pour créer un site à partir de rien. Maîtriser tout le HTML et ses subtilités prend du temps. La maîtrise du CSS et du PHP ne vient pas en quelques heures (même si on peut facilement s'y initier). Mais il n'est pas nécessaire que "l'employé moyen" sache créer formulaires et tableaux impriqués complexes, ni qu'il sache produire une feuille de styles ou un système de gabarits en PHP.
La mise en place préalable d'un tel système permet justement de réduire au minimum le HTML que doit connaître l'employé afin de pouvoir créer de façon indépendante des documents standards. Il ne nécessite pas que l'employé apprenne à maîtriser un nouveau logiciel (souvent lourd, si l'on garde en vue ce que l'on désire vraiment faire avec ces documents). Il garantit une présentation homogène de toutes les pages concernées, puisque toute la présentation est régie par la feuille de style (et que les parties communes à tous les documents, comme un en-tête ou bien un système de navigation, sont gérés par PHP).
Mon approche ne consiste donc pas à dévaluer les compétences de ceux qui sont capables de créer un site à partir de rien. Elle consiste plutôt à dédramatiser le HTML, et à montrer que dans un cadre bien conçu donné, il permet à tout un chacun de contribuer au contenu d'un site ou de l'intranet, en apprenant un peu de syntaxe et une dizaine de balises.
