Dokeos LCMS roadmap proposal

From Dokeos

This is a proposal, and it is not finished. It will be finished hopefully on September 1st. After that it will become an official proposal, before that it's just a text still being written; please regard it as such.

Update: this proposal is withdrawn. We have found a different compromise, and are working that out in a detailed design. Please keep this page around for a while, we might recycle some parts.

With important changes like a move towards LCMS, it is important that we try to get all developers to agree on some fundamental aspects. An LCMS is a very interesting project that will change the future of Dokeos but we must be aware of some possible dangers.

Some things to look out for

These concerns were raised on the developer meeting, we will answer them in this document.

• How do we make it task oriented
• What is the impact on the user interface
• How much development is needed
• What about reverse compatibility and upgrades
• Do we need additional software
• Can we make it simpler than e.g. Sakai / OSPI
• For the end user it should not be more difficult to add a document or a link than previously.
• We do not want a mixed situation (part CMS, part older native storage) like Blackboard.
• Can we have the next version of Dokeos with some CMS features already?
• We should put the spirit of CMS into every tool.

Goal

Our main goal for the first 2 years is to improve the LCMS capabilities of Dokeos. By improving the storage code, we will also move towards having a storage abstraction layer. It is however not the primary goal to have such an abstraction layer so it will probably not be complete and perfect the first 2 years.

The move towards more LCMS capabilities will give us much needed improvements, but we must make sure small installs (small schools, one database paid hosting) are still possible.

Storage

For every learning object in the CMS, metadata can be defined

A fundamental change is that we start seeing all content as owned by a user, not by a course. The user can use this content everywhere: in several courses, in a portfolio... this has implications for the storage structure, which is now based per course. Visually, people who visit a course will notice no difference: you see items in the different tools just like before, only they are stored differently.

Our storage will remain database-based and will not change towards being file-based. We will still store files in folders though, just like normal Dokeos does now. The xml metadata for learning objects will also be stored in the database.

We will provide an easy upgrade system, that converts the course-based storage to user-based storage. People should be able to upgrade from e.g. Dokeos 1.6.1 to Dokeos 2.0 LCMS like they would upgrade with other releases.

Quota are very important for this new system. Courses already had some primitive form of quota, we can improve this now. Not all users need to be allowed the same amount of storage, e.g. in universities and schools, the teachers might have more storage space than the students.

Improved quota management is also the way to keep small installs (schools, small single database on paid hosting) possible. Of course some organisations will disable the possibility of users to upload large documents or to start building extensive portfolios.

User interface

In the document module of a course, a link to add a document uses the CMS underneath

A user can now upload a document, add a link or agenda or ... item with just a few mouseclicks. This will stay the same. People who do not want to see the repository layer will not have to see it. If you just upload a document in a course, it will go in that course as before from the point of view of the user. Underneath it will be stored in the CMS and linked to in the course, but this process is entirely transparent.

As soon as the user wants to do something less basic, she will get additional options and see the extra LCMS interface. In current Dokeos, there is a view/edit metadata button, but nobody has to enter the metadata screen if they don't want to bother. If they change the title of a document, the metadata is updated without them noticing. This is a good design for most users.

If a user wants to set advanced access permissions, they will of course get additional interface screens for achieving this.

Impact on other developers

Some developers are not working on storage structure (e.g. people who work on layout of tools, adding features). We should try to disturb their work as little as possible. This is achieved through

• developing in a separate branch the first months until some level of stability is reached, ad then merging.
• providing a "Using the new LCMS capabilities" document to allow developers to profit from the new features (better search, easy reuse, setting of permissions, portfolio building...)

Roadmap possibility 1

The exact amount of time this takes is difficult to know beforehand. It might be done a lot sooner than 2 years. Currently the timing is more or less speculation; the first 6 months will provide more definite clues about this.

Months 1-6

• We work in a separate branch on the CVS to develop a stable storage structure before merging this with the main development.
• As soon as possible we start releasing installable versions that are probably unstable but will gather feedback from courageous early adopters. We release very often.
• We write the first upgrade script that lets people test the move towards a new storage
• There is already working code for the search tool
• We start a usability effort that gathers knowledge and feedback and designs a user interface that is as easy as possible
• first three or four tools moved over to new storage system (documents, links, ?)

Months 1-12

• After system is stable enough and at least 3 tools are converted to the new storage system, we start merging our changes with the normal Dokeos development. We should time this with Dokeos releases, e.g. two month before a stable release is not the ideal time to integrate.
• We gradually move all tools over towards the new storage architecture
• The system must be able to connect metadata to learning objects (IEEE LOM standard). The current Dokeos 1.6 documents tool already has this, and we also have code from the CMS project for the links already. This is very easy to extend to other learning objects.
• if possible, we can develop some task-driven "wizard" interfaces to help users get the most of their LCMS.
• we continue to release often. As soon as all core functionality is in place, we release an alpha.
• statistics and what's new must be made to work with new storage system

Months 13 - 18

• we focus efforts on bringing out a beta release with a hopefully-decent upgrade script

Months 18-24

• focus becomes bugfixing, further usability improvements, and perfecting the upgrade script. Unfinished features are rescheduled for later versions.
• succession of beta and release candidates will bring more user feedback that helps get the interface right and enhance stability
• first stable release
• production use possible

Months 24 - 30

• More stable releases follow, with bugfixing and small feature improvements.

Developers

• we hope to involve the whole Dokeos community to give feedback, report bugs, discuss user interface and feature aspects
• who can commit to the development
  • Hogeschool Gent: Bart Mollet (dev), Michel Panckoucke (dev)
  • Vrije Universiteit Brussel: Roan Embrechts (dev), Frederik Questier (dev), others: testing, features, usability
  • ...

Workflow research

We will research as part of the usability effort the different workflows different teachers have. Some teachers who don't use many advanced capabilities will work differently from teachers that almost add metadata to their learning objects, for example. We should be able to support many workflows confortable. To support this, some options can be added to the user profile page.

Other issues

• We want the content that users set to available for the entire world, to be indexable by search tools. How should this happen? (this can probably happen through the standard Dokeos web interface).

See also

• CMS meeting July 6th 2005 meeting minutes
• Content management system - this page is being written to contain detailed information about the features, future improvements, design and implementation of the first Dokeos CMS.
• The Dokeos forum - we now have a subsection devoted to discussions on CMS.