Customer Meeting Notes (17.02.2026) - bounswe/bounswe2026group11 GitHub Wiki

Customer Meeting (17.02.2026)

Arda Hoca (Customer)

Primary Target Audience: The application should cater to both event seekers and event creators.
Event Nature: Events do not necessarily need to be ticketed or formal gatherings.
Restrictions: There are no specific user restrictions for joining the platform.
Security: A security check, such as phone verification, is being considered for user authenticity.
Private Events: Users must have the ability to define private events accessible only via invitation.

Essential Information: Every event entry must include location, time, category, description, and host details.
Visuals: It is highly recommended to include an image for each event.
Spatial Data: Locations should not be limited to single points; the system must support routes (e.g., for cycling or trekking events).
Temporal Data: The time of an event should be defined as a time interval.
Categorization: The system will provide predefined categories (concert, exhibition, workshop, party, etc.), but users should also be allowed to add custom tags.
Archiving: Past events will be archived and remain searchable for future reference.
Visibility: The number of participants and "saves" for a specific event should be visible on the event page.
Feedback & Favorites: Users can provide feedback on events and add events to their favorites. The favorite count will be displayed publicly.
Recommendations: The system will store past event data to provide personalized recommendations to users.

Discovery Methods: Users will find events through both a list view and a map view.
Proximity Discovery: Finding events based on real-time location is a "nice-to-have" feature. This includes suggestions for events located along a user's current path.
Map Features: The map will include custom priority mechanisms and advanced filtering.
Updates & Notifications:
- Users can set "favorite locations" to receive updates.
- A notification system will be implemented for real-time alerts.
- Live geolocation tracking is planned for Phase 2.

Cancellations: If an event is cancelled, it should remain in the system but be clearly marked with a "Cancelled" status (Status types: Active, Past, Cancelled).
Version Control: The system should track changes in event data, showing "old vs. new" versions.
Update Logic: If an event is significantly updated, participants must be notified and a fresh join request/approval may be required.

Core Scenarios: The MVP will focus on event creation, sharing, searching, and basic communication (forum/comment style).
Key Functionalities: Essential features include search, update, and cancellation of events.
UI/UX Logic: The application will prioritize the list view first, then the map view.
Visualization: Routes will be displayed as graphs on the map. Items that cannot fit on the map will be displayed as a list.

Join Request System: To maintain event quality and prevent spam, a "Pending Request" system will be implemented where organizers approve participants. This can be toggled off for smaller events.
User Trust: Profiles will feature profile pictures and participation history to build community trust.
Reliability Ratings: Organizers will be rated based on metrics such as event cancellation rates.
Privacy Tiers: Events will be categorized into three levels of access: Public, Private, and Protected.