UX și HTML5: să ajutăm utilizatorii să completeze formularul dvs. mobil (partea 1)

Formularele sunt una dintre cele mai elementare interacțiuni principale pe care utilizatorii le vor avea cu site-urile dvs. web (și cu aplicațiile mobile). Leagă oamenii împreună și îi lasă să comunice. Le-au lăsat să comenteze articolele și să explice autorului modul în care nu sunt puternic de acord cu ceea ce au scris. Le permit oamenilor să converseze direct pe o aplicație de întâlniri pentru a-l întâlni pe „celul”. Fie pentru forumuri, comenzi de produse, comunități online, creare de conturi sau plată online, formularele reprezintă o parte importantă a vieții online a utilizatorilor.

Este 2018 și avem mai mulți utilizatori de dispozitive mobile decât desktop de pe tot globul . Cu toate acestea, încă tratăm acești utilizatori ca cetățeni de clasa a doua ai webului. Toată lumea scrie și vorbește despre experiența utilizatorului tot timpul. Deci, de ce, de ce, de ce atât de multe site-uri web și produse încă fac asta greșit. De ce experiența lor de utilizare mobilă este deteriorată pentru jumătate din lume? De ce este încă o durere, de ce este încă super greu să rezervi un zbor și să înregistrezi un cont într-un formular mobil astăzi? Utilizatorii se așteaptă la mai bine!

Lectură recomandată : World Wide Web, nu Wealthy Western Web

Aceasta este prima parte a unei serii de două articole. În aceasta, voi rezuma câteva dintre cele mai bune practici esențiale pentru a vă îmbunătăți formularele mobile, inclusiv scanabilitatea și lizibilitatea. Vă voi ghida prin plasarea etichetelor și a intrărilor, dimensiunea și optimizarea. Vom vedea cum să alegem elementul de formular potrivit pentru a reduce costurile de interacțiune. În cele din urmă, veți învăța cum să preveniți și să tratați erorile din formularele mobile.

În a doua parte, voi arunca o privire mai atentă asupra capacităților mobile specifice și a elementelor de formular HTML5 și vom merge dincolo de elementele de formular clasice pentru a crea aplicații web și site-uri web unice și plăcute.

Notă : deși majoritatea îmbunătățirilor de cod din acest articol sunt legate de web (pentru că nu cunosc Swift sau Java), cele mai bune practici de utilizare sunt valabile pentru aplicațiile mobile .

Proiectarea formularelor 101: prioritizarea scanabilității și lizibilității

„Un formular este numele, valoarea, perechile, într-o structură pentru stocarea datelor pe un computer, desfășurate ca etichete și câmpuri de intrare pentru ființa umană.” Acesta este un citat direct din Luke Wroblewski la o conferință. Ca și el, cred că majoritatea problemelor de utilizare a formularelor provin din această tendință de a servi structura bazei de date utilizatorilor.

Arhitectură informațională puternică

Pentru a construi formulare mai bune, mai întâi trebuie să faceți câțiva pași departe de structura bazei de date. Încercați să înțelegeți cum doresc utilizatorii să completeze formularele. Aici devine utilă testele de utilizare și cercetarea utilizatorilor pe formularele dvs. Modelele mentale ale utilizatorului este un concept UX care vă poate ajuta în acest sens. Nielsen Norman Group îl descrie drept „ceea ce crede utilizatorul despre sistemul în cauză”. Cereți testatorului dvs. să gândească cu voce tare și să vă spună cum ar completa formularul. La ce pași se așteaptă ei? Ce vine mai întâi? Ce urmeaza? Acest lucru vă va oferi o idee mai bună despre cum să vă structurați formularul într-un mod mai ușor de utilizat.

Gruparea vizuală a câmpurilor care aparțin împreună va ajuta, de asemenea, utilizatorii să completeze un formular. În cod, utilizați eticheta fieldset pentru a le grupa programatic. De asemenea, va ajuta cititorii de ecran să înțeleagă ierarhia.

Dacă formularul este lung, nu expuneți totul în mod implicit . Fii inteligent cu ceea ce afișezi. Utilizați ramificarea cu înțelepciune pentru a afișa numai câmpurile de care oamenii au nevoie. Într-un formular de plată, de exemplu, nu afișați toate câmpurile detaliate pentru toate opțiunile de expediere. Acest lucru va copleși utilizatorul. Afișați suficiente informații pentru a-i ajuta să aleagă opțiunea de expediere potrivită. Apoi, afișați numai detaliile și câmpurile legate de acea alegere.

Perioada de atenție a utilizatorului se scurtează cu timpul: cereți lucruri opționale la sfârșitul formularului. De exemplu, dacă formularul dvs. este un sondaj de satisfacție a clienților, solicitați informații demografice la sfârșit. Mai bine, completați-le automat, dacă este posibil. Cereți utilizatorilor doar ceea ce este necesar.

În cele din urmă, planificați din timp localizarea: ce se va întâmpla când formularul dvs. va fi tradus? Ce se va întâmpla, să zicem, pentru germană? Va mai funcționa designul tău?

Plasarea etichetelor și optimizarea intrărilor

Aspectul cu o singură coloană funcționează cel mai bine

Din cauza lipsei de spațiu, nu aveți opțiuni nesfârșite pentru plasarea etichetelor și câmpurilor pe ecranele mobile:

• Prezentați câmpurile într-un aspect cu o singură coloană . Nu există loc pe mobil pentru mai multe coloane. Formularele cu mai multe coloane nu sunt o idee grozavă nici pe desktop.
• În modul portret, este mai bine să plasați eticheta deasupra câmpului, astfel încât utilizatorii să poată vedea ce este în câmp atunci când scriu.

• În modul peisaj, înălțimea ecranului este redusă. Poate doriți să puneți etichete în stânga și intrări în dreapta . Dar testați-l pentru a vă asigura că funcționează.

Pentru mai multe despre plasarea etichetelor, consultați „Utilizarea formularelor mobile: plasați etichetele deasupra câmpului” a Institutului Baymard.

Etichetele ar trebui să fie clare și vizibile și să funcționeze fără context

Amintiți-vă că, de îndată ce un câmp devine focalizat, tastatura se deschide și va ocupa cel puțin o treime din suprafața ecranului. Pe ecranele mobile mici, utilizatorii vor trebui, de asemenea, să deruleze pentru a completa formularul. Aceasta înseamnă că vor pierde o parte din context în timp ce completează formularul. Planificați în consecință:

• Etichetele dvs. ar trebui să fie text clar, vizibil, care să poată fi citit și înțeles fără context. Utilizatorul ar trebui să poată finaliza fiecare pereche de etichete și câmpuri ca o sarcină separată, chiar dacă își pierd contextul.

• Evitați jargonul, abrevierile și limbajul specific industriei ori de câte ori puteți.
• Fii consistent. Dacă folosiți „client” într-o etichetă o dată, rămâneți cu acel cuvânt. Evitați să folosiți „clienți” mai târziu, deoarece ar putea deruta utilizatorii.
• Dimensiunea fontului ar trebui să fie suficient de mare. Testați-vă formularul pe dispozitive reale cât mai curând posibil și ajustați dimensiunea în consecință.
• Textul cu majuscule poate fi greu de citit pentru unii utilizatori. Poate doriți să evitați utilizarea textului cu majuscule pe etichete.
• Copia etichetei trebuie să fie scurtă și scanabilă. Dacă un câmp necesită clarificări, nu-l pune pe etichetă. Utilizați în schimb o descriere a câmpului.

Cea mai bună practică privind dimensiunea intrării

Dacă este posibil, dimensiunea elementului de intrare ar trebui să se potrivească cu dimensiunea conținutului așteptat . Acest lucru va ajuta utilizatorii să completeze rapid formularul și să înțeleagă ce se așteaptă.

Folosirea măștilor pentru a evita împărțirea intrărilor pe mobil

Nu împărțiți intrările doar de dragul formatării . Este deosebit de enervant pe mobil, unde utilizatorii nu pot folosi tastatura pentru a naviga între câmpuri. Este nevoie de atingeri suplimentare doar pentru a merge la următorul câmp pentru a completa formularul. S-ar putea să vă gândiți, „Dar în mod automat mă voi concentra pe următorul câmp când voi obține numărul necesar de caractere în acel câmp”. Asta ar putea funcționa. Dar veți fi preluat controlul asupra interfeței de utilizare, care devine imprevizibilă pentru utilizator. De asemenea, ar fi o durere dacă i-ai trimite automat în câmpul următor și ar trebui să corecteze ceva în ultimul câmp. În cele din urmă, este mai complicat să ghiciți ce este obligatoriu cu intrările divizate. Deci, să încetăm să jucăm jocul „Dar dacă” și pur și simplu să nu împărțim intrările.

Am înțeles: încă doriți să puteți formata datele utilizatorului dvs. în bucăți mici pentru a-i ajuta să completeze câmpurile dvs. Și ai perfectă dreptate în privința asta. Pentru a face acest lucru, puteți folosi măști . În loc să divizați o intrare, puneți o mască deasupra ei, pentru a ajuta vizual utilizatorul să o umple. Iată un exemplu video despre cum ar arăta o mască pentru a ajuta utilizatorii să completeze un câmp pentru cardul de credit:

Măștile ajută la prevenirea erorilor, ghidând utilizatorii către formatul corect. Evitați să le dezvăluiți treptat - afișați direct formatul. De asemenea, evitați să puneți valori false în mască . Utilizatorii ar putea crede că este deja umplut. De aceea, am înlocuit numerele cu un mic „X” în demonstrația mea. Găsiți ce funcționează cel mai bine pentru tipul dvs. de intrare.

În cele din urmă, amintiți-vă că unele date pot varia de la o țară la alta și, uneori, formatul se schimbă și (numerele de telefon, de exemplu). Planificați în consecință.

Descrieri de câmpuri eficiente

Afișarea unor descrieri eficiente de câmp poate face diferența între o experiență fără întreruperi și o experiență dureroasă.

La ce pot fi folosite descrierile?

Descrierile pot ajuta utilizatorii în atât de multe moduri. Iată câteva exemple.

• Ce ceri mai exact?
  

  Indiferent de motivul legat de baza de date, unele companii de expediere solicită câmpurile „Adresa 1” și „Adresa 2”. Acest lucru este foarte confuz pentru utilizatori, dar este posibil să nu aveți de ales aici. Adăugați câmpuri de descriere pentru a ajuta utilizatorii să înțeleagă ce trebuie să pună în fiecare câmp.

  

  Același lucru este valabil și pentru acronime și abrevieri. Știu că am spus că ar trebui să le eviți, dar uneori nu poți. Dacă lucrați la formulare complexe pentru o anumită industrie, de exemplu, acestea ar putea avea propriul set de abrevieri. Este posibil ca orice utilizator nou care trebuie să completeze formularul să nu fie familiarizat (încă) cu acele abrevieri. A avea o descriere disponibilă undeva îi va ajuta.

• De ce aveți nevoie de aceste informații?
  Utilizatorii ar putea fi reticenți în a vă oferi informații personale dacă nu înțeleg de ce aveți nevoie de ele și ce veți face cu ele . Dar uneori trebuie totuși să ceri astfel de informații din motive legale (cum ar fi data nașterii pentru un site web care vinde alcool). Utilizarea descrierilor câmpurilor aici va ajuta utilizatorii să înțeleagă de ce este nevoie de acest tip de informații.
  
  

  Pe site-urile de comerț electronic, poate doriți să cereți numărul de telefon al utilizatorului în cazul în care persoana care livrează trebuie să-l contacteze. Acesta este un motiv legitim. Deci, din nou, folosiți descrierile pentru a explica utilizatorilor de comerț electronic de ce aveți nevoie de numărul lor de telefon.

  

„Unde găsesc informațiile?”
Dacă utilizatorii dvs. trebuie să găsească anumite informații în altă parte pentru a completa un formular, spuneți-le unde să le găsească. Am lucrat la o aplicație mobilă care permite utilizatorului să își urmărească casa. Utilizatorii trebuiau să împerecheze aplicația cu dispozitivul de monitorizare folosind un număr de serie. Nu este foarte ușor să găsești acest număr de serie pe dispozitiv; necesită niște instrucțiuni. Am adaugat putin ? butonul de lângă câmpul numărului de serie. Butonul deschide un mod care arată o imagine și unele indicații pentru a ajuta utilizatorul să înțeleagă unde să găsească numărul de serie pe dispozitivul de monitorizare. Site-urile de comerț electronic fac același lucru cu codurile promoționale: oferă indicatori care le spun utilizatorilor unde să găsească codurile.



• „Cum ar trebui să formatez informațiile?”
  Unele câmpuri au nevoie de un anumit format . În acest caz, utilizați descrierile pentru a informa utilizatorii despre regulile de formatare din timp. Iată câteva exemple:
  • Număr de telefon: trebuie să pun prefixul internațional (+xx) în fața câmpului?
  • Exista o lungime maxima? Twitter pe mobil face o treabă bună cu acesta.
  • Când aveți de-a face cu sume monetare, formatul este cu virgulă (cum ar fi 10.000) sau cu un spațiu (cum ar fi 10.000)?
  • La ce format vă așteptați pentru date? Vă las să verificați pe Wikipedia ce coșmar este. Diferența dintre ZZ LL AA și LL ZZ AA poate cauza *o mulțime* de probleme utilizatorilor când fac rezervări online.
  Rețineți că multe dintre aceste probleme de formatare pot fi rezolvate prin măști de intrare. Vom ajunge la asta mai târziu în articol (sau poți sări direct dacă ești nerăbdător).

  

Cum se afișează descrierile

În exemplele de mai sus, am văzut câteva modalități de afișare a descrierilor câmpurilor. Iată un rezumat a ceea ce trebuie făcut:

• Descrierile în linie ar trebui să fie direct vizibile și afișate lângă câmp.
• Dacă aveți nevoie de descrieri mai aprofundate, cu conținut bogat, puteți utiliza sfaturi cu instrumente sau modal . Sfaturile instrumente sunt, în general, declanșate la trecerea cu mouse-ul pe desktop și la atingere pe mobil. Același lucru este valabil și pentru modal: deschideți-l când utilizatorul atinge pictograma de ajutor sau linkul „vezi mai multe”, de exemplu.

Fiți atenți cu substituenții

Am înțeles: este tentant să eliminați câmpuri de pe mobil pentru a câștiga spațiu și să folosiți substituenți. Cu toții am mers pe acel drum. Dar te rog nu. Specificația HML5 este clară în acest sens: „Atributul substituent reprezintă un indiciu scurt (un cuvânt sau o frază scurtă) menit să ajute utilizatorul cu introducerea datelor”. Și iată de ce:

• Substituentul dispare când utilizatorul începe să tasteze. Utilizatorul trebuie apoi să se bazeze pe memoria pe termen scurt pentru a-și aminti ceea ce ar trebui să pună pe teren . Dacă nu pot, va trebui să golească câmpul pentru a vedea indicația.
• Este greu pentru utilizatori să verifice câmpurile înainte de a trimite , deoarece câmpurile nu mai au nicio indicație de etichetă.
• Este greu de recuperat din erori odată ce un câmp a fost trimis, deoarece, din nou, nu există nicio etichetă care să ajute utilizatorul.

Chiar dacă utilizați substituenți cu etichete, este posibil să aveți în continuare unele probleme. Este greu de făcut diferența dintre un câmp completat și un câmp cu substituent . Sunt un designer UX care scrie despre designul formularelor mobile și chiar și eu am fost păcălit săptămâna trecută de unul dintre aceștia. Dacă mi se întâmplă mie, li se va întâmpla și utilizatorilor tăi - ai încredere în mine. În cele din urmă, majoritatea substituenților au text gri deschis, așa că este posibil să aveți și unele probleme de contrast.

Dacă doriți să aprofundați acest subiect, există un articol grozav numit „Atributul de înlocuitor nu este o etichetă, iar Joshua Winn și FeedbackGuru intră în detaliu despre motivul pentru care aceasta este o idee proastă. Nielsen Norman Group a scris, de asemenea, un articol pe această temă, intitulat „Placeholders in Form Fields are Harmful”.

Substituenții nu sunt obligatorii în HTML5 . Din punct de vedere al utilizării, cu siguranță nu aveți nevoie de un substituent în fiecare câmp al formularului. Dar, odată cu adoptarea masivă a Bootstrap și a altor cadre, se pare că mulți oameni doar copiază și lipesc componente. Acele componente au substituenți, așa că bănuiesc că oamenii se simt oarecum obligați să adauge ceva la substituent din cod? Dacă substituenții formularului arată ca „Vă rugăm să completați — eticheta — aici”, ați procedat greșit.

Etichetele din interiorul câmpurilor ar putea, totuși, să funcționeze bine pentru formularele scurte în care câmpurile sunt previzibile . Formularele de autentificare sunt un bun candidat pentru acest lucru. Dar vă rugăm să nu utilizați substituentul HTML5 pentru a codifica acest lucru. Utilizați o etichetă reală în cod și mutați-o cu CSS și JavaScript.

De la succesul designului material al lui Android, a început să apară un model: eticheta plutitoare. Această etichetă se află în interiorul câmpului atunci când câmpul nu este completat, așa că ocupă ceva mai puțin spațiu vertical pe mobil. Când utilizatorii încep să interacționeze cu câmpul, eticheta se deplasează deasupra câmpului.

Aceasta pare o modalitate interesantă de a câștiga spațiu, fără a întâlni problemele „substituenți în loc de etichete” menționate mai sus. Cu toate acestea, nu rezolvă problema ca utilizatorii să confunde un substituent cu un conținut completat.

Reducerea costurilor de interacțiune pentru formulare de succes

Reducerea costului de interacțiune (adică numărul de atingeri, glisări etc.) utilizatorilor care își îndeplinesc sarcina vă va ajuta să construiți o experiență de formulare perfectă. Există diferite tehnici pentru a realiza asta. Să ne uităm la câteva dintre ele în detaliu.

Un studiu magic pe internet mi-a spus să reduc numărul de câmpuri

Mai multe câmpuri înseamnă mai puține conversii, nu? S-ar putea să fi întâlnit studiul „Am redus formularul de abonare de la 11 la 4 câmpuri și a crescut conversiile cu 160%”. Este un clasic. Și dacă te uiți la formularul lor de contact, are sens. De ce ar dori utilizatorii să completeze 11 câmpuri doar pentru a contacta compania? Nu poți cere un angajament atât de mare unor oameni care abia te cunosc, nu?

Începeți prin a cere doar informații utile. De ce ai nevoie de sexul unei persoane pentru a-i crea un cont? De ce aveți două rânduri pentru adresă dacă formularul de abonare este pentru un serviciu online?

Cereți doar informațiile de care aveți nevoie. Și apoi cereți informațiile în context. Dacă aveți un site de comerț electronic, utilizatorii ar putea fi mai înclinați să vă dea adresa lor în secțiunea de expediere a procesului de finalizare a comenzii decât atunci când se înregistrează. Vă va face mult mai ușor de completat formularul de înregistrare pentru comerțul electronic de pe mobil!

De asemenea, nu aveți încredere orbește în fiecare statistică și studiu pe care îl găsiți pe Internet. Vă amintiți studiul de la 11 câmpuri la 4? Ei bine, un alt studiu mai recent a arătat că prin reducerea câmpurilor de la 9 la 6, conversiile au scăzut cu 14%. Șocant, nu-i așa? De ce? Ei bine, au eliminat cele mai captivante domenii. Pe scurt, s-au întors apoi la 9 domenii, l-au pus pe cel mai important pe primul loc și voilà, conversiile au crescut cu 19,21%.

Concluzia este că, deși aceste studii sunt interesante, acele site-uri web nu sunt site-ul dvs. Nu aveți încredere orbește în primul studiu pe care îl găsiți pe internet.

Deci, ce poți face? Test. Test. Și testați!

• Faceți câteva teste de utilizator pentru a vedea timpul până la completarea formularului dvs. mobil.
• Măsurați abandonul.
• Măsurați problemele cu anumite câmpuri.
• Măsurați frustrarea asociată cu anumite domenii. Cât de dispuși sunt utilizatorii să ofere aceste informații? Cât de personală este această informație?

Optimizarea interacțiunilor tactile

Realizarea comenzilor prietenoase cu atingerea

Dacă câmpurile dvs. sunt prea mici sau greu de atins, utilizatorii vor face erori și vor avea nevoie de interacțiuni suplimentare pentru a-și atinge obiectivele. Îți amintești legea lui Fitt? L-ați putea aplica și pentru designul mobil: faceți etichetele, câmpurile și comenzile de formulare ușor de atins prin creșterea dimensiunii țintei tactile . Pentru etichetele de pe web, puțin mai multă căptușeală poate crește zona de atingere. Uneori va trebui să adăugați și niște margini între elemente pentru a evita atingerile ratate.

De asemenea, nu uitați să legați etichetele cu componentele lor prin împerecherea valorilor for și ID. În acest fel, dacă utilizatorul ratează o atingere pe etichetă, câmpul corespunzător va fi în continuare focalizat.

Steven Hoober a efectuat câteva cercetări ale utilizatorilor asupra zonelor de atingere. Veți găsi un rezumat în „Designing for Touch”. Pe baza a ceea ce a descoperit, a construit un mic instrument de riglă de plastic: șablonul mobil tactil. Instrumentul vă poate ajuta să vă asigurați că zonele dvs. de atingere sunt suficient de mari pentru formularele mobile și, în general, pentru designul mobil.

Pentru a afla mai multe despre proiectarea pentru atingere, puteți citi următoarele:

• „Design prietenos cu degetele: dimensiuni ideale pentru ecranul tactil mobil”
• „Zona degetului mare: proiectare pentru utilizatorii de telefonie mobilă”

Furnizarea de feedback

Utilizatorii de dispozitive mobile nu au un mouse (nu glumesc), așa că nu primesc feedback-ul de „clic” pe care îl primesc utilizatorii de desktop atunci când apasă un buton. Utilizatorii formularelor mobile au nevoie de feedback clar atunci când interacționează cu elemente:

• Furnizați o stare de focalizare pentru câmpul de formular cu care interacționează utilizatorul.
• Oferiți feedback vizual atunci când utilizatorul interacționează cu un buton .

Nu sunt un mare fan al efectului de ondulare al designului material asupra butoanelor. Dar trebuie să recunosc că animațiile de pe Android oferă feedback clar atunci când utilizatorul interacționează cu un buton.

Onorați comanda butoanelor următoare și anterioară

În cele din urmă, onorați butoanele următor și precedent de pe tastaturile mobile. Utilizatorii le pot folosi pentru a naviga rapid în câmpuri. Ordinea tabindex ar trebui să se potrivească cu ordinea vizuală a câmpurilor și componentelor.

Evitați dropdown-urile pe mobil, dacă este posibil

Mențiunile derulante (elementul de selectare HTML) de pe web necesită o mulțime de file și interacțiuni. Prin urmare, așa cum a spus Luke Wroblewski, acestea ar trebui să fie UI de ultimă instanță. Multe alte componente ale UI funcționează mai bine decât meniurile derulante în multe situații.

Controalele segmentelor și butoanele radio sunt alternative bune la meniurile derulante dacă aveți între două și patru opțiuni. De ce să ascundeți opțiunile sub un meniu derulant când le puteți afișa pe toate direct pe un singur ecran? Rețineți că, la fel ca butoanele radio, controalele segmentului se exclud reciproc.

O listă de țări este un candidat bun pentru o componentă. Un meniu derulant de peste o sută de țări este un coșmar de interacțiune pe mobil. Este în regulă dacă cauți Afganistan (la începutul listei) sau Zimbabwe (sfârșitul listei). Dacă cauți Luxemburg, vei ajunge într-un joc de defilare pentru a ajunge la mijlocul listei, mergând prea departe la litera M, încercând să revii la L și așa mai departe.

Mențiunile derulante lungi pot fi înlocuite cu câmpuri de introducere a textului predictiv . Când utilizatorul începe să tasteze L, interfața va propune nouă țări. Dacă adaugă un U — voila! — Luxemburg este. Patru interacțiuni în loc de două, față de șase sau șapte interacțiuni de defilare cu meniul drop-down.

Dacă aveți nevoie ca utilizatorii să aleagă o dată, uitați să o împărțiți într-o listă drop-down de zi, lună și an, așa cum oamenii obișnuiesc să facă pe formularele de hârtie. Înlocuiți mai multe liste derulante de date cu un selector de date . type=date funcționează în majoritatea cazurilor. Dar s-ar putea să aveți anumite nevoi speciale și să ajungeți să vă construiți propriul selector de date în JavaScript, mai ales dacă vă ocupați de afacerea cu rezervări (hoteluri, mașini, zboruri).

În articolul său „Mobile DropDowns Revisited”, Klaus Schaefers explică modul în care utilizarea unui selector de date pentru datele de sosire și de plecare a făcut interacțiunile cu 60% mai rapide.

Să rămânem cu afacerea cu rezervări. Să presupunem că utilizatorul trebuie să adauge mai mulți călători la itinerarul său. Puteți ** înlocui meniul derulant * cu un * stepper** pentru a selecta numărul de pasageri. Un stepper este un control care permite utilizatorului să crească și să scadă valorile prin simpla atingere a butoanelor + și - . Acest lucru tinde să fie mai rapid atunci când trebuie adăugate mai puțin de șase persoane. De asemenea, este mai intuitiv. Mai jos este un exemplu de stepper folosit în aplicația Airbnb nativă pentru Android pentru a selecta oaspeții și pe site-ul web optimizat pentru mobil al Kayak pentru a adăuga pasageri.

O ultimă alternativă la meniurile derulante este vizualizarea listă. Opțiunile ar fi listate într-o anumită subvizualizare, ca butoane radio , de exemplu. Acesta este, în principal, modul în care funcționează setările Android.

Deveniți inteligent cu completarea automată

Dacă doriți să reduceți costul de interacțiune al formularului dvs., fiți inteligent. Nu cereți informații pe care le puteți detecta automat sau ghici pe baza altor informații pe care vi le-au oferit utilizatorii. Completați automat și completați în prealabil cât de mult puteți.

Locuri și Adrese

Dacă utilizatorul caută un loc sau trebuie să introducă o adresă, puteți oferi completare automată pentru a-l ajuta. Pe măsură ce scriu, un API va completa restul adresei pentru ei. Acest lucru reduce, de asemenea, erorile.

Ai putea folosi:

• API-ul Google Locații
• Algolia Places, care se bazează pe OpenStreetMap

În Franța și în multe alte țări, puteți ghici orașul pe baza prefixului. Așadar, dacă un utilizator francez introduce un prefix, ați putea completa automat automat sau măcar să propuneți orașul. Țara mea, Luxemburg, este mică (nu-ți bate joc de mine). Prefixul meu este legat de strada mea. Deci, dacă îmi introduc prefixul zonal, formularul ar trebui să poată chiar sugera strada mea.

Carduri de credit

Un alt domeniu în care detectarea automată este ușoară este cardurile de credit. Nu trebuie să întrebați utilizatorul ce tip de card de credit are. Puteți detecta automat acest lucru pe baza numerelor inițiale pe care le introduc. Există chiar și o bibliotecă care poate face treaba pentru tine.

Utilizarea completării automate HTML5 (completare automată)

Atributul de completare automată HTML poate precompleta câmpuri pe baza intrărilor anterioare ale utilizatorului. Acest atribut are o stare pornit și oprit. Unii oameni inteligenți au început să lucreze la o specificație pentru a face acest lucru mai puternic și pentru a extinde atributul de completare automată pentru câmpurile de formular. WHATWG are și o listă interesantă.

Chrome și alte browsere mobile acceptă deja unele dintre valorile extinse pentru cardurile de credit și nume. Aceasta înseamnă că utilizatorii pot completa formulare cu numele și datele cardului de credit pe care le folosesc pe alte site-uri web.

Pe scurt, atunci când trebuie să alegeți între sisteme diferite, numărați numărul de interacțiuni pe care le va necesita fiecare.

Se întâmplă greșeli: gestionarea erorilor în formularele mobile

Ultimul pas în călătoria noastră către formulare mobile mai bune este gestionarea erorilor și a greșelilor. Putem încerca să reducem greșelile pentru a ușura sarcina cognitivă a utilizatorului. De asemenea, îi putem ajuta să se recupereze din erori, deoarece, oricât de grozav este designul formularului, greșelile apar.

Evitarea erorilor la completarea formularelor

„Prevenirea este mai bună decât vindecarea”, spunea mama. Acest lucru este valabil și pentru designul formularelor: prevenirea erorilor va îmbunătăți experiența formularului dvs. mobil.

Limitare explicită de format

„Fii conservator în ceea ce faci. Fii liberal în ceea ce accepți de la alții.” Acest principiu de robustețe poate fi aplicat și câmpurilor de formulare. Dacă este posibil, permiteți utilizatorului să introducă date în orice format.

Dacă credeți că trebuie să limitați ceea ce poate introduce un utilizator în câmp, începeți prin a vă întreba „de ce”. În domeniul experienței utilizatorului, avem o tehnică numită „cele trei de ce”. Dacă răspunsul este „pentru că bla bla baza de date”, poate că este timpul să schimbăm lucrurile. De exemplu, de ce refuzați caracterele speciale precum e, a și o în câmpul numelui de utilizator? Am scris un articol în care explică cât de nepoliticos sunt formele pentru mine când încerc să introduc „Stephanie” ca nume de utilizator. Încă încerc să aflu un motiv bun pentru asta (în afară de motivele bazei de date).

Dacă aveți un motiv întemeiat să solicitați un anumit format de la utilizatori, menționați acest lucru înainte . Puteți folosi substituenți HTML5 pentru a oferi utilizatorilor un indiciu despre cum ar trebui să arate datele, dar, din nou, aveți grijă cu acestea. De asemenea, puteți utiliza toate tehnicile de descriere a câmpurilor explicate la începutul acestui articol. În cele din urmă, măștile de intrare pot ghida utilizatorii către formatul potrivit.

Marcarea câmpurilor obligatorii (și a celor opționale)

Nu așteptați ca utilizatorii să trimită un formular pe jumătate completat pentru a le spune despre câmpurile obligatorii. Dacă un câmp este obligatoriu, utilizatorii ar trebui să știe despre el . Marcarea câmpurilor obligatorii cu un asterix ( * ) și o legendă a devenit un model standard pentru formulare. Partea bună este că nu ocupă mult spațiu. Problema este că nu are valoare semantică, deci poate cauza probleme de accesibilitate dacă este codificat prost și dacă te bazezi pe obiceiurile oamenilor cu interacțiunea cu formularele.

În schimb, puteți marca în mod explicit atât câmpurile obligatorii, cât și cele opționale cu cuvintele „obligatoriu” (sau „obligatoriu”) și „opțional”. Atât Institutul Baymard, cât și Luke Wroblewski sunt de acord în acest sens. Acest lucru evită ambiguitatea cu formularele lungi pe mobil, cum ar fi atunci când utilizați un scroller, continuați cu altceva, apoi reveniți și nu vă amintiți dacă câmpurile obligatorii au fost marcate cu un asterisc sau altceva.

În cele din urmă, decizia cu privire la modul de marcare a acelor câmpuri va depinde de designul și lungimea câmpului și de context. Cel mai bun mod de a afla dacă ați luat decizia corectă este, din nou, să testați formularul.

Valori implicite sensibile

Fiți atenți la opțiunile implicite selectate în formulare . Când am aplicat pentru postul meu anterior, exista un formular de informații. Starea civilă era opțională. Ei au făcut ca primul element din meniul derulant, „divorțat”, câmpul implicit. Așadar, am putut fie să nu răspund (pentru că era un câmp opțional) și să las sistemul să creadă că am divorțat, fie să corectez acest lucru și să dezvălui starea mea civilă reală chiar dacă nu am vrut.

De asemenea, ai grijă la sex. Din nou, aveți o opțiune pentru persoanele care nu doresc să o dezvăluie; clarificați de ce îi cereți genul; mai bine, cereți pronume sau nu întrebați dacă nu aveți nevoie. If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don't auto-check the first choice, otherwise people won't be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• Când vă autentificați
  Într-un formular de conectare, o opțiune de masca/demascare a parolei ar îmbunătăți enorm experiența utilizatorului.
  Amazon are un istoric interesant de iterare a parolelor în formularul său de conectare. Avea o versiune în care nu puteai vedea parola. Următoarea iterație a permis utilizatorilor să o dezvăluie. Apoi, parola a fost dezvăluită în mod implicit și ați putea-o ascunde. Iată cum arată în 2015:

  

  Amazon a testat ultima versiune, iar 60% dintre oameni au fost suspicioși. Deci, au înlocuit caseta de selectare „Ascunde parola” cu o casetă de selectare „Afișează parola”. Aceasta ar afișa parola cu caractere mai mici, sub câmp, în timp ce utilizatorul tasta. Iată cum arată la momentul scrierii acestui articol:

  

  După cum puteți vedea, există întotdeauna loc de îmbunătățire.

Validare inline

Dacă sunteți familiarizat cu principiile de utilizare, s-ar putea să cunoașteți legea Gestalt a proximității. Pe mobil, evitați rezumatul erorilor din partea de sus a paginii, fără informații contextuale, după ce utilizatorul a apăsat butonul de trimitere.

În schimb, mesajele de eroare ar trebui să fie situate aproape de erorile în sine .

Validare în timp real

De asemenea, nu trebuie să așteptați până când utilizatorii apasă butonul de trimitere. Puteți valida câmpurile și afișa feedback în timp ce utilizatorul le completează .

Câteva sfaturi:

• După cum am menționat mai devreme, câmpurile de parolă ar beneficia de validarea în timp real și feedback-ul la fiecare apăsare a tastei.
• De asemenea, este posibil să doriți să validați numele de utilizator în timp real atunci când conturile sunt create, pentru a vă asigura că sunt disponibile. Twitter face o treabă bună în acest sens.
• Nu validați fiecare apăsare a tastei. Așteptați până când utilizatorul a terminat de tastat. (Utilizați blur JavaScript pentru formularele web sau așteptați doar câteva secunde pentru a detecta inactivitatea.)

Notă : *Mihael Konjevic a scris un articol frumos despre „Validarea inline în formulare: proiectarea experienței”. El explică conceptul de „ recompensează devreme, pedepsește târziu .”*

„Dacă utilizatorul introduce datele în câmpul care era într-o stare validă , efectuați validarea după introducerea datelor.”

„Dacă utilizatorul introduce datele în câmpul care era într-o stare nevalidă , efectuați validarea în timpul introducerii datelor.”

Culoarea contează

Nu spun că culoarea contează doar din cauza culorii mele actuale de păr ghimbir, roz și violet. Culoarea contează cu adevărat în designul formei.

Există unele convenții pe web pe care nu doriți să le încălcați. Utilizatorii non-daltonişti știu că roșu este pentru erori, galben pentru avertismente și verde este aproape întotdeauna pentru confirmare sau succes. Cel mai bine este să rămâneți cu aceste trei culori. Cu toate acestea, roșul poate face oamenii anxioși. Utilizatorul ar putea crede că a făcut o greșeală foarte gravă. Utilizarea portocaliului sau galbenului pentru mesajele de eroare poate provoca mai puțină panică. Problema cu galbenul și portocaliul este că este greu să le găsești nuanțe prietenoase cu daltonii.

Vorbind despre daltonism: culoarea nu ar trebui să fie singura modalitate de a transmite un mesaj de eroare . Acesta este un criteriu de accesibilitate.

În exemplul de mai jos din stânga, câmpul cu o eroare este portocaliu, iar câmpul care a fost corectat a devenit verde. Am folosit un instrument de testare al daltonismului pentru a face captura de ecran din mijloc: nu mai puteți face distincția între chenarul gri implicit și cel verde. Adăugarea unor pictograme în ultima captură de ecran asigură că mesajele de eroare sunt transmise persoanelor daltoniste.

Recuperarea din erori: scrierea mesajelor de eroare ușor de utilizat

În acest moment, am făcut tot ce am putut pentru a ajuta utilizatorii să completeze formularele noastre și să evite erorile. Dar uneori, în ciuda eforturilor noastre, se întâmplă greșeli. Este timpul să ne dați seama cum să ajutați utilizatorii să se recupereze de aceste greșeli.

În primul rând, amintiți-vă: nu deturnați controlul sistemului. Dacă o problemă nu este critică, utilizatorul ar trebui să poată continua să interacționeze cu cât mai mult restul interfeței posibil. Evitați acele mesaje de eroare de alertă JavaScript și modal care blochează utilizatorii ori de câte ori este posibil. De asemenea, dacă formularul dvs. are nevoie de o anumită permisiune, solicitați-l în fluxul de utilizare. Dacă permisiunea nu este acordată, nu considerați aceasta o eroare, deoarece nu este. Aveți grijă la copia pe care o utilizați aici.

Nu ești un robot și nici utilizatorii tăi

Roboții sunt cool, știu. Dar nu ești un robot și nici utilizatorii tăi. Cu toate acestea, atât de multe mesaje de eroare sunt încă atât de prost scrise. Iată câteva sfaturi când vine vorba de mesaje de eroare prietenoase cu oamenii:

• Nu afișa niciodată un mesaj de eroare brut, cum ar fi „A apărut o eroare de tip 2393. Serverul nu a putut finaliza operațiunea.” În schimb, explicați ce s-a întâmplat în limbajul uman și de ce s-a întâmplat .
• Nu afișa niciodată un mesaj de eroare fără margini, cum ar fi „A apărut o eroare”. În schimb , sugerați modalități de recuperare după eroare . Scrieți o copie acționabilă.
• Nu afișa niciodată un mesaj de eroare vag, cum ar fi „Un server cu numele de gazdă specificat nu a putut fi găsit”, cu un buton „Încercați din nou”. În schimb, faceți mesajele de eroare informative și coerente . Te rog, nu suna ca un robot.
• Nu presupuneți că oamenii cunosc contextul unui mesaj. Utilizatorii tăi nu sunt cunoscători de tehnologie. În schimb, explicați-le într-un limbaj simplu, fără jargon tehnic, cum să vă recuperați din această eroare .

Atenție la limba pe care o utilizați în mesaje

Orice ai scrie, evita să-i faci pe oameni să se simtă proști în legătură cu o greșeală. Dacă este posibil, omiteți cuvintele negative ; au tendința de a speria oamenii și de a-i face și mai anxioși. Utilizați în schimb un ton politicos, pozitiv și afirmativ.

Nu da vina pe utilizatori pentru greșeli ; da vina pe sistem în schimb. Sistemul nu va ține ranchiună, promit. Îndreptați atenția utilizatorului asupra modului în care sistemul nu a putut procesa acțiunea și explicați-i cum să găsească o soluție .

Un mic truc este să -ți citești propriul mesaj cu voce tare. Vă va ajuta să auziți dacă funcționează sau este prea dur sau prea casual etc.

De asemenea, puteți deveni creativ cu mesaje de eroare și puteți include imagini și umor pentru a le face mai puțin amenințătoare. Totuși, asta va depinde într-adevăr de identitatea și tonul mărcii tale.

Pentru a vă ajuta să scrieți un mesaj de eroare mai bun, vă sugerez să citiți următoarele:

• „O listă de verificare pentru microcopii în 6 puncte pentru echipele de produse fără scriitori UX”
• „Arta mesajului de eroare: scrierea unei copii clare și utile pentru când lucrurile merg prost”

Timpul pentru a trimite formularul

Utilizatorul a completat formularul, nu mai există erori și totul arată bine. În sfârșit, este timpul să trimiteți formularul!

Prima regulă este să nu mascați butonul de trimitere . Serios! Mă întreb ce minte întortocheată a venit cu această idee, dar am văzut-o în unele forme. Butonul de trimitere va fi afișat numai după ce toate câmpurile obligatorii au fost completate fără erori. Este deranjant pentru utilizator să se întrebe dacă ceva nu este în regulă sau butonul formularului nu s-a încărcat sau site-ul web este stricat și așa mai departe.

Dacă nu doriți ca utilizatorii să poată apăsa butonul de trimitere dacă lipsesc câmpuri obligatorii sau există erori de validare, utilizați atributul HTML disabled pe intrarea de submit . Va trebui să reactivați butonul folosind JavaScript odată ce formularul este valid și gata pentru trimitere.

Dacă aveți un îndemn principal și secundar, utilizați culoarea, dimensiunea și stilul pentru a afișa ierarhia .

Dacă vă întrebați dacă butonul de confirmare ar trebui să apară înainte sau după butonul de anulare, la fel și eu (și mulți alți oameni). Dacă construiți o aplicație nativă, respectați regulile sistemului de operare. A devenit deosebit de distractiv de când Android a schimbat pozițiile butoanelor în a patra versiune. Pe web, este mai complicat pentru că nu există linii directoare reale. Indiferent de sistemul de operare, iată câteva recomandări generale pentru butoanele de trimitere optimizate pentru dispozitive mobile:

• Dați chemare la acțiune verbe descriptive, acționabile.
• Oferiți feedback vizual atunci când utilizatorul îl atinge.
• Dacă aveți două butoane, scoateți în evidență acțiunea principală .
• Cu excepția cazului în care lucrați la un formular de întreprindere back-office foarte specific (caz în care veți avea multe provocări optimizarea pentru mobil), evitați un buton de resetare . Utilizatorii l-ar putea confunda cu butonul de trimitere și își vor pierde toate datele din întâmplare.

Concluzie

În această primă parte, am discutat o mulțime de tehnici mici pentru a vă duce formularul la nivelul următor și pentru a ajuta utilizatorii să îl completeze. Unele dintre aceste îndrumări generale și cele mai bune practici mobile ar putea să nu funcționeze 100% din timp - aceasta este problema cu cele mai bune practici. Așadar, testați-vă întotdeauna formularele pe utilizatori reali și pe dispozitive reale și adaptați regulile la nevoile și experiența specifice ale utilizatorilor dvs.

De asemenea, faceți o regresie și teste funcționale automatizate - din nou, pe dispozitive reale. Emulatorul mobil Chrome nu va fi suficient pentru a testa formulare optimizate pentru atingere. Spun asta pentru că am lansat un site de comerț electronic cu un formular de căutare care nu funcționa pe mobil. Am făcut doar teste automatizate folosind un emulator. Iată ce sa întâmplat. Formularul de căutare a fost ascuns sub o pictogramă de căutare. Puteai apăsa pe butonul, care deschidea o casetă cu câmpul de căutare. A funcționat prin emularea unui hover mouse-ului ca eveniment tactil. Am testat atingerea butonului și a deschis cutia. Nimeni nu a încercat să lanseze o căutare. Așadar, nimeni (nici măcar clientul) nu a văzut că câmpul de căutare a dispărut imediat ce utilizatorii au încercat să interacționeze cu el. Ce s-a întâmplat? Când elementul de intrare a fost focalizat, butonul a pierdut starea de hover, așa că a închis caseta cu câmpul. Testarea automată nu a reușit să surprindă acest lucru, deoarece intrarea nu și-a pierdut focalizarea. Așadar, am lansat un site de comerț electronic fără funcționalitate de căutare pe mobil. Nu o experiență super.

În a doua parte a acestei serii, vom vedea tehnici mai avansate specifice pentru mobil. Vom vedea cum să folosim funcțiile HTML5 interesante pentru a formata câmpurile și cum să folosim capabilitățile mobile pentru a duce experiența utilizatorului mobil la nivelul următor.