Final Demo Plan

Final Demo Plan — NEPH

1. Demo Goal

The goal of this demo is to present NEPH — Neighborhood Emergency Preparedness Hub as a deployed, live, cross-platform emergency preparedness and mutual-aid system through a realistic crisis story.

The demo will focus on a short earthquake scenario instead of presenting features one by one. We will show how NEPH supports:

• citizens requesting help during a crisis,
• mobile-first and offline-first emergency usage,
• volunteers becoming available and responding to assigned requests,
• responders viewing assigned requests,
• admins/coordinators monitoring the crisis from the web,
• admins publishing announcements based on crisis data,
• users accessing safety features such as safety circles,
• users finding nearby visible people from their residential area,
• users accessing preparedness features such as gathering areas and directions,
• safe users checking live help requests through the Help Request Map.

The demo will be performed on the deployed application through a secure public HTTPS URL.

2. Demo Assumptions

For the final demo, we assume that the following are working:

• Web application is deployed and accessible via HTTPS.
• Mobile app is connected to the deployed backend.
• Authentication works on both platforms.
• Demo accounts and realistic data are already prepared before the presentation.
• Help request creation, request tracking, offline local save/sync, volunteer availability, assigned request, safety circles, nearby users, gathering areas, announcements, notifications/news, Help Request Map, and admin dashboard are functional enough for the demo.
• At least one active request, one assigned request, one resolved/closed request, one safety circle member in an unsafe/no-response state, one nearby residential-area user, one gathering area, and one active map request exist in the demo data.
• Backup screenshots, prepared states, or a short backup video are prepared in case live submission, sync, assignment, notification, location, or map services fail.

3. Core Demo Story

The demo follows a neighborhood earthquake scenario.

An earthquake affects a neighborhood. A registered resident is injured and needs urgent help. While creating a help request from the mobile app, the connection drops. NEPH keeps the request locally and synchronizes it when the connection returns. A nearby volunteer marks himself available, opens the assigned request, reaches the requester, and the request is later marked as resolved after the immediate situation is under control.

In the second part, a user checks his Safety Circle after the earthquake. He is safe, but his sibling is unreachable or appears as needing help. Since direct communication fails, he uses NEPH’s residential-area nearby user cache to find a trusted nearby neighbor. The neighbor checks on the sibling and uses Gathering Areas to choose a nearby assembly area or shelter.

In the final part, an admin coordinator monitors the situation from the web admin dashboard. He notices that active requests around Beşiktaş are too high even though nearby volunteers are already being assigned. He publishes an urgent announcement asking extra safe users near the area to check the Help Request Map. A safe user receives or opens the announcement, checks the live request map, filters requests, selects a suitable request, and gets directions.

The main message is:

NEPH connects people who need help, people who can help, and coordinators who need to understand the whole crisis.

4. Demo Structure

Total target duration: 8 minutes

Time	Speaker	Platform	Section	Purpose
0:00–0:15	Ethem Erinç Cengiz	Verbal / Web or Mobile	Introduction	Briefly explain NEPH’s vision and the three connected emergency scenarios.
0:15–3:15	Gülce Tahtasız, Mehmet Can Gürbüz	Mobile	Offline help request and volunteer assignment	Show urgent help request creation, connection loss, local save, sync, volunteer availability, assigned request, and resolution.
3:15–6:00	Alper Kartkaya, Rojhat Delibaş	Mobile	Safety circle, residential nearby cache, and gathering areas	Show safety check-in, unreachable sibling, residential-area nearby user cache, neighbor support, gathering area filtering, and directions.
6:00–7:50	Berat Sayın, Kağan Can	Web + Mobile	Admin announcement and live request map	Show admin overview, urgent announcement publishing, announcement visibility, Help Request Map filtering, request selection, and directions.
7:50–8:00	Ethem Erinç Cengiz	Verbal	Closing	Summarize the final value of NEPH briefly.

5. User Scenarios

Scenario 1 — Offline Help Request, Volunteer Assignment, and Resolution

User role: Registered requester and nearby volunteer
Example user: Gülce Tahtasız and Mehmet Can Gürbüz
Platform: Mobile
Purpose: Show the main emergency flow from help request creation to responder action and request resolution.

Flow:

1. Open the mobile app as a logged-in requester.
2. Show the home screen.
3. Tap the emergency help action.
4. Open Request Help.
5. Fill only the most critical request fields because the situation is urgent.
6. Use current location instead of typing a long address.
7. Simulate internet connection loss during the request flow.
8. Submit the request while offline.
9. Show that the request is saved locally and remains visible in My Help Requests.
10. Restore the connection and show that the request synchronizes with the backend.
11. Switch to the volunteer account.
12. Mark the volunteer as available.
13. Open the assigned request or notification.
14. Show help type, urgency/priority, situation details, location, contact information, and directions.
15. Switch back to the requester.
16. Show assigned helper details if available.
17. Mark the request as resolved after the immediate situation is under control.

What this proves:

• Prepared users can request help faster.
• Mobile is suitable for crisis usage.
• NEPH supports unstable disaster connectivity.
• Requests are not lost when the network drops.
• Help requests are synchronized after connectivity returns.
• Volunteers can become available and act on assigned requests.
• Assigned request details are actionable in the field.
• Request lifecycle can be closed after help arrives.

---

Scenario 2 — Safety Circle, Residential Nearby Cache, and Gathering Areas

User role: Safe family member and nearby neighbor
Example user: Alper Kartkaya and Rojhat Delibaş
Platform: Mobile
Purpose: Show family safety awareness, residential-area local neighborhood awareness, and safe movement after a disaster.

Flow:

1. Open the mobile app as a safe user after the earthquake.
2. Navigate to Safety Circles.
3. Mark the user as safe.
4. Show a sibling or trusted contact as Needs Help or No Response.
5. Act out that direct phone communication fails.
6. Open Nearby Users.
7. Explain that this list is based on residential/profile-area nearby users, not instant GPS proximity.
8. Show a nearby visible user from the home area.
9. Contact the nearby neighbor and ask him to check on the sibling.
10. Switch to the neighbor’s mobile flow.
11. The neighbor confirms that he found the sibling and needs to move them to a safer place.
12. Open Gathering Areas.
13. Use current location or show a prepared nearby result.
14. Show map/list results.
15. Filter unnecessary categories such as police or fire stations.
16. Keep useful options such as shelters and assembly areas.
17. Select a suitable nearby gathering area.
18. Show distance/details and directions.

What this proves:

• NEPH supports trusted safety check-ins.
• Users can communicate their own safety status quickly.
• Families can identify unsafe or unreachable members.
• Residential-area nearby cache helps users find relevant neighborhood contacts.
• Gathering areas support safe movement after a disaster.
• Category filtering helps users focus on useful places.
• Directions connect information to action.

---

Scenario 3 — Admin Coordination, Announcement, and Live Help Request Map

User role: Admin / coordinator and safe user
Example user: Berat Sayın and Kağan Can
Platform: Web + Mobile
Purpose: Show how admin monitoring turns into user-facing coordination and action.

Flow:

1. Open the deployed web application through HTTPS.
2. Start from an already-authenticated admin/coordinator account.
3. Open the admin dashboard.
4. Show Emergency Overview.
5. Show headline metrics such as active emergencies, recent activity, request statuses, and urgency/priority levels.
6. Explain that Beşiktaş has too many active requests.
7. Explain that nearby volunteers are already being assigned, but extra safe users may still be needed.
8. Create and publish an urgent announcement.
9. Switch to the safe user’s mobile app.
10. Open Notifications or News & Announcements.
11. Open the latest announcement.
12. Navigate to Help Request Map.
13. Refresh the map if needed.
14. Filter requests by type, such as First Aid or Search & Rescue.
15. Select one request marker or list item.
16. Show priority, location, opened time, and directions.

What this proves:

• The web platform supports coordination and oversight.
• Admins can understand the current emergency situation.
• Admins can publish announcements based on operational data.
• Announcements guide safe users toward live crisis information.
• Help Request Map gives users visibility into nearby active needs.
• Users can filter and inspect requests before deciding to help.

6. Detailed 8-Minute Script

0:00–0:15 — Introduction

Ethem Erinç Cengiz:

Ethem briefly introduces NEPH as a neighborhood-level emergency coordination system and explains that the demo will follow three connected emergency scenarios. He also explains that he will operate the demo screens while the presenters act out the user journeys.

Action:

• Show the deployed web application, Android Home screen, or another clean starting screen.
• Keep this section short.
• Switch to Gülce’s mobile screen immediately after the intro.

---

0:15–3:15 — Scenario 1: Offline Help Request and Volunteer Assignment

Gülce Tahtasız:

Gülce introduces herself as the injured requester. She explains that after the earthquake, something has fallen on her leg and she needs urgent help. She opens NEPH and starts the emergency help request flow.

Action:

1. Show Gülce’s mobile Home screen.
2. Tap “I need help now.”
3. Open Request Help.
4. Fill only critical fields:
   • help type,
   • affected people count,
   • key risk flag,
   • current location,
   • confirmation/consent.
5. Skip optional description unless needed.

Gülce Tahtasız:

Gülce explains that she only selects the most important fields because the situation is urgent. She points out that she uses current location instead of typing a long address and that optional details can be skipped in an emergency.

Action:

1. Disable internet during the form flow.
2. Submit the request.
3. Open My Help Requests.
4. Show local/pending/saved state.
5. Restore internet.
6. Refresh or show synced state.

Gülce Tahtasız:

Gülce explains that the connection drops while she is filling the form. She points out that NEPH does not discard the request and keeps it locally until the connection returns. After reconnection, she explains that the request synchronizes and becomes available for the system.

Mehmet Can Gürbüz:

Mehmet Can introduces himself as the nearby volunteer. He explains that he is safe enough to help and marks himself available in NEPH.

Action:

1. Switch to Mehmet Can’s mobile screen.
2. Mark him available.
3. Open notification if it appears.
4. Otherwise open Assigned Request directly.
5. Show type, urgency/priority, situation details, location, contact, and directions.

Mehmet Can Gürbüz:

Mehmet Can explains that availability and location allow the system to match him with a nearby emergency. He opens the assigned request and explains that the screen gives him the needed field information.

Action:

1. Switch back to Gülce.
2. Show assigned helper details if visible.
3. Act out Mehmet Can reaching Gülce.
4. Mark the request as resolved.

Gülce Tahtasız:

Gülce explains that she can see a volunteer has been assigned and that this reduces uncertainty. After Mehmet Can reaches her and the immediate emergency is under control, she marks the request as resolved.

Mehmet Can Gürbüz:

Mehmet Can briefly summarizes that this scenario showed request creation, offline preservation, synchronization, volunteer assignment, and request resolution.

---

3:15–6:00 — Scenario 2: Safety Circle, Residential Nearby Cache, and Gathering Areas

Alper Kartkaya:

Alper introduces himself as a safe user checking his family after the earthquake. He explains that he opens Safety Circles to check whether his trusted contacts are okay.

Action:

1. Show Alper’s mobile screen.
2. Open Safety Circles.
3. Mark Alper as safe.
4. Show sibling/contact as Needs Help or No Response.

Alper Kartkaya:

Alper explains that Safety Circles are for trusted people such as family, close friends, and neighbors. He marks himself safe, then notices that his sibling has not marked safe or appears as needing help. He acts out that direct phone communication fails.

Action:

1. Open Nearby Users.
2. Show residential-area nearby user cache.
3. Show Rojhat as a nearby visible user.
4. Do not present this as instant GPS-based proximity.

Alper Kartkaya:

Alper explains that Nearby Users is useful here because it keeps nearby visible users from the residential/profile area. He finds Rojhat from the home area and contacts him because Rojhat may be closer to the sibling.

Rojhat Delibaş:

Rojhat introduces himself as the nearby neighbor. He explains that he checks on Alper’s sibling, finds them conscious, and decides to move them away from the damaged building to a safer gathering area.

Action:

1. Switch to Rojhat’s mobile screen.
2. Open Gathering Areas.
3. Use current location if stable.
4. Show map/list results.
5. Show category filters.
6. Filter unnecessary categories such as police or fire stations.
7. Keep shelters and assembly areas visible.
8. Select a nearby suitable result.
9. Show directions.

Rojhat Delibaş:

Rojhat explains that Gathering Areas helps him find useful safe locations nearby. He filters out unnecessary categories, keeps shelters and assembly areas, selects a suitable location, checks the distance, and gets directions.

Alper Kartkaya:

Alper closes the scenario by explaining that NEPH supports family safety, residential-area neighborhood awareness, and safe movement to gathering areas after a disaster.

---

6:00–7:50 — Scenario 3: Admin Coordination, Announcement, and Live Help Request Map

Berat Sayın:

Berat introduces himself as the admin coordinator. He explains that he uses the web admin panel to understand the overall emergency situation instead of focusing on a single request.

Action:

1. Switch to web admin panel.
2. Show Emergency Overview or dashboard.
3. Show active emergencies, recent activity, statuses, urgency/priority, and regional concentration if visible.

Berat Sayın:

Berat explains that the dashboard helps him understand active emergencies, recent activity, request statuses, and urgency levels. He points out that Beşiktaş has too many active requests and that extra safe users may still be needed even though nearby volunteers are already being assigned.

Action:

1. Open announcement creation.
2. Enter the prepared title and content.
3. Publish the announcement.
4. Trigger broadcast/notification if stable.

Announcement title:

Urgent Update: Extra Help Needed Around Beşiktaş

Announcement content:

Multiple active help requests have been reported around Beşiktaş. Nearby volunteers are being assigned, but extra safe users may still be needed. If you are safe and close to the area, please check the Help Request Map before moving.

Berat Sayın:

Berat explains that the announcement helps reach safe users who are not directly assigned yet and directs them to the live Help Request Map.

Kağan Can:

Kağan introduces himself as a safe user who receives or opens the admin announcement. He explains that after seeing the announcement, he checks the Help Request Map to understand the situation.

Action:

1. Switch to Kağan’s mobile app.
2. Open Notifications if the notification arrives.
3. Otherwise open News & Announcements.
4. Open the latest announcement.
5. Open Help Request Map.
6. Refresh if needed.
7. Filter by request type.
8. Select one request.
9. Show priority, location, opened time, and directions.

Kağan Can:

Kağan explains that although he is not directly assigned, he is safe and can inspect nearby requests. He filters the map by request type, selects a request he may be able to help with, checks priority and location, and gets directions.

Berat Sayın and Kağan Can:

Berat and Kağan close the scenario by explaining that admin coordination and citizen response are connected through announcements and the live Help Request Map.

---

7:50–8:00 — Closing

Ethem Erinç Cengiz:

Ethem briefly concludes that NEPH aims to make emergency response more coordinated, accessible, and community-driven, then thanks the audience.

Action:

• End on Admin Emergency Overview, NEPH Home, Help Request Map, or another clean screen.
• Do not open a new feature at the last second.

7. Demo Data Strategy

7.1 User Roles

| Role | Example User | Platform | Purpose | |---|---|---| | Admin / coordinator | Berat Admin | Web | Monitors requests, emergency data, and publishes announcements. | | Registered requester | Gülce Tahtasız | Mobile | Shows urgent registered request flow with offline-first behavior. | | Volunteer / responder | Mehmet Can Gürbüz | Mobile | Shows availability, assignment, assigned request details, and response. | | Safety circle user | Alper Kartkaya | Mobile | Shows trusted safety check-in and family status tracking. | | Nearby residential-area neighbor | Rojhat Delibaş | Mobile | Shows nearby user support and gathering area usage. | | Safe announcement receiver | Kağan Can | Mobile | Shows announcement visibility and Help Request Map response. |

7.2 Pre-Populated Users

Admin User

Should have access to:

• admin dashboard,
• emergency overview,
• active operational snapshot,
• analytics or regional information if available,
• announcement creation,
• notification/broadcast flow if available.

Registered Requester: Gülce

Should have a completed profile:

• full name,
• phone number,
• country/city/district/neighborhood,
• extra address if needed,
• basic contact information,
• physical/health details if they are visible in relevant request flows.

Volunteer / Responder: Mehmet Can

Should have:

• active account,
• availability flow ready,
• assigned request state ready or prepared fallback,
• visible requester details,
• visible location and urgency information,
• visible contact information,
• directions option if available.

Safety Circle User: Alper

Should have:

• active account,
• safety circle membership,
• ability to mark self as safe,
• sibling/trusted contact in Needs Help or No Response state,
• access to Nearby Users.

Nearby Neighbor: Rojhat

Should have:

• active account,
• visible nearby user data in Alper’s residential/profile-area cache,
• access to Gathering Areas,
• current location or prepared gathering area results.

Safe User: Kağan

Should have:

• active account,
• access to Notifications or News & Announcements,
• ability to see the admin announcement,
• access to Help Request Map,
• visible active/waiting requests on the map.

7.3 Help Request Data

Prepare at least the following help requests before the demo:

Request	Status	Purpose
Request 1	Local/pending or newly created	Shows Gülce’s request during offline-first flow.
Request 2	Synced active	Shows synchronized state after connection returns.
Request 3	Assigned / in progress	Shows Mehmet Can’s Assigned Request screen.
Request 4	Resolved / completed	Shows lifecycle progression after Gülce marks resolved.
Request 5	Waiting / active with coordinates	Shows Help Request Map for Kağan.
Request 6	High urgency around Beşiktaş	Makes admin dashboard and announcement scenario realistic.

7.4 Emergency Information Data

Prepare realistic emergency information such as:

• nearby gathering areas,
• gathering area categories,
• assembly area and shelter markers,
• optional police/fire station categories for filtering,
• realistic district/neighborhood names,
• active request map markers,
• announcement/news content,
• notification or news fallback data.

7.5 Data Quality Rules

• Use realistic but fictional Turkish names.
• Use realistic but non-sensitive addresses.
• Avoid joke names and placeholder text like “test test.”
• Keep request descriptions short and believable.
• Prepare all important data before the demo.
• Do not rely on creating every record live during the presentation.
• Make sure demo data matches the final three scenarios exactly.
• Make sure Nearby Users is explained as residential/profile-area based in Scenario 2.
• Make sure the admin announcement content matches the final demo story.

Example request descriptions:

• “The building entrance is blocked after the earthquake.”
• “Person is injured and cannot leave the building.”
• “Multiple active help requests reported around Beşiktaş.”
• “Family needs temporary shelter after building damage.”
• “Resident needs evacuation support due to blocked apartment entrance.”

8. Role Assignments

There are 7 team members, and each member will present one part.

Team Member	Responsibility
Ethem Erinç Cengiz	Introduction, closing, and primary screen operation
Gülce Tahtasız	Scenario 1 requester role
Mehmet Can Gürbüz	Scenario 1 volunteer/responder role
Alper Kartkaya	Scenario 2 safety circle/family user role
Rojhat Delibaş	Scenario 2 nearby neighbor and gathering areas role
Berat Sayın	Scenario 3 web admin coordinator role
Kağan Can	Scenario 3 safe user responding to announcement

Additional operational roles:

Responsibility	Assigned To
Main demo operator	Ethem Erinç Cengiz
Admin web preparation	Berat Sayın
Mobile demo preparation	Ethem Erinç Cengiz / relevant scenario owners
Timekeeper	Kağan Can
Backup operator	Mehmet Can Gürbüz
Scenario 1 data check	Gülce Tahtasız / Mehmet Can Gürbüz
Scenario 2 data check	Alper Kartkaya / Rojhat Delibaş
Scenario 3 data check	Berat Sayın / Kağan Can
Technical recovery lead	Mehmet Can Gürbüz or Berat Sayın

9. Rehearsal Plan

The team should rehearse the full demo at least once before the final presentation.

Rehearsal Goals

• Keep the full demo under 8 minutes.
• Make transitions between speakers smooth.
• Present the demo as one earthquake story, not as separate feature descriptions.
• Avoid long technical explanations.
• Avoid unnecessary live typing.
• Make sure web-to-mobile transition is fast.
• Make sure each speaker knows exactly when to start and stop.
• Confirm that all prepared accounts and data are working.

Rehearsal Checklist

• Web app opens from HTTPS URL.
• Admin account is already logged in.
• Admin dashboard loads correctly.
• Emergency overview has meaningful data.
• Announcement creation works.
• Notification delivery or News & Announcements fallback is ready.
• Help Request Map has active requests.
• Mobile app is installed and connected to production backend.
• Gülce user is already logged in.
• Request Help flow is ready.
• Offline/local/sync behavior can be shown or explained clearly.
• My Help Requests has meaningful request statuses.
• Mehmet Can user is already logged in.
• Volunteer availability flow is ready.
• Assigned Request has realistic responder data.
• Mark Resolved action works or prepared resolved state exists.
• Alper user is already logged in.
• Safety Circle has meaningful member states.
• Nearby Users shows residential-area nearby user data.
• Rojhat user is already logged in.
• Gathering Areas page works or has prepared state.
• Gathering area filters and directions are tested.
• Kağan user is already logged in.
• Notifications or News & Announcements can show the final announcement.
• Screen sharing for mobile is tested.
• All speakers practiced their section.
• Backup screenshots and video are ready.

10. Backup Plan

Risk 1 — Internet Connection Fails

Backup:

• Use a pre-recorded demo video.
• Keep screenshots of each major screen.
• Continue narration using the backup material.
• Emphasize that offline-first behavior is part of NEPH’s crisis design.

Risk 2 — Deployed Web App Fails

Backup:

• Use already-open browser tabs if they are still loaded.
• Use screenshots of the admin dashboard, emergency overview, and operational snapshot.
• Continue with mobile demo if mobile still works.

Risk 3 — Backend/API Fails During Live Submission

Backup:

• Do not depend only on live request creation.
• Use pre-populated help requests.
• Show the final expected state from My Help Requests, Help Request Map, or admin overview.

Risk 4 — Mobile App Connection Fails

Backup:

• Use a pre-recorded mobile walkthrough.
• Use screenshots from the mobile app.
• Show local request state if available.
• Continue explaining the intended user flow.

Risk 5 — Login Fails

Backup:

• Start from already-authenticated sessions.
• Keep multiple accounts prepared.
• Keep browser tabs and mobile screens open before the demo starts.

Risk 6 — Location or Map Service Fails

Backup:

• Use prepared coordinates or manually entered location.
• Use already-loaded map state.
• Use screenshots of Help Request Map and Gathering Areas.
• Explain that users can continue with manual location entry.

Risk 7 — Time Runs Short

Backup:

Prioritize these sections:

1. Scenario 1 core request flow.
2. Offline local save / sync explanation.
3. Volunteer assigned request.
4. Scenario 2 safety circle and nearby residential cache.
5. Scenario 3 admin announcement and Help Request Map.

Skip or shorten:

• long form field explanations,
• detailed scrolling,
• external directions app opening,
• repeated helper/contact details,
• detailed analytics explanations,
• optional notification waiting,
• optional map category explanations.

Risk 8 — Assignment or Notification Is Delayed

Backup:

• For assignment delay, open the prepared Assigned Request state.
• For notification delay, open Notifications or News & Announcements manually.
• Avoid waiting silently for push delivery during the demo.

11. Lessons From Previous Demo

In the previous demo, the presentation was weaker because the flow was not structured enough and the team focused too much on separate screens instead of one clear story.

For the final milestone, we will improve by:

• presenting a realistic earthquake scenario,
• giving each speaker a clear role,
• making the demo feel like one connected crisis workflow,
• using prepared accounts and data,
• reducing live typing,
• emphasizing deployed functionality,
• showing both web and mobile clearly,
• showing the most important product value instead of every feature,
• preparing backup screenshots and video,
• rehearsing the full 8-minute flow before the demo.

12. Final Message

The final message of the demo is:

NEPH is a deployed, cross-platform emergency preparedness and mutual-aid system. It helps neighborhoods prepare before disasters, request help during crises, coordinate volunteers and responders, and monitor emergency activity through a live web dashboard.