Add meal plan editor + smaller changes
This commit is contained in:
@@ -1,39 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user