Zadávání údajů ve formuláři dnes a před lety

[Jan Karasek]

v článku pana Tišnovského (PyWebIO) je ukázána tvorba formulářů ve webu a jak to dělat jednoduše. Existuje ještě milion podobných nástroju, různé frameworky, kde se pracuje se vstupími prvky podobně (a to následovně):
- vstupní prvek je vesměs roztažen přes celou šíři obrazovky, i když je pro zadání potřeba pár milimetrů
- mnohdy se do vstupníhu prvku dá napsat cokoliv a po nějakém submitu je uživatel upozorněn, že tam a tam není údaj správny a po řadě se to  koriguje
- čísla se zadávají zrovna tak jako text zleva (ne tedy jako na kalulačce) podle principu zadej co chceš a zkoriguj to jak umíš
- vstupní prvky např. s desettinou (čárkou) tečkou jsou zarovnány podle levého nebo pravého okraje a ne podle polohy desettiné čárky
- atd ...

Nechtěl bych si jako Sokrates teď stěžovat na mladou generaci a vykládat, jak bylo dříve všechno lepší, ale muím říct, že s podobnými formulářemi a editací by s námi zákazníci před 40 lety vyrazili dveře. Proto jsem docela překvapen, co se dá dnes všechno jako software prodat.

Rád bych se tedy zeptal:

- je nějaká vstřícnější forma editace dnes technicky nemožná? (např. javascript knihovny s vysokou podporou ineraktivní editace se skoro nevyskytují)
- bylo by to moc drahé?
- není efektivita práce dnes nutná, rozhoduje moderní vzhled?
- je to zákazníkům dnes jedno, jak budou každodenně pracovat? (v 80-letech existovaly ergonomické předpisy, jak má práce s daty na obrazovce vypadat - je ta ergonomie v rámci poptávek dnes vůbec vyžadována?)
- mohl by někdo doporučit nějakou knihovnu, kde je ta editace na solidní úrovni?

[Reklama]

[none_]

Vsechno je mozne. Otazka je, co si objedna zakaznik. Kazdy radek kodu stoji penize a pokud zakaznikovi staci jedno policko na jeden radek a validace na strane serveru, dostane presne to.

Muj oblibeny priklad:
Platebni brany. Vetsina z nich ma dve oddelena policka pro platnost karty a po zadani dvou cisel musim zmazknout tab, zadat 2 cisla a zase tab. Jedna (o ktery vim) brana vsak umi automaticky posouvat cloveka jakmile zada validni hodnotu do dalsiho policka a jeste k tomu zobrazuje animaci karty, kde se dana informace vyskytuje. Tzn karta se pred zadanim toho kontrolniho kodu ze zadni strany hezky otoci a zvyrazni tu cast.

[Wangarad]

Prepac ale velmy netusim co chces povedat.
Akoze input sa neda spravit tak aby mal presne 3 znaky?
Akoze nevies nastavit aby input bral len cisla?
Tie cisla co sa zadavaju s lava doprava co je a tom zle resp. je problem poriesit aby to slo naopak? Preco?
 A vobec co tym chces povedat? Ze v 80 si mal tak rozlisenie 150x150 alebo ?

Ako moze  to ci pisem pismenka s lava do prava alebo pole kde viem zadat 3 znaky ale opticky vyzera na 4 ovplyvnovat elektivitu?

a k tym knizniciam asi ich vela nie je len preto ze je to podstatne ako 0.0 prd.

Vsetko je to o peniazoch. Ak chces a mas peniaze tak programator naprogramuje aj jednorozca.

Ja vzdy hovorim zakaznikom ze vsetko sa da len otazka je kolko vedia zaplatit.

[Death Walker]

čísla se zadávají zrovna tak jako text zleva (ne tedy jako na kalulačce) podle principu zadej co chceš a zkoriguj to jak umíš

Ako, pre kalkulacky som mal vzdy slabost, ale taku na ktorej by sa cisla zadavali od jednotiek smero k vyssim radom(zprava do lava) som este nevidel, ani na kalkulacke s RPN. Mozete mi prezradit vyrobcu a model?

K ergonomii: no ono v tych 80 rokoch bola praca vyhradne cez klavesnicu jaksi podmienena technicky, mys alebo trackball bola skor rarita. Minula generacia uz bola klikacia a tato tukacia(do obrazovky).
K vzhladu: je to podmienene tiez technicky, v dnesnej dobe nevadi ked sa ta obrazovka prekresli desiatky krat v sekunde, naviac je pozadovana responzivita, koli sirokej skale rozliseni. Tiez je dost caste ze grafikov robia neuspesni umelci, ktory okolo UX plavali akurat v ponorke a aj to bola kalna voda...

[Death Walker]

Mozete mi prezradit vyrobcu a model?

Sorry za rypnutie, dnes mi to zapaluje pomaly, vy ste nemal zrejme na mysli zadavanie, ale zarovnanie inputu vlavo,  ktory by pre zadavanie cisel mal byt zarovnany vpravo. To je mozne lahko upravit par riadkami v css, len dizajnerom to zrejme pride rozsypane ked polovicu poli mate zarovnanu vpravo a polovicu vlavo...

[Reklama]

[Ondřej Holub]

Osobně si myslím, že v dnešní době je oficiální postoj takový, že je to jedno a nezáleží na tom. Když jsem říkal někdejšímu kolegovi, že musíme opravit konfigurační formulář tak, aby při mačkání tab neskákal kurzor z 1. políčka na páté a že to musí reagovat na Enter (jako submit), aby nemusel uživatel tabem doskákat na tlačítko ani nemusel hledat myš, tak mně odpověděl, že nechápe, o čem mluvím. Nedokázal jsem mu to vysvětlit ani na ukázce (dle mého názoru) správného formuláře a chybného. A nebyl to hloupý člověk. Neuspěl jsem ani s argumentem, že třeba Microsoft to obvykle má (nebo aspoň tehdy měl) správně.

[L..]

- vstupní prvek je vesměs roztažen přes celou šíři obrazovky, i když je pro zadání potřeba pár milimetrů

Pár milimetrů? To není ani jeden znak. Co zadáváte v tak malém poli? Jinak ano, políčka jsou občas o dost širší, než by bylo potřeba, což je většinou proto, aby formulář nějak rozumně vypadal. Ony "schody" přesně podle potřebných délek ztěžují orientaci ve formuláři a jsou tak neergonomické.

- mnohdy se do vstupníhu prvku dá napsat cokoliv a po nějakém submitu je uživatel upozorněn, že tam a tam není údaj správny a po řadě se to  koriguje

To je částečně client / server paradigmatem. Protože data na straně serveru kontrolovat musíte. Pokud chcete mít kontrolu i na straně klienta, tak musíte vlastně duplikovat tuhle validační logiku, což znamená vyšší pracnost a riziko nekozistencí. Občas se vyskytují knihovny, které se snaží nějak řešit, že by server dokázal předávat metadata na klienta, ale nevím o ničem obecně použitelném. Takže typicky se kontroluje povinnost, občas typ (číslo / řetězec) nebo pattern, ale složitější kontroly většinou probíhají až na serveru. Také některé věci mohou vyžadovat kontrolu v DB atp., což je další komplikace.

Pokud máte na mysli tzv. maskované inputy, tak ty byly populární v devadesátkách, ale pak se od nich upustilo. Já jsem jejich hodnotu moc neviděl ani jako uživatel. Plus musíte řešit, co když do nic uživatel zkusí něco pastnout, atp.

- čísla se zadávají zrovna tak jako text zleva (ne tedy jako na kalulačce) podle principu zadej co chceš a zkoriguj to jak umíš

Jako že by se měly zadávat nejdřív jednotky, pak desítky, pak stovky... Proboha, kdo takovou šílenost vymyslel?

- vstupní prvky např. s desettinou (čárkou) tečkou jsou zarovnány podle levého nebo pravého okraje a ne podle polohy desettiné čárky

Tohle vyžaduje mít neproporcionální font, jinak to stejně vypadá blbě. Plus je to hodně crcání za malý efekt, input ve webovém prohlížeči by člověk musel dost znásilňovat.

... s podobnými formulářemi a editací by s námi zákazníci před 40 lety vyrazili dveře.

Jako že v roce 1982? Za socíku? No, když by i vyrazili, tak pak by neměli nic, protože konkurence jaksi neexistovala :-D

Pokud jste fakt tehdy nějaké aplikace dělal, tak to byly aplikace na lokálním počítači (ne-webovém), na obrazovce o přesně daných rozměrech s neproporcionálním písmem a pro zaškolené uživatele co je používali velmi často. Dnešní webové aplikace jsou pro dost jiné podmínky.

- je nějaká vstřícnější forma editace dnes technicky nemožná? (např. javascript knihovny s vysokou podporou ineraktivní editace se skoro nevyskytují)

Část je zodpovězena výše. Nějakou rozšířenou JS knihovny vyloženě na vstup dat asi nevím. Co píšu jsou React aplikace, které mají knihovnu obstarávající business logiku formulářů (final-form, formik) a UI knihovnu (Material UI, bootstrap, ...) nad kterými jsou vlastní knihovny. To je interaktivní dost :-)

[MalyTomi]

Protože data na straně serveru kontrolovat musíte. Pokud chcete mít kontrolu i na straně klienta, tak musíte vlastně duplikovat tuhle validační logiku, což znamená vyšší pracnost a riziko nekozistencí.

Toto sa da vyriesit tak, ze na pozadi js odosle request na server, ktory vykona validaciu - presne tu istu, ktoru robi aj on a posle odpoved. Cize ziadna nekonzistentnost, validuje to jedna a ta ista funkcia.

Jako že by se měly zadávat nejdřív jednotky, pak desítky, pak stovky... Proboha, kdo takovou šílenost vymyslel?

Nie, pises normalne, ale v inpute je to zarovnane doprava.


Dnes je to najma o tom, ze formulare uz nezobrazuje len na obrazovke s presnym rastrom, ale su rozne rozlisenia, mame tu mobil/tablet a preto je lepsie mat jednotny vzhlad - napr. rovnaku sirku prvkov, aby sa to lepsie skalovalo a formular vyzeral dobre aj na malo displeji.
Co sa tyka vzhladu, tak existuje vela js frameworkov, ktore ti vedia pekne naformatovat v textovych poliach, dokonca aj podla nastaveneho prostredia, ale to uz stoji cas sa s tym piplat a v pripade velkeho firemneho sw je to tak trocha zbytocne, lebo tam ide o data, nie o vzhlad, a dolezitejsia je funkcnost.

[L..]

Toto sa da vyriesit tak, ze na pozadi js odosle request na server, ktory vykona validaciu - presne tu istu, ktoru robi aj on a posle odpoved. Cize ziadna nekonzistentnost, validuje to jedna a ta ista funkcia.

Nechtěl jsem ze svého příspěvku dělat román výčtem úplně všech možností, ale asi budu muset :-)

Tohle se samozřejmě udělat dá. Ale má to několik nevýhod:

- Je to pracné
- Validace probíhá až se zpožděním, tedy se člověk musí tak jako tak do pole vracet
- Zatěžuje to server (občas to nevadí, občas ano)

Takže se to obecně moc nepoužívá, respektive se to používá jen na validaci nějakých specifických polí, třeba při registraci se takhle asynchronně kontroluje, zda není uživatelské jméno obsazené.

Nie, pises normalne, ale v inpute je to zarovnane doprava.

Aha, to bylo napsané tedy dost zvláštně. No, to je většinou proto, že pokud jsou ve formuláři pod sebou různě řetězce a čísla, tak vypadá blbě, když je každé zarovnané jinak. A na zadávání čísla zarovnaného doleva není nic extra neergonomického. Smysl je zarovnávat doprava má tehdy, pokud se zadává víc delších čísel pod sebou.

[Ħαℓ₸℮ℵ ␏⫢ ⦚ »]

Taky mě to sere, naposled u zubaře chtěli dva archy Dotazníků, z toho jeden dokonce oboustraný!! Před 4 lety ještě nic... A to ještě operovali v respiči !

[Jan Karasek]

Vsechno je mozne. Otazka je, co si objedna zakaznik. Kazdy radek kodu stoji penize a pokud zakaznikovi staci jedno policko na jeden radek a validace na strane serveru, dostane presne to.

a kdyz si zakaznik objedna nejakou zjevnou hovadinu, ktera je sice technicky mozna ale treba mu ve vyslednem efektu vice skodi nez prospiva, tak to take dostane? To si nemyslim, ze to tak delate. 

[Jan Karasek]

Mozete mi prezradit vyrobcu a model?

Sorry za rypnutie, dnes mi to zapaluje pomaly, vy ste nemal zrejme na mysli zadavanie, ale zarovnanie inputu vlavo,  ktory by pre zadavanie cisel mal byt zarovnany vpravo. To je mozne lahko upravit par riadkami v css, len dizajnerom to zrejme pride rozsypane ked polovicu poli mate zarovnanu vpravo a polovicu vlavo...

chyba je na moji strane. Nevyjadril jsem se presne, takze se o to pokusim.
Zadavani napr. ciselneho udaje (7.2f ... dve mista za desetinnou teckou a max. 4 mista pred vcetne znaminka) se drive resilo tak, ze caret se pri vstupu do policka posadil na desetinou tecku a zacala se zadavat ta celociselna cast toho udaje. Pritom se caret nepohyboval a jednotlive cifry se v policku objevovaly zprava jak na kalkulacce.  Pote uzivatel zmacknul znak desetinne tecky a caret se presunul do prvniho desettineho místa za tou teckou a uzivatel zadal nyni to nejvyssi  desettine misto. Od desetinne tecky se to editovalo tedy jako text. Samozrejme, ze byly blokovany ty sipky a jine 'zle' znaky.
To vsechno melo ten smysl, aby uzivatel delal co nejmene chyb. K tomu byly prave ty ergonomicke studie.

Ja to nijak neobhajuji a akceptuji silu trhu. Muj pracovni étos mi to doposovad zakazoval, ale my jsme ve firme schopni se ucit dale :-)

[L..]

Zadavani se drive resilo tak, ze caret se pri vstupu do policka posadil na desetinou tecku a zacala se zadavat ta celociselna cast toho udaje. Pritom se caret nepohyboval a jednotlive cifry se v policku objevovaly zprava jak na kalkulacce.  Pote uzivatel zmacknul znak desetinne tecky a caret se presunul do prvniho desettineho místa za tou teckou a uzivatel zadal nyni to nejvyssi  desettine misto. Od desetinne tecky se to editovalo tedy jako text. Samozrejme, ze byly blokovany ty sipky a jine 'zle' znaky.

Vždycky, když něco takového potkám, tak mám chuť autorům provést něco strašného. Třeba pomazat medem a přivázat do mraveniště. Nebo jim zlámat obě ruce nadesetkrát, aby už nikdy nenapsali ani řádek kódu. Nebo ještě něco děsivějšího - donutit je ten jejich neergonomický paskvil denně používat.

[none_]

Vsechno je mozne. Otazka je, co si objedna zakaznik. Kazdy radek kodu stoji penize a pokud zakaznikovi staci jedno policko na jeden radek a validace na strane serveru, dostane presne to.

a kdyz si zakaznik objedna nejakou zjevnou hovadinu, ktera je sice technicky mozna ale treba mu ve vyslednem efektu vice skodi nez prospiva, tak to take dostane? To si nemyslim, ze to tak delate.

Ale ano, i tak se to dela. Samozrejme se mu to pokusime nejdriv vysvetlit, ale nakonec vzdycky zvitezi: Nas zakaznik, nas pan.

Ma to dva duvody:
1. vy nemusite presne rozumet tomu, co chce zakaznik delat.
2. i kdyby to byl blbec, tak mu to samozrejme nemuzete rict (a pokud pozdeji prijde, ze jste meli pravdu, tak jen dobre).

[APhacker_mob]

Samotne HTML podporuje ciselne inputy vcetne validace. Vic kmentovat nebudu. Otevrte si libovolny webovy formular, kde se zadavaji cisla.