- 1 Background
- 2 Possible Infrastructure Pieces
The Open Education Resource Foundation and its WikiEducator project have been running a sequence of very successful online training courses in basic wiki skills.
Recent courses have been run by combining:
- content pages in WikiEducator
- daily instructional messages from course facilitators in Moodle
- by enrolling all course participants in a particular Moodle course, it is used basically as a broadcast email facility
- participants have the ability to contribute to the forum(s) in the Moodle course, but that is rarely used
An upcoming (early 2011) course in understanding copyright and the open content licensing options may attract an even larger and more diverse audience. It is a good time to review the infrastructure available for the course. A substantial discussion started in the context of the course, but has grown and needs further consideration.
- Rather than using the verified email address that users enter when creating a WikiEducator account, the Moodle course registration uses a text field where users are expected to enter a valid email address. Every class one or two people enter their email addresses incorrectly so they never receive course instructions (at least until someone manually intervenes to copy their email address from the Mediawiki database to the Moodle enrolment).
- Because the OERfoundation email server is hosted at Amazon EC2 and some providers block its entire address range from sending email, not all course participants can receive email.
- The Moodle interface is different from the Mediawiki interface. If the participant is not familiar with either, needing to learn both to participate in forums seems off-putting.
Wayne Mackintosh generated this wishlist / specification:
- A way for "forcing" email from facilitators for daily instructions to all registered participants of the course.
- A way to opt / in out of email notifications for discussion forum posts - -possibly starting with the default being to receive email
- Avoiding the problem of receiving 500 plus emails for all the personal intro's -- the high traffic day.
- Easy for admins to manage - -self registration and then the rest on auto pilot
- Easy for newbies (I worry about newbies being able to change the relevant preferences in MW.)
In addition, for the large courses we are keen to implement Microblogging as a mechanism for learners around the world to connect socially and intellectually using microblogs as a stream of "digital consciousness" for a number of specified activities as a mechanism to pace learning during these large courses.
To harvest a tag or group microblog feed from course participants for display on course homepage in WE.
Issues and thoughts
- Installing widgets based on proprietary code like Twitter potentially contravene the terms of service of the provider and contravene our commitment to free cultural works licensing. Moreover, some users may object to the indirect advertising of a preferred supplier in the third party widget code.
- There is a Mediawiki widget for the identi.ca microblogging service which uses open source software, and all data is licensed under CC-BY
- Existing users of Twitter, may prefer to tweet within their existing networks. There are twitter - identi.ca integration tools on the respective sites (haven't tested this yet.)
- identi.ca supports open ID -- but again we face the issue with Newbies having to create multiple accounts. The majority of our target audience will not have an existing Microblog account.
- Would the identi.ca group feature be better than harvesting the rss of a hashtag?
- Would it be preferable to host our own instance of the StatusNet code for use during our courses? (Existing Microbloggers can integrate with their preferred accounts for the duration of the course.)
Cost / benefit
- At this stage we have an obligation for conducting the pilot offering of the Open Content Licensing 4 Educators course. Lets assume target number of participants of 500 - 1000 learners.
- There is no guarantee that we will be offering subsequent Open Content Licensing 4 Educators workshops --- however the likelihood of follow up funding is possible. --- Incremental design solution :-)
Possible Infrastructure Pieces
The OERfoundation runs its own instance of Moodle 2.0. On 2011-01-05, its external database authentication support was modified to allow checking user names and passwords against the WikiEducator user database, eliminating the need for a separate password.
WikiEducator has the OpenID extension installed and allows both (a) associating one or more remote OpenID authentications with an existing WikiEducator account or (b) allows creating a new WikiEducator account associated with an OpenID authentication.
WikiEducator uses an old version of the LiquidThreads extension which attempts to add a threaded discussion forum to the disscussion (AKA talk) page associated with every content page. A limitation of the version in use is the lack of email notification on forum postings. In October, 2010 WikiEducator added an external program that watches for thread postings and can [WikiEducator:Liquid_Threads#Emailing_Postings|email you when a posting is made] either:
- on the talk page of any page on your watchlist
- OR in any thread in which you have posted
- turn the textarea created by the InputBox extension into a more traditional registration form
- make the class participants list display as if it were a table, rather than a list of lists
- How will this scale -- any issue if say 500 folk register?
Email and Mailman
The OERfoundation runs its own email server. Unfortunately some ISPs block all mail originating from the Amazon EC2 address block where the email server is currently hosted. That means not everyone receives email we send.
Mailman List Processor
The OERfoundation has its own (essentially unused) installation of the Mailman list processor and expertise in its design and operation.
MediaWiki User Email
WikiEducator has a small offline program that can use the Mediawiki user email facility to send mail to a user.
WikiEducator uses the RSS extension which allows displaying a single RSS feed per invocation on a content page. This would allow including feeds from blogging or micro-blogging sites, but not a built-in way to amalgamate multiple feeds.