Skip to content

Scenario 1: Disabled User Route Planning

Baran Önder edited this page Feb 19, 2026 · 5 revisions

User Profile

Can, a 21-year-old Computer Engineering student at Boğaziçi University. He is a wheelchair user who needs to navigate from the North Campus to Duatepe Park. He prefers a pre-planned, stable route over real-time navigation.


Goals

  • Generate a single, optimized accessibility route from North Campus to Duatepe Park.
  • View a static map that highlights the best path based on slope calculations and pre-reported obstacles from other users.
  • Use the map as a fixed guide without the distraction of real-time location tracking or automatic route changes.

Pre-Conditions

  • Can has entered his starting point (North Campus) and destination (Duatepe Park).
  • The application has processed the geospatial data and crowdsourced reports to find the one "best" path.
  • GPS tracking is disabled/not used; the user will navigate based on street names and visual landmarks shown on the map.

Main Flow

  1. Route Generation: Can requests a route. The system calculates exactly one suitable route that avoids any obstacles that may hinder wheelchair accessibility, such as steep inclines, narrow sidewalks, stairs, or ongoing construction.

  2. Displaying the Blueprint: The system presents a fixed map view with the route highlighted in bold. This is the only route Can will see for this session.

  3. Visualizing Pre-Reported Obstacles: On this fixed route, the system displays markers for obstacles previously reported by others (e.g., a "Road Construction" icon near the park entrance reported 2 hours ago).

  4. Manual Navigation: Can begins his journey. He looks at the map, identifies the street names, and matches them to his surroundings. There is no "blue dot" following him.

  5. Handling Wrong Turns: Can accidentally turns into a narrow side street not on the plan. True to the app's logic, no new route is created, and the map remains unchanged. Can realizes his mistake by comparing his visual surroundings to the static route on his screen.

  6. Correction: Can manually navigates back to the original highlighted path shown on the application.

  7. Final Approach: Can reaches Duatepe Park by following the specific "Fixed Path" that led him to the only accessible ramp entrance.


Criteria

1.1.1: The system shall allow users to define a mobility profile (e.g., wheelchair user) to customize route calculation.

1.1.2: The system shall allow users to manually input a starting point and a destination.

1.2.1: The system shall generate exactly one optimal route based on the user’s mobility constraints (slope, stairs, reported obstacles).

1.2.2: The system shall present the generated route as a static visual guide without the use of a real-time moving location marker (blue dot).

1.2.3: The system shall not perform automatic re-routing or path modification once the initial route is displayed.

1.2.4: The system shall highlight the chosen route in a bold, distinct visual format to assist manual navigation.

1.4.1: The system shall render all relevant accessibility markers (ramps, slopes, stairs) as static overlays on the generated route.

1.4.2: The system shall display pre-reported obstacles from other users as icons on the map.

1.4.3: The system shall display street names and key landmarks on the static map to facilitate manual orientation.

Neighborhood Accessibility Mapper - Scenario 1 Mock-up

Project

Team Members

Lab Reports

Weekly Meetings

Scenarios and Mock ups

Use Case Diagrams

Class Diagram

Sequence Diagrams

Milestone Review

Clone this wiki locally