Why Imprint?

I feel we came to working on "Imprint" through our original goal of filling a niche, and then brainstorming as a team until we found what we thought we could make the most impact through. First, we decided we had the best competitive edge if we picked a track not a ton of the other teams we would be doing. After talking to a lot of other teams, we decided the JP Morgan disaster recovery track was one that was suitable as a niche, and also fulfilled our urge to make something during this that actually helped and impacted peoples lives in some meaningful way.

Once we had decided on disaster recovery, we simply talked among ourselves on what was within reach and what would be a good use of the resources provided to us. Since we had the access to the google APIs, we figured we could use those and they ended up being a big driving force that shaped how our project developed.

What it does

Imprint is focused around the idea that in the events of disasters, organizations that provide relief and aid often have the best intentions but not the best means of execution. Donations and aid get caught up in logistics and can take days past when victims of disasters actually need it. Imprint allows people who have supplies to give to directly match up and meet with people who need said supplies, cutting out the middleman and helping those in need get what they need almost immediately.

Imprint, through phone GPS tracking, allows both "helpers" - those who have supplies to donate - and "victims" - those who need supplies - to connect and match with each other based on geographic location and need. Then, the locations are plotted / mapped so that the helper can find his/her way to the victim and deliver the supplies / aid.

How we built it

Imprint is modeled around three different aspects: a Swift iOS frontend, a Node.JS backend, and a pure javascript implementation of the google maps API in a webview for the navigational aspect. The Swift frontend takes input data and sends it to the Node backend, which stores and processes it. When the backend matches a helper with a victim, the backend generates the javascript / html webview, which is then displayed in the frontend.

Challenges we ran into

While we got completed code for the frontend input gathering and layout in Swift, and a completed functional backend for handling allocation of helpers to victims, we struggled and unfortunately didn't manage to completely integrate the frontend and backend together in the allotted time period.

Accomplishments that we're proud of

We thought in particular our idea stood out as a useful way to integrate the materials we were provided with the track that we picked. MLH was kind enough to provide us with a variety of resources to help us make our project bigger and better, and we managed to get good usage out of them.

What we learned

Cross language communication is a slightly bigger pain when managing different data types than I think any of us thought previously. The main reason we didn't manage to finish backend and frontend integration was issues with serializing and parsing different types of data from the Node.JS backend (JavaScript) to the swift frontend so that the swift backend would actually receive the data encoded as we had originally designed.

We also learned the value of doing an event like this with friends. We all feel that throughout this the primary feeling was of enjoyment; I think our passion for the project and the creation of something innovative that really had the potential to help other people also brought us closer together as friends.

What's next for Imprint

Although our prototype didn't work perfectly, we'd love to continue working on Imprint as a disaster resource management system that would truly manage to make an "imprint" on people lives. We believe as a team this idea is actually one with a legitimate use case that hasn't, to out knowledge, been done in the same way before, and we're excited to potentially .

Share this project: