Ned Baldessin, professionnel du Web, nous présente le point de vue des graphistes sur les différentes technologies qui forment les standards de l'Internet.
On pourrait croire que les recommandations du W3C, la problématique de l'accessibilité et les standards de l'Internet en général ne sont pas connus par les graphistes Web… On pourrait également être tenté de penser que les standards apportent plus aux développeurs qu'ils n'apportent aux graphistes…
Ned Baldessin ned-openweb@idsland.com, professionnel du Web, nous présente le point de vue des graphistes sur les différentes technologies qui forment les standards de l'Internet.
Propos recueillis le 16 juillet 2003.
Ned Baldessin — Je suis architecte d'interaction ou, plus simplement, un designer Web.
Le Web design est une composante importante de mon activité, mais ce n'est pas la seule. Dans ce domaine, je travaille sur des projets généralement en tant que Web designer ou en tant que graphiste. Je m'occupe aussi souvent de l'architecture des contenus, mais je peux être aussi amené à gérer la conception et la réalisation complète de sites Web.
Ce sont les interfaces graphiques qui m'intéressent vraiment. J'en ai réalisé pour des applications avec frontal Web, mais j'aimerais aussi pouvoir développer des interfaces de clients lourds (NDLR : par opposition aux clients légers que sont les navigateurs Web).
N. B. — Je travaille sur un grand nombre de projets à la fois et pas uniquement pour le Web. Pour certains projets, j'interviens sur certains points particuliers uniquement. Les projets sur lesquels ma contribution a été majeure sont les suivants :
| Date | Dénomination |
|---|---|
| 2002 | Participation à la conception d'un « goodie » pour le Musée d'Art Moderne Grand-Duc Jean. Développement sur plusieurs intranets de collectivités et d'entreprises (CSF, ECF, Conseil Général du Val de Marne, IDEALX, Vigeo, etc.). |
| 2001 | Divers sites Web d'artistes et de labels indépendants (Katonoma, Rodolphe Burger, etc.). Co-fondation du groupe IDSland, développement de base-design. |
| 2000 | Travail d'architecture de l'information de sites de startups dont LePublieur.com. |
| 2000 | CanalSatellite - Travail sur l'interface graphique de l'EPG, et de son intégration dans le flux vidéo. |
| 1999 | UNESCO - Design d'un outil de travail collaboratif (interface et fonctions) pour des chercheurs disséminés à travers le monde. |
Ceux que je préfère oublier sont déjà oubliés.
N. B. — Aucune, je suis autodidacte.
N. B. — Aucune particulièrement. La meilleure formation pour le HTML c'est : regarder la source !
N. B. — Je suis un indépendant, et j'ai co-fondé avec Olivier Peyricot, Cédric Scandella et Sylvie Chanchus une structure nommée « IDSLand ». C'est un groupement d'indépendants, graphistes, designers, illustrateurs, qui s'est formé autour d'idées communes. Nous avons une approche transversale du design, qui couvre les produits, le graphisme, les interfaces numériques, à travers une méthode de design de contenu. Ce label est destiné à devenir, à terme, une entreprise. En ce qui concerne le site, lancé en 2001, autant le dire tout de suite, il est en pleine refonte.
N. B. — La principale difficulté vient de la collaboration efficace entre les membres de l'équipe : client, DA, Web designer, développeur, etc. Pour pouvoir communiquer son travail aux autres, il faut s'entendre sur des méthodes et des standards.
Pour les mauvaises pratiques, quelques exemples :
N. B. — Les graphistes adoptent des fonctionnalités, pas des standards. En ce qui me concerne, mon utilisation des standards du Web se limite à leur implémentation dans les navigateurs.
Les standards ont commencé à être intéressants pour les graphistes le jour où les standards ont apporté de nouvelles possibilités, en fait le jour où nous avons pu commencer à utiliser les CSS.
Tout a commencé en 1999 je crois, avec la propriété
text-decoration: none; et le sélecteur
a:hover ! Et puis il y a eu le bond en
avant avec l'utilisation de la propriété
line-height, ainsi que la possibilité
d'avoir des fonds de pages qui ne se répétaient pas
(NDR : background: url("image.png")
no-repeat;).
Du point de vue des Web designers, il y a deux « standards » : d'une part les spécifications émises par le W3C, et d'autre part leurs implémentations parfois divergentes dans les navigateurs.
N. B. — De façon très pragmatique les standards, comme les CSS, offrent des possibilités qui étaient impossibles à réaliser auparavant, par exemple dans les domaines du positionnement, de la précision des typos, de la gestion des listes, du contrôle de l'impression.
Mais le gros avantage de l'utilisation des standards c'est que cela permet d'autres méthodes de travail : il est maintenant beaucoup plus facile de travailler en groupe. En séparant la structure (en XHTML), de la présentation (en CSS) et de l'interactivité (en JavaScript), on peut apporter de multiples petites modifications très facilement. Cela permet de décomposer la complexité, et d'éviter que les gens se marchent sur les pieds. Il m'arrive de travailler une journée entière en me concentrant uniquement sur un fichier de CSS, sans jamais avoir à toucher au code HTML. Produire du HTML dit « sémantique », c'est-à-dire avec des balises qui décrivent le type de contenu qu'ils contiennent (<h1> pour un titre, <blockquote> pour une citation, etc.), permet un grand confort de lecture : quelqu'un qui regarde le code pour la première fois va comprendre très rapidement comment la page est construite, ce qui n'est pas le cas avec de multiples tableaux imbriqués. Donc il y a réel avantage pour la maintenance et, plus tard, la refonte.
Je me souviens d'une démo avec des clients où j'ai pu apporter plusieurs modifications assez radicales qu'ils suggéraient directement, sans attendre, et sous leurs yeux. Cette flexibilité est tout simplement impossible à obtenir avec des mises en page basées sur des tableaux où la présentation est mêlée au HTML.
Aussi, utiliser les standards c'est également être indépendant d'un outil. On n'oblige plus toute une équipe à travailler avec les mêmes logiciels.
N. B. — Les maquettes en HTML/CSS pur ont commencé à être utilisées massivement justement à partir du moment où elles ne constituaient plus une limitation par rapport aux tableaux. Je n'ai encore jamais eu de clients qui aient acheté un projet sur une base de l'utilisation des standards. Le point de négociation porte sur les navigateurs qui sont supportés et ceux qui ne le sont pas. Le client fait confiance et attend que lui soit livré un travail de bonne qualité. Mais le client n'a généralement aucune idée de ce que sont les standards du Web, et par conséquent ne vérifie pas la validité de ce qu'il achète. C'est dommage.
N. B. — La taille de l'équipe varie en fonction du projet, mais on retrouve toujours certaines étapes :
C'est important de faire des choix en amont sur les capacités de l'utilisateur final (quel public, quels navigateurs, quelles plates-formes, quelle bande passante, quels plugins, etc.). C'est la responsabilité de chacun de fournir aux autres des données facilement utilisables : le graphiste va fournir toutes les images et typos nécessaires à l'intégrateur HTML, qui va fournir une page HTML monolithique propre et lisible au développeur pour en faire un template, etc. Lorsque l'on fait du développement Flash, il faut se mettre d'accord sur les interactions entre le client Flash et les applicatifs (transferts XML, remoting, etc.). Et on utilise les mêmes méthodes de communication que tout le monde : réunions, calendriers, emails, chats IM ou IRC.
N. B. — Avant de parler de formats graphiques de prédilection, il faut bien être conscient que dans le développement d'un site il y a 3 types de fichiers utilisés :
Les formats utilisés pour le produit final. On trouve alors :
N. B. — Oui je connais ECMAScript et SVG. Pour le SVG, je trouve le plugin d'Adobe plutôt lourd et instable. SMIL je ne connais qu'un peu. Encore une fois c'est l'implémentation de telle ou telle technologie qui nous préoccupe. Si l'implémentation dans les navigateurs est mauvaise ou inexistante, c'est forcément moins intéressant. C'est le cas du SVG.
N. B. — J'utilise des Mac depuis toujours. Depuis fin 2002 ma plate-forme de travail de base est Mac OS X. Au bureau, j'ai également un serveur GNU/Linux qui fait tourner mes sites en PHP. J'utilise enfin Windows XP dans un émulateur pour effectuer des tests de compatibilité avec MSIE.
Pour ce qui est des autres outils, j'utilise Photoshop, Illustrator, parfois Fireworks et Flash, puis un éditeur de texte (BBedit) et CVS par le biais d'une interface graphique. J'utilise aussi une flopée de bookmarklets et de sidebar tabs dans mes navigateurs, surtout pour le débogage.
Je n'utilise plus Golive depuis la version 3, et j'ai même laissé tomber Dreamweaver parce qu'il ne m'a rien apporté quand je me suis mis aux CSS. Il semble que pour la version MX 2004 les choses soient améliorées, mais cela ne dispense en rien la connaissance du langage.
N. B. — Pour travailler, c'est Mozilla. C'est le navigateur qui respecte le plus grand nombre de standards. C'est la référence, particulièrement pour les CSS. Et puis sa console JavaScript est très, très pratique pour les développeurs. Il y a également le visualisateur DOM qui permet de déboguer les CSS en montrant quels sont les styles de chaque élément de la page. J'oubliais « Venkman », le débogueur JavaScript, qui doit être très utile, mais il ne paraît pas facile à utiliser. Tu sais l'utiliser toi ?
J'utilise également Safari qui tire parti de l'interface graphique native de Mac OS X. Il est rapide et forcément très bien intégré à l'ergonomie du Mac. Safari est très agréable à utiliser, même s'il n'est pas aussi évolué que Mozilla au niveau du support des CSS.
Bien entendu, j'ai toute une palette d'autres navigateurs qui me servent à tester : Opera, IE, Lynx, etc.
N. B. — J'utilise les ressources de l'Internet en permanence, des newsgroups, des listes de diffusion et des channels IRC :
Même si la question porte sur les ressources en ligne, il faut aussi que je mentionne le livre Cascading Style Sheets 2.0 Programmer's Reference de Eric Meyer qui m'est toujours indispensable.
Pour le HTML je consulte généralement directement les spécifications sur le site du W3C sur des points très précis de sémantique en fonction d'un DOCTYPE particulier.
N. B. — Je valide l'ensemble de mes pages (X)HTML et de mes fichiers CSS lorsque je termine un projet. Pour cela j'utilise le validateur HTML et le validateur CSS du W3C. Il arrive de moins en moins que je parte dans une réalisation en sachant pertinemment que le résultat final ne sera pas valide. Donc l'étape de la validation et des corrections éventuelles ne me prend pas beaucoup de temps. Dès que tu connais les règles pour chaque DOCTYPE, tu n'as plus besoin de valider au fur et à mesure.
N. B. — C'est une préoccupation grandissante à la fois parce que c'est une exigence de plus en plus forte pour les services publics, au sens large, aux États-Unis et en Europe, et aussi parce que cela donne la satisfaction de réaliser un travail de qualité. À ce jour, je n'ai pas encore eu de demande explicite dans ce sens de la part de clients, mais cela ne m'empêche pas de réaliser des créations accessibles ou le plus accessible possible. La voie entre le 100% accessible et la conception graphique est tout de même assez difficile…
N. B. — Je ne suis pas sûr de connaître la définition exacte de ce qu'est l'interopérabilité, alors j'interprète ça comme le fait pour une réalisation d'être « trans-plate-forme ». Dans ce cas, c'est faire des contenus qui puissent être utilisés et échangés sur et entre n'importe quelle machine. Ça peut être obtenu par l'utilisation de formats standards. Il y a aussi la notion de pouvoir garder des données et de les faire ensuite facilement évoluer. Par exemple travailler avec du XHTML Strict, c'est travailler avec un format standard, et c'est surtout travailler uniquement au niveau sémantique. Travailler au niveau sémantique est une très bonne manière de s'assurer que l'information pourra facilement être récupérée et exploitée plusieurs années après.
Le XML est un bon format standard d'échange de fichiers. XML c'est à la base de RDF, RSS, etc. Tout le monde a bien intégré qu'il fallait utiliser XML, et quand on fait du XHTML, on fait du XML !
N. B. — Pour moi il y a eu une coupure brutale en 2001. Je me suis senti submergé par la masse des bugs, des balises propriétaires, et des fonctions JavaScript spécifiques. J'avais l'impression de marcher sur un terrain miné. Soudainement j'ai décidé qu'écrire une même page en double (une version pour Netscape 4.x, une pour IE4.x, le tout ficelé avec du JavaScript) n'était plus acceptable, que ce n'était pas une bonne méthode de travail. Les standards offraient une alternative : concevoir des pages selon des règles abstraites, connues de tous, précises, inaltérables. Avec la perspective à long terme que ceux qui conçoivent les navigateurs adoptent également ces règles.
Le bond conceptuel, ça a été le jour où j'ai compris que le HTML voulait dire vraiment quelque chose ! J'ai alors compris que <h1> avait une valeur sémantique, que cela signifiait « titre » et non pas « Times 20pt bold » !
Les standards m'ont permis de quitter cette voie dans un mouvement qu'on pourrait décrire comme : « halte au bidouillage ». Utiliser les standards c'est mettre tout à plat, comprendre ce que l'on fait en suivant des règles définies. Au début, on découvre tout ce que les standards, comme les CSS, définissent comme possibilités ; on se sent très enthousiaste. Et puis on se calme vite lorsqu'on s'aperçoit qu'en fait, on est limité par l'implémentation des standards au niveau des navigateurs. Les navigateurs n'implémentent pas toute la spec CSS2, et parfois pas même CSS1. Ensuite certains navigateurs comme MSIE implémentent mal certaines parties des spécifications (le box-model dans IE 5 par exemple). De temps en temps il faut encore avoir recours à quelques « hacks » spécifiques à MSIE 5.5, MSIE 6.0, MSIE Mac 5.0 ou encore Opera pour contourner leurs limitations. Mais j'essaie de résister.
N. B. — Il faut qu'ils comprennent que produire des sites selon des standards, c'est plus facile et à la longue plus rapide. Il faut qu'ils comprennent que cela permettra à d'autres d'utiliser et de faire perdurer leur travail lors d'une prochaine refonte. Pour ce qui est de l'accessibilité, c'est un acte de civisme normal, qui devrait être inscrit dans la charte déontologique des Web designers (s'il en existait une).
Il faut enfin dire aux graphistes que le meilleur est à venir, que CSS3 va nous apporter des blocs aux coins arrondis et les cadres ombrés, et surtout le multicolonnage et les typos téléchargeables. J'attends ça depuis 1997 !
N. B. — Par exemple, j'aurais bien voulu que nous discutions
du travail de David Hyatt qui est passé de l'équipe de
développement de Mozilla à celle de Safari chez Apple.
J'ai suivi avec grand intérêt cet hiver
son blog.
C'est très amusant de le voir trembler à l'idée
d'avoir à implémenter la directive overflow:
auto; on se sent moins seul dans nos
galères !