Přeskočit na obsah

UX v1 — první praktický audit veřejného webu

Stav dokumentu: Návrh s rozpracováním — UX backlog po rychlém průchodu existující aplikace, dokumentace a hlavních komponent. P0 body 1–3 jsou v kódu provedené (veřejná copy, katalogové filtry + předvolby + chips, rychlý přehled na detailu byliny). Dál platí P1/P2 níže. Nejde o redesign značky; cílem je zlepšit použitelnost, důvěru a orientaci při zachování současného „soft nature“ vizuálního směru.

Kontext

Projekt už má funkční veřejné moduly: úvod, katalog bylin, detail byliny, symptomy/témata, sezónu, regiony, zpracování, recepty a rituály. Vizuální jazyk je popsaný v 27-soft-nature-ui.md, inventář komponent v 26-ui-components.md a obsahová pravidla v 30-content-guidelines.md.

Největší UX riziko není nedostatek funkcí, ale to, že rozhraní často ukazuje vnitřní datový model místo běžného mentálního modelu návštěvníka. Katalog /byliny má základ P0 bodu 2 (hledání + tři hlavní filtry, rozšířené ve skupinách, chips, předvolby); hlubší mobilní úpravy (např. samostatný panel „Upravit filtry“) zůstávají v P2 bodu 9. Vysvětlivky u vědecké vrstvy, sezóna/regiony a některé prázdné stavy dál patří do P1/P2. Inventář copy: odstraneni-technicke-copy-pro-navstevniky.md — hlavní veřejné texty z něj jsou v aplikaci přepsané (katalog, sezóna, regiony, zpracování, meta popisy, 404 u detailů).

Cíl

  • Zkrátit cestu k odpovědi na běžné otázky: „co teď sbírat“, „co pomáhá na téma“, „jak bylinu bezpečně poznat a použít“.
  • Snížit kognitivní zátěž ve filtrech a dlouhých detailech.
  • Jasněji oddělit tradiční inspiraci, vědecké poznatky a bezpečnostní upozornění.
  • Zlepšit mobilní použitelnost bez zásadní změny stacku nebo přidávání UI knihovny.

Mimo scope

  • Nový vizuální brand, nový fontový systém nebo kompletní redesign.
  • Admin/editor rozhraní; to patří do 32-admin.md.
  • Nový doporučovací engine, účty, směsi nebo mapa výskytu; ty mají samostatné tasky.
  • Přepis databázových modelů pouze kvůli UX. Datové změny mají vznikat jen tam, kde je bez nich UX neproveditelné.

P0 — rychlé úpravy s velkým dopadem

1. Veřejné texty bez interního žargonu

Stav: Hotovo v produktovém UI (kód v app/components/*, vybrané app/lib/* meta, 404 hlášky u detailů). Stránka /dokumentace záměrně zůstává projektová a patičkový odkaz na ni je v pořádku. (Veřejná routa /roadmap byla zrušena — obsah žije už jen jako docs/11-roadmap.md a docs/24-engineering-roadmap.md pod /cs/dokumentace/:slug.)

Problém (původní): Na více veřejných stránkách se objevovaly formulace typu „v datech“, názvy tabulek, sloupců, query parametrů nebo technické cesty. To oslabovalo důvěru běžného návštěvníka a dělalo z webu spíš náhled databáze než průvodce.

Návrh:

  • Dokončit průchod podle odstraneni-technicke-copy-pro-navstevniky.md. Provedeno v rozsahu veřejných modulů; tabulka v tom souboru může sloužit k druhému auditu (grep / ruční kontrola).
  • Zakázat v běžném veřejném UI názvy DB tabulek/sloupců, slug, query parametry jako primární popisek odkazu a odkazy na interní dokumentaci.
  • Zachovat technický jazyk jen na /dokumentace (resp. v jednotlivých dokumentech /cs/dokumentace/:slug) nebo v interních docs.

Akceptace:

  • Na hlavních veřejných stránkách návštěvník nevidí D1, názvy tabulek/sloupců, slug, query, docs/, npm run ani monospace parametry jako vysvětlení funkce.
  • Odkazy typu „/byliny“ jsou přepsané na lidské texty typu „Otevřít katalog bylin“.

Poznámka k údržbě: Při nových komponentách držet stejný standard; technické názvy patří do komentářů v kódu nebo do app/db/, ne do nápověd pro návštěvníka.

2. Katalogové filtry rozdělit podle úkolu uživatele

Stav: Hotovo v základním rozsahu P0. Hlavní část: app/components/catalog-filter-form.tsx (hledání + měsíc/část/region, rozšířené filtry ve details ve skupinách), app/components/catalog/catalog-byliny-page.tsx (pořadí na mobilu: výsledky a chips před dlouhým formulářem), app/components/catalog/catalog-active-filter-chips.tsx, app/lib/catalog-filter-url.ts. Předvolby z návrhu: catalogDocPresetChips() + CATALOG_EXTRA_QUICK_CHIPS v app/lib/catalog-page-helpers.ts, úvod katalogu app/components/catalog-intro.tsx, měsíc předvolby z loaderu catalogQuickMonth v app/routes/byliny.tsx. Předvolba bezpečnosti „výraznější upozornění“: query safetyRisk=elevated (OR několika stupňů) — parser app/lib/catalog-byliny-search-params.ts, SQL app/db/herb-catalog-filter-ids-query.server.ts, konstanta app/lib/catalog-safety-risk-preset.ts.

Problém: CatalogFilterForm je jeden dlouhý formulář se všemi dimenzemi najednou. Pro pokročilého uživatele je silný, ale pro první návštěvu působí jako editor dat: část rostliny, téma, typ vazby, evidence, typ studie, bezpečnost, spirituální facety.

Návrh:

  • Nechat nahoře jednoduché hledání + 3 nejčastější filtry: měsíc sběru, část rostliny, region.
  • Další filtry seskupit do rozbalitelných skupin:
    • „Použití a témata“: téma, typ vazby, tradiční/spirituální.
    • „Věda a bezpečnost“: evidence, typ studie, bezpečnostní stupeň.
    • „Zpracování“: způsoby přípravy.
  • Nad výsledky zobrazit aktivní filtry jako odebíratelné chips s čitelným názvem.
  • Přidat krátké předvolby: „Sbírat tento měsíc“, „Vhodné na čaj“, „S výrazným bezpečnostním upozorněním“, „S vědeckými zdroji“.

Akceptace:

  • Na mobilu je první obrazovka katalogu primárně hledání + výsledky, ne celý dlouhý formulář.
  • Uživatel vidí, které filtry jsou aktivní, a může odebrat jeden filtr bez resetu celého formuláře.
  • Pokročilé filtry zůstávají dostupné bez změny URL parametrů (stávající query parametry; doplněn volitelný safetyRisk u předvolby bezpečnosti).

3. Detail byliny začít akčním shrnutím

Stav: Hotovo v rozsahu P0. Komponenta app/components/herb-detail/quick-overview.tsx (shrnutí + kotvy), sekce s kotvami přes volitelné id na Section v app/components/herb-detail-section.tsx, logika zvýraznění bezpečnosti app/lib/herb-detail-safety-prominence.ts + test. Legenda stupňů v hero je sekundární: rozbalitelné details v app/components/herb-detail/hero.tsx. Složení stránky: app/components/herb-detail/herb-detail-page.tsx.

Problém: Detail byliny je obsahově bohatý, ale dlouhý. Důležité informace jako bezpečnost, záměny, sběr a vhodné zpracování jsou rozdělené do více sekcí. U bylin se zdravotním kontextem by měl uživatel rychle pochopit, jestli je karta pro něj bezpečná a relevantní.

Návrh:

  • Pod hero přidat kompaktní „Rychlý přehled“:
    • bezpečnostní stupeň,
    • kdy a co sbírat,
    • nejčastější způsoby zpracování,
    • hlavní témata/symptomy,
    • jestli karta obsahuje vědecké zdroje.
  • U rizikových bylin nebo chybějící bezpečnosti zvýraznit upozornění před inspirativním/tradičním obsahem.
  • Dlouhé sekce ponechat níže jako detail, ale přidat kotvy v horní části: „Určení“, „Sběr“, „Zpracování“, „Věda“, „Bezpečnost“.

Akceptace:

  • Nad prvním dlouhým textovým blokem je vidět praktické shrnutí.
  • Bezpečnostní informace nejdou přehlédnout, zejména pokud existuje záznam s vyšší závažností.
  • Kotvy fungují na mobilu i desktopu a neblokují obsah pod sticky headerem.

P1 — orientace a informační architektura

4. Navigaci zjednodušit podle scénářů

Problém: Hlavní navigace má mnoho rovnocenných položek. Všechny jsou validní moduly, ale bez hierarchie je těžší pochopit, kde začít.

Návrh:

  • Zachovat přímé odkazy na hlavní moduly, ale vizuálně zvýraznit tři primární cesty:
    • „Najít bylinu“ (/byliny),
    • „Co řeším“ (/symptomy),
    • „Co sbírat teď“ (/sezona).
  • Sekundární moduly „Regiony“, „Zpracování“, „Recepty“, „Rituály“ prezentovat jako další cesty v homepage a případně v navigaci s menší vahou.
  • Na homepage přidat skutečný rozcestník podle úkolů, ne jen CTA do katalogu.

Akceptace:

  • První návštěvník má z úvodu jasné 3 možné starty podle záměru.
  • Navigace se na menších šířkách neláme do příliš dlouhého pásu bez zřetelné priority.

5. Výpisové karty doplnit o rozhodovací signály

Problém: Karty v katalogu, symptomech, regionech a zpracování jsou vizuálně konzistentní, ale často nenesou dost signálů pro výběr. Uživatel musí otevírat detail, aby zjistil bezpečnost, důkazní vrstvu nebo praktickou relevanci.

Návrh:

  • U HerbCard doplnit malé štítky:
    • bezpečnostní stupeň,
    • „má vědecké zdroje“,
    • „má recept/postup“,
    • hlavní sbíraná část nebo sezóna, pokud je dostupná.
  • U karet témat zobrazit rozlišení „tradiční“, „vědecké“, „životní styl“ uživatelsky, ne jako datový typ.
  • U zpracování a receptů zvýraznit čas, obtížnost a bezpečnostní omezení, pokud existují.

Akceptace:

  • Výpisy pomáhají porovnat položky bez otevření každé karty.
  • Štítky jsou stručné, nepřebíjejí název byliny a mají konzistentní slovník napříč webem.

6. Prázdné stavy a chybové stavy převést na další krok

Problém: Některé prázdné stavy jen konstatují, že obsah chybí. U filtrů, sezóny nebo detailů by měly nabídnout další smysluplnou akci.

Návrh:

  • U prázdných výsledků katalogu zobrazit:
    • reset všech filtrů,
    • odebrání posledního filtru,
    • odkaz na obecný katalog nebo nejbližší sezónní měsíc.
  • U prázdných sekcí detailu používat neutrální copy: „Tahle část zatím není doplněná“ a nezobrazovat interní návod pro editora.
  • U 404 detailů nabídnout návrat do odpovídajícího rozcestníku a hledání.

Akceptace:

  • Každý prázdný stav má alespoň jednu relevantní akci.
  • Chybové stránky neukazují raw slug jako hlavní sdělení.

P1 — důvěra, bezpečnost a zdravotní kontext

7. Bezpečnost posunout z legendy do rozhodovacího UI

Problém: Karta byliny má bezpečnostní legendu, ale legenda je dlouhá a soutěží s obsahem hero. Bezpečnostní stupeň by měl být rychlý signál, legenda až sekundární pomoc.

Částečný postup (souvislost s P0.3): Legenda stupňů pod hero je už v rozbalitelném bloku (details); rychlý přehled nahoře přenáší bezpečnost do praktického shrnutí. Chybí ještě vizuální badge stupně a případný samostatný odkaz „Jak číst bezpečnost“ dle návrhu níže.

Návrh:

  • Zobrazit bezpečnostní stupeň jako kompaktní badge s barvou a krátkým vysvětlením.
  • Detailní legendu přesunout do rozbalitelného bloku nebo do samostatného „Jak číst bezpečnost“ odkazu.
  • Pokud existují konkrétní bezpečnostní varování, zobrazit krátký souhrn hned nahoře a plný seznam dole.

Akceptace:

  • Uživatel vidí bezpečnostní stav bez čtení celé legendy.
  • Konkrétní varování mají vyšší vizuální prioritu než obecné vysvětlení stupnice.

8. Jasnější oddělení tradice, vědy a inspirace

Problém: Produktová vize správně odděluje tradiční/spirituální a vědecké informace, ale UI může v dlouhé kartě stále působit jako jeden proud autoritativních tvrzení.

Návrh:

  • Používat jednotné vizuální typy bloků:
    • tradice/inspirace: teplý tón, opatrný jazyk,
    • věda: chladnější tón, zdroj a typ studie,
    • bezpečnost: výrazný varovný tón.
  • U vědeckých tvrzení zvýraznit nejdřív „co z toho plyne pro čtenáře“, teprve potom metadata studie.
  • U tradičního obsahu přidat mikrocopy typu „tradiční použití, ne lékařské doporučení“, ale bez opakování v každé kartě, aby se UI nezahltí.

Akceptace:

  • Na první pohled je jasné, jestli blok reprezentuje inspiraci, studii nebo bezpečnostní upozornění.
  • Vědecká metadata jsou dostupná, ale nepůsobí jako hlavní obsah pro laika.

P2 — mobil, přístupnost a výkon

9. Mobilní filtry a dlouhé seznamy

Problém: Katalogové filtry obsahují scrollované boxy s checkboxy. Na mobilu mohou být nepohodlné, zvlášť pokud jsou uvnitř dlouhé stránky.

Návrh:

  • Na mobilu používat „Upravit filtry“ blok s jasným zavřením a souhrnem aktivních filtrů.
  • U dlouhých checkbox skupin přidat interní hledání nebo seskupení.
  • Zachovat nativní formulářové prvky a serverový submit, aby stránka fungovala bez složité klientské logiky.

Akceptace:

  • Uživatel se na mobilu neztratí mezi scrollováním stránky a scrollováním v checkbox boxu.
  • Aktivní filtry jsou viditelné i po návratu z výsledků.

10. Přístupnost interaktivních prvků

Problém: Projekt používá převážně nativní prvky, což je dobrý základ. Další vrstvy jako chips, kotvy, rozbalovací filtry a krokovače ale potřebují konzistentní focus, stav a textové popisky.

Návrh:

  • U všech nových chips a filtrů ověřit focus ring, aria-current nebo jasný text aktivního stavu.
  • U rozbalovacích skupin filtrů používat nativní details/summary nebo plně obsloužené tlačítko se stavem.
  • U výsledkových souhrnů ponechat aria-live, ale nepřehánět počet live regionů.
  • Ověřit klávesovou cestu: skip link → navigace → hledání → filtry → výsledky.

Akceptace:

  • Katalog, detail byliny a rituální krokovač lze projít pouze klávesnicí.
  • Aktivní stav navigace a filtrů není závislý jen na barvě.

11. Vizuální stabilita a obrázky

Problém: Detail byliny už nastavuje rozměry hero obrázku, ale výpisy jsou převážně textové. Jakmile přibudou další média nebo OG fallbacky, je potřeba držet stabilní layout a rychlé načítání.

Návrh:

  • Pokud se obrázky dostanou do karet výpisu, použít pevný aspect ratio a lazy loading.
  • U karet držet jednotnou výšku jen tam, kde to opravdu pomáhá skenování; jinak preferovat přirozenou výšku bez skákání obsahu.
  • Přidat vizuální placeholder jen tam, kde chybějící fotka brání orientaci, ne jako dekoraci navíc.

Akceptace:

  • Při načtení detailu a výpisu nedochází k výrazným posunům layoutu kvůli obrázkům.
  • Obrázky pomáhají identifikaci byliny, nejsou jen atmosférická dekorace.

Doporučené pořadí práce

  1. Dokončit veřejné copy bez technického žargonu — hotovo (viz P0 bod 1).
  2. Zjednodušit katalogové filtry a aktivní chips — hotovo v rozsahu P0 (viz P0 bod 2; hlubší mobilní panel až P2.9).
  3. Přidat rychlý přehled na detail byliny — hotovo (viz P0 bod 3).
  4. Upravit homepage a navigaci podle tří primárních scénářů.
  5. Doplnit rozhodovací štítky do výpisových karet.
  6. Projít mobilní a klávesovou použitelnost na hlavních cestách.

Kontrola po implementaci

  • Ručně projít desktop i mobil:
    • /,
    • /byliny (včetně předvoleb v úvodu a např. ?safetyRisk=elevated),
    • /byliny?q=kopriva,
    • jeden detail byliny s obrázkem, vědou a bezpečností,
    • /symptomy,
    • /sezona,
    • /recepty,
    • /ritualy.
  • Ověřit klávesnici: skip link, hlavní navigace, formuláře, chips, details/summary, rituální krokovač.
  • Zkontrolovat, že nové texty drží zásady z 30-content-guidelines.md.
  • Spustit standardní ověření projektu po kódových změnách: npm run verify (vyžaduje Node z package.json → engines). Při zásahu do katalogových filtrů navíc npm run smoke:byliny-matrix (včetně předvoleb a safetyRisk=elevated).