23 komentáře “UX – také terorizujete své uživatele přesnými formáty vstupních polí?

  1. Prima clanek, ale tak nejak se spoustou veci nesouhlasim:

    Zmenit 2011 na 1.1.2011 mi prijde nepouzitelny: Bud uzivatel presnejsi datum nevi nebo nechce zadat a pak je to problem. Nebo staci rok a pak je mozna chyba ptat se na vic. Nebo opravdu myslel den po silvestru ale to ma pravdepodobnost jiste mensi nez 1:356, to uz spis myslel 20.11. U casu mi to naopak prijde v pohode, 17 je proste 17:00:00.000, protoze tak se casy stanovuji (schuzky bezne zacinaji v 5 a ne v 5:09:13) a casto vetsi presnost potreba neni.

    Princip „uzivateli se do dat nesaha“ se mi libi, ale mam pocit ze se ho nedrzis. Sice mu nezmenis to co napsal ale zpracuje se neco jineho, coz bych s velkou nadsazkou oznacil jako „uzivateli se do dat saha tak aby to nevidel“. Ono se to sice ukaze hned vedle, ale on to nejpis nikdo necte, zvlaste kdyz je to zelene. Pokud jde o vyhledavaci formular nebo treba kalendar tak je to celkem jedno, pokud jde o neco kde spatne zadany datum muze byt velky prusvih, tak bych tak tolerantni radeji nebyl.

    Vzhledem k tomu jaky je v tech datumech (spravny ale matouci tvar „datech“ nepouzivam umyslne) gulas, tak asi univerzalni reseni neexistuje. Locale resi vetsinu uzivatelu ale co kdyz nekdo ma vsecko anglicky a pouziva cesky datum (jako treba ja)? Vzdy se nekdo takovy najde, proto jsou heuristiky potreba, ale zadna spolehliva neexistuje. Mozna bych jich zkusil nekolik a v pripade ze vysledek neni jednoznacny, tak bych uzivatele terorizoval aby si z nich explicitne vybral. Tu heuristiku co ho vyprodukovala bych pak pouzil na vsechny datumy toho uzivatele. Taky to nejspis ma svoje mouchy.

  2. Setkání nad pivem se vůbec nevyhýbám 😉 … to bývají jedny z nejlepších diskusí. Lidi tam na sebe mají víc času a s druhým pivem se nestydí říct názory, které si jinak nechávají pro sebe 😉 . Jen ten JOS je krapet daleko. Třeba se ale příležitost naskytne.

    Dík za konkrétnější info o tom cílovém použití. Myslím, že to jak to funguje jsem z popisu docela dobře vyrozumněl. Musím přiznat, že mě hodně ovlivnil zmiňovaný článek: http://www.alistapart.com/articles/inline-validation-in-web-forms/

    Tam v kapitole Testing when to show inline validation
 je hezky popsané, jaké měli zkušenosti s inline validacemi BEFORE, WHILE a AFTER. S tím, že standardně jim vyšlo jako uživatelsky nejpřívětivější používat AFTER (tolik nedrobí pozornost) a na některá vyjímečná pole, kde se předpokládá vysoká chybovost (např. zadání unikátního uživatelského jména) WHILE validace.

  3. Jooo. a k tomu onchange. Asi bych mohl udelat kus videa, ale jsem na to levej.. Takze zkusim popsat. Dulezite je ze veskerou validaci mame jako podbarveni background-color na textboxu. Takze uzivatel otevre formular por zadavani (v nasem pride wizard) a vidi treba 10 poli, pricemz 3 jsou nutne vyplnit a 2 jsou doporucene, zbytek nepovinny. Takze vidi 3 policka red-backgound, 2 yellow-background a zbytek bile (je to trosku jinak barevne, ale pro priklad staci). Na wizardu talcitko finish/ulozit/upravit/smazat (podle situace) je enabled=false. Uzivatel zacne typovat red-background a v urcitem okamziku (onChange) mu pole zbela. Kdyz to udela uz vsech cervenych, tak se wizard button finish prepne do enabled=true a uzivatel tak muze pokracovat. Cela situace je slozitejsi o to ze wizard muze (a casto je) nekolika krokovy a tak si preved vyse popsane na button „next“ kdy az kdyz vsechny stranky wizardu porhlasi ze je vse ok, povoluje se zmineny finish. Pak nasleduji kontroly, ktere nelze delat na onChange a uzivatel to vnima jako dalsi stranku wizardu. No spatne se to popisuje….

  4. Ten zmineny princip „uzivateli se do dat nesaha“ je mi blizky. Taktez ho vsemozne obhajuju a snazim se aby nas software nebyl chytrejsi nez inspektor Trachta. Casto se mi to nedari. Nekdy uplne rezignuju. Nekdy bojuju o kompromis. Velmi vyjimecne uplne vyhraju. Ale k veci. To co delame je pouzivano uzkou skupinou lidi. Jde v podstate o vnitropodnikovy system, bezici jako tenky klient. Takze v podstate si sve uzivatele skolime na to jak to maji pouzivat. Jde o HRMS, kdy je nas soft pouzivan k vykonavani outsourcingu pro ruzne firmy. Takze pro tebe asi ne moc berna mince.
    UI je postavene na Eclipse RAP a tak se to podoba desktopove aplikaci a zaroven si na javascript vubec nesahnem (zaplatpanbuh). Eclipse RAP je slusnej nastroj, ale i tak par veci delame po svem. Preklady, validace, formularove prvky, dataProvidery, sbernice. No kdyz to tak po sobe ctu 🙂 tak v podstate z RAPu potrebujem jen vyhodnoceni delty pro odeslani na klienta (klient qooxdoo), plus eventy, plus theme, plus wrap nad EclipseRCP (hlavne JFace). Je to slozity povidani… ja mam na starosti prave UI vrstvu (jeden na OSGi) a obcas je to i docela zabava. Nekdy bysme meli dat rec nad pivem… uz jsme se potkali na JOS (prvni rocnik), ale tam jsem byl v podstate jen diky Dagimu (zadne prednasky jsem nemel, jen jsem se opajel pocitem, ze jsem mezi elitou) 😉

  5. Zajímavé – tohle už tu trochu výše padlo. My jsme se všude drželi principu: „uživateli se do dat nesahá“. Tj. v tom políčku zůstane vždycky vyplněné to, co tam uživatel zapsal – jím vložené hodnoty nikdy nepřepisujeme. Tu naši zkonvertovanou / domyšlenou hodnotu zobrazíme read-only napravo nebo pod tím vstupním políčkem taky na onblur.

    V tom odkazovaném dokumentu trochu varovali před onchange reakcí formuláře – vyžaduje to od uživatele větší soustředění na to, co se vyplňuje, než když analýza probíhá až na onblur. Což byla pro mě taky velmi zajímavá a nová informace.

    Btw. ta grafika ve videu je velmi jednoduchá – jedná se jen o nějaký náš prototyp. Na zákaznických projektech budou ty hlášky graficky i pocitově doladěnější.

    Dík za komentář.

  6. V nasem softu (webova app) mame zdavani datumu nasledovne: podle zvoleneho jazyka se voli maska pro zobrazeni datumu v ramci cele aplikace. Napriklad CZ: DD.MM.YYYY EN: YYYY-MM-DD . Takhle to uzivatel vidi vsude v tabulkach i na formularich a tedy nam to i tak zada. Problem nastal, kdyz prisel pozadavek od uzivatelu: „ale my nechceme psat tecky (nebo pomlcky), to nas zdrzuje“. Takze validni vstup je i CZ: DDMMYYYY EN: YYYYMMDD a jako bonus i CZ:DDMMYY a EN: YYMMDD pricemz pokud je YY <= abs(2000 – current_year) tak je pricteno 2000 jinak 1900. Na lost_focus na poli dojde k rozepsani datumu na puvodni CZ: DD.MM.YYYY (nebo EN..) a tak uzivatel vidi jestli zadal spravne. Validace mame na on_change a podbarvujeme background textoveho pole + tooltip s error message. Takze po napsani 010202 zmeni policko barvu z cervene (v pripade ze bylo required) na bilou a uzivatel vidi ze uz je validni vstup. Po opusteni policka se hodnota prepise na 01.02.2002 (CZ). Tot vse.

    • Ještě bych se rád zeptal, co za aplikaci to (NkD) vyvíjíte? Je to něco bližšího nějakému IS s úzkým okruhem uživatelů, kteří ji používají velmi často a tak preferují zkratky. Nebo nějaká aplikace otevřená na internet, kde není jisté, co za člověka přijde?

      Jak uživatelé reagují na ten onchange? Dokázal bys třeba potvrdit nebo vyvrátit ty teze z odkazovaného článku? Dík

  7. technicka diskuze je zajimava.
    ale mam z toho dojem, ze uzivatele blbnout kdyz neumi zadat datum a programatori
    musi byt zas o to chytrejsi.
    my mame v nasem softu funkci, ze staci zadat cislo dne, treba 23 a dohleda se blizsi
    datum vpred ci vzad, 23.10. nebo 23.9.

  8. Z pohledu aplikace mi to nelogické nepřijde. Asi je to osobní pocit, ale pokud po uživateli chci „dva údaje“ a on vyplní jenom jeden, je to špatně.

    Opravdu hlavní a vynikající přínos je ukládání dat do databáze v konzistentním formátu, aniž bychom uživatele otravovali využívat přesných konvencí.

    To doplňování data a času, které mi tak vadí, je vhodné případně pro nějaké interní systémy, kde jsou uživatelé s touto „akcí“ seznámeni a (hlavně) denně v kontaktu.

  9. Ahoj Honzo, diskusi si pamatuji a vím co ti vadí. U toho roku je to hodně markantní – tu heuristiku můžeme samozřejmě ještě potunit. Nicméně obdobný příklad je třeba čas – požadován je formát H:mm a když zadáš jen jediné číslo vezme se jako hodina a minuty se doplní jako 00. Tohle ti taky přijde nelogické?

    Navíc, když vezmeš v úvahu druhý faktor téhle funkcionality a to je urychlení práce v případech často vyplňovaných formulářů?

  10. Honzo, jak už jsem říkal, tak dobrá myšlenka. Stačí to opravdu dotáhnou co se týče upozornění (lepší možná uživatele neupozornit a datum uložit v „opraveném formátu“.

    Co mi pořád přece jenom vadí je, že když po uživateli chceme kompletní datum (den, měsíc a rok) a uživatel zadá jenom rok, validátor za něj navrhne například 1. 1. téhož roku. To mi přijde jako zvěrstvo. Pokud je uživatel takový retard, nemá právo projít formulářem dál a opravdu ten den a měsíc musí zadat.

  11. em: Škoda, že jste ten komentář nenapsal už včera 🙂 20092011 by byla krásná ukázka nejednoznačnosti formátu data bez oddělovačů.

  12. Myslím, že nejlepší ulehčení pro datum je umožnit vynechat tečky, ale pak vyžadovat nulu u měsíce. Já osobně pro sebe používám datum RRRR-MM-DD nebo RRRRMMDD_HHMM

  13. Předem díky za všechny komentáře, protože obsahují to, co jsem si představoval – jiný pohled na věc.

    Ad Petr) díky za upozornění na formáty datumu na blogu – zabíralo nějaké defaultní nastavení WordPressu, který pro blog používám, a tak byly pro nás evropany skutečně divné … opraveno

    U toho jednoznačného tvaru se skutečně nápověda nezobrazuje – ono by to bylo trochu dvousečné – tyhle živé poznámky napravo chceme používat spíš jen „výjimečně“, tj. ve chvílích kdy není něco úplně standardní. Kdybychom to začali používat příliš často, myslím, že bychom docílili jen toho, že by to uživatel začal ignorovat.

    Ad Filip) Souhlas … dobrá inspirace.

  14. Souhlasím s tím, že poznámka by u políčka měla zůstat – spousta uživatelů bude stejně o formátu přemýšlet dopředu, protože neví, že tam máte nějakou heuristiku. Pro ně pak není vhodná ani poznámka „zvolte formát, jaký chcete“, protože pak stejně budou muset vybírat, jaký asi tak bude vhodný. Takže je lepší rovnou nějaký vhodný formát doporučit. Doporučený formát bych pak nepopisoval maskou (d.m.rrrr), kterou uživatel musí dekódovat, ale příkladem (ze kterého bude zřejmé, co je den, měsíc, rok). Do třetice – dlouhou celovětou poznámku bych si ponechal pro případ, kdy je potřeba něco podrobně vysvětlit (např. cizinci místo rodného čísla zadají datum narození, sériové číslo výrobku najdete … atd.) Formát data bych uvedl jen stručně jako příklad, takže vedle políčka pro datum bude jen „např. 31.12.2011“ nebo „např. 31.12.2011, +0 (dnes), +1 (zítra)“ (vysvětlení v závorce samozřejmě nějak méně výrazně). Kdo chce poradit jeden univerzální formát, měl by ho najít na prvním místě, pokročilí se můžou naučit vychytávky z dalších příkladů.

  15. Nepřečetl jste si závorku.. Já narážím na „09.21.2011 v 5:31“ zde v komentářích. Pokud to někdo dokáže takhle „spáchat“ na cz webu, pak nemám vůbec jistotu, jestli „použije se 5.6.2011“ znamená 5. června nebo 6. května a vlastně v kontextu toho webu ani nevím, co bych měl zadat já. Samozřejmě „použije se 6. květen 2011“ by to řešilo, pokud bych si toho všiml a pokud by se to tam vůbec objevilo, protože když zadám hodnotu celou a program si myslí, že to je jednoznačné, nápověda není.

  16. Z čeho vyvozujete, že jako první číslo oddělené tečkami máme měsíc? V příkladech používám formát český (tj. evropský) – kdy jako první číslo je vždy den. Nevím, jestli zmatení nemohlo způsobit to, jak jsem ve videu zadával datum 2010-05-06, ale pak se aplikuje opět evropský styl data yyyy-mm-dd.

    Pokud bych jako primární formát data nadefinoval d.MMMM yyyy, tak by se potom v nápovědě zobrazovaly texty jako:

    Použije se „6. květen 2010“

    A to je v podstatě už bez diskuse.
    Vy ale jistě narážíte na to, že 5/6 a 6/5 jsou v podstatě nejednoznačně zadaná data. Máte pravdu, ale aktuálně je preferován evropský styl, kdy den předchází měsíci. Tj. aplikačně to jednoznačné je – uživatel pak vidí výsledné plné datum v té nápovědě napravo, takže z toho by měl usoudit, jestli dostává, to co chtěl.

  17. U zadávání data je nejhorší, když někdo (jako třeba zde v komentářích) otočí měsíc a den. Pokud je den nad 12, tak se to uhodne, ale 5.6. a 6.5. je problém. Pak je mi na 2 věci i vaše nápověda „použije se …“ protože by mě nikdy nenapadlo, že datum oddělené tečkami v ČR bude mít na prvním místě měsíc, jako to máte zde.

  18. A není lepší nedat uživateli šanci zadat datum blbě?
    Např:
    3 selecty (den, měsíc, rok) Zadávat se dá z klávesnice a oproti textovému vstupu stačí místo tečky (a po tečce by správně měla následovat i mezera) zmáčknout tabulátor.

    PS: Datum bez data ( http://www.pravidla.cz/hledej.php?qr=datum )

    • Osobně si myslím, že selecty nejsou ideální z několika důvodů:

      – v případě plného data s časem se uživatel uselectuje (jestli počítám správně je to 6 selectů)
      – v selectech obtížně zajistíte nemožnost zadání např. 30.2.2011 – takto uživatel stejně chybu dokáže vyrobit
      – některé selecty budou obsahovat velké množství položek (roky třeba)
      – špatně se kombinují s existujícími JS date pickery

  19. Jen chci podpořit Koudiho – předělávali jsme nějaké formuláře, které se jevili jako problematické. Nově bral systém téměř všechny myslitelné formáty, tj. nenapsala se k nim nápověda. První, na čem uživatelé již při testech „zatuhávali“ bylo, že nevěděli, jak to zapsat…

  20. „Respektive ideálně se úplně zbavit komentáře u daného pole formuláře ve smyslu: „vložte datum ve formátu XY““

    Tady bych si dovolil lehce nesouhlasit. Spousta lidi uz je zvykla, ze datum jsou problematicky a (bohuzel) je potreba je zadavat v danem formatu. Bez popisku tak budou muset premyslet, jak to asi autor pozaduje, protoze nevi, ze na tom nezalezi. Proto by tam podle me nejaky popisek byt mel – bud ukazky prijatelnych formatu nebo klidne neco jako „zadejte jak se vam zlibi“.