I’ve been reflecting on my #ScratchMIT2018 conference Saturday workshop. I had a lot of information and student work to share and I did that. It was a nice size group of educators from around the world. The people who attended were great and some were definitely excited about it.
@scratch @MrsPollardprime #ScratchMIT2018 excited to be at this session! pic.twitter.com/H3hzklX8Pk
— Uloaku Ojiaku (@uloakuojiaku) July 28, 2018
I spent more time talking about my design review process than I expected. When we finally broke into groups, people seemed engaged when they were looking at my students’ work and thinking about how to support them.
#ScratchMIT2018 : Finding your peeps and learning from them, too! #GettingUnstuck @ScratchEdTeam @MrsPollardprime pic.twitter.com/uHUzldIhVx
— Kathleen Fugle (@kathleenfugle) July 29, 2018
This was my first time presenting a workshop at such a big conference and I learned a lot. One thing I could improve is my facilitation of the discussion. I need to prepare better follow-up questions and do less talking.
I made four different packets of student work to share. Different groups looked at different packets which I thought would facilitate more varied conversations but I was the only one who knew all the work and that hindered the whole group discussion. I should have at least brought up the finished project under discussion on the screen so that the rest of the group could have a frame of reference.
One project that we discussed was Penguin Trivia. It was noted that its design document matches the executed project well.
I could have followed up with what “supports would you put in place for this student?” Since her communication and time management skills seem strong, she could have used more support on game flow code examples and more time testing and debugging. (Although this is always true)
Another example project that was brought up was Thee Annoying’s Return. In this example, we thought the student could improve how he communicated his project.
Someone noted that he says there are no rules, but clearly, there are. So what clarifying questions should we ask during design review so we know he has thought carefully about his game?
The design document serves as a way for students to think deeply about their project before embarking on its creation. The thing with creative adventures is that plans change. That’s okay. The design document is a guide. There were some helpful suggestions about how to refer the student back to the guide during the creating process as a self-check-in. Older students may be able to reflect on their progress and assess the status of their project themselves.
Some other great ideas came up during the discussion. One was having a peer review in the middle of the process as a way for students to support students.
Another idea was to have a checklist of things that should be in the project. I’m not sure if this would be a general or project specific checklist, but it would aid in assessment, either way.
One problem we weren’t able to solve was having the time to meet with each student/group when the numbers are large or the time is short. I generally rally some additional help on Design Review Day so I know everyone’s project gets at least a quick approval so they can get started. I do check in with students each week to see where they are, where they are going, where they are stuck, etc. There are a lot of pieces to project management, but the benefits of letting students pursue these passion projects are huge.
Overall, I am happy with how it went and I’d enjoy running it again.
My Code Club Journal 