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.
- Marc-Aurèle Darche — Pouvez-vous vous présenter et nous décrire votre activité ?
-
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).
- M.-A. D. — Quelles sont vos principales réalisations pour le Web ? Quelles sont celles dont vous êtes le plus fier, celles que vous préférez oublier ?
-
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.
- M.-A. D. — Quelle(s) formation(s) avez-vous suivie(s) ?
-
N. B. — Aucune, je suis autodidacte.
- M.-A. D. — Quelle(s) formation(s) auriez-vous aimé suivre ?
-
N. B. — Aucune particulièrement. La meilleure formation pour le HTML c'est : regarder la source !
- M.-A. D. — Êtes-vous un indépendant ou bien travaillez-vous dans une structure avec d'autres collaborateurs ? Envisagez-vous de changer cette situation ?
-
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.
- M.-A. D. — Quelles sont les techniques de réalisation de sites Web que vous trouvez les moins productives ? Quelles sont les mauvaises pratiques à éviter selon vous ?
-
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 :
- Concevoir la maquette du site calée au pixel près. C'est une vision exportée du monde de l'édition, qui se fait, heureusement, de plus en plus rare. Un site doit prendre en compte un grand nombre d'inconnues concernant les capacités de rendu pour l'utilisateur final. Idéalement, il faut que le site puisse être compréhensible par un malvoyant utilisant Opera sous BeOS, qui aurait désactivé JavaScript, et qui n'aurait pas le plugin Flash.
- Produire de la « tag-soup ». La « tag-soup » c'était le HTML d'avant-hier : le positionnement géré par des tableaux imbriqués 5 ou 6 fois, remplis de « spacer.gif ». Parce que ces techniques sont bien connues, on pense aller plus vite en les utilisant. En réalité on perd plus de temps qu'on en gagne dès qu'il faut morceler une maquette pour l'intégrer dans un CMS, la maintenir ou la refondre. Il semble qu'en moyenne la durée de vie d'une structure de site soit d'environ deux ans, donc ce ne sont pas des considérations superflues.
- M.-A. D. — Utilisez-vous les standards du Web pour vos réalisations ?
-
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électeura: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.
- M.-A. D. — Que vous apporte l'utilisation des standards ? Quelles technologies préférez-vous ?
-
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.
- M.-A. D. — Avez-vous rencontré des difficultés pour convaincre vos clients d'accepter certaines limitations pour, en contrepartie, tirer avantage des CSS ?
-
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.
- M.-A. D. — Vous êtes sûrement amené à travailler en équipe avec des développeurs applicatifs et d'autres graphistes. Pouvez-vous nous décrire comment se déroulent ces collaborations ? Dans ces cas comment synchronisez-vous vos actions ?
-
N. B. — La taille de l'équipe varie en fonction du projet, mais on retrouve toujours certaines étapes :
- le design du contenu, qui définit la ligne éditoriale, les grandes fonctionnalités et les intentions générales du site ;
- l'architecture de l'information, où l'on décide comment sont agencés les contenus, comment l'utilisateur va naviguer, etc. ;
- la création graphique et multimédia, où une maquette (interactive) est validée ;
- la phase de production à proprement dit, où on intègre les contenu en HTML et/ou en Flash, et où on développe les applications côté serveur.
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.
- M.-A. D. — Quels sont vos formats graphiques de prédilection et quelle est votre façon de procéder par rapport aux très nombreux formats graphiques en général ?
-
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 fichiers de travail. Ils sont dans des formats natifs dépendant des applications utilisées.
- Les fichiers d'échange pour la communication entre les différents collaborateurs. Pour cela on utilise des formats interopérables comme les formats PDF, JPEG, etc.
-
Les formats utilisés pour le produit final. On trouve alors :
- JPEG
- GIF, que l'on remplace parfois par du PNG, mais l'export PNG de Photoshop n'est pas du tout top au niveau de la compression.
- Flash (qui est demandé pour beaucoup de projets). Quand on choisit de faire du Flash, on sait qu'on fait des sacrifices, mais c'est pour avoir d'autres avantages.
- Pour les formats audio ou vidéo, on en propose généralement 2 parmi les 4 plus courants : mp3/mpg, Real, QuickTime ou WindowsMedia.
- M.-A. D. — Connaissez-vous SVG ? Si oui pensez-vous que le trio SVG / SMIL / ECMAScript pourra permettre de faire des choses aussi poussées que Flash ?
-
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.
- M.-A. D. — Quels programmes et quel(s) système(s) d'exploitation utilisez-vous pour votre travail ? Ressentez-vous un manque par rapport aux outils existants ?
-
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.
- M.-A. D. — Quel(s) navigateur(s) Web préférez-vous et pourquoi ?
-
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.
- M.-A. D. — Quelles sont les ressources en ligne que vous consultez lorsque vous travaillez sur un projet ?
-
N. B. — J'utilise les ressources de l'Internet en permanence, des newsgroups, des listes de diffusion et des channels IRC :
- newsgroup CSS CIWAS
- listes de diffusion : CSS-discuss, FlashCoders, TheList d'Evolt.org.
- canaux IRC #web sur freenode.org ou #javascript sur undernet.
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.
- M.-A. D. — Si je vous dis « validation » ?
-
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.
- M.-A. D. — Si je vous dis « accessibilité » ?
-
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…
- M.-A. D. — Si je vous dis « interopérabilité » ?
-
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 !
- M.-A. D. — Les standards, vous les avez connus comment ?
-
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.
- M.-A. D. — Comment faut-il procéder à votre avis pour que les graphistes / designers de sites Web pensent aux termes « standards », « accessibilité » et « interopérabilité » en réalisant un nouveau projet ? Comment les informer ?
-
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 !
- M.-A. D. — Quelles autres questions auriez-vous souhaité que l'on vous pose ?
-
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 !
Vos commentaires
# Romain Le 18 mars 2014 à 17:34
Bonjour,
Je trouve ça vraiment top de lire un article datant de 2004 sur les pratiques en Web design, surtout quand vous repensez aux premières techniques d’époque.
Le Web design évolue à une allure folle, ce qui est "in" aujourd’hui ne le sera plus dans 5 mois c’est vraiment dingue !
J’avoue avoir bien rigolé en lisant cette phrase : " J’ai alors compris que
avait une valeur sémantique, que cela signifiait « titre » et non pas « Times 20pt bold » !" :)
Bref, une très bonne lecture
Vos commentaires
Suivre les commentaires : |