Introducing SchoolBot: A GPS Tracking Application for Parents
Getting the kids ready and out the door in the morning to catch the bus is one of the most challenging moments of each parents day. That’s why we created SchoolBot, an application that helps parents track their child’s school bus in real-time using a smartphone. First launched in Brockton, Massachusetts, the morning routine is less stressful for 17,000 students and their parents now because of SchoolBot.
Before SchoolBot, Vermonster launched a similar product, “Where’s My School Bus?” with the City of Boston to serve 120 schools. Code for America, a nonprofit that builds open source applications for city governments, built the first prototype in 2011 after the city went through a particularly harsh winter that resulted in significant delays and with families waiting for up to 30 minutes in the cold. As many families know, weather and mechanical delays mean disrupting the morning routine of students and can lead to missing the bus or forcing a parent to be late for work after dropping a child off at school.
While the app is still in use today, we saw some areas in need of improvement relating to the complexity of the application that limited new feature development and the app’s accuracy and reliability. We decided to rebuild the application from the ground up, branding the application as SchoolBot while continuing support for the open source model that Code for America started.
To ensure the app’s consistency, we needed to point out defects even before the product came online. We did this through testing. One such test I’ll mention here is called acceptance testing. Acceptance testing is the use of an automated script that steps through a user’s workflow within the application, simulating a user’s interaction with a feature under various scenarios. For example, the script would click through the app as a first time user. The script confirms the user can’t add students without first confirming their email and then that an email was actually sent.
We do this not only to ensure everything is functioning properly under different scenarios but also to confirm that new features don’t break any existing functionality.
Before we got to the build stage, we had to capture the product’s requirements in a succinct way that didn’t eat up a lot of time. The best way to get feedback on the product is to create prototypes with which users could interact with. We prefer an iterative cycle of product releases over developing production specifications up front, which requires extra time and more often than not, fails to capture the user’s perspective.
Our goal is to place the application in front of users where we could get clear and in depth feedback about the product. Having conversations with actual families using our product allows us to create user stories. A user story is how we document and drive requirements of our product. It enables us to outline a specific feature including the user’s role, objective, and context in a consistent format:
As a ___, I want __, so that ___.
In the larger context, the purpose of a user story is to clearly relate a feature for the developers to better understand why a functionality has been requested. An example of a user story we used in SchoolBot:
“As a parent I would like to receive a notification that the bus is approaching so that I can get them out the door on time.”
It’s important to the quality of the application that the developer responsible for implementing a specific feature is able to place themselves in the user’s shoes. For example, the developer might then imagine they would need to include settings for a parent or caretaker that is responsible for a student only on certain days of the week. Additionally security of information in this day and age is of utmost concern for applications.
“As a school superintendent I want to share a student’s location without sharing personal identifiable information so that I will be in compliance with federal and state regulations.”
Here, we learned about the security concerns of the school administrators who not only have to comply with regulations in the Family Educational Rights and Privacy Act (FERPA) but also how to communicate security concerns to parents and the community.
Incremental releases, user interviews, story formation, and acceptance testing were some of the inputs into SchoolBot. From development to post launch we learned a lot about how people interacted with the application and how to build a reliable and consistent product. SchoolBot is currently available for free to parents to use in their school district. Find out more here.
