Outils pour utilisateurs

Outils du site


microalg:feedback_apprenant

Feedback Apprenant

Le retour d’information figure parmi les quatre piliers de l’apprentissage selon Stanislas Dehaene (voir ici et ). Il est donc important que MicroAlg puisse fournir ce retour à l’apprenant du mieux possible, tant sur le fond que sur la forme.

Vecteurs de feedback

Parenthèses colorées

Au départ vu comme une petite amélioration cosmétique, les parenthèses se sont révélées être une formidable aide à la syntaxe.

Elle donnent un retour instantané concernant la structure de chaque instruction, et plus globalement, du programme.

Messages d’erreur

C’est pour l’instant un des points faibles de MicroAlg (documenté dans les limitations) :

  • numéros de lignes :
    • pas de numéro de ligne (dans les versions Javascript) ;
    • numéro de ligne pointant vers l’expression la plus extérieure (dans les autres versions) ;
  • messages pas forcément en français ;
  • messages en français, mais pas forcément très clairs.

Ils peuvent concerner :

  • une mauvaise syntaxe,
  • une mauvaise utilisation de mots-clefs intermédiaires,
  • une mauvaise gestion des types,
  • un nombre trop grand d’itérations,

Messages explicatifs

L’algorithme de l’apprenant peut s’exécuter sans erreur, sans pour autant répondre au problème. C’est ici que le retour d’information est délicat à fournir.

En complément, voir le travail sur la PLM (.pdf) et le dépôt concerné.

Base de données d’explications

Imaginons une base de données contenant des entrées de la forme :

  • identifiant de l’exercice
  • données pour identifier une erreur possible à cet exercice
  • message explicatif à donner

Raffinements prévus :

  • notation du message d’erreur pour faire émerger le meilleur message

Algorithmes en jeu

Il y en a au moins un à mettre en place : celui qui va associer un algo fautif dans la base de données à l’algo que l’apprenant a tenté. Il « suffit » de comparer des arbres.

Sauf que comparer des arbres n’est pas trivial. Parmi les idées ci-dessous, certaines contribuent à imaginer une forme « normalisée » des algos.

Tests unitaires

Grâce aux commandes Exemples_de et Tester, il est facile de spécifier des paires entrée/sortie qu’une commande doit respecter. Il est cependant nécessaire de travailler avec Definir. La différence entre les valeurs attendues et finalement fournies peut aider à établir un diagnostic.

Pour feinter l’ennemi, on pourrait ajouter des paires entrée/sortie mystères pour éviter que l’apprenant ne hardcode ces sorties dans son programme.

Commutativité

(+ a b) ne devra pas être différencié de (+ b a). Pour normaliser, on peut penser à trier les arguments des commandes commutatives dans l’ordre alphabétique.

Noms des variables

Les variables pourraient être renommées afin de ne pas différencier les algorithmes identiques sinon. Voir le travail avec OverCode.

Schéma et graphe de structure

Voir les références dans le papier sur OverCode (control flow graph).

Distance de modification entre arbres

Ou edit distance.

Contributions à la base de données

On pourrait imaginer que les algos fautifs ne trouvant pas d’algo assez similaire dans la base de donnée soient remontés, éventuellement directement avec un message d’erreur (si un enseignant est sur place), ou en attente de message d’erreur a posteriori.

On pourrait imaginer que la pertinence du message de remédiation soit évaluée,

  • avec une notation des messages par les apprenants au moment de l’affichage du message,
  • avec l'analyse des tentatives juste suivantes,

…ou une combinaison de ces moyens.

Conclusion

Il y a du pain sur la planche.

microalg/feedback_apprenant.txt · Dernière modification: 2015/08/28 09:06 (modification externe)