## Motivation

We saw how **long queues** can get firsthand at Hack The North and found that we all shared a common interest in solving this issue.

## Approach

Our software **generates a digital ticket** for attendees at an event and orders them, **sending a notification** to those who are closer to being attended to (users who get into the bubble).

## Language & Technologies

* Python,
* JavaScript
* React.js
* Flask
* Vultr
* Domain.com

## Challenges

We struggled with the frontend development (*it's so hard to make things look nice!*) as well as combining frontend and backend.

## Solution

We are proud that we managed to work together to solve all potential problems by discussing and debating possible workarounds.

## What we learned

We all got better with React.js and considered options for a wait time estimation machine learning algorithm.

## Future

We are considering pursuing this project further past this hackathon in the following areas:

* Enhanced Database
* Security Considerations (we don't want hackers to cut the line!)
* "What if the APP crashes? - Unique User ID"
## Inspiration

First thing I think about when I think about software is removing redundancy / tedious work on humans and transferring that work to computers. Yet during Covid we have needed to fill out more forms than ever. Some universities require daily forms, covid test scheduling, and other overhead that adds up over time. We want to offer a solution to remove this burden.

## What it does

App that acts as a hub for all things Covid-related. Each row is a possible task the user can start from the comfort of their phone in just one button click. For now, the only feature present is to fill out the form for the daily check.

## How I built it

I developed the Android app using the flutter framework and the REST server using flask and selenium with my WiFi network acting as the Local Area Network (LAN) allowing the app and server to communicate with one another. Additionally I stored most of the user's information in Firestore and had my server fetch that information as needed. (email and password stored as environmental variables)

## Challenges I ran into

I initially wanted the UI to be a physical button so I spent a significant amount of time trying to scavenge my hardware setup (nodeMCU) to see if I can get that up and running and have that send REST requests to the server but ran into issues there. I also attempted to containerize my server so I could deploy it conveniently in GCP with little to no configuration. I wasn't able to get this to work either and in hindsight dealing with the initial configuration work to get it to work on a virtual machine would have been way more feasible for this hackathon. Lastly, Cayuga's health system form for scheduling a Covid test is much harder than expected to interact with to automate the form submission. Made some progress on this functionality but it cannot submit the entire form yet.

## Accomplishments that I'm proud of

Assuming the server is online, I can swiftly press a single button (after opening the app) to fill out a form that would normally require 2 minutes of work daily. Was this worth 16 hours of work? Well assuming best conditions I would equalize in time saved in 480 days but this is my last year of college haha. But I got to learn a lot about selenium and I can leave this hackathon with a product I can keep working on for my own personal benefit.

## What I learned

Learned more about Selenium during this weekend and Firestore. I also became more proficient in Flutter development.

## What's next for If No Corona Then That

The App could definitely be more smoothened out, especially an onboarding page to allow the user to provide their information to the app (so they're data doesn't need to be written to firebase manually), more features developed by me, and allowing the user to provide their own backend to automate services so they can add functionality without having to reflash the app. My server side logic could be improved so it can handle dealing with tougher forms to fill out, be deployed on the cloud (ex. GCP) so it can be accessible outside of my home network, require authentication for API requests, and managing users' credentials on the server side in a more scalable but safe way.
## Inspiration

The impact of COVID-19 has had lasting effects on the way we interact and socialize with each other. Even when engulfed by bustling crowds and crowded classrooms, it can be hard to find our friends and the comfort of not being alone. Too many times have we grabbed lunch, coffee, or boba alone only to find out later that there was someone who was right next to us!

Inspired by our undevised use of Apple's FindMy feature, we wanted to create a cross-device platform that's actually designed for promoting interaction and social health!

## What it does

Bump! is a geolocation-based social networking platform that encourages and streamlines day-to-day interactions.

**The Map**

On the home map, you can see all your friends around you! By tapping on their icon, you can message them or even better, Bump! them.

If texting is like talking, you can think of a Bump! as a friendly wave. Just a friendly Bump! to let your friends know that you're there!

Your bestie cramming for a midterm at Mofitt? Bump! them for good luck!

Your roommate in the classroom above you? Bump! them to help them stay awake!

Your crush waiting in line for a boba? Make that two bobas! Bump! them.

**Built-in Chat**

Of course, Bump! comes with a built-in messaging chat feature!

**Add Your Friends**

Add your friends to allow them to see your location! Your unique settings and friends list are tied to the account that you register and log in with.

## How we built it

Using React Native and JavaScript, Bump! is built for both IOS and Android. For the Backend, we used MongoDB and Node.js. The project consisted of four major and distinct components.

**Geolocation Map**

For our geolocation map, we used the expo's geolocation library, which allowed us to cross-match the positional data of all the user's friends.

**User Authentication**

The user authentication proceeds was built using additional packages such as Passport.js, Jotai, and Bcrypt.js. Essentially, we wanted to store new users through registration and verify old users through login by searching them up in MongoDB, hashing and salting their password for registration using Bcrypt.js, and comparing their password hash to the existing hash in the database for login. We also used Passport.js to create Json Web Tokens, and Jotai to store user ID data globally in the front end.

**Routing and Web Sockets**

To keep track of user location data, friend lists, conversation logs, and notifications, we used MongoDB as our database and a node.js backend to save and access data from the database. While this worked for the majority of our use cases, using HTTP protocols for instant messaging proved to be too slow and clunky so we made the design choice to include WebSockets for client-client communication. Our architecture involved using the server as a WebSocket host that would receive all client communication but would filter messages so they would only be delivered to the intended recipient.

**Navigation and User Interface**:

For our UI, we wanted to focus on simplicity, cleanliness, and neutral aesthetics. After all, we felt that the Bump! the experience was really about the time spent with friends rather than on the app, so designed the UX such that Bump! is really easy to use.

## Challenges we ran into

To begin, package management and setup were fairly challenging. Since we've never done mobile development before, having to learn how to debug, structure, and develop our code was definitely tedious. In our project, we initially programmed our frontend and backend completely separately; integrating them both and working out the moving parts was really difficult and required everyone to teach each other how their part worked.

When building the instant messaging feature, we ran into several design hurdles; HTTP requests are only half-duplex, as they are designed with client initiation in mind. Thus, there is no elegant method for server-initiated client communication. Another challenge was that the server needed to act as the host for all WebSocket communication, resulting in the need to selectively filter and send received messages.

## Accomplishments that we're proud of

We're particularly proud of Bump! because we came in with limited or no mobile app development experience (in fact, this was the first hackathon for half the team). This project was definitely a huge learning experience for us; not only did we have to grind through tutorials, youtube videos, and a Stack Overflowing of tears, we also had to learn how to efficiently work together as a team. Moreover, we're also proud that we were not only able to build something that would make a positive impact in theory but a platform that we see ourselves actually using on a day-to-day basis. Lastly, despite setbacks and complications, we're super happy that we developed an end product that resembled our initial design.

## What we learned

In this project, we really had an opportunity to dive headfirst in mobile app development; specifically, learning all about React Native, JavaScript, and the unique challenges of implementing backend on mobile devices. We also learned how to delegate tasks more efficiently, and we also learned to give some big respect to front-end engineers!

## What's next for Bump!

**Deployment!**

We definitely plan on using the app with our extended friends, so the biggest next step for Bump! is polishing the rough edges and getting it on App Stores. To get Bump! production-ready, we're going to robustify the backend, as well as clean up the frontend for a smoother look.

**More Features!**

We also want to add some more functionality to Bump! Here are some of the ideas we had, let us know if there's any we missed!

* Adding friends with QR-code scanning
* Bump! leaderboards
* Status updates
* Siri! "Hey Siri, bump Emma!"