Techpoint S.O.S. Challenge Transportation Team 03

Overview

As college students eager to make a difference in the world, we all were preparing for traditional summer internships and applying our skills to change the world. The advent of the Coronavirus pandemic erupting and paralyzing the global community abruptly redefined every aspect of our lives. How could we make a difference now? All of us for different reasons heard of TechPoint's summer remote opportunity and applied. Who knew during a global pandemic, that five students together could virtually collaborate and unite our diverse skills and experience to solve real-world challenges and make meaningful change to help others? We were tasked with proposing and developing a technological solution to secure public safety for those who utilize public transportation in Indianapolis. Our team designed a mobile application to allow bus riders to reserve seats on the bus. The mobile reservation system unilaterally eliminates people's time waiting for a bus and ensures reserved seats are adequately spaced. The full implementation and realization of the IndyGo bus system's mobile application will effectively protect our essential workers, restore confidence in bus riders regarding public safety on IndyGo, and increase ridership.

Team Members

Kayleigh Francis

Kayleigh Francis, now a junior in Computer Science at Purdue University, and a resident of Metro-Detroit has always been connected to the transportation industry. Working as part of the Pro Squad, she utilized her experience and coding skills to address the transportation challenge, and contribute to app development. Some of her contributions include a confirmation email/PDF download system, UI features, and app-server communications.

Thomas Jettpace

Thomas (Wiley) Jettpace comes from a small farming community 30 miles west of downtown. With undergraduate degrees in Anthropology and Psychology from Indiana University, Bloomington, and an in-progress masters degree in Human-Computer Interaction from IUPUI, Wiley brought to the team a human-centered outlook and research/design skills. Wiley’s specific contributions to the project include early research, ideation, the initial information architecture, the visual design specifications, and minor contributions to the front end source code.

Jonathan LaRosa

Jonathan LaRosa is a rising senior at O’Neill School of Public and Environmental Affairs at Indiana University Bloomington. He was adopted from Beijing, China, and is pursuing a Bachelor of Science in Law & Public Policy with a minor in Human Resource Management. He was privileged to collaborate on the product's market research and development.

Andrew Orians

Andrew Orians is a sophomore Computer Science student at Rose-Hulman Institute of Technology. He served on the Pro Squad, helping to build out functionality on both the app and the server. Specifically, he made much of the verification and storage system for reservations, as well as implemented much of the app’s UI based on previous designs.

Patrick Quyle

Patrick Quyle is a second-year Master of Information Sciences student at Indiana University Bloomington. Patrick also completed his undergraduate degree in Informatics with a business minor at IUB. For the purpose of this project, he served as the project manager and business analyst. In this role, he conducted research, provided design feedback, created documentation, and helped to develop the marketing campaign.

How did we decide on this customer segment, problem, and solution?

Upon review of the materials made available to our group through SMEs, we made the decision to conduct further research into the Indy Go system. Research was conducted based on the Indy Go website, and public transit systems in Chicago and Bloomington were identified for points of comparison.

Seeing how these cities all faced similar challenges of declining ridership, our group determined that these numbers would continue to be linked to the current stage of quarantine that a city is in. Rather than attempt to attract riders immediately, we realized we could make a greater impact by creating a product that helps those currently still utilizing public transportation.

With this line of thinking in mind, a high-level value chain of analysis of the typical rider's experience was conducted based on a team member's experience with Indy Go. The primary focus was finding actions that did not allow for proper social distancing. Bus stops were identified as a problem area as they involve spending an extended period of time waiting in close proximity to other riders.

Using the correlation between declining ridership and a cities stage of quarantine, it was determined that essential workers were the primary persona to utilize this system. The secondary persona of college students was decided on after reviewing a 2018 Bloomington Transit Report that held information on the agreement between Indiana University and the city of Bloomington for student transportation. Our other secondary persona of tech professionals was inspired by the TechPoint events in which we heard many young professionals speak highly and passionately about the Indianapolis community.

How did our team build and iterate on the solution?

Further research was conducted into the current applications utilized by Indy Go, and our team determined that our product would need its own platform. An interactive wireframe was designed through Adobe XD and distributed to the team for feedback. The wireframe was updated based on feedback and changes were made based on a styling guide that highlighted the current practices of Indy Go.

With the design in place, the pro team began developing the product. Through a weekly demo with the go squad and coaches, iterations to the design were made, particularly focusing on the information architecture and how to efficiently collect the necessary information from riders. During this process, several additional features were added and points of ambiguity were clarified by focusing on edge use cases.

Key Metrics

Fact Finding

3 Surveys
2 Interviews
2 Periods of Observation
1 Value Chain Analysis

2018 Bloomington Transit Report

$63.84 Transportation Fee per Student per Semester
40,000+ Student Enrollment
$5,000,000+ in Revenue

Indianapolis Universities' Enrollment

IUPUI: 30,105
University of Indianapolis: 5,500
Butler University: 5,095

Technical Architecture

Design and Information Architecture

UML/Class Diagram

Key Tools, Libraries, and Frameworks

Android API - Used to build our android app.
Android Studio - Where code for the android app was developed. Was selected as the primary app IDE based on its easy to use design and development features, and a straightforward way to set up and run an android emulator device, which the app was run on.
Java Socket Library - This was a quick and simple way to allow the app and server to connect. Our priority in this project was building a working prototype, not a perfect product ready for a full release, so we used the easiest solution. Obviously, in a complete version, we would use something more secure.
Android PDF Functionality - This allowed for an easy way to send confirmations in a way that ensures the user will receive them. They may not always supply an email, and something can go wrong with the server, but they will always be using the app on a device with a file system.
JavaMail API - This allowed for easy integration into our app, and allowed for a convenient way to send confirmations in a way that was also familiar to the user.
Gmail - In order to send confirmation emails an email address was necessary. Additionally, by using Google’s SMTP servers to send emails we would not have to set up our own, which was important given our time constraints.

If We Had Another Five Weeks

If our team shared an additional five weeks on our project, we would explore the integration and full implementation of a QR code system into the reservation system. The reservation system for IndyGo would generate a unique QR scan code for every reservation, which could be easily scanned by the digitized kiosk on the bus to identify and confirm people arrive.
Adding a “Running Late" option automatically adjusts your reserved seat to the next bus on that route. (Example: If reserved for 3:15, running late, Notification: “Do you want to change your time to 3:30 or 4:00?)
We could expand the mobile application’s ability to collect aggregated data about customer’s behavior and demand of the reservations resource. The data gathering would inform the bus system, which bus stops on a given route, receive the most or least reservations at a given time, which allows them to adjust the bus routes accordingly to allocate more buses at that time on a route if reservations are high.
Providing the customers the opportunity to directly share photos to IndyGo of their seatings and buses to ensure accountability to public transportation employees to uphold quality standards of public safety.
Behind the scenes computing: Integrate google maps API that gives access to the rider to use google map's resources to calculate the fastest and most efficient route that will present the user with the necessary transfer and times of those transfers, estimate times of arrival and waits based on the user’s entered destination. Assuming the user's location is on, they enter their destination and either what time they plan to arrive or when they plan to leave their house. The mobile application would calculate fastest and most efficient travel plans including when to leave the house, where to walk to a given bus station, automatically reserves seats, and reserves seats on all busses if transferring bus routes are required, which accounts for when the multiple reservations stop and start pulling from the information. The calculated times of switching buses will also end reservation on the previous bus when transferring bus routes.
Include identification in the account of disability status, which would prioritize disabled reservations over well-abled reservations if available seatings are limited. If availability is limited and the user who is disabled reserves more than 15 minutes before, the last well-abled person who reserved will be notified of their reservation being moved to the next stop.
Establish out of 10 reserved seats per bus, the 10th reserved seat specifically for disabled/handicapped users, therefore, when someone reserves the 10th reserved seat they will receive a disclaimer notifying: "You reserved the disabled/handicapped seat and your trip may be impacted if a disabled/handicapped person reserves that seat within 15 minutes of that bus route coming to that stop." A second notification will be sent to the person who reserved the 10th seat specifically for disabled if someone who is disabled has reserved the seat in the upcoming stop. The person's reservation will be adjusted to another seat on the bus if available or the next bus on the route.
Ultimately, expanding the mobile application to embrace a fully digitized payment system (likely using the Google Pay API) would eliminate all physical touchpoints in public transportation. The entire bus system infrastructure would include updating and installing digital kiosks in every bus, which, paired with the developed mobile application that provides a digital payment system, will enable users to scan their phones with their purchased ticket or reserved pass when boarding.
Adding geofencing capabilities that keep track of when users with reservations are on the bus and/or waiting at a bus stop/platform, as well as to provide an additional level of enforcement.
Extend server capabilities so user/account data and reservations can be stored and handled remotely. Similarly, we could build a remote SMTP server to send confirmation emails to guests and account holders, replacing the app’s current utilization of Google’s Gmail SMTP servers. These features would increase the number of confirmation emails that can be sent daily, allow for the logging of accounts (furthering login capabilities), and track the number of reservations and purchases made, giving a better picture of the demand for busing.