1.9 KiB
1.9 KiB
title, trigger_condition, planted_date
| title | trigger_condition | planted_date |
|---|---|---|
| Scope widgetów tab Home | Przed rozpoczęciem Phase 10 (UI chrome polish) lub gdy Phase 2.1 (app shell/navigation/search) wchodzi w fazę projektowania ekranów | 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.