Course Management Scenarios

Ray Davis - 2005-08-23

We seem to be running into some conflicting assumptions between members of the different 2.1 teams. After some intense (to say the least) discussion with Mark Norton, with Craig Counterman, with Josh Holtzman, and with Oliver Heyer, Oliver asked me to put up some diagrams to help elucidate the possible issues.

Non-goals for Sakai 2.1

Taking the usual "walk before you can run" approach, Oliver says his understanding is that in Sakai 2.1, no application on a site should have to deal with more than one level of groups at a time, and that we shouldn't expect to have to deal with unpleasantly unexpected authorization conflicts.

Example of an unpleasant authorization conflict: Instructor Jane is responsible only for Lecture Section A. Instructor Jim is reponsible only for Lecture Section B. The 20 "Lab" sections can contain students from both Lecture Section A and Lecture Section B. Instructor Jane has the right (and duty!) to track "Lab 20"'s progress, but does not have permission to view all the students who are members in "Lab 20". This case is declared out of scope.

Unfortunately, that still leaves us with plenty of ambiguity.

Modelling a big course

This diagram is based on UC Berkeley's current course catalog, but is apparently not uncommon. I think this is the case that Mark generally has in mind, but might not be the case that Craig generally has in mind.

There are three big "primary" sections of "Lecture" type which are tightly controlled by the registrar and which form the official basis of enrollments, instructors-of-record, and final grade posting. The "secondary" sections tend to be much more laissez-faire. Importantly, though, membership in a "secondary" section is dependent on membership in a larger group. For now, we'll say that you can't be a student in a "secondary" section unless you're already enrolled in one of the "primary" sections.

As you can see, our out-of-scope case is a possibility here. How do we eliminate it?

We might try breaking this apart into three different sites, one per "primary" section. But then we lose the ability for the "secondary" sections to draw their memberships from all three lectures, and we complicate content management, section management, grading, and so on.

More likely, the institution would be willing to just say, "OK, Instructor Jane and Instructor Jim are both able to deal with all the sections in the site."

I believe a major source of confusion has been which CMAPI object would model which piece of this diagram. There are at a minimum three different abstract groupings here:

1. Primary sections, which supply official enrollment groups (this is probably what most non-Java-programmers think of as a "class")
2. Course, which says "conglomerate these primary sections together"
3. Secondary sections, which are dependent on the conglomerated enrollments, more volatile, and less closely monitored than primary sections

But CMAPI currently only provides two pieces to work with: CourseOffering and CourseSection. It's pretty obvious that "secondary sections" have to be handled by CourseSection, but what about the other two abstractions?

UI consequences

In this scenario, what would the Section Aware tools show (say) an instructor in their section filtering menu? Probably something like this:

Modelling a smaller course

In a university big enough to support this "primary section" business, they're likely to keep the same approach even where it's theoretically not needed, where a "course" is one-to-one with a "primary section":

When we discuss this case with users or user representatives, we're likely to speak as if there's just one abstract grouping, using the singular "primary section" and the singular "course" interchangeably. This has been another source of confusion.

UI consequences

From a programmer's or an SIS admin's point of view, the user is confused about the course and the primary section being the same thing. But from the user's point of view, insisting that the two be distinguished is a noisy distraction:

"Why are you showing me 'All' and 'Lecture 1' both? They're the same thing!"

For the nicest UI, we'd want to be able to realize that and avoid annoying the user – which is yet another reason for being able to distinguish "primary sections" from "secondary sections".

Bringing in site management

So far we've stayed pretty close to the world of enterprise integration. But this is an online collaborative environment, not just a snapshot of the SIS DB. Once an LMS is integrated with enterprise data, we've found that the instructor's most urgent need is to have some way to override (or at least add to) that enterprise data. The instructors' responsibilities tend to run on a different schedule and with slightly different datasets than the registrar's responsibilities. Notably, students very frequently have to be added manually, and guests and TAs almost always have to be added manually.

So in which abstract grouping do the new students go? Do they get stored in the "course conglomeration" object, thus becoming enrollments that are independent of any primary section? (I and Josh have assumed that to be the case, which is why we've been working on the assumption that a CourseOffering could contain students that weren't in any CourseSection.)

Or do we ask the instructor to assign them to some primary section, thus becoming primary section enrollments that have no connection to enterprise integration?

A different type of course hierarchy

For dessert, here's another enterprise scenario we've heard described. My guess is that this one is out of scope for Sakai 2.1, but I wanted to mention it because I think Craig might have been picturing something like it:

In this case, secondary sections are strict subsets of one and only one parent primary section.

It's hard to see how manually added students can reasonably be taken care of here except by adding them to a particular primary section.

APPENDIX 1. Multi-course site

Instructors sometimes want to create a site shared by more than one course, even aside from cross-listings.

In this example, PSYC 212 and PHIL 204 are not cross-listed. Nevertheless, the courses' instructors wish to share a collaborative site.

The limited UC Berkeley pilot includes two such cases, and John Leasia confirms that it's not unknown at U. Michigan. Sometimes an instructor will want to have a shared site for undergraduate and graduate courses that are dealing with similar topics. Other examples approach "informal" cross-listing, like the one pictured below, in which a Psychology class and a Philosophy class approach an overlapping subject.

APPENDIX 2. Single section site

Again, even in the limited Berkeley pilot, we have a case of a site devoted to a single "secondary" section.

As far as most LMS applications are concerned, this is not really different from the "smaller course" use case. I mention it separately because it is different from the point of view of Enterprise Integration and Course Management data.