Formuláre, ktoré ľudia vyplnia: Návrh, validácia a potvrdenie

01Najprv určite, čo potrebujete vybaviť

Pri dopyte môže byť cieľom dohodnúť prvý rozhovor. Pri reklamácii nájsť objednávku a pochopiť problém. Obe úlohy preto nemusia mať rovnaké polia. Pri každom údaji napíšte, kto ho využije a na aký ďalší krok. Ak odpoveď nepoznáte, pole odstráňte alebo ho odložte na neskôr.

W3C odporúča žiadať iba údaje potrebné na dokončenie procesu. V návrhu si vytvorte zoznam: údaj, dôvod, povinný alebo nepovinný, príjemca. Pri telefónnom čísle napríklad rozhodnite, či bez hovoru naozaj nemožno požiadavku vybaviť. „Obchodník ho možno využije“ nie je presvedčivý dôvod na povinné vyplnenie.

Na začiatku vysvetlite, čo človek získa a čo bude nasledovať. Nesľubujte odpoveď do hodiny, ak takú lehotu tím nedokáže dodržať. Proces najprv dohodnite s ľuďmi, ktorí žiadosti spracúvajú. Formulár zbierajúci správne údaje do nesledovanej schránky nemá vyriešený výsledok.

02Každé pole potrebuje trvalý popis

Názov poľa musí zostať viditeľný aj počas písania. Príklad v prázdnom políčku môže naznačiť formát, ale nenahrádza popis. Pri údajoch, ktoré sa ľahko zamieňajú, pridajte krátku pomôcku: napríklad či chcete číslo objednávky alebo faktúry.

Povinné a nepovinné polia označujte jednotne. Súvisiace možnosti zoskupte a pri skupine uveďte otázku. Návod W3C k popisom vysvetľuje ich prepojenie s ovládacími prvkami. V zadaní pre vývojára preto nestačí uviesť, že popis je nad poľom. Musí k nemu patriť aj programovo.

Vyskúšajte dlhé meno, názov firmy s diakritikou aj viacriadkovú adresu. Krátky ukážkový text neodhalí, čo sa stane po zalomení. Pomocné texty píšte podľa skutočných obmedzení systému. Ak príloha musí mať určitý formát a veľkosť, ukážte to pred výberom súboru.

03Na mobile uľahčite zadávanie

Pole pre e-mail má zodpovedať e-mailu, telefónne číslo má umožniť vhodnú klávesnicu a automatické dopĺňanie má rešpektovať účel údaja. Identifikátory, napríklad PSČ alebo číslo objednávky, nepovažujte automaticky za čísla na výpočty. Môžu obsahovať úvodnú nulu alebo písmená.

W3C pri validácii upozorňuje na rôzne zápisy telefónnych čísel aj zahraničných poštových smerovacích čísel. Prijímajte bežné medzery a predvoľby, ak ich viete bezpečne spracovať. Prísny formát vyžadujte pre skutočnú potrebu, nie preto, že sa jednoducho kontroluje regulárnym výrazom.

Na telefóne prejdite formulár s otvorenou klávesnicou. Overte, či nezakrýva aktuálnu chybu, tlačidlo alebo dôležitú pomôcku. Krátky dopyt nemusí byť výhodné deliť na viac krokov. Dlhší proces rozdeľte podľa rozhodnutí človeka a umožnite návrat bez straty údajov.

04Validujte vtedy, keď človek môže niečo opraviť

Prázdne pole neoznačujte ako chybné hneď po otvorení stránky. Odporúčame kontrolovať dokončený vstup po opustení poľa a znovu pri odoslaní. Pri už oznámenej chybe môže priebežná kontrola ukázať, že oprava zabrala. Konkrétne správanie overte s používateľmi formulára.

Iný režim sa hodí pre heslo, iný pre obsadené používateľské meno. Pri vzdialenej kontrole neoznamujte „voľné“, kým nepríde odpoveď. Ak človek medzitým údaj zmení, starší výsledok nesmie pôsobiť ako kontrola novej hodnoty. Pomalé spojenie zahrňte do návrhu, nečakajte na sťažnosť po spustení.

Dokumentácia MDN k validácii zdôrazňuje, že kontrolu v prehliadači možno obísť. Server preto musí vstupy overiť znovu. Zelená značka pri e-maile potvrdzuje najviac vykonanú kontrolu, nie automaticky existenciu schránky alebo totožnosť človeka.

05Chyba má pomenovať problém aj ďalší krok

„Neplatná hodnota“ nehovorí, čo treba zmeniť. Lepšia správa pomenuje konkrétny údaj a opravu. Chybu pripojte k poľu, zachovajte vyplnený obsah a nespoliehajte sa iba na červený rámček. Text má človeku pomôcť pokračovať, nie ho hodnotiť.

Po neúspešnom odoslaní dlhého formulára pridajte súhrn chýb s odkazmi na príslušné polia. Vzor GOV.UK pre súhrn chýb používa súhrn spolu so správou pri vstupe. Overte tiež presun pozornosti a čítanie chýb pomocou asistenčných technológií.

06Rozlišujte chybu vstupu a nedostupnú službu

Nesprávne zadané PSČ môže opraviť zákazník. Výpadok vášho servera nie. V druhom prípade nepíšte iba „skontrolujte údaje“. Vysvetlite, či systém požiadavku prijal, čo zostalo zachované a ako možno pokračovať. Ak stav nepoznáte, priznajte neistotu namiesto falošného potvrdenia.

Počas odosielania ukážte prebiehajúcu prácu a riešte opakované kliknutie. Pri objednávkach a rezerváciách navrhnite na serveri ochranu pred duplicitným spracovaním. Samotné zablokovanie tlačidla nerieši opakovaný požiadavok po obnovení stránky či výpadku spojenia. Po chybe musí byť jasné, či a ako sa dá akcia bezpečne zopakovať.

07Potvrdenie je súčasťou formulára

Úspech oznámte až po zodpovedajúcom potvrdení systému. Uveďte, čo ste prijali, čo bude nasledovať a kde človek nájde ďalšie informácie. Pri zložitejšej žiadosti môže pomôcť kontrolná stránka pred odoslaním. Vzor kontroly odpovedí GOV.UK ukazuje návrat k úprave jednotlivých údajov.

Navrhnite aj situáciu, keď sa potvrdzujúci e-mail oneskorí. Používateľ nemá vyplniť formulár znovu iba preto, že správu nevidí v schránke. Ak máte číslo požiadavky, zobrazte ho aj na potvrdzujúcej stránke. Citlivý obsah na nej zbytočne neopakujte.

08Merajte dokončenie a kvalitu požiadaviek

Rozlišujte zobrazenie formulára, začatie, chybu vstupu, pokus o odoslanie a potvrdené prijatie. Samotné kliknutie na tlačidlo nie je hotový dopyt. Do analytických udalostí nevkladajte obsah polí, e-mail ani text správy. Pri diagnostike zvyčajne stačí identifikátor poľa a typ problému.

Pri porovnávaní verzií sledujte aj platné kontakty a dodatočnú prácu obsluhy. Vyšší počet odoslaní nepomôže, ak pribudnú nevyriešiteľné žiadosti. Oddeľte mobil a počítač a zapíšte, čo sa zmenilo. Bez rovnakej definície dokončenia výsledky nemožno porovnávať.

Pri odovzdaní si zaznamenajte, kto bude sledovať chyby a kto spracuje prijaté správy. Skontrolujte tiež text automatickej odpovede. Ak používateľ dostane iný prísľub vo formulári a iný v e-maile, ani technicky správne odoslanie neodstráni jeho neistotu.

Pred nasadením prejdite platný vstup, viac chýb naraz, klávesnicu, telefón, pomalú odpoveď aj zlyhanie servera. Požiadavka musí doraziť tam, kde ju niekto vybaví. Chcete preveriť návrh aj dokončenie procesu? Pri webe na mieru začnite práve týmto spoločným scenárom.