dotLRN Course Catalog

Package Specification Summary for Package: dotlrn-catalog

Summary:
Description:
Maturity:	New Submission or Maturity Unknown
This package depends on:	acs-content-repository acs-subsite assessment categories dotlrn
Packages that depend on dotlrn-catalog:	dotlrn-ecommerce
Package parameters:	None

Bug Tracker Summary for Package: dotlrn-catalog

There is no package with the name "dotlrn-catalog" known to bug-tracker.

Code Metrics Summary for Package: dotlrn-catalog

# Tcl Procs	0
# Tcl Lines	0
# Tcl Blank Lines	1
# Tcl Comment Lines	0
# Automated Tests	0
# Stored Procedures	PG: 0 ORA: 0
# SQL Lines	PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0)
# ADP pages	0
# ADP lines	0
# Include pages (dotlrn-catalog/lib/)	0
# Documentation pages	0
# Documentation lines	0
Browse Source	Not installed
Github Repository:	https://github.com/openacs/dotlrn-catalog/tree/oacs-5-10

Proposal To Extend dotLRN Course Catalog

Author: Nima Mazloumi

After talking to Carl and Dave I would like to propose the following extensions to dotlrn-catalog: Please forgive my poor englisch and feel free to contact me for further questions.

Extension technique

In order to keep dotlrn-catalog simple all new extensions should be realized as sub types of the object type dotlrn_catalog. Thus we don't introduce new attributes to the dotlrn_catalog table. Instead the new sub type shall provide it's own table and attributes.

In order to support several sub types dotlrn-catalog has to be modularized in a way that those fragments specific to a type so-to-speak infused in the right way. For this two concepts shall serve as a solution:

• usage of inclulets for adp pages and
• usage of so called extension points for the tcl code.

Includelets

Includelets are the standard way to include adp files within others. The characteristic in this case is that the adp file included is determined by the given sub type used. For this purpose dotlrn_catalog will contain a supfolder lib with serveral subfolders named exactly by the sub type name. Depending on the given type right system will select the right includelet and render the view.

Extension Points

In this case the tcl files have to be extended transparently depending of the given sub type. For this purpose we would like to suggest the usage of callbacks. Depending of the extension form (exclusive or composition) either the callback directly or an implementation for a given type is called to extend the behaviour of the package.

Behaviour at runtime

The default behaviour of dotlrn-catalog will be how it is right now. Administrators are able to create new course items, associate assessments to them and link them to dotlrn communities. The only difference will be how the pages are composed. With the above propsed solution the default installation will only know the object type dotlrn_catalog and therefore only include includlets for this type and also only call callback implementations for this type. This solution will not require any changes to the datamodel.

To achieve this solution forms, lists and type-specific fragments need to ge generated dynamically depending of the object type. You can see it partially implemented in the course-add-edit file in the current dotlrn-catalog package.

To achieve this dotlrn-catalog uses already now the new CR TCL API.

Activation of new types

This is done via a new package parameter called SupportedTypes which will contain the list of available types to the system. The default version of dotlrn-catalog will only know the type dotlrn_catalog. In order to use the other types as well more types must be entered to the list.

Thus at runtime OpenACS will check for the available types and make them available to the installation.

Suggested Extension to dotlrn-catalog

The Unversity of Mannheim has implemented a package called groups which has be used productively in Mannheim for almost one year and which is used by professors to organize the registration process for their courses.

Next to standard attributes like group name, start date, end date, description and the like, which is also available in dotlrn-catalog for courses the packages provides attributes like

• maximal members - to limit the size of the group depending on ressource restrictions like seats ...
• minimal members - to decide whether the course will take place at all or not
• registration begin - when the registration process will begin
• registration end - when the registration will end
• approval required leaving the group
• approval required for entering the group
• allow waiting list for students rejected
• white list, black list  - number of choices the student has to make for courses interested to join or not (see below for explanation)
• can student change his choices during the registration period

Thus an administrator can create a new group type with the above characteristics and let the system take care of the registration process. For this purpose the administrator can select from different join policies. The default policy is the First-Come-First-Served which corresponds to the open policy. The second one is the requires approval which speaks for itself. The third and new policy is by preferences.

This policy allows students to choose from a list of 1 or more available parallel courses. The idea behind this is that often the same course is given during a semester on different days and hours during the week in order to keep the classes small. Since some of them are more appealing than others - maybe one is on monday morning or the other on friday evening - the preffered ones the to explode while other courses are visited sporadically. To solve this problem we don't let the students join direclty a course. Rather we allow the student to indicate which courses he can imagine to join and which not. This we call white and black list. Once the registration process is over. We let the system automatically distribute the students to the courses taking in mind the size restrictions of the course as well as the choices of the students.

In order to integrate this in dotlrn-catalog we propose the creation of a new sub type of dotrn_catalog called dotlrn_registration which contains the above parameters.

Thus the administrator will have the choice to create a new course based on dotlrn_catalog or dotlrn_registration. Depending of the type further actions or informations will be available to students. Students interested in a course of the type dotlrn_registration need to register during a given period. Depending of the join policy they can either join a course or request membership or have to make a choice.

Installations interested in using the new type have to add the type to the package parameter SupportedTypes.

Other features

The type dotlrn-registration will provide other features like:

• Activation of Notification for the various stages during the registration process.
• Support for waiting lists
• Automatic creation of subgroups once the students where distributed to their groups
• Possibility to choose from a list of applets that should be made available to the groups instead of simply installing the default applets defined for classes, communities and subgroups

Example

We have a course called "Introduction to Accounting". This course is offered every semester for undergraduate students. Usually around 800 students attend this lecture. Due to the number of students the lecture is accompanied by up to 8 seminars - all with the same content but usually on different times in order to allow students to be more flexible. Still some seminars are more apealing than others. This could be because of the time, the location, the tutor...Since the sizes of the seminars are rstricted by teh number of seats available students have indicate which seminar the prefer compared to the others. Depending on the configuration set by the course administrator the students have submit a ranking or simply tell which seminar they prefer most and which less. Any number in between is configurable. Once the registration process is over the system recommends a distribution which can be double checked by the course administrator. Finally the distribution is confirmed and 8 subgroups in dotlrn are created and the memberships assigned. If the course administrator wishes all accepted students are notified. He can also notifcy the rejected students or add them to a waiting list.

In order to allow the above scenario it takes the professor 2-3 minutes to define it and further 5  minutes to trigger the distribution. The algorithm to optimize the above problem is takes for a situation of 1000 students and 1000 seats (1 mio elements matrix) around 4 min on a 1-CPU 3.1 Ghz Intel Box.

We have also implemented the distribtion types first-come-first-served as well as random.

Current Packages and Possible Steps 

after taking a close look at dotlrn-ecommerce (DE) and dotlrn-catalog (DC) I would like to suggest some changes since there are a lot of catalog specific stuff hidden in DE. This is especially:
 

• DC should be extended with sections but make sections optional.

dotlrn_ecommerce_section table:

section_id,course_id,community_id,section_name,date_time_start,date_time_end,daily_p,
  weekly_p,max_participants,waiting_list_p,notify_waiting_number,show_participants_p,
  show_sessions_p,description  (a)

product_id,account_code_revenue,account_code_expense,member_price_number,non_member_price,show_price_p (b)

age,qualified_age_low,qualified_age_high  (c)

  As you can see (a) apply to courses as well. We in Mannheim for instance have several courses
  that are split into sections. Thus why not remove those from dotlrn_ecommerce_section to a new
dotlrn_course_section table that should be moved to DC.

dotlrn_ecommerce_section would inherit from dotlrn_course_section and only add attributes under (b) and would stay in DE.

  Regarding the attributes (c) I believe that they should be handled in a third table part of DE since in future
  there might be many more parameters like age, that could play a role. After talking with Carl I think we can
  solve this through the new admin defined filters that are associated to a course/section and an applicant. Thus if
  the parameter age matters, the admin defines that filter and the associated rule. Anyway. I just think there is
  room for improvement here.

max_participants is used twice once here and once in ecommerce. Why is that?

dotlrn_ecommerce_section is not a acs object at all. Why is that? It could also be a CR item, no?

• As I proposed in the wiki I would suggest the definition of several course types an admin can choose from, if

   those types are available. Why should the UI offer ecommerce specific stuff, or assessment specific code or sections
   if a course admin only wants to have his course listed in the catalog where a second course admin in the same institution
   wants to offer a commercial course and a third a course with several sections and registration process.
   Right now we have the policy "eat or die" either use DC or DE. But what we really need is an adjusting UI depending
   on the course type. Looking at DE the UI is too overwhelming to a course admin who only wants to use the sections part
   or in future the filters.

• There are new status types in DE which better should go into a third package I would like to call dotlrn-registration.

   This package could deal with the whole registration process like type of join policies available, type of status possible,
   filters, assessment, registration_start_date, registration_end_date, automated registration depending on student choices...

• The current categories filters in the course catalog overview is not very usable. We would like to offer a second include that generates a tree that can be expanded.

 

• Also after installing DE for some reason there where dependencies to wp-slim and evaluation which should be.

Conclusion

<<>>As a conclusion. I would like to recommend several packages that focus on a specific type:

• dotlrn-catalog --> courses and optionally sections
• dotlrn-registration --> adding registration process, communities (optional), membership status, filters, assessment (optional)
• dotlrn-ecommerce

Several wizards shall be offered to the admin to go through the whole course administration process.

The site admin should have the choice to activate permitted features. The course admin should have the choice to choose from them.
The UI should adapt to the given type.

Open Questions

One question I have is: seperation into several packages is better but we need one package that plays the role of facade. One that knows the extensions and that includes the bits and pieces depending to the selected course type. Any idea how we could solve this?