La présentation

J’ai complètement changé d’axe d’approche entre l’appel à proposition de Paris Web et le jour venu. J’ai retourné le sujet dans tous les sens pour arriver à transmettre le message de la manière la plus adaptée qu’il soit au public. Parce qu’il est vraiment essentiel de comprendre votre auditoire.

De ce fait, j’ai préféré laisser tomber l’atelier magistral où j’aurais été le seul à partager. L’approche choisie fût celle de l’interaction design (IxD) ; notion découverte la veille pendant la conférence de Stéphanie Troeth. L’idée étant de construire ensemble le corps de l’atelier, de produire ensemble la réflexion et d’en arriver à des conclusions plus rapidement.

Le plus amusant fût qu’on arrivait aux mêmes conclusions, et que les slides suivant la phase de design répondaient aux questions nouvellement créées.

Pour l’expérience, et le résultat produit, j’en suis satisfait

Déroulement de l’atelier

L’atelier consistait à passer en revue 3 des étapes du développement frontend : l’intégration HTML, l’habillage CSS et les interactions JavaScript. Chaque étape se divisait en 4 composants de travail :

• Production / réalisation
• Organisation / équipe
• Documentation
• Tests

Pour chacun de ces composants, toute personne dans la salle pouvait suggérer une bonne pratique, une mauvaise pratique ou un outil. Cela s’est matérialisé avec un tableau blanc découpé en 4 zones, dans lesquelles on collait des post-it.

Pour la petite histoire, n’ayant pas pensé à acheter les post-il avant d’arriver à Paris, je me suis rabattu sur le premier choix venu, en me basant sur la connaissance du terrain de David Larlet : Loisirs & Créations du Bercy Village.

C’est ainsi que je me retrouvais avec 200 post-it en forme de cœur,  de maison ou de fleur.

Un peu de gaieté pour un atelier sérieux et créatif.
D’ailleurs, parce qu’on n’a pas bossé pour rien, et que Paris Web c’est aussi la création en plus de share the love, voici la carte mentale de notre heure de travail :

Constats

Mon premier constat, en regardant la carte mentale, c’est qu’on a quand même réussi à produire un bon nombre d’éléments en 1 heure, avec un public qui n’était pas préparé et dans une configuration de salle de classe, remplie de surcroît.
La logistique s’est organisée d’elle-même, avec des contributions diverses pour ramasser les post-it, leur circulation et même la modération.

Quant au contenu en lui-même, plusieurs remarques s’imposent :

• la très grande majorité des contributions concernaient la production (c’était flagrant, face au tableau)
• par extension, il y a peu d’éléments de documentation et de tests et dans une moindre mesure, peu de travail en équipe/organisationnel (à part les classiques versionning)
• en production de CSS et de JavaScript, le nombre de mauvaises pratique équivaut ou dépasse les bonnes pratiques

En une phrase et une seule : le développement frontend, en tous cas représentatif de la population présente dans la salle, travaille dans son coin, avec ses méthodes, peu adaptables à d’autres cadres.

Et la suite ?

Mon avis c’est que si la production n’est pas forcément industrialisable au sens où on ne peut que difficilement automatiser la production du code, en revanche on peut automatiser les tests et la documentation, voire certains aspects d’organisation (diffusion automatique des commits, rapports etc.).

Une de mes hypothèses est que si le caractère individuel du travail est si marqué, c’est que nombre des méthodes, astuces et outils de travail sont basés sur des avis subjectifs. Pas étonnant que les réactions sur le mot industrialisation soient si virulentes et chargées d’émotions.

C’est une des raisons pour laquelle j’ai proposé en conclusion d’aller au-delà de nos jugements personnels pour formaliser des bonnes et mauvaises pratiques, que l’on applique ensuite à son projet si l’on est concerné. Un mélange des guidelines BBC et des bonnes pratiques Opquast en somme.

Ce que j’aimerais, c’est produire 2 livrables :

• une checklist de bonnes pratiques de développement frontend
• un livre blanc du développement frontend, comprenant en plus le processus de dialogue entre acteurs, pendant les phases projet

Ces livrables seront Open Source, libres, gratuits et créés collectivement, parce qu’on a tous des terrains d’expertise différents et complémentaires.

Share the love

Je ne manquerai pas de vous tenir informé des avancées de ces projets, qui me tiennent à coeur.
Je ne saurais que trop remercier les participants, présents lors de l’atelier Paris Web, ceux qui apporteront leur pierre à l ‘édifice (même si ça ne concerne qu’un changement de virgule dans une phrase) et ceux qui apporteront leur soutien, Elie Sloïm en tête. Il propose en effet de mettre à disposition la plate-forme Opquast en tant qu’outil de contribution.

Une idée qu’elle est bonne.

Cette année, j’ai décidé de participer à toutes les conférences qui ne sont pas au cœur de mon activité quotidienne, au sens production. En gros, j’ai voulu laisser tomber tous les buzzwords et me concentrer sur des compétences et connaissances périphériques à activité. Satisfaire ma curiosité.

Je suis donc arrivé à Paris Web sans avoir regardé le programme, en décidant entre chaque pause le titre de la conférence que j’allais inscrire sur mon carnet de notes.

L’ouverture par l’architecture

Ce n’est pas tout à fait vrai : je savais quelle était la première conférence à laquelle j’allais assister. Graine semée il y a 2 ans, dans le retour en métro de Paris Web 2008. J’apprenais que Fabien Basmaison partait 1 année entière en Chine (ou ailleurs en Asie ?).
Absent de Paris Web 2009, il propose « Espace construit et espace virtuel, un retour vers le futur ?«  en guise d’introduction.

Ou comment ne pas parler de Web mais d’architecture, de construction et d’alliage fonctionnel/esthétique.

Il citait d’ailleurs une phrase que j’apprécie beaucoup : l’architecture, c’est savoir changer d’échelle, de point de vue. Je me plais à appliquer ce moto au quotidien mais au fond, n’est-ce pas là une chose essentielle pour toute personne travaillant dans le Web ? Savoir sortir le nez du cambouis, observer ce qui l’entoure, s’en inspirer et replonger/changer d’angle d’attaque.

L’architecture, c’est également réduire les obstacles pour obtenir davantage de fluidité, et augmenter le rendement. C’est la raison d’être des méthodes agiles, comme scrum. Parce que notre défi, c’est réussir un projet sur une base qui est tout sauf industrialisée (voire industrialisable).

L’architecture, c’est travailler sur un patrimoine, ensemble, en utilisant l’existant (cf. Let’s Interface!). On ne peut créer un ouvrage sans tenir compte de l’existant, de l’environnement ou même de l’intérêt même du-dit ouvrage. On ne peut décemment pas concevoir un site Web optimisé pour Internet Explorer 6 et une résolution de 1024×748, ce serait juste omettre/nier l’existence du Web tout entier.

Paris Web est un moment où l’on s’ouvre l’esprit : cette conférence était programmée au bon moment, avec le bon intervenant mais surtout avec le bon contenu. Quelque chose qui n’était pas axée sur le Web. Celui qui replace le Web dans son contexte, celui de l’inspiration.

Conseil livre : de Le Corbusier.

Let’s Interface!

Christian Heilmann me fascine littéralement. Il a le don d’arriver à insuffler ce qu’il recherche : du fun et de l’intelligence.
Si je devais résumer cette conférence en une phrase, ça serait la sienne : le Web est un outil, utilisons-le. On ne construit pas pour le Web, on construit avec le Web.

C’est la transcription parfaite de l’architecture vers le Web. Tenir compte de l’existant, des outils, pour construire les siens et arrêter de réinventer la roue.

Les interfaces devraient être des outils faciles à utiliser, et à comprendre. De l’accessibilité au sens large en somme.
De quoi insister auprès des clients de ne pas perdre de vue l’objectif principal ? L’utilisateur ?

L’accessibilité dans une chaîne de production Web

Quel meilleur moyen de ne pas perdre ses objectifs de vue en effectuant un contrôle qualité, matérialisé par une vérification de l’accessibilité à toutes les étapes du processus, plutôt qu’en livraison finale. C’est le point de vue de Denis Boudreau et de Vincent François.

Pourquoi la fin de chaîne pose problème ? Tout simplement parce qu’il est (souvent) déjà trop tard, que le coût des modifications en est multiplié mais surtout, c’est beaucoup plus simple d’intégrer ça dès le départ.
Si on en revient à l’architecture, c’est comme si on mettait des fenêtres à 2 mètres de hauteur et qu’on se rendait compte à la livraison de la maison que ce n’est pas accessible car trop en hauteur pour les habitants. Vous vous voyez casser le mur et descendre la fenêtre ?

Leur présentation de l’accessibilité dans une chaine de production Web, navigable au clavier et à la souris, est équivoque et découpe ces différentes phases au sein du projet :

• Analyse
• Architecture
• Ergonomie
• Graphisme
• Prototypage
• Rédaction
• Développement
• Contrôle qualité

Le liant entre ces phases étant la gestion de projet, menée de concert entre la maîtrise d’oeuvre et la maîtrise d’ouvrage. Une personne a même très justement souligné qu’il faudrait ajouter une nouvelle dernière étape, la livraison/maintenance. Pour s’assurer notamment qu’à l’usage, lors de la contribution ou des évolutions de l’application, l’accessibilité soit maintenue à niveau.

Innover de 9 à 5

Je m’intéresse à l’innovation, pas seulement à la théorie mais également à sa mise en pratique, depuis que je vois passer sous mon nez des projets intéressants mais qui oublient toujours une chose. Les usagers (tiens, on y revient). Un site est réalisé par une entreprise, pour accomplir un but (besoin marketing, nouveau produit ou autre) mais … la praticité et l’intérêt de l’usager, bien souvent, y sont absent ou trop peu représenté.

J’y reviendrai dans d’autres articles, par le biais de mes lectures et de mes projets.

Toujours est-il, j’ai découvert une autre personne de Phéromone, Olivier Théreaux. Il a présenté de manière méthodique les différents types d’innovations possibles (business, design, incrémentales, radicales). Leur mélange provoque de l’efficacité, une amélioration des processus, de nouveaux produits, une découverte de nouveaux besoins et j’en passe.

Le travail de l’innovation, ce n’est pas seulement l’acquisition de l’idée : c’est l‘art de la faire fructifier, de la mettre concrètement en oeuvre.
En ce sens, il cite Scott Berkun : les gens ne veulent pas innover, ils veulent avoir innové. N’avez-vous jamais entendu de client qui vous demandait une application iPhone sans savoir ce qu’ils voulaient y mettre ? La réponse est dans la citation.

Innover, c’est apprendre à échouer. C’est admettre que des fautes seront commises et que la réussite se mesure également en terme de ressources : elles doivent être à la mesure des ambitions. L’amplitude entre les 2 augmente les risques d’échec.

Olivier soulignait aussi un détail essentiel, qu’on oublie un peu et qui pourtant caractérise tellement notre métier, notre univers : c’est la culture hacker. Hacker au sens bidouilleur. Celui qui parvient à ses fins en se servant d’outils à disposition. LE Web est à notre disposition.

Encore une fois, les personnes les plus fascinantes ne sont pas celles qui apportent de nouvelles choses ou qui sont les « meilleures ». Mais celles qui apportent un regard différent, de par leur(s) culture(s), leur expérience et leur vécu.

Conseil lecture :  de Scott Berkun.

Journey over Destination: creating an effective framework with UX tools

J’ai malheureusement été moins attentif sur la conférence de Stéphanie Troeth (projet client à régler, à croire que chaque année j’y coupe pas ;-(). Néanmoins, à la lecture de ses slides pendant sa présentation, une chose m’avait frappé : tout est clair, limpide et extrêmement synthétique. Sans le son, il y avait de quoi apprendre. C’est d’ailleurs comme ça que je me suis aperçu que la méthode employée lors de mon atelier technique (dont vous pouvez lire l’annonce ; le détail et résumé arrivent) était en fait de l’interactive design.

L’expérience utilisateur repose avant tout sur la conception, du site, de l’outil ou de je ne sais quoi (le concept s’applique à tout, pas seulement au Web). Encore une fois, l’agilité du processus, la fragmentation des tâches et les contraintes (limites de temps, de fonctionnalités etc.) sont un élément essentiel à la qualité du résultat final.

L’exemple le plus parlant est celui du curseur : tirer d’un côté enlève du poids à l’extrême opposé. De même que parmi la trinité temps, argent, fonctionnalité, on ne peut en conserver que 2. Lesquels choisiriez-vous au moment d’acter un choix ? Que diraient vos clients ?

Notre conversation en off m’a confirmé mon intuition : sa présentation représente des mois de réfléxion, au fil de l’eau. Tiens, ce n’est pas justement le concept de l’innovation ?

La typographie comme outil de design

Encore un petit nouveau à Paris Web : David Rault. Encore un globetrotter, à croire que ça va devenir un élément déterminant sur le CV

La typographie, de mémoire, est un sujet qui a été peu abordé à Paris Web, en tous cas pas lors de conférences. Je m’y connaissais assez peu et le moins que je puisse en dire, c’est que je suis resté le regard rivé sur la scène, à noter avec délectation cet enseignement, fort souvent un choix par défaut. On va utiliser quelle typo ? Oh bof, de l’Arial ou du Verdana.

Quelques explications sur la classification typographique, et hop, tout devient plus clair quant aux termes serif, sans-serif, linéales, humanes, garaldes, romaines etc. Je ne paraphraserai pas cette classification.

En revanche, retour à l’architecture, c’est tout le bagage culturel que les polices de caractères véhiculent. Sans oublier leur base historique et sociale. Je n’imaginais pas utiliser sur un ordinateur une police datant du XVI^ème siècle, considérée comme parfaite.

En considérant que le Web, c’est 95% de typographie (ce que l’on lit), ce n’est clairement pas le choix banal que l’on a l’habitude de faire, ou de subir. Je rajoute cette notion aux indispensables à réunir pour réussir un projet, par le biais de la communication écrite.

Conseil lecture : de David Rault.

La macrotypographie de la page Web

On reste dans l’univers de la communication visuelle avec Anne-Sophie Fradier. L’occasion d’ailleurs de me rendre compte que j’avais déjà lu son blog auparavant, et que je le découvre juste maintenant, à l’occasion de la rédaction de cet article Le Web est petit et on se connait plus facilement en avatar en fin de compte.

Macrotypographie vous dites ? Il s’agit de concevoir la typographie au niveau du paragraphe, de la page, par le biais de grilles, de colonnes, leur ratio etc. C’est forcément une personne bien puisque les grilles, elle adore et en mange au petit-déjeuner mais surtout, a eu une réponse extra à ma question (oui j’ai posé beaucoup de questions, je sais ) : les grilles apportent-elles une contrainte qui brident la créativité ?
Réponse : non, bien au contraire, il faut des contraintes pour développer la créativité. Elles agissent comme un guide.

Le rapport permanent du livre au Web était très intéressant. On a tendance à opposer print au Web, moi le premier … et finalement, elle considère que la page Web se rapproche du volumen (les rouleaux de papier, utilisé pour la Torah notamment).
Plus amusant encore, tout ce qui concerne la typographie a déjà été inventé … par les moines. Enluminures, marges, blocs de lecture etc.

Un regard rafraîchissant de plus sur la manière de concevoir et d’architecturer nos contenus, nos sites et nos applications.

Conseil lecture : de Josef Muller-Brockmann.

La crois au rouge français

Conclusion

Alors, pourquoi avoir titré mon article l’âge de la raison ? Parce qu’en plus de partager notre amour du Web, les intervenants de Paris Web, les organisateurs, mais aussi les participants, ont réussi à démontrer qu’on n’était plus que dans la diffusion d’informations à coup de slides.
Non, on était dans la création.

L’âge de la raison parce que finalement, le fond de cette édition était basé sur les réflexions. Qui sommes-nous ? Comment valoriser nos compétences ? Comment dialoguer avec le client ? Comment dire que la qualité ce n’est pas une option (pas la nôtre) ? Comment faire un site Web standard et un site Web mobile en un seul développement ?

L’âge de la raison car les processus de création et les enjeux métier étaient au centre des réflexion. Et qu’on n’a d’ailleurs toujours pas une réponse claire. L’argumentation va s’étoffer avec le temps, je n’en doute pas.

Je remercie chaleureusement les organisateurs d’avoir si bien réussi la programmation. Cette matinée typographie est un vent de fraîcheur qu’il faut continuer à pousser, pour aborder le webdesign d’un angle peu pratiqué jusqu’à présent.
L’expérience de la vélotypie et de la traduction simultanée (et les 2 en même temps) était excellente. Je découvrais l’effervescence d’un organisateur des RMLL se demandant comment mettre en place un tel système.

Je terminerai malgré tout par quelques critiques, car on peut toujours progresser :

• HTML5 c’est sympa, il faut aller vers du concret, au-delà des balises section, header etc. La démo de Paul Rouget cassait la baraque car elle apportait ce qu’il manquait jusque là : la concrétisation au-delà du slide ;
• le mobile a quasiment disparu de la programmation alors que l’an dernier, on sentait que c’était le sujet de toutes les interrogations
• les conférences sur le contenu, leur rédaction me font trop souvent penser à des cours de référencement naturel de bas étage (je suis dur, j’assume)

Encore une fois, rendez-vous de pris pour l’année prochaine, à savoir en 2011 … à moins qu’un Sud Web se glisse entre temps dans le calendrier ?

Remarque : j’oublie plein de choses, plein de personnes (Ryan, toute la famille avec Frank, N1k0 etc.) … dur dur de tout caser en 1 billet ;-(

Je reviens aux sources et à mon grand dada avec l’intégration HTML au sens large du terme. J’ai choisi d’intituler cet atelier : industrialiser l’artisanat de l’intégration HTML. Rendez-vous le samedi 16 octobre 2010 à 10h50 dans les locaux de Télécom Paris pour en discuter … et maintenant, pour le préparer et en dessiner les contours.

Origine de l’atelier

Juste après l’édition 2009 de Paris-Web, je me demandais sur quoi je pourrais parler en conférence ou en atelier. Cette manifestation a le mérite d’attirer des orateurs de qualité … et ce n’est pas évident de monter sur scène en se disant : que pourrais-je apporter au public, qui ne soit pas de la redite et suscite autant d’intérêt qu’une Stéphanie Troeth, Karl Dubost ou Christian Heilmann.

Et là j’ai lu la lettre au papa Paris-Web d’Elie Sloïm. J’ai de suite pensé à un sujet lié à l’intégration HTML. Cette spécialité connaît une effervescence d’outils depuis 2008 (frameworks CSS, pré-processeurs CSS et performances Web) … pourtant les méthodes de travail restent toujours très liées au développeur, à son tempérament et à ses connaissances d’outils capables d’améliorer la productivité. Quelque chose de tout sauf normalisé, industrialisé.

Comme il s’agit également d’une pratique ayant du mal à accepter les changements – je me souviens encore des réticences liées aux frameworks, alors que dans tout langage de programmation ces outils sont perçus comme du pain béni – je me suis dis qu’il y avait quelque chose à faire.

Les axes initiaux de l’atelier

En préparant l’appel à propositions de Paris-Web, j’avais convenu que cet atelier devrait tenter de répondre aux objectifs suivants :

• dresser un état de l’art de l’intégration HTML
• offrir une large tribune à l’audience, notamment en partageant ses propres retours d’expérience
• déterminer ce dont on dispose et ce dont on manque en terme d’outillage

Par extension, je souhaitais répondre (au moins) à ces questions :

• comment bâtir des CSS indépendantes et réutilisables ?
• quand et comment utiliser un préprocesseur CSS ?
• comment dialoguer avec le graphiste ?
• comment dialoguer avec le développeur ?
• comment détecter les régressions et assurer une qualité de code en CSS ?

J’ai également repris l’historique des précédents Paris-Web pour voir que de précédents ateliers s’étaient déjà penchés sur la question de la chaine d’intégration. D’où mon souhait de ne pas forcément réinventer la roue.

Pour autant, les objectifs tout comme les questions ne sont pas figées dans le marbre. Cet article est également là pour capter vos avis et vos remarques, pour ajuster cela avant le jour de l’atelier.

Discuter, échanger, et créer

Enfin, mon évolution personnelle au long de cette année 2010 et certaines paroles de David Larlet résonnaient dans ma tête.
Un sujet de cette importance ne peut pas être magistral. Pourquoi ? Parce que tous les intégrateurs rencontrent une variété de conditions de travail différentes, et qu’il serait d’autant plus difficile d’obtenir un consensus en prodiguant cet atelier de manière magistrale.

D’où l’idée d’introduire l’atelier par un bref résumé de mes retours d’expérience sur les frameworks (existants, ou créés pour le besoin), les pré-processeurs CSS, leur combinaison ainsi que l’application de la philosophie Object Oriented CSS. Quelque chose comme 10/15 minutes maximum.

Le reste du temps serait réparti de manière équitable sur chacune des questions, et animé sous forme de discussion. Chaque participant répondrait (via des post-it, je les fournirai ) par 1 ou plusieurs réponses, positives et négatives. En gros, ce qu’il faut faire, et ce qu’il ne faut pas faire.

Cette collecte en live des post-it, affichés au tableau, permettrait de dresser une cartographie des bonnes et mauvaises pratiques, des actions à mener et dont il faut se méfier.

A défaut de parler d’une industrialisation vidant l’intégration HTML de son côté artisanal, on aurait une excellente occasion pour tous se poser ensemble les bonnes questions, et repartir avec des réponses et des idées pleins la tête.

Conclusion

Bref, si le sujet de l’intégration HTML vous préoccupe, est au centre de vos intérêts et que vous souhaitez en améliorer sa pratique professionnelle (pour une meilleure reconnaissance de celle-ci ?), je vous invite à la fois à venir à l’atelier technique du samedi (il reste quelques places ; ça ne coûte que 22€) et à réagir en commentaires. Je ferai mon possible pour adapter l’animation de l’atelier à vos problématiques et questionnements.

Cet atelier serait ainsi à l’image de Paris-Web : une grande discussion conviviale, constructive et enrichissante.
L’idée sera ensuite de concrétiser ces échanges soit par un ensemble de billets de blogs soit, si la matière le permet, en livre blanc.

Ne me demandez pas ce que je prévois pour 2011, je n’en ai aucune idée … pour l’instant

Je vous parlais en janvier de l’appel à conférence. Celui-ci a battu les records : 35 conférences, 1 table ronde et plus d’une demi-journée de conférences en anglais pour la session Internet, que je co-organise avec Nicolas Perriault.

La session Internet

Toutes les conférences liées à la thématique de l’Internet et du libre se déroulent sur 3 jours, du mercredi 7 juillet (demain) jusqu’au vendredi 8 juillet. Ça se passe dans l’amphitéâtre A (150 places) de l’ENSEIRB-MATMECA, à 2 pas de l’arrêt de tramway B « Arts et Métiers ». Tout se trouve sur le plan détaillé de l’évènement, en particulier dans la rubrique déplacement en tramway.

La philosophie consiste à réduire les durées de conférence sur des durées de 20 minutes, pour offrir un message clair, sans longueur ainsi qu’une variété d’intervenants et de sujets.
Coïncidence de la vie et organisation aidant, on a réussi à caser ça en demi-journées thématiques.
Cela offre d’une part une vision claire du programme mais aussi, si vous avez une attente bien précise, une (ou plusieurs) demi-journées suffisent pour y répondre.

On aurait aimé en faire plus … difficile en 3 jours, déjà intenses.

Frameworks et tests

• Date : mercredi matin
• 6 conférences

Où l’on parlera de frameworks de développement avec Django et Symfony2, de tests avec Selenium et une avant-première Temesis.
SPIP sera de la partie pour inaugurer ce bal technique, servant autant à du site Web que de l’applicatif ou de la création d’API.

HTML, CSS et accessibilité

• Date : mercredi après-midi
• 8 conférences

On habille le Web avec des présentations d’HTML5, CSS3 mais également des outils d’amélioration de qualité (comme KBAccess, ou Tanaguru).
La journée se terminera sur 2 conférences clé : l’intégration accessible de vidéos et l’accessibilité pour les non-lecteurs. Oui, les non-lecteurs

CMS et gestion de contenu

• Date : jeudi matin
• 6 conférences

eZ Publish sera à l’honneur, aux côtés d’Automne, Typo3 et Joomla. Piwigo illustrera la gestion de contenu de photos et d’images.
L’orientation est données aux cas pratiques : intégration de recherche à facette, optimisation de performances.

Internet I/O

• Date : jeudi après-midi
• 6 conférences

À la fin de la demi-journée, vous saurez ce qu’il faut pour devenir votre propre hébergeur, de l’infrastructure matérielle jusqu’à l’accès Internet maitrisé.
Une autre partie des conférences est dédiée à des outils d’extraction et d’accès à Internet, autrement qu’avec un navigateur Web.

Matinée anglophone

• Date : vendredi matin
• 3 conférences

C’est un peu plus fourre-tout : CMS Java avec Apache Lenya (présenté par des membres de la fondation Apache), tests de montée en charge et outil de traduction collaborative par Automattic.

Collaboratif, traduction et Open Data

• Date : vendredi après-midi
• 6 conférences
• 1 table ronde

Le clou du spectacle : traduction automatisée, réseau social décentralisé, collaborer à OpenStreetMap, gérer une communauté Open Source, Open Data et moteur de recherche décentralisé.

On terminera sur une table ronde dédiée à Open Data, afin de décrypter ensemble tous les intérêts à libérer ses données, créer de la richesse et apporter l’innovation jusqu’à la société civile ; un levier de croissance trop facilement oublié.

On se voit sur place !

Je serai sur place pendant toute la durée de la session Internet donc n’hésitez pas à nous interpeler, Nicolas ou moi.
Le programme continue également en soirée, en aparté :

• mardi soir à la Parcelle
• mercredi soir chez Élie − c’est celui qui est plus beau en vrai que sur le Net, et c’est pas un self-service
• jeudi soir au repas du libre
• vendredi soir chez Alriq

Vous pourrez y croiser entre autre (et dans le désordre) Nicolas Perriault, Sébastien Delorme, David Larlet, Mickaël Hoareau, Romy Tetue, Élie Sloïm, Frank Taillandier, Dennis Benkert et moi-même.

Je remercierai quand même mon employeur, Clever Age, qui prend intégralement en charge mes jours de participation à cet évènement. Participer à l’écosystème du libre sans se soucier de l’aspect financier est un confort très appréciable.

Pour un Internet libre !

Ce titre fortement accrocheur à la limite de l’injure annonce la couleur : l’ouvrage est censé vous expliquer que les techniques employées aujourd’hui ne sont que du bricolage et qu’on peut faire la même chose en plus propre et plus simple.

En route pour cette saine lecture … ou pas.

Chapitrage

Everything You Know About CSS Is Wrong! est découpé en 5 chapitres. Cela représente un volume d’une petite centaine de pages. En voici la structure :

1. The Problem with CSS
2. CSS Table Layout
3. CSS Table Solutions
4. Considering Older Browsers
5. The Road Ahead

Si vous commencez à flairer le mauvais plan, vous n’avez pas tout à fait tort.

display: table-cell au lieu de float/clear/margin

Tel serait le credo de l’ouvrage. C’est en teneur ce qui y est distillé, ni plus ni moins.

Quand on y repense, aujourd’hui on utilise vraiment des techniques à la noix pour positionner les flux, pour imiter des colonnes de taille égale. Tout ça pourquoi ? Parce que le navigateur dominant du marché s’appelle Internet Explorer 6/7 et ne permet pas d’utiliser l’attribut CSS display: table-cell.
Son utilité ? Donner à l’élément concerné le comportement d’un tableau : des cellules de hauteur égale et des colonnes notamment.

Les 2 premiers chapitres sont à ce titre très démonstratifs puisque simplement, on apprend à construire un habillage classique à 2 colonnes avec cette technique. Mais, à mon avis, le chapitre 3 est entièrement à jeter.

Le livre commence en nous expliquant qu’on utilise des techniques de barbare pour le rendu. Sauf que celles proposées pour palier aux lacunes de cette mise en page en tableaux ne valent pas beaucoup mieux : pas de solution générique possible, simulation de colspan et rowspan laborieuse … si j’ai été convaincu par la présentation en grille, je l’ai en revanche moins été par ces solutions proposées.

Le chapitre 4 explique avec plein de sous-entendus qu’Internet Explorer 6 et 7 … ben il faut arrêter. En tous cas pour utiliser le display: table-cell. Je pense que même sans cette technique on avait déjà envie de les balancer mais bon. Ça sera un argument de plus pour prôner cette solution.

Le chapitre 5, The Road Ahead, propose une présentation maintes fois vue et revue de l’avenir avec CSS3. Ça fait office de piqûre de rappel concernant le module templates et  grille notamment.

Texte 2 colonnes avec display: table-cell

Pourquoi je ne vous recommande pas son achat ?

Parce qu’au final on se trouve face à gros article doublé d’un titre bon pour écouler des exemplaires. Il aurait pu s’appeler « comment présenter en grille sans tableaux et sans flottants » par exemple.

Sans vouloir relancer le fumeux débat du  Web contre les livres, je pense qu’il y a des articles sur display: table-cell plus courts, moins chers et tout à fait valables (y compris leur article de présentation), notamment sur Alsacréations.
Pour moitié prix, le contenu aurait pu passer. À 30$, j’en attends davantage …

Je recommande avec beaucoup plus de ferveur l’indémodable Transcender CSS d’Andy Clarke.

Un dernier point toutefois : je ne suis pas convaincu qu’un rendu à l’identique au pixel près soit une solution d’avenir. Il ne faut pas espérer avoir un rendu identique à la maquette ni identique sur tous les naivgateurs (notamment au niveau de la colorimétrie). Je crois davantage à un support de fonctionnalités et des solutions alternatives pour les navigateurs ne supportant pas ces dites-fonctionnalités. De même qu’on n’a pas le même rendu de couleurs pour les téléviseurs (y compris HD), il est utopique de vouloir la même chose d’un site.

Depuis quelques mois je ne recommande plus à mes clients de supporter IE6 et ce, malgré ses 20% de parts de marché. Je préfère largement proposer une solution dégradée, toujours fonctionnelle mais moins jolie.
Cette année je refonds le thème de ce blog et je ne compte pas supporter ni IE6 ni IE7. Votre adoption d’autres navigateurs aide mais il faut montrer l’exemple.

Tout développeur, que ce soit à l’école ou en apprenant sur le tas, écrit du code. J’espère n’avoir perdu personne à ce stade de l’explication

Inconsciemment on cherchera à utiliser un style d’écriture avec lequel on se sent à l’aise, qu’on pourra et saura relire facilement et dans le meilleur des cas, qui pourra être relu par une autre personne sans avoir à engager d’interprète.

Tout développeur tend donc à utiliser des conventions de programmation (coding standards), que ce soit en HTML, PHP, CSS, JavaScript ou même en Cobol. Et utiliser des conventions, c’est bien !

Quelle convention de nommage adopter ?

Avant de choisir une convention, encore faudrait-il savoir quelles conventions existent :

• pas de convention
• convention hongroise
• convention PEAR
• convention symfony
• convention Zend Framework
• convention WordPress (que j’abhorre)
• etc.

Autant dire qu’il y a de tout et pour tous les goûts.
Ce qu’il faut retenir d’une convention c’est qu’elle explicite des règles de développement :

• sur le nommage des éléments
• sur l’indentation des éléments
• sur les structures de contrôle (if, else, tout ça quoi)
• sur la syntaxe des commentaires
• sur la syntaxe de la documentation (le code auto-documenté c’est bon !)
• sur l’organisation des fichiers, éventuellement

C’est pour ça que partir sur une convention parfaite sur le papier mais inapplicable est une vaste fumisterie. L’idéal étant de pouvoir reprendre du code dans un projet sans avoir eu besoin de lire la documentation pour en comprendre l’organisation.

Mon conseil : essayez, choisissez mais ne prenez pas non plus trop laxiste en terme de notation.
Une chose est sure : quand on a essayé une belle

Mes conventions de nommage en PHP

J’avoue, la notation utilisée dans symfony m’a tellement plu que je la réutilise quasiment partout. Ci-dessus, une illustration montrant du code pour un plugin WordPress (en PHP 4 malheureusement …). Elle en présente un bon aperçu.

Notation

J’utilise UpperCamelCase pour le nommage des classes sauf s’il y a un préfixe qui, lui, reste en minuscule.
Exemples : class AmazonWidgetsShortcodes, class sfUploader.

Pour ce qui est méthodes de classes, j’utilise lowerCamelCase. Comme ça on sait qu’on reste dans un objet et c’est pas plus mal.

Enfin, pour les fonctions orphelines, helpers & cie, c’est tout en minuscule séparé par des underscore (un nom particulier à ça ? lowered_and_underscored ? )
Exemple : add_filter()

Indentation

Dans l’indentation il y a 2 camps : celui des espaces et celui des tabulations.

J’ai suivi celui des espaces pour une simple et bonne raison : 1 tabulation a une taille différente selon les éditeurs, que ça soit votre IDE, votre shell ou n’importe quel logiciel de texte. L’idéal est d’avoir un rendu identique dans tous les éditeurs sans paramétrage.

En revanche, là encore je suis mais j’aime, je suis sur une tabulation à 2 espaces : c’est bête mais je trouve ça plus esthétique et on arrive moins rapidement à la limite de 80 caractères.

Cette « limite » n’est que virtuelle mais ouvrez un terminal, 80 lignes par défaut. C’est plus confortable de rester en-dessous de ce nombre. Ceci dit je fais quelques exceptions, des fois

Structures de contrôle

On pourrait résumer à 1 ligne = 1 action et 2 types d’utilisation.

Tout d’abord les structures dans le code à proprement parler :

• un espace entre l’opérateur et la parenthèse ouvrante
• un retour à la ligne à chaque accolade
• pas d’espaces dans les lignes vides (résidus d’indentation)
• systématiquement les accolades, même en cas de ligne unique après l’opérateur
• opérateur ternaire quand ça reste simple, pas trop long et plus lisible

Côté templating en revanche j’utilise la syntaxe alternative de PHP à raison d’un opérateur par ligne :

<ol class="posts">
<?php foreach($posts as $post): ?>
  <li id="post-<?php echo $post->getId() ?>">
    <a href="<?php $post->getPermalink() ?>">
      <?php echo $post->getTitle() ?>
    </a>
  </li>
<?php endforeach ?>
</ol>

Syntaxe de la documentation

Enfin, pour terminer sur la partie PHP, PHPDoc est surpuissante en plus d’être simple à utiliser. Comble du bonheur, sa syntaxe est réutilisable dans d’autres langages.

PHPDoc est le principe du code autodocumenté :

1. vous commentez votre code avec la syntaxe PHPDoc
2. vous générez sa documentation avec le programme PHPDoc (en HTML, PDF etc.)

L’idéal est de documenter en même temps qu’on produit le code. Par principe on revient rarement sur son propre code juste pour le loisir de le décrire, par manque de temps ou par flemme.

Mes conventions de nommage en JavaScript

Ne vous inquiétez pas, je ne vais pas tout recommencer pour JavaScript Je suis à peu près la même logique qu’en PHP à part pour les accolades.

En effet si je conserve un comportement similaire pour les structures de contrôles (1 accolade par ligne) :

• je ne fais pas de retour à la ligne sur les accolades/parenthèse ouvrante d’une fonction/objet anonyme
• je ne fais pas de retour à la ligne après une accolade/parenthèse fermante s’il y a une virgule ou parenthèse après

var OncleTom = {
  age:      25,
  pensee:   function(){
    return this.age * Math.random()
  }
};

Mes conventions de nommage en CSS

Inutile de paraphraser ce que j’ai déjà écris dans mon article sur les bonnes pratiques de codage CSS.

Deux lectures en une oui

Conclusion

Bon au final on voit que ce n’est pas si compliqué que ça d’apporter un brin de rigueur.
On pourra même s’amuser à compléter le tout par la disposition des méthodes et fonctions d ans un fichier par ordre alphabétique (j’en connais un que ça fera sourire ).

Les vues Outline fournissent un plan du code et certains logiciels ne semblent pas disposer d’une fonction de tri. Et au cas où un jour vous n’auriez pas votre IDE favori sous le nez, ça ne mange pas de pain de fonctionner ainsi.

Que l’on travaille seul à plusieurs, et à plus fortes raison dans ce dernier cas, l’utilisation de notations et conventions est un gage de qualité. Ça rend le travail plus facilement interopérable avec d’autres développeurs, plus facile à relire, plus facile à maintenir.

Ça n’empêchera jamais des bugs ou de sortir du mauvais code mais c’est ça, c’est une autre histoire.

Enfin, j’aimerais terminer cet article en écrivant qu’il a fait l’objet d’une chaîne par le Padawan PHPiste Damien Alexandre. C’était l’occasion de faire une réponse qui passe inaperçue

Ça ne m’empêchera en revanche pas de refiler la patate chaude à NicoDePrendreUnCafé, de tenter d’insuffler de l’activité au blog de Xavier Lacot, de Spipifier Gastero Prod, d’extirper une technique ninja pyjama à remouk et pourquoi pas lire avec attention l’avis pythonien de David Larlet ?

Et just for fun, un petit coup d’électrode à un de mes futurs étudiants, Thierry Poinot.

Le Web sémantique.
Cette expression est sur toutes les lèvres de ceux qui préparent l’Internet de demain. Moteurs de recherche, services de pointe, secteur marchand … après avoir indexé du contenu, ils aimeraient désormais le comprendre. Comprendre pour mieux cibler, mieux profiler et mieux servir.

Malgré cet aspect futuriste teinté de recherche et de développement, le concept de Web sémantique est pourtant vieux comme … le Web. Tim Berners-Lee y pensait déjà lorsqu’il accouchait d’Internet sur ses petites tablettes.

Si les hommes arrivent à comprendre les hommes, les ordinateurs ne comprennent que ce pourquoi ils ont été programmés. Le Web sémantique a été imaginé pour palier à ce problème, pour expliquer le sens du contenu, pour lier les contenus entre eux tout en décrivant ces relations.

En ce sens, les formats RDF et OWL figurent comme les étendards du concept. RDF décrit les ressources tandis qu’OWL établit des liens entre eux en leur donnant un sens. Ces relations sont nommées ontologies et permettent donc de transformer un Web de données anonymes en un Web sémantique. Un Web où humains et ordinateurs comprennent et échangent.

Les microformats sont nés du constat de complexité de mise en œuvre du couple RDF/OWL et d’un besoin de simplicité.

Les microformats

Tantek Çelik et Adam Rifkin dévoilent le concept des microformats en 2004 après 2 années d’expérimentation. Ils ne s’en cachaient pas : ils souhaitaient démocratiser et implanter la sémantique au cœur du Web en s’affranchissant au maximum de contraintes techniques.
C’est ainsi qu’au lieu de créer un énième format de fichier les microformats se greffent sous la forme d’attributs (X)HTML pour tenter de donner du sens au contenu.

Il existe plusieurs spécifications de microformats :

• hAtom (syndication de contenus, basé sur Atom) ;
• hCalendar (dates et évènements, basé sur iCal) ;
• hCard (représentation d’entité, basé sur vCard) ;
• hResume (CV, mélangeant hCard et hCalendar notamment) ;
• geo (emplacement géographique) ;
• XFN (relations entre individus) ;
• XOXO (description de contenus) ;
• et de nombreux motifs de conception rel-* (tags, nofollow, license, home etc.).

Intérêts et utilité des microformats

La force des microformats réside dans sa souplesse d’utilisation, leur approche métier et surtout, la réutilisation de formats existants.
Les microformats se basent sur deux attributs [HTML :

• <a rel="nofollow"> indique aux robots d’indexation des moteurs de recherche de ne pas suivre ce lien ;
• <span class="tel"> indique que cette balise neutre contient un numéro de téléphone ;
• <div class="entry"> indique que cette balise neutre contient un article (billet de blog par exemple).
  Rassurez-vous, le choix des classes n’est pas arbitraire et le wiki officiel est un bon guide. Il reprend les spécifications des formats cités précédemment tout en les agrémentant d’exemples.

Enfin, et pour achever d’attiser votre curiosité, voici un résumé des microformats en 7 points :

• ils s’adaptent au code et non l’inverse ;
• ils s’appliquent aussi bien sur des pages statiques que dynamiques ;
• ils aident à structurer la page ;
• ils n’ont quasiment aucun coût de mise en place ;
• ils aident et aideront à la bonne indexation du contenu dans les moteurs de recherche ;
• ils offrent des perspectives d’interaction et de navigation intelligente pour les visiteurs d’une page microformatée ;
• ils sont un socle pour réutiliser le contenu (cf. « Outils agrégeant les microformats »).

Cas pratique : offrir une carte de visite en visitant une page Web

Prenons par exemple le cas des fichiers vCard. Nos carnets d’adresses en raffolent car ils contiennent des informations de contact : nom, prénom, adresse, numéro de téléphone, email etc.
Il n’est pas rare de recevoir des emails contenant une vCard en pièce-jointe. Un clic dessus et les informations de l’expéditeur se retrouvent dans notre carnet d’adresses.

Les microformats proposent la même chose mais au format Web avec le microformat hCard. Outre la ressemblance de nom, on retrouve dans sa spécification tous les éléments de vCard (nom, prénom, adresse etc.).
La seule différence se trouve dans la représentation. Nous n’avons plus affaire à un fichier séparé (comme ça aurait été le cas avec RDF et OWL)
mais bel et bien à du texte présent sur une page Web.

Si ce code était placé sur une page Web accessible au public, n’importe quel outil gérant les microformats serait capable d’en extraire les données et pourquoi pas, de lancer une recherche sur
Google Maps pour obtenir les coordonnées GPS de l’adresse.

<div class="vcard">
  <a class="fn org url" href="http://www.clever-age.com/">Clever Age</a>
  <div class="adr">
    <div class="street-address">37, boulevard des Capucines</div>
    <span class="postal-code">75002</span>
    <span class="locality">Paris</span>
    <div class="country-name">France</div>
  </div>
  <div class="tel">
   <span class="type">Téléphone</span> +33 1 53 34 66 10
  </div>
  <div class="tel">
    <span class="type">Fax</span> +33 1 53 34 65 20
  </div>
  <div>Email: <span class="email">commercial@clever-age.com</span></div>
</div>

Outils proposant des microformats

Les industriels et les leaders du Web contribuent à diffuser les microformats en les adoptant progressivement. Cette adoption apporte une valeur ajoutée à leurs services et facilite la vie des utilisateurs.
Concrètement, ils microformatent leur contenu pour enrichir leur présentation et faciliter les interactions avec d’autres services.

Voici une liste non-exhaustive de services proposant des contenus microformatés :

• Blogs (WordPress) ;
• Cartographie (Google Maps, Yahoo ! Local) ;
• Emploi JobiJoba) ;
• Outils sociaux (Flickr, Del.icio.us, Ma.gnolia) ;
• Réseaux sociaux (LinkedIn, Ziki).

Outils agrégeant les microformats

L’utilisation la plus intéressante des microformats reste indéniablement l’agrégation. Vous pourrez ainsi construire un flux RSS à partir d’une page statique ou explorer
des photos en rapport avec la page visitée.

Technorati porte l’étendard des microformats. Ses différents services, utilisables en appelant une simple URI, permettent d’agréger des cartes de visites (vCard) ou encore des calendriers (iCal) pour générer des fichiers réutilisables dans votre carnet d’adresse ou votre gestionnaire de temps.

Jobster propose une utilisation intéressante des microformats. Ce site de recherche d’emploi vous évite l’écueil de l’énième ressaisie de CV. En lui fournissant l’URL de votre profil public LinkedIn, il en extrait toutes les données pour en générer un CV en ligne.

Les navigateurs Web jouent également le jeu. Firefox 2 (avec son extension Operator) ou encore Firefox 3 et le futur Internet Explorer 8 proposent des outils intégrés.
Sur chaque page visitée, ils en extraient tous les contenus microformatés possibles et proposent différentes interactions possibles.

D’autres outils plus confidentiels s’efforcent de défricher le terrain, notamment les agrégateurs de flux RSS/Atom et autres transformateurs XHTML/microformats :

• hatom2rss ;
• hAtom2Atom ;
• atom2rss ;
• X2V.

Conclusion

Il est de plus en plus facile de microformater les contenus, d’interagir avec et de les republier. Leur faible coût d’intégration et la rapidité
d’apprentissage sont d’autres atouts pour intéresser vos intégrateurs HTML, vos programmeurs ou même vos décisionnels.
La publication de microformats de LinkedIn et leur utilisation par Jobster pour préremplir automatiquement le CV sans ressaisie est le cas de figure idéal.
Ces pratiques ont pour vocation d’être généralisées, de quoi nous faciliter la vie.

Nous verrons dans une prochaine partie des bonnes pratiques d’intégration des microformats à des contenus déjà existants. Ce sera d’ailleurs l’occasion
de remarquer que sémantique, respect des standards et accessibilité génèrent une incroyable synergie.

Pour en savoir plus

• Présentation des microformats en mars 2006 au SXSW Interactive ;
• En route vers le Web sémantique ;
• Les 10 prochaines tendances du Web.

1. [1] Il en existe en réalité 3 mais l’attribut rev n’est employé qu’une fois. Difficile d’en déduire une généralité.

Je rédige sur ce blog depuis bientôt 3 ans, depuis plus de 5 ans sur Emu Nova et depuis quasiment 10 ans si on remonte à mon ancien site perso et mon site consacré à Star Wars. Ah l’époque des .fr.st .
Ce bagage m’a permis d’affiner mon écriture sur le Web mais je cherchais à l’améliorer. C’est précisément à ce moment qu’Olivier Ertzscheid offre la dernière préface issue de sa plume et qu’Élie Sloïm recommande un obscur livre : l’écrit Web.

J’apprécie ces hommes, entre autre, pour leur bonne parole donc il n’en fallait pas davantage pour me procurer cet ouvrage.

Pourquoi le lire ?

L’écrit Web se destine à toute personne désireuse de perfectionner son écriture. Et plus particulièrement l’écriture sur le Web.
Combien d’entre vous ou parmi vos connaissances n’ont jamais dis que lire sur un écran c’est fatiguant, les livre c’est mieux ? Une bonne majorité. Et c’est bien parce qu’on ne lit pas de la même manière un livre qu’un écran d’ordinateur qu’on doit impérativement adapter son écriture à un lectorat volatile, contraint par la technologie et difficile à capter.

L’écrit Web dispense ses bonnes pratiques pour mieux écrire sur le Web en suivant 6 grands axes :

1. organiser l’information
2. structurer son texte
3. adapter son style
4. soigner les microcontenus
5. penser indexation et référencement
6. bloguer

J’ai volontairement grassé les 4 axes les plus intéressants. Ils m’ont permis de conceptualiser beaucoup de pratiques que j’appliquais inconsciemment … et d’en découvrir d’autres.
L’idée générale n’est pas d’apprendre à écrire mais de réapprendre. Les raisons sont simples :

• on lit moins vite sur un écran d’ordinateur ;
• on lit en profondeur et non à plat, grâce aux liens hypertextes (qui ralentissent aussi la lecture).

Organiser et structurer

En partant de ces principes là, il faut donc songer à réorganiser ses textes voire ses sites Web d’une part pour faciliter la vie de ses lecteurs (occasionnels ou pas) mais aussi pour capter plus facilement leur attention. Que faites-vous devant un gros pavé de texte ou un site mal organisé ? Vous zappez. Alors pensez qu’on fait de même avec ce que vous écrivez .

En fin de compte tout contenu, que ce soit une page ou du texte, s’organise en suivant le principe de la pyramide inversée à l’image du triangle d’or d’une page Web si cher aux référenceurs. On commence par l’essentiel pour terminer sur du détail. Ça vaut également pour l’ordre des listes à afficher (chronologiques, géographiques, thématiques etc.).

Contrairement au papier où la lecture se fait à plat, on peut et on doit se servir de la navigation hypertexte pour désengorger les pavés de textes susceptibles de décourager la lecture. C’est ce qu’entend l’auteur par navigation en profondeur.
Plutôt que d’accueillir un visiteur avec beaucoup de texte, mieux vaut donc plusieurs boites aux titres informatifs présentant le contenu en une poignée de lignes.

Autre conseil judicieux, respecter les 5W (ou QQOQP en français) :

1. Qui ? (Who)
2. Quand ? (When)
3. Où ? (Where)
4. Quoi ? (What)
5. Pourquoi ? (Why)

En y songeant lors de la rédaction et en respectant l’ordre, on se retrouve à construire des phrases informatives, bien structurées et plaisantes à lire. Cumulez avec la pyramide inversée et c’est le gros lot : votre lecteur sait tout et tout de suite.

Comment mieux écrire pour le Web

Maintenant que l’on connaît l’ordre de rédaction, écrivons mieux. Écrivons court en suivant les principes 1 idée par phrase et sujet, verbe, complément. La lecture n’en est que fluidifiée. Si en plus il n’y a pas de fautes d’orthographe et que le style reste naturel, alors on touche presque au but.

Une des particularités du Web c’est la republication du contenu. On peut écrire un article pour un site mais le retrouver affiché sur d’autres sites, sur son téléphone portable, un agrégateur voire sur le même site mais sans son contenu (dans une liste par exemple).
Cette particularité est une bonne raison pour donner des titres explicites. Ils pourront ainsi être compris déconnecté de leur contexte. L’écrit Web propose des exemples clairs et compréhensibles vous aideront à mieux en comprendre les subtilités.

La construction des liens hypertexte était indispensable et mérite vraiment d’être lue par toute personne peu familière du référencement. Au-delà de cette pratique, ce sont tout simplement la compréhension et l’accessibilité qui sont en jeu. Pas de liens sur des cliquez ici, ici ou là. Je rajouterai même qu’il ne faut pas de liens ayant le même libellé pointant vers des URL différentes.
Tout comme le libellé du lien décrit le contenu vers lequel il pointe, il vaut mieux englober plusieurs mots (plus facile à cliquer) et qu’ils soient soulignés surtout ! Combien de chartes graphiques je reçois sans aucun lien soulignés ; j’outrepasse systématiquement cette mauvaise pratique du graphiste, dans le contenu en tous cas.

Conclusion

J’ai énormément apprécié et appris de ce livre, surtout les parties structurelles et organisationnelles. La pyramide inversée et les bonnes pratiques de rédaction sont des gros « plus » que j’ai rarement retrouvé ailleurs … ou tout du moins, pas concentré en si peu de pages.
Il se lit très bien et rapidement. J’ai prévu de l’offrir à quelques collaborateurs rédacteurs qui seront susceptibles d’en tirer des leçons et ainsi améliorer leur qualité rédactionnelle. Un bon investissement.

J’ai en revanche moins appris (voire rien du tout) sur les 2 derniers chapitres concernant le référencement et les blogs. Étant donné la quantité d’informations à traiter sur ces sujets, le contenu du livre était forcément un peu léger mais pas dénué d’intérêt pour les néophytes.
Ces parties étaient néanmoins plus techniques et à mon avis plus difficiles à comprendre pour des personnes survolant l’informatique.

Si vous ne saviez pas quoi faire de vos étrennes, que vous rédiger pour le Web et que le marketing vous intéresse, il y aura sûrement de bonnes idées à prendre

Lors de la refonte de ce blog, j’ai concocté un petit script JavaScript (non intrusif bien entendu) affichant et modifiant le contenu d’un bandeau sous la forme d’une classe statique reponsant sur jQuery. J’explique aujourd’hui comment ces 48 petits lignes de code (en comptant commentaires, sauts de lignes et accolades) fonctionnent, comment il est aisé de mettre en place de telles routines de manière intelligente, souple et non intrusive.

Et comme l’indique le slogan de jQuery : Write less, do more.

Le besoin

Avant de se lancer tête baissée dans le code, prenons le temps d’exprimer avec des mots ce que l’on aimerait faire.

On souhaite disposer d’une liste de liens. Lors d’un clic sur un lien de cette liste, l’encart correspondant doit s’afficher pour illustrer davantage son sens. Eventuellement, lorsque l’on reclique sur ce même lien, le visiteur est transporté sur la page en question.

J’ai grassé les mots importants de ce besoin. Vous le verrez par la suite, ils vont régir le comportement du script.

La structure HTML

Nous allons donc nous retrouver avec trois grosses parties dans le code :

• la liste de liens, une balise ul semble toute indiquée)
• une liste de textes correspondants, il n’a pas lieu d’être visible pour l’utilisateur final concerné par le code
• un bloc conteneur neutre destiné à recevoir les textes d’enrichissement de manière visuelle

Des mots au code, voici ce que donnerait la structure balisée :

<body>
<!-- (...) -->
	<div id="conteneur_cible"></div>
	<!-- (...) -->
	<ul id="liens_etendus">
		<li><a href="page1.html" class="page1">Page 1</a></li>
		<li><a href="page2.html" class="page2">Page 2</a></li>
		<li><a href="page3.html" class="page3">Page 3</a></li>
	</ul>
	<!-- (...) -->
	<div id="conteneur_source">
		<h2>Titre</h2>
		<p>Texte explicatif apportant de la cohérence aux utilisateurs dépourvus de JavaScript et d'interprétation des feuilles de style.</p>
		<ul>
			<li class="page1">Texte page 1</li>
			<li class="page2">Texte page 2</li>
			<li class="page3">Texte page 3</li>
		</ul>
	</div>
<!-- (...) -->
</body>

L’ordre de la structure importe peu mais dans tous les cas, leur position dans le flux HTML dépend avant tout de leur importance au sein de celui-ci. De manière générale, il vaut mieux disposer le contenu principal tout en haut du flux et le faire suivre par le contenu secondaire tels que les menus de navigation et les textes supplémentaires.
Je pense que le code parle de lui-même, posez vos questions en commentaires si jamais il y a besoin d’explications plus poussées.

Côté HTML tout est réglé avec ceci. Il ne restera éventuellement que du travail de stylage pour lui donner une apparence plus conviviale.
Vous remarquerez qu’il n’y a aucune mention à du JavaScript à l’intérieur de ce code et ce sera le cas jusqu’au bout. C’est tout l’intérêt de séparer fond et forme et donc, du JavaScript non intrusif.

Le code Javascript

J’ai pris la décision d’écrire ce code pour jQuery car cette bibliothèque (ou framework) est embarquée dans WordPress et réduit drastiquement la quantité de code à écrire pour produire des résultats.

Dans la pratique, le code va se charger dès que possible (c’est à dire dès que le DOM est prêt) et exécutera une méthode en se servant des paramètres prédéfinis ou passés manuellement à la classe. Le code suivant est structuré et suffisamment commenté pour le comprendre sans trop de difficulté. J’expliquerai en-dessous sa logique :

/*////////////////////////////////////////
// Classe statique 'oncletom_text_grabber'
// # Permet d'afficher un slide d'informations en cliquant sur un lien
// # C'est rigolo et en plus ça sert à quelque chose
// @ parametres (objet, optionnel) : objet de clé:valeur paramétrant le comportement
////////////////////////////////////////*/
function oncletom_text_grabber()
{
	var parametres = arguments.length == 1 && typeof arguments[0] == 'object' ? arguments[0] : {};
	//Paramétrage de la fonction
	//# permet un lancement de la classe avec un paramétrage par défaut
	parametres.source = typeof parametres.source == 'undefined' ? '#conteneur_source > ul > li' : parametres.source;
	parametres.bindto = typeof parametres.bindto == 'undefined' ? '#liens_etendus a' : parametres.bindto;
	parametres.target = typeof parametres.target == 'undefined' ? '#conteneur_cible' : parametres.target;
	/*////////////////////////////////////////
	// Méthode publique 'ot_text_caller'
	// # Récupère le contenu associé à l'attribut 'rel'
	// # Méthode à appeler sur un évènement
	////////////////////////////////////////*/
	function ot_text_caller()
	{
		//sélection de l'élément à récupérer
		var id = $(this).attr('class');
		//hop ! on vérifie c'est déjà ouvert. Auquel cas le lien redevient cliquable
		if( $( parametres.target ).attr('class') == id )
		{
			return true;
		}
		//on nettoie le contenu de la destination
		$( parametres.target ).empty();
		$( parametres.target ).attr({ 'class' : '' });
		//on remplit la destination avec le bon contenu
		//on le fait en utilisant une expression régulières pour récupérer l'élément voulu
		$( parametres.target ).fadeIn( 'slow' ).append(  $( parametres.source+"."+id ).html() ).toggleClass( id );
		//évite que le lien soit cliqué
		return false;
	}
	//On greffe les différentes méthodes
	$( parametres.bindto ).click( ot_text_caller );
}
//exécution automatique de fonctions au lancement du document
$( oncletom_text_grabber );
//FACULTATIF
//pour assigner une deuxième liste de liens, il suffirait d'écrire le code ci-contre, par exemple :
//tous les paramètres non renseignés prennent la valeur par défaut de la classe
$( function(){ oncletom_text_grabber({ 'target' : '#nouveau_conteneur_cible', 'bindto' : '#exemple_entete ol a[@rel]', 'source' : '#liste_source2' }); } );

1. Dans un premier temps, je m’applique toujours à pouvoir proposer une utilisation de la classe sans avoir à fournir de paramètre lors de son appel. C’est un côté pratique qui permet en plus de documenter les différentes options possibles. Ces options correspondent aux différents sélecteurs jQuery dont on aura besoin par la suite ;
2. Dans un deuxième temps, je déclare une méthode interne à la classe. La cascade des accolades fait qu’elle n’est accessible que depuis la classe. Cette méthode sera assignée à l’évènement onclick de tous les éléments concernés par parametre.bindto. En clair, des liens hypertextes. Le this y fait référence.
   1. On stocke dans la variable interne id le nom de la classe. En effet, la classe du lien permet de récupérer le bon texte dans el conteneur source (parametre.source),
   2. On vérifie que le conteneur cible ne porte pas le même nom de classe : si oui, on suit le lien, si non, on affiche d’abord le texte complémentaire (la suite),
   3. Le passage le plus délicat consiste à extraire ce qu’il faut et le placer où il faut. Heureusement jQuery dispose de deux fonctions magiques : append() et html(). La première rajoute du HTML à la suite du sélecteur tandis que la deuxième extrait le HTML par sélection. Le fonctionnement en chaîne de jQuery permet de réaliser tout ceci en une ligne,
   4. Pourquoi un return false; pour terminer ? Tout simplement pour éviter que le lien hypertexte contenu dans l’attribut href du lien soit suivi.
3. Dans un troisième temps, on assigne la méthode déclarée juste avant. A chaque clic de chaque élément, elle sera appelée et surtout, aura accès à tous les paramètres de la classe ;
4. Enfin, après avoir clôturé la classe, on l’exécute dès que le DOM est chargé.

Conclusion et résultat

Pour que ce code soit effectif, il faut bien évidemment l’insérer à même la page ou bien en appelant un script externe (cette méthode est recommandée justement pour dissocier fond et forme). Il faut aussi penser à inclure jQuery dans votre page sans quoi le compilateur JavaScript va tirer la tête.

Pour résumer, je résume la pensée des bonnes pratiques du JavaScript non intrusif, prouvant si besoin en était que JavaScript est loin d’être le Diable :

1. définir sa structure HTML
2. styler le HTML
3. ajouter le JavaScript en surcouche

Ainsi, on ne pénalise personne (y compris en cas d’erreur de programmation), on conserve un code lisible tout en facilitant sa réutilisation dans un autre document.

Pendant que la bataille fait rage du côté des sites Web 2.0 (mais c’est un des leviers de l’innovation sur Internet que l’on aime ou pas cette appellation), une révolution silencieuse se met en marche : le Web sémantique ou encore le Web 3.0.
Jusqu’à présent, les moteurs de recherche (Google, Yahoo!, Windows Live Search, Exalead etc.) avaient pour défi le recensement du plus grand nombre de documents et des résultats de recherche pertinents.

S’il faudra bien évidemment soigner l’intitulé des liens, il faudra avant tout donner du sens à vos documents. C’est tout l’intérêt d’une programmation propre, respectant les standards et utilisant la sémantique à bon escient.

Les microformats sont pour moi un élément essentiel qui accéléreront le processus et permettront de comprendre l’intérêt de la sémantique.

Qu’est-ce que la sémantique ?

La sémantique est loin d’être une invention de l’informatique puisque ce principe est à la base de toutes les langues du monde. La sémantique se réfère tout simplement au sens exprimés par les mots. Ce concept peut être à vrai dire être élargi à tout ce qui structure de l’information.

Plus concrètement encore, ouvrez un journal (Le Figaro, Libération ou même Voici) et prenez une page au hasard. Vous arriverez sans peine et surtout sans lire le texte à discerner les titres d’articles, leur résumé, leurs passages clés et leur texte à proprement parler. Pourquoi ? Parce que tous ces éléments sont présentés de manière différente, utilisent une police de caractère différente et ont une taille différente. Un titre d’article sera naturellement plus grand et plus épais que l’article ; le résumé sera situé sous le titre et sera espace du texte l’article en lui-même.

Et si vous ne prenez pas garde à la sémantique en elle-même c’est parce qu’elle silencieuse et logique : votre cerveau analyse lui-même ce qu’il faut faire car il comprend la signification de la disposition sans avoir à comprendre ce qui est écrit.

Bien structurer une page HTML

Récemment encore j’entendais de la bouche d’une agence Web on fait des sites aux standards, avec des div et du CSS. C’est déjà bien de passer au validateur mais c’est encore mieux si on produit du code significatif.
Voici deux exemples de code qui contiennent les mêmes textes et qui respectent le standard (X)HTML.

Méthode sémantiquement correcte :

<div id="introduction">
	<h2>Site valide HTML</h2>
	<p>Cette portion de code a un code HTML valide.</p>
	<p class="suite"><a href="./edito">Lire la suite de l'édito</a></p>
<div>

Méthode sémantiquement incorrecte :

<div id="page_haut">
	<div class="titre rouge">Site valide HTML</div>
	<div class="texte">Cette portion de code a un code HTML valide.</div>
	<div class="texte petit"><a href="./?page=12345">Lire la suite de l'édito</a></div>
</div>

Sans avoir à donner un cours de balisage, voici les principes auxquels se tenir :

• utilisez les balises HTML au bon endroit et à bon escient. Ne mettez pas un div (bloc neutre) si un p (paragraphe) ou un hn (titre hiérarchique) peuvent faire l’affaire. De même pour les listes, n’utilisez pas de div (bloc neutre) si une ul/ol (liste désordonnée, liste ordonnée) ou une dl (liste de définition) sont mieux adaptées.
• nommez les classes (.classe) et les id (#id) en fonction de ce qu’ils représentent et non en fonction de l’apparence qu’ils devraient avoir.

Et c’est tout ! Cette petite touche de rigueur assurera une pérennité certaine dans vos développements. Sans compter la facilité à intégrer les microformats par la suite.

Et les microformats dans tout ça ?

Justement les microformats parlons-en. Si de prime abord sémantique et microformats peuvent paraitre sans grand rapport, ces concepts sont pourtant intimement liés. En utilisant les attributs class et rel (pour les liens hypertextes) dans une logique bien précise, on décrit le contenu et sa nature (titre de billet, auteur, date d’un évènement etc.).

Pour faire simple :

• les microformats sont faciles à intégrer si le contenu est déjà bien structuré
• les microformats aident à bien structurer le contenu : qu’il soit bien structuré ou pas, les recommandations vous guideront dans cette voie
• les microformats sont déjà reconnus par des moteurs de recherche spécialisés (Technorati) et plus officieusement par les moteurs de recherche classiques (Google, Yahoo! etc.). Pas convaincu(e) ? Voici la liste non-exhaustive des sites comprenant les microformats.

Pour bien compléter ces paroles, je vous recommande cette excellente introduction aux microformats.

Intérêt supplémentaire des microformats

Ce qui est intéressant avec les microformats c’est que l’on peut les utiliser sans avoir derrière un site Web super hi-tech en Web 46.0 full Ajax. Une page HTML suffit. J’ai justement utilisé les microformats la première fois lorsque j’ai voulu refaire mon CV en me disant qu’en HTML ça serait sympa. Il existe fort heureusement un microformat hResume réutilisant lui-même les microformats hCard (carte de visite) et hCalendar (calendrier et évènements).
Outre l’aspect purement technique de cet exercice, ce CV me sert maintenant de carte de visite (en utilisant le service contacts de Technorati) en plus de pouvoir être réutilisé sur des sites de recherche d’emploi.

Mis à part une sémantisation de votre contenu, voici les bénéfices à retirer d’un microformatage :

• extraction et republication du contenu à la volée : des services Web permettent d’aggréger une page pour la transformer en flux Atom voire même de créer des cartes de visites instantanément
• les navigateurs Web intégreront eux aussi les microformats pour faciliter la navigation des utilisateurs : installez l’extension Operator pour Firefox, revenez sur cette page et améliorez votre expérience de navigation
• les microformats sont au coeur de l’Internet de demain et c’est aujourd’hui qu’il faut y travailler

La sémantique, moteur des futures recherches sur Internet

Même si à l’heure actuelle on peut considérer que les microformats aident au référencement, ce n’est pas explicitement mentionné. Mais l’avenir est à la recherche sémantique afin d’affiner les résultats et de mieux répondre aux requêtes. C’est un énorme défi puisqu’entre indexer du contenu et comprendre ce qu’il dit, il y a tout un fossé. Cette recherche sémantique s’appliquera aussi bien au texte qu’aux ressources audio (musique, interview etc.) et vidéo.
Hakia s’intéresse à la recherche sémantique musicale tandis que d’un autre côté, la recherche sémantique est considérée comme étant une fonctionnalité nécessaire pour le futur de la recherche sur Internet.

Edition du 31/07 à 19h10 : Google Maps intègre désormais le microformat hCard.

Voici donc mon constat de départ :

• un client doit pouvoir saisir un seul article s’il le veut
• un client doit pouvoir saisir 10 articles s’il le veut
• un client doit pouvoir saisir 100 articles s’il le veut
• mais celui qui n’en saisit que 10 ne doit pas être gêné par 100 lignes de formulaire à remplir
• un débutant doit pouvoir saisir 100 lignes sans avoir de mode d’emploi sous la main

Donc ma solution a été très simple : je ne mettrai qu’une ligne.

L’idée

Comment faire pour satisfaire tout le monde, les gros donneurs d’ordre comme les petits ?
En faisant en sorte que le formulaire s’adapte à leur besoin. Je voulais donc qu’à chaque ligne complétée s’en ajoute une autre avant de passer à la validation finale. Place au combo JavaScript + DOM = Ajax.

La version dégradée

Une bonne pratique de l’Ajax est de partir du cas particulier : celui où les conditions ne sont pas requises. En clair, une personne qui n’a pas JavaScript d’activé ou pas de JavaScript tout court.
Conclusion, j’ai décidé de générer un tableau en HTML de 10 lignes. 10 est un choix arbitraire, modifiable à tout moment et qui ne doit donc pas gêner la version dynamique en cas de changement (ajout de colonne, ajout de lignes).

La version Ajax

On peut manipuler le document à loisir grâce à JavaScript. Avec un code propre et ordonné c’est d’autant plus simple. Alors voici la logique à mettre en oeuvre :

1. éliminer toutes les lignes dont on ne veut pas et n’en garder qu’une
2. assigner à chaque champ de formulaire de la ligne (input, select, textarea) une fonction de vérification : si tous les éléments de la ligne sont remplis / cochés et qu’il n’y a pas de ligne après, on clonera la ligne
3. cloner la ligne en la vidant de ses valeurs, en modifiant les noms de champ pour les rendre exploitable après coup

Ce qu’on l’on veut étant relativement simple, le code doit l’être également ! Le résultat aussi, la preuve en mouvement.

Au final, 50 lignes de JavaScript ont suffit à transformer un tableau complètement statique en tableau dynamique, s’adaptant à la demande de n’importe quel client. Client qui pourra également utiliser le clavier pour davantage d’efficacité de saisie.

C’est à dire exactement ce que l’on souhaitait au départ.

Le code

Le tableau HTML

<table cellspacing="0" id="ajout_multi_articles">
  <thead>
    <tr>
      <th>Code article</th>
      <th>Quantité</th>
    </tr>
  </thead>
  <tbody>
    <tr class="article">
      <th><input type="text" name="article[1][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[1][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[2][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[2][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[3][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[3][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[4][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[4][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[5][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[5][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[6][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[6][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[7][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[7][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[8][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[8][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[9][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[9][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[10][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[10][qte]" maxlength="5" size="5" /></td>
    </tr>
  </tbody>
</table>

La fonction JavaScript

/**
 * Transforme un tableau multi-lignes en un tableau mono-ligne mais auto-extensible
 * Renomme également les noms de champ en suivant un masque paramétrable ; par défaut article[]
 *
 * @usage articlesMultiRows([{'css_id': ?, 'css_row_class': ?, 'check_inputs': ?}])
 * @param {Object} params Objet contenant (ou pas) les paramètres de contrôle de la classe
 */
function articlesMultiRows(params)
{
  this.row_number = 0;
  /*
   * Extension des paramètres par défaut
   */
  var params = params || {};
  params.css_id = params.css_id || 'ajout_multi_articles';
  params.css_row_class = params.css_row_class || 'article';
  params.check_inputs = params.check_inputs || 'input,select,textarea';
  /**
   * Initialise le tableau de données et accroche les méthodes dynamiques
   */
  this.init = function(){
    //aucun ID détecté, pas la peine de continuer plus loin
    if (!$(params.css_id))
    {
      return false;
    }
    //on récupère les lignes, on enlève la première du tableau et on supprime les autres
    var rows = $(params.css_id).getElements('tr.'+params.css_row_class);
    var row_first = rows.shift();
    rows.removeElements();
    rows = null;
    /*
     * On assigne l'évènement aux champs paramétrés de la ligne
     * On place le focus sur le premier champ
     */
    $ES(params.check_inputs, row_first).addEvent('blur', rowCheck);
    $(row_first).getElement('input').focus();
    row_number = 1;
    /*
     * On écrit un petit message sympathique indiquant le fonctionnement du bazar
     * On le fait via JavaScript car un utilisateur sans JS ne pourrait justement pas suivre les infos
     * Il est placé juste avant le tableau
     */
    new Element('p',{
          'class' : 'message'
          }).setHTML("Dès qu'un code article et une quantité sont saisis ci-dessous, <strong>une nouvelle ligne s'ajoute automatiquement</strong>.<br />Afin d'accélérer votre saisie, <em>utilisez la touche de tabulation de votre clavier</em> pour passer d'un champ à l'autre. Vous verrez, c'est facile et surtout efficace !").injectBefore(params.css_id);
  };
  /**
   * Vérifie si la ligne a entièrement été complétée et le cas échéant, déclenche l'ajout de ligne
   */
  this.rowCheck = function(){
    var row = { 'inputs' : 0, 'completed' : 0, 'dom' : $(this).getParent().getParent() };
    $ES(params.check_inputs, row.dom).each(function(input){
      //Un élément de plus ...
      ++row.inputs;
      //... dont on vérifie s'il est bien complété
      switch (input.getTag())
      {
        case 'input':
        case 'textarea':
          if (input.value.clean())
          {
            ++row.completed;
          }
        break;
        case 'select':
          if (input.selectedIndex >= 0 && input.selectedIndex < input.length)
          {
            ++row.completed;
          }
        break;
      }
    });
    /*
     * Pour insérer une nouvelle ligne, on doit avoir :
     * - autant de champs complétés que de champs existants
     * - aucun élément suivant
     */
    if (row.inputs === row.completed && !row.dom.getNext())
    {
      rowInsert(row.dom);
    }
  };
  /**
   * Insère une nouvelle ligne en clonant la dernière du tableau et la purgeant de ses valeurs
   *
   * @param {Object} row Noeud DOM correspondant à la ligne à cloner
   */
  this.rowInsert = function( row ){
    //On incrémente le nombre de lignes dispo
    //Ce numéro sert à changer les masques de nom de champ
    ++row_number;
    var row_clone = row.clone();
    //Clonage de la ligne
    $ES('input[type=text],input[type=password],input[type=hidden],textarea', row_clone).setProperty('value', '');
    $ES(params.check_inputs, row_clone).removeEvents('blur'); /* obligé car IE5+ clone aussi les évènements ... alors qu'il ne le devrait pas */
    $ES(params.check_inputs, row_clone).addEvent('blur', rowCheck); /* oui oui, IE5+ ne rassignait pas cet évènement comme il fallait malgré ça */
    //On remplace les noms des champs pour que permettre une utilisation des résultats $_POST
    $ES(params.check_inputs, row_clone).each(function(input){
      input.name = input.name.replace(new RegExp('^'+params.css_row_class+'\[[0-9]+\]'), params.css_row_class+'['+row_number+']');
    });
    //Injection de la ligne, une fois tout le travail terminé
    row_clone.injectAfter(row);
    //Nettoyage, le clonage, ça salit
    row_clone = null;
    row = null;
  };
  /*
   * Initialisation de la classe
   */
  this.init();
}
/*
 * Initialisation du tableau multi-lignes avec les options par défaut
 */
window.addEvent('domready', articlesMultiRows);

Lorsqu’on crée son premier site ou bien lorsqu’on navigue sur Internet, on est loin de se douter de l’étendue des conventions implicites qui facilitent la vie de tout le monde.
Et pourtant, passé l’apprentissage de la soupe de balises HTML et éventuellement des feuilles de style, il y a tout un tas de règles à respecter pour rendre la navigation aisée et non bloquante. Car oui, mal concevoir un site peut en bloquer, qu’il s’agisse de personnes atteintes de déficiences (physiques, mentales) ou pas.

Pour se sensibiliser à ces bonnes pratiques de la conception des sites Web, il existe depuis peu le guide Sites Web : les bonnes pratiques édité dans la collection Memento d’Eyrolles. Les habitués de l’initiative Opquast ne seront pas dépaysés étant donné qu’il en reprend les quelques 153 bonnes pratiques.

Mais au final, c’est quoi une bonne pratique ? Quelques règles que certains appliquent sans se rendre compte alors que d’autres sont au contraire bien loin de pouvoir ne serait-ce que les imaginer.

Exemples de bonnes pratiques simples que n’importe qui peut mettre en oeuvre :

• Le nom du site et/ou le nom de l’auteur sont indiqués sur chaque page ;
• Le soulignement est réservé aux hyperliens ;
• Le site propose au moins un moyen de contacter l’auteur et/ou le webmestre.

D’autres sont plus tordues au premier abord mais totalement justifiée, certaines abordant le délicat sujet de l’accessibilité :

• Les hyperliens sont visuellement différenciés du reste du contenu ;
• L’emplacement du menu principal de navigation est identique sur toutes les pages ;
• La navigation reste possible sur l’ensemble du site en utilisant exclusivement le clavier.

Comme vous pouvez le constater, ça n’a rien de bien sorcier. C’est un peu comme dire bonjour en se présentant à un inconnu : c’est le minimum à fournir pour établir une conversation. Lorsqu’on crée un site Web, c’est une conversation avec le monde que l’on établit