For instance, ateacher might be teaching "special needs" math to high schoolstudents. She would have lessons in her course that range from7th grade-12th grade ability. She would group her students usingthe existing Moodle "groups" feature. Then, she would go throughher course and select which activities to show for each group, based onability. This would allow her to maintain one course/gradebookfor all the "special needs" math students.
In order to do this we will need to do three things.
First,we will have to add functionality to the course "view.php" page toallowonly selected groups to see assignments. This will require anadditional table in the db to keep track of which groups see whichactivities. This table will need to be checked each timethecourse is displayed.
Second, we will need to makesure that gradebook exclusions are created for students that are notresponsible for certain resources. We may also add some visualsto the gradebook to indicate who is responsible for what.
Third,we will need to modify each activity module to check to see what thestudent is truly responisble for. We don't want the student tohave to weed through things that have no bearing on theircoursework. These will also check the new db table every timethey are displayed. Actually, we can just changeget_all_instances_in_course() to check the group. This should becalled in all modules.
This sounds feasible in my head. Do you guys agree?
Would anyone else be interested in this?
See http://www.imsproject.org/accessbility. I'm attaching a diagram.
The main points are that: a) the content has metadata that notes what capabilities the learner needs (think visual, audio, text, or all), b) all users register their preferences in an ACCLIP "service" (think visual, audio, text, or any), c)
at content delivery time, the correct "view" is delivered to the learner based on their ACCLIP preference.
This is similar to the approach you are proposing, Bryce. More general and based on technology standards that the world "accessibility" community is behind.
Now, I could see where we might want to do a short term approach of the sort you are suggesting, that's certainly a faster way to get there. Long term, I am advocating for the IMS Accessibility approach.
Our friends from University of Toronto's Adaptive Technology Resource Centre
are some of the major proponents of this approach, with their ATutor
being a CMS and TILE being a Digital Repository which utilize it. ATutor being written in PHP, this is some prospect that features of it could come into Moodle.
The main difference is that our goal is to allow the teacher to select content based on the child's intellectual ability. IMS aims to alter the content based on the child's specific disability (or preferred method of learning). I think both could be implemented in Moodle without too much overlap.
It appears that you have had some interest in moving forward with this development. Have you begun work on this yet? Is it really in store for 1.6? We're going to need the functionality in the next few months. Maybe we can coordinate our efforts to make this happen.
Bryce
Hello
I approached Martin via www.moodle.com and he was interested in this functionality and we discussed a price for possible 1.6 inclusion. We also threw some ideas back and forth of how it would work (from a mainly cosmetic point of view). Our contribution would be financial rather than providing code.
Since then things have been on hold as Martin is obviously busy with 1.5. I was going to follow this up after a stable 1.5 was released to the public.
I am always interesting in coordination but don't want to take food away from Martin's mouth! Conversely if you do push ahead with this in the next few months then Martin would loose out anyway as there is no point re-inventing the wheel.
Perhaps Martin may want to jump in here? If not you/we could contact him to see what he thinks.
I am keen to get hold of this functionality cause without it i can't really use groups for classes because some teachers add their own content which they do not want to be shown to all the other classes.
Timothy
Thanks for your interest.
It's up to Martin D, really. Obviously he is busy with 1.5 so it will be after that when we get our heads together again and work out the feasibility. Personally we don't need it now until Sept when we start with our new classes.
One complication is since Martin and I looked at this is I think he indicated in these forums that multiple group membership is more complicated than he originally thought and this is really the foundation upon which we would want to build upon.
The way we would use it is students are members of a class (group) and also an ability stream (another group) and resources could be accessed by / limited to the class group or ability stream.
Thinking about it, having a more simplistic version where students are only a member of one group and resource rights based upon that group membership (as you have just described, Timothy) is still something which would interest us.
There are still some reservations about our proposed move to Moodle. This functionality is something that will make people feel much more comforable about our conversion. So, the sooner I can tell them it's done, the better. We could use/devlop a hack for this, but I would rather use an official version if at all possible. It would make maintaining our code much easier.
I'll contact Martin about this after 1.5 is unleashed.
Thanks for the input.
Bryce
I wanted to let you know that Janne has posted some code for hiding activities and resources per groups, in case it might be of some help:
http://moodle.org/mod/forum/discuss.php?d=25023
There is also a hack to achieve content switching on a per course basis provided by John Ryan on this thread.
http://moodle.org/mod/forum/discuss.php?d=15360
Timothy
about "abilities" than "disabilities".
Here's an except for the overview doc:
"... the term disability has been re-defined as a mismatch between the needs of the learner and the education offered. It is therefore not a personal trait but an artifact of the relationship between the learner and the learning environment or education delivery. Accessibility, given this re-definition, is the ability of the learning environment to adjust to the needs of all learners. Accessibility is determined by the flexibility of the education environment (with respect to presentation, control methods, access modality, and learner supports) and the availability of adequate alternative-but-equivalent content and activities."
It's a matter of
1) adding the ACCLIP to the user profile, which the user can select from
2) defining the "meta data" for the "abilities" in question
3) adding insertion and lookup of this metadata for resources (course, activity, resource)
4) adding logic to pick the appropriate theme at display time for the course, activity, resource
as I'm laying it out here, this would work at multiple levels within Moodle:
site
+ course
++ activity
++ resource
which I've laid out in a nested form to represent the levels. Would have to have enhanced mechanisms for:
* user profile
* metadata adding and query for course, activity, resource
* themes at course, activity, resource
You want this at the course level and for a well-defined group of learners with certain intellectual capabilities, as I read it. Make sense?
Going this route would allow for the user profile/ACCLIP to come from some other source. Say an enhanced LDAP.
Folks I work with in IT involved with Accessbility (I'm in IT) at UW-Madison are trying to get the folks from U of Toronto to our campus this fall for a workshop on this stuff with selected folks from Campus. It would be quite interesting to bring Moodle into our discussions as a possible player in this realm.