-
Notifications
You must be signed in to change notification settings - Fork 0
Mobile App Routing Scenario
Mücahit Şimşek edited this page Apr 7, 2026
·
23 revisions
User Profile
- Name: Ayşe (28)
- Characteristics: An active manual wheelchair user. She loves exploring the city and trying out new places.
- Pain Points: She frequently gets stuck or has to take long detours due to unexpected high curbs, steep hills, or broken pavements in unfamiliar neighborhoods. She strongly dislikes surprise obstacles on her path.
Goals
- Motivation: Ayşe wants to meet a friend at a newly opened cafe in a neighborhood she hasn't visited before.
- Goal: To find the safest, most accessible route from her current location to the cafe that matches her physical capacity. She needs to avoid stairs, steep inclines, and missing curb ramps.
Pre-Conditions
- User has downloaded the app, registered an account.
- Device GPS (Location Services) is enabled and accurate.
- Device has an active internet connection (though offline map caches for her city are already downloaded).
- There is already a rich database of crowdsourced accessibility data (curb cuts, sidewalk widths, surface types) available in the system for this neighborhood.
Main Flow
- User opens the app and types the name of the destination cafe in the search bar on the home screen.
- System geolocates the cafe and cross-references the geographic data with the filters that Ayşe selected.
- System utilizes its geospatial routing algorithm and existing crowdsourced sidewalk conditions to calculate the best possible paths.
-
System displays two different accessible route options on the screen. The route cards show:
- Total distance and estimated time of arrival (ETA).
- A color-coded path on the map preview (e.g., Green = accessible surface, Yellow = manageable route, Red = avoid/inaccessible).
- User reviews the options. Route A is shorter but contains a yellow segment. Route B is slightly longer but entirely green (flat). User selects Route B because it offers a more comfortable and accessible journey.
- User taps the "Start Navigation" button.
- System initiates turn-by-turn navigation with audio and high-contrast visual cues. Safe pedestrian crossings, dropped curbs, and smooth sidewalks are highlighted in a thick green line on the map.
- User follows the guided route, successfully navigating via the pre-verified accessible crosswalks, and safely arrives at the cafe.
- System ends the navigation and displays a "Trip Complete" summary showing distance traveled and elevation avoided.
Criteria
- 1.1.1.1.1 Guest users shall be able to search for specific destinations using the search bar.
- 1.1.1.1.2 Guest users shall be able to start turn-by-turn navigation to a selected destination.
- 1.1.1.1.3 Guest users shall be able to select and apply physical capacity filters for routing.
- 1.1.1.2.3 Registered users shall be able to perform the same actions as guest users except sign-up.
- 1.1.3.1 Users shall be able to set and save accessibility routing filters based on their physical capacity.
- 1.2.4.1 The system shall geolocate searched destinations and cross-reference geographic data with the user's selected accessibility filters.
- 1.2.4.2 The system shall utilize a geospatial routing algorithm and existing crowdsourced data to calculate accessible paths.
- 1.2.4.3 The system shall calculate and display the total distance and estimated time of arrival (ETA) for generated routes.
- 1.2.4.4 The system shall display a color-coded path on the map preview to indicate accessibility levels (e.g., Green = accessible, Yellow = manageable, Red = avoid).
- 1.2.4.5 The system shall offer and display multiple route options for the user to review.
- 1.2.4.6 The system shall provide turn-by-turn navigation with audio cues.
- 1.2.4.7 The system shall provide high-contrast visual cues during navigation, highlighting safe paths with distinct visual lines.
- 1.2.4.8 The system shall track the user's live location via device GPS during active navigation.
- 1.2.4.9 The system shall display a "Trip Complete" summary showing the distance traveled and elevation avoided upon reaching the destination.
- 2.1.1 The system shall cache map data up to a 5 km radius and store the currently active route locally to ensure uninterrupted navigation when the device loses network connectivity.
- 2.3.1 The system shall display a native operating system permission dialog requesting explicit user consent before accessing the device's GPS hardware for the first time.
Mock-up
Team Members
- Lab 1 Report (12/02/2026)
- Lab 2 Report (19/02/2026)
- Lab 3 Report (26/02/2026)
- Lab 4 Report (05/03/2026)
- Lab 5 Report (12/03/2026)
- Lab 6 Report (26/03/2026)
- Lab 7 Report (02/04/2026)
- Lab 8 Report (16/04/2026)
- Lab 9 Report (30/04/2026)
- Lab 10 Report (07/05/2026)
- Weekly Meeting 1 (17.02.2026)
- Weekly Meeting 2 (26.02.2026)
- Weekly Meeting 3 (08.03.2026)
- Weekly Meeting 4 (12.03.2026)
- Weekly Meeting 4 'Extra' (14.03.2026)
- Weekly Meeting 5 (22.03.2026)
- Weekly Meeting 6 (28.03.2026)
- Weekly Meeting 7 (03.04.2026)
- Weekly Meeting 8 (14.04.2026)
- Weekly Meeting 9 (22.04.2026)
- Weekly Meeting 10 (08.05.2026)
- Frontend Meeting 1 (22.03.2026)
- Backend Meeting 1 (22.03.2026)
- Frontend Meeting 2 (28.03.2026)
- Backend Meeting 2 (28.03.2026)
- Frontend Meeting 3 (03.04.2026)
- Backend Meeting 3 (03.04.2026)
- Backend Meeting 4 (22.04.2026)
- Meeting with Arda Arslan (17.02.2026)
- Meeting with Özlem Belir (25.02.2026)
- Meeting with Suzan Üsküdarlı (17.04.2026)
Mapcess