Help A Peer is an extension in zoom to help elevate some of the common stresses received by teachers. In the array of teacher interviews, we heard common themes that students seemed disengaged and were missing peer to peer interactions. When students came back to remote learning, teachers were struggling to keep students from talking to each other. We saw this as an opportunity to make grouping in class easier.
The ideal idea was to try to get students to learn from each other. We thought if we paired strong students with weak students we would be getting a double effect. The stronger students would learn better since they are reiterating concepts they already understood. The weaker students would hear from a peer on how they understand the concept and they would get more one on one action.
At first, we wanted to pair students up based on understanding of concepts so we needed a quantitative subject since we could easily measure if a student answered correctly. Then we could do groupings based on those answers. We decided that the most quantitative subject we could use was math.
For the age demographics, we wanted to go with upper elementary students (grades 4, 5, and 6). Most schools in the US followed the common core standards. For grades 4 and 5 students were learning concepts that we knew were easier to check for.
Why this age group?
Children start to lose interest in math after the age of 13. We thought it would be better for playtesting if we focused on this younger age group. They would be more engaged in the concepts being taught. In addition, we were also aspiring that this tool might re-engage students to keep interests after 6th grade .
We also thought that this loss of interest might be tied to a lack of understanding of fundamentals that concepts later on build upon. Our tool might have helped fortify those fundamentals.
We focused on three key pillars based on the commonalities we heard from teachers.
The main Goals/pillars:
- Smart Quizzing
- Ability to give concept question easily
- Easily grade them and get quick feedback on class performance.
- Smart Grouping
- Make grouping easier especially grouping by skill level
- Small group Support
- Allow the teacher to interfere and check up on the students
- Have that walk around feel in the
- A Zoom extension with the goals/pillars implemented
- Documentation on how this tool might be useful for teachers and researchers
This project was a pitch project and it gave the opportunity to see what we could do with ZOOM as a platform. There wasn’t a specific client but we were able to partner with Nativity School of Worcester to playtest and observe their Zoom class sessions.
The project was initially pitched by Ebrahim Karam, Ryan Eckert, and Zhiran Xu. We needed a UI/UX designer to join the team for the mockups and the visual assets for the team. We were lucky to get someone as talented as Hanhui Lu on the team.
Team Member Roles:
- Zhiran Xu (Karen) : Producer and researcher, Team Point Contact
- Ebrahim Karam: Programmer, Designer
- Ryan Eckert: Programmer, designer
- Hanhui Lu: UI/UX Designer and artist
What went well
We were able to find a vast array of resources and expertise quite easily. Our faculty advisor Jessica Hammer was able to give us introductions to people who are working in a similar field. We were able to talk with a few postdocs who works with Ken Holstein’s lab (https://www.thecoalalab.com/).
The guided us through the swarm of literature and pointed us to the dissertation by Jennifer Olsen (“Orchestrating Combined Collaborative and Individual Learning in the Classroom”)
The paper describes a system that would group activities in the classroom. It simply described a prototype. The paper validated the importance of our idea and gave us a sold research background behind our claims.
The paper gave ideas and we refined them through a figma mockup that made it easy to showcase early on what we were thinking. This gave us quite a boost during quarters and really gave us some rails during the programming stage.
The mockup helped to recruit teachers and schools that we wanted to playtest with. At the end, we wanted a product that teachers would use and usability was high on key metrics.
There was a lot of interest from teachers in Pennsylvania and Massachusetts. We even got a few teachers in brazil interested in the extension.
The team dynamics were quite helpful. We were able to resolve conflicts and prioritize what we thought was more aligned with an MVP.
We were also lucky that Karen had friends from her undergraduate who became teachers. This allowed us to have a bit more casual conversations with teacher, and therefore, more insider knowledge of the remote classroom setting.
One of the contacts that was most helpful was Nativity School of Worcester. They allowed us to see how their classes were being run and there wasn’t much red tape on playtesting and observing the classroom. They even gave us co-host privileges during the class session.
What could have been better (or what went wrong)
Using Zoom as a platform instead of Google Meet or Teams
There were limitations on the technical side in terms of what we could do. We wanted to use Zoom since it had an SDK on which we could build our tool on top of. Zoom was a popular platform at universities but most schools used Google Meet (as part of their Google for education bundle) or Microsoft Teams for their remote classrooms.
Even though we had a lot of interested teachers on the platform they could not test it in the classroom since it would be a platform that was not supported by the IT infrastructure at the school, and getting something like this running in a school will require us to get through a lot of red tape. This is the reason why we couldn’t go with Pittsburgh public schools as we initially pitched. They are the largest school district in Allegheny county but their default conferencing tool was Microsoft Teams.
Video conferencing tools used at schools
The lack of Multi Platform option for the SDK
You can check our developer’s article here on the different SDKs for the platform. (Link to in depth article).
In short the only SDK that had the breakout room functionality was the Windows SDK. This meant we could only playtest with teachers that had a windows PC. In order to streamline development and testing we preferred that they had a windows 10 machine since Ryan and Ebrahim were developing and testing on that OS.
John Balash was able to get us with a school that used Zoom for its classes. (Quaker Valley School District). However, they’re teachers used Macs so we couldn’t test with them without getting through red tape.
In the end, our criteria for playtesting was dependent on the conferring tool and OS used by the teacher.
Small Group Support
We heard on multiple occasions that teachers wanted to see and hear what was happening in the breakout rooms. In an actual school environment a teacher could walk around between the groups and check up on them and interfere when needed.
One of the postdocs (Vanessa Echeverria) we talked to introduced us to Zoomsense. (https://zoomsense.io/#/scheduled)
We were able to get the demo of the tool and saw the capabilities. It was able to get information from the breakout rooms. It could tell you who was talking the most and if the breakout rooms were silent.
This gave us some premature confidence that we could get data from the breakout rooms. However, after initially trying to set it up ourselves we found more than one technical limitation. We were lucky enough to have a conversation with one of the developers at ZoomSense (Tom Bartindale from Monash University in Australia). He was kind enough to talk to us and give us an in depth of the limitations they faced developing for Zoom. It was also quite hard to accommodate for the 14 hour time difference when scheduling.
The conversation opened our eyes to the tech resources required to get required.
- A windows machine with Docker setup. Each docker instance would be dedicated as a listener to a breakout room.
- Firebase as the connector between the docker instances and web client.
- Some tedious initial setup on the users end to get it going
We decided that the endeavor would be wonderful to document and point to. but was beyond the capabilities of the team to implement as part of our project.
We decided instead to focus on student support. We focused instead on gathering data the ZOOM SDK allowed and leveraging that info for the teacher to support students.
Zoom SDK was not as refined as we hoped
The Zoom SDK is pretty recent. It was initially released in 2016 but the development community is pretty small because of the paywall to get access to it. In order to access the SDK, you would need a ZOOM pro account which is 15 dollars a month.
It would be important to note that Ebrahim has the licensed badge on the dev forum which is owned by only 14 other developers in the world. Attached is the badge from Zoom.
We also ended up finding answers to our own questions even though Zoom Staff were aware of them and contributing. In a way we gained more expertise than the people who were supposedly maintaining it. (You can see one specific thread here) Some questions required weeks of back and forth between Zoom staff. This was due to either unclear documentation or badly managed SDKs.
There was also a couple of issues with the C# wrapper that we needed to modify ourselves. We wrote the troubles we faced in the articles below
Lessons learned and conclusion
In the end, we have got a very promising beta that we were able to use in a live class session with the Nativity School of Worcester.
There has been a consideration if what we created is better than the alternative.
To summarize the Help A peer extension does the following:
- Easy access for taking notes on the participants
- Administer questions to the class and collect answer
- Suggest grouping based on the answers
- Collect Zoom data on the participants
What about an alternative
|Our recommendation||The Frankenstein Approach|
|Help A peer||Mentimeter|
|A word document for the notes on students|
|Assessing the quizzes and then forming the groups in an excel|
|Manually timing everyone’s talk time and keeping count of raise hands or wait for the feature to be implemented (link)|
The Frankenstein Approach
A teacher would need to create a set of questions beforehand on a Mentimeter. The questions would need to be in a Mentimeter style PowerPoint, or embedded in their PowerPoint presentation. Students would then need to have access to their phone or another tab and switch from the video conferencing tool to Mentimeter to answer the questions. Check the videos below on how to use Mentimeter with zoom.
If the teacher wanted to do groupings based on the answers, they would have to make sure that the data they collected through Mentimeter was not anonymous. This would mean that students would need to enter their name before entering an answer to a quiz. You can see the various possibilities below.
The teacher can then download the data for the students. If they wanted to set up groupings based on similar or varied skill level they would need to do that separately and it wouldn’t be possible to have it done in real time. The grouping would need to be done manually or through a complex excel spreadsheet with custom selection formulas.
If a teacher wanted to take notes while administering a quiz, she would need to switch to a word document or google doc constantly moving from the Zoom window to the notepad document. It would also be less ideal when the teacher is administering a quiz through Mentimeter as they would now need to be aware they shared the presentation only and not the entire screen.
HAP also provides data on student form the ZOOM SDK such as how many times they raised their hand and how much these students contributed to the conversation in the class. This information would need to be recorded separately by the teacher.
The teacher would simply need to login to the ZOOM meeting with the HAP extension. They can create a question before or during the class. They can screen share that question with the class and they can always be sure that they are only sharing the question so they can take notes as they share the question. The students answer through Zoom so they wouldn’t need to log into another app or use another device or defer away from the Zoom Call. They send the answer through chat.
The teacher now has the students answers logged so they can group students based on their abilities.
As all of this happening, HAP is logging how many times a student has raised their hand and how much each student is contributing to the conversation.
You can see a video of how this would look at the link below.
What did we learn
There were a lot of hurdles along the way and there were times that we were making plans without knowing if we can actually make something happen. We were still fighting with the tech as we were trying to find potential playtesters.
At times, we thought that we bit more than we could chew. We went in thinking we would have something pristine and polished that was ready to use. During the semester, we were discovering continuous roadblocks that required us to reassess what we could actually do. In the end, we have learned a lot about having Plan B, C, D to complement with our perfect solutions, and what would happen if those don’t come through for us. We learned to adapt and utilize the resources that are available to us and be open minded.
We had to let go of certain ideas we wanted initially and face a few facts. We also needed to set expectations especially to our playtesters and be honest about the limitations we were having.
In the end, this pitch project has caused each of us to grow and challenge ourselves. We built on a product that we were using everyday, that might not be 100% product ready, but does pretty much everything we set out for it to do, and it gave us a look on what can be augmented and improved on this new platform.