From Dokeos

Contents 1 Participants 2 Meeting Minutes 2.1 Migration tool 2.2 Roles and Rights 2.3 Finetuning the administration tools 2.4 Statistics and tracking 2.5 AJAX implementation 2.6 LCMS TODO 2.7 Communication between Dokeos Company and the Community

Participants

1. Stefaan Vanbillemont (Hogeschool Gent)
2. Bart Mollet (Hogeschool Gent)
3. Michel Panckoucke (Hogeschool Gent)
4. Patrick Roth (University of Geneva)
5. Olivier Jeannin (University of Geneva)
6. Thijs Braem (Vrije Universiteit Brussel)
7. Olivier Sourie (Hogeschool West-Vlaanderen)
8. Jean-Marie Maes (Hogeschool Gent)
9. Hans De Bisschop (Erasmus Hogeschool Brussel)

Meeting Minutes

Migration tool

There are two internship students at Hogeschool Gent that will be working on the first implementation of the migration tool beginning February 2008 until May 2008. We ask some input about the procedure and the expected difficulties.

What is the starting point for the migration tool? Dokeos 1.8.x? Or should we develop also another migration route starting from 1.6.x? The question is: can we force users to first upgrade their platform to the latest 1.8.x version before they can migrate to the LCMS?

When we look at the installed platforms in the Dokeos Dev Team we see that Dokeos 1.8.4 and Dokeos 1.6.5 are the most often used. So we propose to develop the migration tool with a dual migration route: comming from 1.6.x and 1.8.5.

Next question is who does the migration? The platform administrator or each course administrator when she/he logs in? We think that the platform administrator is the right person to do so but we should implement a few tools to give the course administrators some possibilities to arrange his respository. If we don't let it migrate via the platform administrator we will have too many problems with created courses, publications, ..

What should be the 'result' of the migration? In the respository of each user he/she will see all the learning objects migrated from the old platform. The could be arranged in different views:

• a subfolder for each course
• a subfolder for each learning object type
• a subfolder for published/non published learning object
• arranged by date
• ...

There are many different views possible. We should implement some tools so users can decide themselves. What about some analysis tools/views so users can see all published objects, doubles or triples objects, ..

Another problem is the one about ownership of the learning objects in the LCMS platform. When you have serval course administrators in one course and the records in the item_property table are missing it can be a problem when you migrate to point out the new owner of the learning object. What solutions can be presented?

• we should first analyse if there is a real problem (are there records missing in item_property)
• if their is no owner for an learning object we can attach it to all course administrators/one selected administrator

The last problem that we see now is the missing implementation of some learning object types:

• learning path
• some question types
• wiki
• ...

Can those implementations be ready by the end of february/march? We will present all these decisions to the Dokeos company for their approval. More information on the migration tool can be found on this page

Roles and Rights

There is definitely need for a flexible roles and right system in Dokeos. We need a general framework that implements a R&R system and where each new application can attach its roles, rights and locations.

We did a first brainstorm at Hogeschool Gent about the technical implementation. But we don't have the manpower to implement it. Hans De Bisschop from Erasmus Hogeschool Brussels has already implemented a roles and right system in his own Skorpiuz CMS release. He wants to implement this system also in the LCMS project.

There are some technical issues that should be resolved before the actual implementation.

• the roles and right system is implemented using a tree structure
• the same rights can have different meanings on different locations
• the platform administrators should have to option to 'lock' rights for some locations so users cannot override them

We will present this solution to the Dokeos Company. More information about this brainstorm can be found on this page

Finetuning the administration tools

With the implemtation of the LCMS project with should also put some effort in more efficient administration tools. Now we have some overviews of users, courses and classes but no real exports/imports or advanced search options in the sortable tables.

We thought about extending the import/export possibilities so institutions who have limited manpowser or technical knowledge can use their back office to import users, courses, classes and their subscriptions to courses/classes.

Therefore we should extend all sortable tables in Dokeos to offer the possibility of advanced searching (eg. all inactive users, all courses that aren't visited anymore, ..) and exporting that information to well structured CSV files. Those CVS files can be used again to maintain the platform (unsubscribe users from courses, delete old courses, ...) If we extend those features in Dokeos new users have all features present to link Dokeos to their local back office.

More information about this topic can be found on this page

Statistics and tracking

We should plan some analysis on the 'statictics and tracking' now in Dokeos. We record a lot of information now in the stats tables. But do we need to show all that information to the end users? What does an end user want to see? What about the different view between a student/course administrator/platform administrator? What about the link between the shown information and the roles and right system?

We need statistics on different levels:

• course level
• admin level
• user(teacher/student) level

Patrick will ask his institution about their needs for statistics and tracking. All those needs will be put on the WIKI.

There is need for some admin swithes so we don't build a Big Brother system. The privacy of the users should be maintained all time. The next weeks we will plan an analysis of this topic! We will need a lot of feedback from the end users so we know what they want as statistics/tracking.

AJAX implementation

The university Of Geneva started with some AJAX implementations in the course management page and the document module. Scriptaculous and Prototype are the libraries used for the moment. No real progress for the moment. The code is available.

We look forward to see their next implementations.

LCMS TODO

Bart gives us an overview of the work that needs to be done for the LCMS project. Stefaan will list this on a new roadmap page using a wiki template for each topic. On that template we can put information about the analysis/brainstorm, development time, who will develop,

There are some priorities now:

• implementation of the missing LO types
• implementation of the roles and rights system
• implementation of the logging system
• further analysis of all those implementation

• Hans De Bisschop will implement the roles and right system
• The University Of Geneva will implement the missing forum implementations
• Hogeschool Gent will restructure the Dokeos wiki and add all missing LCMS pages
• Hans De Bisschop will write more information about the LCMS code structure

Communication between Dokeos Company and the Community

Stefaan organised a meeting with Yannick (company) in January. The goal is to smoothen the efforts of the community and Dokeos company. With more communcation between those two groups of developers we want to make sure the LCMS will succeed.

Next Dev Meeting: mid february 2008 (location unknown)