Content management system

From Dokeos

Jump to: navigation, search
This page is outdated, please go to LCMS

Currently, Dokeos is a Learning Management System (LMS). In recent years, there has been a clearcut evolution in e-learning systems from LMS to Learning Content Management Systems (LCMS) . New systems are built on a Content Management System or object repository from the start (open source example: Didactor uses the CMS MMBase), existing systems have integrated content management in their suites (Blackboard: CMS & portfolio; WebCT: Vista; N@tschool, and many more). Various commercial CMS's offer support for commercial LMS's (e.g. Hive van Harvest Road).

The advantages of having a CMS are obvious:

  • learning objects are linked to their owners instead of to courses
  • learning objects only have to be stored once and not in every course where they are used (as it is the case now in Dokeos)
  • learning objects updates are simple to perform and (can) affect all instances where the object is being referenced
  • it is possible to develop & use far more powerful search tools system-wide and not limited to a particular course
  • it makes building full-fledged portfolio's within the system a feasible option

and more...

Contents

Meeting

As the planned Developer meeting after Dokeos 1.6 July 2005 was cancelled, a first meeting about CMS was planned to be held on 6th of July, 10h. Location: BME building Ghent, room 132. You can read the meeting minutes.

Goals of a CMS for Dokeos

A CMS for Dokeos has as first priority to improve education, not to become "the ultimate" CMS. Our focus is on education first.

Use cases and user stories

A use case is a description of a typical use of a software. Using use cases, we can more easily see what real-life functionality is wanted. A use case describes the working of a system from the users perspective. This way we can make sure there aren't too many steps needed to achieve real world goals. See also use cases and user stories.

What features do we need

  • Platform-wide use of metadata for all learning objects (IEEE LOM norm)
  • User role and permissions system
    • There should be multiple roles per user possible (owner, teacher, student, ...)
    • The owners of objects should be able to clearly define the permissions on their objects.
    • The owners of objects and spaces should be able to delegate their permissions to other roles, (selfmade) groups or individuals.
    • Possible access permissions should include
      • Owner
      • Members of the course
      • Members of the instititution
      • Teachers (e.g. for certain parts of the student portfolio)
      • Visitors (not authenticated)
    • Other permissions such as Modify and Delete should exist.
  • Support for different licenses: normal copyright, creative commons, GNU FDL, public domain.
  • Ease of use: uploading documents should by default not be more complex than with the current Dokeos interface. Of course metadata offers a lot of optional complexity that many people find very useful. Adjusting permissions should be intuitive.
  • Search: the ability to search all items stored in the CMS, and immediately reuse them if this is allowed. Context-sensitive searches should be easy to initiate, e.g. when I am in a course in the mathematics department, search only for documents that are used in other maths department courses and/or have been indicated as related to math.
  • Reusing content should be as easy as possible. This is supported by a clear interface, a good search function, and good metadata descriptions. Versioning of documents can be useful.
  • Versioning - dealing with multiple versions of the same learning object, and some ability to notify users of this LO that a new version is available.

How do we connect or integrate a CMS with Dokeos

Integrating an existing complete CMS with Dokeos is most probably too complex and not efficient. Dokeos can be extended from LMS to LCMS by adding the missing parts (we have already in development: metadata, search, roles, HoGent Dokeos repository, ...) Eventually Dokeos could be connected to Content Repositories. For the far future it would be ideal if Dokeos could talk to different Content Repositories simultaneously (internal repository and repositories from other institutions, library, publishers, ...) Standards for accessing such repositories are emerging right now (anno 2005). The first standard is JSR 170: Content Repository for JavaTM technology API. PHP Content Repository - phpCR tries to be a full PHP implementation of this JSR 170.

Another view on this is keeping the CMS and Dokeos seperate. This has also several advantages that shouldn't be looked over. Firstly it doesn't overcomplicate the existing Dokeoscode, as seen in the learning path, adding something even that trivial is not easy. Adding a repository makes Dokeos in the near future too complicated to manage and will slow down development. On the other hand a clear api to use a CMS in Dokeos would solve this, while still being able to use a CMS. If an institution decides not to use a cms, then this api can simply be changed to use the current db and filesystem method. I wouldn't call this method the far future as changing from the first method where the dokeoscode is invaded heavily to a modular system is almost impossible. It's much better to start modular. This way existing CMSes can be used (eventhough dokeos could for example only support one in the beginning), which allows institutions to change if they don't like the CMS. Not forcing them to use the one in Dokeos, which will scare people away.

Connection with existing tools

The Dokeos documents tool, for example, has been a tool that generated much discussion. There are very different views on it. It evolves in two ways that are perhaps not completely compatible: on the one hand, users see it as a presentation tool for the course material, so teachers want to organise it, giving items nice titles and descriptions. On the other hand, the document tool is also the gathering place for all document using tools, and becomes more like a repository that is like a big collection of all files used in the documents, groups, and other tools.

Using a CMS, this duality is solved easily: the documents tool becomes the presentation tool where teachers can present material to their users; the CMS itself is the repository where all learning objects are stored, all tools that show learning objects simply link to the object inside the repository.

Existing software

An evaluation of CMSes that can be connected with Dokeos. As a start, we should evaluate the CMS code from the Hogeschool Ghent internship. Their results and code are posted in the Dokeos forum.

Previous experience with CMSes

  • (Plone/Zope) From experience, we see that users appreciate the ability to insert html text fragments everywhere, and sort them, all ordered in a navigation menu (like the "left menu", the learning path left side...). Inline text is a learning object just like uploaded documents.

Forum discussion

See also

Retrieved from "http://www.dokeos.com/wiki/index.php/Content_management_system"
Personal tools