Professeur 2.0 — Semaine 3
Written in October 2020 for my BA in Web and Mobile Design at Haute École Albert Jacquard. Have a preview of my final result.
Previously on “Professeur 2.0” : semaine 1 et semaine 2
Après le feedback du 8 octobre, nous étions perdus quant à l’organisation de notre jeu. Nous avions pleins d’idées de technologies qui seraient intéressantes à utiliser, mais peu de choses concrètes. Nous avions également un peu avancé sur le design, que ce soit pour la charte graphique ou même l’organisation de nos wireframes. Nous n’arrivions pas à nous représenter le projet de manière claire. Enfin nos énoncés d’exercices étaient très flous et pas assez compréhensibles. L’objectif de cette semaine était donc de clarifier tous ces points afin d’avoir un concept fini et de pouvoir enfin passer à l’étape de production.
Choix des technologies
Dans l’idéal, nous voulions que notre jeu soit le plus interactif possible afin que les enfants le trouvent attrayant et aient envie d’y jouer. Nous avions pleins d’idées de technologies qui permettraient cela.
- Utiliser une Wii Remote ou une baguette Harry Potter du studio Universal Studio : Utiliser en tant que souris.
- Scan de QR code ou capteur NFC : Avoir des ingrédients à scanner ou à placer sur un lecteur NFC pour créer les recettes.
- Reconnaissance vocale : Les enfants pourraient dire “Hocus Pocus” à la fin d’une recette pour lancer un séquence.
- Lampe de couleur : Lampe qui changerait de couleur en fonction de ce qu’il se passe à l’écran pour une ambiance magique.
Malheureusement, nous n’avions pas assez de temps pour explorer toutes ces possibilités. Nous avons donc dû faire des choix. Nous nous sommes octroyés 2 jours complets de recherches pour savoir ce qui était réalisable dans la marge de temps qu’il nous restait et surtout, ce qui était le plus intéressant d’utiliser.
La première bonne nouvelle a été l’utilisation de la manette Wii en tant que souris. L’installation a été plutôt simple et au lieu d’utiliser le capteur délivré avec la Wii, on peut l’utiliser avec des bougies. En effet, c’est la manette qui est connectée à l’ordinateur via Bluetooth et elle n’a besoin que de deux émetteurs d’infrarouges, ici des bougies. Nous trouvions que ça mettait un effet magique à l’atelier et donc une bonne idée de garder cette technologie.
Voici les tutos que l’on a utilisé : sur Youtube et un HowTo.
En ce qui concerne le Scan ou le capteur NFC, il s’est avéré que c’était trop compliqué à mettre en place. De plus, avoir des objets en mains à scanner avec l’utilisation d’une manette Wii, ça allait être trop encombrant pour des enfants.
Pour l’utilisation de la reconnaissance vocale, ce sera mieux expliqué dans la partie sur la rédaction des exercices, mais nous avons réalisé que ce n’était pas indispensable dans le jeu. Ça aurait été un plus mais nous avions peu de temps devant nous et un choix a dû être fait.
Enfin, nous avons choisi de garder la lumière d’ambiance. Comme c’est plus une décoration qu’une utilisation première à notre jeu, nous nous sommes dit que si le temps ne nous permettrait pas de réaliser cette étape, nous pouvions toujours l’abandonner. Idéalement, la lampe de couleur ajouterait une ambiance magique à notre atelier.
Déjà des feedbacks!
À cause des deux cours qui étaient rapprochés, nous n’avions que 5 jours pour retravailler notre projet avant d’avoir de nouveaux feedbacks, contrairement aux habituels 8 jours. Nous avions donc peu de choses à leur montrer. Les remarques générales étaient :
- Quel est le but du jeu ? Pourquoi les enfants voudraient jouer à ce jeu ?
- Être clair dans les messages; Pourquoi l’utilisateur s’est trompé, proposer des pistes pour rebondir, expliquer ce qu’il manque,…
- Rendre le hibou vivant; faire bouger son bec, ses ailes, en fonction de ce qu’il se passe à l’écran,
- Harmonie des dessins; si il y a un reflet sur l’un, en faire partout,
- Expliquer comment fonctionne le code; À quoi ça sert, ce n’est pas magique, expliquer qu’il a été écrit par des humains,
- Revoir les interactions avec les boucles et les conditions.
Il était une fois, une histoire…
On nous a souvent reproché que notre fil conducteur n’était pas clair. Quel est le but du jeu ? Pourquoi les enfants voudraient jouer à ce jeu ? On a alors décidé de se concentrer sur le storytelling de notre jeu. Au départ, on savait que l’enfant était un apprenti magicien. Le but final est qu’il devienne un magicien confirmé. On savait qu’il y aurait une sorte de professeur.
Nous nous sommes donc posé un après-midi. On a choisi un nom pour le professeur puis on a fait des sessions de 10 minutes où on écrivait une histoire. On se les racontait, on choisissait la plus prometteuse et on l’améliorait pendant encore 10 minutes. On a fait ça jusqu’à avoir l’histoire parfaite.
La remarque que nous avions pu avoir était qu’il ne fallait pas avoir qu’une histoire que sur la magie mais aussi que ça parle du code. Voilà la version qu’on a fini par choisir. Elle peut encore changer par la suite.
Il était une fois dans le royaume perdu d’Hocus, Magichouette, un maître magicien pas comme les autres. En effet, ses pouvoirs magiques fonctionnent grâce à des programmes informatiques. Un jour, son ennemi Magibou lui a dérobé son chat. Il était disposé à rendre l’animal en échange d’une pierre précieuse dont seul Magichouette connaît l’algorithme. Mais le magicien s’étant cassé une aile en essayant de sauver son acolyte, ne parvient plus à utiliser ses pouvoirs. Dans son royaume personne ne possède les compétences pour l’aider mais toi… Oui toi… Je le sens, tu en es capable.
Avancée de la charte graphique
Nous étions plus ou moins au point mort en ce qui concerne le design. Pour se représenter les exercices, on utilisait des images libres de droit. Il a donc fallu s’attaquer à la charte graphique.
Nous avons fait des premiers tests pour les fioles, les poudres, les cristaux. On savait qu’il fallait utiliser les couleurs primaires et secondaires pour la réalisation des exercices. Il ne fallait plus que la forme. On a de suite aimé les premiers croquis.
En ce qui concerne la mascotte, le professeur, Magichouette, nous avons fait plusieurs croquis suivis d’un premier essai en vectoriel. Nous aimions bien sa forme mais on pense qu’il va encore changer.
Nous avons également fait plusieurs tests pour le logo.
Comme annoncé plus tôt, on nous reprochait que nous nous concentrions trop sur l’aspect magique et pas assez sur le code. On a donc adapté notre logo en fonction. On a fini par choisir celui-ci.
Pour le choix des typographies, nous avons repris la police du logo. Piazzolla est une police avec des angles marqués et du serif. Ils rendent la typographie atypique et curieuse. On pense que cette police s’accorde parfaitement à nos thèmes. Pour aller avec celle-ci, on a choisi Montserrat, une police plus classique, sans serif, avec de belles proportions qui s’apprête parfaitement à des textes qui seront par des enfants.
Rédactions des exercices, user journey
Notre base d’user journey était très flou. Les exercices étaient rédigés mais nous n’avions pas établi quelles étaient les actions que l’enfant devait faire pour réaliser l’exercice.
Par exemple :
Le chapitre 1 — les séquences :
Le chapitre 2 — les boucles :
Le chapitre 3 — les conditions :
Des tas de questions se sont posées. Comment est représentée la boucle ? Est-ce qu’il doit faire un rond avec la manette Wii ? Est-ce qu’il y a un bloc qui reprend la séquence qui est répétée ? De même pour les conditions. Comment est représentée la condition ? Il faut rajouter du bois dans le feu ? Faire un bouton pour le mode jour/nuit ? Cliquer sur le chaudron pour qu’il fasse des bulles ? Nous nous sommes posé des tas de questions comme cela.
Comme pour l’histoire et le design, il a fallu changer les énoncés d’exercices pour avoir la notion de code dedans. Au lieu de faire des potions magiques, nous avons préféré leur expliquer qu’il allait faire des algorithmes, expliquer ce que c’est, ce qu’est une instruction, une séquence. Nous allons insister sur le vocabulaire et leur définition.
Ça a été un casse tête sans nom, nous y travaillons toujours actuellement. Nos professeurs nous ont conseillés d’écourter les exercices. Le but de l’atelier est d’avoir quelque chose qui fonctionne donc on va se concentrer sur le premier chapitre. Nous allons leur apprendre les séquences et faire des exercices plus compliqués que de simplement mélanger les couleurs primaires. Ils apprendront aussi que l’ordre des séquences à de l’importance (nouvelle forme de condition).
Pour la suite, on va seulement imaginer en tant que concept le chapitre 2 et 3.
Design des wireframes
Arrive le moment où il faut penser à l’interface. Comment organisons-nous les éléments afin que ce soit intuitif pour les enfants ? Lorsque l’on pensait encore utiliser un scan de QR code, on pensait avoir une section sur la droite où les ingrédients se placeraient. Pour les recettes, on aurait un pictogramme de grimoire et pour les actions (boucles et conditions) un pictogramme de coffre. Le tout sur un décor de château de sorcier.
Après discussion et suppression du scan de QR code, nous avons décidé d’utiliser le “drag and drop”. On placerait alors une armoire dans le décor avec les ingrédients placés dessus. Les enfants “drag and drop” les ingrédients dans un grimoire où s’inscrivent les séquences. On supprimerait le chaudron pour avoir plus de place. Et on placerait Magichouette dans un coin de la page. Pour les énoncés d’exercices, il y aurait une section en bas de la page.
Conclusion
Malgré que nous ayons encore beaucoup à faire, en une semaine, on a fini par tirer au clair le storytelling, les exercices et le côté pédagogique. Mais ce n’est que le début et il nous faut continuer pour finir le design des wireframes, enregistrer la voix de Magichouette, faire nos animations en AfterEffect et enfin le plus important : coder l’interface. On compte également créer des flyers en print pour rediriger les enfants qui seraient intéressés par le code vers des formations de code.
Next on “Professeur 2.0” : semaine 4, semaine 5, et semaine 6.
