Je voudrais exécuter une instance Discourse unique pour un programme universitaire, où différentes catégories de niveau supérieur correspondent à différents cours, et où l’accès est géré par des groupes. Pour que les instructeurs et les apprenants des cours aient une impression cohérente d’un cours, je voudrais offrir un sentiment d’isolement des différents cours. Je voudrais donc que mon instance offre une expérience de navigation similaire à Teams/Slack/Mattermost, où il y a des équipes relativement isolées, et où les utilisateurs doivent passer de l’une à l’autre. Pour mon instance, cela signifierait que l’interface utilisateur met l’accent sur les données relatives au cours actuellement sélectionné. Ainsi, par exemple, les utilisateurs passent la plupart de leur temps dans l’une des catégories de niveau supérieur, et la sélection de l’une d’entre elles filtre les sous-catégories et les canaux de discussion qu’ils peuvent facilement voir.
Un besoin similaire se présente sur une instance où différentes catégories correspondent à différents groupes de recherche (je voudrais en exécuter une comme ça aussi).
Quels sont les outils existants qui peuvent aider à réaliser cela ?
Cas d’utilisation intéressant ! Une solution possible consiste simplement à masquer les catégories qui ne sont pas pertinentes, afin qu’elles n’apparaissent pas dans les listes de sujets.
Je ne souhaite pas qu’ils soient réellement mis en sourdine : un étudiant suivra probablement plusieurs cours à la fois, et les notifications de tous sont acceptables. C’est plutôt que je veux donner une impression plus claire de « maintenant, je regarde le cours X ».
Il semble que le groupe principal = l’accueil sélectionné, n’est-ce pas ? Vous devez activer user_selected_primary_groups afin que les utilisateurs puissent changer leur groupe principal sur la page de leurs préférences de compte.
Idéalement, je voudrais quelque chose de plus éphémère et de moins visible publiquement. Cependant, j’imagine que si je n’utilise pas le titre et le flair, alors un composant d’interface utilisateur qui bascule le groupe principal fonctionnerait comme un sélecteur d’équipe.
Quelque chose comme le sélecteur de barre latérale supplémentaire qui a été exécuté ici à titre d’expérience il y a quelques jours serait idéal pour cela.
Vous pourriez faire cela. Vous pourriez également changer le logo du site en fonction de leur groupe principal ; je l’ai fait pour un site qui a plusieurs universités partageant une instance. Peut-être auriez-vous un composant de thème avec une liste déroulante dans la barre supérieure qui leur permettrait de sélectionner leur groupe principal (et peut-être de dire « classe » au lieu de « groupe »).
@Anton_Akhmerov espères-tu le faire toi-même ou serais-tu prêt à payer quelqu’un pour le faire à ta place ? Fais-moi savoir !
Si tu veux le faire toi-même, j’aimerais déplacer ceci dans Dev afin que tu puisses y travailler et faire un compte-rendu à la communauté et obtenir l’avis des autres membres. Déplaçons ceci dans Dev.
Si tu veux payer quelqu’un, je le déplacerai dans Marketplace.
Je pense qu’il serait préférable de déplacer ceci vers Community et de discuter davantage de votre cas d’utilisation, de la meilleure façon de répondre à vos besoins aujourd’hui, et de faire de la place pour d’autres qui auraient pu avoir des besoins similaires et les avoir résolus.
Ensuite, s’il y a des lacunes spécifiques identifiées que vous jugez suffisamment importantes pour les construire vous-même ou pour les défendre, nous pourrons créer des sujets distincts dans Feature et/ou Dev pour ces idées.
Cela correspond-il à votre réflexion ? Ou êtes-vous déjà dans la phase « Je suis prêt à construire les pièces manquantes » ?
#communauté a du sens aussi . La fonctionnalité semble délicate et semble quelque peu alignée sur les besoins de la communauté, compte tenu de la popularité des demandes de ce type
Je prévois de travailler dessus, mais jusqu’à présent, mon plan est plutôt vague.
Pour faire suite, voici comment j’imagine le mieux répondre à vos besoins avec les fonctionnalités intégrées de Discourse. Ce n’est peut-être pas exactement ce que vous avez en tête, mais je pense que cela vaut la peine d’être considéré comme point de départ pour la discussion.
Tout d’abord, je fais quelques suppositions, qui peuvent être valides ou non. Veuillez me faire savoir où je me trompe :
Il y aura de nombreux cours (des dizaines, voire des centaines)
La mise en place des cours se fera périodiquement, par lots importants, au début de chaque trimestre (2 à 4 fois par an)
Les cours auront une date de fin de vie
Les personnes qui gèrent les cours doivent avoir une certaine capacité à les mettre en place elles-mêmes
Les personnes qui gèrent les cours auront une expérience limitée, voire nulle, de la gestion d’un site Discourse.
Les personnes qui gèrent les cours n’ont vraiment besoin de voir que les leurs. Elles peuvent vouloir voir les autres occasionnellement comme exemples, mais n’ont pas besoin d’une participation continue à ceux-ci.
^ Idem pour les personnes qui suivent les cours
Il y a une très petite équipe qui gère le système dans son ensemble
Les cours n’ont pas vraiment besoin de sous-catégories ; l’utilisation de tags pour organiser le contenu au sein des cours serait suffisante
Étant donné que ce sont des hypothèses proches, voici ce que je suggérerais, d’abord à un niveau élevé :
Créez un petit nombre de catégories de premier niveau : une pour « Cours actuels », une pour « Cours passés », une pour « Cours à venir » et une ou plusieurs pour des choses plus générales concernant le système lui-même (par exemple, comment utiliser le site)
Définissez le style de la page d’accueil sur « boîtes avec catégories » afin qu’elles soient bien visibles
Utilisez des sous-catégories pour chaque cours
Créez-les dans « Cours à venir »
Déplacez-les dans « Cours actuels » lorsque le trimestre commence
Lorsqu’un cours se termine, déplacez-le de « Cours actuels » à « Cours passés »
Contrôlez l’accès aux cours à l’aide de groupes (plus de détails ci-dessous)
Contrôle d’accès :
Pour chaque cours, créez un ensemble de groupes suivants, par exemple : foo_interested, foo_enrolled, foo_admin
Créez deux groupes supplémentaires : « browse_courses » et « browse_past_courses »
Définissez les catégories dans « Cours à venir » et « Cours actuels » pour qu’elles ne soient accessibles qu’aux personnes des groupes du cours spécifique et aux personnes du groupe « browse_courses ».
Définissez les catégories dans « Cours passés » pour qu’elles ne soient accessibles qu’aux personnes des groupes du cours spécifique et aux personnes du groupe « browse_past_courses ».
Expérience utilisateur pour les groupes et les cours
Ayez un sujet épinglé dans la catégorie de premier niveau pour « Cours à venir » qui explique comment parcourir les cours, avec un moyen simple pour les personnes de rejoindre le groupe « browse_courses ».
^ Idem pour « Cours actuels »
^ Idem pour « Cours passés »
Pour les cours individuels, ayez un sujet épinglé dans la catégorie expliquant comment rejoindre le cours :
Rejoignez le groupe « foo_interested » et/ou « foo_enrolled »
Ajoutez le cours à votre barre latérale
L’administration sera un peu laborieuse au début, car pour chaque nouveau cours, une personne ayant les privilèges appropriés devra :
Créer la catégorie
Créer les groupes
Créer le sujet épinglé
Ajouter les personnes au groupe _admins
Leur fournir la documentation dont elles ont besoin pour gérer leur propre cours
Certaines de ces tâches pourraient être automatisées avec des outils légers. Selon l’équipe d’administration principale, il peut être judicieux de commencer par quelque chose hors bande qui utilise simplement l’API. Ou peut-être avez-vous besoin de quelque chose de plus basé sur l’interface utilisateur, intégré à Discourse en tant que composant de thème ou plugin. Mais je suggérerais de commencer modestement ici, et de vous concentrer d’abord sur la définition d’un processus qui fonctionne, puis de concevoir les outils autour de cela.
La mise à l’échelle des catégories est une préoccupation possible ici. Discourse présente quelques problèmes de performance et d’UX lorsque le nombre de catégories devient trop important (plusieurs centaines ou milliers). Les utilisateurs ayant accès à plus de catégories en ressentiront l’impact, tandis que ceux ayant un accès limité ne le ressentiront pas. C’est l’une des motivations pour limiter l’accès aux catégories comme je l’ai décrit.
Je suis très intéressé d’entendre tous vos commentaires ou questions sur ce qui précède.
. La fonctionnalité semble délicate et semble quelque peu alignée sur les besoins de la communauté, compte tenu de la popularité des demandes de ce type