Case Study: An In Depth Look at the Curriculum for APIs

Why this particular lesson for an in-depth look?

APIs are a “set of methods of communication between various software components” (Rascia 2017). This can refer to a particular software’s ability to extract data from another software, and incorporate this information into its own applications. This is done by sending a request and recieving a response. The use of APIs is extremely useful, as it is a convenient method for one software to utilize information, such as data and algorithms, that has already been established.

In picking a lesson to take an in-depth look at curriculum, I looked for one in which I could evaluate both Girls Who Code’s provided resources and the decisions made in the classroom by the teaching team. I believe that the lesson on Application Program Interfaces (APIs) in the Web Development unit meets both these standards. First, APIs are powerful and useful programming resources, and the teaching team felt that it would be important to introduce APIs to students and inspire them to think of ways to incorporate them in the future, such as their final projects. Second, as this lesson was particularly difficult to teach and required a significant amount of reworking, I believe this is an appropriate lesson to study, as it can strongly represent the teaching team’s decision-making and adaption of curriculum to our own class. Additionally, three out of five of the final projects ended up using APIs. I believe its consistent presence in the final projects is tangible evidence of successfully teaching a challenging topic.

Go To The Original Lesson
Go To The Teaching Team's Addition
Go To APIs Used in Final Projects

The Original Lesson

Go To Hook and Introduction Go To How to use an API
Go To Women in Tech Spotlight Go To API Project - Build and Test Go To Journals and Wrap-Up

Hook and Introduction

Before jumping into teaching technical coding skills or working on projects, the Girls Who Code curriculum begins its lessons with introductions and warm-ups that show students the relevance and significance of the particular topic. Much of the curriculum was designed to begin by providing students with examples of how coding is used in everyday applications (Cooper & Dierker 92), it is important to demonstrate these applications to the students. When introducing students to an application of computer science, it is important to find examples with the right balance of being relatable and being unique, and that have recognizable fundamentals yet leave students amazed at the complexity and curious about how it was made (Montfort 108). These demonstrations are important in giving students an understanding of the bigger picture and what they can accomplish in the future. The focus of the Summer Immersion Program is not what projects students are creating in that summer, but for girls to want to continue coding. Aspects of the lesson will inevitably be difficult, yet these examples can serve as inspiration for students to return to topics they were briefly introduced to and pursue them further, whether it be in the final projects, while in high school, or in college classes.

For this particular lesson, the hook for the day was having students look at the a showcase of 51 web apps (which happened to be built by women!). The website that listed these Web Apps included descriptions of each project and a list of the APIs the engineers had used to made them. This would give the girls an opportunity to see examples of APIs, recognize their usefulness, and begin considering how they themselves would want to use them. While the girls wouldn't have a formal defintion of APIs at this point, exploring how they had been implemented by others gave them a hypothesis as to what they are and realize how they might have previously interacted with APIs in websites they actually use. Below is the slide containing instructions for conducting this investigation and a link to the website students were directed to.

How to Use an API

Code-Along

Code-alongs typically were a successfully method of teaching girls new information, as they provided explicit directions and examples of how to use each specific new concept or function. In addition, asking students to manipulate certain parts of the code and hypothesize how if change the code’s output helped build familiarity and intuition with how code words (Montfort 107). Going step-by-step, making the code more complex in small increments gave students a starting point that allowed them to feel in control of what they were learning, which gave them confidence to move on to the next step (Eney et al. 49). Keeping all of the students on the same page was also very useful for the teaching team to evaluate the progress of the class and know exactly which additions of the code were causing difficulties for everyone (Muller & Kidd 184).

Why this lesson was difficult:

However, this code-along was not as successful as previous lessons. I believe this is because its end product was too ambitions. Rather than using the code-along as an opportunity to introduce girls to fundamental concepts, the code-along was designed for students to reach an end product of an interactive map.

The curriculum provided slides and a sample solution. We alternated by explaining the slides and then using the sample solution to lead a code-along. Both the slides and the sample solution were broken up into seven steps. The lesson had students incorporate APIs into JavaScript, which the girls had only learned they day before. This added an additional layer of complexity to the lesson because the girls had to not only apply a brand new concept, but also do so in a language they are still familiarizing themselves with. In each step, students were responsible for updating and HTML file and a JavaScript file. Additionally, APIs were buried deep into the lesson. In a seven-step code, APIs did not appear until steps five, six, and seven. By the time students had reached these steps, they were already exhausted. The corresponding slides for these steps provided introduced the concepts of forming requests and receiving responses with analogies and samples. However, there were no opportunities for students to engage with the concept through coding simple tasks. Instead, they were expected to transfer what they learned about hypothetical examples to already complex code. As students were still confused about APIs and frustrated with the project, we knew that students would be blindly copying down code. Even if they had the energy to try to understand each line, we knew APIs were still a very abstract idea to them and they would struggle. We ultimately chose to end this lesson early once we decided that continuing would no longer be productive.

Women in Tech Spotlight

Women in Tech Spotlights were included with every lesson in the Girls Who Code curriculum. Each spotlight introduced students to a woman in the computer science field and highlighted her accomplishments. When possible, the spotlight also included additional information about her path to that particular field or the passions behind her work. The spotlights were strategically placed based on matches between the woman’s work and the lesson of the day, so that students could see how a woman was using coding in that particular field. For example, in this particular lesson, Tiffany Taylor’s use of APIs in her projects was highlighted.

The effect of the spotlight varied day-to-day. Some days, students learned about women working in fields they had never heard of or on projects that they never could have thought of, expanding their definition of computer science. Sometimes, students connected with the spotlight’s passions. On other days, students learned about the woman’s story and the qualities she had that helped her succeed. By providing students with real life role models of computer scientists, students could see themselves being part of the computer science field themselves as well. Ultimately, as the girls described in their journals, the spotlights were a valuable addition to the curriculum and worth the class time.

API Project - Build and Test

This project was for students to add an API to their personal website they had built earlier in the week. This project was very open ended, in allowing students to discover their own implementations of APIs (Montfort 107). As our students did not have a deep enough grasp of APIs to begin learning on their own, we decided to skip this part of the lesson. We believed that asking students to begin a project when they felt lost from the beginning would create more frustration than benefit.

Because we didn't move on to the project and didn't want to burn the girls out, we decided to let them use the rest of the day to make additions and improvements to the personal websites they made during the two previous days of class.

Journals and Wrap Up

At the end of the day, we took first took time to apologize to the girls for not being as prepared as we should have been. We let them know that we believed the lesson was too complex for a beginner lesson, and that had we been more familiar with the lesson, we should have recognized this earlier on. Admitting our mistakes is important in creating a learning environment in which students can trust their teachers, advocate for themselves, and know their voice is heard and their opinions are respected (Eney et al 49).

The girls submitted journals at the end of every day, which is beneficial to both them and us. It gave the girls the opportunity to reflect on their day - some questions we believe were most beneficial to the students were asking what they were most proud of figuring out that day and what they saw another student do that they were impressed with. It also provides feedback about lessons and extra insight about the day that we found extremely valuable (Muller & Kidd 184). While we generally had a good read on the class during the lessons, the additional explanations of how students felt the lessons went were very helpful, especially in moments where students were very open and brutally honest. It also let the students share stories of things that happened during they day that we didn’t catch. We tried to show students that their opinions were valuable by implementing changes in the lessons based on their suggestion. We believe this ultimately created a learning environment where students could trust that every activity we did had purpose and was in their interest.

One big change we made to the curriculum was after the first lesson of Python, which was very difficult for the girls. Taking time to read the girls’ feedback allowed for us to design a lesson that was better suited to their needs. After this lesson, their journals were crucial in showing us how our lesson was received. In this case, knowing that we had succeeded allowed us to confidently move on in the curriculum and reuse these strategies when reworking future lessons.

We found that it typically takes the girls about ten minutes to write in their journals. We never wanted them to feel rushed, so we tried to leave the last fifteen minutes of class for their journals. We also gave girls the option to write their journals on their way home, which gave girls who rode the bus a fifteen minute window to walk to the bus stop and catch their bus. We appreciated the responsibility of the girls who rode the bus for responding to the journals as soon as they had the chance. We were glad to help make their commute home faster and less stressful, making this program more accessible to them (Eney et al 49).

This was not the first time that we had gotten negative feedback, and from similar experiences, such as during the first Python lesson, we were not scared of the negative feedback because we knew we had reworked lessons in the past and that the girls had responded well to. Below are some excerpts of journal entries of girls who provided explanations of why the lesson was hard for them. As most of the girls ended up copying and pasting without understanding what they were adding to their code, they felt like they did not understand what they were doing even if they were able to get their code to work.

The Teaching Team's Additions

While we never ended up doing the API project, there are so many possibilities that I knew our girls would have had fun with it if they had been more comfortable with APIs. We felt it was important to reteach this lesson because we felt like it is a useful topic to know. Even more, we didn’t want the girls to leave feeling defeated by a topic and scared of incorporating it into their final project or intimidated of learning it in the future.

The most important thing that we changed was making our lesson have a much smaller goal. Rather than having the students integrate an API into a webpage, we decided to teach the students API fundamentals through a site specifically designed for educational purposes. Using this website and a powerpoint we had made, we were able to isolate the steps and walk them through requesting and retrieving information from APIs. Making requests through a web browser, rather than through JavaScript, allowed students to directly interact with the API and immediately recieve requests, without that added obstable of coding in JavaScript. This allowed students to participate in the learning, instead of feeling like they were only copying and pasting (Cooper & Dierker 97).

In this lesson, we also made sure to thourougly explain every step and participate in each step together as a class. First, to introduce the concept of requests to the students, we showed them how to make a request in a web browser. Making a request in a browser instead of through a JavaScript allowed them to make their first request in a familiar, user-friendly, and non-intimidating way.

Second, we showed students how to understand the response they recieved. We helped students distinguish betwen the components of the JSON response. For example, we had them identify what part of the response contained the dog's image and how they would extract it.

Next, we taught the class how to change the parameters of the requests they send. Parameters allow user to set specifications for the responses they will recieve. We gave them the opportunity to discover the capabilities of the API by using the documentation of possible parameters as a guide.

Once students were comfortable with the idea of making requests and recieving responses, we finished the lesson by providing some suggestions of fun and user-friendly (intuitive and with good documentation) APIs. If we had time to build on this lesson, we would have liked to have our girls make a very simple website to interact with the dog API, such as a web page that displayed a random dog image. However, although we didn't use APIs in actual code that day, the mood of the class told us that we had succeeded in making students more comfortable with and intersted using APIs in the future.

APIs Used in Final Projects

While we never ended up doing the API project, there are so many possibilities that I knew our girls would have had fun with it if they had been more comfortable with APIs. The final projects were a perfect opportunity for the girls to practice using APIs, and we encouraged them to do so. Looking for an API that fit the need of their project was similar to the creative purpose of the original API project (Montfort 107).

Something unique about the nature of this program’s final projects is that the teaching team was able to be very involved. Unlike typical classes where group projects are mostly completed outside of the classroom, we were present for the entirety of their work time. The teaching team divided up among the projects and became partial members of the groups, demonstrating and then facilitating what it looks like to be a leader and team member (Eney et al. 49). Due to our involvement in the projects, the girls knew that they would have the teaching team’s support and guidance. This gave them extra confidence to dream big and take risks, knowing that they wouldn’t have to figure difficult concepts out on their own. Three groups found APIs that they wanted to include in their project. These groups’ projects are included below, highlighting the APIs they used.

One of my biggest fears after the original API lesson was that students would be too discouraged to see APIs as a topic they would want to return to. As girls had never used APIs to the extent that would be needed to incorporate them into their final projects, the girls’ confidence could not come from knowing that they had already accomplished a similar task. Their confidence and determination was crucial, but it was going to have to come from somewhere else (Eney et al. 49). In the second API lesson, our goal was to reintroduce APIs in a way that was less intimidating. I believe we accomplished this goal by rebuilding the confidence and resilience they approached using APIs in their project, as described by one of the girls after her first day of working on the chatroom API for her group.

Impact of Curriculum

Resources