Click. Connect. Learn.

All posts in Moodle

Do You Want To Help Eliminate Blackboard?

The Summer of Code application process is underway. Along with some good folks at The Oregon State Open Source Labs, we have put together a proposal to share content between Moodle and Drupal.

In combination with the recently developed functionality to author and export content from Drupal in IMS LOM format, you could author courses in Drupal or Moodle, and use those courses interchangeably in Drupal, Moodle, or any other LMS that imported IMS LOM.

OER's: Publishing is the Easy Part; Now, Let's Make Them More Usable

Introductory Notes

These are some thoughts in progress -- I've been thinking these things through for probably the last few years, but things have been getting more interesting of late.

Some of the blog posts that have helped shape my thinking here include:
http://bavatuesdays.com/proud-spammer-of-open-university-courses/
http://weblogs.elearning.ubc.ca/brian/archives/044998.php

This Would Be Easier If You Were Joking

I'll admit it at the outset: I'm in a bad mood today.

But when I see things like this, and this, and this, all talking about running courses in Facebook, I can't help myself

(Okay, really I can. But in this case, I don't want to).

Read Facebook's terms of service.

The "User Content Posted on the Site" section is particularly relevant here:

When you post User Content to the Site, you authorize and direct us to make such copies thereof as we deem necessary in order to facilitate the posting and storage of the User Content on the Site. By posting User Content to any part of the Site, you automatically grant, and you represent and warrant that you have the right to grant, to the Company an irrevocable, perpetual, non-exclusive, transferable, fully paid, worldwide license (with the right to sublicense) to use, copy, publicly perform, publicly display, reformat, translate, excerpt (in whole or in part) and distribute such User Content for any purpose on or in connection with the Site or the promotion thereof, to prepare derivative works of, or incorporate into other works, such User Content, and to grant and authorize sublicenses of the foregoing.

Drupal and Moodle together? Really? Really.

Over on the OpenAcademic blog, Sean Lancaster has asked the following question:

i appreciate the effort that is being undertaken to create a terrific online learning environment that brings various resources together seamlessly; however, i am curious to better understand how Drupal and Moodle are different in what they provide. i mean, why would a person use both tools at the same time?

The short answer to your is that the best option is a subjective determination -- kind of like Mac vs PC, etc, etc.

OpenID in an Educational Context

NOTE: Comments closed on January 15, 2013. This post is around 7 years old, and spammers have (for whatever reason) discovered it. END NOTE

OpenID provides a method of Single Sign On (SSO) between multiple web sites. OpenID allows users to "claim" a specific url; this url identifies the user as they browse and join different web sites.

Other SSO options exist, including Shibboleth, SXIP, Pubcookie, and JA-SIG's Central Authentication Service. OpenID differs from other methods in a few ways, but the purpose of this post is not to compare or contrast the pros and cons of the different SSO options. This post is also intended as an overview to demonstrate some possibilities, not as the final word on what OpenID can or can't do.

Far too frequently, conversations that set out to compare and contrast different standards end up denigrating one standard in order to elevate another. This type of conversation seems counterproductive; as with any technological solution, the best solution will be dictated by the specific needs of the institution or organization. While OpenID will not be the perfect choice for every situation, it combines flexibility, security, simplicity, and scalability. These traits make OpenID an attractive choice in a wide range of scenarios.



Background:

Two things are required to use OpenID: an OpenID server, and an OpenID-enabled client site. The OpenID server is the site where users claim their unique url. An OpenID url looks exactly like a web address; for example, if an OpenID server is set up at elgg.net, a user's OpenID url would be http://elgg.net/username -- more to come on this later. Then, using their unique url, the user can log into any site that is set up to accept OpenIDs. Among open source projects, several applications are already OpenID enabled. There are also libraries available to simplify the process of OpenID-enabling other applications.

This page provides links to OpenID providers (to get your own OpenID) and downloadable OpenID servers (to set up your own server). Within an organization you can set up one OpenID server that serves as the central authority for managing SSO to selected resources. OpenID servers can also be incorporated into existing applications, so that any site member also receives an OpenID. For example, an OpenID server can be incorporated into Elgg, which creates some interesting possibilities -- more to come on this later.

It is also important to note that OpenID is both an open standard, and that many of the applications that use OpenID are released under open source licenses.

OpenID is also gaining traction among larger companies. Verisign recently rolled out an OpenID implementation with their Personal Identity Provider service.



OpenID Features:

Single Sign On (SSO): OpenID allows for SSO between sites that are OpenID enabled.

User management: an OpenID server can authenticate against a wide variety of data sources, from a .pwd file to user data in a legacy system via LDAP. So, an OpenID server does not require an institution to maintain and synchronize multiple sets of user data. OpenID servers have been set up to allow pluggable authentication against a broad range of data sources to allow for maximum flexibility.

Whitelist/Blacklist sites: OpenID client sites can be configured to whitelist and blacklist sites. To demonstrate how this works, consider the following scenario:

Johnny is a sixth grader at Neighborhood Middle School, where they have an OpenID server. Using his OpenID, Johnny logs into his class web site, the chess club web site, and his personal learning space. Because all these sites are OpenID enabled, he only logs in once to do work in these different areas. However, because these are all different sites, Johnny can be a student within the class site, and a content moderator in the chess club site.

Within this same school, all client sites have been configured to only accept logins from the school's OpenID users. So, any logins with an OpenID from outside the school community will be rejected. As with all other security systems, a user needs to have a valid username and password.

The whitelisting and blacklisting feature can also be used to support safe, secure online collaboration between different schools. If the Neighborhood Middle School developed a relationship with the Far Away Middle School, the two schools could set up a web site to allow logins only from each school's individual OpenID server. So, members of the two school communities could have access to the site, and the rest of the internet would have no access.

Elgg as an OpenID server: Using Elgg as the front end for the OpenID server creates additional benefits. Elgg's user profiles allow for flexible display of profile information, as the OpenID url points directly back to a user's profile. For example, my Elgg profile is visible at http://elgg.net/bfitzgerald. If elgg.net was enabled as an OpenID server, my OpenID url would be the same as my Elgg profile. The long term roadmap for Elgg will allow for searching across different Elgg sites. The combination of whitelisted logins between different OpenID servers, searching across Elgg sites, and OpenID urls that point directly to a user's profile will simplify collaboration between and across organizations.

Taking this a step further, OpenID could also simplify the process of allowing students from different schools to take the same class in a single Moodle install. If Moodle was OpenID enabled, it would be possible to whitelist OpenID servers from multiple schools. This has the potential to create a truly distributed learning environment: students from different institutions interacting in a more formal class structure (Moodle), and in an informal learning space (Elgg).



Where things stand now:

Kevin Jardine is actively working to OpenID enable Elgg as an OpenID server and client. Drupal 4.7 and 4.6 are OpenID enabled, and we are creating an admin screen to simplify whitelisting/blacklisting sites. A Mediawiki extension is under active development in the Mediawiki subversion repository. There is also some preliminary interest in OpenID enabling Moodle, with at least one developer expressing an interest in writing the code to make this happen.

Update -- 10/29/06: The Moodle and Drupal OpenID clients are working. Elgg is working as an OpenID server, and there has also been some great development on Drupal as an OpenID server. More to come shortly.

Elgg, Drupal, and Moodle -- the components of an online learning environment

NOTE: comments are closed on this post. It has been attracting a lot of spam over the years, and the web has changed significantly since this post was first written. END NOTE

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.

Syndicate content