————————–
Aujourd’hui, je viens vous parler d’un fait réel dont j’ai été témoin en parcourant les sujets sur le Site du Zéro, et qui prouve combien la règle du « payant = qualité » n’a aucun sens dans le monde logiciel.

Ce cas est celui d’un homme, qui a acheté le logiciel « Web Creator » pour faire le site-vitrine pour un proche qui fait de la reproduction sur toile déco. Mais bien vite, il s’est rendu compte, par les retours de sa clientèle, que le code généré est bordélique et lourd, bourré de scripts, avec du texte converti en images et tout ça, pour une page lourde à charger, ce qui ne remplissait pas du tout l’objectif d’un site simple, efficace et rapide. Vous pouvez d’ailleurs lire son commentaire sur ce lien

Même si le monsieur a retiré le lien de son post, j’ai pu finalement récupérer l’adresse du site grâce au cache de Google après avoir lancé la recherche avec le titre complet du sujet.

Voici donc l’adresse du site (Note : Le site a été totalement refait depuis)

Ce que vous voyez en premier n’est que l’intro. Allez plus loin et vous verrez combien ça se gâte vite !

Mais puisque le site sera bientôt refait par quelqu’un qui refera le site avec du code valide, j’ai pris des captures et récupéré les codes HTML pour les mettre dans des fichiers .txt afin de pouvoir continuer à vous montrer les arguments pour éviter Web Creator. Je prends aussi à l’avance le poids de chacune des pages examinées, pendant que la version actuelle du site est présente.

D’abord, on commence par la page d’accueil, sur laquelle on arrive après avoir passé l’intro

Mais avant de continuer, je vais vous montrer deux captures pour vous montrer l’absurdité du code généré par Web Creator.

La page, avec Javascript désactivé : Lien
La même page, avec Javascript activé : Lien

Première constatation : Ça requiert que Javascript soit activé pour que la page se centre ! O_O
Pourquoi donc utiliser du Javascript pour centrer une page, alors qu’on peut le faire avec margin:auto; en CSS et qu’il existe des hacks CSS pour les versions de navigateurs ne reconnaissant pas la propriété ? C’est des kilo-octets pour rien, en plus d’être à l’encontre des règles de bonnes pratiques qui déconseillent l’abus de Javascript, ainsi qu’une utilisation intrusive (en remplacement plutôt qu’en surcouche) ! De plus, le fait de mettre la page à gauche est fatiguant pour ceux qui ont une grosse résolution ou un écran large !

Maintenant, préparez vos Gravol, car on va maintenant regarder le code !
Voici le .txt du code de la page d’accueil : Voir le code

Imbuvable, n’est-ce pas ? On peut déjà faire les constatations suivantes :

• Le code est bourré de code Javascript qui aurait pu facilement être évité
• Il n’y a aucune feuille CSS externe, tout est imbriqué à même les éléments HTML avec l’attribut style où l’on voit du positionnement absolu à profusions, en plus des balises de mise en forme !
• Il n’y a quasiment pas de balises sémantiques ! En débranchant le CSS, on remarque encore plus le bordel, en voyant la page arrangée dans un ordre complètement illogique, ainsi que la quantité inutile d’images, en particulier pour le fond de page ! D’ailleurs, je viens de prendre deux captures pour vous le montrer : capture partie 1 – capture partie 2
• Aucun attribut alt dans les images, pour les textes de remplacement, pour ceux qui ne peuvent voir les images, dont les non-voyants ou les robots de référencement ! Ceci est encore plus catastrophique quand il s’agit d’images porteuses de contenu ou servant de support de lien !

Et avec un tel code généré, la page d’accueil fait plus de 700 Kilo-octets, ce qui est extrêmement lourd pour une simple page d’accueil ! La même page, codée selon les normes du W3C (feuille externe, pas de javascript inutile, nombre d’images au minimum, et celles-ci optimisées), aurait pesé plus de 7 fois moins ! Pour un hébergement ayant une limite de bande passante, ça fait une énorme différence, car si la page d’accueil, dans son état actuel était visitée 1000 fois, la bande passante utilisée serait aussi grosse que la capacité d’un CD et aurait donc approché le giga-octet ! La même page, aux normes avec son petit 100Ko, n’aurait, en 1000 visite, généré que 100 Mo, soit 600 Mo de moins qu’avec la page actuelle !

Maintenant, passons à l’analyse de la page suivante : la page de présentation.

Comme avec la page d’accueil, je vous montre la capture avec le style activé

Sur la capture, le texte paraît être du texte brut, mais attention ! Ce que vous allez voir, dans la capture suivante va troubler tout bon webmaster respectueux des standards : Partie 2 de la page, sans style

Le bloc avec le texte que vous avez donc vu est une image ! Et le texte réel est caché !

Et je ne ferai pas de surprise en montrant le code, tout aussi bordélique et lourd : Voir le code

Et je ne vous ferai pas de surprise non plus sur le poids par rapport à l’optimisation possible : 383 Ko ! Aux normes, elle aurait pu faire moins de 80 Ko, voire même moins de 50 Ko !

La page de contact est sensiblement pareille à la page de présentation (texte-image inutile), donc je passe à la dernière page à analyser, qui contient un formulaire : la page pour les clients, dont voici sans tarder la capture d’écran

Première constatation : On ne voit aucun label, ces étiquettes que l’on met avant chaque champ de formulaire et qui, par souci d’accessibilité, doit être lié à son champ ! Les « étiquettes » sont écrites à même les champs de formulaire !

Et maintenant, on débranche le CSS : Page client sans CSS

Vous pouvez constater, encore une fois, l’incohérence de la structure de la page générée : le champ multiligne se trouve après le bouton « Envoyer » et en plus, le texte qui s’affiche avant le formulaire avec le CSS activé, se trouve placé après le formulaire une fois le style désactivé !

Vous pouvez d’ailleurs constater l’absence d’éléments label et l’incohérence de la structure en voyant le code de la page

Et on remarque alors que le bouton « Envoyer » est inutilisable si Javascript est désactivé !

Et on finit avec, encore une fois, l’analyse du poids de la page qui nous donne 223 Ko cette fois-ci et qui, encore une fois, aurait pu être largement optimisé en respectant les normes, ce qui fait que la page aurait pu faire facilement moins de 50 Ko !

Conclusion

À partir des trois pages analysées, j’ai pu vous montrer combien un logiciel payant n’est pas nécessairement meilleur que les alternatives libres comme KompoZer qui respectent mieux les standards du Web. Et croyez-moi, ce n’est pas le premier site « WeCreator-made » que j’ai vu. Les autres sites que j’ai vus et qui ont été générés avec le même logiciel, soit le site-vitrine de Help-On-Line.org (qui n’existe plus), ainsi que le site de la v1 de Host-on-line.org (qui n’existe plus non plus, et qui appartenait à Help-on-line.org), et le code de ces deux sites était aussi horrible. De plus, j’ai même vu, via ce sujet, un site généré avec ce logiciel, dont les javascripts ne fonctionnaient même pas sous les autres navigateurs mise à part Internet Explorer et Netscape Communicator ! Oui, vous avez bien lu, NETSCAPE COMMUNICATOR ! Un vieux navigateur qui date d’aussi loin que mes premières années sur le Web, soit il y a près de 10 ans !

Ma recommandation

Que ce soit pour un petit site persos ou pour un gros site d’envergure, ne jetez pas vos euros ou dollars par la fenêtre et, autant que possible, tournez-vous vers ces alternatives qui ne vous coûteront pas un sou, mais qui auront un résultat bien plus satisfaisant :

• Écrire votre site de A à Z. De cette façon, votre code sera éditable à volonté, et vous pourrez y intégrer du PHP par la suite, sans problème. Vous pourrez apprendre les bases sur le Site du Zéro
• Utiliser un système de gestion de contenu : Les choix de scripts libres ou freeware (gratuit et non-libre) ne manquent pas, que ce soit Joomla!, XOOPS, SPIP, Drupal, GuppY ou CMS Made Simple pour les sites complets, phpBB, PunBB, FluxBB, Connectix Boards, MyBB, SMF, FSB ou XMB pour les forums, ou bien WordPress, Dotclear ou PluXml pour les blogs, pour vous permettre de monter votre projet rapidement si vous n’avez pas le temps de le coder vous-même. De plus, la plupart de ces scripts sont respectueux des standards du Web et pas trop lourds pour la bande passante (mais après, ça dépend du template).
• Ou à la limite, utiliser un éditeur HTML libre comme KompoZer qui s’appuie sur le moteur de rendu Gecko (le même que celui utilisé par Mozilla Firefox) qui est, déjà au départ, respectueux des standards. Mais cette option est plus limitée que les deux premières et je ne vous conseille pas de vous reposer uniquement sur l’aspect visuel.

Alors, bon webmastering sur le chemin de la lumière, avec l’esprit serein à l’idée d’avoir gardé vos sous pour acheter autre chose… comme par exemple un cadeau pour l’être aimé !

Maintenant que ça s’est calmé et que Beauce Carnaval a repris la route pour aller égayer d’autres villes ailleurs au Québec avec ses manèges, ses jeux d’adresses et les peluches à gagner, me voilà de nouveau devant mon PC où je peux enfin écrire ma critique de design Web, ou « Webdesign review » comme pourrait le dire mon grand frère.

Le site qui sera analysé

En naviguant sur le forum Servhome, je constate qu’il y a un nouveau message dans la section « Logiciels libres ». Le sujet parle de Pixia, un gratuiciel de dessin pour Windows (mais qui peut tourner sous Linux avec Wine). L’url donnée dans le post menait vers le site francophone dédié au logiciel et je jette donc un coup d’oeil, surtout que le site était en .free.fr. Mais je constate vite que le site présente des problèmes d’ergonomie. Puisque je pensais depuis quelques temps à continuer à faire de temps en temps des critiques de designs Web, j’ai donc décidé de faire une critique sur ce site, cette fois en essayant de procéder par barèmes.

Adresse du site : http://pixia.free.fr

Le code

En regardant un tant soit peu le code-source, on remarque très rapidement qu’on a affaire à un codage très archaîque.

Les frames, ça fait mal au coco !

Dans l’accueil, on remarque tout de suite que les frames sont utilisés pour n’avoir qu’un fichier à éditer pour le menu. Or, ce moyen est ergonomiquement très mauvais. Si quelqu’un vient avec un navigateur texte type Lynx, je n’aurais pas une vue d’ensemble des trois frames, ce qui fait qu’une fois que j’entre dans le frame du corps, je ne peux plus en ressortir puisqu’il n’y a aucun lien de retour, alors qu’Accessiweb recommande d’en mettre un. Les non-voyants naviguant avec un lecteur d’écran auront exactement le même problème, puisqu’eux non plus n’auront pas une vue d’ensemble. Et lorsqu’il n’y a pas de lien permettant de retourner à l’accueil, on parle alors de page orpheline. Il ne faut pas oublier non plus que les moteurs de recherche sont « aveugles » et donc, se retrouvent avec le même problème de « non-vue d’ensemble », ce qui a pour résultat qu’un site utilisant des frames sera généralement très mal indexé.

De plus, si un visiteur qui sait à peine naviguer sur internet veut bookmarker une des pages du site ou transmettre le lien direct de la page, il lui sera difficile de le faire avec des frames. Comment le saura-t-il qu’il faut faire clic-droit > Ce cadre > Afficher ce cadre uniquement, pour arriver à ses fins ? Je soulève ce point sur la non-intuitivité des sites construits en frames, puisque je suis déjà passée par là, quand j’étais encore noob en informatique.

Pour ces différentes raisons, ce type de structuration des pages est fortement déconseillé : c’est à réserver aux démos de styles !

Les pages orphelines des tutoriaux

Si on regarde dans les tutoriaux, on constate que si on consulte un tuto en particulier, on tombe directement sur une page orpheline même si on n’a pas demandé à ouvrir dans un nouvel onglet ! On se retrouve alors avec juste le corps contenant le tuto et on n’a donc ni menu, ni lien de retour à l’accueil ! Et puisque ces pages s’ouvrent dans une nouvelle fenêtre ou dans un nouvel onglet sans nous avoir laissé le choix, on ne peut pas utiliser Précédent !

Des tableaux mur à mur…

Si on regarde maintenant à l’intérieur des frames, on remarque vite que c’est bourré de tableaux de mise en page, et que le CSS est à peine utilisé pour les polices des textes et pour le style des liens. Le reste de la présentation est géré par les tableaux et par les balises et atttributs dépréciés.

Cette manière de coder, non seulement alourdit le chargement des pages en obligeant le navigateur de tout lire à chaque fois, mais rend aussi la maintenance plus difficile et donc, c’est la cohérence des fichiers de corps qui devient difficile à garder.

Les solutions

Pour les premiers problèmes, soit les frames et les pages orphelines, on passe au PHP, en remplaçant l’utilisation des frames par l’utilisation de la fonction include(), qui permet tout comme les frames de n’avoir qu’un fichier à éditer pour modifier le menu, sans les inconvénients qu’ont les frames au niveau de l’ergonomie. Puisque Free supporte PHP, ce virage peut donc être fait sans problème !

En combinant avec l’utilisation des includes de PHP, le passage à une structure sans tableaux et la séparation de la présentation du contenu permettrait à la fois d’accélérer le chargement des pages en permettant la mise en cache du styles, et de faciliter la maintenance du code.

Style, ergonomie et accessibilité,

On peut dire que le design est vivant avec l’orange et les chibis et autres dessins manga qui rappelle les origines nippones de Pixia, mais des améliorations auraient pu être apportés.

Je mettrais ma main au feu que le design a été conçu sur un écran cathodique, puisque sur mon écran LCD, j’ai des difficultés à lire les liens qui sont blancs sur fond orangé. Un orangé un poil plus foncé aurait pu rendre ces liens plus lisibles.

L’effet au survol des liens du menu rend la lecture encore plus difficile, avec cet effet d’ombrage qui cause des variations de couleurs derrière les lettres blanches. Quand il y a trop de variations derrière un texte, ça gêne la lecture. Essayez de lire le mot « Téléchargement » sur ces deux captures :

De plus, je remarque que c’est des images qui sont utilisées et qui sont gérées par Javascript. Même si les liens sont tout à fait fonctionnels même si Javascript est désactivé, le fait d’utiliser des images fait en sorte que si on navigue avec Lynx, on n’a que les noms des images au lieu du titre des liens à cause de l’absence de texte de remplacement, comme vous pouvez le voir dans cette capture :

On peut dire la même chose des autres images présentes sur le site : Aucun d’entre eux ne semble avoir de texte de remplacement !

Pour revenir au style, je remarque que dans la page Contact, la présence de pubs Google brise l’unité, car ces pubs dépassent largement la largeur du corps alors qu’ils ne devraient pas.

De plus, à l’accueil, je trouve plutôt étrange visuellement de voir des liens hors de la largeur de la page, alors qu’il y aurait eu un meilleur moyen de les intégrer. Une rubrique « Liens » par exemple, aurait fait l’affaire.

Et finalement, comme je l’avais déjà dit dans la critique précédente, les designs « icy », c’est à dire les designs fixes alignés à gauche, ne sont pas conseillés, car plus la résolution du visiteur sera grande, plus l’espace à droite sera énorme, et ce vide peut justement gêner le visiteur, comme c’était le cas de mon père qui avait déjà réduit sa résolution d’écran parce que le vide à droite sur l’ancienne version de GlobeTrotter.net le gênait. Il vaut donc mieux faire usage d’un style « liquid » (design fixe centré) ou d’un style extensible.

Conclusion

Ce site aurait énormément à gagner en ergonomie, en référencement naturel et en facilité de maintenance en adoptant PHP pour gérer le haut, le menu et le bas ainsi que certains modules hors-forum, et en adoptant de bonnes pratiques basées sur le Web accessible, soit d’éliminer les tableaux de mise en forme et séparer la présentation du contenu.

Pour cela, si un jour l’auteur du site tombe sur ce billet, je lui recommande chaudement ces sites où il pourra apprendre à coder selon les normes du W3C, et à utiliser PHP :

• Le site du zéro
• Alsacréations

L’utilisation d’un CMS (WordPress, Drupal, …) pour la partie site pourrait également être une bonne solution si le temps manque pour coder. Ces sites sont déjà pré-codés en PHP, et tout comme un système de forum, on n’a qu’à l’installer et après, on a accès à l’administration à partir duquel on peut créer ses pages, publier des articles et gérer les membres ! Pour le choix, il ne faut pas hésiter à demander des avis sur les sites que j’ai cités, et à tester en local avec Wampserver avant d’arrêter son choix final.

Le site a tout à gagner en repartant sur des bases saines et solides qui sauront traverser le temps.

En même temps, j’apporte quelques retouches à la mise en forme et j’ajoute quelques précisions.

Enjoy !
———————–
(Originalement posté le 21 août 2009)

D’habitude, les sites offrant un logiciel commercial (Adobe par exemple) ont une structure et une esthétique bien travaillées et sont faciles à naviguer, ce qui les rendent invitants pour le client potentiel. Mais il y a des exceptions…

Il y a quelques jours, en faisant ma ronde quotidienne sur QuébecOS, je tombe sur un post où l’un des membres est venu faire découvrir un shareware de captures vidéo pour Linux qu’il a découvert et dont il a été impressionné par la fluidité des vidéos créées pendant ses tests.
-> lien du post en question

Il a donc donné le lien vers le site, en mentionnant que le site est bordélique. Je suis allée voir et je comprends totalement le choix du terme.

Vous pouvez le voir par vous-mêmes : http://www.demorecorder.com/

Je vous livre donc ma critique, que j’avais d’abord postée sur Gimp-Attitude, mais que je reposte ici sur le blog :

Les points négatifs

En regardant le code-source, on remarque que l’ordre logique n’est pas du tout respectée. Une page respectant l’ordre logique doit avoir cette suite : header -> menus -> contenu principal -> footer.

Mais dans le cas du site cité, on a ceci : Colonne centrale contenant le logo central, le contenu principal et le footer. Ensuite, on a la colonne de gauche, avec la partie gauche du header (une simple image de la boîte juste "là" sans aucune intégration graphique) et le menu de gauche. Puis vient en dernier la colonne de droite, contenant les blocs de droite.

Donc, au final, le footer n’est même pas en bas de la page, et le menu est placé après le contenu principal ! Donc, on ajoute à ça l’absence de skiplinks pour avoir comme résultat que tous les sans-souris fuient car ils n’ont pas envie de s’abîmer les tunnels carpiens à user la touche « Tab » pour avoir le menu… j’ai déjà mal à mon épaule droite rien qu’à y penser, déjà que je viens tout juste de reprendre mes traitements de physiothérapie pour soigner mon épaule en vue de retourner sur le marché du travail… ouch !

TOUT est en Times New Roman ! Et comme on sait que ce type de police n’est pas très adapté pour les écrans, où sa lecture n’est pas très aisée… ça on réserve ça à l’imprimé !

La page d’accueil : Mettre les questions fréquentes dans la page d’accueil, ça allonge inutilement la page d’accueil qui doit être la première page sur laquelle le visiteur tombe. Or, une page d’accueil surchargée rendra le visiteur mal à l’aise. Ces questions et réponses, je les aurais vu dans la page FAQ.

Le design : J’ai beau faire dans le le style épuré, mais ce design, on dirait qu’il n’est pas fini, il est trop brouillon. Le logo de côté, où l’on montre la boîte, n’est pas du tout intégré au reste, son fond est d’une couleur complètement différente et donc, ça tranche sur le fond turquoise. Il y a aussi un manque d’homogénéité entre les pages. Pendant que le fond de la page d’accueil est turquoise, le fond des autres pages est blanc, ce qui fait sauter aux yeux la fausse transparence du logo central.

Et niveau CSS (Vive Web Developer Toolbar !), je vois un party de position:absolute;, ce qui explique donc le fait que sur ma résolution de 1280*1024, la page n’est pas centrée et donc, semble optimisée pour du 1024*768… et ça peut fatiguer certains internautes quand une page n’est pas centrée… je pense notamment à mon père, qui avait déjà baissé sa résolution à 800*600 car ça le fatiguait de voir les pages alignées à gauche avec un gros rien à droite, sur les sites à largeur fixe qu’il visitait fréquemment. Le positionnement absolu est à éviter autant que possible pour cette raison !

Les seuls points positifs

En analysant le poids, on remarque que malgré tout, la page d’accueil fait 145571 octets, ce qui est quand même loin du millon d’octets que j’avais déjà vu sur d’autres sites. Les éléments les plus lourds sont surtout l’animation Flash et les deux images d’en haut (qui ne sont pas des grosses images redimensionnées, heureusement).

Ensuite, j’ai vu peu de tableaux dans le code HTML, comparativement aux pages bourrées de tableaux mur à mur qu’on rencontre encore régulièrement.

Conclusion

La structure est à repenser, et le design est à retravailler, afin de mettre des chances de son côté, pour rendre le site plus attractif et ainsi attirer davantage de Linuxiens modérés, en améliorant son ergonomie et sa présentation visuelle pour que le site ait l’air plus « pro ». Qu’il n’hésite pas à faire appel à un webdesigner-intégrateur s’il le faut, pour réaliser le travail !

Ceci était ma première critique, mais peut-être pas la dernière, ça dépendra sur quoi je pourrais tomber.