Transitioning to Virtual Learning: What We’ve Tried, What We’ve Learned, and How We Aim to Make It Better. Part 1: Setting Up and Hosting Our First Camp

When I reflect on this past year, a quote I saw on Reddit comes to mind:

“2020 Is like Looking Both Ways Before Crossing the Street and then Getting Hit by an Airplane”      

The pandemic has forced most of us to rapidly adjust to unexpected changes.  For Bravo LT, this meant suspending the Raspberry PI Youth Camps, which are part of their company’s community initiative.  The camps were designed to introduce computer architecture and software development, with the lessons being designed by myself and Thomas Lynema (Bravo LT’s lead software developer). We were in discussions regarding making an advanced course for returning campers and older students…but then the pandemic hit. 

Keeping the students safe meant we could not provide in-person instruction, so Bravo LT’s owner asked us to investigate the possibility of setting up an online version.  Upon initial discussion, we identified what was required to provide a meaningful experience to our students:

  • Requirement 1: Only software development could be taught, as no in-person camps meant no hardware.
  • Requirement 2: Ensure that the tools we would use to teach would need to be accessible to everyone, regardless of hardware specs or OS.
  • Requirement 3: Every student attending would need high-speed internet and device capable of using a modern web browser.

Ensuring each student had access to broadband internet would be out of our control, so we set our attention to resolving redesigning the course and finding a means to make it accessible to everyone. 


Changing the Curriculum

Switching our focus exclusively to software development meant that we needed to significantly expand on what we would normally teach at the Pi Camps.  Python 3 was our bread and butter because of its lower learning curve compared to other languages, and since we had taught it before, sticking with it was the obvious decision for us.  But how would we teach a crash course for Python 3 in a matter of hours?

That’s when Thomas brought up this website that taught a full Python course completely in the browser, which made use of Jupyter Notebooks.  When activated, these would render JSON as HTML and executable python terminals.  In other words, this was an interactive textbook that allowed us to run Python in the browser.  The code used on the site was available on GitHub under an MIT License, meaning that we were free to modify and make use of it for our own purposes.  Since we only had a 3 hour course to work with, we decided to cut out a good chuck of the content and focus only on the basics (you can view the changes we made to the project here). 

Finally, we needed to figure out how many students we would be able to instruct at a time.  Typically, we would host around 15-20 students at an in-person camp (ages ranging from 10 to 14), which we could easily handle for the following reasons: 

  • Students could be paired, allowing us to chaperone groups versus individual students.
  • We had the benefit of seeing what they were doing on their assigned Raspberry Pi.  If they were goofing off, it was easy to call out so we could get them back on track. 
  • Being in the same room meant there would zero technical barriers blocking communication. 

Since none of these benefits were available to us in a virtual camp, we decided that a total of six students (3 to 1 student to instructor ratio) would be the most manageable. 

Now we had a curriculum to work with and an ideal instructor-to-student ratio established, but how were we going to host these lessons in a way that was accessible to everyone?


Hosting Our Content

With Raspberry Pis out of the game, we had to seek out a new environment for our students to develop in.  Early on, we knew that asking them to download code editors and Python interpreters onto their computers would be more trouble than it was worth, as we could not promise they would have a consistent experience across all operating systems and/or hardware.  Our best bet was to seek out a solution that worked the same across all platforms.  Once we knew that our content would come in the form of Jupyter notebooks, the reasonable conclusion was that the development environment would need to be hosted and accessed via web browser.

 We initially sought out existing web services that allowed Jupyter notebooks to be uploaded and run on their platforms.  Some that came to mind included Datalore, Colab, and Cocalc.  Unfortunately, none of these proved to be an adequate provider for what we were doing, as they all presented at least one of the following problems:

  • The service would have been too difficult to use, resulting in us spending more time teaching students how to work with it than helping them learn to code.
  • The service(s) were geared toward data science professionals or educational institutions, with the free tier acting as a trial.  Using their trial meant risking breaching their license, and we did not want to subscribe to a paid service if we could prevent it.
  •  Adequate performance for the free tiers was not guaranteed by the host, meaning we would risk our students having a lackluster experience with their platform.

Around the same time, I had been playing around with AWS for the purpose of learning DevOps, and wondered if there was a way we could host our own notebooks in a cloud service we controlled.  After some research, I came across this blog post that provided a step-by-step guide on how to setup EC2 instance for specifically meant for hosting Jupyter Notebooks.  Additionally, I was eligible for free tiers of the EC2 service, which provided sufficient resources for our course.  Seeing as this gave us full control over the development environment at no cost, we decided this would be the best approach.  In next to no time, I had Jupyter Notebooks up and running on an EC2 instance, which could be accessed globally from it’s IP address.  All students would need to do is navigate to site in their browser, and then login.  From there, they would find a directory with their name, containing a copy of our lessons.  We were finally ready to teach.


Hosting the Course

Our course was designed to be a one-day 3-hour event hosted via Google Meet.  Almost immediately after the course started, the realities of online learning came to pass.  One of the first struggles we hit was getting everyone’s microphone to work so we could communicate effectively.  Despite our best efforts, we were unable to get one of the students’ microphones working, forcing them to resort use the built-in instant messaging for any questions or feedback.  Additionally, we had another student who suffered latency issues while using their camera.  This issue somewhat alleviated when we asked them to turn it off.

When it came to teaching our content, we got the feeling right away that reading from the Notebooks were not keeping the attention of our students.  Even with content cut out, most of our lessons consisted of text, which is boring.  We tried having students take turns reading to increase engagement, but we found it did not work as well as we hoped.  Fortunately, we saw increased attention spans when it came time to write code for the exercises in our Notebooks. 

Our goal was to get through every Notebook in a span of two hours, and we had only completed a fraction of lessons.  Despite this, we decided we would move forward with the final part of our course and redirected our students to code.golf.  This site provides a selection of code exercises that can be written and executed in the browser, and our hope was that working on exercises together as a class would be more entertaining that reading and writing code in a notebook.  This resulted again in increased engagement from the students but bypassing a good chuck of our lessons made walking through each exercise very challenging.  When our course was finished Thomas and I came to the same conclusion; we had plenty of room to grow. 


What We Learned

As far as infrastructure was concerned, having a development environment setup in the browser worked out well.  Students had no issues running Python in the code editors provided on our Jupyter Notebooks server or on code.golf.   However, we did not feel students walked away with the level of education we had hoped to provide, and it was clear that our approach had a few shortcomings:

  • The textbook format of our lessons felt too much like a classroom than an interactive learning experience.
  • The open source course we based our lesson plan on was designed to give a comprehensive understanding of Python and software development and could not be adequately retrofitted as a 2-hour crash course. 
  • A single three-hour session may have been too long for kids in the middle-school age group, which may have contributed to the short attention spans we saw while working through each lessons.
  • Finally, while we did see the most engagement with code.golf exercises, they were still a little dry. At the Raspberry Pi Camps, we had the benefit of using programming to control toy cars remotely, but here we were having students solve math problems programmically.

If we were to host an event like this again, we would need to:

  • Write our own lessons from scratch, and design them to be completed in under two hours.
  • Split the class into multiple sessions. 
  • Try to find more engaging content the students could work with after we worked through our lessons.

In Part 2, I will discuss how we applied what we learned to the next camp and elaborate on whether we saw improvement.  Until then, take care and have a wonderful day!