Code, Compose, Collaborate: Goodbye and Hello!

Hello! and welcome to Code, Compose, Collaborate’s (TripleC’s) final report—at least for this grant cycle. It has been a productive and exciting 15 months, and although the grant is ending, this project has wings! Additional workshops are already scheduled for later in the year this year in Beijing, Chongqing, Manila, and New Delhi—our fifth cycle in Delhi, with 3 or 4 in each of the other locations and a whole new deal in Chongqing—way beyond our original goals. Ongoing weekly sessions are also underway at the Urban Assembly’s Maker Academy through the fall in NYC. TripleC’s Code Combinator (the fully networked platform) is completely functional, and we are assessing the results of our initial international collaborations (between sites). In late August we hosted a teacher training exercise in Beijing for 50+ middle and high school teachers. So we continue to test and learn, with many conversations underway about next steps and some exciting possibilities for a significant scale-up (3 million classrooms in China—more on that later). The other outcome of the project appears to be a permanent STEAM Innovation Lab within Design+Technology at Parsons (not necessarily planned, but very welcome).

In this wrap-up, we will provide a general overview of the Code, Compose, Collaborate project, as well as a brief narrative of past and present activity in each location. We’ll also provide a tech update. We will do our best here not to repeat stuff from prior posts, but as this is our final narrative we do want to relate the full project arc. At the end, we will address the trust questions posed by the DML team.

The original development team (Kunal Jain, Michie Pagulayan, and Sven Travis) remains in place and heavily involved. Due greatly to the grant, we have been able to augment this trio with more than 10 Parsons graduate research assistants, both in NYC and on the ground when testing in various locations. The project lives within the Design+Technology program within Parsons School of Design (http://www.newschool.edu/parsons/mfa-design-technology/), and most of the research assistants involved have been Design+Technology graduate students. Throughout the process, we have stuck to our original framing of the project: Code, Compose, Collaborate as an open-source educational coding platform where youth from different cultures, with varying access to technology, can interact, create, collaborate and share using the neutral and safe mediums of sound and computation. A big part of the process, beyond the technical build out, has been to develop and test accompanying curriculum and teacher training modules. Within the TripleC learning process, the emphasis is placed on combining computer programming with learning to compose music. We were intrigued by the possibility of using TripleC (the learning environment) as a mechanism to address critical online issues: privacy, ownership, and sharing, and that has been part of the dialogue as we developed the teaching and learning modules.

Prior to the grant, we were already undertaking initial work in different international locations (New Delhi, Manila, Beijing, and New York), so the idea of creating a networked extension to the project made a lot of sense. Connecting these locations using the TripleC platform allows us to include national and cultural views of the online world as part of the learning deliverables. Students at all sites have been enthusiastic about connecting across long distances, and in virtually every case this part of the experience was a first for the participants. Language has been, and remains, a keen challenge regarding communication between locations, and while facilitating the workshops. We have depended heavily on the Co-PIs (us) and classroom teachers to serve as translators. Still on our punch list is one of our original goals—real time translation in the application.

What have we made? We have used open-source technology (Raspberry Pi, Linux, Python, JavaScript, Ruby, and Ruby on Rails) to produce a portable (kit-based) hands-on teaching environment—a computing station that can be set up easily in a variety of locations, easily networked, and inexpensively replicated. Participants are taught simple Ruby-based programming on the Raspberry Pi using Dr. Sam Aaron’s Sonic Pi (see http://sonic-pi.net/). We want to stop here and give a big shout-out to Sam Aaron for the development of Sonic Pi. It is an application that has been very reliable for TripleC. Aaron has experimented with a variety of applications for Sonic Pi—most recently undertaking some great “live coding” projects. Sonic Pi is also a tremendous educational tool, and we are grateful for Aaron’s stellar work—and for releasing it open-source.

TripleC itself is a web-based envelope that provides a working environment, tutorials, and a connection to other sites. Participants compose music with fellow students first locally—as they are learning about how the system works, and then at a distance in a “private” online workspace (the “Code Combinator”), and finally they present their musical compositions at a “public” online concert (still to be achieved, but we are almost there—this is one area where severely differing time zones are a big deal, especially for young people with bedtimes). The Code Combinator is an application built to work seamlessly with the local Code, Compose, Collaborate website and Sonic Pi programming environments. Within Code Combinator students pass snippets of code and music back and forth, eventually forming a complete composition. We have created a mothership web server that resides in NYC and directs traffic between sites—it is invisible to users (unless teachers want to log in).

The whole thing is taught through a series of teaching modules that we have developed (and continue to work on) for 1-day, 3-day, and 5-day workshops. Our original goal of holding 2-week workshops (five days for teacher trainging and five days for students) simply proved too demanding (mainly schedule-wise), for both the development team and the schools on-site we were working with). We have tested all of the workshop models and have had greater success with the shorter duration workshops, simply because it has often been such a scheduling nightmare.

What is the resulting experience? We originally framed three layers of possible collaboration within TripleC. It is worth revisiting these and providing some quick analysis of our results. Each layer represents different levels of coding competency, and online privacy: from local to distant-but-private, to fully public. Thus, the TripleC workshop modules and pedagogy suggest a link between the advancement of coding skills with greater access to online engagement. Our teaching modules have been developed with concern for a variety of limitations, including language differences, neutrality and safety of the online environment, technical limitations, and time-zone differences.

A vast majority of the TripleC testing occurred within the first (local) layer. This was for three reasons: first, much of our pedagogical development needed to be tested on-site, with teachers, and it took a good deal of time to get initial lessons right, Second, our belief was that the teachers, upon gaining familiarity with the environment, would be the best online mediators (this has generally proven true—and is built into the Code Combinator as a “teacher channel”—this point appears again later in the answers to some of the trust questions.). Finally, the Code Combinator (the networking element of the environment) came into being later during the grant period, hence restricting connectivity early on. No worries; working locally generally worked well, and one advantage was we were able to share initial teaching experiences extensively between sites.

Individual participants (students) in TripleC sessions pass through four virtual “rooms,” each room representing a greater connection to the external online world. Movement is from a local, unconnected machine, to the local networked classroom, to the connected but private Internet, and finally to the public concert space. As we have built the environment, the public concert component is not (currently) directly accessible from the main TripleC windows. Access to the “next” room or level is controlled by moderators (almost always the teachers, after training). Individual participants cannot connect with other participants without obtaining teacher permission. We have found that asking the students to go through this permissioning works well to call attention to the level of their connectivity, and also helps remind teachers of where and what activity if occurring during a session. Of course this plays right into a number of trust issues.

How have we tested? We originally proposed one or two workshop testing cycles at each location (NYC, Delhi, Beijing/Shanghai and Manila). We are proud to report that we have achieved that and much more, if in somewhat of a different fashion at each site. We have held at least three workshops at each location, with additional sessions scheduled at all sites during the coming months. New Delhi, which was one of the earliest sites tested, will go through 5 full cycles by calendar year’s end! Beyond the standard workshops, we have experimented with additional teaching models and testing. In China, we just returned from our first full-fledged large-group teacher-training workshop (50+ middle and high school students), and we are implementing weekly one-day sessions at Maker Academy (NYC) throughout the fall. Throughout this testing, age groups have varied: in Delhi and Beijing, we are working with 11 to 13 year olds, in NYC, we are working with 13 to 15 year olds, and Manila has involved younger (9 to 10 years) elementary school students. This age divergence has been unintentional (again due to unpredictable partners and schedules) but has produced interesting results. One intriguing aspect has been the ability to bring different age groups together over a distance within TripleC, with really no negative consequences. In fact, when collaborating at a distance, the students remain quite unaware of the ages involved. Collaborative music is a fascinating human condition, especially when it is occurring anonymously.

Reports from the front line. Here are descriptions of activity in each location. We will start with an in-depth analysis (provided by Co-PI and technical lead Kunal Jain) of the New Delhi activity, and then a brief report of each additional location (NYC, China, and Manila). On our site, we have posted a variety of shorter and longer location reports (part of what we have had graduate assistants working on recently is editing and unifying those texts), as well as some photo and video montages from the workshops.

FARUKHNAGAR, NEW DELHI, INDIA.

The longest running series of TripleC workshops has occurred at the Rajmala School in Farukhnagar (state of Haryana) in India—just outside of New Delhi. Three workshops were conducted over the course of a year at this school, and in two of these, we undertook separate teacher training as well. We were fortunate to have a highly engaged group of students and motivated teachers throughout these sessions. A significant aspect of the TripleC project is its geographical region and socio-cultural context. As in Manila, the Rajmala School provided an opportunity to work with children from a semi-urban/rural region and to compare the feedback received with similar workshops held in urban areas China, NYC. This comparison helped provide insights into the level of exposure to technology and how it affects learning on new platforms as well exposure to different technical platforms.

The Rajmala School is located in Farukhnagar and serves as a free high school for the local children. The school is run on private philanthropy that pays for the school’s operating expenses. The settlement of Farukhnagar is in Gurgaon district of Haryana. It administrative history dates from the early 18th century when it was established as a feudal state under the Mughal emperor. Its economic activity is centered on agriculture, but its history includes salt mining until forced closure of the salt wells in the early twentieth century. Due to its rural setting but relative proximity to the national capital, a reasonable level of technological exposure could be assumed. Income level the families indicated exposure to technology in the form of low-cost smartphones or computer desktops in labs. However, students were aware of the technological trends among the wealthier sections. As expected, the understanding was more at a consumer level than a deeper empirical level. Over the course of the workshops, we installed 4 TripleC kits permanently in the school’s computer lab. The lab has a few legacy PCs with 14” CRT monitors, minimal power backup that coupled with frequent power failures produced challenges of continuity and consistency.

The lesson plan used for the original workshop was based on our 5-day proposal, but feedback from successive sessions suggested we would be better stripping it down to a 3-day framework. It was also modified to include games and theater activities as a strategy to prepare the group for open learning and generally to build some excitement and fun into the sessions. Each session began theatre games with two allied goals: One is to initiate a group dynamic, enable the ability to focus, the second was to encourage comprehension of instructions, as well as to introduce concepts pertaining to the coding activity by gradually modifying them on successive days to address the awareness of the Raspberry Pi machines and programming. Each workshop began with an introduction to the Raspberry Pi, its components, ports, peripherals, interface, followed by an introduction to the Sonic Pi application, and preliminary commands. These were enough to get the students divided into four groups and start using commands to create a musical program on their own.

The 2nd 3-day workshop session incorporated a more structured approach to programming as well as expecting a project deliverable from each team. The team members by now had enough experience with the command-set to start exploring and composing their codes. A presentation structure was also proposed which would be used by each team to present to the class and staff members at the end of the workshop.

The 3rd workshop was a review and final presentation session for each team member. The staff members and the Principal were present during their presentations and were encouraged to provide feedback.

There was a high level of curiosity from the selected students and the teachers about the nature of the workshops. Many students were quite excited to learn more about the hardware itself and play with its connections and other possibilities, especially due to its price and possible re-use of existing material. The instructions for Sonic Pi were simple enough for most participants to grasp very quickly and start experimenting in work sessions and create compositions/code relatively fast. Issues faced (as is often the case when teaching neophytes to code) were related to syntax errors, hence we learned of the critical role debugging should play in the teaching modules.

During the first workshop, only basic code was taught and experimented with, but it was quite successful in getting the children immersed and interested in learning more. By the 2nd workshop, however, students were easily more comfortable with programming concepts and by the 3rd day were building loops with ease. Multithreading was trickier and took a while to understand, but Sonic Pi’s responsive feedback helped greatly here (once again kudos to Sam Aaron for a great application). The Code Combinator platform to be used for holding and sharing each team’s content was also introduced during the later workshop, and each team was asked to generate content within it. We plan to use this platform further during our next sessions with a focus on sharing, online persona and identity issues. The teams demonstrated considerable interest and enthusiasm for learning and interacting further within this environment. Throughout discussions with teachers and school administrators, we have approached the issues of trust and explained many of the issues we have hoped TripleC will introduce. This has prompted many discussions, although we must admit the extent to which the teachers have taught with these issues in mind varies.

Some students showed an active interest in developing further and asked for the Raspberry 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 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 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 and will be running additional teacher training sessions later this 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.

Our workshops in New Delhi have identified a number of practical concerns. The new Raspberry Pi kits are housed in the existing computer lab, and this raises a possible issue of logistics, as well as the matter of the use of these terminals for other activities. Though it is understood that these terminals will be eventually be provided to the school on a long-term donation basis (an agreement we have with all of our participating sites), security and monitoring of the machines may need to be addressed. The school leadership and the teachers who participated in the workshop have demonstrated considerable interest and engagement. They have been encouraged to take ownership of the activity and to extend the learning sessions beyond the 3-day workshops, to sustain the excitement and growth and to drive the project goals with a long term perspective plan. For sustaining such a development, we received the following requests from the school, which we are acting on:

Teacher training: two more workshops are to be held during this year to train the school teachers so they can run these workshops/classes without the TripleC PI supervision. Without this critical step, we have concerns about TripleC being sustained. A workshop is planned for late November that is intended to be run completely by the teachers, with the coordinators providing background support.
Organizing the curriculum: the administrative staff and the founders committed to modifying their computer lab classes to include time for these sessions. A detailed lesson plan for running such a curriculum has been shared with the school staff.
Equipment resources: though the cost outlay for the equipment is quite low and the basic workshop equipment has already been provided to the school, the annual budget would require an inclusion or maintenance of these items, along with the provision of basic internet access.

NEW YORK, NY, USA.

Throughout the project, we have worked locally with the Urban Assembly Maker Academy, a new public high school (founded 2013) in downtown Manhattan. They have been great! The school is open enrollment and attracts students from very diverse backgrounds, most of whom have been attracted by some aspect of the DIY-Maker ethic. During the grant period, we have introduced TripleC to the Maker Academy in a variety of forms, ranging from dedicated weeklong “Code Camps” held at Parsons (summers 2015, 2016), to multiple teaching module tests in-class at the school (academic year, 2015-16), to weekly after school sessions currently underway (Fall 2016). Maker Academy students have been the oldest group we have engaged with, and certainly the most convenient. They have served as our local test group in multiple locations and have been hugely helpful in testing both the technical underpinnings of TripleC and perhaps, more importantly, the viability of the teaching and teacher training modules.

The Maker Academy has also served as the initial testing ground for the Code Combinator (we set up TripleC kits in multiple classrooms, and had the groups engage accordingly). They also helped us test the actual physical kits—we asked 10th graders to build the set up from ground up (it worked, although they suggested that we use orange cases instead of black). Parsons graduate assistants had the opportunity to write, test, rewrite, and retest multiple TripleC lesson plans within the Maker Academy “Creative Technology” courses. The results have been applied to all locations. Throughout the sessions currently underway, we are continuing to experiment with distance collaboration using Code Combinator (primarily with Beijing), and we hope to hold our first “public” concert end of the 2016 calendar year. There is a current discussion about setting up a permanent TripleC base at Maker Academy, and the possibility of implementation across all (30+) Urban Academy NYC schools. This would be one very doable approach to furthering the project (at the January 2016 UCI DML workshop, one suggestion made was to consider localizing future implementations to overcome travel costs, language differences, and support issues). In any case, the Maker Academy have been great partners, and we look forward to continuing to work with them.

BEIJING, SHANGHAI, and CHONGQING, PR of CHINA.

Three cities? Yes, and generally for the good, but China has been one of our more challenging locations, while at the same time (along with dedicated TripleC workshops in schools) presenting a recent chance to hold a large 50+ TripleC teacher training workshop, as well as a tremendous opportunity for furtherance of the project on a grand scale. Parsons Design+Technology has had an extensive relationship with multiple partners in China for more than a decade, so China presented itself as an obvious addition to TripleC. We started out with the intent of working with a longtime partner—the Dandelion Middle School in Beijing. We undertook an early testing cycle at Dandelion in June 2015, primarily focusing on teaching Sonic Pi (this was prior to a functional TripleC web environment). We were able to test both teacher training and actual learning sessions. At these sessions we were woefully underprepared for language issues—even with Chinese speaking Parsons graduate assistants as translators, the teaching process was tough, and we were quickly reminded of the importance of all written material being translated as well. An additional challenge arose as we realized that an early promise of Internet connectivity was not likely to materialize. Dandelion moved buildings in December 2015, and we were left out in the cold (literally and figuratively). Fortunately, we were actively courting additional partners, and we were able to continue work with two international schools in Shanghai during early 2016. This proved ideal in that these schools teach in English.

At the same time (around the UCI DML workshops) we were approached by Beijing Normal University with a proposal: they had seen a lecture Sven Travis presented at Tsinghua University (Beijing) and wondered if we would be interested implementing TripleC nationwide as part of a Chinese government directed STEAM curriculum. They wanted to know if we had teacher training modules and classroom materials they could distribute to 3 million Chinese teachers. Sven Travis was part of these conversations and his initial response was “this is crazy.” As it turns out, Beijing Normal (who control all curricular certification for the Chinese Education Ministry) was serious. This has resulted in the very real possibility of large-scale expansion of TripleC. Not, mind you, with the original trust issues intact, but interesting nonetheless. The Chongqing aspect of this equation will represent TripleC testing across a large municipality and is slated (currently very informally) to begin in March 2017. Whether any of this large-scale work come into being is still very much up in the air, but it is exciting that TripleC attracted this type of attention, and clearly educators in China at least see possibilities for scaling the project up. In the meantime, the TripleC team did undertake a substantial teacher training exercise in Beijing, at the Tsinghua University Innovation Center, during August 2016. This week-long session allowed us to gauge reaction to the TripleC platform from 50+ middle and high school teachers. They were very enthusiastic, and we distributed materials for them to continue using TripleC in their classrooms upon their return home (they were from all over China, many having traveled a fair distance to participate. This represents a different form of scaling, and we are curious if any will succeed in taking the platform into their schools without on-site facilitation. Of course it would be great if they do. We are intrigued by all of this, but this is China we are talking about. Unpredictable at best.

TAGUIG, MANILA, PHILIPPINES.

TripleC 3-day workshops have been held at two different public schools in the City of Taguig in the southeastern portion of Metro Manila, National Capital Region, Philippines. Both workshops were made possible with the extensive help and the support of the City Government of Taguig and local volunteers. The City of Taguig has been making strides to modernize the public school system and in 2015 rolled out IT support and accompanying “cyber labs” in several public schools. This IT support in public schools is a huge improvement from the past and provides a very real possibility that the TripleC program can be sustained moving forward. These workshops, although fledgling and at different locations, were enough to pique the curiosity in particular of teachers involved, and of all of our locations it is Manila from whom we most frequently hear “when are you coming back?” The age group was younger in Manila, which we worried about ahead of time, but in the end good results and at least some verification that TripleC can work across a fairly wide age-span (no, we are not claiming it is for everyone).

In January 2016, the first workshop was held at Bagong Tanyag Elementary School with 3rd-grade students. The second workshop was held at Gat. Andres Bonifacio Elementary School in August 2016 with 6th-grade students. In both instances, the classroom teachers received initial training separately and then were asked to supervise the workshops with students. During this second round of Manila workshops, we tested substantially revised lesson plans based on earlier experience in NYC, Delhi, Manila, and Shanghai. Essentially, we broke down the concepts of programming for a younger audience, adding more activities and exercises to make it more appealing for the age group. We also increased the number of stations and reduced the team size to two students per station to allow for better division of labor (2-person team) and collaboration because of the smaller group size per station. Participants shared their compositions at the end of each exercise including the final compositions they created. Competition among the teams was inevitable because of the teaming structure, and this was a new experience for us—not present in tests with larger groups. The competition added humor and energy to the process and seemed to lighten up the atmosphere during the workshops. Due to space and equipment limitations, only about 10-12 students were able to participate in each workshop, which is approximately ⅓ of the student population of an average public school classroom. A class size of 70 students in public elementary schools can be typical in Metro Manila, which we are simply unable to accommodate in this program. However, our goal is to conduct additional large-scale teacher training sessions (similar to those we just executed for 50+ in Beijing) in the next planned sessions so the schools will be able to scale up the workshops on their own and evolve the program within their school curriculum.

The technology set-up is identical for all workshops—monitor, Raspberry Pi installed with Sonic Pi, mouse, keyboard, external speakers, and cables were laid out on a long table for the kids to assemble themselves. All of the equipment used, each programming concept presented, and Sonic Pi syntax used were all explained in detail as they are introduced to the participants.

In both Manila workshops the instruction took place using a mix of Tagalog (Filipino) and English—but occurred predominantly in Tagalog with terminologies expressed in English and further explained, elaborated and reinforced in Tagalog. The main reason being that the students participating were clearly more comfortable receiving technical instruction in the local language. This was a fundamentally different language experience than that in China, perhaps because of the presence of at least some English.

A final series of youth and Teacher training workshops are slated for January 2017 at Gat. Andres Boniface Elementary School.

A bit on technology development.

For us (the Co-PIs), this has been and is a very real technology development project. So we want to include at least a bit in our final narrative. Our blog post #3 was almost entirely on tech, so we will keep this brief.

The TripleC “Code Combinator” is powered by the Ruby on Rails framework and hosted on Heroku and Amazon AWS Linux/Nginx infrastructure and integrates a versioning system, translator, and a REST-based interface for data exchange between servers/stations. The final code will be open source. A locally hosted version for the teacher kit is also in consideration to allow offline classrooms to continue to host and share their content with each other. mySQL is our database of choice. The web application client is designed to run with minimal resource loads, with responsive frontend (using the Zurb Foundation front-end responsive framework). It has been designed to run on the pi’s default OS, Raspian, with customized Sonic Pi v2 (Code Combinator client). “Black box inside a glass box” design approach used here. The Code Combinator web application is designed as a secure network platform with a strong privacy model to secure all identification markers for contributed code. Other application features: Direct output from Sonic coding window, viewing/contributing versions with comments + authors, live mode, node-based entity model. Sonic-Pi is a core component of the Code Combinator. It serves as the interface used by all students (and teachers) to write the actual Ruby code and then test (play) it. Sonic Pi is a lightweight, open-source desktop application (which works beautifully on the Pi) created by Sam Aaron, to teach coding creatively by composing and performing music. Its simple interface encourages students to start writing code and listen to the results immediately. Many classrooms across the world have used this application to get children involved in an immersive programming environment.

TripleC’s “Code Combinator” platform is targeted at middle-school/early high school age youth from semi-urban/rural regions in combination with their counterparts in more developed/urban contexts. Our intention is to link participants from different countries and different cultures, with the hope of providing insight into the level of exposure of technology and how it affects learning new platforms, as well as exposure to various experiences with a networked environment. To enable this, the tech platform and hardware kits we developed needed to function across these groups, regardless of socio/economic/lingual/cultural barriers. We created kits that included all hardware/software necessary required to run a reasonably self-contained system for the workshop. The kit design had to satisfy the following requirements:

portable: easy to carry to remote locations
self-contained: all hardware requirements should be included
locally sourced: all components should be locally available where possible
easy set-up: software should be ready to use
provide alternative power
work within a local network
allow for alternate internet connectivity

All applications (offline/online) have been designed to be lightweight and run off a Raspberry Pi for students as well as teachers. We have started the program using the Raspberry Pi 2 model, but the current Pi 3 model can be easily substituted (comes with built-in wifi hardware). To simplify deployment, our portable kit is comprised of:

Raspberry Pi 2 configured to connect automatically to the local wifi network (as is 3) and to open the triplec app in the browser
wired keyboard/mouse
compact wireless router configured to create a local wifi network and a local server (teacher station)
pre-configured Sonic-Pi application and sound setup
compact speakers
7” Pi Foundation touchscreen display
Portable pico projector (as a backup presentation tool)
14Ah portable battery power bank
extra wires, adapters, etc.

These are organized within a compact padded backpack for portability and convenience. Since electricity is very unreliable in the semi-urban areas chosen for the workshops, the kit was designed to be self-powered up to realistic timeframes using power banks. We are still investigating the possibility of a reliable continuous electricity source to power the kit (solar). Network access has been challenging in all of our locations (even in NYC at times) hence we are considering providing cellular-based temporary internet access to allow for “Code Combinator” connectivity during the workshop sessions (bandwidth needs are minuscule, as the actual transferred data is text-based and minimal).

During our various workshops in NYC, New Delhi, Manila, and China, our tech implementation has pretty much worked as we expected it to. Ruby on Rails is a solid, well-supported platform and we have not built an overly complicated thing. Development has been ongoing, and so has debugging and design, but we have never had a complete fail at a workshop. The hardware (primarily basic Raspberry Pis) also proved very stable. During all of our tests, we lost a total of 4-5 Pis, and one of those was because the kit popped open while traveling as checked baggage. As the sites and workshops move onto the network to use the platform more intensively, we will be able to provide more insights into performance, interaction, and connectivity of both the software and the hardware.

TRUST PROMPT QUESTIONS (From DML):

We’ve tried to answer these questions honestly. This is an ongoing project, with multiple opportunities to scale up. Many of these answers remain works in progress. We have learned a great deal about what TripleC does and doesn’t teach about trust, and we have much left to accomplish as far as addressing specific trust/privacy/safety issues as we hone the Triple C curriculum. We look forward to the process.

1. Define what trust means to your learners and their community.

The Code, Compose, Collaborate program was designed so that “trust” never became an issue to participants— they were either working together within the environment, or they weren’t. The presence of teachers seemed to back this up. The TripleC program investigates the dynamics of trust at different levels of interaction: from within teams working on a project, between teams, classrooms and finally teams in classrooms located at our different global locations. We have taken the informal approach of discussing differences in access and attitudes to the Internet when comparing the different locals involved. But in general, because users seemed to feel safe within the coding environment, the definition was never pushed. In the future, it would be worth injecting questions such as “how do you know your collaborator is who they say they are?” or “what is the difference between working in a ‘safe’ group at school, versus independently from home?” As the project has developed, we have continued to evaluate this question in three primary areas:

Local: interpersonal and technical
Collaborative: teachers, groups, distance
Institutional: different access laws, mores, accessibility

2. How do you describe your purpose/mission? How does it align with your learner’s goals? What are the parameters of your mission? How does your work align with issues of trust?

Our mission (as taken from the original grant proposal): “TripleC is a learning environment where youth from different cultures, with varying access to technology, can interact, create, collaborate and share using the neutral and safe mediums of sound and computation. Throughout the process emphasis is placed on combining computational/musical learning/creating with critical online issues: privacy, ownership, sharing, and differences in national and cultural views of the online world. TripleC initial workshops will occur in New York, New Delhi, Shanghai and Manila.”

As we developed the platform and related teaching/learning materials, we spent far more time evaluating and assessing issues such as approach and effectiveness of teaching code, differences in learning between age groups, and ease-of-use of the platform than we did looking at trust issues. This was natural, as a primary part of the development was achieving a functional teaching tool. We are at a point now, though (with the advent of Code Combinator), where we are increasingly looking at how groups at distance are relating to one another, and how differences between social and government views of the internet affect students attitudes and outcomes. There are opportunities now to step further away from the basic lessons of coding and composition and directly address aspects of trust, safety, awareness, and even philosophy.

3. How were you able to embed trust into your product or program from the beginning instead of as an afterthought? How will you demonstrate transparency and show you are being thoughtful with data?

We believe the issue of trust– and the ability to address it as a learning outcome– is inherent in the TripleC platform, from local to networked. However, it has been a juggling act to hone and test the basic learning/teaching environment. The platform we created—Code Combinator—took longer to implement than we initially predicted (welcome to tech development). There were several unanticipated technical issues that didn’t allow our team to fully implement and embed Code Combinator into the program until approximately 9 months into the grant cycle. Network connectivity in cities like Manila, Delhi and Beijing also became an impediment to using Code Combinator on-site during the workshops. What this really suggests is that instead of an afterthought, we have begun to embrace the trust issues after other basics were smoothed out. The transparency and data thoughtfulness, for this project, are much more specific issues, and have been considered from the start. First, TripleC is basically an anonymous environment, with all data public, but little private engagement present. We purposely did not include side-channel chat sessions (with the exception of the teacher channel), or in-line language translation, for this reason. Whether adding such elements would richen the teaching/learning experience is a question for future development. For now we have produced a system that is living in the land of code, with little personal communication possible.

TripleC takes advantage of three basic approaches to moderate and teach aspects of diversity, civility, and inclusivity. First, the aforementioned layering/leveling engagement process, participants are expected to learn and demonstrate basic online etiquette locally before interacting at a distance. Second, they are only interacting within the framework of a programming development environment, allowing for relatively limited straying from the task at hand. Finally, the compositional process implemented within TripleC’s server provides unlimited history of contributions; nothing is permanently deleted, and code snippets can be switched on/off for testing and comparison.

At each step of TripleC implementation and testing, these approaches are being tested and questioned. Is local collaborative (in-person or online) effective in preparing for distance online interaction? Does the local experience translate when new participants are speaking a different language and may have different understandings of inclusion and civil behavior? What teacher-led exercises are most effective in establishing benchmarks of acceptable behavior? What team dynamics produce best results (team size, makeup, synchronous/asynchronous interaction). How do the built-in limitations of interaction via coding, versus more freeform (i.e.– “normal”: text, photos, videos) engagement augment or limit the teaching of acceptable online behavior? To what extent will TripleC need to moderate the code stream to limit problems? Do the participants gain as much from the collaboration when the product is more abstract (a musical composition)? Part of the intent of TripleC is to provide a relatively neutral and globally acceptable collaborative rule set while investigating these questions.

4. What are the systems and infrastructure you need to create transparency and trust? What best practices were you able to achieve in your current environment?

From a technical perspective we believe best practices were demonstrated by curbing ambitions, keeping goals simple and direct, and using well-tested open-source tools during development. From the teaching/learning/collaborating end, centering the entire teaching and learning experience around code and music tended to move the trust conversation to a different space. This is not to say that it isn’t there, but that questions arise about trust in different zones: does collaborative coding require different trust structure than simple conversation? How do we communicate differently when creating music than when talking or exchanging media? We decided throughout this development that there is an inherent trust present in the kind of environment we built, but that begs the question of whether this is good. If participants trust without regard, are we doing our job in teaching about trust? In this sense, questions about best practices in the pedagogical or interactive zones of the project are still being answered. As we begin to include such issues into our teaching modules (see specifically the icebreaking and game-playing activities present in the New Delhi description), we will assess what is working best. Focus is on four areas:

Teacher training
Multiple testing of curriculum, and varied schedules/time frames.
Imparting aspects of teaching away from the CCC platform
Slow role-in of Code Combinator—part by design, part by necessity

5. How did you, or do you plan to gather feedback and engage with your stakeholders? How might you, or did you, involve the learner? What will you, or did you do if you do/did not agree with your stakeholders?

We initially planned a variety of approaches to gathering feedback from facilitators, teachers, and students. We used the initial workshops to test our lesson plans and assumptions and iterated based on feedback from facilitators/teachers. Usability testing on the Code Combinator platform were conducted from the beginning and feedback were incorporated in the various stages of revision. Direct observation (video and photo documentation– some of which can be found posted to the project site), interviews with workshop participants (teachers and youth) and local facilitators provided additional input that we utilized in our design process (various cycles of iteration). We received the best continual feedback from the first two groups. Graduate assistants who were involved in platform development and also workshop facilitation provided the best development-related responses, while classroom teachers were helpful in relating what did or didn’t work within broader curricular or institutional parameters, and in many case quantity and quality of lessons. Originally we had planned to undertake post workshop interviews with stakeholders– we did accomplish this with about half of our sessions, but this was inconsistent due to a variety of factors.

6. How will you iterate to make your program even better? What barriers might iteration present in the short term? How will you overcome them?

Having more than a year to bootstrap the TripleC initiative was valuable in terms of learning and identifying the holes in our program. For us this is very much a project in process, so this is an important, and quite wide-ranging question. Part of the answer lies in where and how we scale up the project. If it evolves primarily locally in NYC, the solutions are far different than if we engage in a massive roll-out with the China Ministry of Education. A current, practical answer to the question is that we’ve made local connections that we can now leverage for future endeavors relating to this project.

Barriers:

Varying degrees of digital literacy of youth and public school teachers in China, India and the Philippines (slow start but they are able to catch up as the workshop progresses)
Motivation of public schools and public school teachers to learn programming basics in order to teach them to students
Bureaucracy—working with local government and the Department of Education to gain access to public schools and teachers delayed some of the planned activities that had a snowball effect in terms of timing/scheduling of activities
Equipment/technology requirements (which is still needed in this program) to make the program more accessible to other students outside of the workshops. Only 12 students are accommodated per workshop session, which is typically only ⅓ of a classroom in public schools in Manila.

Possible solutions:

Work with local government and/or school administrators for support and tap into existing public school teacher training programs so that the program is embedded in the system (easier said than done)
Bureaucracy and leg work was anticipated, but this did not make local situations less complex. Future planning must build in substantial back-up and downtime when working with localities,

7. These principles endure in a community of trust. How were you able to meet them?

Notice
Consent
Access
Ability to challenge existing data
Data security
Respect for Context

We will refer here to answers of other questions that target all of these issues. We’ve already noted that virtually all of the online activity within TripleC is anonymous and in coded form, so to a great extent there is not personal or revealing data involved. That has been borne out by our testing thus far, but should these issues arise, we will have to address them.

8. Accountability: What is your plan to help if something goes wrong, i.e. bullying, data breach?

Regarding interpersonal problems, we are entirely dependent on the classroom teachers, especially after on-site facilitations by the Co-PIs and graduate assistants end. This (along with provision of onlne help) was a primary reason for instituting the tacher channel within the Code Collaborator and a teacher chat line into the main NYC TripleC server.

We have contracted AWS (Amazon Web Services, where our servers are located) to run a bi-weekly security scan. At this point, however, there is little personal data involved but Ruby code (which can contain comments), and musical output.

9. What data will you collect? What is the life cycle of the data collected? Should your organization or organizations using your platform fold or become acquired, what is in place to protect user data?

As noted in our grant proposal, we’ve upheld this goal from the get go that individual privacy is protected by:

Anonymous identity. Only local TripleC teaching stations will have information on identity of individuals;
Nature of the product involved. Compositions will be a product of the group, which will have a team name.
Distributed TripleC Sonic Pi collaborative code will even be scraped of individual anonymous identities (there is currently no intent to undertake such distribution).

We collect Ruby (Sonic Pi) code and musical output from users, and we have documented (photo and video) and undertaken exit interviews at our workshops. All participants have signed release forms for public use of all data and documentation. Our data resides in duplicate on AWS servers and backed up at Parsons. We do not expect Parsons to fold or be acquired, and institutional policy states that Principal Investigators own and control the destiny of their projects.

10. Has your project identified any considerations of trust not otherwise readily recognized? If so, how might such consideration be taken up more generally in learning environments?

Other than the abovementioned aspects of the differences of trust issues within a coded environment, no. We look forward to furthering investigation of the implications as we more thoroughly inflect the TripleC learning and teaching modules with trust and privacy related material.

Note: This is a post originally published on October 2016 on the HASTAC/DML Competition website and has been updated for completeness. You can view the original here.