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 !

Cet outil me paraît indispensable alors j’ai décidé de l’intégrer à WordPress : WP-LESS est né.

LESS en quelques mots (ou lignes de code)

Pour mettre en exergue l’intérêt de LESS, je reprends un exemple officiel :

#defaults {
  @width: 960px;
  @color: black;
}
.article { color: #294366; }
.comment {
  width: #defaults[@width];
  color: .article['color'];
}

Le source précédent utilise 3 principes :

• les variables (dont leur nom est préfixé par un @)
• les namespaces (ici, #defaults) pour regrouper des propriétés
• les accesseurs (pour obtenir la couleur de l’article au sein du commentaire)

Une fois ce code compilé par LESS, la feuille de style générée se résume à ceci :

.article { color:#294366; }
.comment {
  width:960px;
  color:#294366;
}

C’est simple et efficace. Surtout quand on sait que l’on peut effectuer des opérations mathématiques, y compris en utilisant les variables, la conception va se retrouver facilitée.

L’intérêt de WP-LESS

WP-LESS intègre le parseur PHP, phpless, au sein de WordPress pour minimiser le travail à fournir.

Une fois activé, dès qu’il détecte un fichier comportant l’extension .less, il compilera automatiquement le fichier pour produire des CSS interprétables par les navigateurs Web. Pour des raisons de performances, cette compilation n’est effectuée que lorsque le fichier .less est modifié. Cela implique également qu’à chaque mise à jour de votre fichier .less, vous n’avez pas à vous soucier de compiler son équivalent CSS.

De nombreux hooks et filtres sont placées un peu partout dans le code pour permettre à tout développeur, créateur de thème ou bidouilleur de se fixer dessus sans avoir à modifier le code du plugin. Et dans les rares cas où ça ne suffirait pas, tout est extensible puisqu’il suffit d’hériter de l’objet WPLessPlugin pour parvenir à vos fins.
Des tas de choses qu’on ne pourrait pas faire en simple PHP4 (message subliminal : WordPress doit abandonner PHP4).

WP-LESS agit en toute transparence et simplicité.

Quel avenir pour WP-LESS ?

J’ai déjà en tête d’autres fonctions pour simplifier encore plus la vie :

• permettre l’intégration dans un thème en tant que dépendance externe pour permettre aux thémeurs de redistribuer WP-LESS sans avoir à activer le plugin
• proposer des helpers pour ne pas avoir à passer par wp_enqueue_stylesheet (même si c’est la meilleure solution)
• dissocier les fichiers .less des feuilles de style dans l’éditeur de thème avec une validation lors de l’enregistrement
• afficher un tableau de bord montrant l’état des fichiers de cache tout en pouvant les purger

Vous attendriez d’autres fonctionnalités de la part de ce plugin ?

Je me décide à passer un coup de peinture sur ce blog quasiment 2 ans après le CSS Summer Refresh organisé par Alsacréations. À vrai dire, j’avais ce projet dans les cartons depuis septembre 2008 mais le plus difficile a été de trouver le talent graphique. C’était également l’occasion de dire au revoir aux navigateurs Web de seconde zone, à savoir Internet Explorer 7 et moins.

Le besoin

Mon besoin était le suivant :

• Thème graphique
  • durable et peu lassant
  • usage de transparence
  • toujours sur des tons marrons
  • inspire la modernité tout comme le côté rustique et soucieux de la nature
  • structure en grille pour intégrer avec Blueprint
• Fonctionnalités
  • intégration d’un lifestream (intégré entre temps)
  • intégration de Feedburner via son API Awareness
  • intégration d’un bandeau Flickr qui s’étend sur toute la largeur de l’écran, peu importe la résolution employée
  • utilisation du blog comme vitrine : suppression de ma dernière page HTML manuelle (autrefois accessible sur oncle-tom.net)
• Compatibilité
  • navigateurs modernes … c’est à dire rien en dessous d’Internet Explorer 8
  • intégration avec HTML 5
  • pas d’utilisation de GIF mais de PNG 6 et PNG 24
• Autre
  • soucis de performance (peu d’éléments graphiques, utilisation des sprites)

Finalement c’est Lesly qui s’est chargé de la création graphique. Vous pouvez d’ailleurs consulter la maquette graphique originale sur son portfolio. Quant à moi, j’ai réalisé toute l’intégration CSS/HTML dans WordPress.

L’intégration

Tout d’abord, qu’est ce qui a changé par rapport à la maquette ?

• les polices de caractère : hormis le titre, seules des polices standards ont été employées. J’attendrai le support des polices personnalisées en CSS 3 à moins de partir sur une solution à base de SVG (encore que j’ai des doutes sur l’accessibilité d’une telle méthode) ;
• moins d’éléments graphiques : les punaises, les effets papiers ont été supprimés. Rien que le papier et le scotch de la partie « À propos » pesaient plus de 60Ko ;
• abandon temporaire du featured content : les solutions actuelles étaient trop lourdes et j’étais trop impatient pour passer quelques heures de plus … donc c’est temporaire
• l’ajout des pages en lieu et place du fil d’ariane : j’en avais besoin pour présenter différents contenus statiques ;
• le pied de page : peu de widgets WordPress offrent un degré de personnalisation suffisant pour arriver à ce résultat. C’est donc temporisé là aussi en attendant de trouver chaussure à mon pied

Aperçu pleine page

Pour le reste je me suis fait plaisir avec notamment l’utilisation de coins arrondis (border-radius) basés sur les implémentations de Gecko et Webkit. Désolé pour les utilisateurs d’autres navigateurs car j’en ai usé et abusé afin d’éviter l’utilisation d’images.

J’ai également joué avec l’API de WordPress pour générer les vignettes des articles. Je sais bien qu’on peut définir des tailles d’images mais ça ne vaut que pour les médias nouvellement mis en ligne. J’en ai profité pour n’afficher dans le listing que l’extrait du billet. Pas l’intro, seulement l’extrait (excerpt). J’ai lu récemment un article qui parlait de la chose et ça m’a paru plus approprié. Je peux désormais écrire le texte qui me convient pour attirer la lecture vers un article sans pour autant que ça ait de répercution sur son contenu une fois affiché en pleine page.

Je suis en revanche toujours dubitatif sur l’API de WP Cron : ma tâche a beau être enregistrée et planifiée, j’ai l’impression qu’elle ne s’exécute jamais … contrairement aux recherches de mises à jour de plugins & cie. Quelqu’un a déjà joué avec et rencontré pareil problème ?
Mise à jour : j’ai résolu le problème et détaillé la marche à suivre dans l’article affichage personnalisé de ses lecteurs Feedburner. Je planifiais une fonction et non un hook. Cela fonctionnait mais ne produisait fatalement pas de résultat

Au final je n’ai même pas eu à placer la moindre ligne de JavaScript : tout est fait à partir de sélecteurs CSS. Mon seul regret : l’absence de sélecteur adjacent … « précédent ». Pour le menu du haut, je voulais pouvoir styler les éléments de menus ayant comme élément suivant une liste d’élément (<ul>).

Au final

J’ai mis à peu près 2 jours pour tout intégrer et optimiser. Je n’ai pas encore tenté l’optimisation à coup de PNG 8 grâce aux quelques Ko gagnés avec pngcrush. Il faudrait également que je réunisse quelques images dans un seul et même sprite pour gagner encore quelques dizièmes de seconde en temps de chargement.

Rapport YSlow

J’en ai profité pour tester l’utilisation de mod_expires et mod_gzip chez OVH en mutualisé (avant de tout migrer sur serveur dédié) : ça marche plutôt très bien. Si ça vous intéresse, je peux en faire un billet dédié. D’ici là, n’hésitez pas à bouquiner High Performances Web Sites qui reste une référence en la matière. J’attends d’ailleurs sa suite avec impatience : Even Faster Web Sites: Essential Knowledge for Frontend Engineers.

Quoiqu’il en soit, le fait d’avoir eu la pleine utilisation des sélecteurs CSS a été géniale : la vie est grandement facilitée. inline-block évite de nombreuses bidouilles à base de flottants. J’ai hâte qu’une version de Blueprint sorte en se basant uniquement sur les sélecteurs avancés et non des flottants pour disposer de mises en forme plus complexes tout en étant facile d’accès.

Si vous rencontrez des problèmes, surtout n’hésitez pas à les signaler, par le biais des commentaires ou par email

En attendant, je retourne sur mon projet éprouvant du moment !

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.

J’ai eu peur il y a 2 semaines en arrivant à Paris-Web 2008 : en discutant avec plusieurs personnes, il se trouve que peu d’entre elles connaissaient les frameworks CSS. Je craignais de n’attirer personne avec ce sujet lors des ateliers du samedi.

Les frameworks CSS ont été mentionnés la première fois dans la conférence Working in the Now (visualiser la présentation). Au final, on n’était pas loin de faire salle comble avec plus d’une vingtaine de participants à vue de nez.

Une petite scéance de rattrapage s’impose

Pourquoi avoir choisi ce sujet ?

J’ai lu un article sur l’importance du rythme vertical l’an dernier sur Biologeek et ça m’a sensibilisé au fait qu’on pouvait rendre la lecture d’un site tout simplement en rendant prédictible la position du texte.

Entre temps j’ai également lu l’excellent Transcender CSS d’Andy Clarke. J’y ai été sublimé par des présentations de sites totalement en grille.

Depuis je suis devenu fan de Blueprint CSS (je crois que ça s’est remarqué lors de mon intervention ). J’ai commencé à l’utiliser sur des projets personnels puis dans un cadre professionnel. J’utilisais déjà symfony comme framework PHP et jQuery comme framework JavaScript alors pourquoi pas Blueprint ?

Comme le suggérait très justement Christian Heilmann dans sa présentation, l’utilisation d’outils déjà existants est nécessaire pour réduire les coûts de production. C’était déjà un bon alibi mais je les apprécie aussi parce qu’on gagne un temps fou ! On se concentre sur le code métier, pas le reste.

La présentation

Je n’en dis pas plus, je vous laisse lire la présentation. Ayez toutefois en tête qu’en vrai elle dure facilement 1h.

Ce qu’il faut en retenir

J’ai rencontré 2 types de réactions lorsque j’ai parlé des frameworks : les enthousiastes et les réfractaires.

Je ne reviens pas sur les enthousiastes : il suffit de lire ma présentation. Les atouts les ont clairement séduit.
Je m’intéresserai plutôt aux réfractaires. Assez paradoxalement, ce n’est pas dans la salle que je les ai eu mais en dehors. Les principaux arguments étaient :

• ça rajoute des kilo-octets superflus
• on perd le contrôle de notre code
• j’utilise déjà le mini-framework d’un collègue ou qui existait dans mon entreprise avant que j’arrive

Ces arguments sont tout à fait acceptables … mais ça dépend dans quel contexte.

Exemple de mise en forme en grille

Les sites à la recherche de performances exceptionnelles, ceux pour qui un Ko supprimé économise plusieurs Go de bande-passante par jour … oui ceux-là ont un grand intérêt à réfléchir à l’adoption d’un framework, aussi compressé qu’il soit.
Je ne me fais pas de soucis pour eux : en général ils ont leur propre framework, totalement adapté à leur besoin. Cependant ça n’empêche pas d’aller prendre des idées ailleurs et de découvrir de nouveaux concepts. Puis de les intégrer.

Lorsqu’on adopte un outil de développement rapide (RAD), la conception ne se fait plus par rapport à nos habitudes mais par rapport à des principes établis. On ne fait plus forcément comme on veut mais les meilleurs frameworks disposent de fonctionnalités répondant à cette problématique. Le compressor de Blueprint en est un parfait exemple.
Il permet de construire une version de Blueprint adaptée à son besoin, inclut des feuilles de notre choix et compresse le tout en un seul fichier prêt à la mise en production.

Maintenant l’avantage d’un framework c’est qu’une communauté ou un groupe de personnes compétentes en ont la gestion. Ces mainteneurs produisent une documentation, des spécifications et un code suffisamment compréhensible à lire. Ce n’est pas forcément le cas de Joe le développeur à qui on aura demandé 36 choses en même temps.
Je fais davantage confiance à un outil éprouvé avec succès sur des milliers de projets qu’un outil développé sur un coin de bureau, malgré toute la bonne volonté de son concepteur.
C’est également un risque certes mais un bon outil délaissé aura tout de même le mérite de fonctionner … et d’avoir davantage de chances de trouver un repreneur.

Une remarque intéressante a également émergé de l’atelier : faut-il utiliser un framework CSS avant ou après que la créa graphique ait été établie ?
Je réitère ma réponse : l’idéal est que tout soit pris en charge le plus tôt possible. Autrement dit, intégrer les contraintes du framework dès la conception graphique est un gros atout. Le découpage de la maquette n’en sera que facilité et ça évitera tout bricolage.
Certains outils l’ont d’ailleurs bien compris en proposant des supports pour graphistes au format PSD, Visio, Fireworks etc.

Feuilles de dessin pour 960 Grid System

Conclusion

Quoiqu’il en soit, les frameworks CSS sont à mon avis promis à un bel avenir dès lors que les critères d’industrialisation auront débarqué au sein des agences Web.

Aujourd’hui une petite agence a tout à gagner à maîtriser de tels outils et à annoncer qu’elle développera mieux, plus vite et moins cher. Le prix ne fait pas tout : ce sont les outils et la qualité du développement. Tous les frameworks cités sont également des logiciels libres.

J’espère que cet aperçu rapide aura ouvert les yeux à certains d’entre vous. Je suis preneur de vos retours, surtout en entreprise. Ça vaut également pour celles et ceux qui ne sont toujours pas convaincu de l’intérêt des frameworks CSS

Remarque : il y avait 2 ateliers complémentaires à Paris-Web :

• Optimiser ses CSS
• Cascade et héritage : concevoir, organiser, optimiser et maintenir ses feuilles de style

J’ai publié il y a quelques semaines un widget Jaiku dans l’écosystème Netvibes. Autrement dit, on peut désormais interagir avec le sous-employé Jaiku depuis son compte Netvibes en levant à peine le petit doigt.

La réalisation de ce widget était pour moi l’occasion de réaliser mon premier widget utilisant la plateforme UWA : un développement rendu compatible pour plusieurs plateformes dont iGoogle, MacOS X Dashboard, Windows Live etc.

Présentation du widget Jaiku pour Netvibes

Avant de rentrer dans les détails techniques, faisons ensemble un petit tour de ce qu’est capable de faire le widget Jaiku. Rien de bien méchant puisqu’il fait ce qu’on veut : lire et envoyer les messages. Faut savoir rester simple

Widget Jaiku pour Netvibes

Je ne me cacherai pas que je me suis largement inspiré du widget Twitter pour Netvibes au niveau de la présentation tout en ajoutant ma touche personnelle.

L’écran de connexion accueille directement avec des champs identifiant et mot de passe pour faciliter son utilisation. Pas besoin d’aller fouiller dans les options. Un petit confort on dira.

L’entête contient ce qu’il faut pour envoyer des messages : votre lieu de présence et le champ de saisie. Le compteur de texte se met à jour à chaque caractère saisi et surtout, votre saisie n’est pas bloquée une fois que vous atteignez la limite. Il n’y a rien de plus pénible que ça.

Le gros du morceau réside dans les onglets : pour une fois vous pouvez facilement naviguer d’une ligne de temps à une autre. Choisissez les messages de vos contacts, les vôtres (un peu narcissique non ?) ou encore les messages publics.
Les 3 onglets sont paginés à la convenance de l’utilisateur, de 1 à 20 messages par page.

J’ai ensuite agrémenté de plusieurs fonctionnalités que j’apprécie à l’usage (à vous de me dire si c’est aussi le cas) :

• possibilité de répondre à un message en pré-remplissant le champ de saisie avec ce qu’il faut (et ce que l’API Jaiku permet de faire …)
• icône signalant l’origine des messages affichés (flux RSS, Twitter, Last.fm etc.)
• filtrage de ses propres messages : vos messages n’apparaîtront pas dans la ligne de temps des contacts (ce qui en soit n’est pas plus mal)
• formattage des messages avec une meilleure reconnaissance de URL que le widget Twitter et surtout, une reconnaissance des noms d’utilisateurs (@utilisateur) et des noms de canaux (#canal) … vous permettant de leur répondre en cliquant sur leur nom

Il resterait encore pas mal de choses à faire mais on arrive malheureusement assez rapidement aux limites des 2 services.

L’API Jaiku

L’API Jaiku est très bien mais un peu chiche en services.

Le nombre de flux en récupération est suffisant : contacts, messages, informations personnelles.
En revanche les méthodes d’envoi sont limitées et pour cause, il n’y en a qu’une : envoyer un message.

Il ne manque pas grand chose pour qu’on puisse tout faire :

• obtention de la liste des icônes personnalisées
• préciser à quel message on adresse une réponse (pour éviter de casser les discussions)
• une gestion de messages privés (et les flux qui vont bien)
• une API qui ne souffre pas d’autant de délai … parfois il faut attendre 3 heures avant d’avoir un flux actualisé. Pas pratique pour de la messagerie en temps quasi-réel

Ces demandes ont été faites mais bon, il faudra attendre la relance de Jaiku avec Google App Engine … très bientôt visiblement.

Et du côté de Netvibes ?

Le développement du widget repose sur l’API UWA de Netvibes et donc par conséquent, c’est du développement 99% JavaScript.

Heureusement tout n’est pas à faire puisqu’UWA fournit une base d’outils et quelques fonctionnalités natives comme la pagination ou les onglets.

Quels avantages à utiliser Netvibes UWA ?

La spécification UWA permet donc à partir d’un développement unique de le porter sur d’autres plateformes de blogs en un minimum d’efforts (très souvent aucun). Il faut savoir qu’à chaque plateforme de widget il y a une manière de développer différente.

Alors plutôt que de parier sur un cheval, avec UWA, on peut parier sur tous. Et ne faire qu’un seul développement.

Le développement d’un widget aboutit très généralement à l’ajout dans l’écosystème Netvibes. Le widget se retrouve ainsi à la portée de toutes les pages de démarrage par le biais de son moteur de recherche intégré.

Côté développement, tout reste globalement simple quand on veut faire du simple.

Mais quelle galère à développer avec Netvibes UWA …

En revanche ça devient beaucoup moins drôle quand on tombe sur des besoins mal couverts par la documentation.
Et quand je dis mal couvert, ça inclut :

• pas de documentation du tout
• une documentation partielle et pas suffisamment verbeuse (genre pour les onglets et la pagination)
• une documentation obsolète et pas recommandée de leur propre aveu (le stockage des mots de passe)

L’adoption d’un service et sa qualité se jugent à mon avis par sa documentation. Certes des efforts sont faits mais leur API deviendra crédible et fiable le jour où elle sera à jour et complète.

En plus de ça, certaines fonctionnalités sont elles aussi incomplètes.

Au hasard, le processus de l10n : à implémenter soi-même et encore, il ne pourra pas couvrir tous les besoins comme les préférences. C’est d’autant plus dommage que leur système est particulièrement au point pour l’interface traduite en une dizaine de langues.
Mais pas les widgets …

Toute à l’heure j’évoquais les mots de passe. Il y a bien un mécanisme qui permet de les stocker mais il agit comme il veut : on ne peut stocker qu’un mot de passe par widget et surtout, on ne peut pas l’utiliser autrement que dans le cas d’une identification HTTP.
Autrement dit, le stockage d’un clé d’API se fera dans un champ texte standard.

Ça ne serait pas gênant si la plupart des widgets étaient exécutés dans une iframe et que cette dite iframe embarquait dans l’URL toutes les préférences enregistrées. Donc votre clé d’API.
Pourquoi c’est gênant ? Car il y a un mécanisme inhérent à tout navigateur Web qui s’appelle le Referrer. En clair, quand vous affichez une page, votre navigateur envoie l’adresse de la page appelante.
Je me passerai du dessin …

Enfin, et pour terminer sur une note un peu moins noire, l’environnement de développement est un superbe outil pour tester son widget de manière indépendante. C’est à dire sans se connecter sur netvibes.com.
Enfin là où le bas blesse c’est que les comportements et la présentation sont différents entre l’environnement de développement et Netvibes.

Ce qui sous-entend des bugs présents en développement et pas en production, la gestion des mots de passe qui diffère en développement de la production et du paramétrage spécifique pas documenté.

Proxy local pour widget Netvibes

Le proxy de développement Netvibes indiqué dans la FAQ est fonctionnel mais trop minimaliste. On peut en effet récupérer les données mais dès qu’il s’agit d’en envoyer, c’est cuit.

J’ai donc adapté le proxy du Yahoo! Developer Network à mes besoins en ajoutant plusieurs fonctionnalités :

• mise en cache des requêtes GET pour accélérer les chargements de page et éviter de cramer trop de requête auprès de fournisseurs les limitant (qui a dit Twitter ?)
• transmission des données POST ; c’est ce qu’il manquait le plus à la version fournie par Netvibes
• compatible texte/JSON/XML ; le proxy renvoie les bonnes entêtes en fonction de la demande

<?php
define('CACHE_TTL', is_int($_GET['cache']) ? $_GET['cache'] : 3600);
define('CACHE_FOLDER', dirname(__FILE__).'/cache');
//
$session = curl_init($_GET['url']);
// If it's a POST, put the POST data in the body
if (isset($_POST) && !empty($_POST))
{
  $postvars = '';
  while ($element = current($_POST))
  {
    $postvars .= key($_POST).'='.$element.'&';
    next($_POST);
  }
  curl_setopt ($session, CURLOPT_POST, true);
  curl_setopt ($session, CURLOPT_POSTFIELDS, $postvars);
}
// Play with some cache
$md5sign = md5($_GET['url'].$postvars);
$md5file = CACHE_FOLDER.'/'.$md5sign;
/*
 * Read cache
 */
if (file_exists($md5file) && filemtime($md5file)+CACHE_TTL > time())
{
  curl_close($session);
  send_headers_content_type($_GET['type']);
  readfile($md5file);
  exit();
}
// Don't return HTTP headers. Do return the contents of the call
curl_setopt($session, CURLOPT_HEADER, false);
curl_setopt($session, CURLOPT_RETURNTRANSFER, true);
// Make the call
$output = curl_exec($session);
$fp = fopen($md5file, "wb+");
fwrite($fp, $output);
fclose($fp);
send_headers_content_type($_GET['type']);
echo $output;
curl_close($session);
/*
 * Functions
 */
function send_headers_content_type($type)
{
  // Set the Content-Type appropriately
  switch ($type)
  {
    case 'text':
    default:
      header("Content-Type: text/plain");
    break;
    case 'xml':
      header("Content-Type: text/xml");
    break;
    case 'json':
      header('Content-Type: text/x-json');
    break;
  }
}
?>

En revanche, je serais vous, j’éviterais de m’en servir publiquement car il n’y a aucune vérification de sécurité donc à moins que vous ayiez envie de servir de relais à spam, le mieux est de n’utiliser ce proxy que sur une instance locale ou bien de davantage le blinder.

Conclusion

On arrive désormais au terme de ce billet fleuve

Quoique je puisse en dire, Netvibes UWA est quand même fort sympathique et permet d’aboutir à des temps de développement assez courts une fois la majorité des problèmés rencontrés. Nul doute que votre premier développement sera le plus compliqué. Surtout si comme moi vous avez envie de tout utiliser : pagination, onglets et AJAX à droite à gauche.

Dans tous les cas, une bonne conception de l’application vous sauvera la mise et évitera trop de réécriture de code.
L’implémentation de la pagination et des onglets est particulièrement douloureuse si vous n’utilisez pas de programmation objet. Soyez-en avertis.

Je me suis personnellement bien amusé à développer en utilisant UWA et en jouant avec l’API Jaiku. Cette dernière met vraiment l’accent sur le JSON ce qui est très pratique pour manipuler des données distantes de manière minimaliste.

Une fois que ces 2 plateformes arriveront à maturité, il y aura de quoi faire d’encore plus belles applications.

N’hésitez pas à utiliser Jaiku sur Netvibes, à me laisser vos remarques et à partager votre expérience de développement de widgets si le cœur vous en dit

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.

Joie : je fais maintenant partie de Planète Accessibilité en plus de Planet Libre. C’est l’occasion pour ce premier article dédié d’allier à la fois logiciels libres et accessibilité pour le plus grand bien du Web

Le but de cette explication sera de développer la méthode et le raisonnement pour mettre en place un menu en rollover accessible. La difficulté tient essentiellement au fait que tout élément masqué par le biais des CSS est masqué pour de nombreux clients Web.

Nous verrons aussi pourquoi il est important de dissocier la présentation et les artifices graphiques grâce à une dégradation propre du JavaScript. Nous utiliserons pour cela jQuery, ma librairie JavaScript favorite.

Buts et objectifs de l’exercice

J’ai eu besoin d’appliquer cette technique sur le site Emu Nova. Je souhaitais plusieurs choses :

• disposer d’un menu en rollover en haut de page (facilite la navigation sur toutes les pages)
• placer le contenu avant les menus dans le flux HTML de la page (améliore le référencement)
• une navigation possible sans JavaScript (pour cause de bug ou autre)

Autrement dis, j’ai besoin d’un contenu en fin de flux mais visible avant tout le reste. J’ai opté pour la solution JavaScript pour éviter un positionnement absolu pénible à gérer (pour cause de conteneur centré) mais aussi pour respecter le colonnage de Blueprint (puis toutes façons j’ai raison )

En une image, cela se résume ainsi :

Nous allons aborder les 3 phases de ce tracé de flèche :

1. la construction du menu (la zone verte)
2. le déplacement du contenu (la flèche)
3. la construction de notre nouveau menu (la zone bleue)

Étape 1 : construire le menu en HTML

C’est l’étape essentielle. De sa structure dépend le reste de l’application. On doit d’abord penser à présenter le contenu de manière dégradée. C’est ainsi que le verront les utilisateur et c’est important de penser d’abord au pire des cas avant de mettre en place les paillettes et les artifices.

Cette structure est représentée ainsi en HTML :

<div id="contenu-secondaire">
  <ul id="navigation">
    <li class="first column span-6">
      <h2>Actualités</h2>
      <ul>
        <li><a href="...">Actualités</a></li>
        <li><a href="...">Newsletter</a></li>
        <li><a href="...">Flux RSS</a></li>
        <li><a href="...">Twitter</a></li>
        <li><a href="...">Réactions à chaud</a></li>
      </ul>
    </li>
    <li class="column span-6">
      <h2>Émulation</h2>
      <ul>
        <li><a href="...">Émulation</a></li>
        <li><a href="...">Tutoriaux</a></li>
        <li><a href="...">Foire aux Questions</a></li>
      </ul>
    </li>
  </ul>
</div>

Cette version est volontairement tronquée pour faciliter sa lecture.
L’idée générale de tout ça c’est de transporter directement la liste #navigation en dehors de son conteneur, #extra-content. C’est en effet plus rapide et plus performant de transporter une partie du DOM dans un autre endroit que de la recréer séquentiellement.

Ça aura également l’avantage de limiter au maximum le travail à effectuer en JavaScript par derrière. On notera que jusqu’à présent, on n’a pas encore touché à jQuery.

Avec cette structure, on peut dores et déjà deviner que les <ul> de second niveau seront masqués et affichés à la demande.

Étape 2 : préparer le menu HTML

La deuxième reste assez simple : on transporte #navigation dans son nouveau conteneur (déjà existant) : #welcome-bar.

Pour éviter tout aléas graphique, l’idéal est de masquer tout ce qu’on ne veut pas voir maintenant. Nous rentrons maintenant dans la partie pure JavaScript.

Pour atteindre ce résultat, on pourrait envisager le code suivant :

(function($){
  $(function(){
    /*
     * Étape 2 : préparation du menu
     */
    $('#navigation > li > ul').hide();
    $('#navigation').appendTo('#welcome-bar');
  });
})(jQuery);

En soi, ce n’est pas excessif du tout :

1. on masque tous les sous-menus
2. on transporte le contenu de #navigation dans #welcome-bar

Tout le travail se situait dans la réflexion il faut croire

Étape 3 : assigner les évènements

Maintenant le plus dur c’est de donner vie à tout ça. C’est bien beau d’avoir des menus mais encore faut-il les animer. Là encore nous avons plusieurs contraintes à subir :

• les titres doivent être cliquables. Certaines personnes cliqueront en effet avant de réaliser qu’il y a un menu déroulant. Par principe, on prendre le premier lien de la liste et on l’assignera au titre correspondant ;
• le menu doit se dérouler lors du survol du titre …
• mais il ne doit pas se masquer tant qu’on n’a pas quitté le titre NI la liste déroulante

La difficulté tient à ces 2 dernières contraintes. On pourrait tout d’abord penser à l’utilisation des évènements mouseover et mouseout MAIS, parce qu’il y a bien un mais, mouseout est un peu capricieux.

Si on imagine un mouseover directement sur li.column, le problème c’est que survoler un élément comme Actualités ou Newsletter activera le mouseover de ces derniers … et désactivera, un temps minime certes, le survol de li.column. Autrement dit le menu se repliera alors qu’on tentera de l’utiliser.

Heureusement pour nous, jQuery a introduit les évènements mouseenter et mouseleave (présents dans Internet Explorer depuis des lustres, c’est bien le seul avantage de cette atrocité) depuis la version 1.2.2. Ces évènements correspondent exactement à ce que l’on souhaite : maintenir une zone survolée malgré le survol de ses enfants.
Tout est histoire de couches

Côté code, ça se complique :

(function($){
  $(function(){
    /*
     * Étape 3 : assignation des évènements et transformation
     */
    $('#navigation > li')
      .each(function(){
        var title = $('h2:first', this);
        var href = $('a:first', this).clone();
        href.text(title.text()).wrapInner('<span></span>');
        title.html(href);
       })
      .find('h2 > a').bind('mouseenter', function(){
        $(this).parents('li.column').find('> ul').slideDown('fast');
      }).end()
      .bind('mouseleave', function(){
        $('> ul', this).slideUp();
      });
  });
})(jQuery);

Plusieurs remarques sur ce code :

• j’utilise les chaînes de jQuery pour gagner du temps et reparcourir des tableaux déjà connus (le sélecteur n’est pas réexécuté)
• j’utilise également la méthode end() pour revenir au précédent état du sélecteur. Très pratique pour naviguer dans un jeu d’éléments et gagner en performances

Et pour les explications :

1. Pour chaque élément de liste
   1. on met de côté le titre de la liste
   2. on clone le premier élément du sous-menu
   3. on modifie le libellé du lien du clone
   4. on remplace le titre par le code HTML du clone
2. Pour ces liens hypertextes nouvellement créés (plus faciles à styler sans JS au rollover), on leur demande de déplier le sous-menu voisin
3. Ce sous-menu ne sera replié que lorsqu’on quittera le li.column

Conclusion

La mise en œuvre de ce menu est relativement aisée et surtout, suffisamment souple pour que vous puissiez l’adapter à vos besoins.
Dans tous les cas on remarquera que les clés de la réussite sont :

• un code HTML propre (facile les sélections JS et le stylage CSS)
• une évolution d’une base sans artifices vers une interface améliorée en JavaScript
• un code simple, facilement maintenable et adaptable

Ceci n’est qu’un exemple où le JavaScript peut servir à conserver des interfaces accessibles tout en augmentant leur utilisabilité. Qui a dit que le JavaScript c’était nul ?

Le seul reproche que l’on peut faire à ce menu accessible c’est le manque de navigation au clavier. L’idéal serait de pouvoir naviguer dans le choix des menus entièrement avec les flèches de son clavier.
Rendez-vous dans un autre billet pour ce point ?

Mon premier grand fait d’armes sur le Web aura été le lancement d’Emu Nova en octobre 2002. Les grandes lignes du site ont toujours été jeux vidéo rétro, émulation et aide aux utilisateurs.
J’ai ainsi décidé d’offrir une nouvelle garde-robe à Emu Nova le 1^er avril 2008 pour renouveler une interface vieille de 3 ans. 3 ans où le contenu s’est accumulé, les menus se sont désordonnés et la navigation s’est complexifiée.

Aujourd’hui je vous dévoile les tenants et aboutissants d’un travail de réflexion mené sur plusieurs mois tant en terme d’ergonomie, d’accessibilité et de respect des standards du Web.
Où l’on parlera de jQuery, Blueprint et d’interface orientée utilisateur.

Objectifs de la refonte

Comme je le disais, la plus grosse critique se tournait vers l’agencement du site : les menus étaient séparés en 2 et étaient peu visible.

Pire, il y avait tellement de contenu accumulé qu’au final l’utilisateur était obligé de scroller au mois une fois pour atteindre le contenu demandé.
J’ai donc opté pour un choix radical : tout reprendre de la feuille blanche et ne tenter de conserver que l’identité du site au travers de ses couleurs et de son logo.

Plusieurs objectifs ont émergé en griffonnant au fur et à mesure l’interface sur une feuille de papier :

• offrir une page d’accueil qui ne fasse pas doublon avec le reste du site
• offrir une page d’accueil mettant en avant du contenu pour inciter à visiter le site en profondeur (textes courts, images)
• davantage lier les forums et le site pour susciter l’interaction avec l’internaute
• offrir une interface lisible dont les contenus sont aisément identifiables sans effort cognitif
• offrir du contenu annexe en pied de page : je suis désormais intimement convaincu que le pied de page est le meilleur moyen de fidéliser un vagabond curieux qui n’a pas tiré satisfaction de la première lecture
• proposer un site conforme au standard XHTML 1 Strict en bannissant les mises en forme en tableau, entre autre

On le voit, les objectifs de surface sont résolument tournés vers l’interface utilisateur. Derrière il y avait également des objectifs de simplification et de mutualisation du code avec l’interface d’administration.

Choix technologiques

Plutôt que de réinventer la roue, j’ai souhaité utiliser les applications en qui je crois le plus. Je peux compter dessus tout en gagnant du temps. N’est-ce pas là l’essentiel ?

JavaScript : jQuery

Je suis un féroce utilisateur de jQuery que j’adore pour sa souplesse d’utilisation et sa syntaxe vraiment plaisante. Elle dépassera, à mon avis, largement le vieillissant couple Prototype/Scriptaculous d’ici la fin de l’année 2008.

jQuery sert de base à tout le code JavaScript :

• altérer l’interface pour construire le menu de navigation principal : sans JavaScript ça marche, avec c’est encore mieux !
• affichage des messages d’alertes pour les formulaires incomplets : pas de popup mais un message inséré à même la page
• ouverture des liens externes dans une nouvelle fenêtre
• diaporama de photos avec Lightbox ; personnalisé pour l’occasion afin de bénéficier de légendes plus détaillées

Il ne reste donc plus en tout et pour tout que 2 popup/alert/confirm obligeant à un affreux et désobligeant clic.

CSS : Blueprint

Blueprint est la librairie CSS la plus proche du Saint-Graal : facile d’utilisation et très puissante. Mon seul regret à l’heure actuelle est qu’elle ne fonctionne qu’en largeur fixe. Mais dans cette configuration elle joue parfaitement son rôle :

• construction de colonnes les doigts dans le nez
• rythme vertical respecté pour un confort de lecture accru
• construction typographique prémachée
• correctifs liés à Internet Explorer déjà intégrés

Une bonne présentation c’est une présentation sans contrainte : pas de couleur primaire, pas de difficulté à lire, pas de texte trop petit.

Le premier lecteur qui plisse les yeux c’est qu’il aura oublié d’allumer son écran

Transparence d’images : GIF ou PNG ?

Quitte à trancher dans le vif, le GIF a été abandonné au profit du PNG pour le logo.

Pour rappel, si la transparence est possible avec le GIF, il lui manque la couche alpha qui permet de mélanger transparence et couleur. Avec le PNG on peut frimer avec des contours ombrés et des reflets qui fusionnent parfaitement avec le décors.

Alors où est le problème ? Le sempiternel Internet Explorer 6 qui commence même à chauffer les oreilles à Microsoft. À tel point qu’il souhaite s’en débarrasser au plus tôt en poussant Internet Explorer 7, y compris pour les non-possesseurs du Service Pack 2 de Windows XP.
La transparence est affichée comme du gris. Magnifique. Sauf en utilisant jQuery.ifixpng, entre autre.

Emu Nova : carte de chaleurs, avant et après

Voici une comparaison des cartes de chaleur à 6 mois d’intervalle.

On remarque aisément que sur la précédente version les clics sont concentrés, notamment sur la partie haute de la page. Les quelques listes existantes mettent peu en valeur le contenu et de ce fait ne sont pas cliquées.

Sur la nouvelle version les clics semblent moins concentrés mais touchent globalement toute la page, exception faite des vignettes en image. Un problème ? Non pas vraiment puisqu’elles sont rafraîchies toutes les 3 heures ce qui fausse le calcul (qui s’étale sur 1 journée).

Notez aussi les clics en bas de page : le pied de page compte. Qui n’a pas eu envie qu’on lui suggère du contenu à lire une fois sa lecture terminée ?

Conclusion

Il n’est pas aisé de refondre une interface, surtout quand il y a derrière toute une troupe d’utilisateurs attachés à ses habitudes (ce qu’on peut comprendre).

Si on temporise les différentes phases, voici ce que cela donne :

• analyse des besoins, ressenti de la situation : plusieurs mois
• dessin de la nouvelle interface sur papier : plusieurs jours
• intégration HTML : plusieurs heures
• refonte du code : plusieurs jours
• corrections de bugs : plusieurs heures
• premières critiques : quelques minutes

Pas étonnant que ma régularité sur ce blog en aie pris un coup

Nous avions dressé un panorama des microformats dans un précédent article intitulé « microformats : republier et donner du sens aux contenus ». Nous avions notamment conclu que leur intégration était rapide, peu coûteuse et surtout bénéfique tant pour le visiteur que pour la visibilité du contenu.

Nous nous intéresserons cette fois-ci à une partie plus pratique des microformats : leur intégration. Toutefois ce rapide apprentissage sera didactique puisque nous apprendrons à identifier visuellement quels contenus d’une page peuvent être microformatés mais aussi comment microformater du code HTML déjà existant.

Des sites déjà microformatés

Intéressons-nous toutefois à des sites ayant déjà microformaté leurs contenus. Nous pourrons ainsi éveiller notre curiosité et préparer le travail de réflexion de la prochaine étape.

Exemple avec Google Maps :

Google Maps est un service de recherche cartographique accessible via un simple navigateur Web. Le moteur donne un accès à des recherches de lieux, de calculs d’itinéraires mais aussi d’emplacement d’entreprises.

Le support des microformats sur Google Maps est relativement léger mais suffisant pour être utile.
Contrairement à ce que l’on aurait pu penser, Google n’a pas intégré le microformat geo pour exporter les coordonnées GPS d’un point. La société s’est concentrée sur les données personnelles au moyen de deux microformats combinés :

• microformat hCard (correspond à la réunion des encadrés bleu et vert)
• microformat adr (correspond à l’encadré vert uniquement)

Cette combinaison facilite l’extraction des adresse postales et des entités (individus ou entreprises).

Exemple avec Yahoo ! Upcoming :

Yahoo ! Upcoming est un service gratuit cataloguant tous les évènements à venir par pays, ville, date et même par catégories (cinéma, concerts, expositions etc.).

Le microformat par excellence à adopter était bien évidemment le microformat hCalendar. Chaque occurence microformatée est représentée par un rectangle vert et peut contenir ces différents attributs, entre autre :

• date de début de l’évènement
• date de fin de l’évènement
• titre de l’évènement
• description de l’évènement
• le lieu de l’évènement (sous forme d’adresse complète ou pas)
• une URL menant à un descriptif plus approfondi de l’évènement

Ce microformatage permet d’aller au-delà d’une lecture classique puisque de manière simple, elle permet au visiteur de récupérer les évènements qui l’intéresse pour les ajouter à son gestionnaire de temps favoris, qu’il soit logiciel ou en ligne.

Identifier visuellement les microformats à intégrer

Identifier des microformats déjà implémenté est assez simple avec les outils adéquats. En revanche pour décider de microformater du contenu, deux outils sont indispensables :

• la documentation des microformats pour savoir quoi implémenter
• un peu de jugeotte pour savoir comment implémenter

Avec un peu de pratique et de connaissance des différents microformats, il ne faut pas plus de 5 à 10 minutes pour identifier les contenus microformatables. La difficulté d’intégration dépendra uniquement de la structure technique affichant les données : plus elle sera complexe, plus le microformatage pourra être long … au même titre que toute autre modification basique.

Exemple avec Wikia Search :

Wikia Search est un moteur de recherche lancé au tout début de l’année 2008 par un des fondateurs de l’encyclopédie en ligne Wikipédia. Ce moteur en reprend d’ailleurs le principe du wiki pour contribuer à l’élaboration et la notation de meilleurs résultats.

Il est d’ailleurs étonnant de voir qu’aucun microformat ne soit présent malgré de tels objectifs. La capture d’écran ci-dessus découpe la page en 3 zones microformatables distinctes :

1. le lien sur logo aurait pu se voir agrémenter d’un rel-home pour signifier un retour vers la page d’accueil ;
2. les résultats auraient pu quant à eux embarquer :
   • le microformat hAtom pour faciliter la syndication de contenu et l’extraction des résultats.
   • le microformat hReview ou VoteLinks sur les encadrés orangés identifiant les zones de votes.
3. enfin le microformat hCard aurait été le bienvenu sur la liste des résultats correspond à des personnes.

On peut constater que plus il y a d’emplacement représentant des contenus différents sur une page, plus on a de chances qu’un microformat corresponde.

Exemple avec Clever Age :

J’ai dénombré pas moins de 5 zones pouvant accueillir des microformats :

1. les dernières actualités pourraient utiliser le microformat hAtom. Un flux RSS est déjà disponible sur la page mais ce serait offrir un chemin de traverse pour les visiteurs et les moteurs d’indexation ;
2. le microformat hCalendar aiderait à la réutilisation des données dans les gestionnaires de temps. Imaginez un chef d’entreprise affairé désireux de transmettre à ses collaborateurs une ressource contenant toutes les informations de leur future formation : peu d’effort et un gain de communication ;
3. ajouter facilement Clever Age dans votre carnet de contacts et de prestataires serait également facilité si le microformat hCard redistribuait le nom et les moyens de contact de la société ;
4. en complément au moyen de contact, l’emplacement géographique des agences serait à portée de clic avec le microformat geo. Après tout, Google Maps proposera peut-être un jour d’importer des URL microformatée en plus des fichiers KMZ (Google Earth) ;
5. enfin, le microformatage de la dernière partie dépend de ce qu’on aimerait redistribuer :
   • le microformat hAtom pour offrir 3 flux de syndication mais le peu d’éléments (2 à chaque fois) tende à infirmer la pertinence de ce microformat dans le cas présent ;
   • le microformat XOXO est adapté à décrire des types de contenus embarqués dans une page ; ici des flux RSS. Il serait à placer sur chaque lien pointant vers les flux RSS ;
   • le microformat Xfolk est adapté aux collections d’URL plus communément appelés « favoris » ou « marque-pages »

Avec ce dernier exemple, nous venons de voir que le microformatage était facilement adaptable à un site Web de société. Dans ce cas précis, il y a énormément de contenu republiable mais pas systématiquement de manière pertinente.

Intégrer les microformats dans du (X)HTML

Les précédents exemples, sur de l’existant et ce qui pourrait exister, avaient pour but de former notre esprit à reconnaitre des zones susceptibles d’être microformatées.

La difficulté de l’exercice est d’ajouter du balisage sans altérer la présentation actuelle. Je traiterai du site de Clever Age dont nous avons parlé précédemment.

Microformater des données d’entités

Voici le code de départ, repris tel quel :

Clever Age - Siège social : 01.53.34.66.10

Comme nous avons pu le voir, la gestion d’identités passe par le microformat hCard :

<span class="vcard">
<span class="fn org">Clever Age</span> - Siège social : <span class="tel"><span class="value">01.53.34.66.10</span></span>
</span>

La balise span est une balise en-ligne neutre au sens où … n’en a pas justement. div est son pendant de type bloc.

Microformater des ressources syndiquées
Voici le code de départ (simplifié par rapport à l’exemple afin de réduire le code à lire) :

<dl>
<dt><a href="/rss/blog.xml">derniers billets du blog</a></dt>
<dd>...</dd>
<dt><a href="/rss/publications.xml">dernières publications</a></dt>
<dd>...</dd>
<dt><a href="/rss/cleverlink.xml">derniers Clever Links</a></dt>
<dd>...</dd>
</dl>

Le microformat XOXO nous permet de définir une liste d’éléments en fonction des modules XHTML :

<dl class="xoxo">
<dt><a href="/rss/blog.xml" rel="feed" type="text/xml">derniers billets du blog</a></dt>
<dd>...</dd>
<dt><a href="/rss/publications.xml" rel="feed" type="text/xml">dernières publications</a></dt>
<dd>...</dd>
<dt><a href="/rss/cleverlink.xml" rel="feed" type="text/xml">derniers Clever Links</a></dt>
<dd>...</dd>
</dl>

Le microformatage a été rendu possible uniquement en utilisant de manière standardisée des attributs définis par XHTML.
Malgré cet aspect de simplicité, il faut s’investir dans la compréhension des spécifications XHTML. Ce n’est un problème que pour les personnes produisant du code XHTML non-conforme.

Valider l’intégration des microformats

La question qui se pose toujours après avoir produit un code quelconque c’est comment le tester ? Il existe à l’heure actuelle trois outils gratuits :

• la relecture manuelle avec la documentation à côté
• l’extension Operator pour Firefox. Elle n’est toutefois pas complète et ne permettra pas de tester tous les microformats existants. Cette extension propose dans ses options un mode débogage très utile ;
• le service en ligne Optimus. Ce service polyvalent est capable de retourner sous forme de flux XML ou JSON les microformats présents dans une page Web. Il propose également un validateur, toujours pour une page Web, décrivant les erreurs de microformatage.

Conclusion

Il est difficile d’infuser en un article la manière de microformater du contenu. Fort heureusement la documentation des microformats abonde d’exemples en traitant des cas de figure concrets. Les spécifications restent là pour savoir quels sont les attributs, obligatoires ou pas.

De manière générale l’intégration des microformats est relativement aisée mais il existe 3 difficultés principales à l’intégration des microformats :

• difficultés liées à la plate-forme technique d’intégration ;
• difficultés liées à un manque de données. Certaines spécifications exigent la présence de données particulières que l’on n’a pas ou que l’on ne peut afficher, rendant invalide le contenu ;
• difficultés liées à un code HTML désorganisé. L’abus de div et le non-respect de hiérarchie est une source de problèmes et si elle rend pénible l’intégration des microformats, elle pose problème à la maintenance du code et des CSS.

Intégrer les microformats c’est finalement mener une réflexion sur la qualité du code produit. Un bon code, respectueux des standards et sémantique sera pérenne dans le temps, facilitera le microformatage et aura davantage de chances d’être accessible.

J’ai tenu ma première conférence vendredi 29 février 2008 à l’occasion de BlogCamp Bordeaux #3. Petite conférence car il n’y avait « qu’une trentaine » de personnes face à moi. Une fréquentation plus qu’honorable si on tient compte de la jeunesse de BlogCamp France, à savoir 3 mois.

C’est l’occasion pour moi d’aborder cette session par un angle un peu différent, en parlant notamment de l’aspect présentation : où, quand, comment et surtout combien de temps. Ce sera un bon complément du résumé officiel et du wiki BlogCamp Bordeaux #3.

L’atelier BlogCamp Bordeaux #3

Cette présentation m’a pris à peu près 8h de travail, en comptant le temps de recherche de la mise en page. On utilisait en effet pour la première fois un modèle commun. Ces 8 heures ont été réparties de la sorte :

• 2 heures de recherche « artistique » et de manipulations d’OpenOffice Impress infructueuses
• 3 heures consacrées aux grosses questions (au nombre de 2)
• 3 heures consacrées aux petites questions (au nombre de 3)

8 heures de préparation pour … 45 minutes de présentation. J’avais une crainte là-dessus mais si la présentation avait duré 5 à 10 minutes de moins ça aurait été mieux. C’est noté pour la prochaine fois
Comme toujours, une présentation en direct est autrement plus parlante puisque les slides ne sont qu’un support à la discussion.

L’exercice consistait à répondre à des questions posées au préalable : de la gestion générale à du très précis ciblant la présentation d’un blog particulier. L’occasion de vulgariser au maximum des concepts tels que les sauvegardes, le référencement et les feuilles de style.

Les faits marquants de BlogCamp Bordeaux #3

Outre la razzia sur les boissons (après 1h il n’y avait déjà plus rien à boire), j’ai noté une grande mixité des participants : étudiants, salariés, patrons … tous liés au Web … ou pas. Le dénominateur commun de toutes ces personnes était clairement la curiosité de découvrir un évènement lié au Web à Bordeaux.
C’est d’autant plus satisfaisant que ces personnes en sont reparties le sourire aux lèvres, ravies d’avoir rencontré de nouveaux contacts et constaté qu’à Bordeaux, ça bougeait enfin un peu. Une progression à suivre.

Je note aussi la présence de la « Dream Team » bordelaise avec des représentants des sociétés ADDEO, Websiteburo, Clever Age mais surtout Temesis. J’espère très sincèrement que la prochaine fois on pourra davantage discuter et échanger tous ensemble sur le Web à Bordeaux.

La rumeur du jour serait qu’un blog commun aux sociétés des TIC serait en cours de création pour diffuser de l’information liée à l’économie du Web à Bordeaux. J’espère que ça se concrétisera et contribuera à dynamiser l’économie numérique de la région.

J’y songeais mais l’article «De l’ordre, que diable !» m’a incité à m’y atteler plus tôt que prévu.
Il n’y a en effet pas de méthode universelle pour programmer les CSS mais après plusieurs années d’expérience, j’ai affiné ma réflexion que je vous livre aujourd’hui.

Où l’on parlera de présentation en 1 ligne, de CSSDoc mais aussi de folding et d’indentation. En clair, tout plein de bonnes pratiques de développement en CSS qui vous feront gagner du temps, vous éviterons de la sueur et sentent bon le travail de qualité.

Halte là et retour à la ligne !

J’ai utilisé pendant un moment la technique dite du single line CSS ; à savoir 1 ligne par déclaration.
Je n’hésiterai pas une seconde à dire que je déconseille fortement cette écriture pour les raisons suivantes :

• si on souhaite gagner de la place, il y a des compresseurs (je recommande YUI Compressor): pas la peine de réaliser ce travail nous-même ;
• l’ajout de commentaires n’en est que plus compliqué : on a tous besoin de commenter certains passages cruciaux, notamment les hacks et autres fix ;
• c’est tout bonnement illisible dès qu’on s’y replonge quelques semaines plus tard : imaginez pour quelqu’un qui n’a pas écrit le code !

Les arguments avancés pour cette technique ne tiennent pas la route : on recherche avant tout la qualité et la facilité de relecture. Les quelques kilo-octets à perdre se feront par le biais de programmes. Ça ne doit certainement pas entraver le développement.

L’auto-documentation avec la syntaxe CSSDoc

Les habitués de Java connaissent JavaDoc.
Les habitués de PHP connaissent PHPDoc.
Les habitués de JavaScript connaissent JsDoc Toolkit (dérivé de JsDoc).

Il était donc tout naturel que cette syntaxe de commentaires et d’auto-documentation soit utilisable en CSS avec CSSDoc. Il n’y a pas d’inconvénient à l’utiliser, au contraire, que des avantages :

• la syntaxe permet d’harmoniser les commentaires sur les projets impliquant plusieurs développeurs ;
• sa syntaxe facilite la relecture puisqu’elle est connue et employée dans de nombreux langages, autres que les CSS ;
• l’auto-documentation du code c’est faciliter la génération d’une documentation externe en automatisant le processus ;
• documenter en même temps que l’on écrit c’est comprendre ce que l’on fait et gagner du temps en évitant une écriture a posteriori ;

La syntaxe CSSDoc est documentée, aisément reconnaissable et est supportée par les meilleurs éditeurs CSS, dont Aptana IDE :

/**
 * @author Oncle Tom
 * @lastmodified Fev, 26 2008
 * @media print, screen
 * @site http://www.oncle-tom.net/
 */
/**
 * Redéfinition des balises HTML
 *
 * @section html
 * @todo utiliser un reset.css conforme
 */
html,
*{
  margin: 0;
  padding: 0;
}

L’organisation hiérarchique

J’ai pour habitude de travailler avec une seule feuille de style par media. Comme je travaille sur des hiérarchies thématiques, leur découpage en plusieurs fichiers ne consiste qu’à du copier/coller. On peut ainsi facilement passer d’une mono-feuille à du multi-feuilles. Je ne suis pas un fervent utilisateur de ces dernières car un code bien lisible sur une seule page n’est pas problématique.
Je ne l’emploie que pour faciliter la réutilisation des CSS sur plusieurs projets partageant la même base graphique.

Concrètement, je vais d’abord organiser ma feuille pour redéfinir les éléments HTML génériques puis créer autant de sections qu’il n’y en a sur ma page (navigation, contenu, navigation de contenu, contenus annexes etc.).
Plus je m’avancerai dans la profondeur du balisage HTML et plus j’indenterai mon code. Cette indentation fait penser à celle utilisée par le langage Python.

On pourrait résumer cette convention à ceci :

• pas de tabulation, que des espaces pour avoir le même affichage peu importe les éditeurs
• 2 espaces par tabulation
• attributs classés par ordre alphabétique (même logique pour tout le monde)
• une ligne d’espace entre les définitions ; pas de ligne entre les définitions proches/liées

C’est simple et voici un exemple de résultat :

/**
 * Redéfinition du HTML
 */
a{
  text-decoration: underline;
}
  a img{
    border: none;
  }
p{
  line-height: 1.5em;
}
  p img{
    margin: 1.5em
  }
  p img.top{
    margin-top: 0;
  }
/**
 * Contenu
 */
#main-content{
  clear: both;
  width: 100%;
}
  /**
   * Articles
   */
  #articles{
    margin-bottom: 2em;
  }
    #articles h2{
      font-size: 1.5em;
      font-weight: bold;
    }

Les mieux organisés d’entre vous ajouteront un tri par fréquence d’utilisation afin d’optimiser les va-et-vient : on met en haut ce qu’on est susceptible de modifier le plus souvent, en bas ce à quoi on touchera rarement. Je ne vais pas jusque là mais ça reste envisageable, pertinent et surtout adapté aux plus chevronnés de l’optimisation.

Autres conseils et astuces

Utilisation de raccourcis

Les aficionados de l’optimisation et du gain de temps apprécieront cette méthode, s’ils ne l’utilisent pas déjà. J’ai pour habitude de placer des raccourcis dans mes sections pour faciliter l’utilisation d’une recherche via le raccourci clavier Control+F.
Je préfixe chaque raccourci d’un symbole = :

/**
 * Liens d'évitement
 * =evitement
 */

Je trouve cette méthode très pratique pour atteindre des portions de code. On évite ainsi un appel à la touche Alt Gr pour appuyer sur le # d’un ID (pour peu que l’on n’ait que des ID en tant que sections). On évite aussi les collisions de nom ou les recherches infructueuses pour cause de changement de nom de classes ou d’ID.

De la sémantique, que diable !

Je suis particulièrement attaché à cette bonne pratique d’autant plus qu’elle ne tombe pas forcément sous le sens de tout le monde : nommez vos ID et classes en fonction de leur signification, pas de leur représentation. C’est la suite logique de la séparation fond et forme du HTML et des CSS.

Mauvaise sémantique :

.rouge{
  color: red;
}
#sidebar{
  /* ... */
}
#top-links{
  /* ... */
}

Bonne/meilleure sémantique :

.important{
  color: red;
}
#alternate-navigation{
  /* ... */
}
#main-links{
  /* ... */
}

#sidebar pourra être renommé différemment selon son contenu, selon que l’encart contienne des éléments de navigation supplémentaires, des informations utilisateur (#user-content) ou encore des widgets (#widgets).
En conservant votre HTML intact et en jouant sur les CSS, la #sidebar peut en effet se retrouver tout en bas, à l’horizontale. Aurez-vous toujours envie de l’appeler pareil ? Pas forcément. Un bon nommage est un nommage qui se conserve peu importe l’aspect de la présentation.

Du choix de la langue

Cette bonne pratique s’applique aussi bien aux CSS qu’à d’autres langages. Il faut partir du principe qu’il ne faut pas mélanger les langues dans le code, tant dans les commentaires que dans le nommage des classes et ID. Choisissez-une langue et restez avec.
Certaines contraintes peuvent faciliter le choix de la langue : le travail avec une équipe internationale ou la redistribution du code. Dans ce cas l’anglais sera à 99% votre langue de prédilection.

Il n’y a pas de choix idéal : certains préféreront le tout français, d’autres le tout anglais. L’essentiel est que ce choix soit motivé par des arguments objectifs, pas une préférence personnelle.

Recours au folding

J’en parle succintement mais le folding consiste à utiliser votre éditeur CSS pour masquer une partie de code. Eclipse propose par exemple de masquer toutes les définitions et tous les commentaires : leur contenu n’est révélé qu’en le dépliant.

Je ne suis pas un fervent utilisateur de cette pratique bien que je respecte son utilisation. Je trouve qu’en utilisation les précédentes astuces (hiérarchie + recherche) on s’y retrouve très bien.

Conclusion

Ma méthodologie n’est pas parfaite, peut être perfectible et ne conviendra pas à tout le monde, par goûts ou par habitudes. Ces dernières sont cependant à combattre pour améliorer son travail. Quoi de mieux qu’un code propre, bien documenté et où l’on trouvera facilement ce que l’on cherche ?

C’est ce qui importe. Il y a autant de façons de coder qu’il n’y a de développeurs. Le tout est d’être ouvert aux améliorations possibles, aux méthodes existantes et à l’intérêt de leurs utilisations. Je trouverai peut-être cet article obsolète dans 1 an mais il aura été un point de passage.

J’espère qu’il le sera au moins en partie pour vous, développeur en herbe ou féru des pseudo-classes