Caucus "Course" Conferences

(Last revised 10 May 2004.)

Note:  this document is still undergoing revision, and may be updated frequently.  It is provided here in this state as information about features coming in Caucus version 4.6.

I. Introduction
Caucus 4.6 introduces many new features in support of teaching and education.  In particular it adds the idea of a new type of conference, called a "Course" conference. 

A course conference is like a regular conference, but it has additional features, and behaves slightly differently than a regular conference.  The type of a conference ("course" or "regular") is determined when a conference is created.  Once a conference is created it cannot (currently) be changed to the other type.  (Although an existing conference could be archived, and then "restored" during the creation of a new conference with any type.)

The rest of this document describes the features of course conferences.

II. Course Permissions
A course conference (or just "course") has five levels of permission, shown in decreasing order of privilege:

  1. organizer
  2. instructor
  3. include
  4. readonly
  5. exclude

The "instructor" role is new.  An instructor has many, but not all, of the powers of an organizer.  Typically an instructor can manage the day-to-day running of a course, but the powers required for more unusual events (give examples) are reserved for the organizer(s).

The levels of permission are managed through a set of "groups", rather than explicitly editing the conference userlist.  For example, a conference "alpha" will have five groups, as shown below.  The groups are evaluated in the order shown below, from most general to most specific.

The order is important: for example, if a user is listed in both "members" and "organizers", that user will have organizer privilege.  This particular order should work well with the typical application of most course conferences.

An organizer will be able to edit these groups directly (without requiring manager privileges).  An instructor can edit some (but not all) of these groups.  This provides a much easier, if somewhat more restrictive, capability for managing conference membership.

(In fact, the organizer or instructor does not even need to know that they are editing these groups, unless they use the older, more powerful, "userlist" capability.)

When a course is deleted, these special groups are also automatically deleted.

III. Course Status
Each Course has a "course status" page (a sort of gradebook, if you will), that displays a grid of conference members vs. assigned tasks, and the members' scores on each task.  Organizers and instructors can add to and edit the course status, with entries for each member of the conference.  Ordinary members can only view their own status.

Each task in the course status has a maximum score ("points") and an optional weighting factor; the grid automatically displays statistics for running and total averages, course minimums and maximums, and so forth.  Course status grids may be directly exported to Excel, OpenOffice, or other spreadsheet tools.

The Course Status page is accessible from a new "Status" button that appears in the Caucus toolbar, when a user is in a course conference.

IV. Course Assignments
Each Course also has a list of "assignments" that is created and maintained by the organier(s) or instructor(s).  Each assignment has a title, a designated instructor, a due date, a "viewable" window (start date and stop date), and a full description.  The description supports all of the text, HTML, image, and attached document capabilities of a regular Caucus item or response, and has a very similar interface. 

To facilitate discussion of assignments, an assignment may link to an item via the usual %item(n) macro.  Or an item may link to an assignment via the new %assign(key linktext) macro, where key is a unique assignment identifier provided on the instructors' view of the assignment page, and linktext is the text of the link. The Assignments page is accessible from a new "Assign" button that appears in the Caucus toolbar, when a user is in a course conference.

V. Course Filesafe
When a course "alpha" is created, a matching filesafe "filesafe_alpha" is also created.  This special filesafe follows the same permissions as the conference, i.e. organizers and instructors can manage the filesafe, members can add files to the filesafe, and readonly members can only see or download files in the filesafe.

The filesafe is controlled by the special group "filesafe_alpha", which in turn includes the special groups "conf_org_alpha", "conf_ins_alpha", etc. as described in section II.

Clicking on the filesafe button inside a course automatically takes the user directly to the filesafe page for that course.  (The user will also see a separate link to "view other filesafes".)

VI. Implementation & MySQL
Many of these new features, notably Course Status and Assignments, are implemented through the integration of Caucus and a relational database (RDBMS) via what is called "ODBC", the open database connector".  Currently, the only RDBMS that has been tested with Caucus is MySQL.  Thus in order to use these features, you must have MySQL installed on your Caucus host. 

Since MySQL is free, robust, and available for all flavors of Unix, this is rarely a problem.

VII. Access Restrictions, by Interface
Caucus 4.6 also expands the ability to restrict certain kinds of access, by interface.  In particular, a Caucus administrator can "force" the use of particular interfaces in particular conditions, via a new include file called local_iface.i.

They can also restrict which settings can be changed in section III of the "personal information page" (where you go when you click on your own name), via a new include file localswitch.i.

See the comments in those files for more details, or the NYIT Student interface description for a real-world example of how these features can be used.