How would you design this?

Is there any LMS/SCORM solution that does this? (there are some open-source GPL ones)

I imagine your db could have a table for each course with a row for each user that has activity for that course, when a user has activity for that course the appropriate data would be entered in the column (test results, cumulative hours, # of lessons completed)

when user completes a task, scan the corresponding table for "completeness"

I could also imagine building this with Drupal Rules (Workflow-ng in D5)

So is that an offline app (for windows) that accesses online data? As I'm sure you don't need advice on how to go about building a website for this...?

I'm talking about the more abstract program design, not really specifics.

I asked this question on another forum, and someone suggested creating a course object, that accepts two other objects, a requirements object, and a completed actions object.

The requirements class is simply a list of objects that implement an interface that has one method, isMetBy(), which determines if that course has met that specific requirement. -- That's the kind of advice I'm after.

This application is already running, and has been for two years, but it's a nightmare for me to maintain, so I would like to rebuild it using a more intelligent technique.

We don't talk much about program design on the forum, but I still wanted to ask here.

Interesting...

Maintaining, and then executing a list of child objects that implement a 'pre-requisite' interface sounds like a logical approach.

My brain is mush at the moment... let me think about it, would love to chat this through.

Cheers,
Shaggy.

Good Morning!

The first issue was surrounding course pre-requisites.
I don't have any experience building online courses, but I think I can see that a course can be separated into many 'Tasks'.

In a course, 'Tasks' might be completed by a user either seqentially, or they may bounce around a little bit picking and choosing which they want to do first, second, etc.

So, I can see an 'Course' object being the traffic cop, per-se, of delivering 'Tasks'. Tasks would implement a standard interface so the 'Course' object can always determine
1) If a task is complete or in-complete
2) Is user input required: Is this going to be a machine run task, or something that requires input from the user?
2) What stage in a course the task should be completed
- prolog - before the user is able to do anything - setup
- body - The user's 'Course work'
- epilog The end, after the user has supplied everything
- result - The results, after all requirements and 'prolog' have been met
3) other things I haven't thought of that are 'tasky'

Imagine now that your setup tasks, pre-requisite tasks, and results tasks are just 'Tasks', no different than a user driven question or activity in the course.

You can slide in setup tasks in the prolog if you require it before the user needs to lift a finger. You can check requirements in the epilog and instruct the 'Course' object to have the user move back into the 'body' of the course, and you can generate results after the course requirements are complete at the result stage.

A course is never really 'complete' until the result tasks have been delivered to the user.

The administrator would build 'Tasks', and then glue them together inside a 'Course' As your 'Task' library builds including post-course checks and results, building a course becomes little more than gluing the re-usable pieces together into a new 'Course'.

Pick it apart! Offspring is tugging on arm to go play...

Cheers,
Shaggy.

Interesting ideas Shaggy. I've thought about it a little more, and I'm thinking, since I am a much better at designing databases than code, maybe I should create a database that stores the requirements for each course. Then my application code could just run a simple query and check if all the requirements were met. It seems easy, perhaps too easy...

The database is typically where I start out as well. 'Object Relational Modeling' (ORM) is a good way to implement a system from the database up in an object oriented environment. ORM is a system that allows you to refer to your tables, relationships, and rows in objects.

Often (though depending on the implementation) you may 'describe' the tables and their relationships by setting up new classes within your chosen ORM framework. The framework will then create new tables from new objects, and alter tables from existing objects as you build/change. It is a bit of work up front, but often pays huge dividends when changes come down the road.

I believe PHP has several good implementations, I've used 'PHP Doctrine' with success: http://www.doctrine-project.org/

Cheers,
Shaggy