Ludzie nie powinni rozwiązywać zagadki interfejsu
Wyobraź sobie formularz zapytania o projekt witryny. Odwiedzający opisuje zadanie, dodaje kontakt i naciska wyślij, po czym widzi jedynie czerwony obrys. Czy brakuje numeru telefonu, połączenie zawiodło, a może zapytanie już wysłano? Ta niepewność jest problemem projektu, nie brakiem uwagi. Użyteczna makieta powinna obejmować niepełne dane, wiele błędów, oczekiwanie i powodzenie, nie tylko idealnie wypełniony formularz. Te drobne stany decydują, czy cała droga ma sens.
Wyjaśnij, czego potrzebuje pole
Każde pole potrzebuje zrozumiałej etykiety; WAI zaleca powiązanie jej z elementem sterującym. Przykład formatu nie zastępuje etykiety. W naszym wymyślonym briefie numer telefonu mógłby być oznaczony jako opcjonalny, gdy wystarcza e-mail. Nie należy żądać pełnego adresu firmy wyłącznie z przyzwyczajenia, jeśli nie służy niczemu w pierwszej rozmowie. Przed narysowaniem formularza wypisz pola i wyjaśnij, dlaczego każde istnieje. Jeśli pole nie ma jasnego celu, przemyśl je ponownie. W3C WAI: Etykietowanie elementów sterujących
Nazwij rzeczywisty problem
Wykryte błędy potrzebują opisu tekstowego wskazującego odpowiednie pole; sam kolor nie wystarcza. Zamiast niejasnego komunikatu o nieprawidłowych danych przy brakującym kontakcie można napisać „Dodaj adres e-mail”. Dla naszego formularza przygotuj osobne komunikaty o pustym kontakcie, niepełnym opisie i niedostępnej usłudze. Połączenie ich w jeden czerwony baner ukrywa ważną różnicę: poprawienie danych i poradzenie sobie z nieudanym wysłaniem wymagają innych działań. W3C: Identyfikacja błędów
Zaproponuj drogę naprawy
Jeśli poprawka jest znana i można ją bezpiecznie zasugerować, wyjaśnij ją. Gdy pole ma konkretny limit długości, opisz ograniczenie zamiast prosić o ponowną próbę. W dłuższym formularzu podsumowanie błędów z linkami do odpowiednich pól może uzupełniać wskazówki obok nich. Unikaj komunikatów zasłaniających wpisany tekst. Przejdź proces z klawiaturą: osoba powinna móc znaleźć problem, poprawić go i kontynuować bez przepisywania całego briefu projektu. W3C: Sugestie korekty błędów
Walidacja nie oznacza dostarczenia
Walidacja w przeglądarce nie zastępuje walidacji na serwerze. Poprawnie sformatowany adres również nie dowodzi, że wiadomość dostarczono. Komunikat o wyniku powinien odpowiadać rzeczywistej odpowiedzi systemu. W naszym przykładzie zapisanie zapytania różni się od nieudanego wysłania. Nie obiecuj telefonu w ciągu pięciu minut, jeśli taki proces faktycznie nie istnieje. Powtórne kliknięcia, wolne połączenie i ponowne otwarcie strony traktuj jako odrębne sytuacje zamiast zakładać, że każde żądanie przebiega idealnie. MDN: Walidacja formularzy po stronie klienta
Testuj więcej niż powodzenie
WAI zaleca komunikaty zarówno dla udanych, jak i nieudanych wysłań. Przed uruchomieniem wypróbuj pusty formularz, jeden nieprawidłowy kontakt, długi opis, poprawkę, powodzenie i awarię usługi. Sprawdź powiększony tekst, telefon i nawigację klawiaturą; dostępność wymaga też testów z technologią asystującą. Ta krótka lista nie jest certyfikacją. To praktyczny sposób sprawdzenia, czy formularz pomaga ludziom iść dalej, zamiast pozostawiać im interpretację niewyjaśnionej czerwonej ramki. W3C WAI: Powiadomienia dla użytkowników