Gatherly

Difficult planning meetups with friends on campus? Let Gatherly handle it.

Comment

Inspiration

Life on campus can be busy, with classes, labs, and club meetings pulling everyone in different directions. Sometimes even coordinating a short meetup feels impossible. You check your schedule, your friend checks theirs, both of you spend 15 minutes trying to plan a meet up, and somehow before you know it you're both on your way to your respective obligations. Before you know it, you have gone days week without seeing a friendly face. Gatherly was built to fix this. It finds time slots when everyone is free between classes and suggests meeting spots that are convenient for the whole group, so no one has to miss a chance to catch up between classes.

What it does

Gatherly is a fair meeting scheduler for college campuses. Users input their availability and location, join a group, and Gatherly automatically:

  1. Finds every time slot on a given day when the entire group is free
  2. Calculates the fairest meeting location for each time slot based on everyone’s current location
  3. Shows the recommended time and place, plus alternative options
  4. Provides building-to-buidling walking directions across campus Designed for UW-Madison, Gatherly works for any campus with a building graph.

In short, Gatherly helps friends find a convenient time and place to meet without spending time coordinating or having anyone travel too far.

How we built it

We represented the UW-Madison campus as a weighted directed graph using a NetworkX digraph data set, where weights correspond to realistic walking times between buildings. The graph was constructed from a campus digraph dataset file, which allowed us to run Dijkstra’s algorithm efficiently and precompute all-pairs shortest paths for fast travel time calculations.

To compute the optimal meeting spots, the backend retrieves user schedules and availability from the Availability SQL table, and user locations from the Users table. Group membership and relationships are stored in the Groups table, which lets the algorithm quickly identify which users to include in each calculation. These tables feed directly into the fairness algorithm, which calculates travel times from each user’s location to candidate meeting spots, applies the scoring system that balances average travel time with a variance penalty, and selects the optimal location for the group.

  1. Database: Azure SQL Server storing all schedules, users, groups, and relationships efficiently for quick retrieval.
  2. Backend: FastAPI server performing all algorithmic calculations, including free time interval computation, travel time evaluation, and fairness scoring.
  3. Frontend: React + TypeScript single-page app providing a clean dashboard for group management, schedule input, and real-time algorithm results.

GitHub Copilot was used for code completion and syntax checking during frontend-backend API integration. The core algorithm design, scheduling logic, and routing decisions were developed independently by the team.

Challenges we ran into

  1. Defining Fairness: Initially, to find the best travel routes for a group, we considered minimizing the total travel time for the group. However, this often created unfair scenarios where one user would have to travel much farther than others. We had to define a fairness metric that balances efficiency with equality, leading to our average travel time plus variance scoring system. This formula penalizes variance. It ensures that no single user gets stuck with an unfair burden. A meeting location that forces one person to walk 30 minutes while others walk 5 gets penalized, even if the average is reasonable.

    Fairness_score = average_travel_time + 0.5 × standard_deviation_of_travel_times

  2. Data Integrity Discovery: During development, we cross-referenced our campus graph dataset using Google Maps and discovered two locations on campus with missing coordinates (Grand Central, Wingstop). This taught us that real-world datasets are often imperfect, and can cause silent data gaps which break calculations downstream. We documented these discrepancies and implemented validation checks to prevent path visualization errors.

Accomplishments that we're proud of

  1. We're particularly proud of a platform that allows users to seamlessly decide free times to meet and help nurture in-person communication.
  2. We're proud of our algorithmic efficiency: Precomputing shortest paths for 160+ buildings and multiple users is computationally heavy. We optimized performance by storing all shortest paths in a dictionary, mapping every building to every other building. This reduced the complexity of computing travel times on the fly from O(V² + E) per request, where V is the number of buildings and E is the number of edges in the campus graph, to O(1) lookup per building pair.
  3. Without Precomputation (per request for group of 5 friends):
    • 1 user × 1 time slot: O(V² + E) ≈ 25,600+ operations
    • 5 users × 10 time slots: ~1.28 million operations per request
    • Wall-clock time: 500–2500 ms (Dijkstra on 160 nodes takes ~20–50 ms × group size)
  4. With Precomputation (per request for group of 5 friends):
    • O(N × B): 5 users × 75 candidate buildings ≈ 375 operations
    • Wall-clock time: 10–50 milliseconds

What we learned

  1. Having a complete graph, where every building connects to every other building, is important for calculation accuracy. It ensures that travel times are correctly computed for all possible meeting locations, which directly impacts the fairness of location selection, though it comes with higher computation costs.
  2. Graph algorithms like Dijkstra’s are extremely powerful for real-world scheduling problems.
  3. Defining fairness requires balancing efficiency and equality, not simply minimizing total travel time.
  4. Developing Gatherly let us leverage a relational database to its fullest, organizing data efficiently with minimal redundancy and making the backend algorithms faster and more streamlined.

What's next for Gatherly

  1. Automatic schedule import: Allow users to upload their calendars (e.g., Google Calendar, Outlook, or .ics files) to automatically update their weekly schedule, reducing the need for tedious manual entry.
  2. Complete the campus graph: Add more edges (building travel time connections) to make travel time calculations even more precise and improve visualizations of walking paths as a graph for a more intuitive user experience.

Built With

Share this project:

Updates