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

Ça fait un moment maintenant que je voulais écrire sur l’excellent schémas d’Éric Burke, qui met face à face les produits Apple et Google et les applications d’entreprise. Bien que cruel et un peu caricatural, ce dernier révèle pourtant une situation bien souvent vraie, et révélatrice de deux grands travers de la conception logicielle : la trop grande complexité des processus avec, comme corollaire, le trop plein de fonctionnalités.

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

Quel est le plus court chemin transformant la visite hasardeuse en acte d’achat ? Malgré plus de 10 ans de web, la problématique du mode d’accès aux données revient fréquemment dans la conception d’un site ou d’une application web. C’est justement à ce problème que s’attaque Patricia Gallot-Lavallée dans son ouvrage édité à compte d’auteur, et préfacé par Frédéric Cavazza, disponible à partir du 5 septembre prochain.

À travers 60 fiches méthodologiques, le lecteur explore pas moins de 60 modèles de navigation, du plus classique au plus innovant, dans une optique alliant systématiquement ergonomie, accessibilité et référencement.

Chaque fiche est présentée sur une double page, et s’accompagne d’exemples glanés sur le web. Une évaluation visuelle permet de noter le modèle sur 3 points : appréciation globale, coût en termes de temps et de budget (les deux étant le plus souvent liés), et accessibilité. Un paragraphe intitulé “pour qui” décrit succinctement le genre de site auquel se destine le modèle étudé. Un avertissement portant souvent sur l’accessibilité ou un conseil complètent cette première colonne qui permet de se faire une idée rapide de la pertinence du modèle.

Le coeur de la fiche consiste en une série de conseils méthodologiques et de bonnes pratiques visant à une mise en place de qualité du modèle. L’approche est technique, mais accessible, et une explication accompagne chaque point abordé. La démarche donne systématiquement la place la plus importante à l’utilisateur dont la satisfaction complète constitue le coeur véritable du livre.

La fiche se termine sur une étude de cas accompagnée d’une interview mettant en avant les avantages, les inconvénients et les limites du modèle étudié.

Mon avis

Je viens de passer la moitié de la nuit et de la journée à dévorer ce livre que j’attendais depuis plusieurs mois jusqu’à la dernière page, et j’ai vraiment adoré. Le livre explore de nombreux éléments d’une page web faisant partie de la navigation sur lesquels je ne m’étais jamais vraiment penché. L’orientation pratique et les conseils très pertinents permettent de se mettre au travail sans attendre, et les bénéfices sur la navigation sont immédiats. On ne regrettera qu’une seule chose : les fiches sont beaucoup trop courtes, et on aimerait pouvoir en lire plus, la limitation venant de la seule double page allouée aux fiches.

Je recommande cet ouvrage aussi bien aux directeurs artistiques et aux designers qu’aux chefs de projets chargés de la conception ou de la refonte d’un site. Conçu comme un livre de recette, Internet, donne moi ce que je veux est un must have dont la place se trouve sur le bureau de tout architectes de l’information.

[edit]
Afin de répondre à une question plusieurs fois posée, il n’y a pas d’erreur dans l’article, la date de sortie du livre est effectivement prévue pour le 5 septembre. Je fais simplement partie des heureux privilégiés à en avoir eu une édition spéciale pré release (et y’a même pas de dédicace, Patricia, prochaine fois qu’on se voit en soirée, tu n’y coupes pas).

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 :

def is_admin
  si notre utilisateur a le profil administrateur 
    alors la condition est vérifiée
  sinon elle est fausse
end

def is_publisher
  si notre utilisateur a le profil rédacteur  
    ou que notre utilisateur a le profil administrateur 
    alors la condition est vérifiée
  sinon elle est fausse
end

def is_contributor
  si notre utilisateur a le profil contributeur
    ou que notre utilisateur a le profil a le profil rédacteur
    ou que notre utilisateur a le profil administrateur
    alors la condition est vérifiée
  sinon elle est fausse
end

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 :

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 :

def has_right(droit)
  si notre utilisateur a le droit correspondant
    alors la condition est vérifiée
  sinon elle est fausse
end

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.

Parcourir ses statistiques de fréquentation à la recherche des mots-clé amenant le visiteur sur votre site est toujours intéressant. Ces derniers fourmillent souvent de surprises amusantes, mais ils vous permettent surtout de vérifier l’adéquation des résultats de recherche avec le contenu publié. Parmi les phrases revenant régulièrement, cms ou framework pour faire un site de rencontre m’a donné envie d’offrir un semblant de réponse aux pauvre âmes en peine rentrées bredouilles après un passage sur ce blog. La question étant relativement large, et ne fixant notamment pas de limitations technologiques, il m’a semblé pertinent de définir le besoin fonctionnel d’un tel site afin de proposer l’option technique la plus performante.

Inscription des utilisateurs

Le système utilisé doit permettre l’inscription libre des utilisateurs. Idéalement, celle-ci doit permettre le choix de son profil minimal :

• Sexe : masculin / féminin.
• Type du compte : gratuit / payant.
• Âge.
• Cible recherchée (âge et sexe).

On pourra choisir de créer des règles spécifiques en fonction du type de compte choisi et du sexe de la personne, selon les modèles éprouvés du genre :

• Gratuit pour les filles.
• Compte gratuit aux fonctionnalités limitées.
• Compte gratuit, complet, mais limité dans le temps.
• …

Cela impliquera donc un système d’inscriptions particulièrement souple avec un workflow et la gestion du paiement en ligne, ce qui n’existe pas à ma connaissance sur les CMS du marché. L’utilisation d’un framework sera donc recommandée dans ce cas précis, à moins de souhaiter modifier en profondeur le gestionnaire d’inscription du CMS. Une étude de rentabilité des deux solutions serait intéressante.

Gestion des profils et droits

L’application devra proposer une solution de gestion de profils et de droits, que l’on opte pour des profils utilisateurs multiples ou pour un profil unifié. Un site de rencontre nécessite en effet des fonctionnalités avancées d’animation et de modération afin de pallier aux problèmes régulièrement rencontrés sur des services de genre : prostitution, harcèlement…

En ce qui concerne la fiche des utilisateurs, qui sera visible par l’ensemble des inscrits sur le site, il faudra à un moment ou un autre trancher entre deux solutions :

• La fiche et le profil des utilisateurs ne sont qu’une seule et même chose, certaines informations étant publiques et d’autres privées.
• La fiche de l’utilisateur est une composition à part entière, complètement indépendante du profil de l’utilisateur, minimaliste.

La seconde solution me semble la plus intéressante. Certains des éléments du profil pourront en effet servir de fiche temporaire le temps que la fiche des utilisateurs soit validée par les modérateurs de la plate-forme, et pourront de plus être affichés en “fiche minimale” pour les comptes gratuits ou les visiteurs, par essence pas encore enregistrés : vous voulez en savoir plus ? Eh bien payez maintenant.

En ce qui concerne la fiche elle-même, elle devra comporter un très grand nombre de champs, précis, et si possible remplis par des menus déroulants, afin de simplifier au maximum les contraintes techniques des fonctions de recherche.

Workflow de publication de la fiche

Je me suis interrogé un instant sur le bien fondé de l’utilisation d’un CMS pour un site de rencontres. Cette solution m’avait semblé un peu curieuse jusqu’au moment où je me suis rappelé que la majorité des sites du genre modéraient les fiches des utilisateurs à priori. On peut dès lors considérer cela comme un workflow de publication avec plusieurs profils :

• Les visiteurs, qui peuvent visualiser une partie des fiches.
• Les membres, qui peuvent visualiser l’ensemble des fiches.
• Les rédacteurs (qui sont aussi les membres), qui rédigent leur propre fiche, mais sans les droits de publication.
• Les responsables de publication, qui ont le droit de modération à priori sur les fiches des membres.

Se pose alors la complexité des profils utilisateurs des sites de rencontres, généralement très fournis, et peu compatible avec les fonctionnalités de publication de base d’un CMS. Les fonctionnalités de workflow rendent néanmoins ces derniers intéressant.

Recherche interne

Le site doit proposer deux types de recherche :

• Une recherche simple, basée sur le profil.
• Une recherche avancée, basée sur la fiche descriptive.

La recherche simple devra principalement porter sur trois critères :

• Qui ? (âge, sexe…).
• Quoi ? (relation durable ou éphémère)
• Où ? (localisation géographique).

La recherche avancée devra refléter la fiche descriptive des utilisateurs autant que faire se peut, afin de sortir des fiches les plus pertinentes possibles. L’utilisation d’un thesaurus dans le moteur de recherche sera un plus particulièrement appréciable.

Messagerie interne

Qui dit rencontre dit contact, donc messagerie interne, au moins dans un premier temps.

Celle-ci devra être particulièrement simple d’utilisation, tout en proposant un minimum de fonctionnalités :

• Classement par thread.
• Insertion du texte dans les réponses.
• Ajout de pièces jointes.

L’utilisation de cette messagerie ne devra pas être le but du site en soi, les utilisateurs étant évidemment invités à (commu)niquer de manière plus directe le plus rapidement possible.

Alors, CMS ou framework ?

Comme diraient les humoristes Chevalier et Laspales, c’est vous qui voyez. Certains CMS comme Joomla proposent par défaut un bon nombre des fonctionnalités citées dans ce billet, mais des développements lourds seront nécessaire. L’avantage d’un framework dans ce cas résiderait dans les fonctionnalités existantes pour conduire un développement spécifique, comme celles offertes par Ruby on Rails et ses nombreux greffons (comme Authorization pour les gestion des utilisateurs). Seule une estimation des temps de développements en fonction du périmètre fonctionnel recherché permettra de trancher.

On dit toujours les cordonniers plus mal chaussés que leurs concitoyens. Je jugez donc pas ce qui suit à l’aune de ce site, peut être aurai-je un jour le temps d’en faire quelque chose d’acceptable. Et puis de toute manière, un blog se lit via son flux XML, pas directement.

Damien Bonvillain a fait cette nuit une lecture très critique de mon CV, et je l’en remercie.

Outre les problèmes concernant le CV lui-même, ses réflexions, justifiées, m’ont donné quelques pistes intéressantes pour la prochaine fois :

Je n’avais pas refait mon CV autrement qu’en agrégeant les connaissances et les expériences acquises depuis des années. Je me rends aujourd’hui compte à quel point il est difficile de donner à son profil une orientation données quand bien même on sait où l’on va, et j’imagine les problèmes que doivent rencontrer ceux qui ne savent pas vraiment où ils vont.