How This Project Went for Me


#1

I finished this project about a week ago and I thought I’d add some snapshots of how it went. One of my bigger struggles in this unit (up to this lesson) was that I had a hard time imagining what a reasonable final product might look for these students - without this in mind, I wasn’t sure what kind of feedback to give students as they were working to make sure they were moving along a productive path. Now that I have some final results, I thought I’d share so others might get an idea of where this project ends up.

This might be kinda blasphemous, but I abandoned the recommended setup for this project where students interview each other about something they want to learn but haven’t, then design their app around that. I had a really hard time imagining the kinds of apps students would develop this way (but that may just be a problem in my own head - maybe that setup actually works out wonderfully) and I got worried that the interview component would derail the rest of the project - I really had no idea how well my students would interview each other (it’s not really something we’ve practiced before) and I had no idea if they would generate serious & insightful ideas versus easy and generic ideas. I didn’t want this to be the foundation for the rest of the project, especially since the interview component isn’t really the main focus of this project. Also, now that I’m a little farther down the road in the unit, the interview component doesn’t really pop up again in the later app projects, so I feel kinda okay that I skipped it here (even though I know it’s a super-realistic part of the actual design process).

Instead, I had them generate their own user groups (I called them communities) using a Mad-Lib style game. I used this presentation to introduce it, then I cut out these strips and had students pick them from different envelopes. In the end, groups of students were assigned the same mad-lib communities but were free to create whatever apps they wanted for those communities. One group got "Let’s design an app for women over 60 who live on a farm, own a snake, and are interested in stylish technology. Not super realistic, but definitely more controlled in a way where we could focus on the rest of the design process (ie: creating paper prototypes, navigation diagrams, testing, etc), and surprisingly creative - the snake group came up with some really interesting ideas as they looked for intersections of all of those details.

We spent the next week going through the Project Guide, which I adapted a little big from the version posted in the Code.org curriculum. I rearranged the order of some of the pages so they were in chronological order (like moving the navigation diagram forward so it appeared before the reflection), which also had the unintended benefit of making them easier to cut out when they were printed 2-sided. I also removed the requirement that they sketch it on a piece of paper before making the navigation diagram, since the navigation diagram is also basically a sketch so they could just save time and sketch it there (although I guess this cuts out some of the iterative process of the design). I also tweaked the Reflection T-chart to ask them to actually record the changes they would make - I thought this was a more direct & actionable prompt in response to the feedback they got.

When all was said and done, here are a bunch of photos of what they created.

So - there’s that. Hope it’s helpful.


#2

Thank you for being so thorough whenever you post – I appreciate your ideas and reflections, as well as the links to the resources you’ve developed/adapted. In our district, we’ve adopted a semester-long model w/ a sequence of Unit 3 > Unit 2 > Unit 4. We’ve also supplemented the curriculum significantly to better cater to our 9-10th grade (primarily) populations. I’m about to head into Unit 4 and have decided to incorporate some of your ideas/resources. However, rather than go with a paper prototype approach, I’m going to have students use the rapid prototyping tool Fluidui (https://www.fluidui.com). We use this tool in my AP CSP sections when we get into rapid prototyping, and I think with the right approach, it could be equally effective within the context of CSD. Anyhow, thanks again!


#3

Along the lines of this discussion, I made a post under another thread that you might find useful:

There you will find links to resources that you might want to check out.


#4

This is awesome. I only wish I saw it before I taught it. I’ll be trying out your method next time. Honestly, I think code.org should consider changing their lesson to yours.

Thanks, thanks, and thanks!