Digital Prototype

Digital Prototype

Problem:

We originally started this project with the intention to help young adults (18-25) reduce screen time, with a target demographic of college students. After our initial user research, we quickly realized that most users would be less likely to go on their phones if they have more social interaction with their friends or family. Most users said that being social is a greater deterrent than any negative reinforcement such as screen time limits.

Idea:

Based on this feedback, we began prototyping an app where users could submit their availability in a when2meet style, add friends, and receive texts indicating times where friends have overlapping availability. Additionally, the text would include activity suggestions that are appropriate for the found time and duration in efforts to reduce the struggles of deciding what to do.

Description:

For the front end, we used React to render our web app and user information that is pulled from the firestore database. For the backend, we used firebase functions (written in python). We also used Twilio to send texts to users. We used firebase for authentication, hosting, functions, and the firestore database which stored information about our users and a list of activities. Although the firestore databases were no-SQL document based databases, we used a fixed structure for both databases. We did, however, take advantage of being able to store arrays for single fields. The users database used user emails as document ids, and had the following fields:

The activities database had the following fields:

Our application has the following flows:

The user starts on a sign up page where they can create their account with a unique username and password and also requires their email and phone number. Once the user makes their account, they will be able to log in to their account when they use the app in the future and their information will be saved. Then, there is a home page where users can add in their availability on a weekly calendar. The user can change which week they are currently viewing and change the times that are displayed. There is also a profile page where users can adjust their settings on the minimum amount of time they want to be notified before a potential hangout. On this page, users can search for their friends by email and send and receive friend requests. They will be able to manage all their friends from this page. Once they have set their availability and added some friends, the app will find a time for them to meet and send a text message with some recommended activities. This happens once a day at 11pm and each friend group gets one new meeting time with two suggested activities per day.

The web app can be found here: https://friendstomeet-155ac.web.app/ and the Github where the code can be found is here: https://github.com/UWSocialComputing/mack-code. We encourage you to check it out for yourself!

Technical issues:

During the implementation of our project, we encountered several technical challenges that tested our team’s skills and knowledge. As none of us had prior experience with web development, we faced a steep learning curve. Our initial hurdle was setting up our development environment to integrate smoothly with Firebase. We encountered difficulties with configuring the emulator and deploying our application effectively. Additionally, we faced verification issues when working with Twilio, which affected our messaging functionality. Originally, we aimed to send messages in a group chat format to all users involved in a specific plan. However, we discovered that implementing this feature proved to be complex and not well-supported by Twilio. Despite exploring alternative solutions, we found none of the alternatives met our requirements. Although Firebase came with many advantages, such as built in authentication methods and database management, it also came with challenges and limitations. One of which was when we wanted to build complex queries against our Firestore databases. We found out the query feature only allowed filtering on one attribute per query. Our group found a work around by pulling in our database and converting it to a pandas dataframe. Once our data was formatted as a dataframe, we could easily execute the more complex queries that our code required. Based on user testing, we changed a decent amount of the UI so that the interface would be more intuitive for the user - allowing users to go back and forth between different weeks, customize calendar settings, and more. We also separated out the login page from the calendar and profile page. One of the big technical challenges with this application was the algorithm to match friend groups and their availability. We tried a variety of different graph algorithms to create “friend bubbles” of mutual friends, before realizing that we were essentially trying to solve the clique problem (aka finding the maximal fully connected subgraphs of a graph), which is an NP-Complete problem. Luckily, many libraries exist that use some of the existing non-polynomial algorithms to solve this problem, so we used one of them. Because our matching algorithm only runs once a day and we expect to not have that many users at the moment, the large runtime of this algorithm is not a huge deal. If this platform were to scale, we’d store friend bubbles in a database and only run the algorithm to update affected bubbles (or new bubbles) by a new/removed friendship. Once we had our cliques, another challenge was deciding which plans for that group to prioritize. In order to not overwhelm users, we decided to send up to one plan per clique per day. But should we prioritize the duration of the plan, or the number of people available? Is it better to send a plan where two people are free for four hours, or where four people are free for an hour and a half? We decided to implement a weighted sorting algorithm for planned time slots: duration in minutes divided by 30 + number of people in a group * 3.
Overall, our technical issues ranged from classic setup issues that come with learning new tools to more complex social computing questions of prioritizing and weighting certain content over others.