Garder un code valide, un combat de tous les instants

En vérifiant les statistiques de fréquentation du blog ce matin (oui, je sais, nombril tout ça…), je me rends compte qu’un visiteur a passé une de mes pages au « validateur » HTML du W3C.

Je me dis, tiens, ça fait effectivement longtemps que je n’ai pas passé mon blog à la moulinette et je m’empresse de vérifier tout ça… erreur… des tonnes d’erreurs en fait.

Et la faute est mienne, totalement, j’ai baissé la garde, je n’ai pas vérifié le code des nombreux « trucs » orientés promo que j’ai inséré ces derniers temps. Je pourrais dire, c’est leur faute, ils n’ont qu’à me donner des codes valides, mais au final, qui fait le choix d’icnlure telle ou telle chose, de coller tel ou tel code, si ce n’est moi.

Certaines erreurs étaient évitables (des codes en HTML4 alors que le blog est en xhtml), d’autres plus difficiles à détecter (attention ce qui suit n’intéressera que des « puristes »):

L’AJblog utilise un jeu de caractères UTF-8. Pour des raisons que je ne développerai pas ici (allez plutôt voir du côté d’Openweb lire cet article : Introduction aux jeux de caractères), tous les fichiers constituant la partie visible et lisible du blog sont encodés sans BOM (Byte Order Mark). Je parle bien ici des fichiers (PHP ou HTML), encodés, « en dur ».

Sauf que souvent, on utilise dans son blog ou dans son CMS des ajouts, des plugins, qui eux ne sont pas forcément encodés de la même manière. Bilan, votre jolie page que vous avez peaufiné aux petits ognons devient invalide suite à un conflit d’encodage de fichiers.

Ce que je veux souligner, c’est qu’il est actuellement extrêmement difficile de garder un site avec un code valide si on ne se créé pas des mécanismes de contrôle à la hauteur de ses besoins. Et encore, il s’agit de mon site, sur lequel j’ai entièrement la main, imaginez un projet avec différents intervenants techniques et de nombreux rédacteurs.

L’enfer est dans les détails.

Pensez CSS et (X)HTML dés l’élaboration de votre maquette

Si il ne devait rester qu’une différence entre un Webdesigner et un graphiste, ce serait celle là : le Webdesigner pense Web, le Graphiste pense graphisme.

Dit comme ça, nous avons une belle lapalissade, mais croyez moi, c’est vrai.

Ce n’est d’ailleurs pas pour rien que la plupart des graphistes que je connais et qui « font du web » réalisent des sites presque exclusivement en Flash, le seul outil permettant avec un peu d’autoformation de rendre sur un écran la qualité de leur travail, et surtout limitant les contraintes liées au support.

Pour ma part, depuis quelques temps, j’essaie d’analyser ma pratique professionnelle pour optimiser mes méthodes de travail et augmenter ma productivité.

Je me suis rendu compte que j’inclus le rendu final CSS/(X)HTML quand je travaille sur une maquette graphique sous Photoshop ou Illustrator.

J’ai en tête les limitations, les différences de rendu des navigateurs, les techniques que je maitrise déjà donc aisément applicables et celles que je devrais tester pour voir si ma maquette est réaliste et « rentable ».

Précision, je sais bien que tout est réalisable, mais pas forcément dans une logique d’optimisation pour le medium internet.

Un simple décalage de quelques pixels d’un objet dans la maquette peut faire gagner du poids à la page finale, mais également du temps de production, certains effets sont couteux en développement et en test et si ce n’est pas le client qui paie la note, c’est moi.

Au final, en intégrant dés le départ ce processus de construction, je gagne un temps considérable lors de l’intégration html, j’ai déjà mon layout en tête, les blocs d’information sont clairement identifiés, je sais déjà comment je vais lier le tout, le code est presque fait à l’avance.

Et vous, vous fonctionnez comment ? Pensez-vous le faire ? Le faites-vous vraiment ?

PS : je suis en train de préparer un article de « bonnes pratiques » de production, cette partie sera surement reprise.

Référencement, comportement utilisateur, réalité des blogs… un peu de tout en clair.

Un peu trop pris par le travail cette semaine, j’ai manqué de temps pour faire vivre le blog.

Etant toujours aussi pris par le travail, et oui même le week end, je vous livre tout de même quelques lectures intéressantes.

Oui, je sais cette info est assez ancienne, mais il faut bien rappeller l’existence d’Opquast, le projet ayant pris un peu de retard du fait des trop nombreux projets de la société Temesis.

  • La moitié des blogs seraient du spam déguisé, c’est pas moi qui le dit, mais le journal en ligne Wired : Spam + Blogs = Trouble (merci Fred Cavazza pour l’info)
  • Ca ne va pas arranger la confiance que les utilisateurs placent dans les blogs pour trouver de l’information : Les blogs n’inspirent pas confiance. (merci Legizz)

Et, c’est tout.

Bonne lecture,
Aymeric Jacquet

Reprise de MonOpquast de A à Z

Pour ceux qui ne connaissent pas Opquast, c’est un outil d’aide à la validation qualité édité par la société Temesis.

Cet outil qualité se présente sous la forme d’une check list de bonnes pratiques. C’est une description un peu succinte, mais je ne saurais trop vous conseiller d’aller essayer par vous-même.

Toujours est-il que la version précédente du site AJcréa avait été intégralement reconstruite en partant de ces bonnes pratiques.

Comme je codais mes pages en dur à l’époque j’avais dont un contrôle total sur le contenu et le code généré.

Seulement, comme j’utilise maintenant un moteur Dotclear pour gérer mon site (oui je sais dotclear n’est pas fait pour ça à la base), je veux vérifier que mon site est toujours conforme aux recommandations.

La bonne surprise, c’est que contrairement à ce que peuvent dire certains grincheux, c’est qu’une fois qu’on a bien assimilé les pratiques de qualité de construction, valider de nouveau un site est assez rapide et même très intuitif, même si l’outil n’est pas automatique (pour bientôt, pour bientot, une version light existant déja).

Bref, que du bonheur.

Aymeric, d’ailleurs, j’y retourne.