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

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

Une petite scéance de rattrapage s’impose

Pourquoi avoir choisi ce sujet ?

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

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

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

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

La présentation

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

Ce qu’il faut en retenir

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

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

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

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

Exemple de mise en forme en grille

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

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

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

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

Feuilles de dessin pour 960 Grid System

Conclusion

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

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

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

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

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

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