Navstevnost podla typu zariadenia:
1 Like
Co je celkom jasny procesny problem, zatial to teda stale bezi v “docasnom rezime”. Jedna stranka takto vie bezat, ale staci aby pribudli dalsie a zmenite sa de facto na redakciu. To su tie nestastne “side effects”.
Zdravim,
chcel by som vas poprosit o konzultaciu. Na zaklade feedbacku uzivatelov sme sa rozhodli zapracovat novu funkcionalitu - zobrazenie opatreni na nasledujuci tyzden (aby ludia vedeli co ich caka v pripade zmeny stupna).
Samozrejme to chceme urobit v sulade s ID-SK. Tu vsak narazame na problem - semanticky by na toto boli najvhodnejsie taby - vo finale to ilustruje aj priklad pouzitia z gov.uk (ID-SK Frontend). To, ze taby v SK verzii ID-SK nemame asi riesit nebudem (minimalne vo figma kniznici nie a ani medzi webovymi komponentami). Ak by sme to teda pouzili ako kaze gov.uk vyzeralo by to nasledovne:
Odkaz Buduci tyzden by bol ako kotva v ramci stranky a smeroval by na nadpis buduci tyzden pod celym zoznamom opatreni. Pride vam to ako spravne riesnie? Mate pripadne nejake napady ako to zapracovat inak v sulade s ID-SK?
Len pripomeniem:
- viac ako 80% navstevnosti je z mobilnych zariadeni
- je to koncipovane ako progressive web aplikacia - primarne urcenie mobil (moznost nainstalovat si na plochu)
- cielom aplikacie je co najrychlejsie ponuknut uzivatelom prehlad aktualne platnych opatreni … predpokladame zvysovanie opakovanych navstev
Vopred dakujem za kazdy napad a konstruktivny pristup!
M.
Neuvazovali ste to ukazovat priamo v tych boxoch? Predpokladam, ze sa to tak zufalo casto nemeni a ja by som napriklad chcel vidiet, ze ako su skoly dnes a ako sa to zmeni o tyzden. Skor by som to ocakaval tak, ako sa preklikavat medzi tabmi a porovnaval si to. Pre ludi je dolezite vidiet asi skor ci sa nieco meni a ako.
Cize za mna
- ak sa to nemeni, napisat do boxu napr. rusko (od 23.3. bez zmeny)
- ak sa to meni, napisat do boxu napr.rusko (od 23.3. platia nove pravidla, v klude cez preklik nech sa to rozbali az potom)
Proti rieseniu nic nemam.
Nechcem byt sprosty, ale… to tlacidlo “hore” je z akeho dizajnmanualu?
A este citatelnosti by pomohlo imho, aby tie karticky neboli full width, ale pouzil sa aspon 2/3 stlpcovy dizajn.
Mrkni na vzor navigacie na stranke: ID-SK Frontend - Ukážka webových komponentov a scroll uplne dole
Pripomeniem, ze 80% navstevnosti je z mobilu … je teda takto ok aj mobilna verzia(viz. prvy prispevok)?
- nebude to pre uzivatelov zmatok ked budu opatrenia pre aktualny aj buduci tyzden pod sebou v jednom nekonecnom stlpci rozdelene len nadpisom?
- ako sa uzivatel dostane naspat k aktualnemu tyzdnu? to bude scrollovat kym neprebehne vsetky opatrenia?
- nie je problem, ze v podstate na prvy pohlad nevidi vo viewporte nic uzitocne? resp. ziadne opatrenia - podstata aplikacie. A pri kazdom otvoreni aplikacie musim scrollovat aby som nieco videl?
Opatrenia sa menia vzdy od pondelka, podla toho ako sa meni hodnota covid automatu pre okres (moze kludne kazdy tyzden). Oznamuju to v utorok ako sa zmeni situacia na dalsi tyzden. Uvazovali sme nad roznymi variantami:
- taby
- davat priznak ku kazdemu opatreniu
- zobrazit len upozornenie, ze od buduceho tyzdna sa meni situacia a urobit tam odkaz
toto nam prislo najjasnejsie - idealne sme cheli do tabu davat aj info o stupni, datum, … Aby ti bolo hned jasne, ze sa nieco zmeni. Chcelo by to samozrejme odtestovat co by bolo najlepsie. Z feedbacku sme usudili, ze toto.
jejda, to je jeden z tych vymyslov co ste si tam bez otestovania v poslednej dobe dorobili? 
Ano, ved tie columny pod seba padaju v zavislosti od sirky zobrazenia… Lebo presne na taketo veci mysleli v gov.uk, konkretne:
@media (min-width: 40.0625em)
.govuk-grid-column-two-thirds {
width: 66.6666%;
float: left;
}
(skopcil som len z browsera, nechcelo sa mi to hladat)
My sme si toto nevymysleli. Toto s nami nema nic spolocne (minimalne po stranke designu). Neviem kto je za toto zodpovedny, ale predpokladam, ze toto na “ma rovasi” BRISK.
Teraz asi nerozumiem - 2/3 layout v pripade mobilu znamena, ze pri rozliseni 320 px vezmeme cez 100 px z moznej sirky + paddingy v boxikoch a skoncime s priestorom pre obsah tak 150 px. Asi si v tomto nerozumieme. V mobile dava podla mna uplne vyznam mat obsah na celu sirku.
Vyhodou dizajnmanualu je, ze nad takymito vecami sa nemusis zamyslat, lebo sa nad tym zamyslel uz niekto predtym…
Desktop
Mobil
Asi sa fakt nerozumieme … ja dobre viem naco je design manual. Riesime toto zobrazenie na mobile a implementaciu tabov:
To, ze budu boxiky na desktope v 2/3 layoute je ok … stale to bude zobrazenie pre 20% uzivatelov. To co som komentoval sa vsak tyka mobilu. Tak este raz:
- nebude to pre uzivatelov(mobilov!) zmatok ked budu opatrenia pre aktualny aj buduci tyzden pod sebou v jednom nekonecnom stlpci rozdelene len nadpisom?
- ako sa uzivatel dostane naspat k aktualnemu tyzdnu potom co klikne na odkaz buduci tyzden? to bude scrollovat kym neprebehne vsetky opatrenia a dostane sa na uvod stranky?
- nie je problem, ze v podstate na prvy pohlad nevidi vo viewporte nic uzitocne? resp. ziadne opatrenia - podstata aplikacie. A pri kazdom otvoreni aplikacie musim scrollovat aby som nieco videl?
Je toto z pohladu pouzitelnosti ok? Nie je to proti best practices, ktore maju uzivatelia pri pouzivani mobilov? …
Prepac, nerozumeli sme si.
Podla mojho nazoru kladies spravne otazky a mal by si ich otestovat - urobit prototyp, ktory zjavne mas, a najst si zopar respondentov - nemyslim si, ze tu najdes tych najlepsich respondentov 
Tam je problem, ze pokial okres prejde do ineho stupna menia sa podmienky v takmer vsetkych opatreniach. Podla Covid Automatu. Ono sa to viac prejavi az ked sa zacnu opatrenia uvolnovat. Takze toto by bolo skoro pri kazdej polozke. Co pokladam za dost neprehladne.
Suhlas! A teraz otazka. Ked zistim, ze moje hypotezy su spravne, co robit? Je to problem zleho navrhu komponenty, nevhodneho pouzitia komponenty alebo coho? A co s tym robit?
Podla toho co tu uz bolo napisane, boli tieto komponenty testovane a vyvijane kopou odbornikov v UK. Predpokladam teda, ze su navrhnute spravne. Takze usudzujem, ze testovat ich znovu nema zmysel. Takze zle pouzitie? Ale podla toho prikladu pouzitia na webe id-sk, je to presne o tom.
Ako to teda riesit?
Komponenty testovat nemusis, to ako si napisal uz urobili (zvacsa, ak neratame tie “nase”) v gov.uk. Ale to neznamena, ze pouzitie komponentov a aj kontext je vzdy implicitne spravny.
“Najlacnejsie” (effortovo) bude supnut to nejakej vzorke obyvatelstva, na ktoru to cielis (zrejme asi roznorodej zmeske obyvatelstva) a zavolat si s nimi a ziskat feedback. Taka dnesna alternativa ku guerilla testing. A ked sa to neda, tak nasadit nejake nastroje (napr. HotJar) a ziskat feedback aspon po nasadeni.
Sposoby ako to odtestovat su mi jasne. Ide skor o to, co s tym budem moct robit ked mam v ID-SK jasne definovane ako maju vyzerat taby. A ja zistim, ze to ludia nebudu vediet pouzivat.
Som presvedceny, ze pre tento konkretny case mam niekolko ovela lepsich sposobov ako to urobit. Napr. by uplne stacilo dat tie taby vedla seba - clovek by sa jednoducho vedel prepinat medzi aktualnym a buducim tyzdnom. Best practice z material.io (Tabs – Material Design 3) - mimochodom design system, ktory pouziva asi trocha viac ludi a designerov ako gov.uk. Ale! Mame ID-SK v ktorom takto taby nie su navrhnute. A nasim cielom je pouzivat komponenty, ktore su odtestovane a nevymyslat si nove. Co teda?
Nezasluzi si ID-SK trochu oprasit? Minimalne sa zacat zamyslat aj nad inymi pripadmi pouzitia ako jednoduchy informacny web a formular? Zjavne to uplne nevyhovuje ani BRISKu, ked si tam vymyslaju taketo veci - ID-SK Frontend - Hlavička s úvodným blokom . Len skoda, ze sa neporadia.
No a to je to, co sa mi zda, ze sa nezvladlo hned na zaciatku. Bolo podla mna nevyhnutne zadefinovat proces navrhovania, predkladania a akceptacie zmien. Dobre by bolo sa v tomto inspirovat postupom v gov.uk ked to nemame zadefinovane u nas:
Propose a component or pattern – GOV.UK Design System
Develop a component or pattern – GOV.UK Design System
Contribution criteria – GOV.UK Design System
Cize za mna by mali byt zmeny vitane a podporovane, ale pri dodrzani postupov a pravidiel.
1 Like
Tu je este rychly navrh riesenia nie uplne respektujuci ID-SK teda gov.uk. Z mojho pohladu o dost pouzitelnejsie ako povodny navrh. Myslim, ze uplne zbytocne testovat.
A budem uprimny - v tomto pripade uprednostnime uzivatela pred ID-SK. Myslim, ze pointa je vsak jasna.
Z govuk vyberam: Tabs – GOV.UK Design System
Do not use tabs if your users might need to:
- read through all of the content in order, for example, to understand a step-by-step process
- compare information in different tabs - having to memorise the information and switch backwards and forwards can be frustrating and difficult
Test your content without tabs first. Consider if it’s better to:
- simplify and reduce the amount of content
- split the content across multiple pages
- keep the content on a single page, separated by headings
- use a table of contents to let users navigate quickly to specific sections of content
Si si uplne isty, ze ten scenar nie je prave toto?
- compare information in different tabs - having to memorise the information and switch backwards and forwards can be frustrating and difficult
Po tisici krat: Je uplne ziaduce (!), aby sa na specialne pripady vyrabali vlastne komponenty, je vsak potrebne ich poriadne otestovat a urcite ich len tak halabala netahat na centralu IDSK bez testovania.
Pre predstavu: Tabs · Issue #100 · alphagov/govuk-design-system-backlog · GitHub
Iny department robi taby takto: http://rural-payments-styleguide.herokuapp.com/tabs/ (podla mna dost matuce)
Dalsi https://reform-pattern-library.herokuapp.com/components/tabs#before-you-start
- Use tabs only when users don’t need to see content from multiple tabs simultaneously. If people do need to compare the info behind different tabs, then having to switch back and forth puts an added burden on their short-term memory, increases cognitive load and interaction cost, and lowers usability compared to a design that puts everything on one big page.