Je ne peux pas résoudre deux choses :
Quelqu’un d’autre a-t-il rencontré ce problème ?
C’est possible, mais nous avons un cas particulier qui le rend plus compliqué qu’une simple intégration. Le sélecteur de catégorie n’autorise que l’ajout de catégories existantes… mais nous autorisons actuellement une entrée personnalisée @ pour appliquer le composant à la vue de niveau supérieur “toutes les catégories”.
Nous devrons séparer cela dans un paramètre distinct et migrer les paramètres existants pour pouvoir utiliser la liste déroulante des catégories.
Cet onglet ?
Je ne parviens pas à reproduire le problème, il a peut-être déjà été résolu — si vous le rencontrez toujours, faites-le nous savoir.
Désolé, j’ai depuis quitté Discourse et ramené ma communauté sur Discord.
C’est incroyablement déroutant. Pourriez-vous expliquer ce que signifie le « @ » et comment l’utiliser ? Je l’ai vu dans l’interface utilisateur des paramètres Kanban et je n’ai pas pu comprendre ce qu’il fait.
De plus, pourquoi avoir un « @ » personnalisé rend-il impossible l’utilisation de la liste déroulante ? Il suffit d’ajouter l’entrée « @ » à la liste déroulante, cela ne fonctionnerait-il pas ? Et encore mieux, pourquoi le nommer « @ » ? Dites « Toutes les catégories » dans cette liste déroulante, et faites en sorte qu’elle utilise le « @ » en coulisses. Il s’est avéré trop cryptique même pour moi, un développeur de logiciels, qui utilise Discourse depuis sa création.
Ceci est évidemment hors sujet, mais j’aimerais ajouter mon grain de sel et dire que les frustrations persistantes avec l’interface utilisateur de Discourse me rendent complètement incapable de recruter mes partenaires et les parties prenantes du projet pour utiliser Discourse. Ils détestent tous l’interface utilisateur, ils ne peuvent tout simplement pas l’utiliser car elle est déroutante par tous les moyens, et cette incapacité à configurer Kanban comme un outil utile ne fait qu’ajouter à la frustration de ces partenaires que j’essaie de convaincre d’adopter l’utilisation de Discourse pour la gestion de projet. Pour revenir au problème réel discuté dans ce sujet, comment diable dois-je expliquer le « @ » à un responsable qui veut simplement ouvrir le panneau des paramètres et configurer les listes Kanban à sa guise ? Ce sont toutes ces petites choses qui s’accumulent et désorientent complètement les gens lorsqu’ils entrent dans l’espace Discourse, et ils essaient de partir immédiatement et me demandent de ne plus interagir avec eux sur cette plateforme car cela leur fait perdre du temps. Je suis impuissant à enthousiasmer les gens pour Discourse. Et pour couronner le tout, pour une raison quelconque, l’équipe Discourse aggrave certains aspects de l’interface utilisateur au lieu de l’améliorer, voyez une mise à jour récente ici et ma critique à ce sujet : Now that the topic title is editable by click, I can't simply copy it without entering the edit mode
Au fait, si j’entre là-bas @MaCatégorie (ce que j’ai fait intuitivement en essayant de comprendre ce que fait le @), cela ne me dit aucune erreur de validation. Comment est-il considéré comme acceptable de ne pas me dire que je fais quelque chose d’incorrect alors que c’est évident du point de vue du programmeur, et que cela peut être facilement détecté lors de la « Sauvegarde… » de la valeur du paramètre mis à jour ?
Désolé, j’ai dû tout dire, surtout après avoir vu que quelqu’un avait quitté Discourse et était retourné sur Discord, ce qui n’a fait que confirmer mes préoccupations et mes frustrations concernant l’interface utilisateur.
J’ai vraiment essayé, mais il y a trop de complexité. C’est comme au bon vieux temps - les guerres Android contre iPhone.
Android vous permettait de personnaliser tout ce que vous vouliez.
iPhone était super limité, mais… ça fonctionnait tout simplement.
C’est le même cas avec Discourse en ce moment. Je crois que nous devons suivre davantage la voie d’Antoine de Saint-Exupéry : « La perfection est atteinte, non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher ».
Il y a tellement de confusion (comme les MP par rapport aux discussions privées, pour ne citer que le premier qui me vient à l’esprit) qu’il est vraiment difficile de convaincre les gens de l’utiliser librement. Sur Discord, il y a moins de friction. Idem avec Skool. Je pense que c’est ce que nous devrions viser, pas ajouter plus de fonctionnalités.
J’ai récemment eu un client qui a quitté Discourse pour exactement la raison que vous mentionnez - la complexité.
Mais à vrai dire, en regardant certains serveurs Discord, je ne dirais pas qu’ils étaient du tout simples ? Il y a beaucoup de choses que l’on peut ajouter à un serveur Discord maintenant (y compris des bots).
Un inconvénient majeur de passer à Discord ou à toute application sur mesure en cloison est que vous perdez en référencement SEO, non ? Peut-être que cela ne vous impacte pas.
Celui qui l’a implémenté a choisi @ comme symbole unique pour représenter les listes de sujets de niveau supérieur lorsqu’elles ne sont pas filtrées par catégorie ou par étiquette. C’est comme forum.example.com/latest ou forum.example.com/top. Vous entrez donc @ séparément comme entrée propre pour l’appliquer là-bas.
Je suis d’accord que c’est déroutant, mais c’est quelque chose qui peut être ignoré à moins que vous ne vouliez des tableaux kanban globaux.
Ce n’est pas le cas, cela complique simplement le passage à la liste déroulante des catégories car nous devons également créer une migration afin de ne pas annuler les paramètres des sites qui l’utilisent déjà de cette manière.
Les paramètres du thème sont dictés par les API principales, donc lorsque nous utilisons le type de liste de catégories, nous ne pouvons pas l’étendre avec des options supplémentaires du thème lui-même.
Discourse n’est pas une entreprise massive, nous avons des contraintes de temps pour nous concentrer sur les fonctionnalités les plus utilisées et le refactoring des composants (qui sont offerts gratuitement d’ailleurs) peut être difficile à prioriser. Si quelqu’un souhaite sponsoriser des améliorations des paramètres kanban, nous pouvons certainement en faire une priorité plus élevée.
Discord dispose-t-il d’une fonctionnalité de tableau kanban ? J’ai cherché mais je n’ai pas trouvé grand-chose à part un bot qui s’intègre à un service kanban externe.
Vous perdez également un certain contrôle, vos utilisateurs sont des utilisateurs de Discord, le contenu qu’ils publient est également le contenu de Discord. Lorsque quelqu’un paie pour Discord, le profit revient à Discord. Il y a des compromis et des coûts pour chaque plateforme.
Oui, il n’est pas clair quand nous serons en mesure d’accorder de l’attention à la fonctionnalité Kanban pour le moment.
C’est quelque chose que j’aimerais revoir à un moment donné. Je pense que l’adoption du composant de thème a apporté des preuves qu’il existe un désir pour plus de ce genre de choses.
L’implémenter en tant que composant de thème a eu des avantages – il est relativement facile pour tout administrateur de le trouver et de l’installer – mais cela s’accompagne également de contraintes importantes qui rendent difficile sa conception comme on pourrait s’y attendre.
Si et quand nous y reviendrons, je pense qu’il y a deux voies possibles que nous pourrions emprunter – nous pourrions utiliser l’ensemble de fonctionnalités souhaité pour un tableau Kanban comme une raison d’améliorer les API disponibles pour les composants de thème, ou nous pourrions en faire une fonctionnalité principale ou un plugin et avoir plus d’accès pour ajouter des API serveur adaptées à nos besoins.
En attendant, je pense qu’il ne recevra que des ajustements pour des problèmes spécifiques.
C’est vrai, mais ce fardeau repose sur nous - les propriétaires - pas sur les utilisateurs. Les utilisateurs le voient de la manière la plus simple qui soit :
choisir un canal → envoyer le message et c’est tout !
Il n’y a pas de Kanban. Il n’y a pas besoin de comprendre la différence entre Regarder et Suivre. Il n’y a pas tout un tas de fonctionnalités du type « hé, comme ce serait cool si discourse pouvait AUSSI faire ceci ou cela ».
Toutes ces fonctionnalités sont super cool, pour nous - les techniciens/propriétaires/administrateurs.
Mais pour les gens ordinaires, ils veulent un sentiment de communauté. Ils veulent sentir qu’ils sont libres de s’exprimer et qu’ils n’ont pas à comprendre toutes ces centaines (je crois qu’il y en a tellement) d’options, de termes et d’autres choses différentes.
C’est exactement le retour que j’ai des parties prenantes. Ils se perdent entre les discussions et les sujets privés.
Dans mon projet actuel, le propriétaire du projet explore Basecamp parce qu’il dit ne pas pouvoir utiliser Discourse après l’avoir essayé. Je défends Discourse parce que je connais ses fonctionnalités et capacités exceptionnelles, mais je ne peux pas faire grand-chose car la faible convivialité et le désordre dans l’interface utilisateur et la terminologie l’emportent toujours sur la fonctionnalité. Sans parler du Markdown que toute personne normale et non technique déteste et que je ne peux pas leur expliquer pourquoi ce n’est pas wysiwyg en premier lieu. Dieu merci, l’équipe Discourse travaille enfin sur un éditeur approprié. La plupart des gens veulent un éditeur de texte simple, similaire à Word, avec seulement quelques fonctionnalités : formatage, tableaux, couleurs, images, extraits de code. Il n’y a aucune raison pour qu’une partie de cela soit obtenue sous forme de markdown par un utilisateur ordinaire. Des fonctionnalités plus sophistiquées comme l’IA semblent inutiles lorsque l’utilisateur final ne peut pas comprendre pourquoi son éditeur de texte de publication est divisé verticalement en deux colonnes — c’est à cela qu’ils pensent, pas à l’IA.
Ils ont toutes les données. C’est le marché, et je comprends la frustration initiale, mais je vois beaucoup d’améliorations ces derniers mois sur Discourse.
Les administrateurs peuvent choisir d’arrêter d’utiliser les chats et/ou les messages privés et de simplifier. Cela prend du temps, et il y a une courbe d’apprentissage que tout le monde comprend sûrement. Des avantages et des inconvénients comme pour tout.
Je souhaite le meilleur à l’équipe, et je pense que nous devons vraiment contribuer et laisser du temps au processus d’évolution naturelle.
C’est un comportement acceptable à court terme, mais ce n’est pas une très bonne dynamique pour organiser l’information ?
Les utilisateurs qui tirent à l’aveugle > un site web bien organisé.
D’où l’accent mis par Discourse sur la modération et les outils pour organiser les choses ?
C’est précisément dans ce cas que nous ne suivons pas l’évolution du paysage de la manière dont les membres de nos communautés consomment le contenu.
J’ai été confronté exactement à la même décision. Avoir quelque chose de robuste, bien organisé, avec un excellent référencement, quelque chose qui nous permettra de créer un héritage compte tenu de la nature du contenu que nous créons.
Mais aujourd’hui, les gens (et c’est évidemment une généralisation) n’ont pas l’impression, par exemple, que Slack leur retire quelque chose en limitant l’historique aux 90 derniers jours.
L’un de mes membres m’a dit (et c’est une entrepreneure extrêmement prospère qui vient d’avoir 30 ans) qu’aujourd’hui, si l’information a plus de 3 mois, elle ne la lit pas, car tout change si vite, déterrer de vieilles choses est une perte de temps. Qu’il s’agisse d’affaires, de sciences ou… eh bien, de la vie.
Et bien sûr, avoir des fils de discussion comme nous en avons ici concernant des plugins qui pourraient être mis à jour dans plusieurs mois - c’est un cas valable. mais autre que cela - dans le sens de « construire la communauté », il s’agit plus du « sentiment d’appartenance » et de pouvoir interagir avec cette communauté avec peu ou pas de friction, au lieu de comprendre toutes les options qui nous submergent.
J’en ai parlé dans des fils de discussion précédents, où je me renseignais sur le succès de Skool, par rapport à Discourse.
Je comprends tout à fait, merci pour votre point de vue.
Pour être parfaitement clair - je vois un potentiel incroyable dans Discourse, et si je peux un jour aider l’équipe avec mon expérience dans la construction de communautés - je suis heureux de contribuer.
