I would like to run a single discourse instance for a university program, where different top level categories correspond to different courses, and where access is managed by groups. For the course instructors and learners to be able to have a cohesive impression of a course, I would like to provide a feeling of isolation of different courses. So I would like my instance to offer a navigation experience similar to teams/slack/mattermost, where there are relatively isolated teams, and the users need to switch from one to another. For my instance it would mean that the UI emphasizes the data related to the currently selected course. So for example, users spend most time in one of the top level categories, and selecting one of those filters the subcategories and chat channels that they can easily see.
A similar need arises on an instance where different categories correspond to different research groups (I would like to run one like that too).
What are the existing tools that can help achieve this?
I don’t actually want them muted: a student will likely follow multiple courses at once, and the notifications from all are fine. It’s rather that I want to give a clearer impression of “now I am looking at course X”.
It seems that the intent of the plugin is so the primary group = the selected home, no? You need to enable user_selected_primary_groups so users can change their primary group on their account preferences page.
Optimally, I’d want something more ephemeral and less publicly visible. However, I imagine that if I don’t use the title and flair, then a UI component that switches the primary group would work as a team selector.
Something like the extra sidebar selector that was running here as an experiment a few days ago would be neat for that.
You could do that. You could also change the site logo depending on their primary group; I’ve done that for a site that has multiple universities sharing an instance. Maybe you’d have a theme component with a pull-down on the top bar that would let them select their primary group (and maybe have it say “class” instead of “group”).
@Anton_Akhmerov are you hoping to do this yourself or would you be up for paying someone to do it for you? Let me know!
If you want to do it yourself, I’d like to move this to Dev so you can work on it there and report back to the community and get input from fellow members. Ilet’s move this to Dev.
If you want to pay someone, I will move it to Marketplace.
I think it may be best to move this to Community and discuss more about your use case, how best to meet your needs today, and to make space for others who may have had similar needs have solved them.
Then, if there are specific product gaps identified that you feel are important enough to build yourself or advocate for, we can spin out separate topics in Feature and/or Dev for this ideas.
Does that sound aligned with your thinking here? Or are you already at the “I’m ready to build the missing pieces” phase?
Community also makes sense . The feature looks tricky and it seems to be somewhat aligned with the community needs, considering the popularity of requests like this
I do plan to work on this, but so far my plan is rather vague.
As a follow-up, here’s how I imagine best meeting your needs with out of the box features of Discourse. It may not be exactly what you have in mind, but I think it’s worth considering as a starting point for discussion.
First, I’m making some assumptions, which may or may not be valid. Please let me know where I’m getting it wrong:
There will be many courses (10s, possibly 100s)
Setting up courses will happen periodically, in sizable batches, at the beginning of each term (2-4 times a year)
Courses will have an end of life
People managing courses need to have some ability to set them up on their own
People managing courses will have limited or no experience with managing a Discourse site.
People managing courses only really need to see their own. They may want to see others occasionally as examples, but don’t need ongoing participation in them.
^ ditto for people taking courses
There is a very small team managing the system as a whole
Courses don’t really need subcategories; using tags to organize content within courses would be sufficient
Given those are close, here’s what I’d suggest, first at a high level:
Create a small number of top level categories: one for “Current Courses”, one for “Past Courses”, one for “Upcoming Courses” and one or more for more general things about the overall system itself (e.g. how to use the site)
Set the home page style to be “boxes with categories” so these are prominently displayed
Use subcategories for each course
Create them in “Upcoming Courses”
Move them to “Current Courses” when the term begins
When a course concludes, move it from “Current Courses” to “Past Courses”
Control access to Courses using Groups (more details below)
Access control:
For each course, create a set of following groups, for example: foo_interested, foo_enrolled, foo_admin
Create two additional groups: “browse_courses” and “browse_past_courses”
Set categories in “Upcoming Courses” and “Current Courses” to only be accessible to people in the groups for the specific course and people in the “browse_courses” group.
Set categories in “Past Courses” to only be accessible to people in the groups for the specific course and people in the “browse_past_courses” group.
User experience for groups and courses
Have a pinned topic in the top level category for “Upcoming Courses” that explains how to browse courses, with an easy affordance for people to join the “browse_courses” group.
^ ditto for “Current Courses”
^ ditto for “Past Courses”
For individual courses, have a pinned topic in the category explaining how to join the Course:
Join the “foo_interested” and/or “foo_enrolled” group
Add course to your sidebar
Administration will be a bit labor intensive at first, as for each new course someone will appropriate privileges will need to:
Create the category
Create the groups
Create the pinned topic
Add the people to the _admins group
Provide them the docs they need to manage their own course
Some of that could be automated with some lightweight tools. Depending on who the main admin team is, it may make sense to start with sometime out of band that just hits the API. Or maybe you need something more UI based that is built into Discourse as a theme component or plugin. But I’d suggest starting lean here, and focusing first on defining a process that works, then design the tools around that.
Category scaling is a possible concern here. Discourse does have some performance and UX rough edges when the category count gets too large (high hundreds or thousands). Users with access to more categories will feel the impact of this, while those with limited access will not. That is part of the motivation for limiting access to categories as I’ve outlined.
Very interested to hear any and all feedback or questions you have on the above.
. The feature looks tricky and it seems to be somewhat aligned with the community needs, considering the popularity of requests like this