Bonjour.
J’ai lu plusieurs sujets ici concernant l’organisation des catégories et des étiquettes, mais je n’ai pas réussi à trouver une structure qui corresponde à mes besoins.
Il s’agit essentiellement d’un forum de support couvrant de nombreux produits. Il y a peut-être 50 à 100 produits différents, regroupés dans environ 5 à 10 « départements ».
Je souhaiterais également différencier les permissions pour les clients et les non-clients. Cela signifie que les non-clients auront un accès en lecture et en écriture uniquement au support « standard », et un accès en lecture au support « VIP », tandis que les clients auront un accès en lecture et en écriture aux deux.
De plus, j’aimerais utiliser le système de votes pour créer un mécanisme de « demande de fonctionnalités » permettant aux utilisateurs de demander des fonctionnalités et de voter (pour chaque produit). Là encore, seuls les clients pourront demander des fonctionnalités et voter ; les utilisateurs ne pourront voter que sur les demandes de fonctionnalités, et non sur d’autres sujets. Bien sûr, tout le monde (le personnel et les utilisateurs) devrait pouvoir voir facilement les fonctionnalités les plus demandées.
Quelle est la meilleure option ? Au début, je pensais utiliser une multitude de catégories :
DépartementA
Produit1
Demandes de fonctionnalités
VIP
Produit2
Demandes de fonctionnalités
VIP
DépartementB
Produit3
Demandes de fonctionnalités
VIP
Produit4
Demandes de fonctionnalités
VIP
Mais cela semble être trop de catégories.
Les étiquettes semblent aider dans ce cas, mais comment pourraient-elles être utilisées, imposées, filtrées et comment les permissions pourraient-elles être appliquées ?
L’un des principaux inconvénients que je vois avec les étiquettes (outre les problèmes de permissions) est que, sur tous les forums Discourse que je visite et qui servent d’« exemple » pour les étiquettes (comme celui sur les voitures, mais il y en a d’autres), au final, il semble que les étiquettes ne soient tout simplement pas utilisées. Très peu de sujets sont étiquetés, et tout finit au même endroit.
Je ne suis pas sûr que cela réponde à vos besoins, mais je partage l’expérience dans l’espoir qu’un élément puisse vous aider.
Nous avons récemment migré notre communauté de 16 ans de SMF vers Discourse. Nos utilisateurs étaient très satisfaits des multiples niveaux de catégories, sous-catégories et forums enfants. C’était vraiment ridicule, le nombre que nous avions. Les nouveaux utilisateurs se perdaient facilement dans ce labyrinthe.
Depuis notre passage à Discourse, nous avons désormais Catégorie > Sous-catégorie > Tags. Les tags ont remplacé les 917 281 forums enfants que nous avions auparavant.
J’ai rendu obligatoire l’utilisation d’un tag pour publier un sujet, et les utilisateurs ne peuvent choisir que parmi les tags que j’ai créés pour chaque catégorie.
Réglez le paramètre de la catégorie sur « Nombre minimum de tags requis dans un sujet : 1 »
Créez des groupes de tags pour chaque catégorie et décochez « Autoriser également d’autres tags » dans les paramètres de la catégorie :
Nous avons rouvert nos portes pour le Nouvel An, c’est donc encore en cours d’ajustement, mais vous pouvez voir ici mes regroupements de tags : the Lettuce Craft Forums
Dans le flux de création de sujet, l’utilisateur est obligé de sélectionner au moins 1 tag. J’ai personnalisé le libellé pour dire « Maintenant, sélectionnez un tag (sous-catégorie) ». Je sais qu’un tag n’est pas réellement une sous-catégorie, mais c’est le terme qu’il nous faut utiliser pour apprendre à notre vieille communauté à utiliser de nouvelles méthodes pour l’instant.
Vous deux avez donné à ce sujet l’apparence du début d’un tutoriel grâce à vos messages clairs et instructifs.
J’ai rédigé cette réponse longue car je réfléchis à la manière d’aborder la création de nouveaux forums. J’ai donc pensé expérimenter avec votre problème pour voir si je pouvais préparer quelque chose et vérifier si cela vous est utile.
Je suis d’accord avec l’idée d’utiliser des tags plutôt que de tout mettre dans des catégories, ce que je fais moi-même sur certains forums privés. Mais il faut être conscient qu’à l’heure actuelle, les catégories présentent deux avantages clairs :
Les catégories sont essentielles pour contrôler l’accès
Les plugins permettent une personnalisation beaucoup plus poussée des catégories
Les nouvelles fonctionnalités de tags font l’objet de développements fréquents actuellement et constitueront un grand pas en avant pour faciliter leur utilisation. Parmi celles-ci :
Le problème clé ici est de déterminer lesquelles de vos exigences doivent être gérées comme des catégories plutôt que comme des tags. Mais nous n’avons pas à prendre cette décision dès le départ. Nous concevons d’abord les catégories, qui sont des fonctionnalités lourdes, puis nous examinons ce qui peut être converti en tags.
Le processus de prise de décision
Il existe plus d’une façon d’aborder la conception de vos catégories. Lorsque les tags ne sont pas considérés comme le mécanisme principal, je suivrais cette démarche :
Quelles catégories sont nécessaires ?
Quelles catégories nécessitent des contrôles d’accès utilisateur distincts ?
Ai-je maintenant besoin des catégories par défaut ?
Voici une approche différente de celle qui serait normalement utilisée, car vous pouvez voir les catégories par défaut minimales qui pourraient vous permettre de tout faire avec des tags.
Ai-je besoin des catégories par défaut ?
Quelles catégories nécessitent des contrôles d’accès utilisateur distincts ?
Quelles autres catégories sont nécessaires et ne nécessitent pas de contrôles d’accès utilisateur ?
A. Quelle est l’exigence globale ?
Tout d’abord, quelle est la raison d’être de la communauté qui servira à développer la structure du forum ? La communauté et le forum sont deux choses différentes.
D’après votre premier message, je peux dire que vous avez les exigences suivantes pour votre communauté :
L’objectif principal est le support
Le Support est piloté par le produit, c’est-à-dire qu’il n’y a pas de clients sans produits, et donc pas de support requis.
Le Support est segmenté par statut client, c’est-à-dire client vs non-client
Le Produit a une demande de fonctionnalité supplémentaire, venant des clients et des non-clients
Les exigences supplémentaires pour le forum sont que :
Le Département gère le produit, mais le client/l’utilisateur interagit via le produit
Notes :
Le support peut être géré par département, mais les clients/utilisateurs sont probablement liés aux produits qu’ils utilisent. Je ne compliquerais donc pas le forum en incluant votre structure organisationnelle, sauf si vos départements sont des marques ou des sociétés filiales avec lesquelles les clients et utilisateurs s’identifieront presque exclusivement dans leurs interactions normales.
J’utilise Client ici car il devrait y avoir une mise en garde sur l’utilisation de VIP. Cela supprime la possibilité de créer ultérieurement un sous-groupe VIP de clients. J’ai déjà vu ce problème dans un forum pour professionnels de la communauté, je réserverais donc VIP pour une segmentation supplémentaire.
B. Quelles sont les catégories minimales pour atteindre l’exigence globale ?
1. Ai-je besoin des catégories par défaut ?
Je considère que toutes les catégories par défaut sont essentielles, mais vous pourriez ne pas en avoir besoin. Sachez simplement que les paramètres par défaut sont définis avec beaucoup de considération pour les exigences du propriétaire de forum moyen et des utilisateurs de forum :
#lounge
Par défaut, cela s’adresse aux utilisateurs de Trust Level 3 (TL3). Je vous suggère de le conserver comme un avantage pour vos non-clients les plus actifs. Vous pourriez être tenté de l’utiliser pour votre catégorie VIP en la renommant et en réduisant le TL minimum pour y accéder. Ne le faites pas : gardez votre groupe VIP et sa catégorie séparés des groupes et catégories par défaut.
Contribute > Site feedback
Pour tous les utilisateurs afin de suggérer des améliorations ou de signaler des problèmes dans votre forum.
#staff
Pour les administrateurs et modérateurs, donc non visible pour la plupart des utilisateurs.
Uncategorized
Le paramètre par défaut est allow uncategorized topics (autoriser les sujets non catégorisés).
Vous voudrez peut-être désactiver le paramètre suppress uncategorized badge (masquer le badge non catégorisé) pour rendre ces sujets plus visibles dans les listes de sujets, afin qu’ils aient plus de chances d’être attribués à une catégorie plus pertinente.
Cela demande un peu plus de travail aux modérateurs et aux utilisateurs à TL élevé, mais rend les choses beaucoup plus faciles pour les nouveaux utilisateurs qui ne savent pas quelle catégorie choisir.
Cette catégorie est la catégorie shared drafts category (catégorie de brouillons partagés) par défaut, ce qui est une autre raison de la conserver.
Exemple
À ce stade, vos catégories minimales seraient :
Lounge
Site Feedback
Staff
Uncategorized
2. Quelles catégories nécessitent des contrôles d’accès utilisateur ?
La seule exigence certaine est que :
Le Support est segmenté par statut client, c’est-à-dire client vs non-client
Vous voulez séparer les utilisateurs et les clients, donc des catégories doivent être utilisées à cet effet. Toute autre méthode sera extrêmement douloureuse.
Cela signifie que vous avez besoin de clients et de non-clients, chacun dans un Groupe distinct, avec au moins une catégorie où :
Les clients ont un accès CRS (Create, Read, See - Créer, Lire, Voir)
Les non-clients ont uniquement un accès S (See - Voir).
Exemple
À ce stade, vos catégories minimales seraient :
Customer
Lounge
Site Feedback
Staff
Uncategorized
3. Quelles autres catégories sont nécessaires et ne nécessitent pas de contrôles d’accès utilisateur ?
Vos exigences sont :
Le Support est piloté par le produit
Le Produit a une demande de fonctionnalité supplémentaire
Même sans vos exigences, la structure actuelle semble nettement inadéquate car il n’est pas clair où placer les demandes de support produit. Vous avez donc besoin d’au moins une catégorie de support produit, qui nécessite ensuite une sous-catégorie Customer. Je laisserais une catégorie Customer de haut niveau comme endroit pour traiter les problèmes qui ne sont partagés qu’avec les clients et probablement uniquement visibles par eux.
Vous pouvez classer les demandes de fonctionnalités produit en utilisant le plugin Feature Ranking. Cela fonctionne en classant les sujets d’une catégorie, donc vous avez besoin d’au moins une catégorie. Ensuite, vous pourriez avoir deux options pour afficher les classements par produit :
Une catégorie avec des vues filtrées par un tag produit. AFAIK (à ma connaissance), cela pourrait être un obstacle majeur maintenant, mais je ne l’ai pas essayé.
Une sous-catégorie Feature Request par catégorie Product
Quelle que soit l’option choisie, il sera plus facile de placer les sujets Feature Request dans une sous-catégorie.
Exemple sans catégories Product individuelles
À ce stade, vos catégories minimales seraient :
Customer
Lounge
Site Feedback
Staff
Support
Customer
Feature Request
Uncategorized
Exemple avec catégories Product individuelles
À ce stade, vos catégories minimales seraient :
Customer
Lounge
Product 1
Customer
Feature Request
…
Product 100
Customer
Feature Request
Site Feedback
Staff
Uncategorized
Vient maintenant la question de la relation entre les produits et ceux qui les utilisent.
Issue
Une Catégorie pour Support
Une Catégorie pour Chaque Product
La plupart/tous les clients utilisent-ils la plupart/tous les produits ?
Oui
Non
La plupart/tous les clients sont-ils liés à des produits individuels
Non
Oui
Lequel a un meilleur support dans le noyau Discourse
Les tags sont plus limités
Les catégories ont un meilleur support
Lequel a un meilleur support dans les plugins
Les tags sont plus limités
Les catégories ont un meilleur support
Gestion de catégorie plus facile
Oui
Non
Gestion de vue et de rapport plus facile
Non
Oui
Plus facile pour un nouvel utilisateur de Discourse
Non
Oui
Dans l’ensemble, je pense que vous devriez opter pour des catégories individuelles pour chaque produit, car cela fonctionnera et les principaux inconvénients sont la longue vue de la catégorie et une période ennuyeuse passée à configurer les détails de la catégorie et de la sous-catégorie ainsi que l’accès du groupe.
Exemple avec catégories Product individuelles (comme montré ci-dessus)
À ce stade, vos catégories minimales seraient :
Customer
Lounge
Product 1
Customer
Feature Request
…
Product 100
Customer
Feature Request
Site Feedback
Uncategorized
4. Quelles autres catégories pourraient être utiles
Je suis sûr que vous avez conscience d’autres catégories que vous pourriez vouloir et que vous n’avez pas spécifiées ici, par exemple :
Documents de l’entreprise, par exemple des conditions générales génériques valables pour tous les clients et produits
Documents produits, par exemple des documents liés au produit
Téléchargements, par exemple des logiciels liés au produit, tels que d’anciennes versions d’un produit logiciel lui-même
Tutoriels « Comment faire »
FAQ
C. Quelles fonctionnalités devraient être des tags ?
En ce qui concerne les tags que vous devriez utiliser, j’aurais besoin de plus d’informations, par exemple sur la manière dont les départements gèrent le support.
Au début, je laisserais le Département hors de votre forum car vous pouvez développer des rapports basés sur Product avec des résumés par Département qui n’auraient besoin d’aucun tag visible.
Je vous renvoie à des sujets existants ici pour vous donner un aperçu de ce qui peut être fait avec les tags dans un forum de support. Ces sujets sont du plus récent au plus ancien :
Merci à vous deux, @soraiden et @Remah, pour vos réponses très détaillées. Je vous en suis vraiment reconnaissant.
Je n’ai pas encore décidé, cependant. C’est vraiment difficile.
Les suggestions de @Remah semblent mieux adaptées à ma situation, mais quand vous dites : « alors vous aurez une Documentation, des HowTo, des FAQ, etc. » — ne seront-elles pas aussi liées aux produits ?
Cela renforce l’impression que les produits devraient être des tags, sinon je devrai continuer à dupliquer des sous-catégories partout (comme les « Clients » et les « Demandes de fonctionnalités » suggérés).
D’un autre côté, il est souhaitable que chaque client ait un accès différent selon le produit, car en effet, le Client1 peut avoir enregistré le ProduitA, tandis que le Client1 peut avoir enregistré le ProduitB, et ils sont différents. Même si je pourrais m’en passer si cela était vraiment nécessaire.
J’ai aussi peur de mettre en place une structure basée sur les tags, pour découvrir plus tard qu’une fonctionnalité clé n’est disponible que pour les catégories et pas pour les tags…
Une chose que je n’ai pas comprise dans la suggestion de @Remah : pourquoi aurais-je besoin d’une catégorie « Client » de premier niveau, puis d’une sous-catégorie « Client » à l’intérieur de chaque produit ?
Mais encore une fois, merci beaucoup pour votre réponse très détaillée et bien organisée.
Quel est votre délai pour mettre ce forum en place ? Si le délai est court et limité dans le temps, l’opportunité d’expérimenter avec les balises pourrait ne pas exister.
Au fait, pendant que vous testez, vous pouvez configurer à la fois les balises et les catégories côte à côte. Cela n’a pas d’importance si la structure de vos balises duplique celle des catégories. Si vous utilisez des catégories, les balises n’auront pas besoin d’être utilisées, donc elles ne seront tout simplement pas visibles car personne n’aura à les utiliser.
C’est là le problème qui m’inquiète aussi. Mon cœur dit d’essayer les balises, mais ma tête dit qu’elles ne sont pas encore tout à fait là. J’ai déjà identifié un obstacle potentiel avec les balises : le dans mon message précédent concernant le fait que le filtrage par balises ne fonctionne pas avec le plug-in de classement des fonctionnalités. Cependant, l’équipe de Discourse est motivée pour permettre une utilisation intensive des balises, ils pourraient donc voir des opportunités de développer de nouvelles fonctionnalités pour aider.
Vous pouvez commencer à développer la structure du forum en utilisant des balises plutôt que des catégories. Si vous ne pouvez pas obtenir ce que vous voulez pour le moment, votre solution de repli serait de créer toutes les catégories et sous-catégories de produits.
Assurez-vous de noter tout ce que vous ne pouvez pas faire et ce que vous ne comprenez pas. Ensuite, revenez sur ce forum avec ces problèmes et demandez des solutions.
Les catégories sont très visibles et existent indépendamment des sujets, tandis que la structure des balises n’est pas aussi visible et les balises n’existent que lorsqu’il y a des sujets qui les utilisent. Donc, pour semer le forum avec les balises que vous souhaitez utiliser, vous devrez avoir des sujets « exemples » qui les utilisent, par exemple un sujet de liste de produits.
Un avantage supplémentaire des balises est que vous pouvez créer des groupes de balises afin que vos produits puissent être regroupés sous des groupes de balises pour vos départements. Les groupes de balises départementaux n’auront pas besoin d’être ajoutés aux sujets, car l’ajout de la balise produit à un sujet associera indirectement le groupe de balises à ce sujet. Les balises offriront donc des options uniques que vous n’implémenteriez pas avec des catégories.
Oui, je dirais que c’est très probable. Mais vous devriez passer par le processus de décision des avantages et inconvénients de chaque option.
Si vous avez une sous-catégorie Client pour chaque produit, où placerez-vous les sujets qui concernent tous les clients mais pas tous les utilisateurs ? Cela n’a pas besoin d’être une catégorie séparée, mais il vaut la peine de réfléchir à ce dont vous pourriez avoir besoin ou à ce que vous pourriez exploiter pour faire de nouvelles choses.
Un nouveau forum est une opportunité d’adopter de nouvelles façons de faire.
AFAIK (à ma connaissance), cela