Location permission flow

Problem Context

• The product wants current coordinates for nearby search, delivery estimate, check-in, route start, location-based support, safety sharing, field work, fraud signals, personalization, or device-local context.
• Users may be on web, mobile, desktop, kiosk, VPN, low signal, disabled location services, approximate-location mode, previously denied permission, background-restricted OS state, offline mode, or a shared device.
• The request may need one-time, while-using, session, background, precise, approximate, watched, or manual-location behavior depending on task risk and accuracy requirements.
• Location permission flow sits near generic permission request, map view, address entry, privacy settings, offline state, sensitive-data reveal, and saved place selection.

Selection Rules

• Choose location permission flow when current device coordinates are the central interaction and the task needs permission timing, precision, grant or denial recovery, and location lifecycle states.
• Use permission request when the resource access pattern is generic and not specifically about current coordinates, stale location, accuracy, tracking, or manual location fallback.
• Use map view when users mainly inspect or manipulate spatial information such as markers, routes, regions, or layers.
• Use address entry when a typed, searched, pasted, or saved postal address is sufficient and device coordinates would add privacy cost.
• Use privacy settings for durable location-history, sharing, analytics, app permission, or account-level controls outside the immediate task.
• Use offline state when connectivity prevents loading or submitting data; do not confuse network loss with location services disabled or permission denied.
• Request the least precision that satisfies the task, and accept approximate location where city, region, store sorting, or content localization is enough.
• Ask at the moment location helps the chosen task, not on app launch, sign-in, page load, hover, or unrelated navigation.
• Preserve task progress and offer manual address, saved place, retry, or settings recovery after denial, timeout, unavailable service, or stale coordinate.
• Expose active tracking, background use, stop sharing, and retention copy whenever location continues beyond a one-time current-position fix.

Required States

• Unsupported browser, blocked iframe, missing permissions policy, insecure context, or disabled location services state.
• Pre-permission rationale state with task purpose, precision need, scope, retention, and fallback.
• Prompt-ready state triggered by a deliberate user action.
• Allow once or one-time current-position state.
• While using or session permission state.
• Precise versus approximate location choice or explanation state.
• Background location denied or not requested state.
• Granted current fix state with coordinates summarized as place, accuracy, and timestamp.
• Permission denied state with manual fallback and retry guidance.
• Permanently denied or settings-required state with concise browser or OS settings recovery.
• Timeout, unavailable, low-accuracy, or position-error state.
• Stale cached coordinate state with last-updated time and refresh option.
• Manual address, ZIP, place search, or saved location fallback state.
• Active tracking or watch-position state with visible indicator.
• Stop sharing, revoke, or end session state.
• Privacy and retention state explaining what location is stored, for how long, and where to delete it.
• Offline state that distinguishes no network from no location permission.

Interaction Contract

• The native browser or OS prompt appears only after users understand why location is needed and choose a location-dependent action.
• The UI makes permission state, requested precision, requested scope, active tracking, last-updated time, and fallback status visible in text, not only through icons.
• Denial, timeout, unavailable service, approximate-only result, and stale coordinate states never erase the user's task context.
• Users can complete the task through manual address, saved place, place search, retry, or settings recovery when current location is unavailable.
• One-time or session location ends after the task unless users explicitly choose continued sharing.
• Location retention, sharing, background use, and deletion paths are disclosed before or immediately after sensitive location capture.

Implementation Checklist

• Define the task purpose, required precision, acceptable fallback, permission scope, retention rule, and whether a one-time fix or continuous watch is needed before building the prompt.
• Use secure contexts and platform permission APIs where available; handle prompt, granted, denied, revoked, blocked, timeout, unavailable, and unsupported states explicitly.
• Request location from a user action such as Use current location, Check in, Find near me, or Share trip, not on route load.
• Configure maximumAge, timeout, and high-accuracy options to match the task, then show accuracy and last-updated labels when a result is used.
• Provide manual address entry, saved places, search by ZIP, retry, and settings recovery routes that preserve the original task.
• Separate one-time current-position fixes from watch-position or background sharing, and expose Stop sharing or End session for active tracking.
• Avoid storing raw latitude, longitude, movement history, or inferred home/work locations unless the user understands purpose, duration, and deletion controls.
• Test denied permission, previously denied permission, approximate location, disabled location services, stale cache, low signal timeout, offline mode, keyboard, screen reader, mobile OS prompts, and browser settings recovery.

Common Generated-UI Mistakes

• Prompting for location before users choose a task that needs it.
• Requesting precise or background location when approximate or while-using access is enough.
• Treating permission denial as a dead end instead of offering address entry, saved place, retry, or settings recovery.
• Showing stale cached coordinates as current location.
• Using a map view as if it explained permission, accuracy, retention, or tracking state.
• Continuing to watch or store location after the task without a visible indicator or stop control.
• Mislabeling a permission denial or disabled location service as an offline state.

Critique Questions

• What task action triggers the location prompt, and what rationale appears before the native permission dialog?
• Is precise location necessary, or would approximate, ZIP, address, or saved place satisfy the task?
• What happens after one-time grant, while-using grant, denial, permanent denial, timeout, stale coordinate, unavailable service, and offline state?
• How does the UI show accuracy, age, active tracking, stop sharing, and retention?
• Can users complete the task without changing browser or OS settings?
• Is this really location permission flow, or is the main pattern a generic permission request, map view, address entry, privacy settings, or offline state?