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.

Depuis maintenant 3 ans que l’AJAX a commencé à rentrer dans les usages du développement web, on a pu assister à un peu tout et surtout à n’importe quoi. Souvent, la tentation fut forte de mettre d’en mettre pour le seul principe de suivre la mode du moment, au mépris de l’expérience utilisateur et des besoins fonctionnels réels. S’il est très facile de se tromper, il existe pourtant des endroits assez génériques où ajouter une pointe d’AJAX par dessus le fonctionnement normal du site – et j’insiste sur ce point – améliore l’expérience de navigation, simplifie l’utilisation du site, et rend la vie bien plus agréable.

Le choix de l’identifiant utilisateur est une étape capitale de la conception d’une application web, malgré des possibilités sommes toutes relativement limitées. On portera généralement celui-ci sur une chaîne alphanumérique du type bogossdu75 ou une adresse email (bogossdu75@hotmail.com). Plus rarement, on utilisera une carte à puce, une clé PGP ou une empreinte rétinienne. Entre les deux mon coeur ne balance plus depuis longtemps, et les raisons d’utiliser l’email de mon nouvel utilisateur comme identifiant ont depuis longtemps gagné mes faveurs, à quelques exceptions près évidemment.

Le cabinet d’ergonomie norvégien Net Life Research vient de sortir son Bad Usability Calendar pour la quatrième année consécutive. Au sommaire, de cette opus 2008, un conseil sensé à appliquer d’urgence pour chaque mois de l’année accompagné d’un exemple de ce qu’il ne faut surtout pas faire, et de beaucoup d’humour :

Je viens de tomber sur Users Behavior, un intéressant article de Ian Holsman (qui en plus a le bon goût de tourner sous Typo) sur la difficulté de faire changer des habitudes bien établies, même pour une démarche qui devrait sembler normale, ou tout au moins pleine de bon sens.

Le wireframe, ou storyboard, occupe toujours une place considérable dans le processus d’appropriation d’un projet par le client. Lors de la phase de conception, il accompagne de manière plus qu’efficace les spécifications fonctionnelles, et, pour peu que le design ait été validé, il représente à 99% les écrans finaux tels que les verront les utilisateurs. Il prend une place encore plus grande lors d’une refonte ergonomique, à l’occasion de laquelle il se suffit généralement à lui-même.

On peut également prototyper des workflow complexes à l’aide de maquettes fonctionnelles. On reproduit alors l’ensemble des écrans en HTML, design intégré compris, avec leurs interactions côté client, afin de concrétiser le déroulé des opérations. Très coûteuse en temps, la maquette fonctionnelle peut également être déceptive pour le client, ce dernier s’attendant souvent à rencontrer une version allégée de son site (merci Alexis pour tes réflexions sur le sujet).

On donne souvent GIMP en exemple quand on veut parler de la différence de points de vue qu’il peut y avoir entre un utilisateur final et un développeur, et donc de ce qu’il ne faut pas faire en ergonomie des IHM. GIMP est un outil de manipulation d’images libre multi plates-formes bien connu de la communauté open source, plus connu pour son inutilisabilité et sa librairie graphique GTK que pour sa puissance pourtant réelle.

Je lance à partir lundi prochain une série de screencasts sur les bonnes pratiques du web.

Chaque semaine, je sélectionnerai un site volontaire dont je ferai une critique globale en termes d’ergonomie, d’accessibilité, de respect des standards, et d’une manière plus générale des bonnes pratiques du développement web. Ma première “victime” sera le site de Carpe Vinum, le jeu de découverte de la dégustation qui a bien voulu se prêter au jeu.

Peut-être vous êtes-vous déjà frotté à l’un de ces robots ménagers multitâches, multifonctions, vous assurant un remboursement du double du prix d’achat dans l’hypothèse improbable où vous rateriez un seul plat en suivant scrupuleusement livre de recettes mode d’emploi tout-en-un livré avec la bête. Si tel est le cas, vous vous êtes très probablement arraché les cheveux au à la vue des notices d’utilisation mal conçues aux schémas illisibles sur lesquel rien ne ressemble plus à un bol qu’un autre bol, et où rien ne permet de distinguer une lame d’un malaxeur.

J’ai eu l’occasion de discuter de ces aberrations de la nature avec un product manager d’une grande marque de robots ménagers. Ce dernier m’avait confié que les difficultés liées à l’utilisation des produits étaient responsables de plus de 70% des appels au service client. Malheureusement, ils étaient depuis longtemps entrés dans un épouvantable cercle vicieux : seuls se vendaient vraiment les robots disposant d’un nombre proprement incroyable de fonctionnalités, mais leur complexité les rendait inutilisables, au point que la très grande majorité d’entre-eux prend la poussière dans un placard. Je peux témoigner en ce sens, celui gagné par maman à la kermesse paroissiale n’est pour ainsi dire jamais sorti de son carton.

Je viens de tomber sur ce très bon article intitulé 10 Usability Testing Tips et publié sur le blog Attention Scan. En dix points, il rappelle que les tests d’utilisabilité sont et doivent rester orientés autour de l’utilisateur, qui n’est pas un clone de Winrunner destiné à vérifier le bon fonctionnement d’un outil. J’ai traduit chaque point de l’article, les zones en gras, auxquelles je rajoute mes remarques ou approfondissements.