courses app
Ozan Onay
private project is now available at http://code.google.com/p/django-courses/
If you would like to work on it, please let me know so that I can add
you as a member.
It's mostly functional, BUT it hasn't been tested thoroughly, it's
inelegant and not 100% secure in parts, and as I mentioned previously,
I have made some design decisions that will not be appropriate for
many (and so might need to be reverted).
The only reason I have released it so prematurely is so that those who
are interested in building a courses app for pinax-lms can decide
between using this as a starting point and working from scratch.
Some things to watch out for:
* "student" and "teacher" are not user attributes, they are
relationships between User and Course. For instance, I can have a
student relationship with the course "Advanced Group Representation
Theory" as well as teacher relationships with the courses
"Introduction to Group Theory" and "Basic Complex Analysis". This is
required for my project, but in others it may be possible to strictly
specify user roles in which case it would probably be more performant
to do so.
* There is no concept of a course administrator - administration
permissions lie with course teachers. Through configuration,
permissions can be removed from course teachers and left only with
superusers, but this will not be appropriate if the project requires
course administrators to have permissions relating to only a subset of
courses.
* By default, any authenticated user can start a course. Again this is
appropriate for my project but not for most LMSs. This can be
configured using the setting ALLOW_USER_COURSE_CREATION, which if set
to False will only allow course creation through the admin.
* By default, teacher permissions are cascading, so if I become a
teacher of a course, I have the same permissions as any other teacher,
such as inviting new teachers. This can be switched off by setting
ALLOW_TEACHER_PERMISSION_CASCADE to False, at which point course
creators do not pass their permissions to subsequent course teachers.
This means that for many LMS applications, both of the above settings
would be set to False, and no teachers would be set as course
creators.
* Permissions are not sophisticated enough at this stage, even for my
own project. This part of the code should be thought about and
possibly refactored.
* There is a Lesson model when there's no need for it to really be
part of the courses app. It should be decoupled at some stage
* I have really dorky url patterns set up that again suit my project,
but may not be appropriate more broadly. For instance viewing a lesson
involves looking up a pair of slugs rather than a single id, which
allows me to have slugs in the url and non-unique lesson slugs over
different courses, but would be significantly less performant than a
single pk lookup.
* There are no tests. There is very little documentation. i18n support
is sketchy. ajax support is sketchy.
* This is the first piece of django code I've released, so I may not
have followed all appropriate conventions, patterns etc. Please feel
free to correct style as well as substance.
Anyway, hope it is of some help.
Bruce D’Arcus
On Mar 21, 4:54 am, Ozan Onay <ozan.o...@gmail.com> wrote:
...
> * "student" and "teacher" are not user attributes, they are
> relationships between User and Course. For instance, I can have a
> student relationship with the course "Advanced Group Representation
> Theory" as well as teacher relationships with the courses
> "Introduction to Group Theory" and "Basic Complex Analysis". This is
> required for my project, but in others it may be possible to strictly
> specify user roles in which case it would probably be more performant
> to do so.
assistants" and "students" as primary roles. There are probably
others.
A user can have one role in one course, and another role in other
courses. For example, I am the instructor for the course I teach, I
have a graduate student who is the teaching assistant (and therefore
who does a lot of administrative and grading work, though does not
have all the same permissions as I do), but who in other contexts may
be a student in my (other) class.
> * There is no concept of a course administrator - administration
> permissions lie with course teachers. Through configuration,
> permissions can be removed from course teachers and left only with
> superusers, but this will not be appropriate if the project requires
> course administrators to have permissions relating to only a subset of
> courses.
Bruce
Bruce D’Arcus
> part of the courses app. It should be decoupled at some stage
and I presume courses without lessons.
Also, it might be too early to talk about details, but going back to
previous reply, this will need to be more flexible to account for
teaching and lab assistants ..
teachers = models.ManyToManyField(User,
related_name='teachers',
through='Teachership')
students = models.ManyToManyField(User,
related_name='students',
through='Enrollment')
One obvious way to do that is to attach a role property to the
Teachership model (which then maybe should be called something more
generic).
Bruce
Bruce D’Arcus
issues over on the course project?):
One problem with the LMS I currently use, and what I imagine is a
general problem, is there's no distinction between a course and any
particular course instance.
So I teach a course every semester; the course content (lecture
slides, assignments, syllabus, gradebook structure, quizzes) does
change over time, but not that much. It's the same course, with the
same administrative number, etc., etc.
But the LMS has no way to represent that; one must do really awkward
things like "copy" a course, which simply copies over all a course's
content to the "new" course. This results in a lot of UI and
reliability problems.
So I wonder if it makes sense to formally model this distinction in a
course app?
Bruce
Ozan Onay
> Teachership model (which then maybe should be called something more
> generic).
between instructors and assistants overlap. If the two are quite
distinct it might be easier to set up another m2m relationship for
assistants. On the other hand, perhaps all roles (student/instructor/
assistant) should be generalised to a single 'permission' relationship
(again m2m between Course and User). I'm not sure which is ideal.
> One problem with the LMS I currently use, and what I imagine is a
> general problem, is there's no distinction between a course and any
> particular course instance.
courses and their related content, and have been thinking about the
best way to approach it. If anyone can think of an obvious way to do
this, please let me know.
Cheers,
Ozan
Bruce D'Arcus
....
>> One problem with the LMS I currently use, and what I imagine is a
>> general problem, is there's no distinction between a course and any
>> particular course instance.
>
> Yes I would like to come up with a sort of versioning system for
> courses and their related content, and have been thinking about the
> best way to approach it. If anyone can think of an obvious way to do
> this, please let me know.
One way to approach this to say you have Course, CourseVersion and
CourseInstance, and I guess that the latter two can each have
children?
In my university context, I teach a "course." Let's take this one:
<http://www.users.muohio.edu/darcusb/courses/101/spring/>
Aside: I hate my LMS, so most of this content is hosted outside of it ;-)
The course has a name ("Global Forces/Local Diversity"), a department
("geography"), a number ("101"), and a description, and perhaps some
requirements. That abstract course has no instructors or students.
There is, then, my particular version of that course, which has a
syllabus, and a schedule, which at a generic level is a sequence of
topics, which in turn may have associated readings, notes, lecture
slides, assignments, etc. At this level, I am certainly the author of
at least much of that content, but there are still no students.
There is then the particular course instance. This brings in the
student and instructor roles, it is taught in a particular time period
(semester, year), at a particular time and place.
It also has three associated discussion sections, which are part of
the course instance, but are also distinct, with their own times and
places and students (and administratively are treated as distinct
courses). The TA is primarily responsible for these.
In our current LMS, the separate discussion sections can be optionally
merged into the main course site. I'm not certain how this works
behind-the-scenes, but what I see as an administrator is separate
course links for each discussion section But what I see at the end of
those links looks and behaves as if it were part of the same
consolidated course..
Ugh; complicated.
I'll add here versioning per se isn't that important to me as an
instructor. However, it very important that I can as easily as
possible be able to reuse content across terms.
I would also lie to more easily be able to share content with other
instructors teaching the same "course."
Bruce
Bruce D'Arcus
through what they call a major rewrite to clean up the foundations.
The course management API code is here:
So it appears the key classes are:
AcademicSession.java
CanonicalCourse.java (what I called just "Course")
CourseManagementAdministration.java
CourseManagementService.java
CourseOffering.java (what I called "CourseInstance")
CourseSet.java
Enrollment.java
EnrollmentSet.java
Meeting.java
Membership.java
Section.java
SectionCategory.java
Bruce
Skylar Saveland
> slides, assignments, syllabus, gradebook structure, quizzes) does
> change over time, but not that much. It's the same course, with the
> same administrative number, etc., etc.
I visualize MATH2010 being a place where you can see all of the
lessons in the database and sort and search them (this is the
student's perspective). So, even videos from teachers that no longer
teach the course or aren't teaching it _this semester can be pulled
up. Of course, the most obvious first/default sorting would be
choosing your specific teacher and having everything that is most
recent be at the top lessons/announcements/quizzes. This is totally
un-SCORM (I think) but it was what I was thinking of as I am starting
to plan a student interface to a course. I am going to try to digest
this whole mailing list so I might change my mind as I go but I like
the idea of it being a real value-added to the student's experience so
that they can see writings and videos and links and whatnot from past
versions of the course.