Forum .LRN Q&A: interpretation of subject, the group hierarchy of dotLRN

1: interpretation of subject, the group hierarchy of dotLRN

Posted by Peter Marklund on 08/12/02 08:10 PM

At first the word subject seemed to mean for example Biotechnology,
but I have been told that the intended interpretation is really what
is commonly referred to as a class or a course. With this latter
interpretation what is called a class in dotLRN is simply a course
given in a certain semester. I think I would prefer the word course to
subject... Wow, I just changed the classes_pretty_name parameter and
the UI consistently changes from Subject to Course - lovely!

What were the use-cases that motivated the creation of sub-groups
(groups within classes)? Is there a special relationship between the
subgroup of a class and its parent class or are they independent (just
like any two classes are)?

2: Response to interpretation of subject, the group hierarchy of dotLRN (response to 1)

Posted by Deirdre Kane on 08/12/02 08:25 PM

Peter,

There are no written use cases for this, but the motivation for subgroups (sub-subgroups, believe it or not), was to provide space managed by group admins for team project groups (classes), student cohort teams (for the MBA Core courses) study teams (classes and program office communities), ad hoc committees (administrative communities), regional affiliation groups (for alumni communities), class years (for program offices such as our Career Development Office that needed to communicate with students by year), etc. Basically, SloanSpace needed to allow to gruop themselves in virtual space as they already were grouping themselves in realtime.

That said, subgroups are tied to the parent: one cannot be a member of a subgroup and not a member of the parent. However, subgroups can function independently and privately (by setting the enrollment policy to closed or needs approval) or as an open subset of the class.

Also, subgroups are useful to consider when you will need to move or remove groups of users at a later date. It is much easier to manage users at the site wide and group admin level if you think about that ahead of time. For example, if someone requests a new community and its target audience is the MBA Class of 2004, I can move all those users from their Program Office community, where they are already grouped in a subgroup, into this new community, saving that admin from a bunch of tedious work. Users can still opt out of any membership, so this action does not persecute them forever.

The ability to remove a defined group of users from a group, such as a graduated class, needs to be written. It was in SloanSpace V1 and we need to write it and expand it for SSV2.

3: Response to interpretation of subject, the group hierarchy of dotLRN (response to 1)

Posted by Carl Robert Blesius on 08/12/02 09:13 PM

Deirdre,

Thank you so much for your last couple of posts... they have been really very helpful.

The subgroups (and sub-subgroups) will be a killer function for the medical school here in Heidelberg (it was one of the things that made the decision to go with dotLRN easy). In the recently implemented reformed clinical curriculum, which focuses on problem based learning in small groups, teamwork becomes essential (just like in the hospital later). At the same time large 200 person lectures have been broken down into groups of 30-40 which cover the same material in blocks. The fact that a large amount of control and flexibility can be delegated to the group admins is excellent and makes such scenarios simple. Subgroups allows dotLRN to mirror reality more efficiently, which I am sure will be a factor in its success.

I find it so exiting to see the dotLRN born in a business school mapping so well to the structures found in a medical school! I really look forward to the implementation here in Heidelberg... this will be a process that I will try to document for the community as it takes place.