From 8700d197f0317d5fd56b4817ae93fa56dca4e4c1 Mon Sep 17 00:00:00 2001 From: ulfrxdev Date: Sat, 16 May 2026 23:44:55 +0200 Subject: [PATCH] Search/catalog planning notes --- .planning/notes/nav-search-as-catalog.md | 39 +++++++++++++++++++ .planning/seeds/home-tab-content.md | 36 +++++++++++++++++ .../pending/decide-add-recipe-placement.md | 29 ++++++++++++++ 3 files changed, 104 insertions(+) create mode 100644 .planning/notes/nav-search-as-catalog.md create mode 100644 .planning/seeds/home-tab-content.md create mode 100644 .planning/todos/pending/decide-add-recipe-placement.md diff --git a/.planning/notes/nav-search-as-catalog.md b/.planning/notes/nav-search-as-catalog.md new file mode 100644 index 0000000..873c6b5 --- /dev/null +++ b/.planning/notes/nav-search-as-catalog.md @@ -0,0 +1,39 @@ +--- +title: Nawigacja — search jako katalog przepisów + nowy tab Home +date: 2026-05-16 +context: Eksploracja zmiany struktury nawigacji przed Phase 2.1 (app shell/navigation/search) i Phase 5 (Recipe catalog) +--- + +# Nawigacja — search jako katalog przepisów + nowy tab Home + +## Decyzje kierunkowe + +1. **Usuwamy tab Przepisy z docka.** Search button (siostra docka, zgodnie z `project_dock_layout.md`) staje się wejściem do bogatego ekranu-katalogu z kategoriami, browse i filtrem po składnikach. Wpisywanie tekstu w pole to drugorzędna ścieżka — główna interakcja to *przeglądanie*, nie *known-item search*. + +2. **Dodajemy tab Home przed Planerem.** Charakter: landing z podsumowaniami i propozycjami — ma *coś podpowiadać* użytkownikowi, a nie być pasywnym ekranem powitalnym. Konkretny scope widgetów odłożony (patrz seed `home-tab-content.md`). + +## Driver + +Rezerwa slotów w docku na przyszłe funkcje — m.in. "co mam w lodówce → przepis", dodawanie przepisów, potencjalnie inne discovery flows. Bezpośrednia inspiracja: Apple Music (search jako siostra/przycisk obok zakładek, otwierający kategorie zanim użytkownik cokolwiek wpisze). + +## Napięcie do rozwiązania w Phase 2.1 + +Obecny model search (z memory `project_dock_layout.md`) to **overlay w 3 stanach** (closed / open-unfocused / open-focused) z zablokowanym backiem. Nowy model wymaga **pełnej destynacji** z back-stackiem: browse kategorii → szczegóły przepisu → back do listy → filtr → itd. + +Trzy ścieżki do rozważenia w designie: +- **A.** Overlay rozrasta się płynnie w pełen ekran (animacja przejścia stan otwarty-niezaogniskowany → destynacja); back-stack aktywuje się dopiero po pierwszej akcji navigacyjnej. +- **B.** Search button przestaje być overlayem; od razu nawiguje do dedykowanej destynacji (ekran katalogu z search bar na górze). Prościej, ale tracimy "lekkość" overlaya na innych ekranach. +- **C.** Hybryda: overlay pozostaje dla quick-search z każdego ekranu (wpisz frazę → wyniki), ale tap w "browse categories" wewnątrz overlaya nawiguje do pełnej destynacji. + +Decyzja do podjęcia w `/gsd-discuss-phase 2.1` lub w sketch passie. + +## Sprawy zaparkowane + +- Umiejscowienie akcji "+Dodaj przepis" (Home / toolbar app shell / ekran katalogu / ustawienia). Niska częstotliwość użycia — może być dwa-tapy głębiej. Patrz todo `decide-add-recipe-placement.md`. +- Konkretny scope widgetów Home. Patrz seed `home-tab-content.md`. + +## Wpływ na roadmapę + +- **Phase 2.1 (app shell/navigation/search)** — zmienia się definicja search button i layout docka (4-tab → 5-tab: Home, Planer, Spiżarnia, Zakupy + search button jako sibling, bez taba Przepisy). +- **Phase 5 (Recipe catalog)** — ekran katalogu nie ma własnego taba; wejście wyłącznie przez search button. Pozostała funkcjonalność (lista, kategorie, szczegóły, filtry) bez zmian. +- **Phase 10 (UI chrome polish)** — Home prawdopodobnie domyka się tutaj wizualnie. diff --git a/.planning/seeds/home-tab-content.md b/.planning/seeds/home-tab-content.md new file mode 100644 index 0000000..7c6a4d6 --- /dev/null +++ b/.planning/seeds/home-tab-content.md @@ -0,0 +1,36 @@ +--- +title: Scope widgetów tab Home +trigger_condition: Przed rozpoczęciem Phase 10 (UI chrome polish) lub gdy Phase 2.1 (app shell/navigation/search) wchodzi w fazę projektowania ekranów +planted_date: 2026-05-16 +--- + +# Scope widgetów tab Home + +## Kontekst + +Decyzja kierunkowa (patrz `notes/nav-search-as-catalog.md`): dodajemy tab Home przed Planerem. Charakter: landing z podpowiedziami i podsumowaniami — *coś musi mówić użytkownikowi*, nie być pustym powitaniem. + +## Otwarte pytanie + +Co konkretnie pokazujemy na Home, żeby: +- nie dublować funkcji Planera/Spiżarni/Zakupów, +- być realną wartością przy pierwszym otwarciu appki rano, +- nie spuchnąć do nieczytelnego dashboardu z 8 sekcjami. + +## Kandydaci do rozważenia + +- **"Co jemy dziś / jutro"** — wycinek planera w formie karty; tap → Planer otwarty na danym dniu. +- **"Czego brakuje do najbliższych posiłków"** — shortcut do brakujących składników; tap → Zakupy / Spiżarnia. +- **"Propozycje przepisów"** — sugestie oparte na: ostatnio dodane, sezonowe, "na podstawie tego co masz w lodówce" (przyszła funkcja). +- **"Szybkie akcje"** — m.in. potencjalne miejsce na "+Dodaj przepis". +- **Powitanie / pasywny landing** — odrzucone we wstępnej dyskusji (Home ma podpowiadać). + +## Pytania pomocnicze do rozstrzygnięcia później + +- Czy Home jest *statyczny* (zawsze te same sekcje), czy *adaptacyjny* (sekcje pojawiają się zależnie od stanu — np. "brakuje produktów" tylko gdy faktycznie brakuje)? +- Czy Home wystarczy na MVP w minimalnej formie (1-2 sekcje), czy czekamy z nim do momentu, gdy mamy więcej funkcji do podsumowania? +- Czy Home jest też miejscem na onboarding (przy pierwszym uruchomieniu)? + +## Rekomendowana ścieżka + +`/gsd-sketch` na początku Phase 2.1 lub Phase 10 — Home to wyraźny przypadek "what should this look like / feel" z wieloma stanami do wyklikania w HTML. diff --git a/.planning/todos/pending/decide-add-recipe-placement.md b/.planning/todos/pending/decide-add-recipe-placement.md new file mode 100644 index 0000000..003fc33 --- /dev/null +++ b/.planning/todos/pending/decide-add-recipe-placement.md @@ -0,0 +1,29 @@ +--- +title: Zdecyduj gdzie ląduje akcja "+Dodaj przepis" +date: 2026-05-16 +priority: medium +blocks: Phase 5 (Recipe catalog) +--- + +# Zdecyduj gdzie ląduje akcja "+Dodaj przepis" + +## Kontekst + +Po decyzji o usunięciu taba Przepisy (patrz `notes/nav-search-as-catalog.md`) nie ma już oczywistego miejsca na akcję dodawania przepisu. Dodawanie ma być raczej *dodatkiem*, nie codzienną interakcją — może być dwa-tapy głębiej. + +## Kandydaci + +- **Home** — naturalne miejsce na "szybkie akcje"; wymaga że Home już istnieje i ma miejsce na taki shortcut. +- **Toolbar app shell** — globalny "+" obok search button; zawsze pod ręką, ale konkuruje o przestrzeń z search i ewentualnymi przyszłymi przyciskami. +- **Ekran katalogu (otwierany przez search)** — semantycznie sensowne (jest o przepisach), ale dziwne że użytkownik musi przejść przez search żeby coś dodać. +- **Ustawienia** — najbardziej ukryte; OK jeśli dodawanie jest skrajnie rzadkie. + +## Kryteria decyzyjne + +- Częstotliwość użycia (im rzadsze, tym głębiej można schować). +- Czy "+Dodaj przepis" to akcja związana z *katalogiem* (sensowne w toolbarze katalogu) czy *zarządzaniem treścią* (sensowne w ustawieniach / Home jako command center). +- Spójność z innymi akcjami tworzenia, które mogą dojść w v2 (np. dodawanie produktu do spiżarni — gdzie ona ląduje?). + +## Termin + +Rozstrzygnąć przed `/gsd-plan-phase 5` (Recipe catalog). Można też w `/gsd-discuss-phase 2.1` jeśli decyzja wpływa na layout app shell.