TripleC Working Hard and Making Progress!
This is the second blog post from Parsons’ Code, Compose, Collaborate (TripleC hereafter) project (for a quick overview, you can loop back to our first blog post). So hello again! We’ve been busy. Lots of activity underway, ranging from continued technical development and testing of our teaching platform, to running workshops in NY, New Delhi, Manila, and Beijing. We’ll end with a brief commentary on some of the reaction the project received from the recent UC Irvine presentations/discussions. Thanks to the people who put those sessions together: they were helpful. Sven was in attendance at those Trust Challenge grantee workshops out at UC Irvine, and one of his reactions was “wow, participants are coming from all kinds of places, and not just geography”. Out there, and along the way, we’ve received a bunch of questions about who we are, so we thought we would start off here by providing a bit of background about the Mighty Spicy Collective (Michie Pagulayan, Kunal Jain, and Sven Travis), the group undertaking the project, and where we work, the Design+Technology programs at Parsons. So here is a bit about us.
Sven founded DT back in the mid-nineties, and has been heavily involved there every since. Over the years he has held a lot of admin positions at Parsons and The New School, but right now he is very happily just a professor, and spends a lot of time teaching—both on the undergrad and graduate level. Michie also has a long history with DT, graduating with an MFA from the program in the early aughts, and later she became a professor and Director of Special Projects in DT. She recently left full-time teaching to pursue various projects on her own (most recently with the UN). Kunal was one of the first graduates of the MFADT program, after which he oversaw tech facilities and development for DT, eventually leaving to establish a New Delhi/NY design firm, working across architecture, interaction, the non-profit sector, and a variety of government projects. All three of us have been involved in making and building a lot of different projects (together and apart) over the past 15 years. Usually these projects involve some sort of interface with education/interaction/coding. We’ve always enjoyed working together. The Mighty Spicy Collective was formed in that spirit. Code, Compose, Collaborate was initiated about a year prior to the Trust Challenge grant competition. When that competition was announced, we said “wow, that’s a fit.
As for Design+Technology, it’s a big, broad sprawling playground where students and faculty work across many media, and towards many ends. Art, design, education, business, anything goes. The program is approaching 20 years old, so graduates are spread across many industries and pursuits. And there are many of them; DT is a huge program (the largest tech-centered MFA program in the world), and probably the most striking thing about it is its community, which we like to think is immensely welcoming but fiercely supportive and protective of its members. DT attracts students from many different backgrounds. We won’t go into promotional mode here, but please visit. We like meeting people and talking about projects. And Sven tells good jokes…
So back to the project (TripleC). We’ll begin by providing the (slightly modified) progress report we just used for the UC Irvine workshop last month, and then updates from three workshops that have happened during the past few months in New Delhi, Manila, and NY.
Over the past eight months workshop roll-out of TripleC has occurred at elementary, middle and high schools in NYC, New Delhi, Shanghai, Beijing and Manila, with youth ages 8-15involved. These workshops have included an ongoing rollout of support materials as well as the website and app we are building for the project. We have had different experiences at each location, and we have learned to be flexible in our expectations.
Progress has been solid on the tech development end (teaching wedsite and Code Combinator software platform). This has involved a full website design and implementation, and a good deal of back-end Rails work. Kunal has managed the tech side. The technical design of TripleP is a hardware build and a software implementation in two forms: a server and a web application. Progress on each is as follows:
1. TripleP kits (hardware). Complete, functional, and tested on site(s)
2. The TripleP central web server running the Code Combinator web application. Complete, functional, and tested on site(s)
3. The Code Combinator software. Basics are functional, including the versioning system. Translator yet to be implemented
Punch list: additional web and server application features: direct output from Sonic coding window, comments screen, authors, live upload mode
Just yesterday Kunal sent Michie and Sven the following note:
Hi Michie and Sven,
I am hoping to achieve closure on the frontend developer’s work in India later this week. So if you can take some time soon and go through the app site and make sure all looks and functions well (at least until the sharing part) it would be great. Basically, we should have the following working fine with the proper design:
– sign up
– sign in
– forgot password
– access dashboard (as teacher or student)
– create and access projects history and comments
The rest should be working but not templated out yet. Michie, the issue you had has been fixed. Just make sure you select a school/class when you sign up. You can access the backend here:
[Access info omitted]
Let me know!
Thanks!
Kunal
This represents substantial technical progress for the project! Kunal has been managing a group of designers, developers, and DT grad students spread between New Delhi and New York and during the past two months they have accomplished a lot. When he refers to the “sharing part”, he is referencing the Code Combinator, which is the networked extension we are building on top of the Sonic Pi app. As he notes, it is working (we have run a couple of test cycles already), but it hasn’t been spiffed up with proper look and feel on the actual TripleC site. One note: we were thrilled to get some web design done by Yumi Endo, a stellar DT grad long time at Frog (we’ll post some of the style sheets she did, which we like a lot, when we get a chance).
We have tested teaching modules at all locations, and as noted are now beginning to test the Code Combinator that allows locations to collaborate across distance. Distance exchange between Manila and New Delhi was recently successful, and sessions between Beijing/Shanghai and NYC are scheduled for late March. One important note: we have expanded our testing goals beyond the initial grant proposal and scheduled two workshops at each location instead of one. We made this change for two reasons: it gives us greater opportunity to test, iterate, and prototype both the software and the workshop modules, and it allows us time to get used to the challenges and differences of each location (there are many).
The original plan called for one week of teacher training to be followed with one week of (youth) workshop sessions (one three-hour session per day) at each site. It has been hard to stick to that original schedule when onsite. Scheduling challenges abound (different at each location)! In any case, we have completed all of the curricular and teacher training modules; we’ve often ended up running three day workshops instead of a full five. We’ve found that we could include more exercises in each session, so content-wise we are about the same. All curricular activities assume participants will be working in groups for exercises, and this has worked well. We always try to have two members of the development team (one co-PI and one research assistant) present at initial training workshops. After the initial round of training has been conducted for the main facilitators (teachers), they can effectively join in providing support to student participants, so our second round workshops only require one of use present (this approach has worked well in New Delhi and NY). During our upcoming March workshops two locations will be participating simultaneously, allowing for distance online pedagogy and technical testing to occur. Additional admin correspondence, training and collaboration will be remote thereafter (distance training and via online collaborative platforms). Pedagogy for the latter is yet to be developed, but we do have a group of online tutorials prepared.
We wanted to include in this post reports on three workshops we’ve held since July: New York (with the Maker Academy High School), New Delhi (actually two cycles) at Rajmala middle school, and most recently in Manila, at Bagong Tanyag elementary school. One thing you will immediately pick up on is that the age group of participants has ranged from 8 (3rd grade) to 15 (9th grade), and the workshops have occurred across elementary, middle, and high schools. This has been partly intentional, to experiment with different age group reaction to the teaching of coding, but also in one case spontaneous (in Manila, the Department of Education switched locations on us unexpectedly, so we ended up working with students in an elementary school instead of a middle school). Please forgive the different report styles, as we are in the process of editing the reports and posting them to our TripleC blog. One of the questions we discussed recently out at UC Irvine was what proper (and effective) assessment would look like for this project—we’ll identify that at the end of this post as a yet unresolved issue moving forward.
NYC (July, 2015, synopsis):
New York City as the location of this workshop is in stark contrast to the previous TripleC workshop conducted in Gurgaon, India, where participating students came from rural/semi-urban families with very rudimentary exposure to consumer technology. Participants are New York City residents attending the Maker Academy, an open-enrollment public high school in downtown Manhattan. They tended to be confortable using handheld devices and popular personal tech gadgets (they are typical American young teens, if from somewhat economically challenged backgrounds). These NY students were also a from an older age group (8th and 9th graders) which also affected how they would perceive the workshop exercises. These led to a different challenge of introducing a new low-level approach for pedagogy while keeping them involved at all times.
The students came with no experience using Raspberry Pi computers nor the Sonic Pi programming environment, but by the end of the week-long workshop, they were able to hook up the Raspberry Pi computers on their own and code their melodies with Sonic Pi.
The first few days began with ice breaker activities to create a comfortable environment for the students. The class started with a warm-up exercise where students were assigned a code function or term and then acted out the code in their turn. The first day covered equipment set-up—setting up the Raspberry Pi computers which the students caught on quickly, and were able to set-up themselves by the second or third day. After set-up, a brief run through of the Sonic Pi GUI and basic code terms were covered, and an example was shown while students followed along on their computers. Since the students worked in groups, they would alternate who typed so that everyone would have a chance to learn through live coding. Once the new terms were taught, students were given an in-class assignment to review the terms they learned and created their masterpiece using the new terms.
The age group of freshmen and sophomores posed a challenge of keeping the students engaged, so we rotated the group members to feel out which students worked well with each other. Some students who knew each other or became friends during the experience were sometimes distracted with socializing, but in the environment of friends, the students were comfortable enough to ask questions and help each other. Although the group structure had a loophole of not every student participating in typing, the challenge of creating a better song than their opposing teams gave the students motivation to work together and create a complete compilation.
The workshop was conducted over five days with two three-hour sessions each day. There was an initial reluctance to get physically involved with dissembling and reassembling the Pi setup and some general tech-related issues. But many students were able to help each other out through the typical hurdles. Setting them up in teams also helped in many ways but also led to a few non-contributing members. However, with the introduction of sound and music, most students got deeply involved in building music compositions and were able to bring in their personal tastes into their code. The progressive addition of more complex functions, over the next few days, was quite gradual and natural, which helped them resolve many issues they had been struggling with the previous day. By the end of the workshop sessions, students were able to code melodies from scratch, but also use pre-recorded samples to create a final composition. The workshops were designed for four groups, each group of three to four students. Students were able to work collaboratively, though some students caught on faster than others, the more advanced students aided their classmates.
The challenges faced in this first NY week-long workshop taught us the pros and cons of teaching coding through music in groups, but the pros outweighed our difficulties. The team spirit and competition of creating a good song, beat, or melody by the last class demonstrated the strengths of having the students work in teams. The students were able to understand basic programming concepts by applying them in creating their compositions. Though finding the right groups for the students to work proved to be a learning experience, teaching them in groups allowed the students to help each other, and further aided their bond with one another. The groups were able to complete complex songs with variations by the end, and they expressed wanting to make their songs better, even though they had already accomplished so much within one week. We hope this experience will broaden their view of what they can accomplish with code and be excited to learn and create more with code in general.
We are currently experimenting with weekday afterschool version of the TripleC curriculum at the Maker Academy, running through the spring 2016 semester. The weeklong intensive will be repeated during July 2016, with a new crop of kids.
New Delhi (January, 2016, synopsis—note, this is the 2nd workshop help at this location):
This 3 day workshop was designed as a more intensive session with Sonic-Pi for the teams that participated in the 3 day workshop in May. We were able to pull in the same students hence the students already were aware of the processes and methodologies involved. This time we also planned to introduce the networked platform developed in-house to start building awareness of the intricacies involved with working with online persona and content sharing.
Day 1. As before, each day started with a few simple participatory exercises, designed to loosen the students (and teachers) and prepare them for instructions. For this session, the exercises were shortened and made more specific to the content matter presented right after.
Students were given a quick recap on the pi, sonic-pi, and basic instruction sets. A rough outline of programming concepts and how they related to the pi was described. The group was split into their teams and asked to go through some sample blocks preloaded on each terminal. These pieces ranged from simple loops to a bach fugue and a jam loop. Each group were asked to spend some time understanding some of the techniques used, experiment with moving code blocks around and creating variations. At the end of the session, each team presented their work to the class and feedback from other teams were encouraged.
Day 2 started with a review of day 1 and introduction to a few advanced commands (in_thread, sample). A library of samples (pre downloaded on each terminal due to lack of internet access) were demonstrated and each team was asked to go through and select a few to play with using the learnt commands. At the middle of the session, each team presented their work to the class for feedback.
The final project was introduced as per the lesson plan and in the remaining time, the teams were asked to start thinking of a concept for the piece as per the parameters set in the plan.
At the end of the session, the class was introduced to the concept of online persona and the role of the code combinator application as a platform for creating one for each of their teams An overview was provided on how this initial exercise will be a starting point for their interactions with teams from other classes/schools in the near future. However, due to an issue with the application and the local wifi network, they were not able to complete building their profiles on the platform.
Day 3. The teams started work on their final project. The teaching assistants presented an example project which was used to demonstrate the aspects of making a good presentation (which the teams were to make to the School Principal at the end of the session). Another task planned for the day was to continue working on their fledgling online persona and start contributing content by adding comments to other teams’ uploaded projects. However, due to an administrative mixup, the day got over before either could happen and the class had to be dismissed before the students’ final presentations could be made. A later presentation for the teams has been scheduled for later in the semester. On this day, the teams will finish uploading their projects to the platform and add their comments as well, which will help building their understanding of privacy and ownership.
Progress:
- Students were easily more comfortable with programming concepts and by the 3rd day were building loops with ease. Multithreading was tricker and took a while to understand, but sonic-pi’s responsive feedback helped greatly here.
- Some students showed active interest in developing further and asked for the pi set and sonic-pi software for personal use. The teachers have been requested to allow the students regular access to the stations as manageable by their schedules.
- The initial exercises helped the students to effectively connect sonic-pi concepts with actual programming concepts.
- The school administration and faculty have expressed great enthusiasm for the potential of the project to introduce students to basic concepts of coding while navigating the the murky waters of modern communication platforms. We are in the process of establishing a more sustainable delivery method to continue engaging the students through the year.
- To allow for a more standard setup, we compiled an essential list of software/hardware required to run such a workshop and consolidated them into a portable kit that can be carried to sites and set up as a teacher station relatively easily.
- The technology platform to be used for holding and sharing each team’s content is also in progress and can be previewed at: xxx . We plan to use this platform during our next sessions.
Issues:
- The issues faced were largely about sustainability of running and maintaining the idea of the workshop over time. We need to work more on this and outline the key issues and possibly approaches.
- There were some technical issues with the network due to which the application was not tested by the students as yet. We are currently midway through the development of the application platform and intend to fully implement it usage during the next sessions. In particular we would want to better understand the international networking aspect of the project.
- Class timing limitations was an issue at times since students had to catch their buses after end of school and we had to stick to fixed schedules to fit our sessions in.
- It can help greatly if we can use a consultant on site with some musical background to help explain some concepts and help the teams when working on their compositions.
- Due to the school’s remote location from the center, there were logistical issues faced by the team – travel times, setup preparation as well as power and networking issues. Keeping these mind, the lesson plans were prepared to be used without any network dependencies. Also the hardware used could be mostly supported by solar and battery backup in case of power failure. More investigation into alternative setup is required. Internet access is also another requirement for successful networking, and though the workshops was designed ot run on local networks, later workshops will be requiring stable connections to the rest of the world.
Manila, (January, 2016):
Public schools in Metro Manila have two to three class shifts: morning (6 am to 12 pm), afternoon (12 to 6 pm) and, in a few cases, evening class sessions due to congestion issues—lack of classrooms and volume of students. The workshop was initially intended to be a full 5-day workshop similar to that held in New York in the summer of 2015, but was compressed to a shorter 3-day workshop with lesson plans derived and condensed from the NY workshop. Due to scheduling conflicts we had to run the Taguig workshop on a Saturday where it may not disrupt the class schedule, which seems to work for everyone involved. A short lesson plan was quickly prepared for a day-long session from the initially expected 3-day workshop.
A class size of 60-100 students in public schools is typical in Metro Manila and for this school, in particular, it will be about 70 students per class in elementary school. The workshop could not accommodate a group of 70 students due to equipment availability on-site that allowed for only three stations + a demo station. Thus, the school selected a group composed of eight 8-year old girls and boys to join in the day-long workshop accompanied by their 3rd-grade teacher who was there to assist and observe. Living in an urban environment exposed the kids to consumer technology and, for some, a few handheld gadgets like smartphones and tablets that their parents or relatives own. Bagong Tanyang Elementary School (Main) is one of the more fortunate schools in the region with a computer lab. But not everyone has access to the computers and the lack the digital literacy is prominent.
The instruction was done in a mix of Tagalog (Filipino) and English—but predominantly in Tagalog with terms in English that is further explained and elaborated in Tagalog. Although the students understand English quite well, it seems that the kids have a stronger level of comfort in hearing instruction in Tagalog. Moreover, just avoid any additional complexity since programming can be considered another language.
The workshop was held in a classroom where three sets of 19” monitors with Raspberry Pis were installed with Sonic Pi, mouse, keyboard, external speakers, and cables were laid out on a long table for the kids to assemble themselves. Each piece of equipment was first explained and how everything comes together was demonstrated accompanied by a diagram on the screen. After a few donuts and a quick round of introductions, including the TripleC project and the run of the day, the eight kids were grouped into three teams for each station with the assistance of three facilitators to lend a hand to each team when needed. There was an air of excitement and enthusiasm among the kids who have never seen a Raspberry Pi before nor have ever been given the opportunity to put a computer, monitor, and speakers, together. After the Raspberry Pi set-up, Sonic Pi was introduced, and the students were taken through an introduction of the Sonic Pi interface, some basic code concepts, terminologies, syntax and samples and had the students try it out. Competition among the teams is always inevitable, and healthy competition adds to the fun and learning because the students sought to learn to mimic the code of what they just heard from the other team. All the kids, including the facilitators, had fun collaborating, debugging and testing different samples and putting them together in a composition.
Students in a team of twos compared to that of a group of three seem to be more ideal —they both had the opportunity to type, give comments/suggestions, and collaborate, resulting in more even distribution of labor/tasks. A more pared down lesson plan for a younger age group (3rd graders) with possibly more exercises would need to be created because the students seem to be overwhelmed with the terminologies and concepts thrown at them for a day long session. Perhaps breaking it down to a few sessions would’ve helped.
A follow-up workshop will be held in the Philippines mid-year with a more structured lesson plan. We are considering possibly holding this cycle as a series of weekly events similar to the semester-long experiment currently underway in NY.
Topics and discussion at the recent UC Irvine gathering:
As noted previously we very much appreciated the effort extended in pulling this gathering together. We enjoyed meeting project groups, and seeing progress reports. The discussion on TripleC was informal but helpful, answering some questions and providing us several perspectives as we move forward. We touch upon a few of these in concluding this blog post, and look forward to more discussion.
Security/privacy evaluation and approach. This came from our expression of concern about testing system reliability in these areas, as well as topics such as the possible addition of a comment feature, which would allow participants greater informality in communication. Experts commented that we should be rigorous in how we represented the security issues involved, and this may result in an internal white paper on this topic. Another interesting comment was that we shouldn’t worry too much about containing and parameterizing everything—we should let the experiment flow. Of course, we liked this approach, and it reminded us that given the extreme differences of our test locations, it will be hard to establish clear security rules that apply equally everywhere. We also discussed the security differences between local (classroom) and distance (Internet) implementation of the curriculum. There is a certain amount (we would hope enough) security built into the system via teacher moderation. To be continued!
Scalability and sustainability. Both issues came up in a variety of ways at UCI. Scalability issues include differences (cost, complexity, culture, rules) between local (or domestic scalability in American schools, vs. international. Recent discussions of massive rollout in China (across 1100 schools) was noted. China, in fact, is a complicated and ongoing aspect of this project. We haven’t touched upon it in this post, partly because we have two upcoming workshops (March and June), and partly because the conversation of funding via the Chinese government may provide opportunities for expansion of the project that are only just beginning to be understood. Probably a major part of Blog Post #3 content (you’ll just have to wait with baited breathe). Sustainability is an ongoing topic, and we have looked hard at each workshop structure as it relates to teachers moving forward with our curriculum on their own. This has occurred most extensively in the ongoing local work in NY, and this relates to the locality issue. Much of our planning work during the next few months will involve further development of teaching modules (various schedules) and the implementation of online tutorials and support.
Assessment. The main question we were asked was (“what do you want to assess?” Our obvious answer (and addressed in a couple of the prior workshop reports) is “teaching code”, and whether our platform helps or hinders. But privacy, online understanding, and development of group trust (local and distance) also remain in our headlights. It is our goal to seek further advice in this regard, as we are no experts.
That’s all for now. More soon. Thanks for reading.
Note: This is a post originally published in February 2016 on the HASTAC/DML Competition website. DML website. You can view the original here.
