STIC:STIC III (2016)/Programming Boty

Introduction et problématique

Auteures: Lydie Boufflers et Sophie Linh Quang

Programming Boty

Dans la vie professionnelle comme dans la vie quotidienne, nous sommes de plus en plus entourés par les nouvelles technologies. Connaître les bases de l’algorithmique et de la programmation devient donc de plus en plus indispensable pour mieux comprendre ce domaine, être capable d’en résoudre les problèmes et garder un esprit critique vis-à-vis du pléthore de dispositifs qui nous sont proposés. La nécessité d'apprendre la logique basique de programmation aux novices est donc de plus en présente.

Nous sommes parties de ce constat pour imaginer Programming Boty inspiré du jeu Lightbot, inspiré à son tour du jeu en ligne Bill the Robot crée par un auteur anonyme. Ce dispositif propose une première approche simplifiée et ludique de la logique de programmation pour des novices. Basé sur la pédagogie de Maria Montessori, ce kit appartient à une catégorie d'objet d'apprentissage nommée “manipulation conceptuelle” (Zuckerman, 2006). Comme le stipule cet auteur, les artefacts de Montessori portent sur des concepts abstraits. Le principe est qu’en manipulant, les apprenants parviendront à «absorber» le concept par l'interaction physique. Dans le fonctionnement imaginé pour notre kit, nous avons placé au centre du dispositif le principe de l’Autonomie en y ajoutant une dimension d’Apprentissage collaboratif. De plus, utilisé dans le contexte scolaire, ce dispositif est plus économique que la version numérique dont il s'inspire, puisqu'il ne nécessite pas l'utilisation d'ordinateurs ("activité débranchée") et se dispense ainsi des éventuels problèmes techniques ou de dotation de matériel informatique qui s'y rattachent.

Dans cette page, nous détaillerons les étapes de construction du kit en commençant par l’exposition de la problématique et du cahier des charges. Nous présenterons ensuite notre solution (le kit a proprement parlé) ainsi que les tests utilisateurs réalisés.

Cahier des charges

Public(s) cible(s)

A l'origine, le public visé sont les enfants de 6 à 12 ans soit des élèves de degré primaire. L’enseignant, quant à lui, interviendrait pour expliquer les règles du jeu et gérer le niveau de difficultés (niveau 1, 2 ou 3).

Cependant, ce kit pourrait également être destiné à des adultes n’ayant aucune notion d’informatique comme les séniors, les étudiants débutant la programmation soit tous les novices en algorithmique et programmation. Un modérateur jouerait alors le rôle que l’enseignant occupe pour les élèves de degré primaire.

Périmètre

La question de l’apprentissage du code informatique est de plus omniprésente dans l’éducation. Il constitue une compétence transversale mais de plus en plus fondamentale avec l’évolution des nouvelles technologies de l’information et de la communication. A l'échelle du monde et en premier lieu dans les pays dits développés, le code va donc devenir de plus en plus présent. Aussi, la première cible pour ce kit sont donc les pays dits industrialisés et, dans un proche avenir, les pays dits en voie de développement.

Objectifs du kit

Objectif de conception

Programming Boty est un kit de construction destiné à proposer une initiation à la programmation informatique afin d'initier à la pensée / la logique informatique. Il ne s'agit donc pas de proposer un cours d'informatique à destination de futurs professionnels.

Objectif pédagogique

A l'issue de l'apprentissage avec ce kit, les apprenants seront capables d’utiliser les principes de base de la programmation et de l'algorithmique en manipulant des instructions et des procédures.

Description fonctionnelle du projet

Il s’agit ici de décrire les exigences et les contraintes associées à la conception de ce kit

Exigences et contraintes du kit de construction

Exigences	Contraintes
Pédagogie active, Apprentissage par découverte	Technique : kit en noir et blanc, réalisation des dessins en SVG sur Inkscape
Apporter une dimension dimension collaborative, une dynamique de groupe	Organisationnelle : jeu compatible avec un enseignement en classe
Favoriser l'autonomie de l'apprentissage (voir Pédagogie Montessori)	Conceptuelle : jeu accessible aux novices du code informatique, jeu adaptable à plusieurs profils d'individus (enfants, séniors...)
Kit réalisable avec une graveuse / découpeuse laser

Livrable attendu

Un kit constructif adapté à l’apprentissage du code informatique en classe (élèves de 6-12 ans, notre cible primaire) comportant les bases de la programmation et de l'algorithmique. Pour qu'il puisse être mis en place en classe, il est nécessaire que l’enseignant puisse réaliser plusieurs groupes d’élèves qui doivent apprendre en autonomie et en collaborant. En effet, matériellement, ce dernier n’aura pas le temps de s’occuper de tous les groupes et pédagogiquement, cela favorise la pédagogie active que nous souhaitons mettre en place à travers ce kit.

En outre, ce kit doit aussi pouvoir être proposé à d’autres profils d’individus comme les séniors, les étudiants débutant le code informatique par exemple. Il ne doit donc pas être trop infantilisant ni trop simpliste.

Délai de réalisation

Remise finale du projet le Jeudi 02 Février 2017.

Solution

Description du jeu et matériel

Le kit est composé de :

• Un plateau de jeu,
• Boty, le robot à déplacer,
• Des “jetons de déplacements” pour programmer les mouvements Boty sur le plateau,
• Des “outils” (pièces mécaniques) que Boty doit ramasser au cours de son parcours,
• De “supports principaux” pour la disposition des différentes instructions (i.e jetons de déplacements) permettant de mouvoir Boty,
• De “support procédures” pour la conception des procédures par les joueurs (niveau 2 et 3),

NB : Pour plus d’informations concernant le matériel, se reporter à la section Prototype papier.

Le jeu se joue en relative autonomie; l’enseignant/modérateur intervient dans le ‘mode practice’ pour expliquer les règles du jeu et gérer le niveau de difficultés (niveau 1, 2 ou 3).

Objectif et règles du jeu

L’objectif est de programmer les déplacements du robot afin que ce dernier aille ramasser toutes les pièces mécaniques disposées sur le plateau.

Avant de commencer, le robot et les pièces mécaniques sont placés sur le plateau. Pour cela, des maps de positionnements sont à disposition selon différents degrés d'expertises que l’enseignant / modérateur introduit petit à petit:

• Dans un premier temps, des déplacements simples en n’utilisant que le support principal (niveau 1)
• Puis introduction de la procédure 1 (niveau 2),
• Et enfin l'utilisation des deux procédures à la fois (niveau 3).

La difficulté du jeu augmente donc avec le nombre des pièces disposées sur le plateau et le nombre limité de pièces de déplacements pouvant être positionnées sur le support principal (d’où la nécessité pour les joueurs de recourir aux supports procédures pour pouvoir résoudre l’énigme).

Le jeu se déroule en deux étapes:

1. Phase de réflexion : les joueurs réfléchissent à une solution et placent les jetons de déplacement sur leurs supports pour organiser leur solution (support principal et supports procédures);
2. Phase d’action : les joueurs tentent de résoudre l’énigme en déplaçant le robot selon leur programmation. Par exemple, on peut imaginer que l’un lit le code pendant que l’autre met le robot en mouvement par exemple. Peut-être aussi l’enseignant peut entrer en jeu à ce moment là, pour vérifier qu’ils exécutent correctement les déplacements.

A cette étape, soit la programmation est réussie (le robot a réussi à ramasser toutes les pièces), soit la programmation comporte encore des erreurs. Dans ce dernier cas, les joueurs reprennent l’étape de réflexion, et ainsi de suite jusqu’à ce qu’ils trouvent une solution.

Afin de d'expliciter les règles aux joueurs, une documentation explicative du jeu et de ses règles est disponible sous Programming Boty _ Règles du jeu

Fonctionnement du kit

Nous avons imaginé un fonctionnement selon deux “modes” afin que le jeu se prolonge au delà de l’apprentissage de concepts :

• Mode practice

Le mode “practice” correspond à la phase d’apprentissage des concepts de programmation. L'apprenant est seul ou en groupe (de 2 à 5 joueurs). En groupe, ils doivent réfléchir collectivement à la combinaison de instructions la plus efficace possible afin que le robot puisse atteindre son but en utilisant un minimum de instructions. Pour cela, ils doivent échanger et se mettre d’accord sur la procédure en classant les éléments sur le support mais sans pouvoir toucher physiquement le robot sur le plateau. Ils doivent donc être capable de conceptualiser la procédure mentalement avant de la réaliser physiquement sur le plateau.

• Mode compétition

Ce mode permet de prolonger l’utilisation de l’outil pédagogique (apprentissage de concepts) décrit dans le mode “practice”. Une fois l’apprentissage des concepts réalisé, le mode compétition peut entrer en jeu. Il fait intervenir deux groupes d’apprenants qui se livrent une ‘battle’ pour trouver le plus rapidement possible la solution.

Egalement, pour apporter de l’intérêt au jeu et surtout susciter la motivation des apprenants, nous avons imaginé un système de points pour le mode compétition selon le barème suivant:

• +1 point par case non utilisée sur le support principal,
• +5 points pour l’équipe qui a trouvé la solution,
• +5 points lorsque la solution est trouvée du premier coup,
• 0 point pour l’équipe qui n’a pas été suffisamment rapide pour présenter sa solution ou si elle n’a pas trouvé de solution,
• -1 point lorsque la solution présenté par l’équipe la plus rapide est erronée, la tentative est dite “échouée”. Dans ce cas, l’équipe adverse peut alors présenter sa solution si elle en a une. Si l’équipe adverse n’a pas de solution, les deux équipes continuent de réfléchir jusqu’à ce qu’une des deux équipe annonce une nouvelle solution.

Qui est l’équipe gagnante ?

Au terme des trois tours de jeu (i.e 3 maps de positionnement), l’équipe gagnante est l’équipe qui remporte le plus de points. C’est l’équipe qui aura montré le plus de rapidité et d’efficacité à coder les actions du petit robot!

Résultats

Conception du kit

La phase de conception du kit comporte deux sous-phases:

1. La réalisation d'un prototype papier pour matérialiser le jeu,
2. Puis, la réalisation des dessins des éléments sur un logiciel.

Prototype papier

Une fois les bases conceptuelles posées, un prototype papier a d'abord été réalisé.

Date de réalisation : Octobre 2016

Type de matériel : papier

Croquis et description des pièces

	Croquis	Description
Plateau en damier (8x8)		Il s’agit du plateau sur lequel vont être disposées des pièces mécaniques que le robot devra aller ramasser selon les déplacements qu’on lui aura programmé.
Boty, le robot		Il s’agit du robot dont il faut programmer les déplacements. Le robot “tiendra debout” par un système de chevalet ou par imbrication dans un support horizontal.
Personnage robot		Il s’agit des pièces qui seront disposées sur le plateau de jeu et que le robot doit ramasser (élaboration pièces selon la thématique "mécanique").
Jetons de déplacement		Il s’agit des éléments (jetons) dont les joueurs vont se servir pour programmer les déplacements du robot sur le plateau: a. Procédure 1 (le robot exécute les déplacements indiqués dans la procédure 1); b. Avancer (le robot se déplace d’une case vers l'avant); c. Procédure 2 (le robot exécute les déplacements indiqués dans la procédure 2); d. Ramasser l’objet (le robot ramasse l’objet de la case); e. Tourner à droite (le robot s’oriente vers la droite, mais n’avance pas); f. Tourner à gauche (le robot s’oriente vers la gauche, mais n’avance pas). Le joueur aura plusieurs pièces de chaque type à sa disposition.
Support principal		Le support principal est prévu pour disposer les jetons de déplacements dans les emplacements prévus. Il doit accueillir la solution retenue pour faire avancer le robot. Il peut accueillir 12 pièces de déplacement maximum.
Support procédure 1 et support procédure 2		Les joueurs placent les jetons aux emplacements prévus. Les supports de procédure peuvent accueillir 4 jetons chacun.

Croquis du jeu

Ci-dessus, exemple de partie de niveau 3 (beaucoup d’objets à ramasser et utilisation de deux procédures) avec présentation d'une solution possible. Le robot démarre la partie dans le coin inférieur gauche.

Fichiers SVG

Une fois le prototype papier finalisé, les dessins des différents éléments du Kit ont ensuite été réalisés sur Inkscape. Ils sont disponibles dans le dossier Programming Boty SVG dans le dossier STIC III/STIC IV (accès uniquement via le réseau de l'UNIGE ou en VPN).

Les dessins ont été en partie réalisés par nos soins et en partie importés de banques d'images libres de droits. Dans ce dernier cas, les sources des images figurent dans les fichiers SVG de chaque dessin.

Prototypage carton

Date de réalisation : Novembre / Décembre 2016

Type de matériel : carton ondulé

Paramètres de la Trotec Speedy 100R:

Prototype carton

• 

  Kit de construction (face)

• 

  Kit de construction (vue de dessus)

• 

  Procédure 1 et procédure 2

• 

  Support principal

• 

  Pièces de déplacement et pièces mécaniques

Bilan et correctifs à apporter :

Après la réalisation de ce prototype papier, voici les éléments qui restaient à finaliser :

1. Le nombre de jetons de déplacements à prévoir : à adapter selon les niveaux ? avoir un nombre fixe ?
2. Système de points : évaluation de l’aspect motivant / démotivant du système de points tel qu’il est actuellement,
3. Dimensions du kit constructif : taille des pièces / plateau / supports,
4. Prise en compte d'une fonctionnalité additionnelle du kit : aller au delà des scénarios fournis, c'est à dire laisser la possibilité de créer d’autres maps de positionnement (aspect non limitatif du jeu); ce qui suppose de prévoir suffisamment de pièces (combien?)
5. Maps de positionnement : à tester lors du test utilisateur et à modifier si nécessaire.

Réalisation définitive sur contreplaqué

Date de réalisation : Janvier 2016

Type de matériel : contreplaqué bouleau 4 mm

Paramètres de la Trotec Speedy 100R :

Réalisation

• 

  Plateau de jeu

• 

  Boty, le robot

• 

  Support Principal

• 

  Supports procédures

• 

  Pièces de déplacement

• 

  Outils

• 

  Boîte à outils

Bilan L'impression et la découpe ont été, en règle générale, de bonne qualité. Le seul bémol réside dans l'impression du plateau de jeu. Les éléments de repérage autour de la grille (chiffres et lettres utiles pour placer les pièces) n'ont pas tous été correctement imprimés.

Test du projet : réalisation d'un test utilisateur

Le test utilisateur a été réalisé avec le prototype carton.

Population testée

Le test a été effectué avec un groupe de quatre personnes, toutes âgées de 25 ans, dont trois n’avaient aucune notion en programmation, ce qui était notre principal critère de recrutement. Ces quatre sujets sont des habitués de jeux de société pour lesquels ils se réunissent régulièrement:

• Une infirmière, novice en informatique.
• Une enseignante d’histoire-géographie, novice en informatique.
• Un éducateur petite enfance, novice en informatique.
• Un ingénieur qui a de l’expérience en programmation mais qui a tenu à “jouer le jeu” car il a un attrait tout particulier pour l’enseignement de la robotique aux enfants.

Déroulement

Tout d'abord, les participants ont été informé du test à réaliser. Il s'agit de jouer à un jeu collaboratif qui a pour objectif d'enseigner les bases fondamentales de la programmation. Il leur a également été mentionné qu'il s'agissait de tester le matériel et non pas leurs capacités à réussir le jeu et que les données personnelles resteront confidentielles.

Puis, l’expérimentatrice a procédé à la mise en place du jeu, en a expliqué les règles tout en présentant les différents éléments composant le kit. Elle a ensuite mis en place la première map de positionnement. Tout au long de la séance, c’est l’expérimentatrice, en prenant le rôle “d’enseignante” qui dispose les objets et le robot sur le plateau selon les maps prédéfinies.

A la fin de la séance, lorsque les joueurs ont terminé les 14 maps proposées, l'évaluation du kit a pu débuter. Tout d'abord, un entretien ouvert s’est engagé à propos du Kit avec des questions du type : "Qu’avez-vous pensé du jeu?" "Selon vous, quels sont les points forts et les points faibles du jeu?" puis, les participants ont été soumis à une version adaptée du Questionnaire SUS (System Usability Scale). L'ensemble de ce matériel est disponible sous : Programming boty_Matériel d'évaluation.

Recueil des données

Observation et verbatims

Même si les novices ont d’abord montré quelques signes d’appréhension (crainte vis-à-vis du mot “programmation”), l’ensemble des participants semblent avoir rapidement compris les règles du jeu. Les joueurs coopèrent bien. Ils donnent chacun leur opinion. Bonne dynamique. Le joueur “expert” laisse les autres joueurs manipuler les pièces et se place davantage en observateur. Il intervient seulement lorsque les autres joueurs semblent se trouver dans une impasse en donnant des conseils “là on pourrait essayer de mettre la P1 dans la P2”. Les novices commencent à élaborer des stratégies “il faut regarder les éléments qui se répètent, comme ça on peut les mettre en procédure”.

Entretien ouvert

Qu’avez-vous pensé du jeu lorsque vous effectuiez les tâches demandés?

Les participants ont tous trouvé que l’activité était très ludique. Il étaient tous d’accord pour dire que la prise en main a été simple et très rapide Ils déclarent tous s’être beaucoup amusés. Les joueurs ont aimé l’aspect collaboratif et ont estimé que le jeu constituait une bonne activité de groupe. Ils pensent que ça pourrait être une activité également "sympa" et adaptée pour les enfants. A ce propos, l’expert parle de son expérience à apprendre la robotique à des enfants de 8 ans. Il déclare qu’il s’agit souvent d’une activité très intuitive pour eux, et qu’ils s’en sortent souvent mieux que les adultes.

Selon vous, quels sont les points forts et les points faibles de ce jeu?

Points forts

• Univers robotique
• Difficulté progressive pour faire comprendre les concepts
• Personnage-robot sympathique
• Jeu collaboratif

Points faibles

• On ne sait pas où mettre les pièces une fois ramassées. De ce constat émerge la proposition de faire une “boîte à outils”
• Pose la question de la longévité du jeu (nécessite beaucoup de maps de positionnement). Cependant, rien n'empêche l'enseignant / modérateur voire même les participants de créer de nouvelles maps comme nous l'avons mentionné dans le document Règles du Jeu
• Un des joueurs déclare qu’il aurait préféré un mode de jeu plus compétitif, cela lui procurerait davantage de motivation (sachant que le groupe n'a pu expérimenter que la version "practice").

Scores obtenus au SUS adapté

Les participants devaient indiquer leur degré d'accord avec 10 propositions dont la moitié est formulée positivement, l'autre moitié négativement. Chaque proposition est évaluée à l'aide d'une échelle de Likert en 5 points, de 1 (pas du tout d’accord ) à 5 (tout à fait d’accord). La somme des réponses à chaque questionnaire est multipliée par 2.5. Cela permet d’obtenir un score d'utilisabilité subjective allant de 0 à 100.

Le score moyen obtenu est de : 85 / 100

Aux vues des commentaires (points positifs / points négatifs) faits par les utilisateurs, ce score est cohérent. Les utilisateurs sont, en effet, globalement satisfait du jeu et lui trouve des points forts significatifs. Cependant, quelques axes d'amélioration plus mineurs ont été soulevés. Ce score, mis en relation avec les commentaires des utilisateurs permet d'avoir une évaluation quantitative aux commentaires qualitatifs faits lors de l'entretien ouvert.

Problèmes et propositions de remédiation:

Problèmes rencontrés et proposition de remédiation

Problèmes	Proposition de remédiation
En phase de résolution: les apprenants lisent la solution et déplacent le robot, mais ils ne voient pas leurs erreurs entre la lecture et le déplacement effectif (par exemple: ils lisent “tourner à gauche” (ce qui est la bonne solution) alors qu’il ont placé un “tourner à droite” sur le support).	Pour le mode practice: c’est l’enseignant qui lit la solution et la contrôle Pour le mode compétition: c’est l’équipe adverse qui lit la solution et la contrôle
Les joueurs trouvent qu’il y a trop de niveaux faciles.	Adapter le nombre de niveaux faciles suivant la population: Les adultes comprennent rapidement les règles de déplacement simples, ils n’ont pas besoin d’autant de maps de niveau 1 et 2. Pour eux, il faut peut-être seulement prévoir 1 map de positionnement de démonstration (l'enseignant ou modérateur montre aux joueurs le fonctionnement), 1 map de niveau1, puis 1 map de niveau 2 pour enfin concentrer le jeu sur les maps de niveau 3, puis éventuellement en développer d’autres.

Proposition d'amélioration de la part des utilisateurs

• Intégrer une narration: le robot doit ramasser les outils et pourrait les mettre dans une “caisse à outils”.
• Pour la suite du développement, proposition de créer des extensions dans lesquelles ajouter d’autres notions (if, boucle, etc.)
• Numéroter les pièces qui composent le plateau pour bien les assembler.

Limites du test

• Pour des raisons techniques, le test n’a pu s’effectuer que sur le mode practice et pas sur le mode compétition (nombre limité de pièces à disposition),
• Population adulte,
• Population de joueurs de jeux de société: habitués à apprendre rapidement des nouvelles règles de jeu.

Discussion

Notre objectif était de réaliser un kit de construction destiné à proposer une initiation à la programmation informatique et à l’algorithmique. Aux vues du résultat final et des commentaires positifs des utilisateurs, nous pouvons conclure que notre solution répond à l'objectif de départ d'un point de vue utilisabilité. D'un point de vue conceptuel et théorique, ce kit appartient bien à la catégorie d'objet d'apprentissage défini par la "manipulation conceptuelle" de Maria Montessori où il s'agit de manipuler des concepts abstraits que sont les instructions et procédures dans la programmation informatique.

L'apport pédagogique de ce type d'outil est qu'il est éligible à une utilisation dans TOUTES les classes dans le cadre d’une initiation à la programmation. En effet, la dotation en équipements informatiques dans les écoles est en cours et nombre d'entre elles ne disposent pas encore des ressources informatiques permettant d'enseigner la programmation avec des logiciels comme Scratch. De plus, cet outil permet d’avoir une approche ludique et simplifiée de l’informatique - univers qui peut “faire peur” aux novices - en permettant d'appréhender assez rapidement les bases de la programmation. En manipulant des objets physiques, nous pensons que l’apprentissage de concepts abstraits est facilitée.

Enfin et dans le prolongement de ce projet, il conviendrait de réaliser d'autres tests utilisateurs et notamment auprès des enfants qui sont la cible primaire.

Licence, fichiers SVG et documentation

Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale 4.0 International.

Documentation, fichiers SVG et matériel d'évaluation

• Programming Boty _ Règles du jeu
• Programming Boty, Fichiers SVG
• Programming boty, Matériel d'évaluation

Conférence EIAH, Strasbourg 2017

• Article de conférence Initiation à la pensée informatique avec le jeu de plateau Programming Boty
• Présentation du jeu à la conférence EIAH (Environnements Informatiques pour l'Apprentissage Humain) en Juin 2017 : Powerpoint présentation Programming Boty
• Participation à l'atelier "Apprentissage de la pensée informatique de la maternelle à l’Université : recherches, pratiques et méthodes"

Bibliographie

Brooke, J. (1996). « SUS: a « quick and dirty » usability scale ». In P. W. Jordan, B. Thomas, B. A. Weerdmeester, & A. L. McClelland. Usability Evaluation in Industry. London: Taylor and Francis.

Zuckerman, O. (2006). Historical overview and classification of traditional and digital learning objects. Repérer à https://llk.media.mit.edu/courses/readings/classification-learning-objects.pdf, (novembre 2016)