EventEase - Frontend Web Application
Problem and Solution
Generic accessibility labels like "Accessible" vs "Not Accessible" omit critical venue details. They fail to communicate whether a step-free entrance exists, if accessible restrooms are available, or how far attendees must walk from a drop-off point to the main venue area.
EventEase solves this gap by bridging personalized attendee needs with organizer venue claims across seven physical accessibility dimensions. This repository is the web interface for that journey:
- Attendees set their needs, browse events with a personal 0-100 match score, send accessibility requests, accept the organizer's answer, and verify the result after the event.
- Organizers publish events with their accessibility claims, answer incoming requests, and follow their reliability score.
The scoring and data live in the backend. See BE-EventEase.
Technical Architecture & Tech Stack
┌────────────────────┐
│ Frontend (this) │
│ Next.js App Router │
│ Tailwind CSS │
└─────────┬──────────┘
│ HTTP / REST API
▼
┌────────────────────────────┐
│ BE-EventEase (FastAPI) │
│ Match score, requests, │
│ verification, reliability │
└────────────────────────────┘
- Framework: Next.js 16 (App Router) with React 19
- Language: TypeScript
- Styling: Tailwind CSS v4,
shadcn/ui, lightswind, @base-ui/react
- Animation: Framer Motion,
tw-animate-css
- Maps: Leaflet with React Leaflet
- Icons: Lucide React
Exact versions are listed in package.json.
Key Justification
Short version of the choices a reviewer might question. The full list of differences from the proposal, with reasons, is in docs/PERUBAHAN.md.
- The frontend never calculates the match score or the reliability score. It displays what the backend returns, including the per-attribute breakdown, the list of unknown claims, and the weight version. This keeps one source of truth and avoids two screens showing different numbers.
- Unknown information is shown as unknown. If an organizer has not stated a claim, the app says so and explains that it counts as not fulfilled, instead of quietly assuming the venue is accessible.
- Scores are labeled as provisional. The match weights are not yet derived from a user panel study, so the app shows the weight version next to the score. See entry 1.
- Needs are entered as a checklist, not as a diagnosis. Six required or not-required choices and a walking distance tolerance describe what a person needs without any medical label.
- A commitment requires the attendee's acceptance. An organizer's response only becomes a saved commitment after the attendee accepts it, and only accepted commitments can be verified after the event.
- Routes and in-venue navigation are not shown. No verified venue map data exists, so the app does not guess. See entry 3.
Prerequisites
- Node.js 20 or newer
- npm (bundled with Node.js)
- An internet connection in the browser, for Google Fonts and OpenStreetMap map tiles
- A running EventEase backend. Either run BE-EventEase locally (default
http://localhost:8000), or point the frontend to a hosted instance.
How to Build and Run
1. Install dependencies
npm install
The repository includes an .npmrc with legacy-peer-deps=true, so no extra flags are needed.
2. Configure the backend address
Create a .env.local file in the project root:
NEXT_PUBLIC_API_URL=http://localhost:8000
Use the address of your backend without a trailing slash. If you run the backend locally, its CORS_ORIGINS setting must include http://localhost:3000, which is the default in the backend's .env.example.
3. Run in development
npm run dev
Open http://localhost:3000.
4. Build and run for production
npm run build
npm run start
npm run lint runs the linter.
Trying the Full Journey
The backend ships with seeded Jakarta events, so no data entry is needed to start. There is no demo login in the frontend. Register two accounts on the Daftar page, one per role, using two browsers or a private window for the second:
- Attendee: open Profil and save your needs, then browse events on the home page and compare scores. Open an event, read the breakdown, and send an accessibility request.
- Organizer: on the dashboard, open the new request and respond with a decision and a note. Under Acara you can also register a new event with its seven accessibility claims.
- Attendee: open Permintaan, read the response, and accept it. Then open a finished event under Verifikasi and rate each of the seven attributes.
- Organizer: the reliability score on the dashboard and profile now reflects the verification.
The same journey is described step by step at the API level in the backend's demo flow.
Pages
| Route | Who | Purpose |
|---|
/ | Everyone | Landing page for visitors, event discovery for attendees |
/login, /register | Visitors | Sign in or create an account with a role |
/profile | Both | Attendees edit their needs. Organizers see their score and event history |
/events/[id] | Attendee | Event details, match breakdown, request form |
/history | Attendee | All accessibility requests, with accept or decline |
/request | Attendee | Send a request for a chosen event |
/verification | Attendee | Post-event verification |
/dashboard | Organizer | Request counters, reliability score, respond to requests |
/event | Organizer | List and register events, with photos and venue location |
Project Structure
FE-EventEase/
├── src/
│ ├── app/ # Pages (Next.js App Router)
│ ├── components/
│ │ ├── attendee/ # Home, filters, map, requests, profile
│ │ ├── organizer/ # Venue location picker
│ │ ├── lightswind/ # Animated UI blocks
│ │ └── ui/ # Base components (buttons, cards, etc.)
│ ├── hooks/ # Shared React hooks
│ └── lib/
│ ├── api.ts # Backend calls, types, session handling
│ └── attendee-ui.ts # Labels and formatting for attendee screens
├── public/ # Static assets
├── docs/ # Project documentation
├── .npmrc # npm settings
└── package.json # Dependencies and scripts
Documentation
This README is the quick tour. For anything deeper, see docs/:
- Changes from the Proposal (PERUBAHAN.md)
- Backend repository and its docs
- License
