Bonjour, je suis un fan de Discourse, issu d’une petite communauté qui envisage de migrer depuis vBulletin5. Une personne s’opposait à Discourse en déclarant que « détourner Ctrl+f est mal », et après avoir compris ce qu’elle entendait par là, je dois admettre qu’elle a raison. Il existe un sérieux problème d’utilisabilité dans la façon dont Discourse gère actuellement Ctrl+f, qui est le raccourci du navigateur pour « Rechercher du texte sur cette page ».
Le problème
- Parfois, Ctrl+f fonctionne comme prévu : Discourse utilise la fonction de recherche intégrée du navigateur, ce qui fait défiler la page jusqu’au premier résultat immédiatement au fur et à mesure de la frappe. Ctrl+G vous emmène au résultat suivant.
- La vie est belle.
- Parfois, Ctrl+f ne fonctionne pas et affiche à la place une liste de résultats provenant d’une recherche dans la base de données.
- Il ne fait pas défiler la page vers le premier résultat pendant que l’utilisateur tape.
- La phrase de recherche n’est surlignée que si elle se trouve déjà à l’écran.
- Il ne permet pas de rechercher des termes trop courts, comme « UX ».
- Il n’accepte pas Ctrl+G pour afficher le résultat suivant.
- Il affiche des résultats pour des sujets non pertinents que Ctrl+f n’aurait pas montrés s’il n’avait pas trouvé le terme sur la page.
- La raison pour laquelle cela échoue est totalement invisible pour les utilisateurs, mais c’est extrêmement frustrant. Ils ont l’impression que la possibilité de rechercher dans une page a été retirée sans aucune explication.
- Il ne sert à rien de leur dire qu’appuyer deux fois sur Ctrl+f lancera une recherche du navigateur, car cela échouerait à trouver des messages qui existent pourtant.
La cause racine
Ce n’est pas un problème cosmétique, mais un problème fondamental d’utilisabilité que Discourse devra régler à la racine : l’illusion qu’une conversation entière se trouve réellement dans le DOM du navigateur, alors qu’elle est en réalité chargée dynamiquement.
Lorsqu’il y a plus de vingt messages dans un sujet, Discourse n’envoie les messages au navigateur que selon les besoins. Vous pouvez consulter un fil de plus de 1000 messages avec une charge serveur quasi nulle, car la majeure partie du DOM n’est constituée que de squelettes vides. C’est une idée brillante, mais c’est aussi ce qui fait que Ctrl+f échoue mystérieusement.
Je ne suggère pas d’abandonner cette illusion, car je la trouve pertinente. Discourse a eu raison d’abandonner l’ancienne méthode consistant à diviser les conversations en pages arbitraires d’environ 40 messages chacune.
Discourse doit simplement faire mieux pour rendre cette illusion transparente.
Solutions
Pour être honnête, je ne connais pas la meilleure solution, mais j’ai quelques idées qui, je l’espère, seront utiles.
Briser consciemment l’illusion
Tout d’abord, voici quelques idées simples et raisonnables si Discourse choisit de briser l’illusion en passant à une recherche dans la base de données :
- Informez l’utilisateur de ce qui se passe. Affichez une petite note à l’endroit où la boîte de recherche du navigateur apparaîtrait normalement, avec des excuses et une explication.
- « Nous sommes désolés, mais ce sujet contient 1002 messages, alors que votre navigateur n’en a chargé que 7. Par conséquent, la fonction Rechercher dans la page ne fonctionnera probablement pas. Si vous souhaitez tout de même essayer, appuyez à nouveau sur Ctrl+f. »
- Donnez à l’utilisateur un certain contrôle. Lorsqu’un utilisateur appuie sur Ctrl+f, affichez un bouton permettant de charger manuellement le texte de tous les messages du sujet dans le DOM.
- Si cela est jugé impossible en raison de la limite de 100 messages mis en cache dans le navigateur à la fois, affichez alors un bouton permettant à l’utilisateur de revenir à l’ancienne méthode de consultation des sujets : divisés par page.
- « Cliquez ici pour consulter ce sujet d’une manière compatible avec Ctrl+f : [Page 1] [2] [3] [4] [5] [6] [7] [8] [9] […] [>>] »
- Augmentez la limite par défaut de 20 à 100 messages. Ce changement pourrait ne pas être trop difficile à implémenter, car Discourse est déjà capable de mettre en cache ce nombre de messages dans le DOM.
Réparer l’illusion
Bien sûr, ces idées sont peu élégantes et je les considère comme des solutions provisoires. À terme, la meilleure solution serait que Discourse implémente Ctrl+f d’une manière qui corresponde aux attentes des utilisateurs. Répliquer dans Discourse ce que fait le navigateur pour la recherche interactive en valdrait largement la peine, mais je suppose que cela serait difficile.
Cependant, il pourrait exister une solution (relativement) simple.
Ne pas supprimer le texte du DOM
Je crois que la meilleure solution pour Discourse est de ne supprimer que les objets multimédias des messages, et non le texte. Ainsi, il n’y aurait plus besoin de « détourner Ctrl+f » pour le remplacer par une recherche dans la base de données.
La fonction Rechercher dans la page ne recherche que du texte, il n’est donc pas nécessaire que le navigateur dispose de tout le DOM chargé pour pouvoir le parcourir. Le texte est extrêmement léger à transmettre, surtout si le serveur HTTP a la compression gzip activée. Le texte ne prend pas non plus beaucoup de mémoire dans un navigateur web.
Vous le savez mieux que moi, mais j’ai quelques hypothèses :
- Taille moyenne d’un message : 5 Ko de texte
- Longueur moyenne d’un sujet : 50 réponses
- Texte moyen à transférer : 250 Ko, ce qui semble raisonnable.
Bien sûr, chaque octet compte pour la réactivité. Si mes estimations sont inexactes et que la taille du texte pose problème, le remplissage du DOM avec du texte pourrait être effectué comme un processus d’arrière-plan une fois les parties importantes de la page envoyées. Si le DOM n’est pas complètement rempli de texte au moment où l’utilisateur appuie sur Ctrl+f, un indicateur peut apparaître pour informer l’utilisateur d’attendre et montrer la progression au fur et à mesure que le texte arrive.
Merci
Bien qu’il s’agisse d’un problème sérieux que Ctrl+f brise l’illusion créée par Discourse, je suis impressionné par le travail remarquable accompli par les développeurs de Discourse pour créer cette illusion dès le départ. Je suis convaincu qu’ils trouveront également la bonne solution pour ce problème à terme.
Merci d’avoir pris le temps de considérer mes suggestions.
Cordialement,
Mx. F.N.