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

Suite à la lecture de l’excellent Navigation Menus, Trends and Examples, j’ai découvert les navigations “parlantes”. De la théorie à l’application, il n’y avait qu’un pas. J’en ai donc profité pour redonner un coup de jeune à mon thème, sans toutefois changer radicalement de charte graphique. Finis les thèmes glossy et brillants à la Apple / web2.0, je passe à quelque chose de semblable mais beaucoup plus épuré.

Wordpress 2.5, dont une démo est disponible en ligne apporte son habituel lot de nouveautés, parmi lesquelles une refonte en profondeur de l’administration, organisée autour des fonctionnalités de plus en plus nombreuses et diversifiées du plus populaire des blogware open source. Qu’on aime ou qu’on aime pas – et je rentre depuis longtemps dans la seconde catégorie – force m’est d’avouer que cette nouvelle version est impressionnante.
Plutôt qu’un tour complet de cette nouvelle admin qui ne servirait pas à grand-chose, je vous propose de passer en revue les 9 petits trucs qui vous changent la vie.

Je découvre avec plaisir Version 1, un excellent outil de suivi de projets pour méthodes agiles proposé en mode ASP. Ce dernier propose quelques fonctionnalités vraiment intéressantes ou bien pensées pour faciliter la vie de l’utilisateur. C’est notamment le cas de la validation de la création des bugs. Cette dernière propose quatre choix à l’utilisateur :

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 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.

La première application web digne de ce nom qu’il m’a été donné de croiser était une infâme usine à gaz en J2EE, lente à souhait malgré une architecture plus que respectable, mais qui avait le mérite de reproduire à l’identique l’application desktop dont elle était le portage. J’évoque souvent cette expérience, car, malgré bien des défauts, elle a marqué pour moi le jour où j’ai vu le web comme autre chose que du vent tout juste bon à causer des soucis de sécurité aux administrateurs système.

Je me rappelle très bien m’être alors fait la remarque – nous étions au mois d’août 2003 – qu’à la façon dont allaient les choses, les applications web pourraient rapidement remplacer leurs homologues de bureau tant elles palliaient les principaux défauts de ces dernières :

• Plus de problèmes de compatibilité entre les architectures, les systèmes d’exploitation et les bibliothèques graphiques. Même si les problèmes d’interopérabilité entre les divers navigateurs existent toujours, leur résolution est nettement plus aisé que le portage d’une application développée dans un langage compilé d’un système à l’autre.
• Plus de problèmes de copies piratées, puisque tout le contrôle se fait côté serveur. Il est certes toujours possible de se faire passer les identifiants, la mise en commun des documents avec les heureux possesseurs de mes accès risque fort de poser problème un jour ou l’autre.
• La décentralisation totale des ressources, permettant à tout un chacun de travailler de n’importe quelle machine sans avoir à rapatrier un profil, un parc applicatif, une configuration et des documents sauvegardés. Tout se ferait côté serveur, ce qui supprimait bien des problèmes d’administration.
• Dernier mais non des moindres, la solution à tous les problèmes de déploiement et de mise à jour posés par les applications de bureau sur les parcs de taille importante, malgré l’existence d’outils de déploiement automatisés.
• Ma réflexion sur le sujet du point de vue de l’utilisabilité y a plus tard apporté une pierre supplémentaire : la possibilité de supprimer de nombreuses applications toutes les fonctions inutiles dont personne ne se sert jamais et qui les rendent inexploitables ou sous-utilisées. Corollaire : la vente de licences avec différents niveaux de fonctionnalités adaptées aux besoins des utilisateurs. En un mot, remettre ce dernier au centre de la boucle dont il n’aurait jamais du sortir.

Je me rendais rapidement compte des obstacles opposés à l’avènement de ce monde entièrement décentralisé dans lequel l’application web – on ne parlait alors pas encore de web 2.0, nous en étions aux premiers balbutiements d’AJAX, et c’était alors la croix et la bannière pour avoir quelque chose qui marchait vraiment – régnerait en maître.

• Tout restait à faire en matière de portage. Nous sommes en 2007, soit quatre ans après ce premier contact, et la suite bureautique la plus aboutie a encore bien du chemin à faire.
• Même si nous sentions que les choses bougeaient, la crise de confiance dans les valeurs de la première bulle Internet restait tenace, et il faudrait beaucoup de temps avant que les marchés, et à travers eux le grand public s’en remettent.
• Je connaissais peu d’entreprises capables de confier leurs documents à une société tierce, quel que soit le niveau de confidentialité de ces derniers. Le passage par des appliances déployées chez le client pouvait bien résoudre ce problème, mais il déportait alors celui des mises à jour et du déploiement au niveau de l’éditeur, et non plus du SI de la société.
• Enfin, et non des moindres, dès lors que je dois ouvrir mon navigateur pour y accéder, une application web reste un site web, avec toute la connotation négative que cette notion peut porter.

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.