Chiiiiiic, un débat de fond ! Passant sur le forum, j'ai inévitablement été attirée par le titre de ce sujet, qui pose une question cruciale, sinon LA question cruciale.

I. GuppY Land

Une naissance estivale sans péridurale

Je crois que GuppY Land est né l'été dernier (à moins que ce ne soit l'été d'avant, je ne sais plus...) J'ai conçu cette version initiale, avec les renforts précieux de Balou. Tous deux y avons bossé des heures et des jours et des nuits ; j'y ai pour tout dire consacré l'intégralité de mon mois d'août. Le travail était énorme, déjà à l'époque, bien que le nombre de forks fût moindre par rapport à ce qu'il est aujourd'hui. Nous avons dû longuement et âprement débattre pour trouver une formule de présentation rigoureuse, documentée.

Les premiers problèmes

Une fois lancé, le site a "marché" au-delà de nos espérances, mais les problèmes de maintenance sont vite apparus : les mises à jour trop fréquentes absorbaient un temps considérable ; il était dur de suivre le rythme... et dans l'équipe, dur de trouver des volontaires pour cette tâche peu enthousiasmante !

Bien vite, surtout, j'ai été frappée par le manque de participation de la communauté GuppYste. Non que les GuppYstes ne contribuent pas à la croissance du poisson ! Loin s'en faut ! Mais nombreux étaient ceux qui fabriquaient forks, plugins, skins et autres éléments graphiques et les offraient en téléchargement sur leur site, après en avoir posté l'adresse ici, sans les envoyer à GuppY Land, de sorte que la vocation originale de cet entrepôt s'est perdue. Je constate simplement, sans amertume (à l'époque, comme j'étais très engagée dans l'aventure GuppYste, je dois dire que mes sentiments étaient moins... retenus !)

Une solution éphémère

Je crois deviner la cause, bien humaine, de cette attitude : c'est, convenons-en, agréable de voir des visiteurs arriver sur son propre site à la pêche aux guirlandes qu'on a découpées et c'est frustrant de se priver de cette gratification flatteuse. C'est la raison pour laquelle nous avons opté pour un principe d'exclusivité, estimant normal qu'un créateur de plugins ou skins conserve l'exclusivité de ses productions pendant une quinzaine de jours, avant de les envoyer en partage sur GuppY Land. Il nous semblait qu'ainsi les créateurs étaient "récompensés" dans leur démarche et que GuppY Land pouvait toutefois remplir sa tâche fédératrice des ressources.

De l'échec à la coupe sombre

Pourtant, cela échoua. Tout le monde ne joua pas le jeu, le fonctionnement de GuppY Land devenait vraiment lourd, à cause des mises à jour constantes qu'il réclamait, d'une pénurie de personnel pour s'y coller et d'un découragement progressif face à la "dérive"...

La partie "skins" surtout était lourde : à chaque version, les skins répertoriées devenaient obsolètes ; les créateurs ne pouvaient pas toujours les mettre à jour, certains le faisaient, mais n'envoyaient pas les MAJ... ou bien nous ne pouvions plus au contraire suivre le flot de celles qui parvenaient - bref, j'ai proposé que, pour "sauver" GuppY Land de la désaffection dans laquelle il risquait de sombrer en offrant des ressources obsolètes, nous sacrifiions la section "skins", pour nous recentrer sur les plugins / forks. Cela n'a, je le crains, pas suffi à remettre GuppY Land à flots - manque de personnel, ah !

Un pis-aller : le répertoire de ressources

Dans l'attente d'une meilleure solution, lorsque j'ai refait la doc de FreeguppY l'an dernier, j'ai eu l'idée d'ouvrir dans la section "Liens" du site un répertoire de sites-ressources, histoire de "re-router" les GuppYstes à la source des sites producteurs, pour seconder GuppY Land, à l'abandon. J'ai ajouté une liste de sites producteurs de skins sur GuppY Land pour remplacer feu la section "Skins". Cette liste n'a hélas pas été maintenue. La faute m'en incombe partiellement : j'ai peu à peu réduit mon engagement dans l'équipe, en raison de mes occupations professionnelles et aussi, dois-je dire, d'une certaine forme de lassitude par rapport au poisson, de sorte que je ne l'ai pas tenue à jour et personne n'a pris le relais.

Perspective : rideau ou refonte ?

Quid de GuppY Land maintenant ? Je pense comme Djchouix qu'il n'a plus qu'à pousser son chant du cygne... Si son ambition était légitime (et le reste), je ne vois pas bien comment il pourra atteindre ses objectifs, sans risquer d'être noyé. Qui aura assez d'abnégation et de temps à accorder à l'entretien ingrat de ce site ? La tâche est énorme ! Du reste, si GuppY Land était à refaire, je ne le referais pas sous sa forme actuelle.

Etant donné le manque de personnel actif dont souffre la GuppY Team, je crois que le mieux est en effet de réduire la tâche de l'entrepôt à une tâche de collecte et de présentation des ressources, en évacuant la question du stockage, pour minimiser l'effort de maintenance. L'idée de Djchouix, que je relaie, serait que les créateurs de skins / plugins / autres fassent eux-mêmes l'annonce et le suivi de leurs producations sur l'entrepôt. A charge pour eux d'annoncer la dernière skin produite, la dernier patch du fork machin ou la MAJ de leur plugin.

Une question demeure : le feront-ils ? Puisqu'ils n'ont pas su profiter de la formidable plate-forme qu'eût pu être GuppY Land dans sa première version (je rappelle qu'on faisait tourner une bannière publicitaire du site contributeur pour chaque contrib apportée), auront-ils plus à coeur de le faire si la gestion des affaires leur est complètement déléguée ?

Je crois qu'il y a un moyen "gentiment coercitif" pour les y encourager fortement (comprendre : les y contraindre) : il s'agirait de prohiber - je choisis ce terme à dessein, "interdire" sonnait un peu stalinien ;-) - les annonces de parution de skins, plugins, boules et guirlandes... sur le forum. Car en gros, c'est sur le forum qu'on pêche les infos relatives aux skins, plugins, etc. En prohibant toute annonce de ce genre ici, en redirigeant tant les demandeurs que les offreurs sur GuppY Land, on pourra réorienter le forum vers son rôle d'assistance / dépannage et redynamiser GuppY Land dans son rôle d'entrepôt entretenu et mis à jour.

L'expérience vaut le coup d'être tentée. Le plugin OpenFiches pourrait être une base de travail peut-être ? Ou un petit Wiki sans BDD pour que chacun puisse éditer à loisir ses fiches de présentation ?

II - Et GuppY dans tout ça ?

Je trouve remarquable le travail effectué par l'équipe active, notamment sur la dernière version, qui s'est penchée sur l'aspect sécuritaire, comme dirait Sarko ;-). Ce travail a été un vrai travail de fond, un vrai développement, essentiel, de même que le travail effectué en coulisses, dans l'admin, sur l'ergonomie. Mais, je dois dire en bémol que je regrette pour ma part certaines orientations du développement.

La galerie : parente pauvre du développement

Le système des mini-messages avait été refait dans une version antérieure pour éliminer l'usage extensif des popups dont l'abus est nuisible à la santé. Bizarrement, dans cette version, les popups ont été réintroduits dans la galerie, ce qui m'apparaît contradictoire. Quoiqu'à bien y songer, l'usage de popups se justifie traditionnellement dans les diaporamas, pour agrandir les images. De ce point de vue, j'avoue ne pas comprendre le choix qui a été retenu pour la présentation de la galerie : pourquoi n'avoir pas opté pour une simple galerie de vignettes agrandissables, avec le commentaire de la photo en légende dans la popup ? C'est une présentation certes traditionnelle, mais si tant de gens l'utilisent, c'est peut-être parce que c'est la façon la plus ergonomique de présenter ses photos.

Pour moi, les fonctionnalités de GuppY sont au top depuis la version 3, à l'exception du photorama qui est la fonctionnalité "pauvre" de GuppY, celle qui n'a pas évolué de version en version, alors que les scores des plugins Diaporama de Jean-Mi et PhotosGD de Nicolas indiquaient un besoin de ce côté-là. Sans se lancer dans des constructions abracadabrantesques (je cite), peut-être une simple liste de catégories, avec une planche de vignettes cliquables, eût-elle fait le bonheur des utilisateurs :-)

Trop de javascript tue le javascript

Il y a aussi une pratique très présente dans la dernière version et dont l'usage extensif n'est pas sans m'interpeller : celle des menus rétractables. Ces derniers avaient été introduits dans une version antérieure pour permettre le repliement des menus des boîtes articles, afin de compacter les colonnes latérales, qui devenaient kilométriques au bout de quelques dizaines d'articles. Le chargement des pages était alors ralenti, l'interface encombrée perdait en lisibilité, bref, cette évolution s'imposait, non pour des raisons esthétiques, mais pour des raisons pratiques, d'autant que toutes les pages étaient concernées, puisqu'il s'agissait du squelette du site.

Or j'ai remarqué que l'emploi du menu rétractable s'était considérablement étendu dans la dernière version : aux liens, aux news, à la faq, aux téléchargements, à la galerie... Mais je me demande : y gagne-t-on en lisibilité ou en termes d'ergonomie ? J'hésite à répondre par l'affirmative. Devoir déplier menus / sous-menus pour afficher un item, un lien par exemple, me semble souvent fastidieux. C'est là une question de convenance personnelle, cela dit.

Mais au-delà de cet aspect, se pose la question de l'emploi systématique et massif de javascript. En cas de javascript désactivé (option offerte par des navigateurs comme Firefox ou Mozilla), le site est totalement inaccessible. Pas moyen de voir quoi que ce soit : le site reste fermé comme une huître. En terme d'accessibilité, c'est fort dommageable. On objectera que la plupart des visiteurs auront tôt fait de comprendre qu'ils n'ont qu'à activer le javascript pour régler le problème ; il n'empêche qu'il est délicat de contraindre quiconque à modifier ses préférences pour accéder à un site. (Voir le guide des bonnes pratiques du Web à ce sujet).

Certes, le problème se posait déjà avec les menus-articles rétractables. Mais il suffisait pour le contourner de faire à la main une liste de liens pointant sur les articles et de rendre cette page accessible. Pour l'essentiel, le reste du site fonctionnait normalement (à condition d'introduire toutefois une petite modif dans la forme du lien du popup de téléchargement pour que la fenêtre popup s'ouvre en pleine page lorsque le javascript est désactivé). Avec l'usage étendu des menus rétractables, il n'y a plus d'échappatoire possible : l'affichage du site est régi de part en part par le javascript et rien n'est prévu pour le cas où java est désactivé.

Je pense à une solution : il faudrait faire en sorte qu'en cas de javascript désactivé, les menus apparaissent automatiquement dépliés par défaut. Ainsi l'accessibilité au contenu du site serait-elle préservée. J'ai fait un test sur le site de Tanet (que je salue bien bas au passage) : la fonction qu'il a implémentée fonctionne de cette façon. Si javascript est off, alors tous les menus sont dépliés : le contenu est sauf. Si javascript est on, alors les menus sont rétractés et le visiteur les ouvre / ferme à sa convenance. A mon avis, la mise au point d'une solution alternative de ce genre s'impose pour les raisons évoquées supra, d'autant plus que la pratique du menu rétractable a gagné toutes les fonctions de GuppY.

Les frames, c'est mal :-)

Une autre orientation du développement m'interpelle : l'usage croissant des frames. GuppY en était dépourvu à l'origine (me semble-t-il), or il en compte 3 dans la page où j'écris actuellement : deux frames pour l'éditeur et une frame pour le message auquel je réponds. Si le calendrier était activé, cela en ferait quatre. Si on ajoute l'usage des frames via le plugin IconeFrame de Jean-Michel, cela fait beaucoup beaucoup de frames pour un site. Si on ajoute encore certains plugins (plugin Gifs par exemple sur Guppy Italia ou plugin Tchat), le nombre de frames devient proprement gênant.

Une fois encore, les bonnes pratiques recommandent de limiter (sinon renoncer à) l'usage des fenêtres enchâssées, ne serait-ce que parce que certains navigateurs (ou barres d'outils ou extensions - voir Greasemonkey pour les Gecko'likes) permettent d'éliminer les frames des pages qui les utilisent. L'avantage, c'est qu'on est ainsi débarrassé d'une grande partie des bannières publicitaires qui encombrent certaines pages, et qui sont souvent implémentées via des frames. GuppY a tendance, à mon goût, à recourir par trop à cette solution.

Un code XHTML valide, c'est bien

Le HTML a été supplanté par le XHTML, en attendant une évolution à long terme vers le XML. GuppY en est resté pourtant à un code HTML pas toujours orthodoxe. Il me semble que le faire évoluer vers le XHTML représente un enjeu crucial pour l'avenir du script, au moment où beaucoup se préoccupent de produire des CMS / scripts formatés en XHTML propre-qui-valide. Le validateur du W3C n'est pas seulement une mode pour webmasters snobs et / ou "bobo" : il est devenu le garant d'un contenu stable et accessible. Combien de fois un petit tour de validation de mes pages m'a-t-il permis de débusquer un tableau mal fermé ou un lien mal formaté, qui auraient à terme flingué mon affichage ? Il est devenu important pour un CMS soucieux d'être pris au sérieux de tout faire pour produire / offrir un code propre et valide.

GuppY en est encore loin, en dépit d'un sérieux nettoyage effectué lors d'une précédente version. Il est resté en HTML fautif au lieu de glisser, ô cygne majestueux, vers un XHTML pur et sans mélange (comment cela je m'égare ???) ;-)

C'est rien que la faute aux nouveaux éditeurs

La faute en incombe surtout aux éditeurs WYSIWYG embarqués . S'ils offrent des interfaces de saisie plus agréables que le textarea natif (aucune balise HTML apparente, impression d'écrire comme avec un traitement de texte... ), ils produisent souvent un code hypra-dégueu. D'ailleurs le principe même de leur fonctionnement les conduit de facto à générer un code lourd et surchargé d'erreurs de syntaxe.

Imaginons le cas suivant : dans un article, on écrit une phrase avec une police arial bleue, puis on change d'avis et on met du Verdana rouge ; finalement, on introduit un tableau, mais on le déplace, en supprimant deux cellules. Au cours de ces manipulations, les balises vont s'empiler les unes sur les autres dans un joyeux capharnaüm et une partie d'entre elles vont rester dans la source comme des parasites orphelins. Le rendu visuel ne sera pas perturbé en apparence, mais un coup d'oeil au code-source ferait s'évanouir d'horreur les W3C-extrémistes !

Aussi, quand bien même le code du GuppY de base, livré sous blister, serait propre, le code engendré par les éditeurs embarqués s'attacherait-il à le pourrir en moins de temps qu'il n'en faut pour dire "Indiana Jones"... C'est d'ailleurs, d'après ce que j'avais compris aux dernières nouvelles, ces éditeurs qui empêchaient GuppY de transiter vers le XHTML : ils ne parviennent pas à produire du XHTML.

Autrefois (ah, mes aïeux !), Guppy était livré avec un simple textarea doté de touches de raccourcis balises, comme sur les forums PhpBB. On saisissait son blabla, puis d'un clic sur le bouton | B |, on mettait le texte en gras. Seulement, ce n'était pas le gras qui apparaissait, mais les balises de mise en forme (b)texte(/b). L'avantage de cet éditeur préhistorique, c'est qu'avec lui, on voyait tout de suite quand les balises étaient mal placées, de sorte que le code produit était aisément contrôlable et corrigeable. L'inconvénient, c'est qu'il fallait se familiariser un peu avec le HTML, s'accoutumer à la présence de ses balises de formatage et surtout se faire à l'idée que tout ne fonctionne pas en visuel comme Word !

Pour toutes ces raisons, j'ai conservé le textarea "antique" sur mon site. Il est léger, non framé, tout aussi fonctionnel que celui-ci, compatible IE-Mac-Mozilla-Firefox-Opera (grâce au boulot de Djchouix - embrassades répétées au passage !), mais non WYSIWYG. En contrepartie, il produit un code sain dans un contenu sain et mon site y gagne tant en légèreté, qu'en propreté et accessibilité.

Nous voici confrontés à une aporie : doit-on revenir au textarea de base non wysiwyg ? Je ne crois pas : GuppY étant majoritairement utilisé par des grands débutants, le choix du Wysiwyg se justifie par sa convivialité. Néanmoins, il faudrait dans le développement à venir redoubler d'efforts pour que le code généré soit proprement formaté (pas de majuscules dans les balises, respect de la balise ouvrante-fermante, pas d'attributs dépréciés, etc.) et accompagner ce développement d'une sensibilisation croissante des utilisateurs au fait que c'est aussi à eux de veiller à la propreté de leurs pages, en jetant un oeil au code-source produit par l'éditeur qu'ils utilisent, afin de l'expurger de ses scories. On peut - j'ai fait l'expérience sur le site d'un copain - réduire la taille du code généré par les éditeurs de moitié avec le même résultat à l'affichage !

Les tableaux, c'est mal ;-)

Les guides de bonnes pratiques et l'orientation syntaxique du XHTML recommandent de cesser d'utiliser les tableaux à des fins purement esthétiques, et d'utiliser à la place les DIV couplées aux CSS. Un tableau doit être utilisé pour présenter des données tabulaires - CQFD. Or une grosse partie du squelette de GuppY repose sur des tableaux imbriqués, à des fins uniquement cosmétiques.

Il est pourtant possible d'éliminer la plupart de ces tableaux et de leur substituer des DIV CSSisées. Cela allège considérablement le code, en le compactant. La page se charge plus vite. Par ailleurs, la syntaxe de la page est ainsi respectée au mieux, les tableaux étant réservés à la présentation de données qui ne peuvent être présentées autrement.

Par exemple, la boîte Newsletter nécessite-t-elle le tableau qu'elle contient ? En réalité, non ; ce tableau est utilisé pour positionner les éléments. Voyons le code source de cette boîte sur la présente page :

<table summary="box_side" class="htable1" border="0" cellpadding="0" cellspacing="0" width="166">
<tbody><tr>
<td class="stl"></td>
<td class="stc"><p class="titrebox">Newsletter</p></td>
<td class="str"></td></tr><tr>
<td class="sl"></td>
<td class="tblbox">
<form name="subscribe" action="newsletter.php?lng=fr" method="post">
<table align="center" border="0" cellpadding="0" cellspacing="0">
<tbody><tr><td class="box" align="center">Pour avoir des nouvelles de ce site, inscrivez-vous à notre Newsletter.</td></tr>
<tr><td align="center"><input class="texte" name="nlpseudo" size="18" value="Isa" onfocus='this.value=""' type="text"></td></tr>
<tr><td align="center"><input class="texte" name="nlmail" size="18" value="realia@free.fr" onfocus='this.value=""' type="text"></td></tr>
</tbody></table>

<table align="center" border="0" cellpadding="0" cellspacing="0">
<tbody><tr><td><input name="action" checked="checked" value="sub" type="radio"></td><td class="box">S'abonner</td></tr>
<tr><td><input name="action" value="unsub" type="radio"></td><td class="box">Se désabonner</td></tr>
<tr><td colspan="2" align="center"><img src="inc/img/skin/skn_benoit/button_left.png" alt="["><input class="bouton" value="Envoyer" title="Envoyer" name="submit" type="submit"><img src="inc/img/skin/skn_benoit/button_right.png" alt="]"></td></tr>
<tr><td colspan="2" class="box" align="center">
1518 Abonnés</td></tr>
</tbody></table>

</form>
</td>
<td class="sr"></td></tr><tr>
<td class="sbl"></td>
<td class="sbc"></td>
<td class="sbr"></td>
</tr>
</tbody></table>

Outre le fait que la skin utilise un premier tableau (en bleu) pour afficher les coins ronds (il existe des solutions de remplacement avec des DIVS mais peu aisées à développer il est vrai), on note la présence de deux autres tableaux enchâssés (rouge et orange), dont on pourrait aisément se débarrasser.

C'est ce que j'ai fait sur mon site. Voici le code qui affiche ma boîte Newsletter :

<div class="boxside">
<div class="titrebox">Newsletter</div>
<div class="boxcontent">
<form name="subscribe" action="newsletter.php?lng=fr" method="post">
<div align="center">
Abonnez-vous pour recevoir des nouvelles du site.<br>
<input class="texte" name="nlpseudo" size="18" value="Isa" onfocus='this.value=""' type="text"><br>
<input class="texte" name="nlmail" size="18" value="realia@free.fr" onfocus='this.value=""' type="text"><br>
<input name="action" id="sub" checked="checked" value="sub" type="radio"><label for="sub">S'abonner</label><br>
<input name="action" id="unsub" value="unsub" type="radio"><label for="unsub">Se désabonner</label><br>
<input class="bouton" value="Envoyer" name="submit" type="submit"></div></form>
</div></div>

Décortiquage :
- en rouge : la DIV qui forme la boîte
- en turquoise : le titre de la boîte
- en vert : la DIV qui contient le contenu (sic) de la boîte
- en violet : une DIV pour centrer l'ensemble des textes et éléments du formulaire d'abonnement.

Voilà une sérieuse économie de code, réalisée à moindre frais, qui élimine deux tableaux inutiles, allège considérablement le code, sans affecter le rendu qui est exactement le même. On peut, de la même manière, éliminer une dizaine (sinon plus) de tableaux du squelette de GuppY. Il me semble que le développement pourrait aller dans ce sens, qui allie optimisation, respect des standards et préserve l'accessibilité du site sans sacrifier à l'esthétique, grâce aux magiques CSS ;-)

La cosmétique au détriment du contenu ou l'inverse ?

Un dernier point avant de mettre un terme à cette odyssée :-) : j'ai noté que la dernière version comportait des améliorations destinées à multiplier les possibilités de skinnage, en offrant des combinaisons diverses (skinnage du header entier ou partiel, skinnage des bannières, skinnage indépendant des citations, etc.)

Je crois assurément qu'il est important de soigner la présentation d'un site. De même qu'un joyau emballé dans du PQ plein de m*** a toutes les chances de passer inaperçu, de même un site en vrac, sans attrait, risque-t-il d'éconduire son visiteur avant que ce dernier ait eu le temps de prendre connaissance de son contenu. Enfin, pour résumer, on n'attire pas les mouches avec du vinaigre.

De ce point de vue, étendre les solutions de skinnage est louable. La souplesse introduite dans la dernière version est méritoire, mais je trouve que son coût est excessif en matière de propreté du code justement. Je m'explique : imaginons que pour ma skin, je choisisse de styler les citations, mais pas la bannière. Lorsque je passe ma page au Validateur, je note des erreurs. Celles-ci sont dues au fait que je n'ai pas skinné ma bannière, laissant donc vides des attributs CSS inclus directement dans le code, ce qui n'est pas recommandé. Autrement dit, ce que je gagne en souplesse cosmétique, je le paie en contrepartie par des erreurs supplémentaires dans le code.

Je trouve ce prix à payer exorbitant et déraisonnable. Que le skinnage de GuppY s'assouplisse et s'étende, d'accord, mais s'il doit "pourrir" le code ou engendrer une syntaxe fautive, je crois plus sage d'y renoncer. La cosmétique est et doit rester au service du contenu ; elle est l'écrin, pas le bijou, et quand elle altère le bijou, elle doit céder le pas.

Je crois que s'il m'était permis de faire des voeux pour l'avenir de GuppY, je les formulerais ainsi : l'enveloppe d'un site doit être soignée, certes, mais il importe que cette carrosserie ne dissimule, sous le clinquant de son vernis d'apparat, ni un moteur essoufflé par un tuning forcené, ni des malfaçons qui risquent, à terme, de la défigurer.

Bref, il est important de garder à l'esprit :
- qu'un bon CMS est un CMS ergonomique, fonctionnel, sécurisé, dont le code est proprement formaté et valide, respectueux tant des standards que des bonnes pratiques Internet
- que le contenu prime sur les considérations cosmético-esthétiques

Pour conclure, je souhaite une longue vie à GuppY, qui a, crois-je, de beaux jours devant lui, à condition peut-être de mieux fixer sa voie :-)