Enrolment

Now that I have had a chance to look over the Paypal plug-in, I have been able to assess how far this will suit my (and in the process, other potential users' needs). Personally, I could see myself using this out of the box in the future for certain kinds of courses I plan to offer. However, for the courses I want to start off with in the beginning on my Web site, it does not suit my needs.

There are three factors I have identified that limit the flexibility of the current enrollment/payment architecture.

1. There are only two variables taken into consideration when determining an enrollment in a paid course-price of course and length of course.
2. These two variables can only each contain one value.
3. These two variables are tied to a specific course.

Why is this a problem? I'll give the example of what I wish to do on my site, but there are also a lot of other situations that would also not work with the above structure.

On my site, I wish to have a sequence of three courses. Course 1 is prerequisite for enrollment in course 2, and course 2 is prerequisite for enrollment in course 3. Students may enroll in a single course and gain access to it for a period of 180 days for $250, or they can enroll at the beginning in all three courses for a period of 540 days for $600. Students who do not complete a course within the time period may extend their enrollment for another 180 days for a price of $50.

Obviously, the current design of the enrollment/payment plugin would not accomodate something like this. Therefore, I would like to propose an alternative that would, along with a lot of other scenarios. What is needed is the ability to create enrollment packages.

What is an enrollment package? An enrollment package is a course/set of courses and related variables that either are pre-chosen by the admin or can in some cases be customized by a student. The enrollment packages would be independent from the courses themselves, with the courses simply being one of a number of variables that make up an enrollment package.

Here are the variables I would propose and the types of values they might have:

1. Course(s): In addition to the current system of a single course, an admin could make a predefined package of courses that could be purchased, as I need on my site. Another option would be for students to be able to choose their own set of courses. For example, paying a certain fee would entitle students to enroll in 4 courses of their own choosing, or a certain number of units (courses would have to be able to have a unit value assigned to them). Students would be able to choose the courses that they wished to take that met these requirements.
   
2. Price: In addition to the example I gave above of a discount for enrollment in three courses, there are other examples where one might need to have variable prices for the same product. In the US at least, all public universities and colleges have different tuition fees depending on whether the student is an in-state resident or not. On a business site, one might want to offer a special promotional discount to certain users (this price could be activated through a special enrollment key).
   
3. Enrollment Period: In addition to my own example, one might also want to link enrollment periods in a single course to the price paid. Someone pays $50 and gets 1 month of access, or they pay $75 and get 2 months of access.
   
4. Prerequisites: This is extremely important. There are different kinds of prerequisites that might exist-a previous course might have to have been successfully completed, permission from the teacher might be required, or a specific course might have a limited number of "seats" that must not have been exceeded. A lot of this could be dealt with if the enrollment key system were to work with paid courses. Students who successfully completed a prerequisite would be given an enrollment key allowing them to enroll in the next course (or on a more sophisticated level the system could check to see if this had been met automatically), or for teacher permission required courses the teacher could give out the key. On a business site, it would be a huge hassle if the system did not check to make sure users had met prerequisites before they actually enrolled in courses because you might have people enrolling who are not eligible to take the course because they don't read the fine (or not so fine print) and then you have to refund their money to them.
   
5. Groups: By linking groups within courses to a specific enrollment package, you could automatically put students into the groups they belong in. The choice of groups might be something chosen by the students themselves, or there could be numerical limits to groups (e.g. once group 1 reaches 20 students, new enrollees are put in group 2), or if Moodle were adapted to accomodate "supergroups" (i.e. cohorts of students who are grouped together on a site level), the enrollment package system could automatically place them within the proper groups inside the individual courses they enroll in.
   

Students would be able to go to a page where they could choose/configure their particular enrollment package(s). Once this step was finished, in cases where a payment plug-in would be used, they would be sent to PayPal or wherever to make their payment. Finally, they would be given access to their package.

Now, I know what I am proposing is very sophisticated. It is actually beyond what my own personal needs are but I wanted to propose something that would accomodate the widest possible number of users. If we can come up with a conceptual design that would suit the needs of a large scale education provider, it might be possible to find one that would be willing to fund its development because of the potential benefit to them.

Or at least perhaps at least some of the ideas I have presented could be implemented in the interim.

What does everyone think?