Developer meeting February 28 2005 summary

From Dokeos

Jump to: navigation, search

Monday, February 28th, 2005 - 10:00 AM, Brussels

Arteveldehogeschool: Frederik

Dokeos company: Thomas D, Denes, Olivier B, Yannick, Laurent Dobritch, Vincent Buys

Ghent University: Bert, Patrick, Thomas B, Ren�

Hogeschool Gent: Bart, Michel, Sandra, Stefaan

Vrije Universiteit Brussel: Roan

Contents

Important news and agreements

The release date for Dokeos version 1.6 has been pushed back.

The following release dates are final. What's not finished by that time, will not be in release 1.6.

May 1st, Dokeos 1.6 beta

The beta needs to be feature complete. When we release the beta, we will branch the CVS into a stable 1.6 branch, and an unstable development branch. After the beta there is a feature freeze on the stable branch, this means no new functionality can be added on that branch, only bugfixes and translation improvements. This gives us one month of testing and bugfixing, in this phase we want to gather as much feedback as possible from users. This is also the time to go through our bug lists (bug forums, bugzilla bug tracker, reports from users)

Feature freeze also means there must not be any database changes between the beta and stable release. The upgrade from Dokeos 1.5.4 and 1.5.5 to Dokeos 1.6 should be working in the beta.

Reminder: we should also release code packages on sourceforge and freshmeat, the two main repositories for free and open source software.

June 1st, Dokeos 1.6 stable

We release the Dokeos 1.6 stable to the public this day. This means the packaging should be done earlier (no 11:59 PM releases ;-)

CVS and branching

After the branching, the Dokeos 1.6 branch can be used for bugfixing of that release. June 1st we will release the stable version from that branch and also mark (tag) the code. Afterwards we can continue working on this branch to deliver stable bugfix releases 1.6.1, 1.6.2 ...

Simultaneously the unstable, development branch will be used for all our new development work. When we have branched off the beta of 1.6 you can continue to use this branch during the beta period to commit risky or unfinished new developments.

Thomas B. has more info on branching somewhere, should look it up

Topics

Security

We will clean up code to eliminate the use of global variables. In the end we want to get rid of the register_globals and all code that imitates this, like there is now in the claro_init_global.inc.php.

We will use the data filtering of the kses tool (which is also GNU GPL) to filter user input. For consistency, we will always show the htmlarea when html input is allowed, and no htmlarea when it is not allowed. Even when it is allowed, we will not allow everything. As a general rule, we will not allow html in titles (agenda title, lmink title, announcement title...) but we will allow html in the descriptions /comments of an item. We plan not to allow adding javascript in descriptions, but do allow it in uploaded documents.

At the meeting, Ren� was asked to check JavaScript in metadata. Here's his after-the-meeting feedback: Where Metadata requires JavaScript, it is either (1) predefined, see e.g. md_script.js, or (2) generated from a course-manager-uploaded XML-file (keywords cache), or (3) (in the as yet unsupported importmanifest.php), in a course-manager-uploaded html template file.

For consistency, we will never allow anonymous users to upload anything. This is IIRC currently possible in the student publications tool, that has to go.

Groups refactoring

The group tool in the platform admin section will be removed, it is not necessary there at the moment and we eliminate some confusion and a button. forum topic

Which tools will we make group based? The forum and documents are already like this, the announcements and agenda will follow. Adding a wiki was mentioned, but nothing has been decided, you can discuss on the forum topic about wiki. Making the links group based: perhaps later, but no decision was taken.

Chat tool

PHP is not very good for a chat tool. We could replace the chat tool by e.g. a flash one. We will keep the requirements of the normal Dokeos release low, we will not require people to have flash plugins installed. Flash is also not an open standard. A chat tool using flash, java, ... can be developed, but only as a plugin for Dokeos, by default we keep the basic php chat.

Math: LaTeX and gif rendering

Dokeos allows TeX input, this language often used for mathematical expressions can be displayed in two ways: by displaying TeX input and (client side) rendering it with the TeX Explorer browser plugin, or by doing a server side method to convert the TeX code to gif image files (with mimeTeX, see http://www.forkosh.com/mimetex.html ). With a javascrtipt check, we will test for the availability of the plugin, if it's present we will use the plugin, else we will create gif images. When javascript is not activated we will use the gif method.

TeX only in HTMLArea, not TeX docs.

Session problems

Olivier Brouckaert has developed a mechanism to work around a problem when php crashes with a very large number (10 000) of sessions. By default this mechanism is not active, and sessions will continue to use the default php management.

Patrick will check for some beta code where form data was saved in a temp table just before the session expired. When logging in again the user would be presented with the question wether or not he wants to continue that work.

Apache mod_rewrite versus AcceptPathInfo

We will use mod_rewrite instead of AcceptPathInfo.

This is used for guaranteeing both userfriendliness and security to users with an Apache webserver. The URL will show the "real" path to a document, e.g. COURSE001/document/info.html but Apache will rewrite it so we can check permissions and do other stuff.

We will create an .htaccess file with instructions for Apache. We could store this inside every course document folder but to make things more flexible we will create only one .htaccess file in the main dokeos directory.

The only drawback is that people without Apache cannot have this combination of userfriendliness and security.

Motivation for mod_rewrite vs. AcceptPathInfo: 1) functionality of both is equally good; 2) mod_rewrite is not PHP-dependant 3) mod_rewrite supposedly also exists in IIS

Bugs noticed during FOSDEM, Dokeos developer room

  • There is one urlencode too many in the documents tool, when showing an html document you get file=%2Fblabla instead of file=/blabla
  • Usability: in some forms the last name comes first, followed by the first name. We should put the first name first and the last name second.
  • ...

Language translation tool

This tool is now active on the Dokeos website.

  • We will need to promote this tool on the dokeos website, to attract translators.
  • At least once a month, we will add the new translations to the CVS

Resource linker

The 'Add resource' button will be renamed to 'Attachments'.

Search

In the development of a search tool for Dokeos, the following points appear as important.

It is important that actions be buttons (crawlers - like Google - ignore them). Several crawlers could cause non-innocent actions such as e.g. delete (crawlers, while following the link, might provoke the action), although this seems to be avoided by some sort of check whether the command has been issued from a browser of from an automated program.

Also, links will be changed to add the course ID in it, while in the course. This will look like this: http://www.mydokeos.com/claroline/course_home/course_home.php?cidReq=JAP101 instead of http://www.mydokeos.com/claroline/course_home/course_home.php The change is meant to allow any website crawler to display a link to the course, for someone to click on it and get into this course. This was not possible before as the cidReq (the course ID) was kept in the session.

UI Plugins

UI plugins are bits of codes, not altering Dokeos code, that can be displayed in the banner or the main menu, or anywhere else after several code changes.

The idea is to hold a $plugin array in clar_main.conf.php and several checks for this array in claro_init_banner.inc.php and index.php (and maybe in other files).

The $plugin array would look like this in the claro_main.conf.php: 

$plugin['main_menu'] = array();
$plugin['banner'] = array();

Adding a plugin in the main menu would be done like this: 

$plugin['main_menu'][] = 'my_plugin';

And in the 'claroline/plugin' directory, you should put the 'my_plugin' directory (with index.php in it).

Then in the index.php code, we could find something like this just before the home_note.html inclusion 

foreach($plugin['main_menu'] as $this_plugin){
  include('claroline/plugin/'.$this_plugin.'/index.php');
}

The same goes for claro_init_banner.inc.php.

These code changes will be implemented real soon in the Dokeos code for banner and main_menu sections.

User interface

  • We discuss on the place of the OK button for forms. The general rule is that it shoud be at an edge, Thomas DP prefers the left side: there's a usability theory that advises right, but on the web your rightmost stuff is often hidden, like in a forum when a messageline gets too long. The place can easily be edited using stylesheets, but we need a good default.
  • The add resource button - renamed attachments - in forms looks bigger than an OK button, so many people inadvertently click on it. Therefore, it should be at an edge opposing the OK button.
  • Feedback messages should always appear on the tool page itself, not on a different page.
  • The upload section of the documents tool is moved to a separate page to avoid interface clutter.
  • When adding a new item in a tool, the list of current items (documents, agenda items...) should not be displayed.
  • Present an upload form with the same code (with parameters), this removes code duplication and improves interfce consistency: document tool upload, group document tool upload ...
  • In the breadcrumbs (campus > COURSE001 > documents), we will replace the course code by something a bit friendlier to users, current proposal is 'current course': (campus > current course > documents)
  • We will not display a cancel button in forms. It is almost never used, takes up screen space and causes confusion with the OK button.
  • The orange background of messages will disappear (technical tip: use Display::display_normal_message for this).
  • The next / previous buttons of the learning path will remain somewhere in the tool, not in the header
  • We will get rid of those useless colons (:) after every field title in a form. Just whitespace to separate them.


The header

The header takes up a lot of lines. The tool shortcuts will be set to off by default, this can be adjusted in the new web adjustable admin settings. The help link and buoy icon will move to be placed on the same line as the tool title, to the right of it.


Exercise tool

The exercise tool looks somewhat 'disjointed and analytical', not offering a compelling user interface. One of the big problems is the tool does not make enough difference between a test (a series of questions) and a question. Another big problem is that the tool does separete the question part of the question rom the answers, which creates a confusing interface. There is no word for the question-part-of-the-question, so editing a question' means ???

Some of the test - question confusion was created through translation: from french to english to dutch and back, by dutch and french native speakers.

Possible solutions, we should try them to see wether this does improve matters:

  • make more clearly the distinction between tests and questions
  • editing a question means editing everything: the question text and the question type and the answers and feedback.

Test code

Developer discussion: if people have scripts with code tests and examples, should we store this in the CVS or not? Should this test code be e.g. a subfolder of a package (like the existing dokeos.metadata.doc), or a separate dokeos.test package? No agreement was reached.

Virtual course support

Will we further develop Virtual course support for next release? When this feature becomes more mature, universities can switch to this instead of everyone using their own mechanism. However, there's only one overworked developer on this so it will be usable but not perfect.

What we want in the future is the combination of this with a much more mature support for classes in Dokeos. The current classes (platform admin tool) are very simple.

Course visibility

Change to Dokeos 1.6 stable approved: we will add two extra fields to the course table because the visibility field now hides two settings: visibility and registration. We will add a subscribe and an unsubscribe field, and add at least one more option to the visibility: instead of open and closed, make this more clear: open to the world, open to the users of the platform, closed.

Backup/Copy/Restore tool

(forum):

  • What should be the name of this tool? We decided to split into two tools with two icons on the course homepage, in the course admin section: backup/restore and recycle/copy
  • The old, very buggy backup and restore functionality will be deleted.

Release dates

Lot of discussion about the release dates. Arguments for pushing it back were mainly to allow Bert to finish several important aspects of the document tool refactoring and to allow Patrick to check in more of his finished-but-not-in-CVS developments. And for keeping it at the original date (release in April): you can never know when some big refactoring is ready, if you delay there will just be more tools created that 'have' to be there, we should release more often and then just release what's ready at the time. Releasing more often means more users will test and give feedback and use a better Dokeos. In the end we agreed to push the date back, to May 1st for the beta release and June 1st for the stable release. However, beta means: feature complete, including the upgrade script.

To do

  • Everyone
    • add their developments to the CVS, help debugging, testing and cleaning
  • Olivier B
    • give CVS admin rights to Thomas Berton
    • have the upgrade script working in the 1.6 beta
  • Roan
    • release dokeos 1.6 beta and stable at sourceforge and freshmeat
  • Thomas B
    • manage the necessary tagging and branching for Dokeos 1.6 beta, stable
  • Bert
    • produce an estimate of how long the document tool refactoring will take
  • Yannick
    • post-1.6, make an everything-in-UTF-8 branch

...

The pizza's were delicious. Thanks, Thomas!

Ceterum censeo Carthaginem esse delendam

Things we did not discuss

Update: we have now decided not to use css styling for the buttons, instead using the default of the browser and OS.
  • Concerning Security / data filtering / we will not allow html in titles (see above): HTML-entities of the form &...; should be allowed to make sure that titles in other than plain English can be rendered correctly (discussion on train back to Ghent, Ren�)
Retrieved from "http://www.dokeos.com/wiki/index.php/Developer_meeting_February_28_2005_summary"
Personal tools