At the risk of adding to the world of “list-of” blog posts, I wanted to share some of the things that have come up in conversations with many people lately around choosing an OER platform. More important than things like allegiance to a programming languages, wikis, content management systems, or some particular software framework, a platform choice has to be sensitive to the context in which you wish achieve the OER-related impact.

Just for interest, my off-the-cuff list of the big OER platforms is (apologies to those not mentioned):

• Connexions
• Curriki
• CK12
• WikiEducator

I’m the first to admit that it would be an incredible amount of fun and possibly extremely satisfying (assuming success) to try to build a new, better, slicker, faster solution from scratch but the OER world has some pretty significant players now and there is little to be gained from additional fragmentation. In fact, consolidation may be one of the best things we could see in the OER space now that governments are starting to take OERs seriously.

Context: Education in South Africa

A quick context description is the best place to start and I’ve put some of the context information down in an earlier post about the Siyavula strategy.

The four key features that the Siyavula software framework needs to provide are:
Importing – the ability to import already existing material so that teachers and organisations can share easily
Editing – the ability to edit, adapt, enhance and reorganise resources
Vetting – the ability to flag content as approved by either an individual or organisation
Typesetting – the ability to produce print-ready material because the vast majority of South African learners need hardcopy material, this is the primary accessibility requirement in South Africa

As part of our sustainability model Siyavula did not want to be responsible for building another web-portal from scratch and maintaining it. We sought a platform that we could use or partner with that embraced openness. We chose Connexions as our platform and have been working with the Connexions team for well over a year now.

Apart from ensuring that the platform had a strong team backing it, good governance and other due-process related things, we considered:

Open Licence

Connexions demonstrates an extreme commitment to openness in all aspects. The software that is used on www.cnx.org is an extension of Plone and is available as a separate open-source project called Rhaptos.

The content on Connexions is licenced under Creative Commons By-Attributions licence. This licence ensures that the content is compatible with all other projects using Creative Commons licences, even those that have chosen more restrictive ones and also enables the possibility for the exploration of commercial enterprises based on the open content items. Many other projects use more restrictive licensing constraining use and innovation.

Homogeneous vs. Heterogeneous Repositories

For communities with real diversity to form rapidly within the body of content it should be rapidly re-usable and re-mixable. For this to be possible the content needs to be edited and mixed easily and rapidly online, imposing the requirement that the content be homogeneous in a number of respects.

Format

Repositories that allow users to upload files in a random selection of formats do not promote rapid re-use and re-mixing as users are required to have all the relevant software packages (many proprietary) to make adaptations. This places an unnecessary burden on the users and hampers content adaptation and enhancement.

Connexions imports all text-based content and homogenises it, storing it in XML. This ensures that all content in the repository can be re-mixed without users requiring any special transformations or software packages. XML also allows proper semantic mark-up which has many additional benefits, for example equations stored in MathML can be imported into the vast majority of maths packages allowing users to interact with the content.

Licence

Repositories that contain content of mixed licensing can be frustrating for users as they are often not clear what content can be re-mixed, even if the format is compatible.
All Connexions content is licensed under the same copyright licence ensuring maximal mixing.

Structured Content

The vast majority of K-12 (known as R-12 in South Africa) content requires structure. Wiki-based platforms, based on a model involving a flat structure of individual pages are not well suited to the collaborative development of cohesive, coherent structured texts (see FHSST How-To for detailed anecdotes of WikiBooks usage). It is possible to restructure wiki software to behave more like a content management system with structured content but the simpler solution IMHO is to begin with a content management system.

Connexions provides the ability to develop structured content in the form of collections, ensuring that small units can be developed, modules, as well as books or entire courses.

The full revision history of any published resource is also permanently available on Connexions allowing courses, books or sites to reference specific versions of resources even though new editions may exist.

Editing

To simplify the content creation process and ensure that once a user had access to the content repository they were able to adopt an authoring the platform had to provide both authoring as well as a solid repository.

Connexions is such a solution, allowing users to edit content that has been imported or create content from scratch online.

Permissions

Although all content can be re-mixed by all users on Connexions, users still have control over their own versions of a module. This in fact increases freedom as users produce their own versions of content rather than entering into flame-wars around controversial resources, particularly prevalent in wikis where a single page exists on a topic.

A solution was required that would allow different versions of resources to exist in parallel. This is particularly important in a context like the South African context where we expect many parallel versions of a resource to exist to cater for the vast number of cultural and social contexts that need to be catered for.

Workgroups

The sustainability of content in the Siyavula project will be ensured through communities of practice. All candidate platforms needed to provide organic communities with a space in which to exchange content, ideas and collaboratively develop new resources.
Connexions provides this through workgroup functionality.

Vetting

To ensure credibility with the vast majority of the teaching corps, content vetting is required. Connexions provides light-weight lens functionality which easily allows for multiple vetting agencies to approve the same content items.

Typesetting

The primary accessibility requirement in South Africa is still hard-copy. A solution that allows for the typesetting of content is needed to gain real traction.
Connexions provides a typesetting solution which handles mathematics well, something most solutions aren’t capable of handling.

Decision

The primary platform discriminators for the Siyavula project were:

• homogeneity of format and licence,
• structured content, and
• typesetting.

Serious consideration was also given to choosing a platform and deploying it ourselves but this was shelved for sustainability reasons. For reference, some platforms considered were:

• Plone / EduCommons
• Drupal (extension of www.fhsst.org)
• MediaWiki

Topics like homogeneity of repository and requiring structured content (to wiki or not to wiki) eliminate many of the candidate platforms. Coupling the need for proper typesetting ensures that Connexions is the only sustainable solution that simultaneously:

• allows external development on the underlying platform,
• imports content into a homogised format,
• provides an authoring platfrom with the relevant permissions and structure,
• supports the organic growth of virtual communities with their own space,
• enables effective solutions for vetting, and
• is coupled to an effective typesetting engine.

We need much better management of the feedback we receive for the Free High School Science Texts project. It needs to be simple and fast and allow us to manage it easily. To help with this we’re looking to have a small feedback module written for the site. We’ll use it once we’ve upgraded the site to Drupal 6.x.

I’m looking for some development quotes and thought I might get some additional exposure if I post the draft specification on my blog. If you’re a Drupal person and would like to have a crack at this feel free to contact me with any clarifying questions or a quote for the work. I intend to make a decision by the middle of next week (18th November) so you’ve got a week to get the information to me.

FHSST Feedback Module

The FHSST site allows authors to build books in LaTeX. The original goal was to have many LaTeX-competent authors working on many sections. We have learnt that very few people are comfortable with LaTeX and PSTricks. To better accommodate people who still want to make contributions but not get their hands dirty we must provide a simple way to give the necessary input.

We would like a feedback module to be written for Drupal to help with this. This module should allow three types of feedback:

1. errata

2. suggested contributions

3. testimonials

Errata

Each erratum needs to contain:

• erratum title (mandatory)

• detailed erratum information (mandatory)

• book for which it is submitted (mandatory)

• book version for which erratum is applicable (mandatory)

• book section in which error occurs (mandatory)

• book page number (optional)

• submitter’s:

  • name and surname (mandatory)

  • email address (mandatory)

  • role, one of:

    • learner

    • educator

    • parent

    • other

• timestamp of submission (recorded automatically)

• status (only changeable by coordinator – starts in pending):

  • pending

  • corrected

  • disputed

• timestamp of resolution (i.e. corrected or disputed state change – recorded automatically)

• person changing state (recorded automatically)

When submitted, an erratum must go into a queue and the coordinators of the relevant book should receive an email notification that it has been submitted. They can then login and review the erratum. Once they have processed it they must be able to set it to either corrected or disputed in the case where the erratum is actually incorrect.

A page should be provided where users can see all errata submitted, the submitters’ name, the relevant book and version, and the status of the errata. The title should link to the full erratum view.

A block should be provided where users can see the 5 most recent errata submitted (title, book and status).

Suggested Contributions

This is to allow general users to submit a contribution to be included in the book by a LaTeX-enabled author. Each contribution should have:

• contribution title (mandatory)

• detailed contribution (mandatory)

• attached files (optional)

• book for which it is submitted (mandatory)

• book section (optional)

• submitter’s:

  • name and surname (mandatory)

  • email address (mandatory)

  • role, one of:

    • learner

    • educator

    • parent

    • other

• timestamp of submission (recorded automatically)

• status (only changeable by coordinator – starts in pending):

  • pending

  • incorporated

  • discarded

• timestamp of resolution (i.e. incorporated or discarded state change to be recorded automatically)

• person changing state (recorded automatically)

When submitted a contribution must go into a queue and the coordinators of the relevant book should receive an email notification that it has been submitted. They can then login and review the contribution. Once they have processed it they set it to either incorporated or discarded state in the case where the contribution cannot be used.

A page should be provided where users can see all contributions submitted, the submitters’ name, the relevant book and version, and the status of the contribution. The title should link to the full contribution view.

A block should be provided where users can see the 5 most recent contributions submitted (title, book and status).

Testimonials

This is simply to collect information about how the content has been used.

• testimonial title (mandatory)

• detailed testimonial (mandatory)

• book for which it is submitted (optional)

• book section (optional)

• submitter’s:

  • name and surname (mandatory)

  • email address (mandatory)

  • role, one of: (mandatory)

    • learner

    • educator

    • parent

    • other

• timestamp of submission (recorded automatically)

Administration

For the feedback module the books for which feedback is being received need to be configured. This should happen from the module administration page and not depend on the book module of Drupal. The administrator will add the books for the module and then add, on a book-by-book basis:

• versions

• chapters and sections

• coordinators

When a book is added at least one version number is required. For each version number provided, a list of chapters and sections is required. A book will have multiple versions, each with their own unique chapter and section listing. This listing can be a simple textarea where each line is a chapter or section heading.

Each book must also have a list of coordinators who are users on the system. Coordinators should be able to access a list of all errata and contributions for their books. They should be able to view them and change the status if necessary. The time when the status is changed should be recorded.

Special Remarks

All the feedback types should be node types and should integrate into the Drupal CMS properly so that they can be integrated with other modules designed to manipulate nodes. The theming information should also be separated so that they can be re-themed.

A special page should be provided that can be used as the homepage. This page should have a customisable body of full html and then have forms for all three feedback types. This will be presented to non-authenticated users as the homepage allowing them to provide the feedback directly from the front page. We would like jQuery/jQuery UI integration in this page so that a button can be shown for each type of feedback and if clicked the form must render as a modal window. Submission using these forms should be via AJAX and should trigger an update on the blocks for the content types if they are shown.

To simplify the forms when a user selects a book the relevant versions should be loaded. Once the version is selected only the relevant sections should be loaded. Validation for all form fields should be implemented.

The module should be written in such a way to conform to the Drupal 6.X API and should only have dependencies on well established modules (modules that are actively maintained and have demonstrable support and traction within the Drupal community).

We would release all the code under the Gnu General Public Licence.