Skip to content

MVP Demo Plan

Jump to bottom
Bora Aydemir edited this page Apr 2, 2026 · 1 revision

MVP Demo Plan

1. Demo Overview

Project: Neighborhood Accessibility Mapper Milestone: MVP (Milestone 1) — Customer Demo Presentation Date: April 8–9, 2026 Duration: 10 minutes presentation + 5 minutes Q&A Platforms: Web Application (deployed, HTTPS) + Mobile Application (deployed, live device)

Core Message: Our system empowers users with mobility challenges to navigate the neighborhoods around Boğaziçi University safely by crowdsourcing obstacle reports and generating accessible routes that avoid them in real time.

2. Role Assignments

Role Person Responsibility
Narrator & Web Presenter Person A Drives the web app on the projected laptop; narrates the overall story and transitions. Leads the presentation.
Mobile Presenter Person B Holds the mobile device (screen-casted to projector); performs the obstacle reporting flow on mobile.
Co-Narrator Person C Supports narration during transitions and the routing segment; explains technical decisions briefly when needed (e.g., "why the route changed").
Observer / Note-Taker Person D Sits in the audience. Records customer questions, reactions (confused/pleased), and observations for the post-milestone review. Does NOT present.
Timekeeper Person E Tracks time silently; gives discreet signals to presenters at 5:00, 8:00, and 9:30 marks. Also serves as backup presenter if technical issues arise.
Backup / Tech Support Person F Monitors the deployed backend and infrastructure during the demo. Ready to switch to backup plan if the live app goes down.
Backup / Tech Support Person G Has a pre-recorded screen capture of the full demo flow on standby. Ready to play it if both web and mobile fail.

Note: Persons E, F, and G do not speak during the presentation but are critical for a smooth demo. Person D must bring a notebook or laptop dedicated to note-taking.

3. Demo Structure & Script

The demo tells a single connected story involving two characters: a wheelchair user named Aylin who needs an accessible route, and a volunteer contributor named Kemal who spots and reports an obstacle. Their actions intersect on the same map.

Act 1 — Setting the Stage (0:00 – 1:30) · Person A narrates, Person B ready

[0:00 – 0:40] Opening & Context (Person A, speaking to audience)

Person A opens with a brief spoken introduction — no slides. Something like:

"Imagine you're a wheelchair user living in Bebek. Every morning you need to get to Boğaziçi University's South Campus. The sidewalks along the coast seem fine on Google Maps — but in reality, there's a broken ramp here, construction blocking the path there. Our app solves this — it crowdsources obstacle data from the community and generates routes that avoid these real-world barriers. Let us show you how."

[0:40 – 1:30] The Map — First Impression (Person A on web app, already loaded)

The web app is already open on the projector, showing the interactive map zoomed out to cover the Bebek – Rumelihisarı – South Campus area along the Bosphorus coastline.

  • Person A pans and zooms the map briefly to show it's live and interactive. The wider area makes the map visually rich and easy to read on a projector.
  • Several pre-seeded obstacle markers are visible at different points along the Bebek coastal road, Rumelihisarı streets, and near the South Campus entrance.
  • Person A clicks on one existing obstacle marker (e.g., the construction zone on Bebek Caddesi) → the detail popup opens showing the photo, description, category (ROAD_CONSTRUCTION), and status (VERIFIED).
  • Person A: "These are obstacles reported by the community — some from just last week, others from months ago. Each one has a photo, a category, and a verification status. Now let's see how a new obstacle gets reported."

Act 2 — Obstacle Reporting on Mobile (1:30 – 4:30) · Person B on mobile, Person A narrates

[1:30 – 2:00] Introducing the Contributor (Person A narrates, Person B holds mobile device)

Person A: "Meet Kemal, a student who walks along the Bebek coastal road every day. This morning he noticed a broken ramp on the sidewalk near Bebek Park. He pulls out his phone to report it."

Person B's mobile screen is cast to the projector. The app is already open and Kemal is already logged in (no login flow shown).

[2:00 – 3:15] Submitting the Report (Person B acts, Person A narrates key steps)

Person B performs the following on the mobile app:

  1. Taps the "Report Obstacle" button on the map screen.
  2. The app drops a pin on the map. Person B manually adjusts the pin location to place it on the Bebek coastal sidewalk (near Bebek Park, ~41.0770, 29.0440).
  3. Selects context: Outdoor.
  4. Selects category: Broken Ramp from the dropdown.
  5. Takes a photo — Person B uses a pre-taken photo from their gallery showing a real broken ramp or cracked sidewalk from the Bebek area. Alternatively, Person B takes a live photo of something in the classroom as a stand-in — this creates an engaging live moment.
  6. Adds a short text description: "Sidewalk ramp near Bebek Park is cracked and unusable for wheelchairs."
  7. Taps Submit.

Person A: "Kemal has just submitted his report. Notice the app required a photo — that's by design, every report needs photographic evidence for credibility."

[3:15 – 4:00] Verifying the Report Appeared (Person A switches to web app)

Person A refreshes or pans the web map to the Bebek area.

  • The new obstacle marker from Kemal's report is now visible on the map at the reported location near Bebek Park.
  • Person A clicks on it → the popup shows the photo Kemal just uploaded, the description, category BROKEN_RAMP, and status UNVERIFIED.

Person A: "And here it is — Kemal's report is now live on the map for everyone to see. It's marked as unverified for now. In our Final Deliverable, the community will be able to upvote it to confirm, and it will affect routes immediately."

[4:00 – 4:30] Brief Pause / Transition (Person A)

Person A: "Now let's switch perspectives. Meet Aylin — a wheelchair user who lives in Bebek and commutes to Boğaziçi University every day. Let's see how the system helps her plan her route."

Act 3 — Mobility Profile & Route Generation on Web (4:30 – 8:00) · Person A on web, Person C co-narrates

[4:30 – 5:30] Aylin's Profile Setup (Person A acts on web, Person C narrates)

Person A switches to a pre-loaded browser tab already logged in as Aylin. No login flow is shown — the profile page is already open.

Person C: "Aylin is a registered user. When she first set up her account, she created a Mobility Profile. Let's take a look."

Person A navigates to the Mobility Profile page:

  • Mobility Aid: Wheelchair
  • Avoid Stairs: Enabled
  • Avoid Steep Slopes: Enabled
  • Max Slope Gradient: 8%

Person C: "These preferences are saved permanently to her account. Every route she requests will automatically factor these in — she doesn't have to configure them each time."

[5:30 – 7:00] Route Generation — The Core Feature (Person A acts on web, Person C narrates)

Person A navigates back to the map view (still logged in as Aylin).

Step 1: Route that avoids pre-seeded obstacles

  • Person A sets origin to Bebek Park area and destination to South Campus Entrance — using pin drops or the search bar.
  • Person A clicks "Calculate Route."
  • The system renders a static route (Blueprint) on the map along the Bebek–Rumelihisarı coastal road, showing: the visual path, total distance, and estimated time.
  • Person C: "The system generated an accessible route for Aylin from Bebek to South Campus. Notice it already detours around the construction zone on Bebek Caddesi and the damaged sidewalk near Rumelihisarı — those were reported by other users days ago."

Step 2: Route now also avoids Kemal's new report

  • Person A keeps the same origin and destination but the route's natural path now passes through Kemal's newly reported broken ramp near Bebek Park.
  • Person A clicks "Calculate Route" again (or the route auto-updates).
  • The rendered route detours around the newly reported obstacle, taking a slightly different path away from the broken ramp.
  • Person C: "Look — the route has changed. It now also avoids the broken ramp that Kemal reported just minutes ago from his phone. This is the core value of our system: community-reported obstacles immediately affect route calculations for everyone."

Person A can briefly hover over Kemal's obstacle marker on the map to reinforce the connection.

[7:00 – 7:30] Passive Report & Visibility Toggle (Person A)

Person A zooms or pans to show the passive report marker (the old report from Kadıköy, visually semi-transparent).

Person A: "This marker looks different — it's a report from over a year ago that never received any community interaction. Our system automatically marks these as passive. They're displayed with a faded style and don't affect route calculations. Users can toggle their visibility on or off."

Person A toggles the passive report visibility filter — the semi-transparent marker appears/disappears.

[7:30 – 8:00] Mentioning Future Scope (Quick) (Person A)

Person A: "Everything we showed today is outdoor routing. In our Final Deliverable, we'll add indoor obstacle support — like missing elevators inside buildings — displayed at high zoom levels. But for the MVP, outdoor accessibility is our focus."

Act 4 — Wrap-Up (8:00 – 9:30) · Person A and Person C

[8:00 – 8:30] Location Search (Person A, quick demo)

Person A types a location name (e.g., "Bebek Park" or "South Campus") in the search bar → the map pans to that location. Quick feature showcase, no long narration needed.

[8:30 – 9:30] Summary & What's Next (Person A and Person C, spoken — no slides)

Person A: "To summarize: today we showed you a volunteer spotting a broken ramp in Bebek and reporting it from his phone, that report appearing instantly on the shared map, and a wheelchair user getting a commute route from Bebek to campus that automatically avoids it. This is our MVP."

Person C: "For our Final Deliverable, we're adding: community verification where users can upvote or flag reports, a trust score system that rewards reliable contributors, a dashboard for infrastructure authorities like the municipality to manage and resolve issues, indoor obstacle mapping, and personalized routing preferences. Thank you."

[9:30 – 10:00] Buffer / Transition to Q&A

Q&A (10:00 – 15:00) · All team members can answer

Person D (Observer) pays close attention to questions and records them. All team members are available to answer based on their area of expertise.

4. Demo Data Strategy

User Accounts

Account Role Purpose
Kemal (Registered User) REGISTERED_USER The mobile contributor. Pre-authenticated on the mobile app. Used for the obstacle reporting flow. Trust score: 0 (new user).
Aylin (Registered User) REGISTERED_USER The web user with a wheelchair mobility profile. Pre-authenticated in a separate browser tab. Has a saved Mobility Profile (Wheelchair, Avoid Stairs, Avoid Steep Slopes, maxSlopeGradient: 8.0).

Pre-Seeded Obstacles

We will seed the database with 7 realistic obstacles spread across the Bebek–Rumelihisarı–South Campus corridor and a few from distant locations to show the system works city-wide. All use real GPS coordinates.

Along the Bebek → South Campus route (primary demo area):

Obstacle Location Coordinates (approx.) Category Context Status Created Purpose
Construction blocking sidewalk Bebek Caddesi, near Bebek Mosque 41.0785, 29.0435 ROAD_CONSTRUCTION OUTDOOR VERIFIED 2 weeks ago Visible on initial map load. The route in Act 3 detours around this.
Damaged sidewalk surface Coastal road between Bebek and Rumelihisarı 41.0810, 29.0490 DAMAGED_SURFACE OUTDOOR VERIFIED 1 month ago Shows variety of obstacle categories; route avoids this.
Steep stairs on hillside shortcut Rumelihisarı, hillside path toward campus 41.0835, 29.0520 BLOCKED_PATH OUTDOOR VERIFIED 3 weeks ago Critical for demo: Aylin's route avoids stairs due to her mobility profile.
Recently reported narrow sidewalk Near South Campus entrance, Hisar Üstü 41.0843, 29.0510 NARROW_SIDEWALK OUTDOOR UNVERIFIED 3 days ago Shows an unverified report with a different visual style on the map.

Distant / historical reports (showing city-wide usage):

Obstacle Location Coordinates (approx.) Category Context Status Created Purpose
Old broken ramp (passive) Kadıköy ferry terminal area 40.9910, 29.0235 BROKEN_RAMP OUTDOOR PASSIVE March 2025 (over 1 year ago) Reported over a year ago, never received any interaction. System automatically transitioned it to PASSIVE. Used to demonstrate the passive visibility toggle and semi-transparent styling. Shows the report lifecycle in action.
Blocked pedestrian path Taksim Square area 41.0370, 28.9850 BLOCKED_PATH OUTDOOR VERIFIED 2 months ago Distant verified report showing the system is not limited to one neighborhood. Visible when zooming out.
Narrow sidewalk near bus stop Beşiktaş waterfront 41.0425, 29.0060 NARROW_SIDEWALK OUTDOOR VERIFIED 1 month ago Another distant report. Shows that community contributions come from all over the city.

Important: The broken ramp near Bebek Park (~41.0770, 29.0440) is NOT pre-seeded — Kemal will create it live during the demo. The route calculation in Act 3 depends on this report existing, so the reporting flow must succeed first.

Route Test Setup

  • Route (Act 3, Step 1): Origin at Bebek Park (~41.0770, 29.0440) → Destination at South Campus Entrance (~41.0843, 29.0510). The natural shortest path passes near the pre-seeded construction zone on Bebek Caddesi and the stairs at Rumelihisarı. The route should detour around both. Kemal's new report does NOT yet exist at this point.
  • Route (Act 3, Step 2): Same origin and destination. After Kemal's report is submitted near Bebek Park, the route should now also avoid the newly reported broken ramp, producing a visibly different starting segment.

These pairs must be tested and validated during rehearsal to ensure the routing engine produces visually distinct and correct detours. The Bebek–South Campus corridor provides enough road network alternatives for the detours to be clearly visible on the projected map.

5. Backup Plan

Failure Scenario Mitigation
Internet goes down in classroom Person G has a pre-recorded screen capture (video) of the entire demo flow. Play it from a local file while Person A narrates live over it.
Mobile app crashes during report submission Person F has a second mobile device with the app installed and Kemal logged in. Switch devices. If both fail, show a pre-taken screenshot of a successful submission and manually insert the obstacle into the database (Person F via admin tool), then continue with the web demo.
Web app fails to load or route calculation times out Person E has a second laptop with the web app open in the same state. Switch laptops. If the routing engine itself is down, show a pre-recorded clip of the route calculation and explain the issue honestly.
Newly reported obstacle doesn't appear on the map Person A manually refreshes the page. If it still doesn't appear after 10 seconds, Person A narrates: "There's a brief propagation delay — let me show you one of our pre-seeded obstacles instead" and demonstrates the route avoidance with the pre-seeded stairs.
Projector / screen-casting fails for mobile Person B walks through the audience briefly showing the phone screen, while Person A describes the steps verbally. Alternatively, switch to the pre-recorded video.

6. Rehearsal Checklist

Before the demo day, the team must complete the following:

  • Both web and mobile apps are deployed and accessible via HTTPS public URLs.
  • All 7 seeded obstacles are populated in the production/demo database with correct GPS coordinates.
  • Kemal's account is pre-authenticated on the mobile device; Aylin's account is pre-authenticated in a browser tab.
  • The Bebek Park → South Campus Entrance route has been tested and produces visually clear detours around pre-seeded obstacles (construction on Bebek Caddesi, stairs at Rumelihisarı).
  • Kemal's report submission has been tested end-to-end: submit on mobile near Bebek Park → appears on web map within seconds.
  • The route calculation after Kemal's report has been tested: the route visibly changes to avoid the newly created obstacle.
  • The passive report from Kadıköy is visible with semi-transparent styling, and the visibility toggle works.
  • The distant reports (Taksim, Beşiktaş) are visible when zooming out, showing city-wide usage.
  • The location search returns correct results for "Bebek Park" and "South Campus."
  • A screen recording of the entire demo flow has been captured and saved locally on Person G's laptop.
  • The full demo has been rehearsed at least once end-to-end with timing.
  • Person D has a dedicated notebook/laptop for note-taking during the presentation.
  • All presenters (A, B, C) know their lines and transitions.

Project

Team Members

Lab Reports

Weekly Meetings

Scenarios and Mock ups

Use Case Diagrams

Class Diagram

Sequence Diagrams

Milestone Review

Clone this wiki locally