Mám nějaké informace, které mohu zadat do textového pole. Data jsou strukturována a platné jsou pouze některé sekvence. Například pro telefonní číslo je neplatný dopis, například A
.
Měl bych tedy zachytit události na klávesnici a zabránit tomu, aby zadaná písmena dosáhla textového pole, nebo bych měla nakreslit nějaké červené zakřivené čáry (nebo jiné vizuální narážky), abych informovala svého uživatele, že dopis není přijatelný? Co je lepší uživatelský dojem?
Převládající kontrola uživatele nad jeho počítačem bude vždy přerušením a často vnímána jako invaze pracovního postupu daného uživatele. Webové stránky „neměly“ mít kontrolu nad našimi počítači, takže taková kontrola bude alespoň trochu alarmující.
To znamená, že procházíte opravdu důležitým tématem, protože je důležité informovat uživatele o tom, že jeho položka je neplatná, než vyplní celou sadu polí a odešle je.
Přístup, který jsem zjistil, že je nejméně rušivý, ale poskytuje nejrychlejší odezvu, je tok níže.
V zásadě počkejte, až vyplní své první pole, a poté, co kliknou na kartu/kartu kolem nového pole (nebo pole, které bylo zrušeno), zkontrolujte pole, které bylo právě vyplněno. Pokud je pole, které bylo právě vyplněno, platné, vytiskněte vedle něj nenápadnou „dobrou“ ikonu (zelená, zaškrtávací značka, šťastná tvář, dostanete nápad). Pokud se nezdaří validační pravidla, vytiskněte „špatnou“ ikonu (červená, „X“ atd.) A krátký řádek o tom, co selhalo.
Nezapomeňte však nepřerušovat jejich pracovní postup:
Až budou hotovi s polem, do kterého se přesunuli, buď se vrátí do neplatného pole, nebo se přesunou a vrátí se později. Ať tak či onak, uvidí, že mají úpravy, ale mohou to udělat ve svůj vlastní čas.
Nakonec budou mít před odesláním zcela platný formulář, což znamená
Vzhledem k tomu, že používám formulář na obou koncích, zde uvádíme několik pokynů, které dávám přednost:
onBlur()
, a ne dříve. To dává uživateli šanci opravit chybně zadané písmeno „A“ dříve, než se zobrazí chybová zpráva. Umožnění uživateli opravit chybu, zatímco je stále ve vstupním poli, poskytuje o jednu menší šanci pro rušivou zprávu typu „hej, zmatek, kámo“.Pokud během psaní zabráníte neplatným znakům, mohli by si myslet, že jejich klávesnice nefunguje správně. Uživatel má rád věci, které fungují tak, jak očekávají. Pokud se chystáte zabránit stisknutí určitých znaků na tlačítku, měli byste přinejmenším zároveň zobrazit chybové hlášení poblíž vstupu. Tímto způsobem vědí, proč to není psaní.
Další věc, která může být nepříjemná, je, když jste právě dokončili vyplňování dlouhého formuláře a web používá ověření na straně serveru, takže se musíte vrátit skrz formulář a zjistit, co se děje. Rád používám ověřování na straně klienta především, ale upadám zpět na straně serveru. Zobrazí se chyba buď při psaní, nebo když vstup ztratí fokus. Tímto způsobem uživatel okamžitě ví, že se jedná o problém a přesně ví, o jaký problém jde.
Zjistil jsem, že bránění uživatelům v tvorbě chyb je vždy 10x těžší, než jsem si původně myslel. Příklad: Telefonní číslo někoho může mít příponu, například x2333. Použil jsem jQuery plugin pro vstupní mask pro kreditní karty a to fungovalo dobře. Používám automatické návrhy, kdykoli je to možné.
V jakémkoli složitém systému budete mít okolnosti, které je nákladné detekovat inline, a musíte je po tom sdělit. Odpověď je pro mě případ od případu a ujistěte se, že pokrýváte každý případ Edge.
Navrhoval bych kombinaci obou přístupů, ale pouze pro přísně ověřená pole, jako jsou telefonní čísla (SSN, PSČ, atd. ... cokoli, co musí být podle definice číselné).
Sledujte každý stisk klávesy a když uživatel zadá neplatný znak, ukažte to ... ale okamžitě signalizujte, že se něco děje. Pravděpodobně otočte vstupní pole červeně a napravo od pole se zobrazí „Zadejte pouze číselné znaky“.
Blokovací vstup je ne-ne, protože jej může uživatel nesprávně interpretovat. Mohou předpokládat problém se svým strojem nebo vstupním zařízením, ne že by neměli psát písmeno do číselného pole.
Ověření po po dokončení vstupu může být nepříjemné. Zejména s poli, která se používají při vytváření hesel. Některé weby vyžadují šestimístná hesla s pouze alfanumerickými znaky. Ostatní vyžadují 9místná hesla a povolují libovolný znak (včetně! @ # $% Apod.). Zadáním hesla a zjišťováním poté, co jsem zadal, je to nejnepříjemnější typ formuláře, který jsem našel, a skutečně mě odvrátil od několika služeb .
Poskytování dynamické zpětné vazby při zadávání dat jim pomáhá
Blokování vstupu selhalo na všech 3 účtech. Zvýraznění chyb ověření po vyplnění textového pole selže také na všech 3.
Záleží na případu. Pokud je to možné, použijte automatické návrhy. Pokud zachytíte vstup uživatele, je nezbytná okamžitá zpětná vazba. Jedním z možných řešení je „záchytná skříň“, která se objeví hned po zachycení klíče. Můžete to vidět na přihlašovací obrazovce Windows, objeví se, pokud například stisknete znak $.
Stejně jako u většiny věcí. Závisí na kontextu. Mám specializovanější téma. Většina aplikací, na kterých já nebo moje skupina pracuji, má technický charakter a používá je pouze přiměřeně vyškolená osoba. Proto můžeme dát uživatelům více odpovědnosti a svobody do rukou uživatelů, než byste mohli s širokou veřejností. Stručně řečeno, některé pokyny, které používáme ...
Téměř všechny příklady jsou vyžadovány uživatelem a, ano ... implementace je někdy skutečný medvěd/noční můra/vrah, ale zřídka nemožné.
Upozornění: Opět platí, že tyto příklady jsou uvedeny v souvislosti se svislým systémem s technickou základnou uživatelů ... nejde o webovou veřejnou formu atd. Váš počet najetých kilometrů se liší.
* Kromě červené. V našem podnikání červená znamená: Nebezpečí, že byste mohli být zabiti ... nebo ještě horší.