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

En tant qu’utilisateur de Mac OS X, mon plus grand soucis dès que je dois tester la compatibilité d’une feuille de style entre les différents navigateurs vient de la difficulté de trouver une plate-forme Windows, disposant en plus des deux dernières versions de Microsoft Internet Explorer (5.5 et 6), et de la toute dernière version de Windows Explorer (la 7 donc).

J’utilisais jusqu’à aujourd’hui les comptes gratuits de browsercam, plutôt pratique pour tester un rendu final sur un très grand nombre de plate-formes, mais pas vraiment idéal en phase de debug. Et puis ce matin, j’ai découvert Netrenderer dans les quelques milliers de billets en retard de mon OPML.

Netrenderer est un service allemand qui permet d’afficher en temps réel les résultats d’une capture d’écran sous une des 3 versions sus-mentionnées du navigateur de Microsoft. Gratuit, sans pub et rapide, il permet de pallier relativement bien à l’absence d’Internet Explorer sur les plate-formes UNIX ou Mac OS X.

L’initiative WMI W3C organisait aujourd’hui un séminaire d’une demi journée consacré au web sur les appareils mobiles, PDA et téléphone portables. Au programme, état des lieux, bonnes pratiques de création de sites à destination de ces outils, problèmes à résoudre à perspectives.

Quelques chiffres sur le web mobile.

• 28% des téléphones mobiles ont accès à Internet.
• 10% d’entre eux l’utilisent vraiment régulièrement.
• 41% des utilisateurs se déclarent insatisfaits par les sites à leur disposition.
• 3,2 millions de personnes ont utilisé leur téléphone mobile ou leur PDA afin d’accéder au web lors du mois de juillet 2006.
• Plus de 80% de la population mondiale est sous couverture GSM.
• 2 milliards d’êtres humains disposent aujourd’hui d’un téléphone mobile, ce nombre aura doublé dans 4 ans.

Selon Bango, durant les 18 derniers mois :

• Le nombre d’utilisateurs identifiables a été multiplié par 2,6.
• La durée moyenne des visites sur le web a été multiplié par 1.38.
• Le nombre d’utilisateurs redirigés d’un site web “normal” vers un site web pour mobile a été multiplié par 45.
• Le nombre d’utilisateurs étant arrivé sur un site mobile par SMS a crû de 140%. Ceci est du au fait que les claviers des appareils existants se prêtent mal à la saisie d’une URL.
• Le nombre de terminaux différents a décru de 58%.

De bonnes pratiques de développement sur mobiles.

• Concevez vos sites pour une résolution de 120*120 pixels.
• Limitez vos pages à 20ko, images comprises.
• Utilisez de préférence des images au format .gif et .jpg.
• Préférez un encodage en UTF-8.
• Utilisez du XHTML basic.

Et retenez ces 10 principes de développement, qui résument les 60 points des “best practices” émises par le W3C :

1. Faites vos sites pour un web unique (mobile et non mobile).
2. Conformez-vous aux standards du web.
3. Banissez les frames, les layouts basés sur les tables et les gifs transparents.
4. Optimisez la navigation.
5. Pensez aux utilisateurs en déplacement.
6. Faites attention aux éléments graphiques et aux couleurs utilisées. Préférez un contraste important entre le fond et les couleurs.
7. Faites de petites pages, utilisez de petites images.
8. Aidez les input utilisateurs.
9. Économisez la bande passante.
10. Ne vous reposez pas sur le javascript et les cookies.

Notez que ces recommandations se basent sur les critères d’accessibilité du WAI. Cela ne garantit pas pour autant que les contenus produits sur les mobiles seront 100% accessibles aux déficients visuels ou aux aveugles.

Le navigateur mobile idéal

Michael Smith nous présente la vision d’un navigateur mobile idéal selon Opéra.

Un bon navigateur mobile devrait pouvoir :

• Reformater un texte (même disposé sur plusieurs colonnes) en une seule afin d’éviter le scrolling horizontal.
• Redimensionner une image à la taille de l’écran utilisé, pour les mêmes raisons qu’évoquées ci-dessous.
• Proposer un mode “desktop”, c’est à afficher le site tel qu’il apparaîtrait sur un navigateur traditionnel.

Michael considère ces critères comme minimaux et souhaiterait aussi voir les navigateurs mobiles pouvoir :

• Réduire, ou faire disparaître (expand / collapse) les longues listes de liens généralement utilisées pour la navigation, et qui empêchent un accès rapide au contenu.
• Découper les grosses pages en pages de taille plus raisonnable (autour de 10ko) en suivant leur sémantique structurelle afin de s’adapter à la fois aux écrans et aux limitations de mémoire de ces outils.

Et là encore, il considère que c’est le minimum.

Je rejoins tout à fait la position de Mike. La très grande majorité des sites web n’offriront jamais de version dédiée aux mobiles. L’adaptation des contenus doit donc se faire coté navigateurs quand la feuille de style “handhelds” n’est pas disponible. En supprimant la feuille de style normale et appliquant une découpe aux pages trop longues, on obtient des sites utilisables.

Et Michael d’en rajouter une couche à propos du navigateur idéal qu’il verrait bien :

• Avoir une API de scripting permettant de détecter et utiliser les fonctionnalités des appareils (comme le GPS).
• Ce qui permettrait de créer des applications web pour les services géo localisés.

Problèmes à résoudre

• Il existe plus de 200 outils mobiles différents.
• Certains utilisent du XHTML 1.1, d’autres du XHTML basique, d’autres du xHTML…
• Aucun n’a le même support de CSS que le voisin.
• Certains supportent le javascript et les cookies, d’autres non.

Aujourd’hui, la solution utilisée est de formater la page en fonction du device utilisé : menu déroulant ou cases à cocher ? Puis d’envoyer des pages générées dans le bon langage. Autant dire que seuls les plus gros peuvent se l’offrir, et le contenu créé par les utilisateurs est fort peu disponible sur le web mobile.

On voit pourtant apparaître des outils de blogging, de partage de photos… les réseaux sociaux sont très actifs dans la téléphonie mobile, et on les comprends. Quoi de plus communiquant qu’un téléphone ou un PDA ?

Perspectives

Le web mobile est probablement l’avenir des pays en voie de développement, principalement pour les services comme :

• Les services gouvernementaux.
• L’éducation.
• La santé.
• La banque.
• Les affaires.

Quelques chiffres :

• Inde : taux de pénétration des PC : 2%, stable, contre 11% pour les téléphones mobiles, avec une croissance de 47% par an.
• Chine : taux de pénétration des PC : 8%, contre 30% pour les téléphones mobiles.
• Maroc : 4 lignes fixes pour 100 habitants (chiffre inchangé depuis 1995), contre 24 téléphones mobiles.

L’utilisation des SMS pour accéder à tous ces services explose dans les pays en développement.

Conclusion

Les présentations des intervenants sont accesibles sur le site du séminaire.

La pente est forte, mais la route est longue, alors au travail !

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.

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.

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.

Je réécris totalement ce billet : la fatigue de ces deux dernières semaines aidant, l’original était plein de fautes, obscure, et manquait d’une partie de ma réflexion.

Ce matin, je tombais un peu par hasard sur cette note technique offerte aux visiteurs du site dédié au jeu de rôles Le Gant et l’Épée.

“Non je ne trolle pas”

Daniel Glazman.

Microsoft vient de publier la longue litanie des corrections apportées à son navigateur Internet Explorer 7 pour assurer un meilleur respect de la norme CSS 2.1. La liste est impressionnante, et je retiendrai surtout la liste de bugs relevée par le site Position is Everything, et le support de min-width, max-width, de la transparence des images PNG, de background-attachment : fixed;, du dimensionnement automatique des éléments positionnés de manière absolue avec width: auto; ou de la pseudo classe :hover sur l’ensemble des balises HTML.

Je voulais vous parler de cet excellent article de Tantek Celik depuis plusieurs jours, mais entre la refonte organisationnelle et graphique de ce site – la seconde ne me satisfaisant pas encore pleinement – et un week-end en province particulièrement chargé, j’ai du délaisser quelque peu l’écriture.

De nombreux articles exposent les mille et une bonnes raisons de passer ses sites en XHTML, que ce soit en s’appuyant sur l’esprit – respect des standards, accessibilité – ou sur la lettre – à travers les outils de validation mis en place par différents organismes. La plupart d’entre eux sont excellents, mais si la réponse au “pourquoi ?”