Wishlist: mark places as want-to-try vs. visited #7

New issue

Open

opened 2026-06-06 01:24:52 +02:00 by myrmidex · 0 comments

myrmidex commented

2026-06-06 01:24:52 +02:00

Owner

Most natural next feature — completes the original product vision.

The app currently treats every subject as implicitly visited/rated. The original vision distinguishes between places we want to try (wishlist) and places we've actually been to. Needs a design decision before build: is "wishlist" a status field on Subject, or simply the absence of any rating? Each approach has different implications for the map display (different pin style?), filtering, and the add-subject flow.

Scope: Design the data model, decide on the UX flow (how you add to wishlist vs. log a visit), update the map to visually distinguish wishlist pins from visited pins, and wire up the backend. Does not include child subjects or rating criteria.

Size: medium

**Most natural next feature — completes the original product vision.** The app currently treats every subject as implicitly visited/rated. The original vision distinguishes between places we want to try (wishlist) and places we've actually been to. Needs a design decision before build: is "wishlist" a status field on Subject, or simply the absence of any rating? Each approach has different implications for the map display (different pin style?), filtering, and the add-subject flow. **Scope:** Design the data model, decide on the UX flow (how you add to wishlist vs. log a visit), update the map to visually distinguish wishlist pins from visited pins, and wire up the backend. Does not include child subjects or rating criteria. **Size: medium**