Martin dit de sa fusée: > on avait envie d'en faire une ressource progressive qui explique > les étapes de fabrication du jeu
Julien: > Les ressources progressive (tutoriels, pas à pas, jeux de code, série > d'exercices) masquent souvent le but final, et d'obtenir longtemps des > résultats simple ou très similaires les uns des autres. > Parfois elles n'ont pas de but réels, juste "apprendre des notions", > et du coup ont les transforment en exercices / casse tête sans > motivation autre que "passer à l'étape suivante". L'idée des ressources progressives m'intéresse depuis longtemps. Avant toute chose, pour ne pas vous faire perdre votre temps, les fichiers attachés à ce message sont une version du jeu plus facile à développer progressivement. Regardez cet exemple de la fusée pour un avoir sous les yeux ce que progressif peut vouloir dire. Maintenant la notion de progression dans le développement et son apprentissage. Elle m'intéresse depuis longtemps. Partant d'une idée assez naïve que le développement par essai et erreurs a quelque chose de "naturel" et donc va être "bon" dans nos méthodes d'enseignement, j'ai fini par en venir à une définition plus claire, et restreinte, de ce qu'une situation "progressive" veut dire. On présente à l'élève un cas où: - la solution ne va pas de soi - les solutions partielles sont productives, c. à d. qu'elles permettent un progrès vers une solution plus complète - les solutions erronées, ou partiellement erronées, sont productives également. La version de la fusée utilise cette idée - je fais usage du parallélisme de Scratch pour que chaque élément du jeu puisse être développé et testé indépendamment des autres: initialisation, mouvement, gravité, interaction, et conditions de fin. Reste deux questions sur lesquelles je travaille. Le pire dans les ressources progressives à mon avis, c'est la longueur du développement. Il faut lire et lire encore, taper trois versions du même programme voire plus, tout ça pour faire la version que la version 1 ne marche pas du tout, la deux est limitée, la trois a un bug imprévu... C'est en partie un problème de notation - la résolution d'une équation est progressive et peut être enseignée ainsi, parce que des notations existent qui permettent d'écrire de façon compacte, sur souvent une seule ligne, le problème entier. Un algorithme est plus étendu. C'est aussi un problème de visualisation d'un développement qui évolue dans le temps. Sur mon site, j'utilise l'animation pour tenter de résoudre le problème, exemple (en anglais): http://www.boisvert.me.uk/run/elcid.html?file=users/charles/is_it_sorted.xml Je comprend Julien qui trouve que la présentation pas-à-pas est souvent assignée après coup, qu'elle > Jeanne semble s'être bien à amusé à recopier. En ce moment elle aime > beaucoup écrire, faire des livres, et je ne pense pas qu'elle voit le > fait de recopier comme nécessairement une tâche ingrate. > > Ce qui l'a le plus frustrée au départ c'est d'aller retrouver tel ou > tel bloc dans la liste, mais j'ai l'impression que une fois qu'elle > les avait repérés la recopie du code devenait un travail très "flow". > Et assez court pour être content d'avoir fini avant de se lasser. > > > (On aurait besoin de chercheurs pour observer et noter les réactions > des enfants ! Je suis sérieux !) > > > Alors on avait envie d'en faire une ressource progressive qui explique > > les étapes de fabrication du jeu, au moins. à la codeclub, mais j'en > > ai déjà parlé. > > > > Je suis biaisé : je n'ai jamais réussi à apprendre quoi que ce soit de > manière "tutorial" ou "série d'exercices". (Je pense que j'apprends > plus de manière holistique, plein de morceaux qui se mettent en place > pour former le tout) > Je soupçonne que les sachant construisent ce type de ressource pour > faire faire un chemin de compréhension aux apprenants, du simple au > complexe qui n'est pas nécessairement celui qu'eux même ont pris. > > Dans l'approche expérientiel des maths, j'ai retenu cette formule : > "Au lieu de faire faire aux enfants des maths simples et dures, > faisons leurs faire des maths complexes et faciles" (en considérant > que en math il y a plein de phénomènes complexes simple à comprendre > et tester). C'est une direction intéressante. > > > > Ma question est la suivante : est ce que Jeanne a eu envie de modifier > > ce qu'elle venait de fabriquer après ? Si oui, victory pour nous. > > Si non, est-ce peut-être parce que taper tout ce code l'a gavé et ca > > aurait été mieux si on lui donnait le code tout fait ? Ou alors pour > > quelle raison ? > > On était vers la fin du goûter et elle avait envie de faire autre > chose (dessiner, jouer avec les chaises !). > > Elle a pris trèèès longtemps, au début les dessins, puis ensuite elle > était très peu concentrée puis elle a accéléré, en mode flow / > concentration et fini vite à la fin. Les goûter durent 3 à 4 heures et > pour Jeanne c'est bien car elle peut faire les choses à son rythme et > sans être forcée de se concentrer quand elle n'y arrive pas. > > Du côté des améliorations, elle m'a dit ce matin que si elle devait > modifier une chose la prochaine fois, elle "ajouterai la vitesse pour > savoir si on perd ou si on gagne" ! > Donc ça lui a donné des idées de pistes d'amélioration, et ça c'est > intéressant bien sur. > > C'est le phénomène que l'on a utilisé dans nos cours "hello world des > apps" avec de grand débutant de 19 ans. (Des programmes waouh! mais > qui appellent la modification) > > Julien > > > > > >> On Tue, Apr 08, 2014 at 09:42:00PM +0200, Julien Dorra wrote: > >> Hello à tous, et hello à Martin en particulier, > >> > >> Jeanne (8 ans) à utilisé "Poser la fusée" en version papier dimanche au > >> Coding Goûter. Occasion aussi de tester Snap (préalablement téléchargé > en > >> local depuis github). > >> > >> Elle a voulu dessiner des costumes pour les sprites qui ressemblent le > plus > >> possible aux dessins de la feuille ! > >> > >> Le nom des costumes n'est pas le même dans le listing et sur la > >> présentation et c'est un petit piège qui pourrait être corrigé (par moi > >> d'ailleurs si je prends le temps !) > >> > >> Pour gagner il faut taper vraiment super rapidement sur la touche > flèche, > >> et au début on avait du mal à voir si l'appui sur la touche marchait ou > >> pas. On a pas eu le temps de se pencher sur des valeurs pour rendre le > jeu > >> plus facile. > >> > >> Voilà, c'était la première fois en 2 ans de Coding Goûter que Jeanne > >> suivait / recopiait un modèle, mais c'est aussi une des fois où elle a > le > >> plus avancée toute seule (on a commencé ensemble, plutôt dissipées, et > elle > >> a fini toute seule, en mode très concentrée). > >> > >> Je pense que le fait d'avoir explorée Scratch/Snap de manière plus > >> baladeuse a préparé le terrain pour lui donner envie de "copier le > listing" > >> pour voir le résultat. > >> > >> > >> Merci ! > >> > >> Julien > > > >> _______________________________________________ > >> Discussion mailing list > >> [email protected] > >> http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion > > > > > > -- > > Once we were designed intelligently, now we have digressed to random > > idiocrity. -- darwin awards web site > > _______________________________________________ > > Discussion mailing list > > [email protected] > > http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion > _______________________________________________ > Discussion mailing list > [email protected] > http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion >
_______________________________________________ Discussion mailing list [email protected] http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
