Valery Fremaux

Voilà, un tel article nous permettrait de lancer des "spécifications" d'évolutions de façon globale, de sorte à pouvoir réagir avec notre connaissance de groupe pour savoir si se lancer dans un développement (gros ou petit, ce n'est pas le problème) a du sens (nous ne connaissons pas tous le fonctionnement de toutes les versions et n'avons pas en tête tous les "diff" des évolutions en cours). Voici un exemple de problème que j'ai pragmatiquement aujourd'hui :

Dans les ateliers, les documents déposés par les membres d'un groupe (séparés ou visibles) ne sont visibles que par leur auteur. C'est la  même chose pour le module devoir (v < 1.7). Du coup, on ne peut pas remettre ni gérer de façon pratique un vrai "travail de groupe". Je n'ai pas encore été plus loin, mais je doute que la notation par les pairs permettent une mise à jour des notes de tout le groupe, à partir du moment où le rendu qui est évalué est attribué à un seul User.

Question 1 : Qu'en est-il en 1.7, avec les modifications du schéma de rôles ?

Question 2 : Une modification de ces modules, qui permettrait vraiment la gestion d'une production collective sur la base des groupes du cours, est-elle pertinente (elle l'est pour moi, c'est sûr, vu que la gestion des projets chez nous se fait comme ça). La modif suppose :

• Permettre à chaque élève de voir les documents déposés par les membres du groupe.
• Distribuer les documents entre groupes et non entre élèves, pour les évaluations par les pairs, ceci suppose simplement le changement du "point de vue" des interfaces d'évaluation.
• Répliquer les évaluations données par les pairs à tous les participants d'un groupe, collectivement "propriétaires" du rendu.
• Attribution collective de l'évaluation du prof aux membres du groupe et non plus un par un par recopie.
• Réplication des feedback à tous les membres du groupe. 

Question 3 : Si oui, est-ce que nous devrions prévoir une option spécifique pour que certains de ces groupes (plus dur à faire) continuent à être évalués et gérés par individus ?

Bonjour Hassan

Effectivement actuellement non. Je suis en cours d'étude de la question, car nous avons dans notre école pas mal d'activité sur le thème du transport de contenus pédagogiques entre différentes plates-formes de publication. Le fait est que Moodle sait exporter son contenu sous une forme XML, mais propriétaire. La scormisation d'un cours Moodle n'est évidemment pas impossible, mais pose pas mal de problèmes, notamment :

- tous les liens internes inter-documents doivent être transformés en liens relatifs indépedants de la stratégie php.

- les liens mis en place par l'enseignant directement dans le contenu doivent être réévalués.

- Les liens vers des ressources internes (fichiers, images, autres ressources "contenues" par Moodle nécessitent également un traitement d'extraction et d'autonomisation.

- tous les objets fortement interactifs du type quizz, leçon, devoir, atelier posent un problème de transcription : il faudrait leur trouver une technologie autonome qui rende le même service, et dont les objets seraient générés par les données que l'enseignant a mis dans Moodle. Je commence à travailler là dessus, mais vu le temps que j'ai...

Je dois aller voir ce que fait la communauté international de développement de Moodle, et je poserai la question également à Nicolas, qui suit de manière très aigüe la politique de dévelloppement.

Il ne reste pour l'instant qu'une extraction manuelle et une compilation SCORM avec un outil (pas top top pratique) comme RELOAD, une fois les ressources reformatées.

Voir ma réponse

http://moodle.org/mod/forum/discuss.php?d=62766&parent=297126

Si ça vous intéresse...

Pour ce qui est de l'opportunité d'un module, je ne sais pas : voir la discussion sur les critères pour décider de la fabrication d'un module

http://moodle.org/mod/forum/discuss.php?d=62766&parent=293280

Outre cette discussion, un module peut être utilisé pour piloter un dispositif plus général à partir d'un cours, mais celà pose plusieurs problèmes d'architecture.La construction de blocs dédiés (comme Daniel l'a fait avec son appel Skype) me semble un piste de départ pour une intégration simple de fonctions autonomes. Un bloc peut toujours connaître le contexte courant du cours "en cours" mais il fait également prévoir son fonctionnement hors contexte du cours (contexte général par exemple), ce qui rajoute des cas d'usage.

J'en en exemple le cas du "coursetracking" (voir discussion dans le forum développeurs) qui avait commencé initialement par un simple filtre et une modification de l'éditeur pour pouvoir marquer des balises dans le contenu. Ca a fini en module, avec une possibilité de gérer plusieurs "pistes d'enregistrement" indépendantes dans le contexte d'un même cours (via le module, c'est là où ça sert). Donc tout dépend de ce que vous voulez pouvoir faire.

Pour continuer cette discussion, je vous réitère mon invitation dans le forum développeurs.

Oui mais il est aussi exact qu'assurer une gestion contextuelle intégrée et cohérente par rapport aux possibilités de gestion interne de la plate-forme peut être un plus.

C'est ce type de réflexions que nous pouvons mener sur le nouveau "forum développeurs" en plus de l'aide à la conduite du développement et d'une réflexion sur l'opportunité fonctionnelle de telle ou telle intégration (ou telle ou telle "profondeur" d'intégration).

Moodlement vôtre.