59 lines
4.7 KiB
Markdown
59 lines
4.7 KiB
Markdown
# Request location picker — design QA
|
||
|
||
## Evidence
|
||
|
||
- Source visual truth: `/home/simple/.codex/generated_images/019f725d-87b5-79e1-8a9f-66e6eaffb35a/exec-d7ad900f-ed0f-4909-8a64-43bfc32dce7e.png`
|
||
- Browser-rendered implementation: `/d/my_projects/who_need_help/output/playwright/location-picker-real-map-focused.png`
|
||
- Full browser viewport: `/d/my_projects/who_need_help/output/playwright/location-picker-real-map-selected.png`
|
||
- Side-by-side comparison: `/d/my_projects/who_need_help/output/playwright/location-picker-real-map-comparison.png`
|
||
- Source pixels: `1672×941` at the supplied image density.
|
||
- Implementation component pixels and CSS size: `1024×888`, captured at `deviceScaleFactor: 1`.
|
||
- Full browser viewport: `1673×1288` CSS pixels at `deviceScaleFactor: 1`.
|
||
- Normalization: both focused images were scaled to `900 px` height only for the side-by-side comparison; the original captures remain available above.
|
||
- State: light theme, authenticated request form, approximate-area mode, `1 km` radius, selected Kyiv map position.
|
||
|
||
## Full-view comparison evidence
|
||
|
||
The implementation keeps the reference hierarchy: public landmark field, three privacy choices, large map, radius controls, privacy guidance, post-match guidance, status, and manual-coordinate fallback. It uses the existing Who Need Help container width and type scale, so the component is narrower than the standalone concept while preserving the same information structure.
|
||
|
||
The live implementation now renders real OpenStreetMap raster tiles, a bounded translucent area, and a green draggable MapLibre marker. The marker is intentionally visible only in the editing form. Public request maps render the area without disclosing a center marker.
|
||
|
||
## Focused-region comparison evidence
|
||
|
||
The focused component capture makes the important interaction details readable. Typography, spacing, semantic green, radii, borders, map attribution, control hierarchy, and instructional copy were compared directly. No additional crop was needed because the component screenshot contains the entire location workspace at native CSS density.
|
||
|
||
## Required fidelity surfaces
|
||
|
||
- Fonts and typography: existing application font stack and optical weights are consistent across the form; headings, control labels, help text, and map hint retain clear hierarchy without clipping.
|
||
- Spacing and layout rhythm: the three modes align as one segmented control; map and sidebar tracks remain balanced; cards, status, and fallback use the existing form rhythm.
|
||
- Colors and visual tokens: success green, neutral borders, translucent area fill, warning semantics, and contrast use the existing DaisyUI/application tokens.
|
||
- Image and asset quality: real OpenStreetMap tiles are sharp at the checked density; MapLibre and Heroicons supply map controls, marker, and UI icons. No placeholder map or handcrafted icon remains.
|
||
- Copy and content: the interface explicitly says how to move the area, what becomes public, and what can be shared privately after matching.
|
||
|
||
## Comparison history
|
||
|
||
1. P1 — the first visual E2E preview used a deterministic solid tile, which looked like a missing map. Fixed by running the visual review stack with the configured OpenStreetMap tile URL. Post-fix evidence: `location-picker-real-map-focused.png`.
|
||
2. P1 — the area could be moved by clicking, but that affordance was not discoverable and the circle itself had no drag handle. Fixed by adding a green draggable center marker, live circle movement, a map overlay hint, and a persistent status message. Post-fix evidence: `location-picker-real-map-focused.png` and the passing drag E2E scenario.
|
||
3. P2 — the map-unavailable fallback could retain the movement hint after a LiveView patch. Fixed by persisting the unavailable state in the hook and hiding the hint in fallback mode. Post-fix evidence: the Firefox fallback branch in the passing cross-browser E2E scenario.
|
||
|
||
## Current findings
|
||
|
||
- P0: none.
|
||
- P1: none.
|
||
- P2: none.
|
||
- P3: the implementation adds more explicit safety/help copy than the concept; this is an intentional product constraint and does not obstruct the map task.
|
||
|
||
## Interaction and runtime checks
|
||
|
||
- Clicking the map creates or moves the area.
|
||
- Dragging the green marker moves the circle and updates the stored center.
|
||
- `500 m`, `1 km`, and `2 km` are the only selectable public radii.
|
||
- Exact mode uses a separate red draggable marker.
|
||
- No-map mode clears coordinates and hides map controls.
|
||
- Chromium and WebKit exercised the map and drag interaction; the containerized Firefox runner exercised the no-Canvas fallback.
|
||
- Server test suite: `302 passed`.
|
||
- Targeted browser E2E: `3 passed` across Chromium, Firefox, and WebKit.
|
||
- Visible Chrome console after the final interaction: `0 errors`, `0 warnings`.
|
||
|
||
final result: passed
|