Final Demo Plan

Lab 10 – Final Milestone Demo Plan

1. User Scenarios

Scenario A — Guest Discovery

A visitor with a mobility impairment opens the web app without an account. They browse the map, inspect obstacle markers, and see that reporting and voting require a login — motivating registration.

Scenario B — Outdoor Report & Community Verification

A registered user spots a broken ramp near Boğaziçi University South Campus entrance. They submit an outdoor obstacle report with a photo. A second registered user (Trusted Contributor) sees the report and upvotes it, automatically pushing it past the Verification Threshold and transitioning the status to "Confirmed Obstacle".

Scenario C — Indoor Report

The same user enters a university building and notices an elevator is out of service. They switch the report context to "Indoor" and pin it inside the building (visible only at high zoom levels per 1.2.1.2), demonstrating the indoor/outdoor distinction.

Scenario D — Authority Resolution Workflow

The Infrastructure Authority account receives a notification about the confirmed broken ramp. They open the Authority Dashboard, filter by open reports, upload a post-repair photo, and mark the issue "Resolved – Awaiting Validation". The original reporter is notified automatically.

Scenario E — Admin Moderation

A spam account submitted several fake reports that the community has flagged. The Admin user opens the flagged-reports queue, permanently deletes the malicious reports, and suspends the abusive account.

Scenario F — Notifications & Profile

Back as the original reporter: they open the Notifications tab to see the "Resolved – Awaiting Validation" notification, tap it to navigate to the report detail, and view their Trusted Contributor badge earned from their accumulated Trust Score.

---

2. Demo Script

Total target time: 10 minutes Speakers: X (presenter / narrator), Y (web demo operator), Z (mobile demo operator)

---

0:00 – 0:20 | X — Introduction

"AccessMap is a community-driven accessibility reporting platform for people with mobility impairments. We'll walk through the full lifecycle of an obstacle — from guest discovery, through community verification, authority resolution, and admin moderation — across both our web and mobile apps."

---

0:20 – 1:10 | Y (web) — Scenario A: Guest Map Browsing

• Open the deployed web app unauthenticated (pre-loaded tab).
• Pan around Boğaziçi University South Campus area.
• Zoom in past the high-detail threshold → indoor POI markers appear inside buildings.
• Click an existing "Confirmed Obstacle" pin → popup shows description, photo, upvote/flag counts.
• Attempt to upvote → read-only counts and "Sign in to vote" label appear; interactive buttons are absent.
• X narrates: "Guests have full read access — they can discover obstacles and browse the map freely — but write actions require an account."

---

1:10 – 1:45 | Y (web) — Login & Profile

• Switch to pre-authenticated tab as User X (registered user, Mobility Profile: Wheelchair, Saved Places pre-loaded).
• Open Profile tab briefly → show Mobility Profile card and Saved Places.
• X narrates: "Registered users have a permanent mobility profile and saved destinations tied to their account."

---

1:45 – 2:45 | Z (mobile) — Scenario B: Outdoor Report Submission

• Logged in as User X on mobile.
• Tap Report tab → report form loads immediately (no sign-in prompt).
• Select context: Outdoor. Category: Broken Ramp.
• Upload a pre-saved photo. Add description: "The ramp at the south entrance has a crack making it impassable for wheelchair users."
• Submit → success screen appears with report ID.
• X narrates: "The system assigns status 'Unverified' on submission. No trust score changes yet — the community must validate it first."

---

2:45 – 3:30 | Y (web) — Community Upvote → Verified

• Switch to pre-authenticated tab as User Y (Trusted Contributor — badge visible on profile).
• The new "Unverified" pin appears near South Gate on the map.
• Click the pin → popup shows 0 upvotes, status "Unverified".
• Press Upvote → optimistic counter increments instantly.
• X narrates: "Trusted Contributors carry a lower verification threshold. A single upvote from User Y is enough to push this report to 'Confirmed Obstacle'. User X's trust score increases automatically."
• Pin style updates on the map to reflect the new status.

---

3:30 – 4:10 | Z (mobile) — Scenario C: Indoor Report

• Still logged in as User X on mobile.
• Zoom into a university building — indoor POI markers become visible.
• Tap Report → select context: Indoor. Category: Elevator Out of Service.
• Upload photo, submit.
• Y switches to the web and zooms into the same building — indoor pin is inside the building footprint, not on the street layer.
• X narrates: "Indoor obstacles are excluded from route calculations and are only rendered at high zoom — they don't clutter the street-level view."

---

4:10 – 4:50 | Y (web) — Route Planning & Passive Filter

• Open a guest tab (unauthenticated).
• Route planner: start = Beşiktaş Ferry Terminal, destination = Boğaziçi South Gate.
• Route renders as a static blueprint, routing around the confirmed ramp.
• Toggle "Show Inactive" chip → passive (stale) reports appear with semi-transparent styling.
• X narrates: "Passive reports are excluded from routing by default but users can choose to make them visible on the map."

---

4:50 – 6:00 | Y (web) — Scenario D: Authority Resolution

• Switch to pre-authenticated tab as User Z (Infrastructure Authority role).
• Open Authority Dashboard → filter by Confirmed Obstacle status → broken ramp appears.
• Open the report, upload post-repair verification photo, append repair note.
• Click Mark as Resolved – Awaiting Validation.
• X narrates: "The authority cannot simply close the report — it transitions to 'Resolved – Awaiting Validation' and the system automatically notifies the original reporter and all upvoters."

---

6:00 – 6:45 | Z (mobile) — Scenario F: Notifications & Profile

• Switch to User X's mobile session.
• Open Notifications tab → notification: "Your report status changed to Resolved – Awaiting Validation."
• Tap the notification → navigates to report detail.
• Open Profile → Trusted Contributor badge now visible.
• Toggle Notifications off in profile settings → Notifications tab shows "Notifications are off" banner.
• X narrates: "User X earned Trusted Contributor status automatically after their trust score crossed the threshold."

---

6:45 – 7:30 | Y (web) — Scenario E: Admin Moderation

• Switch to pre-authenticated tab as Admin.
• Open Flagged Reports queue → 3 pre-seeded fake reports listed with flag counts.
• Permanently delete one malicious report.
• Navigate to User Management → locate the spam account → Suspend.
• X narrates: "Admins can remove malicious content and restrict abusive accounts. Legitimate reports from other users are untouched."

---

7:30 – 8:10 | Y + Z — Resolution Validation: Closing the Loop

• Z (mobile, as User Y — previous upvoter): notification shows "Resolved – Awaiting Validation".
• Tap "Confirm Resolution" → vote registered.
• Y (web): threshold is met → status transitions to Closed/Archived — pin is removed from the active map layer.
• X narrates: "Closure is community-gated, not unilateral. The marker is only removed after citizens confirm the fix — closing the full lifecycle."

---

8:10 – 8:30 | Z (mobile) — Registration Flow (quick)

• Log out as User X on mobile.
• Show guest view of the Report tab → "Sign in to report" prompt with Sign in / Create account buttons.
• Tap Register → show registration form fields (email, full name, birth date, password).
• X narrates: "New users can register in seconds. Guests are gently prompted to sign up when they try to take an action that requires an account."

---

8:30 – 9:00 | X — Password Reset & Wrap-Up

• X briefly shows the "Forgot Password" flow on a pre-loaded browser tab (reset link sent to email).
• X: "We've demonstrated the complete obstacle lifecycle — guest discovery, outdoor and indoor reporting, trust-based community verification, authority resolution, admin moderation, and in-app notifications — all live on our deployed platform. Thank you."

---

3. Demo Data Strategy

User Accounts

Handle	Role	Trust Score	Notes
(no account)	Guest	—	Unauthenticated browser tab
user_x	Registered User	Just below Trusted Contributor threshold	Reporter; mobile device
user_y	Trusted Contributor	Above threshold — badge visible	Upvoter; web tab pre-authenticated
user_z	Infrastructure Authority	—	Authority dashboard tab pre-authenticated
admin	Admin	—	Admin panel tab pre-authenticated
spam_user	Regular (suspended live)	—	3 pre-seeded flagged fake reports attached

Pre-populated Reports

• Broken Ramp, Boğaziçi South Gate — Unverified, 0 upvotes, submitted by user_x. Upvoted to Confirmed live during demo.
• Narrow Sidewalk, Beşiktaş — Confirmed Obstacle, 7 upvotes. Shows confirmed pin style on the map before the demo's live action.
• Missing Tactile Paving, Kabataş — Passive status. Demonstrates passive semi-transparent style and the "Show Inactive" filter toggle.
• Elevator OOS, Engineering Building — Unverified, Indoor context. Demonstrates indoor pin at high zoom.
• 3 fake reports — each flagged by multiple users, linked to spam_user. Used in the admin moderation segment.

Pre-populated Notifications

• user_y has one pre-existing unread notification (Confirmed Obstacle for the Beşiktaş report they previously upvoted) — shows the notifications list is populated before the live demo triggers new ones.

Saved Places & Profile Data

• user_x: Mobility Profile (Wheelchair), Saved Places ("Home", "Boğaziçi South Gate").
• user_y: Trusted Contributor badge visible on profile page.

---

4. Role Assignments

Role	Person	Responsibility
Presenter / Narrator	X	Speaks throughout; explains business logic and transitions
Web Demo Operator	Y	Controls browser tabs, performs web actions
Mobile Demo Operator	Z	Runs the mobile app; handles report submission and notification segments
Timekeeper	—	Signals at 5:00, 8:00, and 9:30 marks
Observer / Notes	—	Watches for glitches; notes audience reactions

---

5. Technical Checklist Before Demo

• Deployed app is live on HTTPS and reachable from the demo venue network
• All user accounts created and login tokens confirmed working
• Pre-seeded data verified in production DB (reports, notifications, badges, saved places)
• Browser tabs opened, pre-authenticated, and arranged in presentation order
• Mobile device charged; user_x and user_y sessions logged in
• Indoor pin zoom threshold tested — markers appear and disappear at correct zoom level
• Route planner tested with demo start/end points
• Authority dashboard filter tested
• Admin delete and suspend tested on throwaway data beforehand
• Passive filter toggle tested on live data
• Password reset email flow tested (email delivery confirmed)