Workshop Reflections

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.

Project Management Workshop Design Document

Project Management from Design to Showcase

This is the title of my Scratch @ MIT 2018 Conference workshop coming up this Saturday. I’m excited and honored to be given the opportunity to share some of my experience working with students to create the original Scratch projects, some of which I have written about in this blog.

Session description:

Managing a class (or club) of students working on individual Scratch projects is complicated.  They have big, creative ideas for their projects. They want multiple levels, gravity, complicated animation, and character interactions in their very first programmed game. We, on the other hand, need these projects done on schedule, for the parent showcase or before grades close. This is project management. How can we, as educators, honor student creativity and voice while dealing with the practical realities of limited time and guidance?

In this session, we will look at elementary student game design documents and find ways to support the conversion of these documents into a working, Scratch-coded final product. Participants will work in pairs or small groups with actual game design documents from my 4th grade Code Club members.  They will discuss and interpret what the student envisions and develop a plan to help the student be successful. A formal plan will help gauge if the student is on target to finish on time.

We will discuss issues that come up during different stages of the process such as helping students communicate their ideas about their project, and think programmatically. We will discuss different ways to code animation, how to find resources, and dealing with student expectations. We will talk about facilitating students working in pairs, time management, and debugging.

(This is my original wording and may differ from the conference program)

Title: Project Management from Design to Showcase
Date: Saturday, July 28
Time: 11:00a – 12:00p
Room:  E15-207 (Wiesner Room)

When I finished writing the description last winter, I was in high spirits because it sounded like a workshop I would want to attend.  I’m hoping to facilitate interesting discussions centered around supporting students and their creativity.

I’ve gathered the student design documents I want to share and am putting the final touches on my presentation.  I’ll share everything here in a post before the workshop on Saturday.  For now, here is the current version of the design document I use with my 4th-grade Code Club students.

Engineering Design Process

This week I will become the “project manager” for some 30 Scratch projects between my two Code Clubs.  It is Design Review week and the students will meet with me to go over their Game/Project Design Document before beginning to code their own projects to share at our Showcase for parents at the end of the term.

Last time we met I handed out the GDD (Game Design Document) for them to work on and complete before I meet with them for the design review process this week.

I’ve updated the GDD again.  (It is a work in progress).  This time I’ve added the EiE diagram of the Engineering Design Process to the front page and used language to support this process idea within. We use EiE curriculum in school, in our Hypertherm Hope grant supported after school clubs and summer Title I engineering camps. Many students have seen this before.

In the “Ask” phase I explained that they would have an opportunity to make their own Scratch project and opened it up for their many questions.  We also spent some time looking at past 5 Code Club Showcase projects to see what others have done. (I really hope the llamas don’t get remixed again this time around.  They are hilarious the first time you watch, but… well, even the students were tired of them by the end)

I also gave them some time to “Imagine” and sent the “Plan” GDD home with them.  Some were quick to come up with their ideas and completed the GDD before Code Club ended.  There will be some time this week while I meet with the groups to work on their “Plan”.

Once the “Plan” is approved it is time to “Create” then test and “Improve”.

Also new to the GDD is the Team Member Jobs plan. – I am letting them pick a partner of their choice (this is a club, not school) but I’ve found it is often ambiguous who will work on what part.  I’m hoping this part of the GDD will help me help them get work done.

Cute story:  One of my high school volunteers came to me, concerned, with a question about the “working with a partner” option.  A code club member had asked him, the high schooler, to be his partner. So I had to specify to the nine year old, “You can work together with any other code club member, but the high school volunteers will be helping everyone and can’t be your partner.”

My Own “Programming in Scratch” Challenge

Last week was Design Review Day for my code club. In one week’s time the students were able to come up with an original idea for a game, design it, plan its creation and pitch it.  Amazing!  This time I manned the lab while Alex, my high school volunteer and a parent volunteer conferenced with each group.  Both volunteers were pleased with the pitches in general. I admit that I haven’t had a chance to review any of the completed game design documents myself.

Instead I’ve been busy working through a Scratch language MOOC on edX, from my alma mater, called: HarveyMuddX: CS002x Programming in Scratch. I’ve been excited about taking this online class since I first learned of it and started following the course professor Colleen Lewis on Twitter and at CSTeachingTips.org. The course has a nice balance of video lecture, directed “play” in Scratch and rigorous quizzes. The class has helped fill in gaps in my knowledge of Scratch. For one thing, I hadn’t played around much with the Sound blocks in Scratch, so that was a fun week.

I also learned about race conditions, which I hadn’t heard of before.  A race condition is where two things are competing to set a variable or perform two operations at the same time and you cannot be sure of what the outcome will be.  For example, below I’ve set the score to two different values when the green flag is clicked.  Which will Scratch choose?  -whichever setting wins the race.

An example of a race condition

I had fun making some little drawing projects and a helicopter game.

Now I have to design a final project. And I have been directed to think about it first…

Rather than just diving into a project, we want you to start thinking about different ideas for things what you might do.

Hmm.. that’s like what I asked my students to do.  The tables have turned and I’m not sure how they did it, now.  I’ve been toying with a couple of different ideas for awhile now and I’m still not sure what I want to tackle.  I’m going to have to make a decision soon and get to work.

This is my favorite question in the final project design phase of this MOOC:

Think about breaking your project into a series of simpler steps. What are the FIRST three things that you would make work?

I wish I had put some wording like that in my game design document for my students.  At any rate, I will remember to ask my students how they will break up their tasks as they continue work on their projects tomorrow.