Note: Forward this to your “Shameless Commerce” division… If you’re going to be in Philadelphia at the end of January, consider making some time for any one of a series of workshops being hosted by Steve Hargadon at the Science Leadership Academy. The principal of SLA, Chris Lehmann is hosting the sessions: run by Michelle Moore on January 29th and 30th; run by Will Richardson on February 2nd and 3rd; and run by yours truly.

In planning my session, I’m trying to build a training that allows educators to use the tools they learn about. Toward that end, all participants in the Drupal session will receive Drupal hosting through August 2007. So, a workshop participant can learn how to build curriculum in the session that they can deliver on their first day back in the classroom.

For those interested, here’s a rundown of the curriculum I’ll be covering –

Overview: This workshop will cover how to access Web 2.0 tools in a secure educational environment. Participants will learn how to work in Drupal to give students access to social bookmarking, blogging, podcasting, and collaborative workspaces. Participants will also learn how to design curriculum within the site, and best practices for working in an online environment. All participants in this session will also receive hosting for a fully configured Drupal site through August, 2007, as part of the conference cost. As this is a working session, participants are encouraged to bring materials from lessons they are planning. The goal of this session is to provide participants with tools they can use immediately in their classrooms.

Day 1:

• Creating accounts for instructors and students;
• Student blogs;
• Tracking student work/providing feedback on student work;
• Curriculum Development;
• Managing the day to day operations in a course.

Day 2:

• Social bookmarking;
• Photo sharing;
• Podcasting;
• Aggregating rss feeds from external sources;
• Creating customized searches and webquests;
• Managing content over time (aka how not to drown in a sea of student writing).

In an earlier blog post, Sean Lancaster 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 is that the best option is a subjective determination — kind of like Mac vs PC, etc, etc.

A slightly longer answer is that the choice of tool for the learning environment will be determined by the relationship between learners’ needs, instructors’ needs, and institutional needs.

A still longer answer is that making an across the board choice is no longer necessary, and we are at a place where it’s possible to match the tool to teaching/learning style. It’s possible for an institution to provide these tools side by side to support learners and teachers in the classroom.

Moving outside the classroom, Drupal is a pretty flexible tool that can be used to create intranets for different academic departments, club sites, a public facing school site, an alumni forum — and within each of these contexts, Drupal can be customized and focused to meet the specific needs of the site users. Some people have also used Moodle to meet these needs. The need for a “one size fits all” approach no longer exists, as we have options.

All of these elements (and others ) will factor into the decision. It’s possible to set up OpenAcademic without Drupal, or without Moodle. The solution is, by design, flexible and scalable. However, it’s necessary to stress that the choice of tool to use is just that: a choice. The user has options. The institution has options. The sysadmin has options. People and institutions do similar things in different ways. The work we’re doing at OpenAcademic is intended to provide a flexible, adaptable toolkit. Using the tools within OpenAcademic, you can create a simple web presence, or a learning network that connects learners and institutions on different sides of the world. You can choose to use the tools — in any combination — to meet your needs in your way.

If you’re still awake and reading at this point, I’ve written more about ideas related to this topic here and here and here.

At long last, we are happy to announce the launch of the OpenAcademic project. This project is dedicated to integrating Elgg, Drupal, Moodle, and Mediawiki. All code developed under this project will be released back to the respective communities under an open source license, and it will be freely available to download and distribute.

Yeah. We’re silly like that.

This project arose from a series of online discussions about Elgg, Drupal, and Moodle, and how these tools fit in an educational setting. As we continued to talk about these tools, we all saw the opportunity to create a better online learning environment — a learning space that incorporated informal learning alongside a more formal course structure, and that drew from the strength of the community-building software already built by the open source community.

Over the next few days and weeks, we will be talking more about our plans and vision for the integration. In general terms, the integration will start with single sign on between sites, and the ability to move content seamlessly between sites. The integration will also include the ability to search across sites, and to aggregate tags across sites. As the integration develops, these tools have the potential to create a truly distributed network of learners.

This integration, and this site, are very much works in progress. As I mentioned above, we will be writing about our precise vision for the initial integration. As we develop code, we plan to release it as early and as often as possible. We want people to use it, and to give us feedback, and to get involved in the process. Towards that end, we will be launching a developer site shortly — a site where developers can find information on how to get involved, meet other coders working on the project, and share code back. Look to this space for an announcement about when the developer site goes live. In the meantime, if you want to help out with the code, or talk to us about development for your institution, don’t hesitate to contact us.

Currently, the project is moving forward on a few fronts. We have been focusing on single sign on, as we see that as a central piece of functionality. Work is underway on building out Elgg as the front end for an OpenID server, and Moodle integration of OpenID has also begun. Drupal is also OpenID enabled, and there is an OpenID plugin in the Mediawiki svn repository. We have also looked at a few possibilities for searching across multiple sites, and for aggregating tags across sites. One of the items on Elgg’s long term roadmap is the ability to search user profiles and maintain friends across different Elgg installs, and some initial work on that has also been completed.

So, here’s to the beginning of something fun.

Cheers,

The OpenAcademic team

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, , 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, . There are also to simplify the process of OpenID-enabling other applications.

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. an OpenID implementation with their .

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:

is actively working to OpenID enable Elgg as an OpenID server and client. 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.