-
-
User profile page - saving preferences
-
Saved Event View
-
Posting Event - As Event Organiser
-
Swipe view - event card
-
Adding Event Card - Populating Details
-
Browse view - all event cards
-
Remove Event Card - As Event Organiser (added the event)
-
Event Details View - More Detals
-
User Profile Page - Weekly Interests
-
Event Link Details Successfully Parsed
-
Browse Event Page - With Event Type Filter
-
Sign up and log in page
-
Friends page - add/request and see current friends
-
Notifications page
-
Sign up email confirmation
What inspired us
University students are surrounded by events, clubs and opportunities, yet finding them is surprisingly difficult. Information is fragmented across university websites, student-union calendars, club Instagram accounts, newsletters, Humanitix, Eventbrite and registration forms. Students usually discover only the events promoted within their existing university or social circle. Even when they find something interesting, attending alone, especially at another university - can feel uncomfortable.
As a cross-university team, we experienced this problem ourselves. This inspired us to create Yonder: a platform that helps students look beyond their own campus, discover relevant experiences and find people to attend with.
What we learned
Building Yonder taught us that the main problem is not a lack of university events, but how difficult they are to discover. Event information is spread across university websites, club social media pages, ticketing platforms and registration forms, each using different formats.
We also learned that personalisation and browsing should work together. A swipe-based feed can make discovery engaging and introduce students to unexpected opportunities, while a searchable catalogue with filters remains important for users who already know what they want. Collaborating across business, cybersecurity, digital infrastructure and data backgrounds helped us consider the product from technical, user-experience, privacy and feasibility perspectives.
How we built our project
We began by mapping the student journey from discovering an event to registering and attending. This helped us identify fragmented information and the fear of attending alone as two connected - but distinct - problems.
We designed Yonder as a mobile-first application using HTML/CSS, Javascript, and Supabase for Postgres and authentication (passwords), with the Supabase JS client talking directly to the database and real-time subscriptions keeping the deck, saved list and notifications in sync. We created a standard event structure covering categories, location, date, price, host club, description and registration provider. Our recommendation logic uses onboarding preferences and swipe interactions to rank relevant events.
The challenges
One of the challenges was designing a recommendation ordering for the swiping events feature, that is outside the filter that is already applied from the user’s preferences input. Too complex algorithms might end up involving machine learning, which would be difficult to design within the time limit, while random ordering is not particularly meaningful, nor does it cover the feature design that is meant to give personalized recommendations to users. We ended up choosing to balance it in the MVP by applying a static weighted formula for the ordering of the events in the swipe feature, which takes into account how well an event matched a student’s interests, physical distance, whether friends were attending, and the general popularity of the event itself.
Another challenge was the event ingestion. Clubs events are scattered across different platforms, in Instagram, Humanitix or Eventbrite pages, platforms like Rubric, and some sent directly through emails as newsletters. There is no single feed to pull them from, and web scraping presents privacy or consent concerns. After discussions, we scoped this to a long-term plan for club committee to self-submit their own Humanitix or ticketing links, so that we can parse the source to obtain information on the event, also as an easy method for clubs to include their events such that they do not need to manually enter the event details into this platform. This also sidesteps the privacy/consent problems as the clubs will be opting themselves in rather than us scraping their data. This changes our initial plan to just have university email or use SheerID to log into the app for students as a verification step as our app is specifically for university students, as clubs often have emails that are private email, not organization-based email. Additionally, this also changed our original plan to handle checkout directly within the app to just redirecting users to other sites that the event organizer chose to use, which kept the app more focused on discovery and accessibility, although a more complete version would need proper integration agreements with the ticketing providers and the university clubs.
Built With
- claude
- copilot
- css
- html
- javascript
- sql
- supabase
Log in or sign up for Devpost to join the conversation.