Merci Julien de renvoyer à tous en effet. Pour voir où on en est.
- les idées de choses à tester ne manquent pas. - certains test sont plus accessibles que d'autres. Il faut pouvoir réaliser les observations, etc. - la méthodologie demande du travail. - La réalisation aussi - observer, créer les ressources à tester, trouver des groupes/enfants/parents qui voudraient bien soutenir un (des) tests, etc. En envoyant ma première proposition, je voulais savoir si ce groupe était intéressé par la possibilité de participer / d'aider à organiser un test de ce genre. J'ai deux oui (Julien, Martin), et personne ne s'est encore plaint, donc - je suppose que c'est possible en principe. Reste les détails: faire quoi, quand, avec qui, pourquoi. - je commence par pourquoi, histoire de vous motiver. Si vous voulez nourrir le progrès pédagogique en informatique, l'étudier est une bonne façon de faire. Pas la seule, on voit la diversité de nos approches, mais si on peut, c'en est une valable. - faire quoi. Je suis un adepte des méthodologies agiles. Appliquées ici, je dirais qu'il faut rechercher ce qui est faisable - les fruits à portée de la main d'abord. Si ça marche, alors on s'appuiera sur notre expérience pour faire mieux encore. Le test que j'ai proposé - sur la progressivité des exemples, façon poser la fusée - marcherait. Le dernier de Julien - beaucoup ou peu de commentaires - aussi, mais l'écrire va nous demander pas mal de recherche documentaire. - quand. Je veux être ambitieux, mais pas trop. Pour préparer le matèriel, trouver des volontaires, s'assurer que tous ont compris le protocole à appliquer, etc., étant donné que c'est la première fois, je dirais qu'il nous faut jusqu'en octobre. D'autre part, il serait bon de publier les résultats. Les comités de lecture prennent des mois; un exemple: la conférence (anglophone) sur l'éducation informatique, ITICSE, se tient en juin 2015 à Vilnius; ils faudrait leur soumettre le travail écrit vers février 2015 (et si le travail manque de qualité, on retarde la diffusion pour mieux l'écrire). Ce qui fait approximativement: préparer un test, 3 mois; le réaliser, 3 mois; finir d'écrire, 2 mois. Si un premier test réussit, on peut commencer d'en envisager d'autres sans attendre, mais il faut ne faudrait pas que la soif de connaissances ne cassent l'ambiance pour les enfants, donc - on verra. - qui. Il faut des animateurs de clubs prêts à présenter certaines activités dans un certain ordre. Le protocole que je vous ai proposé a l'avantage de donner à tous les enfants des ressources comparables, seul l'ordre change, donc on ne sacrifie pas les progrès (même hypothétiques) ni le plaisir des enfants. D'autre part, il faut préparer deux versions de deux exemples. Enfin, il faut établir la collection d'informations après et peut-être l'observation pendant. Le travail écrit pourrait nommer tous les participants (observateurs, animateurs etc.) comme co-auteurs. Ca me paraît bien vu la bonne ambiance de cette liste. Je crois que si on réussit ça, c'est déjà beaucoup, et que ce sera une très bonne base pour envisager d'autres questions. Charles Le 26 mai 2014 15:31, Julien Dorra <[email protected]> a écrit : > (Je pense que tu as envoyé en privé par erreur, je repasse sur la liste!) > > Oui, hypothèse falsifiable nécessaire, bien sur. Tu fais bien de le > rappeler. B-A BA de la science :-) > > Perso de mon côté au niveau test d'hypothèse falsifiable j'aimerai tester > immersion et compréhension d'un même code sans et avec commentaires très > détaillés et explicatifs. Est-ce que trop de commentaires perdent le novice > ? > > > Le 26 mai 2014 à 15:16, Charles Boisvert <[email protected]> a > écrit : > > Justement, je travaille sur l'enseignement de l'informatique a > l'université de Sheffield, c'est pour ça que je suis ici. > > Nous rapprocher d'équipe de recherche en science de l'éducation et >> science cognitives qui font déjà ce type de travail (et ont les >> méthodo scientifiques déjà standardisées) >> > > Concernant la méthodologie, c'est pour ça que je propose: > - de comparer deux versions de deux ressources, produites chaque fois sur > le même principe > - de tester les différentes versions en les inversant, ce qui demande > quatre essais > > Le point le plus faible de ce que je propose là reste les informations > collectées. Je suis en faveur de données extrêmement simples - durée de > travail, sondage à la sortie - parce que des informations précises > demandent des observateurs bien formés. Mais un observateur peut prendre > des notes ou même filmer un évènement (avec consentement) si le risque de > faire valoir ses préjugés est bien compris. > > Si vous connaissez des gens prêts à participer en collectant ces > observations, et déjà habitués, ça m'intéresse. > > > Peut-être que poser 2 ou 3 questions claires nous aiderait à faire ce > pont : > > 1. Texte versus Visuel ? > > 2. 7 ans versus 10 ans versus 13 ans ? > > 3. Bases d'abord versus immersion exploratoire ? > > … ???? > > La question claire que je vous propose, c'est de travailler sur ce > problème des ressources pas-à-pas, telles que je les ai définies avant ( = > productivités des solutions partielles et des erreurs). > > Les questions que tu poses, sauf peut-être la dernière, sont très > difficiles - elles paraissent claires, mais en réalité elles ne sont pas > falsifiables, c'est à dire que si les résultats obtenus ne sont pas ceux > souhaités, il suffit de déformer l'hypothèse. > > Par exemple, > > Texte versus Visuel ? > Si je fais un dessin en Python, est-ce visuel? Selon l'opinion de > l'expérimentateur, et les résultats, on dira "visuel", ou "pas visuel", ou > encore "ça dépend... S'il y a du vent..." > Donc l'hypothèse est trop "molle" pour qu'une expérience donne une réponse > définitive. Un bénévole convaincu trouvera toujours une raison de continuer > à travailler à sa façon. > > Par comparaison, la question > > La nouvelle version de la fusée sert à quelque chose, parce qu'elle > > montre des états du programme simples à comprendre et à réaliser, mais > qui permettent le progrès vers la suite. > > Reproduite sur le même principe avec deux autres jeux, l'hypothèse est > simple à tester, mais surtout le résultat laisse peu de place au doute: > soit il faudra écrire nos tutoriels en s'appuyant sur cette définition de > "progressif", soit je dois sèrieusement repenser ma compréhension de > l'apprentissage. > > C. > >
_______________________________________________ Discussion mailing list [email protected] http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
