Inspiration
Where2Meet was born out of a desire to fix a common inconvenience known to friends all around the world: "Where do we meet?". It's a simple question, but is one that often times runs into many complications! Some places are too far, some people don't feel the vibe of the plan despite previously stating they were up for anything, etc. etc... Where2Meet aims to fix that by finding places the most accessible location to everyone in the group and gathering a list of locations/activities that might be worth checking out. Simply gather the location of everyone, input your mode of transportation and desired travel time, and off you go!
What it does
Where2Meet finds the most accessible location for everyone by first generating isochrones using the TravelTime API. Isochrones are basically outlines that show what is accessible in an area in a given amount of time. It then finds the best intersection among the isochrones, and feeds the location of that isochrone into the Google Places API. The Places API then returns a list of locations which all your friend's can travel to in the same amount of time, and you can then use that to plan your trip! Here's a breakdown of the processes involved:
- The user inputs their own starting point and their preferred mode of transport. They repeat this for their friends.
- This data gets fed into the TravelTime API geocoder, which returns coordinates from these addresses.
- This information gets passed into the *TravelTime * isochrone API which outputs a list of points that determine the shape of the isochrone.
- We determine the intersection of the isochrones using a TravelTime ** feature, and once we do, we find the geographic centre of this intersection and feed it into the **Google Places API to find nearby places to hang out
- We then feed all this data to the frontend, where it's displayed to the user on an embedded Google Maps API map. This combines a little bit of map drawing and a lot of complicated frontend components.
How we built it
Our project was separated into 4 main parts:
- handling the APIs: this step involved interfacing with the APIs in the backend (Google Maps and TravelTime), reading and interpreting that data. This was done in its own file in order to maintain modularity. To ensure that our data was safe, we kept our API keys in a .env file.
- controlling that data and handing it to the frontend: this was pretty much the rest of the backend. It involved everything to do with the server and linking up the backend and frontend.
- displaying the map and the isochrones: This step was the most finnicky and involved linking data from the Google Maps API directly to the website page. The data passed up from the backend was used to draw and display the isochrones to the users.
- rendering the components of the website itself: Adding all the fancy stuff that makes a website function
We used primarily typescript to handle our backend work. The frontend was written in a combination of react and typescript.
Challenges we ran into
Since this is everyone's first hackathon experience, it was definitely challenging, and we went in with the mindset that we should do our best to get a barebones MVP running and learn as much as possible. The planning stage was quite rough, as not only did we have to think of a good idea, we had to make sure we had an idea of how to implement it.
The biggest challenge we ran into were related to integrating the numerous APIs. This was for a few reasons.
- We had to constantly be wary of going over the token limit and needing to pay a fee
- There was very little extensive documentation about how to use the API with the specific setup we were using (especially since React had a recent update)
- We haven't worked extensively with APIs before, so it was unfamiliar territory
We also faced some additional challenges including, but not limited to:
- Coles Express closed and we were not able to buy energy drinks
- We had to balance our other commitments despite a very strict timeframe!
Accomplishments that we're proud of
We're immensely proud that we were able to create something in only 2 days time. From idea to implementation to struggle to power-through to finished product. That already is a triumph, but we are especially excited that it's a product that we would actually use. This was also the first time most of us did a hackathon - so we're really proud of how polished our project turned out, and we're especially proud of how cohesive our group dynamic was.
What we learned
We learned a lot! But the most import lessons we learnt were:
- The nuances of working with APIs: APIs can be really, _ really _ tricky to deal with sometimes. This also taught us about the importance of writing good documentation, so the things you make can be not so opaque.
- Working within a team: While we had all known each other beforehand, it was important to remember to write code that was as transparent as possible to everyone else, especially since we all had different roles. Communication and planning was key to our execution of the project. What we really took from this project was task delegation and division of labour. Some members were naturally suited for different tasks, and a wide variety of skills really elevated the quality of our hack!
- Working under time constraints: Organisation. Organisation. Organisation. The most important thing was to make a plan and stick to it. Setting mini goals to complete by certain times helped us stay on track, and breaking down tasks and their dependencies helped build momentum that kept us going through long nights.
What's next for Where2Meet
We see a lot of potential in the project, and would like to continue developing it further. So it's likely that we'll continue to make updates to Where2Meet! A couple things we'd like to implement to further improve Where2Meet are:
- Web-socket based planning: This makes it so that people can input their location from different devices.
- Further front-end improvements: The frontend right now is quite barebones. We'd like to make it better and add onto it to provide much better UI/UX. Features such as showcasing the region represented by the isochrone's name on hover, icons beside places identifying their type, and more QOL improvements could definitely take our project to the next level.
- Trip/Hangout planning: We plan to make it possible to interact with the hangouts tab, allowing people to add places to an itinerary and set desired schedules/activity details.
- Deployment: Due to time constraints and unfamiliarity with the API, we are cautious about deploying the project, as we don't want our API to go over the rate limit. We hope to continue learning and eventually deploy this project to make it easier for people everywhere to plan hangouts with their friends.
It's quite difficult for projects to greatly improve without input from their users, so feedback would be greatly appreciated! Do feel free to try it out and give us your thoughts! :D
Built With
- google-maps
- javascript
- react
- travel-time-api
- typescript
- visual-studio
- vite
Log in or sign up for Devpost to join the conversation.