Refondre aux standards des sites de taille industrielle

Par le WaSP

WaSP :

Dan, la rumeur dit que tu serais derrière la transformation de Fast Company et d'Inc.com en sites basés sur les standards web ? Quel rôle as-tu joué dans cette refonte ?

Dan :

C'est exact. Mon rôle a consisté à prendre en charge tout le design et le développement de la partie publique (XHTML, CSS, XSLT des deux sites. Le nouvel habillage de Fast Company a été lancé en mars 2003 sous la direction artistique de Daigo Fujiwara, et Inc.com a été relancé en juillet dernier.

En plus de la partie publique, il y a eu aussi de nombreux changements réalisés sur la partie privée. Par exemple notre CMS a été réécrit pour inclure des routines de validation qui garderont le code propre comme un sou neuf après avoir passé des mois à le convertir.

WaSP :

La question que nous nous sommes tous posé à un moment ou à un autre est celle-ci : comment diable réussis-tu à vendre les standards web à des gens qui ne les ont pas encore adopté, et qui (parfois) n'en n'ont pas besoin ? Peux-tu nous dire comment tu as conclu le dossier avec Fast Company ? Y a-t-il eu des frictions ?

Dan :

C'est toujours un point d'achoppement - particulièrement dans les équipes web internalisées. Cependant je ne vais pas vous mentir, ça a été très facile. L'argumentation a ressemblé à quelque chose comme Hey, Bob (il s'agit de Rob Roesler, le directeur des deux sites), jette un coup d'œil sur Wired.com et sa réponse a été C'est ça que nous devons faire.

Je dois sans aucun doute remercier ici Douglas Bowman pour avoir défriché le chemin avec la refonte de Wired.com en octobre 2002. C'est une date importante pour la construction de sites conformes aux standards web. Nous avions tous enfin une référence à évoquer, et par ce «nous» je veux parler des designers et des développeurs travaillant dans des équipes web commerciales. Il y a eu de nombreux pionniers des montages en CSS avant le lancement de Wired, mais ce dernier a prouvé que le respect des standards peut aussi fonctionner sur des sites commerciaux, et ça, c'était très excitant.

Nous nous sommes donc mis au travail, et nous avons découvert en cours de route tous les avantages qu'il y avait à construire un site de cette manière. L'expérience de Fast Company nous a énormément appris, et une fois celle-ci conclue avec succès, nous avons su que nous devions faire la même chose avec Inc.com.

Je réalise que mettre tout le monde dans le coup pour fonctionner selon les standards n'est pas facile dans toutes les équipes web. Mais vous avez vraiment besoin que tout le monde soit dans le coup. En tant que designer vous pouvez créer des modèles aussi clairs que de l'eau de roche, mais si le CMS et les autres applications qui se trouvent derrière ne respectent pas les standards, ça n'aura servi à rien. En l'ocurrence, j'ai eu la chance de travailler avec des gens qui étaient sur la même longueur d'onde.

Pardonnez-moi cette analogie ridicule, mais : nous sommes trop gros. Il est temps de nous mettre au régime. Il est 18h00 et nous sortons juste du travail. Nous avons faim alors nous faisons ce que nous avons toujours fait - aller chez KFC et commander une barquette de poulet frit. Hmm, ça sent bon... C'est ce que nous avons toujours fait. Mais c'est ce qui nous tue.

C'est là qu'on entend parler de ce régime à la mode, qui pourrait bien nous aider. Nombreux sont ceux qui, à juste titre, se méfient des régimes à la mode, les rejetant immédiatement. Et puis il y a ceux qui essayent tous les régimes imaginables. Il y a toujours un piège, celà dit, sans parler des mauvaises habitudes à abandonner.

Je vois les standards web comme un régime à la mode - mais qui fonctionnerait vraiment. Le plus difficile reste de convaincre. Tout le monde est convaincu d'être en bonne santé, ou ne voit pas de risque particulier. Jeffrey Zeldman fait un travail d'évangélisation formidable. Peut-être qu'il faudrait aussi quelqu'un comme Richard Simmons dans cette croisade.

WaSP :

Très bien, il y a ce régime incroyable qui marche réellement. Pourquoi était-ce important pour Fast Company de l'essayer ?

Dan :

Je pense que c'est important pour tous les sites - mais à l'époque c'était particulièrement logique pour nous. Nous étions une très petite équipe, qui rétrécissait sans cesse à cause des réductions de coûts et de personnel. Nous cherchions des solutions pour réduire le budget de toutes les manières possibles. En passant aux standards web, notre code a littéralement été divisé par deux, et le temps de chargement moyen d'une page a diminué d'autant, réduisant la sollicitation de nos serveurs. Rien que ces deux bénéfices nous ont permis de louer moins d'espace avec un peu moins de serveurs pour gérer le même volume de trafic.

À côté des améliorations côté serveurs, il était aussi important de toucher l'audience la plus large possible. FC et Inc sont des magazines. Leur modèle économique est basé sur le contenu. Apporter ce contenu aux gens est leur objectif principal, et les gains en terme d'accessibilité obtenus grâce à un balisage structuré et aux CSS ont rendu cette démarche exceptionnellement facile. Les navigateurs textuels, les lecteurs d'écrans, les téléphones et les PDA peuvent maintenant lire le contenu des deux magazines aussi facilement que les autres.

WaSP :

Quels ont été les autres bénéfices pour Fast Company depuis le changement ? Y a-t-il eu des inconvénients ?

Dan :

Nous avons vu des bénéfices pour les deux sites. Le premier a été une réduction moyenne de la taille des page de près de 50% (y compris pour les deux pages d'accueil). Oui, la moitié du code ! Le second est la facilité avec laquelle on peut changer l'habillage des différentes sections du site, en utilisant une CSS additionnelle qui peut remplacer les styles par défaut. Par exemple, si Microsoft venait nous dire nous voudrions que vous montiez chez vous un micro-site tout en conservant notre logo et nos couleurs, il nous suffirait d'agglutiner quelques règles de style qui remplaceraient celles par défaut et de les importer après tout le reste. Cette section du site aurait alors une structure identique, mais avec un habillage sur mesure.

Pour ce qui est des inconvénients, le plus important est probablement la contrainte de la largeur dont je parlerai dans un instant, ainsi que les montages imbriqués qui peuvent souvent se révéler délicats à réaliser, comme par exemple une mise en page multi-colonnes à l'intérieur d'une maquette elle-même déjà composée en CSS. Ce sont des situations complexes à gérer, et certainement celles où les limitations deviennent évidentes.

WaSP :

Comment les choses se sont-elles mises en place une fois que la décision a été prise ? Quelle sorte de pièges ton équipe a-t-elle dû déjouer, par rapport au CMS et aux anciens articles à réintégrer ? Et au fait, quelle était la taille de votre équipe ?

Dan :

Pour faire fonctionner les deux sites, je dirai que nous avions une équipe vraiment très réduite. Il y avait moi-même, un intrépide directeur (Rob Roesler), deux super-bons développeurs (David Searson et Bob Joyal), un maestro de la production (Paul Maiorana) et une paire de stagiaires pour aider à nettoyer et valider près de 20 000 articles au total. Il y avait aussi 3 ou 4 autres membres de l'équipe web qui ont géré la rédaction, le développement commercial et la publicité.

Nous avions un gros avantage : notre CMS était un produit-maison écrit par le brillant australien, David Searson. Il a profité de la refonte pour réécrire l'ensemble du CMS avec en tête les fonctionnalités nécessaires à la validation. Au final, un rédacteur ne pouvait pas publier un article sans que celui-ci ne soit validé. Ça a forcé tout le monde à se mettre dans le bain, et à apprendre un XHTML correct. Ce CMS qui confortait les efforts que nous fournissions pour la partie publique a été essentiel.

L'étape la plus difficile des deux refontes a sans aucun doute été le nettoyage de l'ancien contenu. Certains contenus d'Inc remontent à 1986, et nous y avons trouvé le pire HTML qu'on puisse imaginer. Il a fallu une petite armée de deux stagiaires qui tous les jours pendant des mois l'ont épluché, article par article. Qu'ils en soient bénis.

Ce qui est merveilleux quand on nettoie un vieux contenu qui ne change pas, c'est qu'une fois qu'il a été nettoyé, finis les soucis. Il n'aura plus jamais besoin d'être retouché.

WaSP :

Il y a aussi des onglets de navigation très sexy...

Dan :

Merci ! Je suis plutôt content de cette solution, bien qu'elle ait ses défauts. La contrainte était que nous avions besoin d'y caser un certain nombre d'éléments de premier niveau. Utiliser du texte n'aurait pas marché à une résolution minimale de 800x600. Il fallait donc utiliser des images. Tout ce que j'ai fait a été de combiner l'excellente technique de rollovers de Pixy avec la méthode de substitution d'image du moment. Pour toutes les fois où vous êtes forcés d'utiliser des images dans la navigation, c'est une option. Dans l'idéal, c'est bien de pouvoir utiliser du texte, pour laisser les utilisateurs à faible vision augmenter la taille de la police sur ces éléments. Nous avons essayé de réduire ce problème en référençant, dans une feuille de style alternative, un deuxième ensemble d'onglets qui utilisent une taille de police plus importante.

WaSP :

Y a-t-il quelque chose que tu aurais souhaité et que, pour une raison ou pour une autre, tu n'as pas pu faire ?

Dan :

Une des choses que j'aurais pu faire de manière différente est de repenser l'utilisation d'un affichage fluide par opposition à un affichage fixe. La raison principale pour laquelle nous avons choisi le fluide plutôt que le fixe était de pouvoir mieux gérer le nombre important de publicités sur les pages des articles. La sale pub de 336 pixels de large au milieu de la page est un véritable fauve à dompter. Bref, nous avons pensé qu'avec une largeur de page flexible, la lecture serait plus facile pour les utilisateurs possédant des grands écrans.

Le revers de la médaille, c'est qu'il peut être difficile de réaliser des affichages sur mesure (comme celui de la page d'accueil) pour cette colonne du milieu, tout en gardant à l'esprit la largeur flexible. Nous nous sommes beaucoup servis des blocs flottants, mais c'est parfois agréable de pouvoir compter sur une largeur spécifique.

WaSP :

Nous avons lu quelque part que depuis ces changements, vous n'avez pas reçu une seule plainte d'utilisateurs de Netscape 4.x. Dans la mesure où ils peuvent évidemment accéder au contenu (mais pas à l'habillage) des pages, que penses-tu que cela dise sur l'utilisateur moyen qui utiliserait toujours une technologie plus ancienne ?

Dan :

C'est dingue, non ? Ou peut-être pas. Celà dit, il est exact que nous n'avons pas reçu une seule plainte d'utilisateurs de Netscape 4.x depuis le nouveau lancement des deux sites. J'aime à penser que c'est parce qu'ils apprécient la rapidité de chargement de la version sans style. C'est peut-être aussi parce que ces utilisateurs ne pensent pas à nous faire de retours. Mais à en juger par la masse de commentaires que nous recevons sur d'autres sujets, il semble que les utilisateurs de versions 4 ou antérieures n'ont rien remarqué, ont mis à jour leur navigateur, ou sont simplement contents.

C'est en tout cas ce qui a rendu plus facile la décision d'utiliser la méthode @import pour cacher toutes les CSS à ces navigateurs.

WaSP :

Le mot de la fin ?

Dan :

Il y a une chose que je voudrais mentionner : il y a tous les jours plus de redesigns de sites qui utilisent les standards web. C'est une très bonne chose. Ces refontes prouvent que la technologie peut être utilisée aujourd'hui non seulement sur des sites personnels ou pour des bancs d'essai, mais aussi dans des projets du monde réel. C'est excitant de voir qu'on se focalise moins sur la technique et plus sur les résultats.

Celà dit, quand nous voyons quelqu'un qui annonce une nouvelle refonte d'un site faite à partir des standards, la première chose que nous devrions tous faire c'est de le féliciter d'avoir essayé de faire les choses un peu mieux. Parfois notre sympathique communauté peut se montrer trop critique, trop rapide à décortiquer les détails microscopiques de la construction d'un site. J'ai peur que ces dures critiques découragent certains d'utiliser des méthodes conformes aux standards. Nous sommes tous dans le même bateau. Alors «mieux aujourd'hui» vaut plus que «parfait demain».

WaSP :

Un bon conseil pour nous tous. Merci Dan d'avoir pris le temps de nous répondre. Nous attendons avec impatience ton prochain gros lancement !

Dan :

Merci ! Ça a été un plaisir.

Sur le même sujet, lire aussi :

  1. Douglas Bowman (Wired News) Interview
  2. Mike Davidson (ESPN) Interview, Part 1
  3. Mike Davidson (ESPN) Interview, Part 2
  4. WaSP XHTML Resources
  5. WaSP CSS Resources

Fiche technique

À propos de l'auteur

Le WaSP (Web Standards Project), a été fondé en 1998 dans le but de promouvoir les standards web les plus importants et d’encourager les fabricants de navigateurs a faire de même, permettant aini un accès au web simple et abordable pour tous.

Articles similaires

Voici la liste des dix articles les plus récents en rapport avec cet article :

Tous niveaux

Web design

© 2001-2016 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! - RSS / ATOM - About this site