Concept

To be completely honest, I don’t really remember where the idea for GeoDrop came from. I had been exploring the functionality of various browser-based APIs and I was familiar with the GeoLocation API from a previous weather app I built while learning JavaScript. For some reason, the WatchPosition method caught my attention. From there, my mind connected geocaching and media and I was off the races.

My first idea was to allow users to stash audio such as poetry or songs in specific locations and allow people to discover them in a style along the lines of geocaching or Pokemon Go. This iteration of the app was called ListenHere and I built it out as a proof of concept in January 2024. It was glitchy and the design was very colorful and a bit cluttered, but the idea still intrigued me.

After I shared the ListenHere site with a few friends, they asked about photos or videos, and I finally made the connection that this could be a really cool social media platform idea based entirely on geolocation and discovery. This is where GeoDrop was born.

The goal was to create a social media platform that encouraged users to get out into their communities, explore the world, and discover remnants of experiences and stories that people left behind in locations all around them.

Design

Contrary to the extremely colorful ListenHere iteration of my design, for GeoDrop I wanted a modern and cool theme that worked well in light or dark mode. By using the electric blue color for buttons I draw users attention to actions they can take, and the softer white color makes the aesthetic a little less harsh while maintaining a clean high-contrast interface.

I went with the drop theme for a few reasons.

This web app really only works for mobile devices. The primary concept of the app is geolocation-based discovery. For example, you can only view drops within a 100 ft radius of your current location. Since desktop computers don’t frequently go exploring, I decided to keep the layout of the app designed for mobile and make only minimal accommodations for desktop viewing.

The logo is bold and features the drop icon prominently for recognition with a globe superimposed to imply the Geo part of the drop rather than spelling it out. It turns out that the implied ‘O’ with the drop is actually read by many people as an ‘i’ and so I frequently have people read the title as ‘Drip.’ The name was also influenced by domain name availability and geodrop.xyz seemed to make sense with the coordinates reference. The price tag was also much more attractive.

Solutions

The main feature of this project is the map that displays the user’s current location and allows them to explore content located nearby. Users can browse the map to look for undiscovered content, or view a feed that sorts the nearby drops in order of ascending distance. I decided to use Leaflet for this project primarily for their ease of getting started and their React component library.

After reading the documentation, I was able to use the react-leaflet library to create custom markers, popups, group markers by proximity, and customize the map tools displayed.

To make use of the GeoLocation API’s WatchPosition method, I incorporated this API into my location context that was shared throughout the app. I debounced the updates based on proximity to the previous updated position (No need to update the state if the user moved less than 10 ft). I was also able to use this shared context to control the Leaflet map so the map moved with the user’s location, keeping the user at the center of the map at all times.

One challenge I faced when developing this app was how to ensure content was synced to the database (MongoDB in this case) when multiple users could be adding content and discovering content simultaneously. I didn’t think the situation warranted a web socket connection, so I decided on server-sent events. The current drops would load on initial page load, then subscribe with an event listener. Anytime a change was processed via the API, the API would publish this update to the server, who would then distribute the update via an SSE to all its subscribers. This was not a perfect solution, but it seemed to get the job done and was a very new concept for me at the time.

Reflection

While this was a fun project, and a novel concept, there were definite limitations from its architecture and design that would require revision if I wanted to be able to fully market this product successfully. I learned quite a bit during the development process about the Context API in React, the GeoLocation browser API, and the Leaflet React library.

I wish I had known more about state management, as I may have opted for the useReducer hook to simplify state management logic. Additionally, I think this concept would function much better as a mobile app than a website. Since the design is primarily for mobile anyway, getting access to more accurate geolocation status from device settings and a purely mobile interface could do a lot to improve the experience.

As I discussed this with friends and colleagues I realized this type of concept could have very marketable niche markets for community history projects, alumni organizations, or artists looking to craft a geographically linked canvas for a virtual installation work. I’m very excited about exploring more geolocation projects in the future, and GeoDrop was a great start.