Edutainment For Kids!

“Edutainment, both inside and outside the classroom, helps to make learning fun. American illustrator Peter Catalanotto coined the term in the 1990s while teaching students about writing and illustration.” — American University, School of Education.

What is “Scribble Stadium”?

Scribble Stadium is an interactive learning platform for grade school children. It was founded by a man named Graig Peterson, an ex-classroom teacher, now a pioneer within the EdTech scene.

Screens are all around us, and kids use them often. Most of the time to play games or do something else outside the realm of educational material. Scribble Stadium is well aware of this dilemma, and they are here to help! This is done by gamifying creativity, which turns “reluctant readers” into authors and illustrators, through a collaborative world-building game.

“Story Squad” was the original name of the application, it is now called “Scribble Stadium”

An imposing task

There had been many other developers who worked on the codebase for Scribble Stadium before me. This made it into the largest repository that I had ever personally seen, so it was incredibly daunting to navigate at first. The sheer number of files… I was a little fearful that I would not be able to wrap my head around what was happening. Then I was concerned that this would cause me to become an ineffective teammate, and in turn, prevent us from completing the task that was assigned to us.

The cohort that I was in, LabsPT22, was split up into three teams. I ended up on Team C. Our team was assigned the responsibility of swapping authentication services, from Okta to Auth0. The Scribble Stadium stakeholders had a problem with Okta, which was a less than seamless and thematically incongruent service in comparison to Auth0. The idea was to swap the services and that would fix the problem.

As we began to learn more about Okta’s authentication flow, Auth0’s flow, and how to plug those elements into the codebase appropriately, we were given roles to fulfill during our time in Labs. These roles were set in a “choose your own adventure” style by having us rank our preferences for a set of specialized roles. The roles included the following:

  • Technical Project Manager
  • UX Engineer
  • Frontend Engineer
  • Backend Engineer Node

At first, I was leaning towards the Frontend Engineer position, which would have kept me a little bit more in my comfort zone, but I decided to make it my second choice and volunteered for the role of Technical Project Manager.

Off to the races!

As the Technical Project Manager, I was responsible for coordinating the workflow for our team. Product features needed to be scoped down as specified by our roadmap, first into user stories, and then into technical tasks that the team would complete providing solutions for the product. Our first user story read something like this:

“As a user, I want to be able to securely login/sign-up on the Scribble Stadium Website, so that my child can benefit from the Scribble Stadium experience.”

Gif of the Trello Process.

Once we had formulated the proper user story, we began to break it down into smaller tasks. The first being; Research of Auth0. We utilized Trello to manage our scrum processes as seen in the gif on the left. It was vital for keeping us organized and on task throughout our labs experience.

After researching Auth0 and its implementation, we came away with a few takeaways. The first was that conveniently, Auth0 provided a perfect universal Log In/Sign Up form component that could be styled to complement our application, as well as make it secure.

Universal Login/Sign-Up example.

The second takeaway was the realization of an important npm library called “@auth0/auth0-react”, which is the Auth0 software development kit for React Single Page Applications. This library was foundational in setting up the services that Scribble Stadium needed to solve the problem of user authentication. To get started with this library we had to configure the software development kit by wrapping our application with an Auth0Provider, like so:

Auth0 Provider wrapped around our App.

The third research takeaway was that we needed to implement a hook called “useAuth0” within our components to access authentication state (isLoading, isAuthenticated, and user) as well as authentication methods (loginWithRedirect and logout).

This concluded most of the research necessary to understand how Auth0 needed to be implemented, so it was time to roll up our sleeves and dive into the code.

A long list of FE components needing Auth0 authentication.

We again leaned on Trello to help us organize, as we went through the entirety of the frontend codebase, and found a long list of components that needed Auth0 integration.

The list extends past this screenshot, totaling up to around fifty different components that needed attention.

I took the list of components in this Trello card and turned them into a checklist. I feared that we would miss files if we did not have a proper way to keep track of what was complete and what was not.

Of the original fifty components that needed Auth0 integration, I assumed the responsibility for twenty-four of them.

A front-end component updated with Auth0.

In the image above, arrows are used to denote the importation of the @auth0/@auth0-react library, useAuth0() hook, user, and isAuthenticated, into the component to successfully integrate Auth0 for authentication state management. This process was conducted twenty-three more times to complete my portion of the front-end component list.

An unforeseen technical challenge was regarding test files. These test files were associated with the files that had new Auth0 integration. All of them were failing. This problem was first found while creating a pull request off of the branch that I made, “feature/okta-to-auth0-element-swap.” Our Github organization was set up to run tests to determine if the test files would pass or fail. If they failed then the pull request would be incapable of merging into our “main” branch.

After diving into the test files to determine what exactly was going wrong, I realized that the test suites were attempting to call methods from Okta. This was obviously impossible to do since we just got rid of Okta throughout the list of front-end components. All of the test files needed to be updated to reflect the new Auth0 authentication service. Once this was determined I set out to change all of the test files that were my responsibility like so:

Changes made to update a test file for a component.
All tests pass! (skipped tests were not associated with our team).

This auth0 process was injected into the rest of the test files, and eventually, they all passed.

The Current State of Scribble Stadium, and beyond.

Scribble Stadium currently has Auth0 authentication integrated into the app. No more need for Okta. This big task was one of two that had been assigned to us as a team, the other was to work on integrating Stripe into the application, for the purposes of managing payments for customer subscription plans. Unfortunately, we only had enough time to tackle Auth0 integration. It turned out to be a bigger task than originally expected by the managers and stakeholders.

New and improved login/sign-up form.

Remember the universal login/sign-up form from before? In the gif on the left, you can see the updated form, which reflects the rest of the app's themes and design schema. The style was updated by the UX Engineer on our team. He did great work.

Regarding future features for Scribble Stadium; I could see Stripe integration being high on the list for work to be done. I would not be surprised if the cohort immediately following us is assigned to work on that task. Like most features, it is typically a challenge to take whatever you are working on in the front-end and have it talk to the back-end perfectly. The Stripe feature will probably take a lot of work to understand, implement, and troubleshoot. Then on top of that, it has to be stylized to work with Scribble Stadium.

I received feedback from my peers and my Technical Project Lead throughout my time in Lambda Labs. They revealed things about me through constructive feedback and criticism that helped me to grow. Things like:

  • Need for greater details. When talking about my work, or work from others on the team, a theme of insufficient details surrounding my writing was apparent. In labs, we were required to work hard in gaining the skills necessary to talk about our work. To tell a story. To paint a picture. My TPL, as well as my colleagues, helped me to understand that the way I write needs further examples to provide clarity. I have taken this feedback seriously, and have done my best to improve by adding more to the stories that I tell.
  • Feedback from my peers on Team C partially came from the use of an app called, a fascinating application that helps people to provide valuable feedback for their teammates. My team had a lot of great things to say about me, but two things stood out to me that I need to improve on.

To the left is a diagram of some of the feedback that was given to me. According to this, I would benefit from practicing more self-reliance, as well as becoming faster in working on my tasks and tackling challenges.

I do agree with it all. As I move forward I plan to increase my speed by becoming more familiar with web development in general. More experience can equate to more speed, as well as more self-reliance. As a junior developer, it has been difficult to create a sense of self-reliance within myself. Fear maybe, or the imposter syndrome setting in, but regardless I will improve, as self-reliance is desired quality for myself.

Finally, I must reflect on the impact that working on this project has made on my career goals. It has helped me to evolve and grow into a more confident and capable developer. Before going into labs I would not have thought that I could be a Technical Project Manager, helping all of the engineers on my team to accomplish their goals, but I did! If it was not help directly from me, I made sure to help them get the help that was required to get them unblocked. I practiced my organizational skills in Trello. Practiced the Github workflow with our branches and pull requests. Helped to review and merge pull requests. Think of user stories and how they are broken down into more manageable tasks. Discussed features and requests with the product stakeholders. And much much more! I am thankful for each person that I had the privilege to work together on this product.

Scribble Stadium is an amazing application, and I can’t wait to see where this stepping stone of experience takes me next on my web development journey.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store