classroom

May I Have Some More Social Networks?

Some interesting conversations going on around the intarweb.

First, Stephen Downes peeled back the first layer of the onion and described the goals of his project.

Then, there has been some discussion on social networks in general, and the Classroom 2.0 group Steve Hargadon has set up on Ning.

Steve likes Ning's low barrier to entry, while Dave Warlick, by his own admission, doesn't get it. Tony Karrer points out that a social network alone won't do it, but that some degree of common interest is required to unify the discussion. I'll leave my thoughts on Ning, the service, out of this blog post because I'm in a good mood and don't particularly feel like dwelling on flaws.

Spring Is In The Air -- Friends Everywhere I Browse!

With spring in the air, sap rising in the trees, sun warming the ground as it thaws our hope, it's only natural that our thoughts turn to code.

The Summer of Code, more precisely. Isn't that what you're thinking about?

We're submitting two proposals this year; the first is a collaborative effort with the Open Source Labs to leverage some of the functionality from Google's exposed APIs (and yes, I know, I know, I know). I'll be writing more on the precise spec over the next few days, so check back.

Our second proposal is up over on drupal.org.

For those who don't feel like reading about it elsewhere, here is the proposal:

1. Overview

This application allows users to make friends with any user on any site. This project is proposed in Drupal, but it can be built as an add-on module in any application. This has the potential to allow people to escape from the silos within most networks. Using this module, a person can connect with any user, on any site.

More importantly, this is completely decentralized, so a user does not need to hand over their personal information, or their friend's information, to a service/company they don't know or trust. At the end of this spec, we'll look at possible ways that this application can be extended.

2. Goals

Create a lightweight, extensible, scalable, decentralized framework for connecting people belonging to any site on the internet.

More importantly, make it easy to set up, and easier to use.

3. Implementation

The core functionality revolves around the following tables and fields:

The friend_user table: For a user creating their profile:

  • UID -- a user id -- in Drupal, this will be the site members UID
  • ProfileURL -- the user's home page, or the page where they want to be recognized. Within Drupal, this could default to a user's profile page, but it could also be configurable via admin settings to baseurl + somepath + username -- this would allow for integration with, among other things, modules like MySite. The user can also manually enter a URL, so if they want their home page to be their own special handcoded page on their own domain, they can make it happen.
  • FeedURL -- an RSS feed that presents a view of the user -- this can be their blog feed, or some other feed entirely. As with the profile URL, it can be set to a default value, an admin-specified value, or manually by the user.
  • PhotoURL -- an avatar that is uploaded by the user
  • name -- Just one name -- for some rationale behind this, start reading here -- FirstName LastName isn't as universal as one might think :)
  • email -- not shared publicly, but only between friends -- can also be used in some automated communication

The friend table -- stores records of friends, and of friendship requests

  • FID -- a randomly assigned ID for the friend
  • UID -- a user id (from the friend_user table -- aka, Friend Of
  • ProfileURL -- the address of the friend's profile page
  • FeedURL -- the address of the friend's RSS feed
  • PhotoURL -- the URL to the friend's avatar
  • name
  • email
  • status -- a flag on whether the friendship offer has been accepted or rejected
  • type -- group/categorize acquaintances -- Friend, Contact, Acquaintance, CyberAmigo, etc

The friend_category table -- this table stores user-defined categories of friends.

  • UID
  • friendcat -- the values in this field appear as options in the UI for friends, and are stored in the type field in the friend table

The friend_request table -- this table is used to keep track of requests for friends

  • requestURL -- the URL where the request for friendship was made
  • date -- the date the request was made

4. Making Friends

This section describes the core functionality. There are a few ways to get this done, but I'd favor something simple, and leave the exact approach up to the student.

a. Offer Your Friendship

  • Navigate to a site.
  • Click the Make a Friend button.
  • Leave your contact info -- what is the best mechanism for leaving contact info on the potential friend's site, and creating an entry in the potential friend's friend table?

This action should leave a record in the friend_request table

b. Accept/Reject a Friendship Offer

  • When a user logs into their "home" site, they will see if they have any pending friendship requests. These requests are stored in the friend table. Users can flag requests as accepted or rejected, and organize the friends into groups
  • Accepting/rejecting an offer should prompt an email to the new friend, with an area for a personalized message from the user

c. Reciprocity

While it would be nice to have friendship automatically reciprocated, I don't see it as necessary for the first pass. Thoughts?

5. Additional Functionality

These items would be part of the first version

  • Friends Block -- configurable to show x number of friends' avatars -- clicking on the avatar brings a user to the friend's home page.
  • Friends Page -- display all friends, with links to their feeds
  • Friends' Feeds -- display all feeds, sortable by date or friend. If the feeds are imported as nodes, and displayed via a view, then the feeds would be searchable, which would be quite cool -- but that's a small detail at this point

6. Expanding the Functionality

The functionality described here goes beyond the scope of what would be realistic within a SoC project.

  • OpenID integration -- with OpenID, it would be possible to create an overview of daily activity -- I need to look into whether this could be extended to include comments left while logged in using an OpenID
  • Profile expansion -- include user generated information such as Likes, Dislikes, Profession, Interests, Favorite Ice Cream, etc
  • OpenSearch integration -- create a feed from the info in the friend_user table that could be searched/aggregated via OpenSearch -- this could potentially be another way of finding like-minded people, and would have some interesting applications within large organizations and schools.
  • Building the profile wall -- there are a few ways to do this within Drupal, and using one method wouldn't need to preclude someone else from using another. A shortlist of possibilities includes MySite, custom themes of the existing user profiles generated by the core profile module, profiles as nodes, or my personal favorite, a node type that pulls some info from a user's profile and augments that with friend's info collected by the Friends Everywhere module. This last method would allow for comments on the node, and a quick doorway into a user's online identity. Combine this type of functionality with field-level access control and there are some pretty broad possibilities for only showing specific content to specific users.

See you in Philadelphia!

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: one on Moodle run by Michelle Moore on January 29th and 30th; one on Web 2.0 for educators run by Will Richardson on February 2nd and 3rd; and one on Drupal in the classroom 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 --

The Best Things In Life Are Free (as in Free Speech*)

Will Richardson talks about some useful tools in a recent blog post. While the tools he highlights are useful, a few things were left out.

A few alternatives to consider:

Will highlights Google Blog Search and Google Custom Search. As an alternative, a school or a teacher could set up a Drupal site. Add in the leech module which copies blog posts -- or other content -- into the site. Then, add in the OpenSearch module and the OpenSearch client module. The result: a class-specific, fully searchable aggregation of selected resources. For more info on OpenSearch, click here.

Vocab Daydreams

For a K-12 language educator, teaching vocabulary presents some singular challenges. While we all agree that vocabulary is a critical skill, the agreement tends to disappear when it comes to how to present vocabulary in a classroom setting. Talking about words has the potential to expose students to the power and paradox of language; however, vocabulary instruction frequently descends to a balance between exposing students to as many words as possible, defining the words clearly, and keeping the class awake in the process.

The challenge: minimize the rote repetition, maximize the time spent using the words.

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.

Integrating Elgg, Drupal, Moodle, and Mediawiki

This has been in the works for a while, but now it's official: http://openacademic.org

This is an open source project designed to integrate Elgg, Drupal, Moodle, and Mediawiki. All code that fuels the integration will be released back to the community.

The project is a collaborative venture between the Elgg team and FunnyMonkey.

In the next few weeks, we'll be building out the infrastructure to support the project, including a development site to centralize the integration discussions and coding, as well as a svn repository for the codebase.

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.

Storing and Sharing Bookmarks in Drupal

We are happy to release a new bookmarks module for Drupal. Using this module, users can create and share bookmarks with other site members. We'll be checking this in to drupal.org shortly. This module works in 4.7.x, and is released under the GPL -- enjoy!

From the module's README.txt:

The userlink module allows users to save and share links. To access the full potential of the userlink module, we recommend using the functionality offered by freetagging, and the contributed module tagadelic.

Pages

Subscribe to RSS - classroom