Together with some friends I manage the events of a local CoderDojo group: we meet once a month, gathering together some kids that want to create something interesting and fun with computers. We use different technologies, but we mostly build little games or stories in Scratch, and one day we decided to run an experiment.
A typical Saturday afternoon starts with the mentors asking the kids what they want to create, but contrary to what it may seem this is not a simple task: some kids don’t have a clear picture of what they want to achieve and the greatest part of them tends to work individually.
To overcome these problems we thought to provide the kids a sheet of paper with printed some directions and to ask them to gather in groups and take half an hour to fill in the blanks before starting to code. Actually, some groups were suggested by the mentors, but in the end they worked.
The printed directions were simple and their goal was to lead the kids to create an outline of the game they were going to code afterwards. The hints were:
Of course during the 30 minutes time frame the kids were not left alone: the mentors as usual moved among the tables asking and answering questions. Actually the process requires the mentors more to ask than to answer; for example when a kid was stuck on a character’s movement a typical question would have been: does your character move only horizontally, only vertically, or both? Does it jump? And so on. This way the kids find the answers by themselves and write them down on the paper.
The advantage we noticed was twofold. First, the hints helped the kids that have more difficulty in focusing their ideas to define better their game before starting to code, and this in turn avoids them to get lost in the middle of the development. Second, the kids discussed in groups how to structure the games and then the collaboration continued during the development: in some groups different kids were assigned different tasks, in others all kids worked each one on their own computer to create the same game but syncing once in a while and exchanging experiences.
Overall for us it was a positive experience because the advantages one can achieve with this approach are not restricted to the coding world but could be applied to other learning environments: writing down such a simple template for your activity and inviting the kids to fill it can go a long way in setting up the right organization in your team. For sure we will use the same approach again in other future events.
A typical Saturday afternoon starts with the mentors asking the kids what they want to create, but contrary to what it may seem this is not a simple task: some kids don’t have a clear picture of what they want to achieve and the greatest part of them tends to work individually.
To overcome these problems we thought to provide the kids a sheet of paper with printed some directions and to ask them to gather in groups and take half an hour to fill in the blanks before starting to code. Actually, some groups were suggested by the mentors, but in the end they worked.
The printed directions were simple and their goal was to lead the kids to create an outline of the game they were going to code afterwards. The hints were:
- title of the game;
- rules of the game;
- backgrounds to be used;
- characters and how they can move and act;
- other elements and how they can move and act;
- how the game ends.
Of course during the 30 minutes time frame the kids were not left alone: the mentors as usual moved among the tables asking and answering questions. Actually the process requires the mentors more to ask than to answer; for example when a kid was stuck on a character’s movement a typical question would have been: does your character move only horizontally, only vertically, or both? Does it jump? And so on. This way the kids find the answers by themselves and write them down on the paper.
The advantage we noticed was twofold. First, the hints helped the kids that have more difficulty in focusing their ideas to define better their game before starting to code, and this in turn avoids them to get lost in the middle of the development. Second, the kids discussed in groups how to structure the games and then the collaboration continued during the development: in some groups different kids were assigned different tasks, in others all kids worked each one on their own computer to create the same game but syncing once in a while and exchanging experiences.
Overall for us it was a positive experience because the advantages one can achieve with this approach are not restricted to the coding world but could be applied to other learning environments: writing down such a simple template for your activity and inviting the kids to fill it can go a long way in setting up the right organization in your team. For sure we will use the same approach again in other future events.
Comments
Post a Comment