Kanon formularzy: każde pole to pytanie

Formularz to moment, w którym interfejs przestaje prezentować, a zaczyna pytać. Każde pole jest pytaniem postawionym komuś, kto wolałby robić coś zupełnie innego — dlatego każde zbędne pole jest natręctwem, a każde niejasne drobną zdradą. Rzemiosło formularzy da się sprowadzić do kanonu, który mieści się w głowie: pytać mniej, w jednej kolumnie, z widocznymi etykietami; przyjmować odpowiedzi w takiej postaci, w jakiej ludzie naturalnie ich udzielają; uruchamiać walidację wtedy, gdy użytkownik kończy myśl, a nie w połowie wpisywania; pisać komunikaty błędów, które mówią, jak naprawić problem; i pod żadnym pozorem nie wyrzucać tego, co zostało wpisane. Większość tarcia, jakie formularze wywołują w praktyce, to złamanie którejś z tych zasad. {.answer-block}

TL;DR

• Formularz to rozmowa, więc pytać trzeba tak, jak zapytałby człowiek: możliwie najmniej pytań, w jednej uporządkowanej kolumnie, pogrupowanych tematycznie — a każde pole musi się obronić wobec kosztu zadania pytania.
• Kwestia układu jest rozstrzygnięta: jedna kolumna, etykiety nad polem, szerokość pola podpowiadająca długość odpowiedzi. Formularze wielokolumnowe i sztuczki z etykietami pływającymi wymieniają realne zrozumienie na wyobrażoną elegancję.
• Odpowiedzi należy przyjmować w takiej formie, w jakiej ludzie ich udzielają. Obciąć przypadkową spację, przyjąć numer telefonu w dowolnym formacie, zachować pole w całości zamiast dzielić je na trzy okienka — normalizacja to zadanie oprogramowania, nie użytkownika.
• Walidacja po opuszczeniu pola, nie po każdym naciśnięciu klawisza, a komunikaty błędów mają uczyć: co poszło nie tak, jak to naprawić, tuż obok pola, którego dotyczy.
• To, co wpisał użytkownik, jest święte. Nieudane wysłanie, które czyści formularz, albo wyłączony przycisk, który nie zdradza dlaczego, zamienia chętnego uczestnika w byłego.

Dlaczego każde pole jest pytaniem

Wystarczy potraktować formularz jako zapis rozmowy, a jego jakość staje się czytelna. Czy kompetentny rozmówca z przyzwyczajenia pytałby o numer faksu? Żądał daty urodzenia, zanim wyjaśni po co? Przerywał w połowie literowania adresu e-mail, żeby ogłosić, że jest nieprawidłowy? Zapominał wszystko, co usłyszał, bo w kodzie pocztowym pojawiła się spacja? Każde z tych zachowań ma swój odpowiednik w formularzach działających na produkcji, a użytkownicy odbierają je dokładnie tak, jak odebraliby rozmówcę: jako grubiaństwo.

Z tego ujęcia bierze się też pierwsza i najważniejsza reguła, wyprzedzająca cały układ i całą stylistykę: każde pole musi uzasadnić swoje istnienie wobec kosztu zadania pytania. Każde dodatkowe pytanie podnosi odsetek porzuceń; każda zebrana odpowiedź to dane, które trzeba odtąd przechowywać, chronić i za które trzeba odpowiadać. Najsilniejszym ruchem w projektowaniu formularzy jest usunięcie — pole, które zniknie, bije każdą politurę, jaką dałoby się na nie nałożyć. Kanonicznym dowodem jest przypadek Expedii: usunięcie jednego opcjonalnego pola „Company” z formularza rezerwacji było podobno warte około 12 milionów dolarów rocznie — klienci wpisywali tam nazwę swojego banku, a potem nie przechodzili weryfikacji adresu. Jedno pole, uczciwie przepytane, wygrało z każdym przeprojektowaniem. „Opcjonalne” nie jest uzasadnieniem; to mniejsze natręctwo, ale wciąż natręctwo. Warto pytać o to, czego wymaga sfinalizowanie transakcji, oznaczyć nieliczne opcjonalne pole jako opcjonalne, a całą resztę przenieść na później, gdy relacja na to zapracuje. (Obóz przeciwny woli opatrzyć gwiazdką każde pole wymagane; gdy wymagane jest niemal wszystko, gwiazdki stają się tapetą.)

Reguły układu

Układ formularza to jeden z niewielu zakątków projektowania, w których dowody są w zasadzie rozstrzygnięte, więc odstępstwo jest wyborem przeciwko użytkownikowi:

Jedna kolumna. Formularz to sekwencja pytań, a pojedyncza kolumna czyni tę sekwencję jednoznaczną: odpowiedz, zejdź niżej, skończ. Układ wielokolumnowy wymusza w każdym wierszu decyzję o kolejności czytania — w poprzek czy w dół? — a ludzie rozstrzygają ją niekonsekwentnie i pomijają pola, których w ogóle nie zobaczyli. W najbardziej znanym porównaniu eyetrackingowym te same pola w jednej kolumnie wypełniano około piętnastu sekund szybciej niż rozbite na dwie. Wyjątkiem są prawdziwe złożenia, czytane jako jedna odpowiedź: miasto / województwo / kod pocztowy w jednym wierszu, data w trzech częściach. To jedno pytanie przebrane za trzy pola, a nie trzy pytania.

Etykiety nad polem, zawsze widoczne. Etykiety obok pola tworzą poszarpaną drogę wzroku; etykiety wewnątrz pola (placeholder w roli etykiety) znikają dokładnie w chwili, gdy użytkownik zaczyna pisać — czyli wtedy, kiedy są najbardziej potrzebne: w połowie długiego formularza każde wypełnione pole zamienia się w zagadkę „o co tu właściwie pytano”. Etykiety pływające, ten animowany kompromis, przetrwają wprawdzie fokus, ale kurczą się do rozmiaru podpisu i sprawiają, że puste pola wyglądają na wypełnione: łagodniejsza wersja tej samej wymiany, wciąż opłacana zrozumiałością. Placeholder służy podpowiedzi formatu („[email protected]”), nigdy samemu pytaniu.

Szerokość pola niesie informację. Pole na kod pocztowy równie szerokie jak pole adresu kłamie o kształcie odpowiedzi. Dobieranie rozmiaru pól do spodziewanej treści — krótkie dla kodów pocztowych, długie dla adresów — to to samo rzemiosło co odstępy kodujące grupowanie: geometria, która komunikuje po cichu.

Grupować tematycznie i pozwolić, by grupowała przestrzeń. Kontakt, dostawa, płatność — skupiska powiązanych pytań z wyraźnymi szwami pomiędzy nimi, a szwy zrobione ze światła, nie z ramek czy linii. Formularz czytany jako trzy małe tematy jest psychologicznie mniejszy niż te same pola w jednej niezróżnicowanej płycie.

Reguły wprowadzania danych

Motyw projektowania pól mieści się w jednym zdaniu: normalizacja to zadanie oprogramowania. Jakikolwiek ciężar formatowania się pojawi, dźwiga go maszyna, bo to maszynie na formacie zależy.

• Przyjmować niechlujne odpowiedzi. Obcinać białe znaki — końcowa spacja z autouzupełnionego adresu e-mail zniweczyła więcej logowań, niż jej się należy. Przyjmować numery telefonu z myślnikami, kropkami, spacjami, nawiasami albo bez niczego. Akceptować numer karty z przerwami i bez nich. Jeśli da się to sparsować, trzeba to sparsować; odrzucenie 555 867 5309, bo chciało się 5558675309, to zmuszanie użytkownika, żeby ręcznie wykonał kod formatujący ciągi znaków.
• Nigdy nie dzielić tego, co dla użytkownika jest jedną rzeczą. Numer telefonu w trzech okienkach, data w trzech listach rozwijanych, kod weryfikacyjny w sześciu jednoznakowych komórkach z własnoręcznie napisanym przeskokiem fokusu — każde z tych rozwiązań rozbija jedną myślową odpowiedź na łamigłówkę nawigacyjną i zwykle psuje wklejanie, najskuteczniejszą metodę wprowadzania danych, jaką dysponuje użytkownik. (Wyjątek dla złożeń z reguł układu pozostaje w mocy: data w trzech wpisywanych częściach jest w porządku — grzechem jest ceremoniał list rozwijanych i skradziony fokus, a nie sąsiedztwo. A dla kodów trwałą odpowiedzią jest jedno pole z autocomplete="one-time-code".)
• Przywołać właściwą klawiaturę. Na urządzeniach dotykowych type="email", inputmode="numeric" i pokrewne atrybuty decydują o tym, czy ktoś wpisuje adres na klawiaturze do tego stworzonej, czy poluje na @ w warstwach symboli. Kosztuje to jeden atrybut.
• Pozwolić przeglądarce pomóc. Poprawne wartości autocomplete zamieniają dwunastopolowy proces zakupu w dwa dotknięcia dla powracającego klienta. Wyłączanie autouzupełniania w polach adresowych i płatniczych — zwykle zabobon odziedziczony po audycie bezpieczeństwa, który nigdy się nie odbył — wyrzuca największe pojedyncze przyspieszenie dostępne formularzowi.
• Wyjść palcowi naprzeciw tam, gdzie ląduje. Pola, ich przyciski i wszystko inne, co da się dotknąć, zachowują minimalny obszar dotyku platformy — 44 pt w iOS, 48 dp w Androidzie. Zwarte, eleganckie pole, w które kciuk nie trafia niezawodnie, to formularz desktopowy przebrany za telefon.

Reguły dotyczące klawiatury i autouzupełniania kosztują razem kilka atrybutów:

<input type="tel" autocomplete="tel">              <!-- phone keypad, autofilled -->
<input inputmode="numeric" autocomplete="one-time-code">  <!-- digit pad, code autofills -->

Reguły walidacji

Moment walidacji to miejsce, w którym formularze najczęściej stają się wrogie, a reguła jest prosta: odpowiadać wtedy, gdy użytkownik skończy myśl. Uruchamianie jej po każdym naciśnięciu klawisza oznacza krzyczenie „nieprawidłowy e-mail!” do kogoś, kto wpisał dopiero cztery znaki — krytykowanie zdań, zanim się skończą. Szkoła przeciwna waliduje wyłącznie przy wysyłce i ma poważnego obrońcę: system projektowy GOV.UK robi dokładnie to, łącząc wysłanie formularza z podsumowaniem błędów na górze strony, ponieważ podsumowanie da się odczytać czytnikom ekranu i daje osobom korzystającym z klawiatury jedno miejsce, od którego zaczynają poprawki. To spójne stanowisko, dostrojone do usług, w których dostępność stanowi ograniczenie wiążące. W przypadku większości formularzy produktowych mimo to obstaję przy walidacji po opuszczeniu pola: użytkownik kończy pole, idzie dalej i dostaje informację zwrotną na szwie między myślami, dopóki myśl jest jeszcze ciepła. (Jedno doprecyzowanie: pole już uznane za nieprawidłowe może być sprawdzane ponownie po każdym klawiszu, żeby czerwony stan znikał w chwili naprawy, a nie z opóźnieniem całego pola.)

Pisanie komunikatów o błędach przechodzi ten sam test rozmowy. Błąd nie jest wyrokiem, tylko instrukcją naprawy. „Nieprawidłowe dane” tego testu nie zdaje — nieprawidłowe pod jakim względem? „W tym adresie e-mail brakuje @” zdaje. (A instrukcja musi być zgodna z rzeczywistą regułą: numery kart mają zgodnie z prawem od 12 do 19 cyfr, więc „musi mieć 16 cyfr” nie jest komunikatem błędu, tylko usterką walidacji odrzucającą każdego posiadacza karty Amex). Komunikat trzeba umieścić przy polu, którego dotyczy, i to tekstem — sam kolor wyklucza osoby z zaburzeniami widzenia barw, a tekst jest jedynym kanałem, jaki widzi czytelnik, który niczego nie renderuje — oraz powiązać go programowo z polem (aria-describedby), aby technologie wspomagające odczytywały błąd razem z polem, zamiast zostawiać go osamotnionego na ekranie. Ton ma pozostać rzeczowy: zadaniem formularza jest przeprowadzić użytkownika przez proces, a nie rozstrzygać o winie. Cała reguła w jednej parze:

<!-- before: a verdict, visually nearby, programmatically stranded -->
<label for="email">Email</label>
<input id="email" type="email">
<span class="error">Invalid input</span>

<!-- after: a repair instruction, announced with its field -->
<label for="email">Email</label>
<input id="email" type="email"
       aria-invalid="true" aria-describedby="email-err">
<span id="email-err">This email address is missing its @</span>

Zestaw domykają dwie reguły strukturalne. Nigdy nie wyłączać przycisku wysyłania jako strategii walidacji — martwy przycisk bez wyjaśnienia jest zagadką, a następnym ruchem użytkownika jest wyjście; lepiej pozwolić wysłać, a potem precyzyjnie pokazać, co wymaga uwagi. (Wyłączenie na czas trwającego wysyłania, żeby zapobiec podwójnemu obciążeniu karty, to co innego: to stan, nie ocena). I najgłębsze prawo kanonu: nieudane wysłanie zachowuje każde naciśnięcie klawisza włożone w pracę. Formularz, który czyści się po błędzie, zabrał komuś kilka minut wysiłku i spalił je na jego oczach. Z tego nie podnosi żadne dopracowanie wizualne.

Kanon jako lista kontrolna

Robocza postać wszystkiego powyższego, do przyłożenia do każdego formularza przed wdrożeniem:

W systemie projektowym te reguły twardnieją w samych komponentach formularza — pole tekstowe dostarczane ze slotem etykiety u góry, slotem błędu na dole i wbudowanym momentem walidacji — więc kanon obowiązuje domyślnie, a dryf wymaga wysiłku. To ten sam argument za systematyzacją co przy tokenach ruchu: zakodować decyzję raz albo rozstrzygać ją od nowa w każdej funkcji.

Często zadawane pytania

Czy formularz powinien mieć jedną kolumnę, czy dwie?

Jedną. Pojedyncza kolumna czyni kolejność odpowiadania jednoznaczną i mierzalnie skraca czas wypełniania; układy wielokolumnowe powodują pomijanie pól, bo użytkownicy niekonsekwentnie rozstrzygają kolejność czytania. Wyjątkiem jest odpowiedź złożona — miasto / województwo / kod pocztowy — czyli jedno pytanie wyrażone w sąsiadujących polach.

Kiedy powinna uruchamiać się walidacja formularza?

Po opuszczeniu pola — gdy użytkownik z niego wychodzi — a nie po każdym naciśnięciu klawisza; w przypadku większości formularzy produktowych także nie z odłożeniem do momentu wysyłki. Walidacja po klawiszu krytykuje niedokończone odpowiedzi; walidacja wyłącznie przy wysyłce zrzuca wszystkie niepowodzenia naraz, choć podsumowanie błędów GOV.UK po wysłaniu jest właściwym wyborem tam, gdzie odczyt przez czytnik ekranu stanowi ograniczenie wiążące. Pole już oznaczone jako nieprawidłowe może być sprawdzane po każdym klawiszu, żeby błąd znikał natychmiast po poprawce.

Czy można użyć placeholdera jako etykiety pola?

Nie. Placeholder w roli etykiety znika, gdy tylko użytkownik zacznie pisać, czyli dokładnie wtedy, gdy musi sobie przypomnieć pytanie, a przy przeglądaniu zamienia każde wypełnione pole w dane bez opisu. Nad polem należy zostawić widoczną etykietę, a placeholder zarezerwować na przykłady formatu.

Czy przycisk wysyłania powinien być wyłączony, dopóki formularz nie jest poprawny?

Nie. Wyłączona wysyłka bez wyjaśnienia to ślepy zaułek, który użytkownik musi sam zdiagnozować. Przycisk ma pozostać aktywny, a po wysłaniu każde nierozwiązane pole powinno zostać pokazane z konkretnym, instruktażowym komunikatem obok — przy zachowaniu wszystkiego, co już zostało wpisane.