Improve classes UI

Classroom for [course_name]

I think I would stick with 'class' rather than classroom. At British primary schools the class and classroom are 1-1, but once you reach secondary school, you join multiple classes that move around different classrooms in the school, so 'class' is the closer analogy to the LMS concept for me.

However I think it would be a quick win to call the classes 'Class for [course_name]' - we initially avoided that in case people start assigning those classes to multiple groups, but that's an edge case and classes can be renamed anyway, so we should make the default behaviour more obvious - could use its own issue?

I think the word "class" should be configurable to cover more LMS application scenarios. Class really sounds like school something few adults are keen on. Udemy nor Coursera reference class, teachers, learners, etc. hey are simply courses with presenters and subscribers/ participants. Many companies use LMS for onboarding new employees. So, imagine a new senior manager welcomed as "learner" to a "class". However, the "class" on the admin-backend should have a name that is linked to the course so that it can be quickly identified. I only have 3 test-courses and get confused!

Any terminology is configurable using translation. But I also think there must be a better name that we can use by default.

What "class" refers to here is the group of people who are signed up to receive the content of a course. There are different ways to express that, but how about "audience"?

So instead of "You have been added to the "Class 2X" class." we would have:

"You have been added to the [course_name] course audience."

When students are added to classes, the notifications should tell them they were added to the course, not the class. An instance of this was fixed in 🐛 Membership request accepted notification - class as a placeholder Active , if there are other cases, please open bug reports.

The default behaviour of classes is that they should be transparent to students - e.g. students have no idea they're in a class and just interact with courses.

Eventually we may want to add the option to expose classes to students - e.g. to allow class sign-ups or similar things, but that would always be optional.

I personally think 'class' as a mostly admin-facing term is appropriate here, it's very easy to map it to the education system where the same class might take multiple different courses/subjects together.

I am really not sure why we need classes. In Opigno, classes are for live-training. The users allowed to do a "training" (Opigno) = "course"(LMS) just become members of the training. I don't really understand why we need a separate group as class to attend a course. Could we not just make the participants members of the course? If we need to split learners into groups, we could do this in the groups-module?

BTW, I think the concept of having a training programme consisting in either/ or courses and modules, does actually work quite well. Once subscribed to a training programme, that can consist in a whole set of courses, each with a set of modules, has worked well for the online training I designed.

The users allowed to do a "training" (Opigno) = "course"(LMS) just become members of the training

Opigno does (or at least did when we were using the stock modules) support classes for regular trainings - you could add a class to a training, and then Opigno would add all of the individual members to the training too from that class, which led to data-integrity and performance issues due to the duplicate memberships.

I think classes could be made optional though, so I've opened 📌 Considering factoring out classes to an optional module Active . The main reason for it is so that you can add the same group of students to multiple courses quickly.

From my knowing so far no one from the corporate world with "senior managers" on board reached out to the project maintainers or developers involved to help with their e-learning projects based on Drupal LMS. If they do, I'm sure we can work more on the project and accommodate everyone's needs.

Classes (whatever they are called) serve the purpose of separating students (whatever called) from teachers (whatever called) as it takes place in the real world education. The more a model differs from the real world, the less flexible it is and the more limitations it creates.

If needed, the classes UI can be hidden completely on a specific project and changing some translatable labels was never a big problem.

Ahh and class names can be 100% configurable as patterns with placeholder replacement (predefined or using tokens). Not a big task really.

On the other hand.. Students don't have to be members of a course really to be able to take it with group permissions. I'll add some implementation thoughts to 📌 Considering factoring out classes to an optional module Active .