Sunday, April 4, 2010

Scratch: collaboration or not?

I was contacted by Gary Bertoia via twitter about a collaboration project using Scratch. If you are unfamiliar with Scratch, it is an MIT designed software that allows students to create games by clicking and dragging commands rather than using a complicated programming language. It allows students to think about the design and layout of how video games work without having to learn the language. Gary's idea was to teach our 8th grade classes the basics of the program and then have them design and create their own game together. Oh by the way, Gary teaches at South Saigon International School in Vietnam exactly 12 time zones ahead of us!

We started by using some instructions in Google Presentations created by Simon Haughton. Students learned the basics of Scratch by designing an Etch-a-Sketch, race car maze, Pong, and Pacman. Then we used a wiki for students to come up with their own game ideas. The first challenge was to match up our classes' ideas. My class was divided in groups of two and Gary's students worked in groups of two or three. We then had to bargain with the students to convince them to agree to one anothers' ideas. It would have been nice to have the students engage in a real discussion about the topics with each other but the time zone difference made that impossible.

For our first attempt, collaboration might have been more of a goal than a reality. There were many challenges to this project centered around the communication piece. We had many ideas and tried many tools including e-mail, Google Docs, Voicethread, wikis, and the Scratch upload site. On my end there were challenges related to us having many class periods off due to parent conferences, a conference I attended, and mid-winter break. We also had challenges with our district filter blocking our uploads to the Scratch site and not allowing the students to download email attachments from Gary's students. 

We ended up with a chart in Google Docs that linked the student teams, emails, and an individual Google Presentations for each game. Students used the slides in Google to share their ideas, drawings, and changes to the game. On our end we would download the games from Scratch and then e-mail them back to the students in Vietnam. But we spent wasted days not being able to access the games due to the filter and changed passwords. I think sometimes my students neglected to email their games back to the students in Vietnam. The end result is that in many groups Gary's students did the lion's share of the programming and had more buy-in than mine.

Just because you build it, does not mean that they will collaborate. Gary and I had plans of a great cooperation, but we did not make it personal enough so students did not feel it. We originally planned to have the students make video introductions to each other. We scrapped this due to time restraints and my not having permission slips from students ahead of time.

We surveyed both of our classes about the experience afterward and they (I use they to represent both Gary's students and mine) expressed frustration about their partners abroad not working hard and the lack of communication. They also were frustrated by feeling that their ideas were not heard or deleted. Both of our classes experienced similar thoughts and we both had some students that worked harder than others. As Gary said it "felt more like us and them rather than a collaboration." Middle school students need more than a Google Doc to communicate to develop a relationship with others.

Gary and I learned a lot from this experience. Gary's school uses Google Apps so his students were already comfortable with gmail and Google Docs. I underestimated how long it would take to get students started in these tools. His class was a semester long class and mine was only nine weeks.

Remember it is ok to model failure to students. I am not afraid to "fail" at an idea especially if it is something new with great potential. The good news is that we are going to do it again next year. Things we will do different next year include:
  • both doing this project during a semester class for more time and make sure that there will not be a major break in our school schedules during the project.
  • teaching gmail, wikis, and Google Docs before the project
  • starting the collaboration sooner with introduction videos and google docs before we introduce Scratch to the students to build relationships
  • finding a better way to share our work perhaps with dropio or dropbox
In the end the students did not really collaborate because they had no relationship with each other. We will work to fix this next year and hope for a more successful project based on better communication and real relationships. Hopefully this reflection will both encourage you to try a collaborative project and help you to plan it well.

5 comments:

  1. Why not do the collaboration within the class? Is there some reason you have to create all these barriers to collaboration (12-hour time zone changes, ...)

    ReplyDelete
  2. Very interesting, I can see where there are lots of problems to solve.

    Now I don't feel so bad, I did as Kevin, (comments), said. Collaborated within my class and still had some of the exact problems. My students used the message service within our Moodle to communicate as they had to go there anyway, to get assignments, etc., while learning to use Scratch.

    I need to write up what I did and what happened.

    ReplyDelete
  3. This is a very useful reflection and I hope to share it with colleagues as an example for collaborative projects and the steps to success. I have done several projects that have had that similar results. For me, the crux of the issue is what I have heard is called the hand shaking process. The first step in any collaboration is that students need to get to know the person on the other end in some fashion. This step is important for collaborations within the same class to classes on the opposite side of the world. Students have to take ownership over the relationships. Trust has to be built...

    Students who build trust into their working relationship will work harder to overcome the tech issues. Otherwise the tech issues become a very convenient excuse for them.

    ReplyDelete
  4. Thanks Carl and Scott for confirming what was missing here. It is good to have outside perspectives showing the same problems (lack of relationships) and results (lack of student buy-in). It definitely helps me/us plan for more successful projects in the future.

    I totally agree with Scott's last sentence "tech issues become a very convenient excuse for them." Well said.

    Kevin, you ask a critical and important question that I have been thinking about all of last night and this morning. Carl's admission to the same issues in an in-classroom collaboration sheds some light on it.

    Kevin, I feel another blog post brewing to try to fully answer your question. Thanks for the push back.

    ReplyDelete
  5. Nice overview of the collaboration and suggestions for how to make it work smoother. It was a learning experience. I know when I tried a sprite based collaboration between classes, like Carl, I had difficulties as well.

    As you mention our collaboration had a number of fundamental issues that I think we can solve. The reality of the world we live includes multinational companies with teams working on collaborative projects in different parts of the world. So I like the fact that we are working multiple time zones away.

    I think, we have a much better understanding of the structural issues involved with the collaboration. In addition, especially with middle school kids once we create some type of icebreaker activity that allows the kids to meet each other, see where they live, attend school we will build the relationship needed to make the collaboration much better. Also by doing this each group will learn more than just how to animate a sprite. I am looking forward to trying this again.

    ReplyDelete