http://www.funnymonkey.com/together-at-last
Elgg, Drupal, and Moodle all have a role to play in providing tools for learning communities. The example outlined in this post illustrates one way these three applications can work together in an academic setting. At the outset, however, it needs to be stressed that this is one solution chosen from among many. These three applications can be used by different institutions in different ways in response to specific institutional needs.
In this post, I am assuming some familiarity with Elgg, Moodle, and Drupal. For a quick overview, go here for Elgg, here for Moodle, and here for Drupal.
This chart provides a visual representation of the functionality described in the post.
Background
For the purposes of this post, I will talk about three discrete sections: class sites, the common area, and the school site. While these boundaries are constructs, they are useful in understanding both functional differences and practical security built into this setup.
Class sites refer to areas of the site devoted to supporting the classroom work. The main users of the class sites will be students and teachers, and content in this area will be largely private. Moodle and Drupal are used to run the class sites.
The common area is most closely analogous to a school intranet for one reason: every member of the school will have an account on it. However, as the core of the common area will run in Elgg, the similarities end there. Using Elgg, students will be able to create and maintain learning portfolios, maintain feedbooks, store files, and get updates on schoolwide and course-specific events. Additionally, all clubs, administrative divisions, academic departments, and athletic teams have an initial presence here as Elgg communities. Any groups within the institution that need more functionality and more security than offered within Elgg can extend their work into a Drupal site.
The school site refers to the official school web site. As this site is the public face of the institution, the content on this site will be public. In most institutions, the ability to put add and edit on the site will be limited to a small number of people. The school site will run in Drupal.
Specifics
- Class Sites
Offering class sites in both Drupal and Moodle will allow instructors to choose the tool that works best for them. To generalize, Drupal sites offer a greater degree of flexibility in crafting a learning environment -- some users make the case that class sites in Drupal feel more student-centered than class sites in Moodle. This flexibility, however, comes at a cost. From a sysadmin perspective, Moodle is easier to maintain than Drupal. Additionally, some users claim that the focused UI of Moodle is easier for users who are not tech-savvy. The ease of use caveat, however, is directed more at teachers than at students. Students thrive in either Drupal or Moodle.
Over time, students will export content from their course work into their learning portfolio (maintained in the community area in Elgg). Currently, this can be accomplished through Elgg's aggregator/feedbook creator.
- Common Area
As the name implies, the common area is the heart of the school site. All members of the school -- students, teachers, and administrators -- will have accounts here, and these accounts all come with the standard functionality of Elgg: a personal blog, personal file storage, podcasting, personal feedbook, etc. Users can choose to share resources they collect in their area, or to keep their resources private. Over time, students can use their space in the common area to build a portfolio of their work. Each member of the the site can use their personal space to create their own individualized learning/working environment.
Additionally, all clubs, departments, and administrative divisions can create private or public sections. Within Elgg, these sections are called communities, and these communities can be set up as private (users can only join with an invitation) or public (the user joins at their discretion).
Elgg communities have the same functions as Elgg users. Within the community space, every community member can post to the community blog, upload files to community file storage, create community-specific podcasts, create community-specific news feeds, etc. Also, like individual users, community resources can be private within the community or shared among all site members.
Within the institution, it is highly likely that some administrative divisions and extracurricular activities will want more functionality, privacy, and/or security than offered by Elgg communities. These groups can do their work in a Drupal site. This allows these groups to collaborate on sensitive or private work behind an additional level of access control, and to set up more structured/discipline-specific sites than possible within Elgg. When members of these communities want to share content with the rest of the school, they can aggregate the content from the Drupal site onto their community blog, where all members of the school will be able to view it. As one example of functionality that exists within Drupal and not within Elgg, the Drupal sites will allow online publishing and layout of newspapers, newsletters, and literary magazines with a level of complexity that Elgg doesn’t support.
- The School Site
Up to this point, we have described content that is largely private to members of the school community. The content of the class sites and the content in the community area is not accessible to the general public. The school site, however, is intended for the public, and all of the content on the school site is visible over the web. For this reason, only a select few people should have the ability to create and edit content on the school site.
Much of the content -- like the directions, or the mission of the school -- on the school site will be static. However, dynamic content can be added to the site by aggregating feeds from the community blogs. One example of how this could be used involves athletics: if a game was cancelled, this would be posted to the athletics blog. The feed from the athletics blog would be picked up on the school site, where the information would be distributed to site visitors. Obviously, not all blogs from the community area would be aggregated and published on the school site, and the choice of what blogs to include for publication would be made by a site administrator of the school site.
Summary
What I outlined in this post provides one way of setting up a private online learning environment and public web presence for a school. In describing this setup, I attempted to create a scenario where student needs and institutional needs were met in a mutually supportive way. As I said in the beginning of this post, this is one way of doing it. Given the flexibility of Elgg, Drupal, and Moodle, countless other technologically viable and pedagogically sound solutions exist.
Keywords: blogging, Drupal, Elgg, ePortfolio, K12, Moodle, online learning, open source
Comments
Hi Bill,
This post has come at just the right time. I've been mulling over something like this for a while now - we have Moodle and Elgg working quite happily side by side, and are excited about the possibilities which Penny and Martin's work in NZ open up for integration here, but I've been feeling that it would be worth bringing the public facing website into the equation, and would love to have some easy way of sharing at least some of our blog content publicly, and Drupal certainly looked the front runner there, especially when coupled with Elgg's feedbook functionality.
I'm surprised your diagram doesn't make more of Moodle; there are certainly things which you might use Elgg or Drupal for that I'd probably run in Moodle, in part becuase of the rich range of activity and resource support, and perhaps also the UI design - we've used it successfully for projects like the school magazine and staff communications, alongside the more traditional courses. I do take your point about student-centredness, though. I guess this is a matter of choice!
I'd be interested to hear your views on integration with school management information systems - I know SIF compliance has been mentioned both here and in Moodle-world but I'm not aware of much progress. Out of interest, are there ways of sharing user authentication between Moodle/Elgg and Drupal?
Hello, Miles,
RE: "we have Moodle and Elgg working quite happily side by side, and are excited about the possibilities which Penny and Martin's work in NZ open up for integration here" --
I'm pretty excited about that too, and that's part of the reason I didn't delve too heavily into details concerning Moodle -- I'm waiting to see what possibilities this integration opens up. I'm looking forward to seeing the solutions they coded.
RE: "there are certainly things which you might use Elgg or Drupal for that I'd probably run in Moodle" --
For a lot of things, either Drupal or Moodle will get the job done very well. Moodle has some school-specific features that don't exist in Drupal, while Drupal gives you a flexibility with regards to layout and workflow you can't get in Moodle. A Drupal site can give you a very nice layout for an online version for a literary magazine. However, when all is said and done, the main differences are aesthetic, rather than functional. I completely agree -- this is a matter of choice.
RE: "are there ways of sharing user authentication between Moodle/Elgg and Drupal?" --
There is a module that integrates Drupal and Moodle, but it was designed for an older (4.5) version of Drupal. Currently, the Drupal community is getting ready to release version 4.7. I've been researching ways of integrating users between the three apps (one of the other reasons I'm excited about the work that Penny and Martin have done -- from reading through Penny's notes it appears that they have written some code that will be useful for this).
As I think about user integration, it seems like (at minimum) the following things would need to be in place to simplify user management:
I've been doing some research on the best way to implement this, and while I have some ideas, I'm still looking around -- I'd actually love to get some feedback on the perceived advantages/disadvantages of these different approaches --
RE: "integration with school management information systems" --
This is always a tricky issue :) -- the basic question I see asked most frequently involves balancing security against convenience. One easy point to use to start integration is with the user info used for ldap authentication. Most schools maintain multiple lists/spreadsheets/databases of their students/faculty, and as all of these lists are slightly different, this is where the problems begin. So, as a starting point, I always try to get schools to reduce (or even eliminate) duplicate data entry. Really, though, in many schools this is less a technological issue and more of a school culture issue -- Development uses different software than Admissions, who uses different software than the Registrar, and they all like what they have and don't want to change.
Bill
Thanks for responding to my queries and comments so quickly, Bill.
This is going to be a really interesting area to follow. It would be great to have CRM and MIS functionality fit into the package somehow, but I guess one step at a time. I'm loosely involved with Schooltool (web-based open source school MIS), who're interested in getting Moodle integration on board in the medium term, but are waiting for the Moodle folks to sort out their web services API.
FWIW, in the UK, the SSO solution of choice is Shibboleth, which also provides a federated authentication model, so eg your learners could read my learners' blogs, but the rest of the world couldn't.
Hello, Miles,
With regards to CRM, I'm actually looking at CivicRM with an eye toward that -- it currently integrates with Drupal. That's on my to do list, but after we sort out some of the details I mentioned earlier.
Also, thanks for the link to Shibboleth -- I'll look it over as well.
Bill
Thanks for posting up these excellent thoughts Bill - I can see some exciting times ahead between these three (and other) open source tools.
The work that Martin, Penny and co have done looks very good indeed, they have really moved Elgg on, not just in regards to Moodle integration but in terms of Elgg's scalability, efficiency etc - we are currently testing the code, once testing is complete the plan is to get everything merged as soon as possible.
I am currently involved with a particular programme at my college (Skills for Life), where it would be quite useful for us to get an Elgg/Moodle deployment together.
I have read the above with interest as I have been helping a friend out with a commercial Drupal installation:
http://www.dmwsafety.co.uk
Is there anywhere I can see a Moodle/Drupal installation in action? Will just help me understand how this setup could work a bit more.
WRT integrating Moodle and Drupal directly, so far (at least from the Drupal side) we've been working more on issues of user management than content management. Toward this end, I've been working on sorting out the details of single sign on with a single source for user data. This would allow users to log on once and get access to multiple sites (with access roles managed on a site-by site basis) while sysadmins only need to worry about maintaining user one source of user data (ie, no duplicate data entry, or concerns about synching multiple sources of user data).
From the Drupal side, we've also sorted out importing content as any node type via rss feeds -- we'll be releasing this code back to the drupal community in a week or two.
In the framework I described above, Elgg is really the core. Drupal, Elgg, and Moodle will work side by side in a complementary fashion, but the Elgg site will provide the most open place for all users to congregate (think of it as a lunchroom -- some people hanging out, some people studying, some people tutoring one another, some people assembling portfolios, etc) -- then, people leave to go to different places: a club meeting (a Drupal site), a class (Drupal or Moodle), a dep't meeting (a Drupal site), etc. These more specialized activities can share content with the larger community by publishing content that will be picked up by the public-facing school web site (a Drupal site) or by individuals in their personalized workspace (Elgg).
There are some obvious places where integration should exist among these apps, and among Drupal and Moodle -- for example, it would be nice when, within a Moodle site, to have a block of links to any Drupal sites to which a user had access -- however, I'm still not 100% convinced that this feature isn't better suited for the user management side of things, than for Drupal- or Moodle-specific code.
So, a long answer to a short question: We're tackling the backend work of sharing users in a scaleable way before looking at the opportunities that can be provided in the UI. Our goal is to build the best working version possible by mid-July, and use that experience to inform where we need to improve the quality of the code, the simplicity of the setup, the cleanliness of the UI, the clarity of the documentation, etc.
And we're definitely looking for interested parties to help with developing code :) Many hands make light work, and all code developed will be GPL'ed.