Je cherche à donner une visibilité plus structurée aux tags dans la navigation, en particulier pour ceux d’entre nous qui s’appuient sur Parent > Enfants. Nous avons un peu plus de 40 tags, et une navigation structurée pour les tags (ce qui, sur mon soapbox, sont lamentablement sous-utilisés par tant de forums, alors que Discourse excelle dans ce domaine !) est donc essentielle.
Puisqu’il est inutile d’ajouter plusieurs menus au-dessus de la navigation native de Discourse, ma proposition (je pense ?) n’est rien de trop spectaculaire. J’ai fait un mockup grossier pour illustrer l’idée…
Si une solution similaire existe, je ne parviens pas à la trouver. Le composant de @Johani s’en rapproche le plus, mais malheureusement, il n’est pas structuré.
En tout cas, je serais ravi d’avoir vos retours, même si c’est « Cela n’a pas de sens » ou « Il m’a fallu 10 secondes pour trouver cela sur GitHub, toi nouveau venu ».
Je comprends cette position — je dirais que l’exemple de [tip-toeing] meta n’est pas le meilleur moyen d’utiliser les balises, sans qu’il existe pour autant de meilleure pratique évidente en la matière. Mais même en tant que simple option pour ceux d’entre nous qui disposent d’un vocabulaire contrôlé pour les balises et qui s’y fient beaucoup (beaucoup plus qu’aux catégories), cela pourrait s’avérer utile. Mon exemple était purement illustratif… Je soupçonne que d’autres auront peut-être une meilleure idée !
Pourquoi ne pas simplement utiliser la page des tags ? Vous pourriez mettre en évidence le lien vers cette page de différentes manières. La page elle-même prend en charge la structuration par groupes par défaut.
Ensuite, vous pourriez ajouter des styles personnalisés, soit pour les tags :
Oui, j’adore la page des étiquettes — et sa flexibilité. C’est génial. Mais la page des étiquettes n’est pas omniprésente, alors qu’un menu offrirait une navigation dynamique et permanente, comme c’est le cas pour les catégories.
Je soupçonne, comme moi, que certains d’entre nous s’appuient bien plus sur les étiquettes que sur les catégories. Cela peut sembler contre-intuitif, mais cela a du sens dans certains contextes. Même l’exemple de la voiture utilisé dans le post Étiquettes bénéficierait d’une chose comme celle-ci. Si c’est pour des passionnés de voitures, par exemple, ils pourraient préférer passer d’une étiquette à l’autre (« Ford vs Ferrari ») plutôt que de naviguer entre les catégories.
Enfin, peut-être n’êtes-vous pas encore prêts pour cela. Mais vos enfants vont adorer.
Je serais ravi si vous trouviez une solution plus dynamique ! Mais je suppose que cela impliquerait une quantité importante de codage si vous voulez quelque chose qui ne nécessite pas de maintenance manuelle. En attendant, je me contenterais de rendre le lien vers la page des tags plus omniprésent
L’autre aspect qui rend les tags beaucoup plus conviviaux, selon mon expérience, ce sont les bannières de tags appropriées. J’ai créé un composant simple en tant qu’extension du composant tag-banners qui vous permet d’ajouter des descriptions aux tags : https://github.com/nolosb/discourse-tag-banners-descriptions
Une orientation légèrement différente : j’ai fait en sorte que l’affichage des balises sur les sujets et dans les listes de sujets suive une hiérarchie en fil d’ariane : « parent > enfant » au lieu de « enfant, parent ».
Ma solution était quelque peu spécifique au site et plutôt ingénieuse, mais le résultat final est satisfaisant.
Le plus grand obstacle à ce que j’ai fait, et à ce que vous souhaitez faire, est que Discourse ne précharge pas les groupes de balises, ils ne sont donc pas disponibles au moment où vous en avez besoin sans effectuer une requête API. Je pense qu’il devrait le faire, de la même manière que la structure des catégories est préchargée.
Le problème ici est une limitation d’espace et non une limitation technique.
comme noté ici
Imaginez votre expérience en tant qu’utilisateur ; si vous ouvrez un menu sur un site web, cela ressemble à ceci.
Vous seriez submergé, pour le moins qu’on puisse dire. Surtout puisque ce menu n’a pas de fonction de recherche pour vous aider à affiner les résultats.
Alors, essayons de trouver un juste milieu entre ce que vous voulez faire et ce que les utilisateurs veulent vivre. Comment faisons-nous cela ? Nous affichons un nombre limité de groupes de tags et indiquons qu’il y en a d’autres à consulter. Donc, quelque chose comme ceci :
Notez que le JavaScript ci-dessus respectera le style de tag défini dans les paramètres de votre site. De plus, si votre site repose très lourdement sur les tags, alors vous n’avez probablement pas besoin d’avoir les catégories visibles dans ce menu. Les masquer aiderait à réduire la confusion des utilisateurs.
Aussi, si vous ajoutez une section de tags étendue, alors ce lien devient redondant.
Ces données ne sont pas transmises au client par défaut à moins que vous ne visitiez /tags, donc le code ci-dessus ajoute une requête supplémentaire sur la page d’accueil (exécutée une seule fois par visite). Discourse essaie de garder les choses très simples, donc, à moins que les données ne soient nécessaires, elles ne seront pas chargées par défaut.
Je ne vois pas cela être ajouté au cœur de Discourse de sitôt. Donc, une requête supplémentaire est à peu près votre seul choix ici, sauf si vous voulez écrire un plugin qui s’exécute sur le serveur.
Quelques petites choses… J’ai remarqué que votre réponse initiale récupérait les éléments par groupe de balises (et non par balises enfants). Y a-t-il une raison à cela ? Je n’ai pas réussi à faire apparaître les balises enfants, mais j’ai tout de même obtenu de bons résultats avec votre réponse initiale en utilisant le groupe de balises.
Le seul problème est que les balises ne sont pas visibles pour les utilisateurs non connectés. Je suppose que cela est lié à l’API ? Y a-t-il un moyen de contourner cela ?
Sinon, c’est une aubaine — je peux facilement imaginer d’autres personnes utilisant ce code. Merci infiniment !
