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

Bien que la loi oblige les fabricants à traduire les notices de traduction en 8 à 11 langues différentes, selon le type de produit, on peut légitimement se demander à quoi elles servent tant les utilisateurs les ignorent royalement. On fera cependant une exception pour les notices de montage des meubles de la marque suédoise Ikéa, dont la simplicité est connue dans le monde entier. Il n’en est semble-t-il pas de même avec l’informatique, comme le montre cette tranche d’histoire de l’Internet français dans laquelle on voit un opérateur se battre pour faire comprendre le bon fonctionnement de ses équipements à des clients pourtant supposés technophiles.

Au milieu des années 90, lorsque apparurent les tous premiers modem ADSL USB, la notice d’utilisation de ces derniers spécifiait en toutes lettres que l’installation des outils fournis sur un CDROM était le préalable obligatoire au branchement du modem. Dans le cas contraire, une corruption de la base de registre Windows invitait le contrevenant à réinstaller son poste, avec la perte des données qui résultait.

Après une période de plusieurs mois durant lesquels son service d’assistance technique croulait sous les appels de clients enragés – et on les comprend – un opérateur de l’époque décida de pallier au problème. Dans ce but, il ajouta sur le dessus du carton contenant le kit de connexion un papier sur lequel était écrit en rouge sur fond blanc : “installez les outils présents sur le CDROM avant de brancher le modem”. Le nombre d’appels pour cause de réinstallation forcée diminua d’environ 5%, ce qui est bien, mais pas top.

Afin de faire passer l’information, il fut décidé de placer un autocollant affichant le message d’avertissement en blanc sur fond rouge sur le corps même du modem USB. Il fallait forcer les utilisateurs à prendre connaissance du message au moment du déballage de l’engin. Peine perdu, le nombre d’appels quotidien chuta à nouveau de 5%.

Puisque la notice, la partie supérieure de l’emballage et le modem ne suffisaient pas, il fallait aller au devant des utilisateurs les plus bornés. L’opérateur fit donc appel au bon sens de sa R&D, qui, une fois n’est pas coutume, n’en manquait pas. Il fut donc décidé de mettre un cache sur les prises USB du modem, scellé par l’autocollant sus-cité, pour voir enfin les utilisateurs prendre connaissance des consignes d’utilisation. La quatrième tentative fut la bonne, et les appels à la hotline pour ce motif diminuèrent de plus de 80%.

En guise de conclusion, je rappellerai deux points fondamentaux pour tout concepteur de site web – et concepteur tout court d’ailleurs :

1. N’imaginez pas un seul instant que votre application puisse être un jour utilisée de la manière dont vous l’avez conçue.
2. Si vous devez placer un garde-fou quelque-part, faites le toujours le plus tard possible, et de la manière la plus bloquante possible.

Sur ce, je vous souhaite une bonne nuit. Si vous êtes sages, demain, nous parlerons des manières de concevoir une application web idiotproof.

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.

Vous avez développé une petite application pour vos propres besoins, par exemple un outil de publication en ligne. Des gens l’ont remarquée et ont commencé à s’y intéresser, au point que vous la publiiez sous une licence quelconque, pour le plus grand bien de la communauté. Et un jour, ce qui allait très bien pour une seule personne ne suffit plus, et vous décidez de franchir le pas : rendre votre application multi utilisateurs. Belle initiative, mais par où commencer ?

Quels utilisateurs ?

Commencez par remettre à plat l’ensemble des fonctionnalités de votre outil. Recensez chacune d’entre elles et classez les par groupe en fonction des utilisateurs “type” qui seront amenés à les utiliser.

Dans notre cas, nous séparons les fonctionnalités de l’application en 3 groupes distincts :

L’administration

• La configuration.
• Le paramètrage du thème.
• La sélection des greffons.
• La gestion des utilisateurs.

La publication

• La gestion / publication des billets.
• La gestion des catégories.
• La gestion des média.
• La modération des commentaires.

La contribution

• Ajout de commentaires.

Et voilà, nous avons défini 3 profils types, et défini leurs attributions possibles. Nous aurions pu en définir plus, par exemple un rédacteur qui aurait des droits d’écriture mais pas de publication, ou un modérateur pour les contributions qui n’aurait pas de droits en écriture, mais nous choisissons la simplicité. Reste maintenant à l’implémenter dans notre application, et là, deux choix s’offrent à nous.

Implémentation par profils

L’implémentation par profils est la plus simple à mettre en oeuvre, au détriment de la souplesse. On attribue un profil à chaque utilisateur, puis, pour chacune des actions possibles, on contrôle le profil de l’utilisateur, et on agit en conséquence. Pour cela, on va créer 3 méthodes, vérifiant que l’utilisateur dispose bien du profil voulu :

Vous remarquerez que pour chaque profil inférieur, on vérifie également que l’utilisateur dispose du profil supérieur. En effet, on considère que les utilisateurs hiérarchiquement les plus élevés disposent de fait des droits les plus bas.

Implémentation par droits

Beaucoup plus complexe à mettre en place, l’implémentation par droit est en revanche extraordinairement souple. Elle ne convient cependant pas à n’importe quelle application car elle a son petit effet “usine à gaz”, vous pèserez donc bien le pour et le contre avant de la mettre en place.

Le principe est simple : vous définissez une série de droits ; chacun de ces droits correspond à une action possible sur l’application : créer une catégorie, modifier un billet, effacer un commentaire, afficher la liste des utilisateurs… Vous remarquerez au passage que ce système de droits repose sur le CRUD (Create, Read, Update, Delete) et trouve tout à fait sa place dans une application RESTful, mais je m’égare. Une fois définis les droits, vous créez les profils fonctionnels que nous avons vus tout à l’heure, et vous leur attribuez les droits qui vont bien. L’administrateur les aura à priori tous, le contributeur n’en aura que très peu. Pour cela, faites un tableau de correspondance entre les deux. Il y a d’ailleurs de fortes chances pour que vous ayez le même dans votre application :

Droits	Administrateur	Rédacteur	Contributeur
Créer un billet	X	X
Ajouter un utilisateur	X
Ajouter un commentaire	X	X	X

Vous assignez ensuite un profil à chaque utilisateur. Pour chaque action possible, vous vérifierez que l’utilisateur dispose bien du droit adéquat. Pour cela, on va créer une méthode toute simple :

Deux choses rendent cette implémentation par droits formidablement souple :

• Vous pouvez ajouter autant de profils que vous le souhaitez, puisque ceux-ci ne sont que des conteneurs à doits. Les droits sont en effet liés à l’utilisateur et le profil ne sert qu’à les grouper.
• Vous pouvez très facilement surcharger un profil en attribuant ou supprimant des droits à un utilisateur spécifique.

Et maintenant ?

Il ne vous reste plus qu’à vous mettre au travail, en réfléchissant bien à ce que vous souhaitez faire de votre application. Chaque système a ses avantages et ses inconvénients, et passer de l’un à l’autre est tout sauf évident.

Et pour ceux qui pensent que ce billet est une réflexion sur ce que pourrait devenir Typo dans un futur proche, vous vous trompez. 50% du code est déjà fait, il me reste à le propager à l’ensemble de l’application.