Pour ma part, c’est la quatrième année consécutive où je m’y rends … et où on accepte de me voir déblatérer des sujets de plus en plus bizarre. Qu’y ai-je vu cette année ?

Gloire au petit amphitéâtre

Les double sessions sont apparues à l’origine avec une orientation décideur/technique. Aujourd’hui j’y vois davantage une découpe atypique/grand public puisque dans la pratique, la distinction se fait sur la contenance de l’amphithéâtre.

Dans ce petit amphi, on a décortiqué la base de notre travail : l’impact du webdesign dans les neurosciences et vu comment fonctionnait un navigateur, d’une requête HTTP au rendu de l’interface.
Subtilement, en deux heures, on a pu se rendre compte qu’un changement de code hexadécimal dans un fichier CSS transitait au travers de plusieurs milliers de ligne de code au sein de votre navigateur Web … mais surtout, traversait 7 zones différentes du cerveau pour provoquer une … sensation.

Sensation. Mot qui navigue lui aussi au travers de l’accessibilité, de l’ergonomie ou plus généralement, d’UX (expérience utilisateur).

De la technique au management

Le public a eu du mal à retenir un rire sarcastique, moi compris, lorsqu’Arthur Rigaud de Voyages-SNCF.com a débuté sa présentation sur l’accessibilité. Malin, il a préféré utiliser grand compte pour éviter la désertion de la salle ?

Toujours est-il qu’on a vite oublié les sarcasmes devant l’ampleur de la mission : 70 sites Internet, 450 sites Intranet et 1 mission commune, les rendre accessible. Tous ne le seront pas à la date buttoir mais l’explication dans leur démarche mérite attention.

En effet, classiquement, un expert accessibilité a été missionné pour aider les différentes équipes à rendre leurs sites accessibles. Grand bien leur en a pris, car ça s’est soldé par un échec. L’ampleur et la dureté de sa mission a certainement contribué à l’intégrisme de son application, excluant cette personne de tous les projets.

Une approche tranversale a ensuite été adoptée : communication dans les lieux communs (machine à café, affichages de communication interne), formations au personnel et surtout, une responsabilisation de différents postes, du développeur au chef de projet en passant par les graphistes.

De la brutalité isolée à la douce transversalité.

Du public au grand public

On ne parle pas de backend à Paris Web par contre on y parle Open Data !

David « Nippon » Larlet et Olivier Thereau ont présenté à la fois un panorama d’Open Data au travers des cultures, et comment la BBC s’y prenait pour utiliser Open Data avec leurs contenus et ceux issus de communautés spécialisées.

Open Data est le gros buzzword pour lequel le retour sur visibilité reste faible, en partie à cause du manque d’accompagnement, des coûts de développement et de maintenance (ben quoi, c’est de l’informatique et du temps de cerveau piqué à TF1) … et pourra-t’on constater, du manque d’outillage.

Y’a du maille pour mailler les données, car le Web sémantique c’est bien beau, mais lier des fichiers PDF entre eux, c’est priver un diabétique de son insuline en le gavant de chamallow (OK ? © Pablo).

L’atelier des bonnes idées

Samedi fût un peu plus difficile : réveil tardif suite à la retombée de pression de la veille et d’un épuisement lié au manque de sommeil. Bref, j’ai préféré rogner sur le premier atelier pour réserver mon attention au reste de la journée.

Après un énième café, la journée débute sur un sujet de typographie adressée aux développeurs. Le sujet couvrait les aspects de ce qu’on devait connaître mais après les 2 excellentes conférences de l’an dernier (macrotypographie de la page Web et typographie comme outil de design), dur dur. On repartait en tous cas avec l’idée essentielle : d’abord le contenu, ensuite le design. Couplé avec Mobile First et l’accessibilité, le lien n’en est que plus évident.

Songeant de plus en plus régulièrement à publier ce blog sous forme de contenu versionné avec git (geek), je pensais naïvement que ce serait le sujet de l’atelier Création et partage d’archives Web personnelles. La bonne surprise c’est qu’il y fût surtout question de créer des archives distribuées pour éviter les liens morts sur nos propres blogs : chaque lien externe est indexé en local pour s’y substituer en cas de disparition de la page cible respective. Ce sera à suivre sur le projet Owark.

Et le meilleur pour la fin : deux jeux sur l’itération et la communication de Pablo Pernot. J’avais déjà entendu parler du Marshmallow Challenge et ce fût l’occasion de l’expérimenter. Tout le monde (ou presque) a eu le réflexe de construire la tour la plus haute possible … et de se planter au dernier moment. Comme dans nos projets informatiques en fin de compte. Livraisons itératives vs. grosse livraison finale (qui fait mal).

Puis de tester la communication écrite (nos belles specs et cahiers des charges) vs. la communication orale. Cette dernière a donné de meilleurs résultats, en permettant d’ajuster en fonction du feedback. Ça m’a donné à réfléchir sur la capitalisation technique : travailler à 2 en même temps, pour qu’un formalise par écrit semble plus efficace qu’une seule personne, réfléchissant et écrivant. Et de constater une fois de plus la difficulté à imposer un processus formalisé à des personnes ne se sentant pas en mesure de le faire.

Des outils aux ressentis

C’est avec surprise que je suis reparti sans le boost d’énergie habituel, et sans le spleen post-évènement. Et de me rendre compte que finalement, j’ai passé tout mon temps à m’imprégner des expériences humaines exposées sur scène, ainsi que des conversations pendant les repas, apéritifs et autres diners plus ou moins informels.

J’y vois trois raisons :

1. l’expérience Sud Web a déjà regonflé le ballon il y a 6 mois ;
2. en travaillant en indépendant, je ne subis plus cette pression du boulot mal fait ou de l’incompréhension auxquelles Paris Web apporte une grande bouffée d’air frais ;
3. je n’espérais pas révolutionner ma vision des outils pour améliorer radicalement mon quotidien.

À vrai dire, ça doit bien être la première année où je me suis fichu éperdument des outils pour me focaliser totalement sur le comment et le pourquoi. Pourquoi ça foire ? Comment des hommes et femmes font réussir un projet ?

Et ma conférence ?

J’y reviens dans un prochain article pour apporter à la fois une explication à mes slides et aussi des éléments complémentaires.

D’ici là, tous mes remerciements à l’organisation impeccable de l’évènement (notamment sur l’arrivée des orateurs), à l’excellente soirée communautaire au Comptoir Général et aux personnes avec qui j’ai pu échanger, que ça soit sur ma coupe de cheveux ou sur nos vies respectives.

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

Des conférences de choix

Les thématiques abordées sont une nouvelle fois intéressantes. Si leur titre n’est pas forcément attirant, la qualité des intervenants fait qu’à n’en pas douter, on va encore en prendre plein les yeux : suffit de lire le programme.

Parmi celles qui retiennent toute mon attention :

• Intégrateurs, montez au front !
  Notamment parce que j’ai participé à l’enquête sur le dialogue entre webdesigner et intégrateur et qu’il s’agit d’une pierre angulaire de la réussite graphique d’un projet.
• Un seul Web
  Car l’an dernier j’avais été épaté par la présentation des nouveautés CSS3 de Daniel Glazman.
• CSS peut-il être orienté objet ?
  Parce que je crois beaucoup aux nouvelles méthodes de réutilisation et de conception CSS ; cette approche combinée à d’autres outils CSS est à mon avis la meilleure qui soit.
• CSS3 : Future Style Now
  Parce qu’il est toujours bon de savoir comment utiliser les technos que l’on utilisera dans pas trop longtemps.
• WCAG 2.0, Flash, PDF, Javascript et les autres sont dans un bateau
  Une bonne piqûre de rappel sur l’accessibilité et les différentes boîtes noires qui sont devenus des standards de facto.
• Les nouveaux standards du web et leur implémentation dans les navigateurs modernes
  Le titre parle de lui-même

C’est sans compter sur les ateliers techniques où là, je n’ai pas encore fait mon choix … la concurrence est rude

Atelier technique sur Gears

Il y a toutefois un atelier où je suis sûr d’être présent, c’est celui-ci : le Web en Offline avec Gears et HTML 5, à 14h00 pour la digestion . Et pour cause, je l’animerai … enfin, encore faut-il que j’en termine la présentation. En voici la description officielle :

Gears est un outil Open Source, majoritairement connu pour permettre à une page Web d’être consultable en étant déconnecté du réseau. Ce plugin pour navigateur Web propose pourtant d’autres briques utiles dans d’autres contextes, notamment les performances et le traitement d’un nombre important de données. C’est un outil unique permettant de créer des applications fonctionnelles hors-ligne et cross-brower sans avoir à recours à du client lourd (type application iPhone).

La présentation se focalisera sur la présentation des composants, des exemples d’utilisation mais aussi sur les contraintes et les choix de stratégie à adopter dans son code pour éviter la création d’usines à gaz.

L’atelier concluera sur l’avenir et HTML 5 dans la mesure où les travaux de Gears sont désormais intégrés à la spécification HTML 5.

Mais globalement, l’atelier s’articulera autour des points suivants :

• présentation des modules de Gears
• contraintes d’ergonomie
• implications en terme d’architecture de code
• débat ouvert avec l’assemblée

Le choix sera difficile avec en même temps un atelier de David Larlet et Charles McCathieNeville … où j’aurais aimé également être présent.

À samedi … et jeudi et vendredi pour d’autres

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 enfin pu assister à mon premier Paris-Web à Paris du 13 au 15 novembres 2008 inclus. C’était bien, très bien mais que dis-je : excellent ! J’ai rarement eu aussi peu envie de rentrer chez moi après cette multitude de rencontres dans un état d’esprit des plus respectueux.

Y’a même pas de troll pendant la conférence Internet Explorer 8, c’est dire.

Les conférences en quelques mots

Les conférences de Paris-Web 2008 étaient réparties du jeudi au vendredi. Je souhaitais intituler cette partie « mes conférences préférées » mais en faisant le décompte, j’en citerais au moins 75% :

• Qualité et accessibilité Web : vers l’amélioration continue
• Travailler dans le présent
• Accessibilité, des volontaires ?
• Internationalisation
• La mode se démode, le <style> jamais
• Identité 2.0 et Web sémantique
• IE8 et les standards du Web
• Performances côté client

Stéphane Deschamps

Ce qu’il faut retenir c’est que désormais, nous sommes dans une époque où nombre d’outils sont à notre disposition. Il faut maximiser l’utilisation d’outils déjà existants et s’en servir pour bâtir nos applications, interfaces et présentations.

Il faut également qu’on en finisse avec notre approche trop technique et intégriste de travailleurs du Web : le client se fiche éperdument de la techno employée ou de la fonctionnalité en elle-même. Ce qui compte c’est ce qu’elle apporte ainsi que le résultat final.
Bien entendu, si la solution employée tient compte des performances et est facile à mettre en œuvre, c’en n’est que mieux.

Élie me faisait la remarque : il faut vendre de la qualité et pas de l’accessibilité. Il faut vendre un site qui rassure et guide le client. Si le site n’est déjà pas adapté aux individus sans déficiences, à quoi bon s’acharner à le rendre accessible ?
Mieux vaut beaucoup de sites accessibles à 60% qu’une infime proportion de sites accessibles à 99%.

Bon nombre de conseils sur l’optimisation des sites Web étaient déjà cités dans l’excellentissime livre High Performances Websites. L’équipe Exceptional Performance de Yahoo! s’est toutefois penchée à fond sur l’optimisation des images.
J’y reviendrai d’ailleurs car j’ai découvert pngnq et pngcrush. Ces 2 programmes sont d’une utilité redoutable pour compresser et optimiser vos PNG, notamment pour faciliter la transparence IE6 sans douleur.

Chris Wilson

On terminera également avec une perspective du futur.
Daniel Glazman a fait un show exceptionnel sur les nouveautés de CSS3 avec tout plein de bonnes choses. J’ai vraiment hâte qu’on puisse jouer avec … peut-être dans pas si longtemps que ça vu que les navigateurs intègrent ces nouveautés par anticipation.

De son côté, Chris Wilson (qui faisait déjà partie de l’équipe de développement de Mozaïc) a abordé les standards et Internet Explorer 8. En toute honnêteté, j’admire la bravoure de cet homme « seul » face à une assemblée pro-standards qui passe sa journée à jeter des cailloux sur Internet Explorer.
Pour avoir un peu discuté avec lui après coup, il représente une chance exceptionnelle d’enfin avoir Internet Explorer au niveau des autres navigateurs.

Si fonctionnellement je me fiche éperdument du navigateur puisque je ne l’utiliserai plus, le monde a tout à gagner à avoir un navigateur de plus à respecter les standards.
Bon courage à Chris car ça ne doit pas être évident tous les jours pour lui. Je n’ose pas imaginer les montages qu’il a dû déplacer pour imposer ce choix du respect.

Du côté des ateliers

Le samedi c’était ateliers : 2 sessions le matin et 2 l’après-midi. Je me suis d’ailleurs vite retrouvé avec des choix cornéliens puisque pour chaque horaire, il y avait 5 sujets qui se faisaient concurrence.

J’ai pour ma part assisté à :

• Rédaction Web et référencement naturel
• Validation avancée des formulaires
• Développement efficace avec les frameworks CSS
• RDFa vs Microformats

La rédaction Web était intéressante même si je n’ai pas appris grand chose et j’en profitais pour terminer mes slides. Vous retrouverez tout le contenu de cette présentation dans le livre l’écrit Web.

La validation avancée des formulaires partait d’un bon principe mais s’enfonçait inutilement dans certaines parties. À mon avis, expliquer chaque fonction (y compris celles du DOM) était une perte de temps.
Conseil : charger ses slides ne rend pas pour autant l’information digeste. C’est pas un document Word.
C’était néanmoins intéressant pour le raisonnement et la satisfaction de mettre en place son propre validateur. Toutefois en production autant utiliser de l’existant. Il y a des plugins pour tous les bons frameworks JavaScript qui se respectent.

Je passe sur l’atelier des frameworks CSS puisque je l’animais. J’y reviendrai dans un prochain article pour appuyer ma présentation et fournir des explications à ceux qui n’ont pas pu y assister.
J’étais en revanche étonné qu’ils soient si peu connus. J’ai par contre été enchanté de les voir cités à plusieurs reprises dans mes conférences préférées

Rien à redire sur RDFa vs. Microformats même si on aurait pu éjecter les microformats rapidements et plonger encore plus loin dans la pratique de RDFa. Ça sera prétexte à une suite plus technique l’an prochain

La sublime Amélie Boucher

Sans oublier les gens !

Paris-Web c’est aussi l’occasion de rencontrer la moitié de son aggrégateur et de ses followers Twitter

Et Dieu sait s’il y avait tout un tas de pointures du Web à notre disposition dans une ambiance exceptionnellement cordiale :

• Sophie Major, big boss du Yahoo! Developer Network
• Nicole Sullivan, de l’équipe Yahoo! Exceptional Performance
• Christian Heilmann et son incroyable bonne humeur pragmatique ; je suis fan !
• Daniel Glazman, du CSS Working Group ; franc, direct et j’aime ça
• Sans oublier pêle-mêle Than, Sébastien Delorme, Monique, La Lène, Amélie Boucher, Hellgy, Raphaël Goetter, Fabrice Bonny, François Hodierne, Xavier Borderie … et en oubliant très certainement plein d’autres :’(
• Et d’excellentes découvertes : Anthony Ricaud, Mathieu Pillard et toute l’équipe Paris-Web !

La brochette des meilleurs !

Conclusion

Bref, Paris-Web c’est bien. Tellement bien que l’attente de l’édition 2009 me paraît déjà insoutenable !

Je ne regrette au final qu’une chose : 3 jours ça paraît long mais ça passe teeeeeeeeeeeeellement vite en compagnie de personnes de qualité avec un programme chargé.
J’ai essayé de discuter avec un maximum de personnes, que je connaissais ou pas, mais des fois c’est très insuffisant.

Les tables rondes étaient également exceptionnelles … désolé ça frise le billet sponsorisé mais il est difficile de ne pas déborder d’enthousiasme après un tel évènement.

C’est l’effet Paris-Web. Rendez-vous est pris.

Après 10 ans de règne d’Internet Explorer et un succès d’adoption en demi-teinte pour son successeur, Internet Explorer 7, Microsoft a fort à faire pour convaincre avec Internet Explorer 8.
La firme de Redmond est confrontée à ce fâcheux dilemne :

• considérer ses clients existants
• réagir aux pressions exercées par la concurrence, Firefox en tête

On peut à ce titre saluer le choix de Microsoft d’enfin embrasser les standards du Web. La huitième version de son navigateur Web adoptera ainsi par défaut une interprétation respectant ces standards (HTML, XHTML, CSS 2, partiellement CSS 3).
Ce choix a notamment été facilité par la proposition d’une nouvelle balise propriétaire : X-UA-Compatible.

Solution de facilité ou excellent compromis ?

Internet Explorer 6 : retour de boomerang

Si les développeurs de sites Web « pour Internet Explorer 6 » ont pu se réjouir d’un certain laxisme d’interprétation des standards du Web, ils vont payer dès demain le prix d’une catastrophe annoncée.
Des milliers (des millions ?) de sites Web et des milliers d’applications spécifiques reposent ou ont été conçues uniquement pour Internet Explorer 6. Ce navigateur n’est désormais plus supporté par Microsoft et ce dernier pousse les utilisateurs à adopter au moins Internet Explorer 7. Il faudra cependant disposer de Windows XP et son Service Pack 2 pour en « profiter ».

Mais alors, que faire de ses sites et applications vouées à une double obsolescence : la leur et celle de leur navigateur compatible ?

La solution X-UA-Compatible

En adoptant par défaut le support des standards avec Internet Explorer 8, Microsoft ne pouvait pas fermer la porte à sa base de clients et d’utilisateurs.
Au lieu de les flouer et de les ignorer, une nouvelle balise HTML propriétaire pourra être incluse dans l’entête de toutes les pages HTML : X-UA-Compatible.
Cette entête pourra également être renvoyée par le biais d’une entête HTTP par votre serveur Web favori.
Par « propriétaire », j’entends que seul Internet Explorer 8 (et peut-être ses successeurs) sera en mesure d’interpréter la valeur de cette balise. Elle est fort heureusement respectueuse du standard HTML et n’empêchera donc pas vos pages Web de passer au validateur sans provoquer d’erreur.

Cette balise a pour effet d’indiquer à Internet Explorer quel moteur de rendu utiliser. Autrement dit c’est le site/application Web qui influe sur le comportement schizophrénique du navigateur et en aucun cas l’utilisateur final.
Si Internet Explorer 8 ne rencontre pas cette balise, il utilisera son moteur de rendu respectueux des standards. Autrement, il basculera dans le mode d’interprétation correspondant à la version spécifiée, à savoir Internet Explorer 6 ou Internet Explorer 7.

Il faut toutefois avoir en tête que cette bascule n’affecte pas que l’interprétation d’HTML mais aussi celles des CSS et de JavaScript.
Autrement dit, si vous décidiez un jour d’enlever la balise X-UA-Compatible, il y a de très fortes chances que vous souscriviez à une grosse couche de recettage fonctionnel, tant du côté CSS que JavaScript.

Bouton d'émulation Internet Explorer 7 ... équivoque ?

Les options de compatibilité, le casse-tête

Microsoft propose 3 modes de rendu :

1. IE=7 pour forcer tout type de rendu en respect des standards à la sauce IE7 (respect approximatif donc) ;
2. IE=EmulateIE7 pour respecter les standards sauf quand la page est moisie (le fameux mode Quirks). Autrement dit, un Internet Explorer 8 déguisé en IE7 ;
3. IE=EmulateIE8 pour respecter les standards (mais vraiment) sauf quand la page est moisie. Autrement dit un Internet Explorer 8 avec quelques laxismes.

Si on compte avec ça la possibilité pour l’utilisateur de basculer de lui-même vers un mode de rendu « dégradé », difficile de choisir la moindre balise à appliquer.
Le navigateur sera cependant strictement compatible par défaut (pas besoin d’ajouter la moindre entête ou balise pour cela).

Quelle stratégie adopter pour ses sites Web ?

Si la présence de cette balise est en soi une bonne nouvelle, il convient de se poser les bonnes questions : X-UA-Compatible ne doit pas permettre à l’errance Internet Explorer de se reproduire à nouveau. La facilité ne doit pas être le seul facteur à envisager.
Voici quelques intérêts à utiliser X-UA-Compatible :

• manque de compétences internes sur HTML/XHTML et CSS
• besoin rapide d’adapter l’existant au nouveau logiciel
• parc d’applications non-maîtrisé ou doté d’une politique de mise à niveau stricte
• pas de budget pour redévelopper le site/application Web
• la refonte du site/application aboutira plus tard que le déploiement d’Internet Explorer 8

Vous remarquerez que je n’aborde en aucun cas la question des nouveaux sites et applications et/ou leur refonte. Ceci pour la simple et bonne raison suivante : X-UA-Compatible est un palliatif à court-terme pour conserver un maximum d’applications fonctionnelles en attendant leur adoption des standards.

Il y a de très fortes chances que cette balise ne soit plus prise en compte dans la version 9 du navigateur ; tout du moins, je l’espère fortement.
En clair et pour résumer en 2 lignes :

1. X-UA-Compatible n’est à utiliser que sur des sites existants, peu conformes aux standards et nécessitant une compatibilité maximale très rapide avec Internet Explorer 8
2. les refontes doivent impérativement se concentrer sur les standards et agir comme si X-UA-Compatible n’existait pas

Conclusion : l’avenir passe par les standards

Si ce résumé éveille des craintes au plus profond de vous-même, sachez qu’il n’est pas trop tard. Comme tout choix logiciel ou matériel, il faut anticiper à moyen et long terme en évitant de s’enfermer dans une solution totalement fermée.

Les 99% des parts de marché d’Internet Explorer d’antan sont la preuve même qu’on ne peut se reposer sur un taux d’adoption mais bel et bien sur une base qualitative saine : le Web de demain sera sur vos ordinateurs, vos PDA, vos téléphones mobiles, vos téléviseurs, vos frigos, vos montres, vos consoles de jeux et même vos murs et tables basses. Dans tous les cas, la garantie que vos sites et applications fonctionnent c’est le respect des standarts ; les standards du Web, pas ceux définis par Internet Explorer 6.

X-UA-Compatible est une solution à court terme, en aucun cas une fin en soi ou une garantie de pérennité.

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’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

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

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

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

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

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

Les microformats

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

Il existe plusieurs spécifications de microformats :

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

Intérêts et utilité des microformats

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

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

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

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

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

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

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

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

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

Outils proposant des microformats

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

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

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

Outils agrégeant les microformats

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

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

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

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

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

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

Conclusion

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

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

Pour en savoir plus

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

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

Firebug fait partie de mes extensions préférées depuis un bon moment. Je l’estime aujourd’hui même plus importante que l’extension Web Developer, c’est dire.

J’ai pourtant constaté que la plupart de ses utilisateurs la sous-exploitait en se limitant à la console pour consulter les erreurs et éventuellement à l’inspecteur HTML pour remonter rapidement dans l’arborescence des balises en 1 clic. C’est bien mais pas assez.
Firebug est tout simplement énorme ! Suffisamment énorme pour gagner un temps incroyable dans le développement d’applications JavaScript et pour mieux comprendre les incohérences des CSS dans une page, entre autre.

Je vous offre aujourd’hui mon cadeau de Noël pour gagner en productivité et maîtriser cet outil ô combien indispensable.

Le plus amusant dans l’histoire c’est que le site officiel de Firebug dévoile (succinctement certes) tous les petits plus qui simplifient la vie. Je vais m’atteler à les éplucher en fonction des domaines d’utilisation :

1. pour le HTML et les CSS
2. pour le JavaScript
3. pour gagner en performances

Firebug pour le HTML

L’inspection HTML

J’apprécie l’inspection HTML car elle me permet de retrouver simplement le code lié au visuel. Après avoir activé l’inspecteur, je survole l’élément sur lequel je veux travailler, je clique dessus et le volet Firebug se fige dessus en m’indiquant toutes ses propriétés CSS, le modèle de boîte et ses propriétés DOM. On en reparle tout de suite après.
L’inverse est également possible. C’est à dire qu’en survolant le code, la correspondance visuelle dans la page est établie. C’est rudement pratique pour repérer des éléments qui sortent du flux. Ça l’est d’autant plus que les différentes marges (internes, externes, bordures) sont elles aussi mises en surbrillance.

Le gros atout de cet inspecteur c’est également l’édition à la volée de toutes les balises ! Idéal pour tester diverses classes d’un objet ayant un impact visuel fort sur son affichage. Cet outil présente un gain de temps énorme par rapport à la modification du code dans son éditeur et un petit coup de touche F5 dans la foulée.

Il faut également retenir que toute balise est sélectionnable en cliquant sur son nom (div, h3 etc.). Cela a a pour effet de mettre à jour le panneau latéral de Firebug. Panneau latéral qui est également fort utile.

L’inspection CSS, Layout et DOM

Le panneau latéral de l’inspecteur HTML se compose de 3 onglets, tous très utiles.

Inspecteur CSS

Les propriétés CSS affichées concernent uniquement l’objet actif et c’est ce qui en fait sa force. Ce panneau indique en effet la cascade CSS en cours ce qui permet de comprendre rapidement pourquoi sa feuille de style n’est pas appliquée comme il faudrait. Elle a la bonne idée de mentionner quelle feuille de style est utilisée et quelle ligne. De quoi corriger ça dans son éditeur favori rapidement.

Ou pas. En effet l’inspecteur CSS permet, tout comme l’inspecteur HTML, de modifier les propriétés à la volée et sans fioriture. Si je précise sans fioriture c’est parce que l’éditeur à la volée de Web Developer rend parfois l’affichage de la page bancale en décalant des éléments. Là vous pouvez totalement compter sur l’éditeur intégré et ce n’est pas un luxe !
Désactiver, supprimer, modifier ou ajouter des propriétés sont quelques-unes des actions que vous pourrez effectuer à même la page.

Là encore c’est une des parties où les gains de temps sont énormes. On peut en effet modifier ses CSS et les tester tout en observant l’impact immédiat de ses modifications.

Inspecteur du modèle de boîte (Layout)

Le modèle de boîte CSS peut vite devenir pénible à gérer et plus particulièrement quand on visualise mal le cumul des différentes marges.
Dans tous les cas c’est appréciable de pouvoir constater les marges en présence et encore, de pouvoir modifier leurs dimensions à la volée. Firebug a la bonne idée de colorer les marges intérieures (padding), extérieures (margin) et les bordures (border) d’une couleur différente.

Il a également la bonne idée d’afficher une double règle millimétrée au survol du panneau layout. Très pratique dans le cas de design en grilles ou nécessitant un certain rythme de visualisation.

Inspecteur DOM

Ah l’inspecteur DOM ! S’il n’existait pas il faudrait l’inventer. Firefox proposait déjà un tel outil à la différence près qu’il était moins pratique d’utilisation.
L’inspecteur DOM m’est moyennement utile dans le cas d’une simple inspection du code HTML bien que ce soit toujours pratique de visualiser la présence ou pas d’objets JavaScript dans tel ou tel élément. C’est fortement appréciable pour la librairie Prototype étant donné les dégâts causés par son extension du DOM à gogo.

Firebug pour le JavaScript

L’inspecteur JavaScript

C’est l’autre outil indispensable de Firebug. Avec lui, c’en est fini des alert(mavariable);. L’inspecteur DOM prend avec lui toute son utilité.

J’illustre sur l’image ci-dessus l’utilisation des points d’arrêt (breakpoints). Il suffit d’un clic à gauche d’un numéro de ligne pour en placer/retirer un. Concrètement quand l’exécution du JavaScript arrivera au premier point d’arrêt, elle va se stopper.
Quel intérêt ? Observer. En agissant ainsi, vous avez la main sur toutes les variables connues au sein de votre code/fonction. Très utile pour connaître les paramètres passées à la fonction et détecter les erreurs. C’est pour cette raison que les alert() deviennent inutiles : tout est à portée de main. Vous ne pesterez plus contre un undefined mal placé

En parallèle de ça, l’inspecteur DOM est à utiliser pour visualiser d’un coup d’œil les différentes variables actives ainsi que leur arborescence. Comme tout est cliquable, l’inspecteur vous transporte sur n’importe quel objet pour en étudier le contenu.

La console Firebug alias console.*

La console Firebug est l’autre tueuse d’alert() et s’utilise de deux manières.

La plus accessible est d’interagir avec. Vous saisissez votre code, la console l’exécute et retourne le ou les résultats. Encore une fois les objets sont cliquables et navigable au travers de l’inspecteur DOM.
La console est utile pour utiliser des fonctions sorties du contexte de l’initialisation : il devient tout à fait possible de piloter des éléments après le chargement de la page. Ça évite encore une fois des F5 inutiles et consommateurs de temps.

L’autre manière d’utiliser la console c’est de ne pas l’utiliser. Ou pas de manière active tout du moins puisqu’elle est également un objet JavaScript (console) utilisable dans votre code auquel sont rattachées plusieurs fonctions au nom explicite :

• console.log() : affiche une information standard
• console.info() : affiche une information de type « information »
• console.warn() : affiche une information de type « avertissement »
• console.error() : affiche une information de type « erreur »
• console.debug() : débogue le contenu d’un objet directement dans la console

Autrement dit, si l’inspecteur ne suffisait pas, au lieu de lancer un alert(mavariable) (potentiellement dangereux dans une grande boucle qui n’a jamais cliqué 50 fois sur « OK » à cause de ça ?), il vaudra mieux utiliser console.log(mavariable). Il y a de quoi faire, surtout avec la possibilité de créer des groupes de messages et l’utilisation de la syntaxe printf.

Et top du top, en cas d’erreur JavaScript, la console affiche un petit cercle rouge qui rappelle fortement le point d’arrêt. Normal puisque c’en est un. Un clic et on évite de rechercher la ligne problématique dans le code. Encore une fois, du temps de gagné.

Firebug pour les performances

Après avoir bien développé, Firebug propose de mieux développer. L’extension magique propose quelques outils sympathiques pour rapidement déceler les problèmes, notamment de scripts trop gourmands ou à optimiser.

Le traceur réseau

Avec le traceur réseau c’est simple, tout ce qui est chargé sur la page est chronométré. Si un élément est systématiquement long à charger en tête de liste, pourquoi ne pas essayer de le déplacer dans le bas de la pile ? Je pense notamment aux appels vers des fichiers JavaScripts externes. Les appeler en bas de page permet d’éviter des gels de page. C’est ce que YSlow nous recommandera

Outre une petite prévisualisation des contenus, le traceur affiche aussi les statuts des contenus s’ils sont différent du statut 200 (found). Et de surligner ça en rouge en cas de fichier introuvable.

J’aime beaucoup le traceur pour le suivi des requêtes XHR (appels AJAX). Un clic sur un appel affiche à la fois les entêtes, les données transmises au serveur et sa réponse. Fini les requêtes AJAX qui ne produisent rien sans qu’on puisse savoir pourquoi. Le clic droit sera également un fidèle allié, notamment pour ouvrir l’appel AJAX dans un nouvel onglet. C’est plus lisible pour déboguer quand même

Le profileur JavaScript

Le profileur (profiler) JavaScript s’utilise un peu à la manière de la console : de manière active ou au travers de l’objet console.

Le profileur enregistre tout ce qui se passe entre le moment où il est enclenché et le moment où il est stoppé. Il va ainsi dénombrer toutes les appels (calls), leur durée d’exécution et leur fichier d’origine, entre autre. L’idée est bien entendu de voir ce qui consomme le plus d’appels et de temps pour savoir si ce comportement est normal ou pas. À ce stade là, difficile de pousser la granularité du profileur plus loins.

Sauf en utilisant le profileur directement dans le code comme on a déjà pu le faire pour les logs. console.profile() et console.profileEnd() seront vos amis. C’est vraiment l’idéal pour profiler l’exécution d’une fonction, voire même les portions de code exécutée en son sein.

L’extension YSlow

L’extension YSlow est une extension pour Firefox mais elle nécessite toutefois la présence de Firebug. Elle s’articule autour de trois critères.

Il y’ a d’une part la surveillance des performances. YSlow se base sur la liste des bonnes pratiques établies par Yahoo! (14 à l’heure actuelle). YSlow passe ces critères en revue et accorde une note en conséquence. Si certaines sont difficiles à tenir, c’est un bon moyen de s’intéresser à de nouvelles pratiques d’optimisation et de performances.

Le second critère est affiché dans le panneau stats. Il s’agit de la capture d’écran ci-dessus. Certes il s’agit d’un simple tableau mais dont les chiffres sont intéressants à étudier. YSlow analyse la page pour un premier et un second chargement. La différence entre les deux ? C’est que le cache est passé par là et normalement, je dis bien normalement, le second chargement se doit d’être beaucoup plus rapide.
Si ce n’est pas le cas, il y a de l’optimisation à faire et cela peut aussi signifier du côté serveur Web. Pas forcément du développement donc.

Enfin on termine sur une partie complémentaire aux stats : les composants (components). Elle distille des informations plus verbeuses que le traceur réseau de Firebug en se focalisant sur les E-Tag, la présence ou pas de compression, la date de validité du cache ainsi que la taille des objets.

Conclusion

J’espère avoir éclairé quelques lanternes sur l’utilisation de Firebug. Cette extension est suffisamment puissante pour gagner en confort de développement ; il serait dommage de s’en priver. On gagne du temps, du confort et surtout, de la qualité de développement.
À noter qu’il existe aussi Firebug Lite. Il s’agit d’un script JavaScript compatible avec les principaux navigateurs du marché mais comme le Lite l’indique, les fonctionnalités sont plutôt limitées. Seule la console JavaScript persiste.

Concevoir un site Internet dans les règles de l’art demande de multiples compétences : architecture technique, programmation, graphismes, intégration, ergonomie et du bon sens. Transcender CSS : sublimez le design Web ! s’intéresse à l’aspect esthétique au travers des CSS.

Ou comment CSS, sémantique, intégration XHTML, microformats, sources d’inspirations et approche du design en grilles sont indispensables pour tirer partie du meilleur du Web.

Transcender CSS : sublimez le design Web ! est un ouvrage paru en France en août 2007 aux éditions Eyrolles ; en novembre 2006 dans le monde anglophone. Le livre est broché sur 360 pages ce qui en fait un livre imposant et propice à de riches illustrations d’excellente qualité. Andy Clarke, son auteur, s’est permis ce plaisir pour montrer au mieux qu’un site visuellement alléchant et bien structuré est un succès assuré pour capter l’attention du visiteur.

Transcender CSS ne s’adresse pas aux débutants puisqu’il ne s’attardera pas à vous expliquer les modèles de boîte ou les innombrables bugs d’Internet Explorer. Son contenu évolue toutefois en douceur de la facilité à la complexité ce qui le rend néanmoins abordable par des néophytes.

Découverte

Organiser les contenus avant tout, tel est le credo de Transcender CSS. C’est l’objectif majeur de cette première partie ; partie qui devrait être lue et transmise par tous les enseignants puisqu’elle explique comment on adapte le design au contenu et non l’inverse.

La mise en pratique du balisage XHTML est menée avec pédagogie. Vous apprendrez comment traduire une image en balises HTML de manière adaptée. Et un bon balisage c’est déjà la moitié du travail, l’autre restant son habillage. Il faut dissocier le contenu et la mise en page tout en n’oubliant pas un point essentiel : donner du sens au contenu.
Il existe de nombreuses balises XHTML qui ont chacune leur propre signification : il faut les utiliser pour donner du sens. C’est non seulement important pour le référencement mais aussi pour ancrer les feuilles de style de manière propre et efficace. Nos professeurs de français nous ont appris à utiliser des verbes riches au lieu de verbes pauvres (être, avoir, aller, prendre etc.) alors faisons de même avec les balises XHTML :

• <h1 à h6> pour afficher des titres hiérarchiques
• <p> pour des paragraphes de textes (les images sont du texte)
• <ul/ol/li> pour des listes de contenus
• <q/cite/blockquote> pour des citations de textes
• <pre/code/kbd> pour des saisies de texte au clavier ou des extraits de code
• <span/div> dans les autres cas ; ce sont des balises neutres vides de tout sens

Et d’aborder dans la foulée les microformats. Ça a été ma première surprise car je ne m’attendais pas à les retrouver dans ce livre. Un duo de page les aborde et montre (un peu trop succinctement) que microformater du contenu n’a rien d’impossible, surtout quand la structure XHTML est bonne dès le départ.

Processus

Transcender CSS s’intéresse à une approche industrielle du processus de création. Autrement dit : comment proposer efficacement une interface graphique à un client/décideur sans investir trop de temps. Nous savons tous qu’il y a toujours du changement, mineur mais surtout majeur, et qu’il est difficile de chambouler toute une feuille de style pour repositionner des éléments en conservant une cohérence.

C’est là que l’approche par la méthode de la boîte grise prend tout son sens. Elle définit à l’aide de boîtes grises l’agencement des contenus de la page. Une boîte, un contenu et le charme opère. Les classiques story-board s’en approchent.
Cette méthode peut se compléter à l’aide de symboles pour représenter des éléments annexes (textes, formulaires etc.) mais est surtout très facilement réalisable à partir d’un logiciel de présentation de type OpenOffice Impress ou Microsoft Powerpoint.

Une fois les bases de la structure mise en place, l’heure est venue de présenter une maquette statique. Autrement dit du HTML et des CSS. Les ajustements resteront possibles puisque la première partie du livre a expliqué comment mettre en œuvre une structure pérenne et libre de mise en forme.
Transcender CSS recommande fortement, et je suis on ne peut plus d’accord, d’utiliser de manière poussée les extensions indispensables de Firefox que sont Firebug et Web Developer.
J’y consacrerai un billet mais les éditeurs intégré modifiant à la volée votre page sont des outils précieux offrant des gains de développement mésestimés.

L’ouvrage poursuit sur des bonnes pratiques d’organisation de son code au sein même des feuilles de style. Des pratiques qui permettent de retrouver facilement ses petits sans avoir à chercher inutilement. Des pratiques qui suggèrent également de bien coder pour mieux réutiliser son travail dans d’autres projets. Si vous estimez votre travail, pourquoi le recommencer intégralement lors du projet suivant ?

Inspiration

Cette troisième partie a été mon deuxième choc pendant la lecture. C’est la partie dans laquelle j’ai le plus appris car elle explore des aspects finalement peu abordés dans les ouvrages liés aux CSS.

J’ai commencé à mieux percevoir l’intérêt et l’ingéniosité du rythme vertical grâce à la divine proportion. Qui aurait cru que les maths se cachaient aussi subtilement dans le design Web ? Certainement pas moi. Retenez bien le nombre 1,62 (φ) car c’est le nombre d’or qui régira avec majesté les designs CSS les plus réussis.
En français, il s’agit de la règle des tiers. Au lieu de choisir arbitrairement la taille des contenus, divisez les espaces en largeurs proportionnelles, elles-mêmes divisibles par 1,62 etc. La clarté en résultat est tout simplement saisissante.

Tout ceci nous amène à parler du design par grille. Vous venez de suivre le lien ? Vous aurez probablement remarqué, consciemment ou pas, que la page est découpée en 8 colonnes de largeur identiques. Certains contenus occupent davantage de place mais devinez-quoi ? Cela correspond toujours à un certain nombre de colonnes, pas une largeur hasardeuse.
Cette lubie n’est pas si excentrique que cela puisqu’elle nous provient directement des … journaux papiers. Qui aurait cru que le New York Times aurait pu inspirer les meilleurs designers du Web ? Et pourtant, on ne regardera plus les journaux de la même manière en observant leur structure à 6 ou 8 colonnes. Du nombre d’or en veux-tu en voilà.

Andy Clarke termine ce chapitre sur les sources d’inspirations. Là non plus il n’y a pas de frein à l’imagination puisque tout est susceptible de catalyser créativité : architectures d’immeubles, coupures de presse, publicités de magazines, affiches diverses et variées. Vous l’aurez compris, tous les supports visuels facilement agrégeables.

Transcendance

Cette partie termine en apothéose Transcender CSS. Nous savons intégrer, nous savons structurer et nous savons imaginer alors maintenant il va falloir sublimer. Au prix du livre, ça serait dommage que notre côté créatif n’aie pas pris du galon

Il n’y a d’ailleurs qu’un point sur lequel j’ai du mal à adhérer : cette adhésion au positionnement absolu/relatif et le dénigrement déguisé des flottants. Si les positionnements relatifs permettent de forcer le positionnement d’un bloc, c’est en revanche une solution beaucoup moins flexible dans la majorité des cas. Cette technique oblige, à mes yeux, de connaître les tailles des éléments à positionner. C’est parfois impossible, surtout si on veut pouvoir s’affranchir de largeurs fixes pour profiter de designs élastiques.
Je comprends néanmoins que c’est une pratique appréciable pour les designs en grilles.

De très nombreux cas pratiques abondent dans cette partie. Ces exemples stimulent l’imagination avec des mises en pages (et des variantes) convaincantes, attractives et on ne peut plus déclinables dans le monde réel. Réel ou presque puisqu’ils se basent sur des navigateurs valides uniquement.
C’est l’occasion d’aborder le génie de Dean Edwards avec IE7, la librairie Javascript ultime pour Internet Explorer. Cette librairie permet de mettre à niveau Internet Explorer 5 et Internet Explorer 6 au niveau d’Internet Explorer 7. Ce n’est certes pas la panacée mais ce n’est plus l’enfer truffé d’incertitude que l’on haït tant.

Transcender CSS conclut sur une quarantaine de pages avec les CSS 3 en mêlant exemples pratiques et des comparaisons entre CSS 2 et CSS 3. J’ai été ravi de voir en pratique l’affichage multi-colonnes sans jouer avec les flottants, l’habillage d’un bloc avec plusieurs bordures en images (sans balises superflues) et surtout l’Advanced Layout.
L’Advanced Layout est probablement l’avancée la plus attendue car elle permet de s’affranchir des positions absolues pour repositionner du contenu sur la page simplement. Et de retrouver les notions de grilles puisque des régions sont définies dans la feuille de style. Au designer de déplacer un contenu dans le flux sans le faire quitter.

Autant dire que les designs bâtis sur CSS 3 seront riches en créativité. Et ce n’est pas l’initiative Goto CSS3 qui dira le contraire

Conclusion

Cet ouvrage m’a énormément plu pour 2 raisons :

• j’ai failli croire que je n’allais rien apprendre
• le contenu est ouvert vers l’avenir

En effet plutôt que de nous dire quoi faire, Transcender CSS explique comment mieux faire. C’est véritablement appréciable car en lisant le livre on adapte son contenu à ses besoins. Ses pages sont généreusement émargées de conseils, d’astuces et de ressources qui enrichissent la perception de la conception du design Web. Je me suis d’ailleurs surpris à relire le livre mais uniquement ses marges de peur d’avoir raté un lien essentiel …

Vous le savez tout aussi bien que moi, le gros problème des ouvrages réside dans des cas pratiques difficilement réutilisables au quotidien. Transcender CSS a l’intelligence de proposer des recettes pour mieux aborder la conception des sites, des sources d’inspiration jusqu’aux secrets du découpage en grilles. Qui eût cru que la presse papier avait encore de belles leçons à donner au Web ?

Transcender CSS ne livre pas clé en mains des solutions mais vous aidera à y voir plus clair, à comprendre pour mieux réagir. En soi c’est ce que j’attends d’un livre à 30€. Une valeur sure.