37 lines
1.9 KiB
Markdown
37 lines
1.9 KiB
Markdown
---
|
|
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.
|