Design Web-Client Viewer Map And Location Experience

[TheSilkky]

Design Web-Client Viewer Map And Location Experience

Priority

Very high

Type

Product design / API confirmation

Labels

backlog, frontend, design, accessibility, security, documentation, testing

Branch Scope

Created from docs/end-user-product-design at d2c32a3.

Background

The server currently documents token-scoped viewer routes and payload behavior. The end-user design document calls for a future React web-client viewer that can present shared read-only information, including latest shared location when the server payload provides it.

The web client should design this carefully before implementation because viewer links are bearer secrets and map providers may receive coordinates.

Proposed Scope

• Confirm the current viewer-token semantics and payload fields against open-proofline/server.
• Design the no-account viewer route for status, evidence summary, latest shared location, map display, and download actions.
• Define freshness, unavailable, redacted, and stale states for location.
• Define an accessible coordinate fallback for map failures.
• Specify how external map provider actions work without including viewer tokens in provider links.
• Review deployment, logging, and header implications before any map provider integration.

Acceptance Criteria

• The viewer design preserves token-scoped access semantics and does not introduce account-owner controls into the viewer route.
• The design describes what is shown when location is missing, stale, redacted, or unavailable.
• External map links never include viewer tokens or other bearer secrets.
• The viewer copy does not imply live tracking or emergency dispatch.
• Accessibility requirements for map fallback, keyboard navigation, and readable status text are documented.

Out Of Scope

• Backend route implementation.
• Live tracking claims.
• Browser decryption or key unwrapping.
• Raw viewer token display after creation.
• Notification delivery or emergency-service integration.

Suggested Validation

• Server API confirmation against open-proofline/server
• Product design review
• Security review for bearer-link and map-provider behavior
• Accessibility review for map fallback
• Full frontend validation if a later issue implements UI changes:
  • npm run typecheck
  • npm run lint
  • npm run test
  • npm run build
  • npm run test:e2e
  • git diff --check