Inspiration

As we look towards a hopeful 2021 to be able to socialize and gather together again with family and friends, we wanted to build an app that helps us quickly and conveniently track where our friends and family are, whether it’s reassuring that our family members are home safely, checking if our friends are almost at the destination for a surprise party, or even just helping to locate a misplaced phone. Although current apps like Apple’s Find My Friends provide this functionality, it is only available for iPhones and not everyone has an iPhone. To provide for an inclusive environment that is not limited to only certain phone users, we built an app that would allow cross-platform use, providing engagement and tracking by both iPhone and Android users who want to track each other and also for users to track through a browser, when they don’t have a phone. The theme of 2020 was safety and inclusivity – the need to address both these two themes through technology inspired us to create this New Year hack in 2021.

What it does

Once signed in, the app allows users to track the location of their friends and family’s phones, which are registered in the app. Similar to the Find My Friends app created by Apple, the main difference and advantage that this app addresses is allowing the use of the app by both Android users and iOS users, allowing tracking among different phone types. Even if members of the same household have different phones from different companies, they will still be able to track each other. Furthermore, additional functionality will allow tracking by rescue teams or firefighters to determine a person’s location for safety measures, if the person grants such access.

We used Firebase to manage our accounts with our users saved in PostgreSQL. Radar.io helps us get the locations of users, setup geofences, and ferry user data, while Socket.io helps push messages to clients. UX Flow: The user is first presented with the first screen with username and password, where the user can either login or create a new account. When a basic login is established, the user will be directed to the registration page to register their family and their name. We used the registration to set up family units and support multiple families and we set up our database so that we can isolate user updates to within single families, but we could support being in multiple families or communities in the future. Once complete, the user will be directed to a main dashboard where they can see the roster of family members and their current at-home status. We plan to add popular locations (e.g. school, work, common places to hang out) and update each user with a place value. Potentially, we could track user travel or proximity to a place to check intent to travel. Since radar.io works on web and mobile, we can put our app on smart devices and potentially track pets, cars and personal belongings that frequently leave the house or go missing.

How we built it

  • Design: Figma was used to sketch out all UX flows
  • Frontend: Javascript - We used create-react-app as our base react app. As we are beginners, we didn’t use material-ui or other button frameworks and chose to create them with vanilla js and react. We used react-router for future expansions between pages.
  • Backend: Python - Leveraging the MLH starter app, we used Flask as the web framework. For the database, we used PostgreSQL in production and SQLite for local development, and we can also use a NoSQL DB like firestore in the future for performance and adding indexes on family_id.
  • Full Stack: RadarIO, Firebase, SocketIO libraries were used in both frontend and backend. RadarIO was used to fetch locations, funnel user metadata and set up geofences and webhooks for events. Beyond using Firebase for authentication we could use Firestore for improved performance, should we want to cache these updates we could expand our GCP usage to Redis on GCP. Lastly, we used SocketIO to ferry updates of users going online to all active family members.
  • Production: We used Heroku and various domain providers, exploring different hosting methods. We only recently learned to draw app designs using Figma and we were all still trying to learn some frameworks over the holidays. We had just finished playing with the MLH flask starter kit and just integrated auth (not fully working when the hackathon started), and also had an old basic SocketIO client in a single HTML page. We felt this hackathon would be a great opportunity to implement the new idea while learning new technologies including RadarIO, GCP, Firebase, React, SocketIO, Flask, SQL concurrently. We still have a lot of learning to do to fully productionize these and write them using the best coding practices and leverage advanced functionality.
  • User Interface and Design: Due to the limited time in the hackathon, we first created a web app in a format that will make it very simple to re-create this project in iOS and Android apps. In terms of user interface, we focused on simplicity and easy usability. We chose a color palette that inspired the calm and serene feel of a safe haven - a darker shade of midnight blue to symbolize evening and rest for the home. We used a single house icon to reflect the home and a door in complementary yellow to symbolize light inside a home. The foundation under the home also symbolizes structure and sturdiness of a shelter. Users can login or sign up without any distractions. After the login page, users who have not previously saved their address of their homes will be able to enter their name and address information, as well as a phone number to track. For return users who have already saved their addresses, they will be able to see at a first glance who is currently home, manage or edit their address information, manage their contacts or modify their privacy and settings. The settings page will provide additional accessibility options and the ability to toggle location sharing and notifications on or off.

Challenges we ran into

The project used a handful of frameworks that we were unfamiliar with, learning them on the spot, the setup and dealing with conflicting interactions between them were the toughest parts.

  • RadarIO Rate Limits: We did so much testing to the point that RadarIO rate-limited us. To work around this, we resorted to using the default browser location provider and continue to ferry messages with SocketIO.
  • HTTPS: We are not very familiar with DNS setup, domains and production services. Without HTTPS we are blocked from using location services in production, the default Heroku app URL supports it though. The domain does not as it needs SSL.
  • Flask: We used numerous libraries from SQLAlchemy, SocketIO, Firebase, RadarIO and it got extremely complex and hard to debug when they interacted - and often didn’t interact well. We also started to use Dotenv and gunicorn more, although the latter doesn’t work on local Windows machines so we had to use flask run locally.
  • Firebase: Auth was very challenging to set up involving tokens, token expiry and lots of confusing credentials, although we managed to figure everything out after some tinkering.
  • React: We are beginners at React, so using web component libraries might help build UX faster. Additionally we heavily used React context to avoid ferrying props all over the place.
  • Hosting: Learning to host on Heroku had a learning curve. We tried to host the backend and frontend servers on separate hosts but CORS kept getting in the way. Luckily we were able to build the frontend into static files that could be served on the backend. Heroku free dynos however do not have SSL and the other free hosts like Vercel and Firebase were not straightforward enough for us to host a Flask app.
  • Create-react-app: Needed to proxy between the client and the backend-APIs/SocketIO was not straightforward and needed a lot of hacks, such as bypassing CORS to get them working.
  • Webhooks: It was quite difficult to use some frameworks who don’t provide example payloads like RadarIO so we had to use requestbin to collect the request.
  • Domain Name: You will notice that the name is “Hu Home” – the reason for this is we wanted a domain name that matches the app’s name and unfortunately any combination of “whoshome” was already claimed. Thus, with one of our last names being “Hu” (pronounced “Who”), we named the app “Hu Home” so we can use the domain name link.

Accomplishments that we're proud of

Through our diligent efforts over the weekend, we were thrilled that we built this app to track whenever someone is at home, using the above technologies. We feel accomplished that we were able to piece all of this together with our collective effort over the last few days. This app also has so many potential expansion directions in terms of functionality and features, especially in this new year once the pandemic is over. Of course, there will be many improvements to make this app even better which we are planning to do.

What we learned

We stretched ourselves significantly for this project, working on it all weekend. Each and every framework were new to us. Some of these we had to work through completely on our own with research because we were not familiar with them. We learned how to create web apps that could receive input and react to that input accordingly (including storing that input) as well as create login and sign-up pages using new frameworks and libraries, and hosting everything on an external site.

What's next for Who's Home App

In addition to improving this app’s current usability and existing user interface, we will also create apps for both iOS and Android and expand this app’s functionality and features in 2021. For instance, we plan to add separate profiles or events where individuals can follow or track each other for a particular time-limited event, such that the access automatically starts or ends at a certain time. Thus, if your Uncle Joe wants to track you coming to his house for Christmas, he could create an event, add all the invitees, and track your location to make sure you get home safely, and then his access to your location will automatically end, without either of you needing to remember to update that status.

We also plan to add a feature for emergency help, which users can decide to turn on or off. For example, when turned on, firefighters or rescue teams could have an additional method to find out if you are in your house or not, without you needing to invite them to your home profile on your phone.

With added features, we plan to roll this app out to both iOS and Android users, as well as web app only users, so that everyone will be able to access this app and can interact with each other within a single app.

Share this project:

Updates