Developer meeting February 17th, 2004

From Dokeos

Dokeos developers meeting February 17th, 2004

Contents 1 Introduction 2 Dokeos versions 3 Assignments, Publications, Dropbox� 3.1 The original works / assignment tool 3.2 The new tool: drop box 4 Portfolio 5 Master Calendar 6 Community System 6.1 What is a Wiki? 7 Rich Text Editor 8 Table of contents 9 Learning Path, Resources 10 New Plugins 11 Accessibility 12 Language 13 Icon Packs 14 Forums 15 Documents 16 Course homepage 17 Chat 18 Coding conventions 19 Code file structure 20 To be researched 21 Refactoring

Introduction

If there are any suggestions or problems with the following report, please post at the Dokeos forum at http://www.dokeos.com/forum/. I have tried to keep records of the meeting, but it�s still possible that I missed some things, apologies in advance. The roadmap and developers manual will be updated as soon as possible. A log of the chat is also available.

We�re thinking of making the next dev meeting chat only, this put everyone on more equal footing and eliminates the 30 second delay for audio. Let us know what you think is best.

Dokeos versions

We regularly release new versions to the general public. The latest version is Dokeos 1.5 alpha2. In the last week of February 2004 we expect an alpha3 or a first beta release. We will take several weeks for fixing bugs and then release the official version 1.5 (at the end of February � begin March). Everyone has read access to the CVS (code repository) so everyone can get the latest code anytime they want, but these versions are not expected to be bug free.

Assignments, Publications, Dropbox�

The original works / assignments tool was often used as a tool for sending assignments to the teacher. But, every uploaded document was visible to the world by default. It was actually more like a �student publications� tool. There is a new tool in Dokeos (included in version 1.5 alpha2 and higher), the drop box (by Jan Bols). This tool keeps files invisible by default, and it is only meant for communication between a student and (one or more of) his teachers.

By adding this new tool (the drop box) there has to be a clear distinction between the two tools.

The original works / assignment tool

This tool is indeed more a publication tool where students can share interesting documents with other students and teachers. This is by no means a �homework hand-in� tool. It should be seen as a peer-to-peer tool for additional information.

The newly added feature that allows course managers to change the visibility of newly uploaded documents is added to allow course managers to review posted material before it can be viewed by the other students. It can be useful for censor to prevent unsuited material.

UGent suggest therefore to change the name of the original works / assignment tool to �Student publications�.

The new tool: drop box

This tool is really intended for handing in homework. In contrast to the original works / assignment tool, it does allow private document sharing and is thus suited for handing in homework.

The private document sharing is only allowed from the teacher to the student and vice versa, but not between students. Students can only send documents to and receive documents from the teacher.

Update: sharing bewteen students is now also possible, as an option (by default this is not activated).

Portfolio

There is much discussion about a portfolio tool; allowing everyone to have a webspace of their own where they could store and selectively publish documents. Some people are investigating this, in about a month we will hear more on this topic.

Master Calendar

In Dokeos, every user will have a personal agenda that shows all agenda items of all courses in a handy visual overview page. This code (by Eric Remy and Toon Van Hoecke) is not in the Dokeos 1.5 alpha2 but it has already been committed into the CVS.

Community System

Several possibilities are being developed or discussed for making Dokeos more like a community. The current Dokeos is mostly student-to-course, we would like to investigate student-to-student communication.

• A (link to a) list of currently logged in users at the bottom of every page in Dokeos. Clicking on a user brings you to a chat or
• Instant messaging tool.
• A Wiki

What is a Wiki?

This is a simple web based system for editing content in a collaborative way. Everyone can edit every page on a certain Wiki just by using his browser. Editing a Wiki page is easy: click on edit, you see an edit box with the text of the current page, edit the text, and click on save. For layout however you have to know the Wiki markup language, which resembles html and this is not something every user wants to learn.

There are many different wikis. The most famous one is Wikipedia (http://www.wikipedia.org/, http://wikipedia.sourceforge.net/), a free online encyclopedia written entirely by its users. There is also PhpWiki (http://phpwiki.sourceforge.net/phpwiki/), which is easy to install and can very quickly be integrated in Dokeos. Most Wikis are free software / opensource.

A Wiki that requires just Php and MySql can be integrated easily, but some chat / messaging tools require extra software libraries, which would make Dokeos harder to install. Editing a Wiki is very easy, but for more advanced markup you need to know the markup codes. However, some Wiki�s, e.g. Wikipedia has started to provide some buttons for organising, adding links, styling text� and perhaps integration with the Rich Text Editor is possible?

Rich Text Editor

Dokeos now includes a WYSIWYG html editor (the Rich Text Editor, by Kevin Roth). This will be activated in many places, but at some places it would be overkill, like when providing a simple comment on a document. In the announcements tool it will be active. However, many people object to html in emails, so for the emails the announcements tool sends we will strip the html from the text.

Update: Dokeos now uses HtmlArea as its wysisyg html editor

Table of contents

Formerly called �miniweb�, this tool (by Roan Embrechts) has been rethought. Now the module is better integrated with the documents tool. In the documents tool, you store documents; you can organise them (change order and divide into chapters) in the table of contents (TOC). If a TOC is defined, you always see it in a separate frame when viewing html documents, so you can navigate easily through courses.

Learning Path, Resources

Many people ask for personal learning paths. Example, in a certain course every user has a learning path to be completed in a certain order. First do some research (read texts, visit websites), then answer a question. If the answer is correct you go to one place, if it�s incorrect to some other place.

There is already a development (by Patrick Cool) that allows you to add resources (links, agenda items�) to another tool.

(Note by Patrick Cool: It is rather unlikely that this tool will be in dokeos 1.5. This development already works rather good, but the release schedule doesn�t allow me to do the hard needed cleaning up of this development)

And we also have the official standards (like SCORM Learning Objects) to keep in mind.

The Ghent University team will make an analysis of all these tools and try to design a good, coherent solution to people�s needs.

New Plugins

People ask for new features / plug-ins all the time. This is a good thing of course. However, some of these plugins require extra software to make it work: streaming video or audio, chat servers, java virtual machine� the more software, the more problems.

Accessibility

We will try to keep W3C accessibility guidelines in mind when writing software. The CMS Plone (plone.org) has good accessibility features, worth taking a look at.

Language

At the moment there is one default platform language; every course can also set its own language. People have requested the ability to choose the platform language per user as well.

Keeping the language files up to date is a problem. There are several factors here: the ease with which non-programmer users can create a first translation, update a translation� we could put everything in a database.

At the moment, Dokeos simply includes language files. Other options: we do the translations in a database, and generate language files form this database. Or we change Dokeos to get the language strings from a database. There were two database projects, which haven�t been completed the moment because of lack of time. CSS

We will start using CSS more often, expand the styles and try to use them in all new code.

Icon Packs

Many people, have different proposals about the icons for Dokeos. People from CESGA have modified the original icons and added colour, people from Ghent University have created a different set of icons (32x32 pixels and using colors)� We can make these available separately as an icon pack that Dokeos admins can just drop into the image folder to change the look.

Forums

Perhaps the option should be created to allow anonymous posts in the forums. A complete rewrite from scratch is proposed.

Note by Patrick Cool: I suggested this because it is certainly easier to start from scratch than to integrate an existing forum into Dokeos.

Documents

The documents tool needs some touching up:

• All documents should have an entry in a course table, regardless if the document is visible or not. This will shorten the code of the document tool drastically and opens a lot of possibilities (see the �add resource� development)
• Security: documents should not be accessible without being logged in (solved for LAMP by using htaccess files)
• The document tool should allow reordering just like the well known file-explorer on every OS. The following ordering should be possible: by filename, by date, by size. All of these should be possible ascending and descending.
• While we are at is, why not allow ordering by filetype (extension) (all files of the same type together) (by clicking the icon column)

Update: many of these things are done, and the document tool is receiving lots of attention now. The security option caused lots of problems, but we're busy switching to Apache URL rewrite rules now.

Course homepage

On the dokeos forum there was a huge thread about how the course homepage should look like.

There are three main views about this, each one has its own pros and cons

• Current view: hide inactive tools so that students only view the active tools
• Ordering: allow course managers to order the tools
• Grey icons: give each tool a fixed place and inactive tools become inclickable and grey

At UGent we are developing a course homepage that uses three colums and grey icons for inactive tools. Each column has its own orientation. The first column is for the resources that are provided by the course manager, this is teacher driven, the second column is for the resources that are student driven and the last column is more administration oriented.

We should introduce a configuration parameter that deals with the view of the course homepage. This should typically be a platform decision so that each course has the same view.

We suggest using $course_home_view to determine which file should be included in course_home.php

Chat

For chat as well as in the forums, allowing anonymous posts has disadvantages and advantages. Some students can perhaps start by using the tools anonymously, to overcome their fear of the new medium. And the teacher can play devil�s advocate�

After the voice chat there was still some discussion about conventions. Here�s what�s been decided so far.

Coding conventions

All the conventions are explained in detail in the developers manual, version 3.6 and upwards includes the new coding conventions. In general most conventions were agreed on unanimously, for some no agreement was reached and we had to resort to voting.

Furthermore we decided to use the proposed layer of abstraction between the kernel and tools layer for adding functions that provided access to global variables, instead of using the global variables themselves.

These global variables are preferable stored in arrays.

Code file structure

In the future we would like to have four separate folders: one for the code (e.g. called engine), and one each for the courses, archive and garbage. This would make the �root� Dokeos folder much cleaner, and it helps to put the right security on the right folder.

Update: It's not in Dokeos 1.5.4, but it's in the CVS and it will be in the next release: all courses are now stored inside a courses folder, making the root Dokeos folder look much cleaner. Finally.

To be researched

• A convention for dealing with magic quotes; register_globals and safe_mode.
• The use of Unicode.

Refactoring

If possible spend a week or two refactoring after the initial 1.5 release. The goal is

• Use more of the API functions to eliminate code duplication
• Divide more code into functions
• Clean up and document some �worst offenders� pieces of code.

Update: this turned out to be a seriously underestimated aspect. It takes more time and developers to get this right. We are finally going in the right direction however. The code is getting better, we're using more functions and more code libraries.

Original meeting summary by Roan Embrechts, Vrije Universiteit Brussel (at the time this meeting was held working for Ghent University)