Ergonomie, Rails et Architecture de l'information web (2.0)

Le 17 décembre 1996, le W3C publiait la première version de ses feuilles de style en cascade. Dix ans plus tard, CSS est entré dans les moeurs au point de profondément changer nos méthodes de développement web : plus léger, plus simple, plus beau.

J’ai découvert CSS un peu par hasard en 1998, dans un article destinés aux webmasters sur iFrance qui s’intitulait “un design au pixel près avec les feuilles de style CSS”. Je m’intéressais assez peu au web à l’époque, en tout cas certainement pas au design, et me contentais de plaquer des feuilles de style minimalistes sur mes différents sites, utilisant div identifiées et balises d’en-têtes hx et p proprement, faisant mon Monsieur Jourdain de la sémantique structurelle sans le savoir.

J’ai commencé à me détourner du développement système et de l’administration UNIX pure et dure pour le web au milieu de l’année 2003 en commençant à réaliser moi-même les thèmes de mon blog personnel. Je me suis rapidement pris au jeu de la mise en forme, du balisage propre, puis du web sémantique, au point d’en avoir fait mon métier après 8 ans de dénigrement du web comme “parent pauvre” de l’informatique.

Bon anniversaire CSS, à la santé de qui je boirai certainement une coupe de champagne… avec style évidemment.

Via 10ème anniversaire pour CSS chez Tristan Nitot.

Ce billet fait suite à un certain nombre d’expériences malheureuses et conversations survenues ces deux dernières années, dont les plus récentes entre autres avec Mathieu Pillard. Rendons à César ce qui est à César, je râle suffisamment quand on ne me le fait pas.

Je ne sais pas si vous avez remarqué la quantité de gens qui se présentent à des entretiens d’embauche – ou que des sociétés de service peu scrupuleuses vous présentent comme les plus fines gâchettes de la profession – sans avoir jamais développé une ligne du langage dont ils se prétendent pourtant spécialistes. Je me souviens un jour avoir entendu un commercial tentant de vendre un stagiaire technicien réseau au CV maquillé comme une voiture volée en tant que développeur PHP expérimenté. Il clamait à qui voulait bien l’entendre : “Il a déjà fait un site perso en HTML, le PHP c’est facile, n’importe quel imbécile peut en faire, il y a suffisamment de documentation et d’exemples sur Internet, il fera l’affaire”. Deux semaines plus tard, le garçon se faisait dégager de la mission avec pertes et fracas.

C’est sans doutes à cause de ce genre d’anecdote que je crois fermement qu’un simple entretien technique ne suffit pas à déterminer le niveau réel d’un développeur. Un test pratique représente la solution à la fois la plus efficace et la plus intéressante, pour peu, évidemment, qu’il soit mené intelligemment.

Il y a deux ans, j’avais assisté à la mise en place d’une batterie de tests techniques à destination des postulants avec la philosophie de laquelle j’avais du mal à m’accorder.

Dans un premier temps, le candidat devait, en deux heures de temps, développer une petite application simple en PHP, comme un carnet d’adresses, une interface de vente de voitures, ou un annuaire simple. Il s’agissait avant tout de tester ses capacités de “machine à pisser du code”, plus que son degré de réflexion et d’abstraction. Curieusement, sur parfois une trentaine de candidats présentés par des sociétés de service, seuls deux ou trois pouvaient prétendre à passer la seconde partie du test. Seconde partie qui consistait en l’intégration d’un nouveau module dans une application effroyablement compliquée, bourrée de bugs aléatoires, codée avec les pieds par un unijambiste parkinsonien, et reposant sur un moteur de template interne non documenté. Pendant ce temps, certains membres de l’équipe passaient derrière le courageux postulant, regardaient son travail et émettaient des réflexions pas toujours très agréables à son propos. Après ma sortie, je me suis sincèrement demandé s’ils cherchaient un développeur ou un mélange entre Mac Gyver et un bonze tibétain pour les capacités de concentration en milieu particulièrement hostile.

Je trouvais cette manière de faire critiquable sur deux points :

Le premier projet était un exercice d’école basique, sans aucun lien ni dans l’esprit ni dans le domaine fonctionnel avec ce que le postulant aurait à développer par la suite. Malgré le peu de réussite, j’aurais aujourd’hui tendance à dire qu’il était trop facile, et ne correspondait pas aux contraintes techniques de la mission (php objet, javascript omniprésent, ajax partout pour des contraintes de bande passante). Le second projet était particulièrement difficile, trop même, et l’application à reprendre très loin de la moyenne des projets développés au sein de cette équipe. D’autant que l’utilisation du template maison nécessitait quelques jours de formation et d’adaptation en internet.

En un mot, le test visait à recruter des techniciens purs, capables de pondre, de lire et de reprendre du code très rapidement, mais sans aucune méthode ni réflexion, même si les développeurs rapides savent aussi souvent réfléchir à leur code. Cela va bien pour des applications simples, jetables, mais en aucun cas pour des projets complexes et destinés à évoluer dans le temps.

Plus le temps passe, et plus j’envisage le test d’embauche pour les développeurs comme un mélange intelligent de plusieurs éléments avec des coefficients différents :

• Une partie purement technique, afin d’évaluer la connaissance du langage, sur 10 points. Le candidat doit développer quelque chose de simple, mais avec des contraintes particulières, notamment en termes de sécurité, de rapidité ou d’utilisabilité, toutes ces contraintes étant clairement exprimées dans l’énoncé de l’exercice.
• Une partie méthodologie et compréhension sur 20 points. Celle-ci se traduit par une revue de code. Le code est revu avec le candidat qui explique sa démarche, et justifie ses choix.
• Une partie “freestyle”, sur 5 points, qui récompense les candidats ayant dépassé les consignes de base afin d’offrir une application plus sexy, plus agréable à utiliser, ou fonctionnellement plus riche.

L’idée derrière cela est de laisser leur chance à des éléments parfois moins bons techniquement, mais intelligents, capables de réfléchir et d’évoluer avec une bonne tournure d’esprit, pour de les mélanger à des équipes plus expérimentés et leur permettre de parfaire leur technique. Parce qu’une équipe projet n’est pas seulement un investissement pour l’immédiat.

Les liens hypertextes sont au coeur du web. Sans eux, rien n’existerait, et nous avons pourtant tendance à les négliger. Bien employés, ils ajoutent de la valeur aux contenus publiés ; bâclés, ils peuvent aller jusqu’à leur retirer tout intérêt. Raison de plus pour s’y intéresser et en prendre grand soin.

Combien de fois êtes vous passés à côté de documents passionnants pour cause de liens invisibles, introuvables, incompréhensibles, illisibles ou inaccessibles par bête négligence ? Ce genre de choses ne doit plus arriver, et ce billet se propose justement de vous aider à les éviter en passant en revue les erreurs les plus fréquemment rencontrées et les optimisations trop souvent méconnues. Parce qu’il n’y a que sous UNIX que les liens sont symboliques.

Anatomie d’un lien hypertexte

Selon la définition du W3C :

Un lien est une balise à deux bouts – les ancres – et une direction. Le lien va de l’ancre “source”, et pointe vers l’ancre “destination”. Celle-ci peut être n’importe quel ressource sur le web (une image, une vidéo, un fichier musical, un document HTML, un élément embarqué dans un document HTML, etc…)

Nous nous intéressons aujourd’hui au lien hypertexte visible matérialisé par la balise <a> ... </a>. Il existe aussi le lien <link /> qui fera l’objet d’un autre billet.

<a href="http://t37.net">Frédéric de Villamil</a>

L’ancre “source” possède nombre d’attributs. Certains d’entre eux sont sous utilisés, voire franchement ignorés quand leur emploi à bon escient ajouterait pourtant une valeur certaine à vos liens.

hreflang :

L’attribut hreflang vous permet de spécifier la langue du document destination. Il s’utilise à l’aide du code langue à deux lettres :

<a href="http://t37.net" hreflang="fr">
    Frédéric de Villamil
</a>

Sous les navigateurs modernes, un peu de CSS permet d’afficher cette information juste à coté du lien :

a[hreflang]:after {
   content: "\0000a0[" attr(hreflang) "]";
   color:#999;
}

On peut aussi choisir d’afficher une icône en fonction du code langue :

a[hreflang=fr] {
    padding-left: 20px;
    background: url("fr.png") left no-repeat;
}

Ceci affichera un petit drapeau français à gauche de vos liens.

Bien que ceci ne soit pas supporté par Internet Explorer, il serait dommage de priver les 20% de vos visiteurs munis de navigateurs modernes non ?

type :

Souvent ignoré, l’attribut type vous permet d’indiquer le type mime du document destination.

<a href="http://t37.net/cv.pdf" type="application/pdf">
    Télécharger mon CV
</a>

Comme précédemment, un peu de CSS permettra aux utilisateurs de navigateurs modernes d’afficher une petite icône à côté du lien pour un document destination au format PDF :

a[type=application/pdf] {
    padding-left: 20px;
    background: url("pdf.png") left no-repeat;
}

Évidemment, ceci reste valable pour n’importe quel type mime.

Les attributs ne s’excluant pas l’un l’autre, on pourra proposer :

<a href="http://t37.net/cv.pdf" type="application/pdf" hreflang="fr">
    Télécharger mon CV
</a>

En utilisant les deux bouts de CSS proposés ci dessus, le visiteur verra donc au premier coup d’oeil que le lien pointe vers un PDF rédigé en français.

title :

L’attribut title donne le titre exact de la destination, en plus de l’image ou du texte placés entre la balise ouvrante et la balise fermante.

<a href="http://t37.net/cv.pdf" title="Curriculum Vitae de Frédéric de Villamil">
    Télécharger mon CV
</a>

Le navigateur affiche généralement la valeur de l’attribut title au passage de la souris sur le lien. Un peu de javascript permet même d’afficher celui-ci dans une élégante info bulle.

title permet de spécifier le titre d’une oeuvre ou d’un document d’une manière plus formelle et complète qui n’aurait pas forcément eu sa place dans le flot du texte. Les moteurs de recherche prennent aussi ces informations supplémentaires en compte, ce qui peut s’avérer utile.

rel :

Souvent mal utilisé, rel décrit la relation existant entre le document courant et celui indiqué dans l’attribut href. On trouve de nombreux exemples d’utilisation de rel dans les Microformats, comme le le microformat rel="tag", mais aussi dans les liens de type <link />

<a href="http://t37.net/articles/tag/microformats" rel="tag">
    Microformats
</a>

Comme précédemment, vous pouvez signaler la présence d’un tag – par exemple – à l’aide d’un peu de CSS. Et comme précédemment, cela ne fonctionnera que sur les navigateurs modernes.

a[rel=tag] {
    padding-left: 20px;
    background: url("tag.png") left no-repeat;
}

rev :

À l’inverse de l’attribut rel, l’attribut rev décrit la relation entre le document pointé par l’attribut href et le document courant. L’attribut rev est notamment utilisé dans les Microformats, particulièrement dans les vote-links.

<a href="http://t37.net" rev="vote-for">
    Frédéric de Villamil
</a>

Vous pouvez maintenant utiliser un peu de CSS afin d’afficher de petites icônes à côté du lien afin de permettre à vos visiteurs utilisant un navigateur moderne – et non pas forcément récent – de connaître votre opinion à propos du lien cible :

a[rev=vote-for] {
    padding-left: 20px;
    background: url("for.png") left no-repeat;
}

a[rev=vote-against] {
    padding-left: 20px;
    background: url("against.png") left no-repeat;
}

tabindex :

tabindex nous fait quitter le domaine de l’information sur la destination des liens pour entrer dans le cadre de l’ergonomie et de l’utilisabilité. tabindex sert à indiquer dans quel ordre les liens – ou les champs d’un formulaire – doivent être parcourus lorsque le visiteur navigue à l’aide de la touche tab de son clavier.

accesskey

Là aussi, on rentre dans l’ergonomie et l’accessibilité, puisque accesskey permet de définir une touche permettant d’accéder directement au lien – ou au champ d’un formulaire – à l’aide d’une seule touche.

Un peu de clarté ne nuit pas

Donner une ribambelle de liens tout juste séparés d’un espace dans une même phrase ne sert pas à grand chose. Non seulement le visiteur aura du mal à définir où commence et où finit un lien, mais il ne saura très probablement pas de quoi ces liens vont parler. Si ce genre d’énumérations est particulièrement fréquente sur les blogs, elle est évidemment à proscrire.

Pour des raisons d’accessibilité, chaque lien doit être séparé du suivant par un caractère imprimable qui ne soit pas un lien, comme le stipulent les WAI Guidelines du W3C.

Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. [Priority 3]

Une avalanche de liens n’apporte souvent pas grand chose à un billet. Si pour une raison ou une autre vous souhaitez cependant indiquer un grand nombre de liens concernant un même sujet, vous pouvez le faire de manière bien plus pratique ou élégante. Pourquoi ne pas ajouter à la fin de votre article une annexe présentant un lien et sa description par ligne ? S’ils sont si pertinents, ils méritent cet espace dédié. Et s’ils ne le méritent pas, c’est probablement qu’il vous faut remettre leur présence en cause.

Tant qu’on en est à parler de ce qui se trouve entre l’ancre “source” et l’ancre “destination”, réfléchissez bien à ce que vous y mettez. C’est en effet de votre choix que naîtra chez votre visiteur l’envie de cliquer ou de ne pas cliquer. S’il s’agit d’une image ou d’un bouton, n’hésitez pas à abuser des attributs alt et title. Au sein d’un paragraphe, soyez clairs, précis et concis. Non seulement vous influencerez vos visiteurs dans leurs choix, mais en plus vous aiderez les moteurs de recherche. Que demander de plus ?

Mettez vos liens en valeur

Pour être visités, vos liens doivent avant tout être vus par vos visiteurs, et ce au premier coup d’oeil. Pour cela, un peu de CSS peut faire beaucoup.

Un peu de typographie

Commencez par leur choisir une couleur qui tranche avec celle du texte et du fond. J’ai choisi un texte noir sur fond blanc pour la lisibilité, et je mets mes liens en rouge pour les faire ressortir. Laissez vos liens soulignés. Il s’agit du comportement par défaut de tous les navigateurs, et l’oeil du visiteur cherche instinctivement des éléments soulignés pour cliquer dessus. En revanche, ne soulignez que les liens – une bordure sous un titre n’est pas un soulignement. Si vous devez donner le titre d’une oeuvre et souhaitez la souligner, profitez-en tant qu’à faire pour donner un lien vers sa page officielle ou Wikipedia, ça ne coûte rien et ça donnera peut-être envie au visiteur d’aller plus loin.

Utilisons les comportements

La balise a dispose de deux pseudo classes bien pratiques, supportées par tous les navigateurs et combinables entre elles : hover et visited.

hover permet de définir un comportement lorsque la souris survole le lien. visited permet de définir le comportement lorsque le lien a déjà été visité.

Je ne sais pas s’il existe une règle définie pour cela, mais j’ai tendance à toujours utiliser les mêmes comportements.

• a : couleur vive tranchant à la fois avec le texte et le fond, souligné.
• a:hover : même couleur que précédemment, sans soulignement. La transition souligné / non souligné au survol de la souris permet d’attirer l’oeil sur le fait qu’il s’agisse d’une zone active de la page.
• a:visited : couleur dans les mêmes tons qu’un lien non visité, mais plus foncé, souligné. J’avais coutume d’utiliser l’attribut text-decoration: line-through; pour indiquer que ce lien n’était plus à visiter – je le supprimais tout de même au au survol de la souris – mais je me suis rendu compte que cela grêvait trop la lisibilité du document.
• a:visited:hover : même couleur plus foncée que précédemment, mais avec le soulignement en moins.

Je tiens à préciser que j’utilise ces règles dans le corps de texte d’une page, et non dans le menu dans lequel je supprime généralement le soulignement. En effet, cette partie d’une page me semble suffisamment parlante d’elle même et est généralement assez lourde – surtout sur un blog – pour ne pas tout souligner systématiquement. Peut-être est-ce une erreur ? Je n’ai cependant pas trouvé assez d’arguments qui me poussent vraiment à changer pour l’instant.

Attendez vous à voir pas mal de modifications de ce billet dans les prochains jours. Je suis complètement crevé, il doit donc être bourré de fautes de français, et probablement incomplet par rapport à ce que j’avais initialement prévu de faire.

Je vous parlais ce matin de développement web à destination des terminaux mobiles, et cela tombe bien, puisque le W3C Mobile Web Seminar se tiendra à Paris le 16 novembre prochain, de 9 heures à 13h30 à l’Entrepôt, 7-9 rue Francis de Pressensé 75014 Paris.

Au programme : bonnes pratiques pour développer des sites adaptés aux terminaux mobiles, et adaptation des contenus existants à des usages mobiles, le tout animé par Philipp Hoschka, leader du Web Mobile Initiative au W3C, et de nombreux acteurs du marché.

Je devrais normalement m’y rendre si mes projets et mes employeurs m’en laissent le temps, et j’espère vous y rencontrer aussi : une demi journée est plus facile à poser qu’une journée, et l’entrée est gratuite, même si une préinscription est obligatoire.

Cameron Moll qui publie le blog Authentic Boredom vient d’annoncer la sortie de Mobile Web Design, un ouvrage sur le développement de sites web pour terminaux mobiles, c’est à dire principalement pour PDA et téléphones portables.

Le site officiel dit :

Beaucoup de choses ont été écrites à propos des terminaux mobiles. Beaucoup de choses ont été écrites à propos du développement de sites web à l’heure des “standards”. On a cependant bien peu fait pour relier ce deux sujets. Ce livre a pour but de combler ce vide.

La généralisation des smartphones et des forfaits internet fera certainement exploser le marché des sites web pour téléphones mobiles – appelons le WAP 2.0 et j’ai le sentiment qu’ils constitueront le prochain gros marché une fois celui de la vidéo en ligne régulé. Pour peu que les opérateurs comprenne qu’une baisse des tarifs les avantagerait plus que de maintenir forfaits et téléphones à des prix prohibitifs, des terminaux comme le Nokia E61 – ma prochaine acquisition – qui couplent téléphone mobile et PDA avec accès WIFI risqueraient bien de devenir la norme en France d’ici deux à trois ans, et il serait dommage de passer à côté. Je compte d’ailleurs rapidement mettre en place une feuille de style spécialement dédiée aux terminaux mobiles qui ne disposeraient pas d’un agrégateur RSS.

Alors en attendant ce livre, vous pouvez toujours lire ce guide des bonnes pratiques du W3C à destination des développements sur terminaux mobiles.

Si vous utilisez un navigateur moderne, par exemple Mozilla Firefox ou même Flock, vous lisez actuellement un site en XHTML 1.1 servi avec le bon type mime, soit application/xhtml+xml. Les utilisateurs de navigateurs archaïques se voient servir du XHTML 1.0 strict, tout de même, avec le type mime text/html.

Je ne sais pas si cet état de fait durera, mais je suis au moins parvenu à mes fins, à savoir faire servir à Typo le contenu en fonction des navigateurs malgré de très nombreuses difficultés. J’ai testé plusieurs méthodes, et la seule qui ait fini par me convenir ne me satisfait toujours pas pleinement, mais après 5 jours de recherche acharnée, je vais me permettre de me reposer un peu avant de reprendre mes recherches.

Je profiterai du week-end pour compléter cette note avec les problèmes rencontrés, les méthodes testées et celle que j’ai finalement retenue.

Sur le principe, difficile de ne pas approuver l’auteur d’un ouvrage sur l’utilisabilité des sites web qui commence son livre en expliquant qu’il a voulu faire quelque chose de court afin d’acquérir la certitude que son livre soit lu jusqu’au bout et serve à quelque chose. Tant que la brièveté ne masque pas l’indigence, cette introduction me parait frappée au coin du bon sens, et cela tombe bien, puisque c’est justement de bon sens que Steve Krug nous parle dans Don’t Make Me Think, A Common Sense Approach to Web Usability (Ne me faites pas réfléchir, une approche de l’utilisabilité des sites web par le bon sens).

Actualys, jeune société parisienne spécialisée dans l’accompagnement des grands comptes dans toutes les phases de leurs projets web (nous ne sommes pas une SSII au sens général du terme) recherche un chef de projets web junior ayant de bonnes connaissances techniques, principalement en PHP, SQL, XHTML et CSS. Ruby, Ruby on Rails, Python et Java / J2EE seraient un plus.

Ceux qui ne me lisent que depuis leur flux RSS ignorent encore probablement que j’ai changé de feuille de style pour la seconde fois en trois semaines. On prend (presque) le même, et on recommence. Mon sens artistique étant proche du zéro absolu, je me dois de citer mes sources d’inspiration : Ruby, Think Vitamin et Web Worker Daily pour ne citer qu’eux.

O Reilly a publié hier Using Microformats, dans la collection O’Reilly Shortcuts. Écrit par Brian Suda, il fait 56 pages, et son acquisition vous coûtera 9.99$.