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

Réaliser le formulaire de login parfait relève un peu de l’utopie ergonomique, tandis qu’il est particulièrement facile de se tromper. Dans son article en deux parties, Account sign-in, 8 *2 mistakes to avoid Jared Spool détaille 16 erreurs à ne pas commettre quand on crée un tel formulaire. Il y étudie le formulaire lui-même, mais également tout ce qui va autour : placement, opportunité… en l’appliquant à la boutique en ligne du site de Cisco.

Plutôt que de traduire simplement son billet, j’ai repris les 16 points étudiés, et j’ai tenté de les appliquer aux cas les plus génériques possibles, afin de pouvoir les réutiliser sur tous les types de sites et d’applications possibles.

Après la sortie la semaine dernière de la version stable de Ruby on Rails 2.0, La toute nouvelle version de Typo se profile doucement à l’horizon. À l’occasion de ce changement de version majeure, nous avons décidé de changer le thème de base, pour un design rajeuni. Et dans notre grande mansuétude, nous avons décidé que ce serait TOI, oui TOI lecteur qui choisirait à quoi allait ressembler ton blogware préféré (si, si, tu vois, non seulement on va te faire décider à ta place, mais en plus décide à ta place que tu aimes Typo et que tu vas l’installer sur ta machine… ha les joies du crowdsourcing…)

Après cet intermède d’un cynisme particulièrement marqué, il est temps pour moi de vous présenter les heureux lauréats, parce qu’ils le valent bien :

Les Open Source CMS Awards 2007, récompenses attribuées aux meilleurs outils de gestion de contenus libres viennent d’être attribués sur le site de l’éditeur britannique Pact Publishing, et j’avoue que certains résultats me laissent sans voix.

Meilleurs CMS de l’année 2007 :

1. Drupal.
2. Joomla.
3. CMS Made Simple.

CMS les plus prometteurs :

1. MODx.
2. TYPOlight (rien à voir avec Typo).
3. dotCMS.

Meilleur CMS développés en PHP :

1. Joomla.
2. Drupal.
3. e107.

Meilleurs CMS n’ayant pas été développés en PHP :

1. mojoPortal.
2. Plone.
3. Silva.

Meilleur CMS à vocation sociale.

1. Wordpress.
2. Drupal.
3. Elgg.

Devant la déferlante des détournements de couvertures de Martine – phénomène qui n’a rien de nouveau mais qui semble avoir pris une ampleur particulière depuis quelques semaines – je n’ai pas pu m’empêcher d’accommoder l’héroïne des enfants sages à la sauce des bonnes pratiques du web.

Depuis le temps que je ne vous avais pas donné de nouvelles de Typo, je pouvais bien me fendre d’un petit billet de teasing, histoire de vous montrer la prochaine fonctionnalité qui devrait arriver sous peu dans la trunk, avant de rejoindre la prochaine version stable : un éditeur de thèmes en ligne, qui m’a été demandé par pas mal de gens souhaitant migrer depuis Wordpress et pouvoir éditer leurs templates directement depuis le web.

Depuis maintenant trois ou quatre ans, on peut lire jusqu’à plus soif que le web 2.0 a inauguré le règne du contenu, et cette allégation n’est pas complètement fausse. L’auteur d’un site publie un contenu ; les visiteurs y réagissent par des commentaires, des billets liés, du bookmarking social, ou de la mise en avant sur les agrégateur sociaux. Bien que la qualité des contenus promus laisse souvent à désirer – il vaut mieux ne pas trop demander aux gens de réfléchir – le système marche semble fonctionner malgré quelques ratés ici et là. Pourtant, si l’on parle beaucoup du contenu, on en oublie que trop souvent la structure, y compris dans le monde des développeurs web, à l’exception peut-être du web sémantique.
Contrairement à ce que j’ai longtemps cru, le XHTML n’est pas seulement un langage de mise en forme ; par la nature même de chacun de ses éléments, il donne du sens à la structure de la page, et ce sens peut être exploité de bien des manières. C’est pour cette raison que l’on parlera dans la suite de cet article de sémantique structurelle.

On se retrouve tous un jour ou l’autre confronté au problème de questions à réponses multiples et encore plus nombreuses, sans possibilités de filtrage préalable. Dans ce cas, la première solution qui vient à l’esprit est celle du menu déroulant à choix multiple, et elle peut sembler alléchante à plus d’un point de vue.

Grave erreur ! Il n’y a pas pire pour votre utilisateur que cette extension de notre bon vieux select, dont j’avais sérieusement remis la fiabilité en question il n’y a pas si longtemps que cela. Je me suis rendu compte à mes dépends que les menus déroulants à choix multiples étaient aux formulaires ce que le blink et les gifs animés étaient aux pages web des années 90 : une plaie.

On fait tous des conneries, et moi le premier. Confronté à des formulaires dans lesquels je rencontrais de nombreux champs à réponse multiple sans aucun contrôle de ma part sur leur nombre, j’ai mis du menu déroulant partout, persuadé de détenir la bonne méthode. Horreur, malheur, dirait la sorcière si elle était là, le truc s’avère épouvantable à utiliser.

• Un clic de souris à coté, et on perd toute sa sélection.
• La sélection de cases non adjacentes relève du défi olympique.
• Difficile à styler, on s’y perd facilement entre les réponses.

J’ai cherché un moment avant de trouver une solution satisfaisante vues les contraintes qui m’étaient imposées :

• Un nombre infini de réponses potentielles.
• Accessibilité totale, donc pas de javascript.
• Facilement personnalisable.

La solution

Pas besoin de chercher bien loin. Remonter à l’origine du problème et aux avantages apparents de la solution choisie devaient me permettre de prendre la bonne direction.
Dans un formulaire, la première chose à laquelle on pense quand il s’agit de réponses multiples, c’est “cases à cocher”. Malheureusement, celles-ci deviennent rapidement impossible à afficher au delà de quelques éléments. D’où l’utilisation du menu déroulant à choix multiple, dont l’ascenseur permet d’occuper un minimum de place, mais au détriment de l’utilisabilité.

Il me fallait donc combiner les avantages des cases à cocher et des menus déroulants à choix multiples, sans sacrifier à l’accessibilité :

• Espace à l’écran restreint.
• Réponses multiples.
• Nombre de réponses indéfini et potentiellement infini.

Pour cela, je commence par englober mes réponses dans une div dont je force la hauteur et à laquelle j’attribue la propriété CSS overflow-y : auto. Voilà pour la partie déroulante.

J’ajoute ensuite une série de label dans lesquels j’englobe ma case à cocher. Si je trouve ça sémantiquement moyen – le label désigne le champ de formulaire, ce dernier ne saurait donc y être inclus – c’est structurellement valide. J’applique ensuite à chacun de mes labels la propriété CSS display: block

Ce dernier point est très important. En effet, si l’id de la case à cocher et la propriété for= du label sont renseignées correctement, la sélection du champ quand je clique sur le label s’étend à toute la ligne. Pratique non ?

Il ne me reste qu’à mettre un peu de couleur une ligne sur deux pour bien différencier les réponses, et le tour est joué. Évidemment, le résultat présenté est tout sauf joli, mais je vous rappelle que mon sens artistique avoisine le zéro absolu.

Télécharger le code source de l’exemple.

Les standards du web expliqués à ma mère

Ma mère utilise un ordinateur sous Windows Millenium “le seul avec lequel je n’ai jamais eu de problèmes”, appelle une unité centrale un “moteur” car ça fait du bruit et c’est ce qui fait propulse la machine, et a depuis longtemps oublié sa propre adresse courriel peu peu qu’elle l’ait jamais connu. Le jour où elle m’a demandé de lui expliquer ce qu’étaient ces fameux standards du web dont je parlais si régulièrement et qui avaient l’air tellement importants, je savais que la partie était tout sauf gagnée.

– Ces standards du web, c’est quoi ?
– Eh bien, c’est un code de bonne conduite pour créer des sites web qui ont la même apparence sous tous les navigateurs du marché.
– Ah, parce qu’il y a plusieurs navigateurs ? Je ne connais qu’Internet Explorer.
– Oui, il y en a tout un tas : Firefox, Netscape, Flock, Opéra…
– Et ça sert à quoi d’en avoir autant, ce ne serait pas plus simple de n’en avoir qu’un seul ?
– Hmmm… peut-être, si. Au fait, pourquoi roulez-vous dans une Clio verte ?
– Eh bien parce que c’est une bonne voiture, et qu’elle me plaît bien.
– Ce ne serait pas plus simple que tout le monde roule en Golf diesel bleue ? Plus de problèmes de pièces détachées, un seul type d’essence à la pompe… le bonheur quoi.
– Et laisser à une entreprise allemande le monopole de l’automobile en France ?
– Ben voilà, vous avez compris.
– Quel est le navigateur le plus utilisé ?
– Internet Explorer, avec 90% de parts de marché (la conversation est assez ancienne, ndlr).
– Et Internet Explorer suit ce code de bonne conduite ?
– Non, pas vraiment. En fait il ne suit que ce qu’il veut.
– Alors pourquoi parler de “standards”, s’ils ne sont pas suivis pas 90% des utilisateurs ?
– C’est que les standards du web n’ont pas valeur normative.
– On ne peut donc pas parler de norme. Dans ce cas, à quoi servent-ils ?
– Vous connaissez les normes ISO ? La norme ISO9002 par exemple.
– Oui, prend ta vieille mère pour une imbécile, je ne te dirai rien.
– L’institut ISO part d’une implémentation pour définir une norme. Le W3C définit des codes de bonne conduite à priori pour que les navigateurs puissent s’y conformer dans le futur.
– Le W3C ?
– Oui, une organisation indépendante composée de grands noms de l’industrie informatique. Elle élabore les préconisations que l’on appelle les standards du web.
– Et qui les rédige ?
– Des groupes de travail. L’activité du W3C va bien au delà de l’unification du rendu des pages web.
– Et Microsoft en fait partie ?
– Oui.
– Donc, si j’ai bien compris, les standards du web sont directives à valeur non normatives créées par des sociétés qui ne les appliquent pas dans leur propre produit, produit qui se trouve de fait être le navigateur standard sur le web. C’est bien ça ?
– En quelque sorte, oui…
– Eh beh, nous voilà biens…

Note : cette conversation a été à peine déformée, dans un soucis de concision et de clarification.

Intéressante discussion la semaine dernière avec le responsable du service clientèle d’un fournisseur de télécommunications sur l’emploi fait par les utilisateurs des formulaires web de demande d’aide à la hotline.

En substance, il s’avère que, concernant les menus déroulants servant à qualifier les problèmes rencontrés par ses clients, cet opérateur m’a fourni les chiffres suivants :

• 90% choisissent la première option, quelle qu’elle soit.
• 5% choisissent l’option autres si elle est présente.
• 5% choisissent une option plus ou moins en rapport avec leur problème.

Cette constatation introduit deux problèmes évidents :

Les problèmes étant répartis entre les différentes équipes en fonction de leur typologie, un travail de requalification de l’affaire doit être effectué systématiquement avant traitement, avec une retransmission à l’équipe concernée. Outre l’allongement des délais de traitement, cela implique aussi une charge de travail supplémentaire, qui passe par l’analyse de diatribes rédigées dans un français généralement douteux par Madame Michu, dont je vous reparlerai très bientôt.

Vus ces chiffres, quel crédit accorder aux données émises via un menu déroulant, et par extension, par toute zone de formulaire à choix multiples ? Dès lors, on doit classer ces données en trois catégories :

• Celles qui impliquent une dépense ou un investissement du client, par exemple la durée d’un abonnement. On peut raisonnablement tabler sur la fiabilité d’une telle donnée puisqu’elle implique une variation du paiement à l’arrivée.
• Celles qui sont absolument indispensables au traitement du formulaire et qu’une intervention humaine ne peut permettre de recouper à partir d’autres renseignements.
• Les données purement statistiques.

Quant à notre opérateur, afin de mieux répartir le travail entre les équipes chargées des différentes typologies de problèmes, il a tout simplement décidé de générer ses menus déroulants dans un ordre aléatoire.

Les mauvaises langues qui diront que j’ai parcouru tous les didacticiels Photoshop estampillés “web 2.0” afin de réaliser ce thème ne seront pas très loin de la vérité. Cette remise à neuf part d’une constatation évidente : difficile de parler d’ergonomie et de webdesign quand on a un design peu soigné, et surtout peu utilisable. Certes, les cordonniers sont toujours les plus mal chaussés, mais il y avait des limites.

C’est la seconde fois que je commence par coucher le résultat final sous Photoshop, avant de me lancer dans le développement, et les résultats sont visibles : c’est nettement plus propre. Ma démarche habituelle consiste à ouvrir Textmate avec une vague idée de ce que je veux faire, et à coder. La démarche inverse, même si elle est beaucoup plus fastidieuse en rajoutant un très grand nombre d’étapes nécessitant un outil que je ne maîtrise pas du tout, est aussi très intéressante, puisqu’elle m’oblige à aborder les problèmes à venir en amont.

J’imagine qu’il y a un certain nombre de bugs sous Internet Explorer, principalement dans sa version 6 à cause du manque de support de l’alpha des images au format PNG, mais je n’ai pas de machines sous Windows pour tester. Ils attendront donc lundi soir que je sois au bureau pour un recensement exhaustif.

Et pour finir, la liste de mes sources d’inspiration :

• Iris Design pour les gros boutons Aqua de la barre latérale.
• Shadowness pour les onglets de navigation.
• Simple entrepreneur pour la mise en valeur des zones de souscription.