ERMI

01. Imaginer des progressions dans les équations “figurées” (balance, échange). Deux types: avec référence aux unités standard (une brique pèse …), sans références aux unités standard (AF, LOP 8.02.11).

02. Quid de télécharger les exercices (cf. pepit.be) (AF 8.02.11)

03. Ajouter parent.locReponse (au cas où elle est définie) dans suivi-nok.htm et suivi-nok.xml. Permet d'ajouter une nuance éventuelle au message d'erreur. (fait LOP130211 à tester)

04. Il y a des confusions entre les contextes nbReprise et remise. Dans le cas des exercices de type flash nbReprise a été pris comme étant le nombre d'exercices générés (dans le cas automatique), mais par contre c'est 'remise' qui reçoit 'perpete'. Proposition de rendre la nbReprise obsolète pour ce modèle et de prendre 'remise' avec les significations suivantes: 'sans' ou 'avec' présuppose des exercices préparés avec fct standard, 'perpete' ou un entier N génération automatique de N questions ou à l'infini.

05. A la base, l'idée était de favoriser l'approche document. Chaque document est indépendant, possède ces aides, etc. Avec l'introduction des dispositifs (défi, boucle, diagnostic et test adaptatif) des paquets d'activités deviennent solidaires. Cela implique pour les défis de cloner les activités et de leur ajouter les informations idoines (mode, poids, penalite, etc.) et de prévoir des enchaînements ad hoc. L'idée serait rendre les activités un peu plus indépendantes de leur environnement d'utilisation. Pour les défis, la chose faite (février-mars 2011) est de pouvoir utiliser une fin standard (formulaire, certificat) en introduisant une information sur la page d'introduction (de plus le suivi est engrangé dans une structure au niveau de la salle (salle.jx), voir cpi/cpi_cal_def0.xml).

06. itinerai/nu_def3.xml est une interaction originale (maquette) qui pourrait être instituée en modèle (utiliser des div avec insertion de HTML (innerHTML) plutôt que des zones de texte !).

07. A réfléchir à un moteur de recherche avec diverses sections (recherche dans lexique de partout, recherche d'une salle avec vocabulaire relativement libre, etc.) (rappel: il est prévu dans les attributs ceux de notions et de keywords).

08. Avec les possibilités offertes par javascript au niveau de la manipulation du document, il pourrait être possible de n'utiliser que le format qtml, d'utiliser les fonctions de salle.jx et d'ajouter des bibliothèques qui correspondraient à chacun des modèles.

09. En s'inspirant de dokuwiki, installer un plugin pour rendre les formules en latex (utiliser mathjax). (fait, voir Nouveautés 22 LOP160412)

10. On pourrait simplifier les structures des tables concernant les salles en n'utilisant que la clé (et non les séparations partie, floor, zone, salle utilsées avec prolog) (voir aussi conseil 04).

11. Lors de la réalisation de la base d'indexage (voir 07) des activités, il pourrait être utile d'ajouter le modèle utilisé.

12. Remarques enregistrées lors de la rencontre avec formateurs (novembre 2012, CPI, Fribourg): faire des exercices “recherche de dimension à partir de la donnée de l'aire”; modifier vocabulaire de “l'ontologie” (téléporteur → menu); introduire des icônes à la place des labels (fiche, exercice, etc.); faire une entrée sans nécessité d'inscription.

13. Voir la possibilité d'utilisation de la bibliothèque javascript Jquery (http://jquery.com/). Voir aussi http://en.wikipedia.org/wiki/List_of_JavaScript_libraries et http://javascriptlibraries.com/.