Hello, all,
I'm putting down some quick ideas here to start getting feedback --
A distribution for Education will mean different things to different people: a set of tools to support classroom blogging, a set of tools to support teacher professional development, a set of tools to allow a school to track student progress (aka a SIS), a public-facing school web site, an internal teacher professional development site, a personal learning space (the PLE), to say nothing of the library sites, the LMS's, etc, etc, etc.
Drupal can do all of these things well -- some with existing modules, where others will require development. The question is, where do we want to start?
I also think that it's pretty clear that, while it might be possible to put all this functionality into one site, the complexity of the site would be intimidating to novice users. At the outset, I want to throw out the idea of housing this functionality within different sites. This way, a teacher who wanted to use Drupal to run a course wouldn't need to deal with the added overhead of, for example, school management functionality. Another advantage of having smaller, more targeted install profiles is that it eliminates the need for a bloated distribution. We all love Drupal for it's leanness(or at least I do :) ), and this should not be sacrificed in a distribution.
Then, once we have the functionality clearly defined, how should we go about determining the "standard" configuration; ie, what the site should look like after it is installed?
Then -- and arguably, for the long term viability of the distribution, this is arguably the most important piece: what is our workflow to guarantee that security fixes get rolled into the distribution immediately, and how do we inform people using the distribution that an update is required?
These are some initial thoughts to get the ball rolling -- what did I miss?
As a final thought, what about shooting for a release of an initial distro accomplishing at least one of the above featuresets for shortly after the 5.0 release? As with most deadlines, I see this one as both arbitrary and flexible, but it seems like a nice line in the sand.
Cheers,
Bill
Comments
Moodle target
My university is actively developing extensions for Moodle, while we still have a large Blackboard user-base. The debate is on-going on-campus and across the CSU system. Moodle is seen as a flexible solution that can compete on features and price with systems like Blackboard. This is why I think that a Moodle-like feature set would be a good target. I mostly see other functionality (SIS, PLE, etc.) stemming from this base feature set.
Additionally, Drupal brings a lot to the table that systems like Moodle just can't provide using their current architecture. An good example is global content management. Moodle considers EVERYTHING as part of a course.
I agree that a 5.0-based distro makes the most sense.
Ideas...
I don't know very much about this specific field, but I've noticed tremendous interest in it that began building some time ago, making it interesting to me even though I have no contact with it's audience, otherwise (and I've taken it upon myself to try and be a point of contact for folks developing distribution profiles, so I definitely want to keep up with this group).
As such, though, I wanted to throw out a couple of ideas general to installers that address a couple of points raised by this post. Clearly, there are a few standards in place that involve TLA's and other things that go bump in the night that may tend to put folks off simplifying their lives by learning a new platform. As such, you may want to make a list of the bullet points involved and try to match them to the configuration portion of the installation. This would allow you to turn the install into a basic mini-tutorial, allowing you to describe the broad functionality of your distribution and how it applies to existing standards and requirements and point out how to make use of these within your distribution.
While keeping your distribution current with security fixes and so forth will still mean making sure the updated files are included with the distribution, you might also consider pointing out (towards the installation) that, beneath the elegant and intuitive exterior that is your distribution, it is still Drupal, and as such, can be updated and maintained like any other Drupal installation -- at which point you can alert the user to the availability of the various mailing lists, support forums and help options available (offering to subscribe them to the security updates mailing list, for example, using the email address they provided to install with, for example) and then reinforcing this information in the distribution itself, by preconfiguring the installation to provide links to these resources in the form of a menu entry or some such.
Moving away from Moodle
Thanks for the kickoff Bill!
For the past year and a half I've been running all School Engine installations off a customized version of Moodle. For the past 2+ years, I've been heavily developing in Drupal. We've come to the realization that we do not want to do any further development on Moodle. Our current goal is to move most of the LMS functionality from Moodle to Drupal, notably the ease of creating assignments and editing grades. Something I'd like to start doing for our clients is having a fully integrated Drupal site: a front-end School site built on on Drupal allowing students to log in and see their courses, post assignments, check grades, etc. Moodle handles the LMS part well enough, but you can't design a pretty high school website in Moodle. :)
For School Engine, I think we'd be looking towards one main DrupalEd distro for the high school level, and possibly a slightly modified one for the primary/middle school level as those are our target markets.
I'd like to start talking specifics regarding code. Here are some rough ideas, mostly in Moodle terminology, that I'm hoping Bill can help out on.
That's all I can stomach ATM, but may provide a decent base to get into specifics.
We're on the same page
It's good to hear that we are all on the same page.
I'm the developer of the Drupal Gradebook module and I am working to stabilize it for 4.7. Gradebook already supports making any node type an assignment. It also comes with a simple base assignment module to make setup easy.
As for courses, I am already working on an OG_Gradebook module. At present, a group admin is a teacher and a subscriber is a student. The OG module does not support fine-grained permissions out of the box, so allowing read-only subscribers (aka parents) could be difficult to implement in a flexible manner. OG_Gradebook should be in CVS soon.
Oops
Ok, that was me that just posted that. I didn't realize I wasn't logged in. I wish they didn't allow anonymous.
This technology stuff is
This technology stuff is hard :)
FunnyMonkey
rwohleb
Wow, that would be great! If I could put a bug in your ear - could it include a homework tracker and a way for parents to login to see what homework has been assigned and what homework has been done. That is, if you are doing a gradebook for k-12. Otherwise, ignore me ;)
The parent functionality is
The parent functionality is something that is a must have for School Engine, so we'll be brainstorming flexible solution to create relations between users. Maybe an extension of buddylist.module and ACL (I've not messed too much with the latter, but Bill seems to think good things).
Possible parent's access solution?
Just a thought: What about - in addition to the course groups - create a unique OG subgroups for each student and course, to which the course teacher, the student and the parents have access with appropriate roles, and where all student-specific assignments and answers can be posted?
If so, the students will subscribe both to course-groups and to their own course-specific subgroup for each course. Then you would merely need some functionality of automatically creating subgroups for each subscriber in the course-group (a proposal for a module?).
I'm not currently using Drupal for educational purposes (only preparing for it), so I might not know of all possible difficulties there might be with this solution, but to me it seems possible. Your comments are welcome.
Regards,
// Samuel
Samuel Lampa
RIL Partner AB
It would be hard to build
It would be hard to build this module and not get a hw tracker :) -- in the current setup, assignments are nodes, and we're looking at either the event module or views calendar as a method of tracking assigned and due dates in a calendar-style format.
RE the parent login: as Rob responds, this will requires a module that creates a relationship between users to create the parent/child relationship. Really, the parent account would need to be a sub-account of the student's account.
In brainstorming this out, it could work something like this -- a parent gets an account that is linked to their child's account. This account would only have access to a subset of areas where their child has access. In these areas, the parent would have limited rights -- really, read only access to information specific to their child's learning. So, the parent account would need to clone a child's OG memberships, but only with access rights as specified in a specific "parent access" role. The combination of the child's groups determining the areas a parent can access, and roles determining what the parent can do in these areas, would probably create sufficient flexibility. By implementing this via a module, it would leave this functionality as optional -- ie, i don't see much need for this in higher ed.
Cheers,
Bill
FunnyMonkey
Educational Instituions
Hi, I was thinking about starting a group discussing Drupal in the context of educational institutions, namely in the context of a University. But maybe it would be better to discuss this all in one place. I presented on this topic at Drupalcon06 - see http://www.dominiklukes.net/drupalcon06 and would like to pursue some of these ideas further. I'm not as interested in integrating Moodle as in developing some original modules for Drupal - see http://tuit.glottalstart.com. I also set up a group for discussing using Drupal for language learning communities on http://groups.drupal.org/language-learning-communities. I am very interested in the notion of motivating through social interaction and I think Drupal provides an ideal framework for this kind of approach.
Dominik Lukes
http://dominiklukes.net
@techczech
Based on the feedback in
Based on the feedback in this thread, I've started a thread that focuses on implementation over here.
FunnyMonkey
What about a PTO website?
I'm thinking about putting up a PTO website for my local elementary school, and wondering how different that would be from a DrupalEd site. Obviously, it would not expect to support teachers developing their class curriculum, but it could support class parents organizing events for each class, class-based parent networking, school-wide organizing, etc.
Has this already been discussed/considered in DrupalEd? If not, should it? Or should another group/distro be developed for PTO organizations?
Erik Britt-Webb
drupal@britt-webb.net
Erik Britt-Webb
drupal@ebrittwebb.com
RE: PTO website
I'm working on the same idea. I've downloaded DrupalEd installation profile. It seems like a reasonable starting point. I'm working on subtracting some of the DrupalEd features (at least initially) and renaming/reorienting some of the other features, . Being a Drupal beginner, it seems a better place to start than a vanilla Drupal install... A lot of thought and good work has obviously been put into DrupalEd (thanks!). I'd be happy to explore collaborating on this idea.
BTW: is there a place to report bugs that I've found in DrupalEd?
Questions and bugs
If you have questions about how to use the site/configure the site, the DrupalEd group is a good starting point --
If you are reporting a bug with a module, then it should be reported on the issue queue for that module -- the main issue queue is here: http://drupal.org/project/issues -- from there, you can search issues to see if anyone else has reported it, and submit issues yourself.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
That all depends. The first
That all depends. The first thing you ought to do is turn on the "update_status" module and get all of the updated versions of the modules (it only checks the ones you have turned on). Then run the database update script to make sure that's all where it needs to be.
If you're still finding bugs at that point, you'll probably want to report the bugs in the issue tracker for the module in question. All of that resides on the main drupal site. (http://drupal.org/project/issues)
RE: update_status
Thanks for the tip! I did this. The first module it identified to be updated was the Drupal 5.1 core itself. Following the upgrade.txt instructions, I attempted to disable all the non-core modules. The result was - not pretty (SQL errors, etc.). I'm glad I backed the DB up before doing this. Question: should I update the Drupal core, and if so should I follow the upgrade.txt instructions in the Drupal core distribution? Might there be schema changes in the latest Drupal core that are incompatible with oa_drupaled.sql? When I initially installed DrupalEd I followed the drupaled_INSTALL instructions and installed the Drupal core and then installed DrupalEd over that. Am I going in circles? Thanks!
The drupal version in the
The drupal version in the base install is a development snapshot from a few weeks after the 5.1 release, so it has some minor bugfixes/etc not present in the 5.1 release. I opted to use the snapshot because of some minor fixes present in the snapshot that were not in the point release.
There are no schema changes between the 5.1 release and the snapshot release, so if you wanted to roll back to the point (the 5.1) release there would be no issues.
The reason you see the sql errors when you disable the non-core modules is that many of the page views and nodes are generated by contrib modules, so without these modules enabled things will look pretty broken, because they, well, are pretty broken :)
FWIW, I'm preparing a maintenance release that should be out within the next few days. This release incorporates upgrades in several contrib modules. While it's not essential in any way, shape, or form for security, it does get the latest version of the code for these contrib modules. This update does not alter the core drupal codebase that shipped with the original installation.
RE your original question to paring down the functionality, I would recommend limiting access to views and content types by using roles first, before you disable modules. This way, you can learn the system by seeing what the different access features control. This will allow you to make more effective choices about what modules you will eventually want to disable, without affecting the navigational structure currently in the site. Eventually, of course, you will want to replace the stock nav structure with something more suited to your organization.
I hope this helps.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
Thank you!
Thank you!