fastclemmy.com

Quand la RATP veut faire passer ses clients de l'âge de pierre au stade de l'Homo Modernus, elle lance le site Objectif Respect et ça fait mouche !

Soutenu par une campagne presse et affichage signée Human to Human (voir le post d'Aziz à ce sujet), le site a été entièrement réalisé par l'agence Upian.

L'utilisateur est invité à parcourir les différents thèmes liés au respect dans les transports en commun : incivilités, vandalisme, fraude, etc. Chacun de ces thèmes est illustré par un jeu, un quizz, un documentaire et aboutit sur un forum où les clients sont invités à donner leur avis sur le sujet. Intelligemment construit, sans tomber dans le piège du ton moralisateur, la mécanique du site fonctionne à plein.

Par ailleurs, la réalisation sans faille, que ce soit au niveau de la qualité de la vidéo, de la fluidité de l'animation, en fait pour moi un des sites incontournables de cette rentrée !

Et vous, qu'en pensez-vous ?

#conceptionWeb

Non ce n'est pas un SimpleQuiz, un ToughQuiz ou un AccessQuiz, mais juste une interrogation que j'aimerais partager avec vous.

Parmi les bonnes pratiques du web, il est de bon ton de réfléchir à la structure de son site avant de se lancer afin de pouvoir avoir des URLs sympas. L'idée générale c'est qu'il est plus cool d'avoir des http://www.mondomaine.com/produits/jardinage/desherbants/ que des http://www.mondomaine.com/cgi-bin/processShop.nsf?relatedPath=//820871exBV47/desJ_43/. Meilleure lisibilité, meilleur référencement, mémorisation facilitée, y'a pas à dire, c'est vraiment sympa les Cool URLs.

Seulement une autre bonne pratique consiste à penser également à l'internationalisation de votre site. Peut-être que pour le moment votre site n'est qu'en français, mais quand votre audacieux business model séduira les investisseurs, il faudra voir plus grand et surtout dans d'autres langues !

Votre http://www.mondomaine.com/produits/jardinage/desherbants/ qui avait l'air si cool tout à l'heure devient nettement moins tripatif maintenant que vous voulez acheter un spot de 30 secondes pendant le Super Bowl...

Alors, quelle solution privilégiez-vous pour l'URL anglaise de votre site ?

  • http://www.mondomaine.com/produits/jardinage/desherbants/?lang=en
  • http://www.mondomaine.com/products/gardening/grass-killer/ avec un super système sous le capot qui gère intelligemment le contenu
  • Une solution intermédiaire ni vraiment anglaise, ni vraiment française pour faire illusion dans les deux langues
  • ou une autre idée géniale ?

N'hésitez pas à donner vos retours d'expérience en la matière dans les commentaires, notamment avec les détails techniques sur la gestion des URLs côté serveur (solutions avec mod_rewrite, etc.).

#conceptionWeb

Etonnant de voir comment ce qui fait grand bruit chez nos voisins anglophones passe tout à fait inaperçu dans la blogosphère francophone. Tout comme l'apparition du social tagging, AJAX -le nouvel acronyme désignant l'utilisation de javascript et en particulier d'XMLHTTPRequest pour rendre les applications réactives (Google Maps, Google Suggest et consors)- est complètement passé sous silence... Peut-être est-ce le fait que cela dépasse un peu le cadre habituel de la blogoroutine des standards, toujours est-il que le phénomène est à mon avis suffisamment intéressant pour que l'on s'y attarde...

AJAX, nouvel emballage pour un vieux produit

AJAX, c'est le nom baptismal donné par Jesse J. Garrett à un regroupement de technologies :

  • XHTML/CSS
  • Javascript/XMLHTTPRequest/DOM
  • XML/XSLT

Très bien, mais concrètement ça donne quoi ? Gmail, Google Suggest, Google Maps (Y'a blogmarks aussi, à droite) sont des exemples concrets et à grande échelle de son utilisation. L'idée qui sous-tend tout cela, c'est d'éviter le processus de rechargement de la page web à chaque action. Dans Yahoo!Mail, quand je supprime un e-mail courriel, la page se recharge et me réaffiche la liste de mes messages. Dans Gmail le processus est strictement le même, à la différence près que celui-ci est quasi-instantané car le système fait sa cuisine en coulisses grâce à javascript. L'utilisation d'une application web devient enfin "seamless" comme disent les anglo-saxons, fluide pourrait-on traduire. Difficile en fait de rendre par l'écrit cette impression, le mieux est d'utiliser lesdites applications pour s'en rendre compte. Fiftyfoureleven liste d'ailleurs un grand nombre d'entre elles.

Si l'article de Garrett a le mérite d'avoir trouvé un nom mnémotechnique pour définir ce mécanisme (c'est vrai, ça sonne presque comme un produit lessivier), il soulève des critiques justifiées car il se base sur les exemples AJAX existants pour expliquer concept. Il en ressort que la théorisation faite d'AJAX (utilisation d'XML/XSL par exemple) se vérifie dans le cas particulier de Google Maps, mais ne s'appliquera pas forcément dans une autre application AJAX. Y'a un peu tromperie sur la marchandise en somme.

Par ailleurs l'article fait à peine mention du fait que le concept de l'application réactive n'est pas vraiment nouveau. On l'indique simplement en bas de page dans les Q&A, où l'on fait aussi mention du fait que non XML/XSL ne sont pas des prérequis dans l'équation AJAX... Bonjour l'embrouille.

Si je comprends bien, tout ça c'est du flan ?

Pas vraiment en fait. En effet, on pouvait déjà avoir des mécanismes de ce genre avec des solutions que l'on qualifiera pudiquement de "peu élégantes".

Ce qui est intéressant avec cette "nouvelle" approche c'est :

  • que Google a validé le concept en le déployant à grande échelle, donc que ça marche
  • que les technologies utilisées reposent sur de véritables standards (à la réserve près qu'XMLHTTPRequest est une invention de Microsoft implémentée par tous les gros navigateurs, mais la standardisation est à l'étude)
  • que la réapparition de ces technologies réactives intervient à un moment où le microcosme des développeurs web s'intéresse à des concepts comme l'ergonomie, l'accessibilité, etc. Nul doute donc que ce qui sortira de la marmite aura un bon goût de technologie mature et intelligente.

Voilà pour un rapide état des lieux et quelques perspectives qui se dégagent déjà. Il semble donc que l'avènement annoncé de DOM en 2005 se matérialise peu à peu avec AJAX...

#conceptionWeb

La récente réunion de W3Québec à laquelle j'ai assisté dernièrement m'a ouvert les yeux sur les certitudes que je m'étais forgées concernant l'accessibilité web.

La discussion portait sur la définition de l'accessibilité. Dans sa formulation d'alors, celle-ci mentionnait les deux grandes composantes que l'on connaît :

  • l'accessibilité pensée spécifiquement pour les utilisateurs handicapés
  • l'accessibilité dite "universelle" (qui profite à tous quel que soit le browser, le moyen d'accès à Internet)

Cette dernière est une acception récente du terme "accessibilité". Enfin disons pour être plus précis que la prise de conscience en est récente. On pourrait en effet attribuer la paternité de ce concept à Tim Berners Lee, considéré comme le père d'Internet, autant dire que ça ne date pas d'hier...

Toutes les bonnes raisons "d'oublier" les handicapés quand on parle d'accessibilité pour se concentrer sur l'accessibilité universelle sont développées dans l'article d'Eric Daspet paru sur Cybercodeur. Quelque peu polémique (surtout dans le ton malicieusement provoquant), le texte a eu un écho très positif dans la communauté. Beaucoup, moi le premier, en ont réutilisé les arguments afin de "vendre" l'accessibilité. Comme le faisait remarquer Denis Boudreau le côté "moralisateur" insistant sur l'obligation -légale dans certains pays- d'offrir un contenu aux personnes dites handicapées n'était pas vraiment "sexy". Au contraire, parler de l'amélioration du positionnement dans les moteurs de recherche, de la possibilité d'avoir un site consultable directement sur un téléphone portable ou un PDA accrochait bien plus souvent l'auditoire.

Par une manoeuvre finalement assez tordue, on essayait ainsi de vendre l'accessibilité, non pas sur ses objectifs initiaux (relire les recommandations WAI pour se les remémorer), mais sur les avantages collatéraux qui en découlaient.

A mon sens, on touche là aux limites de l'approche cloisonnée consistant à promouvoir de manière indépendante l'accessibilité, la sémantique web, la validation HTML. Comme je le soulignais déjà dans un billet d'humeur précédent sur le piège de l'accessibilité, on a sans doute beaucoup à perdre à essayer de faire passer notre discours sur la qualité web sans essayer d'expliquer le message dans sa globalité. L'accessibilité n'est qu'une composante parmi d'autres du nouveau web que nous essayons tous de promouvoir.

Il peut paraître séduisant -car plus simple- d'avancer par petites touches, en glissant un soupçon d'accessibilité ici, un peu d'XHTML valide par là. Ceci est d'autant plus compréhensible quand on connaît la réalité des projets et des leurs contraintes (timing, budget, compétence des équipes). Pourtant, je reste convaincu qu'il est dans notre intérêt d'agir au grand jour, pour ne pas avoir à jouer sur les concepts comme expliqué plus haut. Cohérence et sincérité, voilà les deux seules motivations qui devraient nous guider.

#conceptionWeb

Intéressant phénomène que celui qui fait grand bruit chez nos amis anglophones (et à peine chez nous). L'objet de tant d'ébullitions ? Les tags. Aucun lien avec une quelconque activité illégale de peinture urbaine, il s'agit simplement du développement d'un système permettant aux internautes d'enrichir l'information disponible sur le net grâce à des métadonnées. Porte-étendards de ce mouvement : del.icio.us qui permet de partager ses favoris et flickr qui permet de publier ses photos en ligne. Explications et pistes de réflexion sur ce qui pourrait bien dépasser le stade de l'épiphénomène...

Tout vient en fait d'un constat assez simple : le déferlement journalier de l'information a atteint un point qu'il devient de plus en plus difficile de la classifier, de l'archiver et surtout de la restituer à ceux qui la recherche par la suite. Même si certains doutent de la réalité de ce déluge (non je n'ai pas osé dire tsunami), il est sûr qu'une course est engagée tous azimuts pour ne rien en manquer (agrégateurs RSS, blogmarks, Google News, etc.).

Le phénomène del.icio.us

C'est dans ce cadre qu'on a vu débarquer del.icio.us. Au-delà de l'astuce du nom de domaine, le service web répond à une vraie demande de la part des utilisateurs. Malgré un format normalisé pour les favoris (XBEL), les différents navigateurs utilisent leur propre format pour stocker les bookmarks. Par ailleurs le stockage en local expose potentiellement l'utilisateur à la perte de ses informations (virus, plantage de machine, formatage...), la bonne solution est donc évidemment de profiter du réseau pour une sécurité et une mobilité accrue. C'est justement ce que propose del.icio.us, mais à la différence d'un mylinea par exemple, il offre un double avantage : l'aspect collaboratif et l'exploitation des métadonnées.

Métadonnées, mouais, concrètement, ça veut dire quoi ? Traditionnellement les métadonnées sont définies comme de l'information sur l'information ("data about data"). Les internautes partagent grâce à del.icio.us leurs marque-pages, ils ne les classent pas dans des dossiers mais leur attribuent des "tags" ou "mots-clés", ils enrichissent l'information brute (l'URL) par une autre information (le mot-clé). Ainsi, fastclemmy.com par exemple est marqué par les termes suivants : "blogs", "css", "xhtml", "français", "standards-web", "web"... Le résultat peut paraître chaotique (il l'est d'ailleurs certainement de facto) et pourtant il s'avère terriblement efficace. Contrairement aux usines à gaz de la métadonnée (Dublin Core, DocBook...), la mise en oeuvre est intuitive, rapide et pertinente.

Le processus est intéressant dans la mesure où, à l'instar des wikis, le marquage des tags est collaboratif. Le travail de classification de l'information n'est plus subordonné à une équipe ou à un outil informatique (par définition non-intelligent) mais à un nombre élevé d'utilisateurs. On parle de classification distribuée.

Le phénomène s'étend... et trouve déjà ses limites

D'autres services ont emboité le pas à del.icio.us. J'ai parlé plus haut de Flickr, qui permet de partager ses photos et de les annoter avec des tags. Récemment c'est aussi Technorati, sorte de baromètre des weblogs, qui proposait une syntaxe simple <a rel="tag" href="http://technorati.com/tag/[tagname]"> pour voir de quoi on parle dans la blogosphère.

Autant dire que ça bouge pas mal dans le domaine en ce moment... et on ne tarde pas à cerner rapidement les limites de ce système : les conséquences sociales, la montée en charge des systèmes de tags, les abus, etc. On l'aura compris, ce nouvel outil n'est pas parfait, le contraire serait étonnant pour un phénomène aussi jeune. Les métadonnées c'est l'avenir mais c'est encore un peu jeune...

Et Google dans tout ça ?

A mon avis, tout ce mouvement doit en faire réfléchir plus d'un chez Google... Je ne doute pas qu'ils soient toujours à l'affût des nouveautés en termes de technologie de l'information. On l'a déjà vu avec l'expérimentation de Google Suggest, ce petit "plus" qui permet d'affiner sa recherche en temps réel grâce à l'utilisation de javascript/xmlhttprequest. Leur intérêt pour des techniques alternatives de ce genre est d'autant plus probable que leur décision d'introduire l'attribut rel="nofollow" sonne comme un aveu d'échec de leur algorythme de recherche PageRank. Pourtant, cet échec (relatif, Google reste l'un des moteurs de recherche les plus pertinents) n'est pas le premier : l'indexation manuelle des sites dans des annuaires a fait long feu (que ce soit par une "petite" équipe chez Yahoo ou l'appel international de DMOZ), les méta-moteurs ont fait un flop, etc. La distribution classifiée pourrait être l'un des moyens pour Google d'améliorer un peu plus sa pertinence.

Imaginez un Google qui combinerait ses différentes sources d'informations : DMOZ, informations HTML des pages (balises <title>, titrages, emphases), PageRank ET tagging. Car s'il est illusoire de penser que le phénomène de tagging est une révolution, il me semble plutôt qu'il s'agit d'un outil de plus pour mettre en place une approche combinatoire de la recherche d'information.

Tout ceci bien sûr en attendant que les metadonnées atteignent enfin votre bureau...

#conceptionWeb

L'effet de loupe joue sans doute un peu, mais une chose est sûre : on parle de plus en plus de l'accessibilité. Et quand je dis "on", je parle non pas de notre microcosme blogosphérique, mais bien d'un cercle plus élargi, celui des sites informatiques "grand public".

Cela tient sans doute au fait qu'un projet de loi sur "l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées" est actuellement en discussion auprès de nos sénateurs et députés. On voit donc fleurir ici et là des articles sur le sujet, des interviews, des dossiers chez le Journal du Net, Zdnet ou encore Neteconomie.

Premier écueil, les intervenants généralement interrogés sur le sujet sont surtout là pour vendre leur solution propriétaire (ne comptez pas sur moi pour leur faire de la pub). Plus que l'accès pour tous à l'info, ce qui les intéresse c'est que le plus de clients possibles aient accès à leur produit ! On passe bien souvent sous silence qu'aucune rustine coûteuse n'est nécessaire pour rendre un site accessible. Un simple tour chez Accès pour tous devrait vous en convaincre.

Deuxième écueil, dissocier le concept d'accessibilité des autres concepts promus par les standards du web (conception par blocs, validité du code, sémantique) est à mon avis terriblement dangereux. Si il est clair que ces domaines sont bien distincts, ils participent tous d'une même philosophie prônant un meilleur web. D'ailleurs, faut-il rappeler qu'il faut oublier les handicapés quand on parle d'accessibilité ? On a tout à perdre à laisser s'installer une accessibilité-rustine (comprenez reposant sur des solutions propriétaires). C'est à nous de fournir l'effort pour réussir à imposer les standards dans toutes leurs dimensions, sans quoi le défi de l'accessibilité se transformera en défaite pour les standards.

#conceptionWeb

Au voleur !

# 03-02-2004

Article original du 15.09.2003 - Une chose dont on parle assez peu sur les blogs XHTML/CSS (mon obsession de parler de choses originales me pousse donc à en parler), c'est le piratage de design facilité par l'utilisation de la conception par blocs.

Je dois avouer que c'était pas une chose à laquelle je n'avais pas pensé, mais le problème a été soulevé par un ami sur un forum. Il se plaignait de la non "sécurisation" des CSS : en volant la feuille du style d'un site, on peut très facilement faire la mise en page d'un autre site en changeant quelques images et en insérant son contenu dans la page HTML. Certainement plus simple que de repiocher dans le code fouilli d'un site fait à base de tableaux (encore que ?).

Preuve faite avec Openweb, référence francophone en matière de conception par blocs qui se faisait plagier à de nombreuses reprises. Preuve aussi avec le créateur du CSSZenGarden qui a tergiversé quelques jours pour déterminer sa position sur les conditions de mise à disposition des designs créés pour le CSSZenGarden. Dans les deux cas, les propriétaires des sites plagiés ont laissé globalement faire, se disant à juste titre, AMHA, que le préjudice subi n'était pas si terrible au fond.

Cela dit, cette problématique ne peut que nous faire réfléchir sur le degré de malhonnêteté de certaines personnes...

Mise à jour du 03.02.2004 - Un petit tour dans mes référents m'a fait tomber sur ce site de danse. Pas vraiment un voleur, puisque je suis cité en tant qu'auteur du design original, mais comme quoi, personne n'est à l'abri...

#conceptionWeb

Parmi les nombreuses approximations et contre-vérités de cet article du webzine Emma à propos des défenseurs de la conception par blocs, celles sur l'accessibilité ont de quoi faire réagir.

Tout d'abord, un petit rappel. L'accessibilité -ce mot est vraiment très laid mais ce n'est pas le sujet- c'est quoi ?

L'accessibilité consiste à rendre l'information disponible pour tous les utilisateurs sans discrimination. Traditionnellement, on prend comme exemple un handicapé qui surfe sur Internet avec un navigateur Braille, autant dire qu'un site tout en Flash ne lui sera pas très accessible. Est-ce le bon exemple ? On se confronte souvent en l'utilisant à des railleries du type "Et tu en connais beaucoup toi, des aveugles qui utilisent Internet ?" et cela reflète bien les lieux communs associés à l'accessibilité.

Pour beaucoup, se pencher sur cette problématique c'est perdre du temps pour un pourcentage très infime de visiteurs.

Pourtant, la démarche n'est pas propre à la conception de site web : on serait par exemple choqué de voir un architecte qui édifie un bâtiment sans prévoir de rampe d'accès pour les poussettes ou les fauteuils roulants, non ? A fortiori alors que 2003 a été décrétée année européenne du handicap !

Sur le web, faciliter l'accès à l'information pour tous est même plus simple, pas besoin comme le conseille JF dans son article d'EMMA de

(...) Générer des versions complètes adaptés à des critères d'accessibilité en quelques secondes. On effectue quelques modifications dans des modèles, on régénère le site et on le met en ligne.

Je suis certain que le patron de JF serait content de savoir qu'avec un modèle en XHTML/CSS le site serait tout aussi accessible pour lui sur son Internet Explorer que pour les handicapés ou que pour Google.

Quel rapport avec Google ? Et bien tout simplement qu'il navigue sur Internet comme quelqu'un le ferait avec un navigateur texte : pas de Flash, pas de javascript, pas d'images. Castrateur n'est-ce pas ? Et bien non. Car est-il besoin de rappeler qu'on peut faire des sites jolis, accessibles et standards sans pour autant faire des pages aussi austères qu'une recommandation du W3C ? C'est ça la grande force des sites conformes aux standards : offrir un accès vers un site très joli pour les derniers navigateurs graphiques mais en même temps un accès vers le contenu pour tous.

La question n'est donc pas "Pourquoi se préoccuper de faire un site accessible pour les quelques handicapés qui pourraient venir sur mon site ?" mais plutôt "Pourquoi faire plusieurs versions d'un même site si on peut offrir un contenu adapté pour tous ?".

Pour en savoir plus sur le sujet, je vous conseille de vous reporter à la section concernée chez Tristan ainsi que chez Denis et Stéphane.

#conceptionWeb

Article original du 04.08.03 - Un (des nombreux) grief(s) que l'on m'a fait à propos de ce site c'est le fait que les sites du portfolio ou que le PDF du CV ne s'ouvrent pas par défaut dans une nouvelle fenêtre. Bien sûr un target="_blank" résoudrait le problème, mais pour toutes ces bonnes raisons je ne le ferai pas.

Ce problème illustre le fait qu'une mauvaise habitude de conception web a été inculquée aux internautes : pour eux un lien vers un site extérieur doit forcément ouvrir une nouvelle fenêtre. Or ce n'est pas au site d'imposer son type de navigation, si l'utilisateur veut ouvrir un lien dans une nouvelle fenêtre c'est à lui d'utiliser les possibilités de son navigateur. D'autant que cela peut se faire d'un seul clic avec un navigateur digne de ce nom.

Mise à jour du 14.11.03 - Extraits d'une (vive) discussion sur le sujet

Pourquoi ouvrir une fenêtre casse la navigation linéaire ?

Dans un browser web, la navigation est par définition linéaire : on surfe de lien en lien. Ouvrir des nouvelles fenêtres casse cette linéarité. Non pas que ce soit mauvais en soi, c'est juste qu'il faut que l'utilisateur en soit conscient (rien n'indique généralement sur une page si le lien va s'ouvrir dans une nouvelle fenêtre). Le meilleur moyen étant que lui-même fasse le choix d'ouvrir une nouvelle fenêtre, cessons de forcer la main aux gens, de perpétuer cette sorte d'assistanat de la nouvelle fenêtre. Soit c'est effectivement un newbie et la navigation linéaire ne le déroutera pas, soit c'est un power-user et il pourra à son gré ouvrir le lien qu'il veut dans une nouvelle fenêtre ou dans un nouveau tab.

Bel exemple de connerie jusqu'au-bout-iste... Désolé, mais quand sur mon site je fais un lien vers ailleurs, j'ai pas envie de perdre mes visiteurs !

Je pense que tu n'as pas saisi la logique du truc. Ouvrir une nouvelle fenêtre, c'est jouer avec le navigateur de la personne, c'est donc logiquement le rôle de javascript, pas du HTML, il est donc normal qu'en utilisant en DTD stricte on se fasse envoyer paître.

Imposer l'ouverture d'une nouvelle fenêtre au visiteur, ça fait partie de ces vieilles habitudes qu'on traine et qu'il faut s'efforcer d'oublier. D'autant qu'il n'est pas évident pour quelqu'un qui utilise peu Internet, enfin quelqu'un de normal quoi, pas comme nous, de comprendre le mécanisme de l'ouverture d'une nouvelle fenêtre (impossible de faire "Précédent", fenêtre ayant bougé, redimensionnée...).

Le webmaster et lui seul doit pouvoir décider comment on navigue sur son site, avec de nouvelles fenetres s'il veut.

Erreur. C'est au visiteur de décider comment il veut naviguer. Moi par exemple j'ai horreur des target blank, je middle-click tous les liens pour qu'ils s'ouvrent plutôt dans un nouveau tab puisque mon navigateur dispose de cette fonction.

Le client est roi. C'est aussi dans cet esprit que tu ne dois pas baser ta navigation sur javascript par exemple, au cas où ton visiteur n'aurait pas cette fonction activée (le robot de Google par exemple ?).

#conceptionWeb

Changer de style ?

# 01-10-2003

Post original 25.08.03 - Dans ma todo list se trouve en première position : Trouver l'intérêt de proposer un style switcher sur le site. La question de l'opportunité d'un style switcher sur un site me taraude en effet depuis pas mal de temps déjà.

Pour les non-initiés, un style switcher apparaît la plupart du temps sous la forme d'un petit menu déroulant permettant de sélectionner un autre "style" de mise en page, très concrètement cela revient à recharger la page courante avec une feuille de style différente. Sur ce site par exemple, on pourrait imaginer que je fasse une feuille de style alternative où les informations s'afficheraient verticalement.

Si vous parcourez un peu les différents weblogs traitant comme le mien de l'XHTML-CSS, vous constaterez que ce petit outil est présent dans nombre d'entre eux, effet de mode sans doute... Mais côté utilisateur, cela apporte-t-il vraiment quelque chose ? En regardant mon expérience personnelle, je me rends compte que passé l'effet de surprise que je peux avoir en regardant les différents styles (la plupart du temps ils sont quand même relativement similaires, exception faite du cssZenGarden), je me fixe sur l'un d'entre eux et je n'en change presque jamais. Preuve que le style switcher tient plus du gadget que d'autre chose.

Ceci dit, grâce aux feuilles de style on peut changer non seulement la présentation mais aussi le contenu d'une page grâce à la propriété display des éléments. Et c'est peut-être de ce côté que la réflexion est à mener. Qu'en pensez-vous ?

Mise à jour 26.08.03 - L'ami Talou avance 3 arguments en faveur d'un style switcher. Tout d'abord le confort de lecture. Il est vrai que je ferai sans doute quelques heureux en créant une feuille de style verticale, mais d'une part ce genre de choix n'intervient généralement qu'une fois et le rapport temps passé pour créer un style alternatif/intérêt ne me paraît toujours pas probant.

Ensuite, Talou nous expose deux idées qui à mon sens se rejoigne : il s'agit de la démonstration de la puissance des CSS/du talent du webdesigner. Soit. Mais ces deux arguments ne sont valables que pour un public averti : il est certain que sur un blog parlant de l'XHTML+CSS, le public sera sensible à la qualité (technique) des styles alternatifs, pas sur un site grand public.

Pour mon blog, n'ayant toujours pas trouvé d'argument convaincant, je ferai l'impasse (pour le moment) sur un style switcher, ça tombe bien j'ai déjà quelques autres choses à faire dans ma todo list.

A noter également que du côté de Darken et d'Anubis, ça bouge dans les style switchers.

Mise à jour 01.10.03 - La lecture d'un post sur un nouveau blog anglophone me conforte dans mon idée. Sans en remettre en cause l'utilité, Vinnie se plaint du temps que lui prend le travail sur des feuilles de style alternatives et je le comprends !

#conceptionWeb

Article original 17.09.03 - Je me suis fait épingler par mail aujourd'hui. Sujet de récrimination, la phrase tirée de mon log précédent : Qu'un site fait avec Dreamweaver par un graphiste dans sa web agency ne valide pas parce qu'il ne sait même pas de quoi il s'agit, c'est normal, chacun son job. Pas de bol pour moi, le seul graphiste féru de CSS lit mon weblog ;-)

Mes plates excuses à mon lecteur créatif froissé, mais le syndrome du graphiste en matière d'XHTML+CSS est une réalité que je constate quotidiennement. Il est clair qu'à la base, la conception à base de blocs (par opposition à la conception à base de tableaux) a d'abord attiré l'attention des gens qui s'occupent de la technique plutôt que de l'aspect graphique des sites, ceci expliquant les sites web trop carrés. Ceci au même titre qu'un patron se sert mal de Word en utilisant les boutons de sa barre d'outils plutôt que d'utiliser les styles de texte.

Les graphistes qui font du web ne s'intéressent pour la plupart pas au côté technique, ils préfèrent passer du temps sur leur maquette dans Photoshop que de se creuser les méninges sur les bugs d'affichage du site une fois affiché dans IE. De même, l'outil fétiche de cette génération de webdesigners est plutôt Dreamweaver qui permet de mettre en page un site visuellement et rapidement (en recourant massivement aux tableaux pour structurer la page). Changer de méthode est donc pour eux un plus gros bouleversement que pour les programmeurs qui utilisaient les tableaux certes, mais qui codaient déjà avec un éditeur de texte. Car en l'absence d'outils performants pour le moment (et le dernier Dreamweaver n'y change rien ou presque), concevoir en blocs impose d'utiliser un éditeur de texte plutôt qu'un outil WYSIWYG.

Je persiste et je signe donc, la conversion des graphistes web à l'XHTML+CSS est un vrai challenge, tant mieux si de nouveaux adeptes apparaissent (et me lisent !).

Mise à jour 23.09.03 - Effectivement, des graphistes me lisent ! Certains critiquent d'ailleurs (sans doute à raison) le sectarisme de mon propos; qu'ils n'oublient pas le parti pris quelque peu "provoc" de ce blog, qui en pimente le contenu selon certains. D'autres partagent mon avis comme Gaëtan, dont je publie ci-dessous l'opinion -elle aussi un peu provoc- in extenso.

Le graphiste, ... Il vient souvent d'écoles que l'on nomme "d'Arts Appliqués". C'est cette notion d'Arts Appliqués qui est importante. Que signifie-t'elle ?

"Le graphiste" est théoriquement amené à travailler dans une industrie (imprimerie, studios divers), une entreprise de service (web agency, agence de pub...) et non à se pavaner dans une galerie d'art. "Sa mission" est donc d'appliquer son "art" à une industrie, et non d'essayer de plier l'industrie à ses petits caprices visuels.

Un designer travaille selon les limites de la physique, un architecte fait de même. Les règles de base (la physique des matériaux,...) de ces métiers sont intransgressables. Cela n'empêche en rien la création... ni de voir fleurir de belles architectures, ni de superbes objets aux designs les plus farfelus.

Lorsque le graphiste crée un document pour l'imprimerie, ce document répond à des tas de normes :

  • Des normes de mise en page;
  • des normes de typographie (presque aussi strictes que l'XHTML);
  • des normes de contraintes d'impression (dues aux méchants imprimeurs);
  • etc.

Le graphiste est donc bien contraint de respecter, dans la nature même de son métier, des règles assez précises. (Même si certaines de ces règles font appel à un peu de sensibilité).

"Le graphiste" doit se jouer des normes, de l'(x)HTML, des CSS et autres contraintes... Mais il ne doit pas le faire en violant ces règles, mais en les connaissant à fond. Au même titre que les règles de typo existent pour éviter de rendre un document illisible, les normes ne sont pas des barrières mais des gardes-fou afin de rendre l'Internet plus accessible (entre autres).

Mais cette connaissance pour le moment passe par le code, par la lecture d'une documentation des plus obscures et indigestes. Le W3C qui s'améliore cependant et les sources se diversifient et se vulgarisent. L'arrivée des blogs (qui souvent parlent de normes...) est un souffle nouveau par rapport à tout ça.

Mais c'est à ce moment que le graphiste en général s'arrête, car les outils à disposition ne sont effectivement pas suffisants. (Je suis du même avis que toi concernant DW 2004...) et cette obligation de passer par le code rebute souvent "le graphiste"...

Mes outils actuels sont essentiellement des éditeurs de texte (JEDIT sur Mac OS X est très puissant notamment sur la capacité à valider un doc selon une DTD précise), quelques sites de références ainsi qu'un outil de validation. Rien de bien "HuisiWuig", ni de très joli (genre plein d'icônes super... comme Dreamweaver ;)) Mais qu'est-ce que je m'amuse! Enfin un défi plus qu'interessant... passionnant !

#conceptionWeb

Petit mail hier de mon commercial me demandant de me pencher sur une stratégie de référencement pour un client (achat de liens sponsorisés sur Google entre autres). Il se trouve que le site (que je ne nommerais pas pour des raisons de confidentialité) a déjà acheté lesdits mots-clés, je clique donc pour visiter le site et là, c'est le désastre.

La première impression que donne un site c'est évidemment la charte graphique. Couleurs tristounettes, design désuet, typos moches, mise en page bancale, c'est loin d'être gagné. Pour un site "recommandé par Google" ça ne fait pas très sérieux...

Là où ça se gâte, c'est quand on regarde la source de la page en question. Il y a bien sûr les frames comme toujours inutiles qui font afficher à Google comme description du site le fameux "Cette page utilise des cadres, mais votre navigateur ne les prend pas en charge". On a aussi droit à l'inévitable mise en page par tableaux, toujours très efficace pour augmenter le ratio code produit/texte réel à afficher. Mais encore des titres en images alors qu'une liste texte suffirait amplement, etc.

Nous connaissons tous ce genre de sites. Alors faisons pression pour les faire disparaitre de la Toile pour imposer les sites de nouvelle génération enfin bien conçus, agréables à l'oeil et mieux référencés.

#conceptionWeb

Une petite discussion avec Greut (qui a rhabillé déplumé son blog) m'amène à développer l'idée que je rumine depuis quelques jours concernant l'intégrisme des promoteurs des standards du web.

A vrai dire, il y a encore quelques mois, je persiflais joyeusement devant toute l'énergie et leur inlassable volonté à démontrer à tous ceux qui veulent bien les entendre que les standards du web ça vaut le coup. Pour tout dire, j'avais même commencé à rédiger un petit pamphlet à ce sujet pendant un trajet de bus... Mais j'ai bien vite vu que je tournais à vide. Au fond, à part le fait que Netscape 4 ne supporte pas correctement cette nouvelle bonne façon de faire de l'HTML, je n'ai pas réussi à trouver d'arguments à lui opposer.

Me voilà donc convaincu, dorénavant je coderai avec <style>..

Pire, je passe directement dans la catégorie des intégristes en pestant quand je tombe sur des sites faits avec l'ancienne la mauvaise méthode. Oui, je fais partie de ceux qui pensent que quand Macromedia.com sort un site sans tableaux mais qui ne valide pas pour quelques broutilles modifiables en 5 minutes chrono, je trouve ça nul (désolé Sam). Oui, je trouve les sites avec une conception hybride mi-tableaux, mi-blocs complètement débiles. Oui, je ne vois pas pourquoi on adopterait une norme XHTML 1.0 transitional alors qu'une norme 1.0 strict existe.

Plus les jours passent, plus j'en apprend sur le domaine, plus je me radicalise. D'ici 6 mois, j'écris un bouquin et je monte ma boîte de consulting XHTML/CSS. LOL.

Viens ici que je t'embrasse !!! ;) -Denis

#conceptionWeb

Indice de confiance

# 02-09-2003

On connaissait tous les sites optimisés pour Internet Explorer et autres joyeusetés de ce type, je viens de découvrir, ébahi, l'indice de confiance du site web. Une vraie poilade.

Au hasard d'un surf, je tombe sur un site de petites annonces. Déjà, je constate avec effroi que l'URL qui m'est indiquée dans la barre d'adresses s'est considérablement rallongé, super idée pour l'envoyer à ses amis, passons. Passons aussi sur la mise en page chaotique en tapis (pour reprendre une expression PAO) d'où rien ne ressort et intéressons-nous aux quelques logos qui trônent en milieu de page.

Vous ne rêvez pas, les sympathiques concepteurs de ce site ont pris la peine de répertorié les bugs d'affichage qu'ils ont provoqué eux-même en codant comme il y a 5 ans. Bien entendu, les possesseurs de navigateurs alternatifs tels que Mozilla Firebird ou Opera n'ont pas l'air les bienvenus sur ce site. Ca tombe bien, il ne m'a pas donné l'envie d'y retourner.

#conceptionWeb

Les bons outils

# 12-08-2003

L'ami greut poursuit sa croisade pour faire découvrir HTML-Kit. "L'essayer c'est l'adopter", dit-il, pourtant mon expérience ne s'est pas avérée très concluante. Comme il l'avoue lui-même, le côté usine à gaz du logiciel est très rebutant, moi qui ait pour habitude de coder au kilomètre dans un éditeur de texte spartiate, j'ai eu de la peine à me retrouver dans cette opulence de menus, de fenêtres et d'icônes.

Pourtant, je ne suis pas sûr d'avoir encore trouvé l'outil idéal pour le développement web. Y en a-t-il un d'ailleurs ? Je n'en suis pas persuadé. Il y a juste des outils que l'on teste, que l'on étrenne, avec lesquels on prend ses petites habitudes. Pour en changer, il faut que le nouveau prétendant ait un vrai plus produit, Firebird a définitivement remplacé IE, HTML-Kit ne remplacera pas pour moi UltraEdit. En attendant le test d'un autre outil...

#conceptionWeb

Un mail de Pascal m'a permis de découvrir d'une part un blog qui vient se rajouter à mes lectures quotidiennes et d'autre part une sidebar pour Firebird ma foi très utile.

Donc cette petite appli, EditCSS permettra de travailler sur les feuilles de style d'une page, et de voir en direct le résultat s'afficher. Le projet ne part pas de zéro : tout est basé, pour l'instant sur l'excellente "bookmarlet" de Jesse Ruderman [en]. Et puis y a tout plein de défauts encore, des bugs, des menus inutiles, d'où pas encore de vrai numérotation..., dixit l'auteur.

N'ayant pas eu trop le temps de tester, je n'ai pas encore trouvé tous les "bugs" dont il parle mais en tout cas je suis déjà fan de cet outil. Quel bonheur de pouvoir modifier en temps réel les fichiers CSS d'une page à gauche et de la voir se modifier à droite. Et ce, sans la pop-up du bookmarklet original. Indispensable à mon avis pour tous les développeurs web XHTML/CSS.

#conceptionWeb

Basse besogne

# 28-07-2003

Il est toujours amusant de voir que les atermoiements professionnels transcendent les différents métiers.

J'entendais ainsi une graphiste se plaindre l'autre jour du fait qu'elle allait être obligée de faire de l'exécution, c'est-à-dire de réaliser concrètement un document en le mettant en page dans QuarkXPress (dont le site est joli et valide XHTML transitional). Cette activité d'exé étant à ses yeux beaucoup moins noble que celle de la Conception et de la Conception graphique.

J'ai déjà entendu le même grief vis-à-vis de l'intégration HTML dans la bouche de développeurs ASP ou PHP. J'avais d'ailleurs moi-même une vision assez peu engageante de cet aspect de la création web. Devoir s'arracher les cheveux sur de tous petits détails, opérer des tâches répétitives afin de mettre en page correctement un site, voilà ce qu'évoquait pour moi le mot "intégration web".

Depuis que je me suis intéressé à la mise en page XHTML/CSS, tout cela a changé, bien sûr il faut toujours batailler un peu pour obtenir un rendu similaire sur les navigateurs principaux, mais la souplesse et la rapidité de cette nouvelle méthode de travail rendent le travail enrichissant, captivant, bref, intéressant. Il n'y a qu'à voir tout le talent et l'envie que transmettent des dizaines de personnes sur leurs weblogs pour se rendre compte que tout cela ne peut pas être considérer comme de la basse besogne mais au contraire du grand Art.

#conceptionWeb

Tout concepteur web est confronté à ce problème, même si ces noms ne lui sont peut-être pas familiers : il doit faire un choix entre Icy, Jelly ou Liquid.

Les sites web Icy ont une structure rigide. Ils occupent une taille fixe horizontale (généralement 760 ou 780 pixels pour tenir dans la résolution standard 800*600) et sont généralement calés sur le côté gauche de l'écran, quelle que soit la résolution. C'est par exemple la configuration du très respectable Le Monde.

Les sites web Jelly sont une déclinaison du modèle précédent : taille fixe mais centré sous toutes les résolutions, conservant ainsi, même dans les plus hautes un meilleur équilibre visuel.

Enfin les sites Liquid ont une taille exprimée en pourcentage qui fait qu'ils prennent toujours le même espace proportionnellement à la taille de l'écran disponible.

Certains gourous (auto-proclamés) voudraient nous faire croire que les mises en page Liquid sont la panacée pour les sites web. Bullshit.

  • Les personnes utilisant des hautes résolutions ont l'habitude des sites Icy ou Jelly et surfent la plupart du temps en mode fenêtré,
  • Le fait de se baser sur une résolution standard de 800*600, étant donné les statistiques actuelles sur le sujet est toujours d'actualité,
  • Les sites liquid sont globalement moches, les contraintes graphiques étant trop importantes (taille des images, répétitions, etc.),
  • L'argument "mon site est lisible aussi bien sur PC que sur mon Palm" est fallacieux. On ne cherche pas le même type de contenu quand on surfe sur un PC que sur un appareil nomade, d'où la quasi-obligation de faire une feuille de style spécifique pour les deux supports.

Autant de raisons qui font que personnellement j'ai opté pour la majorité de mes designs pour la tendance Icy : tailles maîtrisées, possibilités graphiques plus nombreuses. Ne reste plus qu'à convaincre mon commercial :-/

#conceptionWeb