UX i HTML5: Pomóżmy użytkownikom wypełnić formularz mobilny (część 1)

Formularze to jedna z najbardziej podstawowych interakcji użytkowników z Twoimi witrynami (i aplikacjami mobilnymi). Łączą ludzi i pozwalają im się komunikować. Pozwalają im komentować artykuły i wyjaśniać autorowi, jak bardzo nie zgadzają się z tym, co napisali. Pozwalają ludziom rozmawiać bezpośrednio w aplikacji randkowej, aby poznać „tego jedynego”. Niezależnie od tego, czy chodzi o fora, zamówienia produktów, społeczności internetowe, tworzenie kont czy płatności online, formularze stanowią dużą część życia online użytkowników.

Jest rok 2018 i na całym świecie mamy więcej użytkowników mobilnych niż komputerów stacjonarnych . Mimo to nadal traktujemy tych użytkowników jako obywateli sieci drugiej kategorii. Wszyscy cały czas piszą i mówią o doświadczeniach użytkownika. Dlaczego, dlaczego, dlaczego tak wiele stron internetowych i produktów nadal robi to źle. Dlaczego wrażenia z korzystania z urządzeń mobilnych są uszkodzone na pół świata? Dlaczego nadal jest to uciążliwe, dlaczego dziś nadal jest bardzo trudno zarezerwować lot i zarejestrować konto w formie mobilnej? Użytkownicy oczekują lepszego!

Zalecana literatura : World Wide Web, Not Wealthy Western Web

To pierwsza część serii dwóch artykułów. W tym artykule podsumuję kilka podstawowych dobrych praktyk, które pomogą ulepszyć formularze mobilne, w tym skanowalność i czytelność. Przeprowadzę Cię przez rozmieszczenie, rozmiar i optymalizację etykiet i danych wejściowych. Zobaczymy, jak dobrać odpowiedni element formularza, aby obniżyć koszty interakcji. Na koniec dowiesz się, jak zapobiegać i radzić sobie z błędami w formularzach mobilnych.

W drugiej części przyjrzę się bliżej konkretnym możliwościom mobilnym i elementom formularzy HTML5, a także wyjdziemy poza klasyczne elementy formularzy, aby tworzyć unikalne i przyjemne aplikacje internetowe i strony internetowe.

Uwaga : chociaż większość ulepszeń kodu w tym artykule dotyczy sieci (ponieważ nie znam języka Swift ani Java), najlepsze praktyki użyteczności odnoszą się do aplikacji mobilnych .

Projektowanie formularzy 101: Nadawanie priorytetów skanowalności i czytelności

„Formularz to nazwa, wartość, pary w strukturze służącej do przechowywania danych na komputerze, wykradzionych człowiekowi jako etykiety i pola wejściowe”. To bezpośredni cytat z konferencji Łukasza Wróblewskiego. Podobnie jak on uważam, że większość problemów związanych z użytecznością formularzy wynika z tej tendencji do obsługi struktury bazy danych użytkownikom.

Silna architektura informacji

Aby zbudować lepsze formularze, musisz najpierw zrobić kilka kroków od struktury swojej bazy danych. Spróbuj zrozumieć, jak użytkownicy chcą wypełniać formularze. W tym miejscu przydatne staje się przeprowadzanie testów użyteczności i badań użytkowników na formularzach. Modele mentalne użytkownika to koncepcja UX, która może Ci w tym pomóc. Nielsen Norman Group opisuje to jako „co użytkownik sądzi o posiadanym systemie”. Poproś testera, aby pomyślał na głos i powiedział, jak wypełniłby formularz. Jakich kroków oczekują? Co jest pierwsze? Co jest następne? Daje to lepsze wyobrażenie o tym, jak ustrukturyzować formularz w bardziej przyjazny dla użytkownika sposób.

Wizualne grupowanie pól, które należą do siebie, również pomoże użytkownikom wypełnić formularz. W kodzie użyj tagu fieldset , aby programowo je pogrupować. Pomoże to również czytnikom ekranu zrozumieć hierarchię.

Jeśli formularz jest długi, domyślnie nie ujawniaj wszystkiego . Bądź mądry w tym, co wyświetlasz. Mądrze używaj rozgałęzień, aby wyświetlać tylko te pola, których ludzie potrzebują. Na przykład w formularzu kasy nie wyświetlaj wszystkich szczegółowych pól dla wszystkich opcji wysyłki. To przytłoczy użytkownika. Wyświetlaj wystarczającą ilość informacji, aby pomóc im wybrać odpowiednią opcję wysyłki. Następnie wyświetl tylko szczegóły i pola związane z tym wyborem.

Okresy uwagi użytkownika skracają się z czasem: Poproś o opcjonalne elementy na końcu formularza. Na przykład, jeśli Twój formularz jest ankietą satysfakcji klienta, poproś o informacje demograficzne na końcu. Jeszcze lepiej, jeśli to możliwe, wypełnij je automatycznie. Pytaj użytkowników tylko o to, co jest konieczne.

Na koniec zaplanuj lokalizację z wyprzedzeniem: co się stanie, gdy Twój formularz zostanie przetłumaczony? Co się stanie, powiedzmy, z niemieckim? Czy Twój projekt nadal będzie działał?

Umieszczanie etykiet i optymalizacja danych wejściowych

Układ jednokolumnowy działa najlepiej

Ze względu na brak miejsca nie otrzymujesz nieskończonych możliwości umieszczania etykiet i pól na ekranach telefonów komórkowych:

• Prezentuj pola w układzie jednokolumnowym . W telefonie komórkowym nie ma miejsca na wiele kolumn. Wielokolumnowe formularze i tak nie są dobrym pomysłem na komputerze.
• W trybie pionowym lepiej jest umieścić etykietę na górze pola , aby użytkownicy mogli zobaczyć, co jest w polu podczas pisania.

• W trybie poziomym wysokość ekranu jest zmniejszona. Możesz umieścić etykiety po lewej stronie, a wejścia po prawej . Ale przetestuj to, aby upewnić się, że działa.

Więcej informacji na temat umieszczania etykiet można znaleźć w artykule Baymard Institute „Użyteczność formularzy mobilnych: umieszczanie etykiet nad polem”.

Etykiety powinny być wyraźne i widoczne oraz działać bez kontekstu

Pamiętaj, że gdy tylko pole zostanie uaktywnione, klawiatura się otworzy i zajmie co najmniej jedną trzecią obszaru ekranu. Na małych ekranach mobilnych użytkownicy będą również musieli przewijać, aby wypełnić formularz. Oznacza to, że podczas wypełniania formularza stracą część kontekstu. Zaplanuj odpowiednio:

• Twoje etykiety powinny być wyraźnym, widocznym tekstem, który można odczytać i zrozumieć bez kontekstu. Użytkownik powinien mieć możliwość uzupełnienia każdej pary etykiet i pól jako oddzielnego zadania, nawet jeśli stracą kontekst.

• Unikaj żargonu, skrótów i języka branżowego, kiedy tylko możesz.
• Bądź konsekwentny. Jeśli raz użyjesz słowa „klient” w etykiecie, trzymaj się tego słowa. Unikaj używania „klientów” później, ponieważ może to zmylić użytkowników.
• Rozmiar czcionki powinien być wystarczająco duży. Jak najszybciej przetestuj swój formularz na prawdziwych urządzeniach i odpowiednio dostosuj rozmiar.
• Tekst pisany wielkimi literami może być trudny do odczytania dla niektórych użytkowników. Możesz chcieć uniknąć używania na etykietach tekstu pisanego wielkimi literami.
• Kopia etykiety powinna być krótka i łatwa do zeskanowania. Jeśli pole wymaga wyjaśnienia, nie umieszczaj go na etykiecie. Zamiast tego użyj opisu pola.

Najlepsza praktyka dotycząca rozmiaru wejściowego

Jeśli to możliwe, rozmiar elementu input powinien odpowiadać rozmiarowi oczekiwanej treści . Pomoże to użytkownikom szybko wypełnić formularz i zrozumieć, czego się oczekuje.

Używanie masek, aby uniknąć dzielenia wejść na urządzeniach mobilnych

Nie dziel wejść tylko ze względu na formatowanie . Jest to szczególnie irytujące na urządzeniach mobilnych, gdzie użytkownicy nie mogą używać klawiatury do poruszania się między polami. Wymaga dodatkowych stuknięć, aby przejść do następnego pola w celu wypełnienia formularza. Być może myślisz: „Ale automagicznie skupię się na następnym polu, gdy uzyskam wymaganą liczbę znaków w tym polu”. To może zadziałać. Ale przejmiesz kontrolę nad interfejsem użytkownika, który staje się nieprzewidywalny dla użytkownika. Byłoby również kłopotliwe, gdybyś automagicznie wysłał ich do następnego pola i musiały coś poprawić w ostatnim polu. Wreszcie, bardziej skomplikowane jest odgadnięcie, co jest obowiązkowe w przypadku dzielonych wejść. Więc przestańmy grać w grę „Ale co, jeśli” i po prostu nie dzielmy wejść.

Rozumiem: nadal chcesz mieć możliwość formatowania danych użytkownika w małych kawałkach, aby pomóc mu wypełnić twoje pola. I masz co do tego całkowitą rację. Aby to zrobić, możesz użyć masek . Zamiast dzielić dane wejściowe, po prostu umieść na nim maskę, aby wizualnie pomóc użytkownikowi je wypełnić. Oto przykład wideo przedstawiający maskę, która pomoże użytkownikom wypełnić pole karty kredytowej:

Maski pomagają zapobiegać błędom, prowadząc użytkowników do właściwego formatu. Unikaj ich stopniowego ujawniania — pokaż format bezpośrednio. Unikaj też umieszczania fałszywych wartości w masce . Użytkownicy mogą pomyśleć, że jest już zapełniony. Dlatego w moim demo zastąpiłem liczby małym „X”. Znajdź to, co najlepiej pasuje do Twojego typu danych wejściowych.

Na koniec pamiętaj, że niektóre dane mogą się różnić w zależności od kraju, a czasami zmienia się również format (na przykład numery telefonów). Zaplanuj odpowiednio.

Wydajne opisy pól

Wyświetlanie skutecznych opisów pól może mieć wpływ na różnicę między bezproblemowym a bolesnym doświadczeniem formularza.

Do czego można używać opisów?

Opisy mogą pomóc użytkownikom na wiele sposobów. Oto kilka przykładów.

• O co dokładnie prosisz?
  

  Z jakiegokolwiek powodu związanego z bazą danych, niektóre firmy transportowe proszą o pola „Adres 1” i „Adres 2”. Jest to bardzo mylące dla użytkowników, ale możesz nie mieć tutaj wyboru. Dodaj pola opisu, aby pomóc użytkownikom zrozumieć, co muszą umieścić w każdym polu.

  

  To samo dotyczy akronimów i skrótów. Wiem, że powiedziałem, że powinieneś ich unikać, ale czasami nie możesz. Jeśli na przykład pracujesz nad złożonymi formularzami dla określonej branży, mogą one mieć własny zestaw skrótów. Każdy nowy użytkownik, który musi wypełnić formularz, może (jeszcze) nie znać tych skrótów. Pomoże im w tym posiadanie gdzieś opisu.

• Dlaczego potrzebujesz tych informacji?
  Użytkownicy mogą niechętnie podawać Ci dane osobowe, jeśli nie rozumieją , dlaczego ich potrzebujesz i co z nimi zrobisz . Czasami jednak musisz poprosić o takie informacje ze względów prawnych (np. data urodzenia w przypadku strony internetowej sprzedającej alkohol). Użycie opisów pól w tym miejscu pomoże użytkownikom zrozumieć, dlaczego potrzebne są tego rodzaju informacje.
  
  

  W witrynach handlu elektronicznego możesz poprosić o numer telefonu użytkownika na wypadek, gdyby dostawca musiał się z nim skontaktować. To jest uzasadniony powód. Dlatego ponownie użyj opisów, aby wyjaśnić użytkownikom e-commerce, dlaczego potrzebujesz ich numeru telefonu.

  

„Gdzie znajdę informacje?”
Jeśli Twoi użytkownicy muszą znaleźć określone informacje w innym miejscu, aby wypełnić formularz, powiedz im, gdzie je znaleźć. Pracowałem nad aplikacją mobilną, która pozwala użytkownikom śledzić ich dom. Użytkownicy musieli sparować aplikację z urządzeniem monitorującym za pomocą numeru seryjnego. Nie jest łatwo znaleźć ten numer seryjny na urządzeniu; wymaga pewnych instrukcji. Dodaliśmy trochę ? obok pola numeru seryjnego. Przycisk otwiera moduł, który pokazuje obraz i pewne wskazówki, aby pomóc użytkownikowi zrozumieć, gdzie znaleźć numer seryjny na urządzeniu monitorującym. Witryny e-commerce robią to samo z kodami promocyjnymi: podają wskaźniki, które informują użytkowników, gdzie znaleźć kody.



• „Jak mam sformatować informacje?”
  Niektóre pola wymagają określonego formatu . W takim przypadku użyj opisów, aby z góry poinformować użytkowników o regułach formatowania. Oto kilka przykładów:
  • Numer telefonu: czy muszę umieścić międzynarodowy numer kierunkowy (+xx) przed polem?
  • Czy istnieje maksymalna długość? Twitter na komórce dobrze sobie z tym radzi.
  • Czy w przypadku kwot pieniężnych format zawiera przecinek (np. 10 000) czy spację (np. 10 000)?
  • Jakiego formatu oczekujesz na randki? Pozwolę ci sprawdzić na Wikipedii, co to za koszmar. Różnica między DD MM YY a MM DD YY może sprawić *dużo* kłopotów użytkownikom podczas rezerwacji online.
  Pamiętaj, że wiele z tych problemów z formatowaniem można rozwiązać za pomocą masek wejściowych. Dojdziemy do tego w dalszej części artykułu (lub możesz wskoczyć od razu, jeśli jesteś niecierpliwy).

  

Jak wyświetlać opisy

W powyższych przykładach widzieliśmy kilka sposobów wyświetlania opisów pól. Oto podsumowanie tego, co należy zrobić:

• Opisy w tekście powinny być bezpośrednio widoczne i wyświetlane obok pola.
• Jeśli potrzebujesz bardziej szczegółowych opisów o dużej zawartości, możesz użyć etykietek narzędzi lub modów . Etykietki narzędzi są zazwyczaj uruchamiane po najechaniu myszą na komputerze i dotknięciu na urządzeniu mobilnym. To samo dotyczy modów: otwórz go, gdy użytkownik na przykład kliknie ikonę pomocy lub link „zobacz więcej”.

Uważaj na symbole zastępcze

Rozumiem: kuszące jest usuwanie pól na telefonie komórkowym, aby zyskać miejsce i zamiast tego używać symboli zastępczych. Wszyscy poszliśmy tą drogą. Ale proszę nie. Specyfikacja HML5 mówi o tym jasno: „Atrybut placeholder reprezentuje krótką wskazówkę (słowo lub krótką frazę) mającą pomóc użytkownikowi we wprowadzaniu danych”. A oto dlaczego:

• Symbol zastępczy znika, gdy użytkownik zaczyna pisać. Użytkownik musi wtedy polegać na pamięci krótkotrwałej, aby zapamiętać, co ma umieścić w terenie . Jeśli nie, będą musieli opróżnić pole, aby zobaczyć wskazanie.
• Użytkownikom trudno jest dwukrotnie sprawdzić pola przed przesłaniem , ponieważ pola nie mają już żadnych oznaczeń etykiet.
• Trudno jest naprawić błędy po przesłaniu pola, ponieważ znowu nie ma etykiety, która mogłaby pomóc użytkownikowi.

Nawet jeśli używasz symboli zastępczych z etykietami, nadal możesz mieć pewne problemy. Trudno odróżnić pole wypełnione od pola z symbolem zastępczym . Jestem projektantem UX, który pisze o projektowaniu formularzy mobilnych i nawet mnie w zeszłym tygodniu oszukał jeden z nich. Jeśli przydarzy się to mnie, stanie się to Twoim użytkownikom — zaufaj mi w tej sprawie. Wreszcie, większość symboli zastępczych ma jasnoszary tekst, więc możesz mieć również problemy z kontrastem.

Jeśli chcesz zagłębić się w ten temat, znajdziesz świetny artykuł zatytułowany „Atrybut zastępczy nie jest etykietą”, a także Joshua Winn i FeedbackGuru szczegółowo wyjaśniają, dlaczego jest to zły pomysł. Nielsen Norman Group napisała również artykuł na ten temat zatytułowany „Wypełniacze w polach formularzy są szkodliwe”.

Symbole zastępcze nie są obowiązkowe w HTML5 . Z punktu widzenia użyteczności z pewnością nie potrzebujesz symbolu zastępczego w każdym polu formularza. Ale przy masowej adopcji Bootstrapa i innych frameworków wygląda na to, że wiele osób po prostu kopiuje i wkleja komponenty. Te komponenty mają symbole zastępcze, więc wydaje mi się, że ludzie czują się zobowiązani do dodania czegoś do symbolu zastępczego w kodzie? Jeśli symbole zastępcze formularza wyglądają tak: „Proszę wypełnić — etykietę — tutaj”, robisz to źle.

Etykiety wewnątrz pól mogą jednak dobrze działać w przypadku krótkich formularzy, w których pola są przewidywalne . Formularze logowania są do tego dobrym kandydatem. Ale nie używaj symbolu zastępczego HTML5 do kodowania tego. Użyj prawdziwej etykiety w kodzie i przenoś ją za pomocą CSS i JavaScript.

Od czasu sukcesu projektowania materiałów w Androidzie zaczął pojawiać się wzorzec: pływająca etykieta. Ta etykieta znajduje się w polu, gdy pole nie jest wypełnione, więc zajmuje nieco mniej miejsca w pionie na telefonie komórkowym. Gdy użytkownicy rozpoczynają interakcję z polem, etykieta przesuwa się nad polem.

Wygląda to na ciekawy sposób na zyskanie przestrzeni, bez wpadania w przytoczone powyżej kwestie „wypełniaczy zamiast etykiet”. Niemniej jednak nie rozwiązuje problemu mylenia przez użytkowników symbolu zastępczego z wypełnianą treścią.

Redukcja kosztów interakcji dla udanych formularzy

Zmniejszenie kosztów interakcji (tj. liczby naciśnięć, przesunięć itp.) użytkowników wykonujących swoje zadanie pomoże Ci zbudować płynne wrażenia z formularza. Można to osiągnąć różnymi technikami. Przyjrzyjmy się szczegółowo kilku z nich.

Magiczne badanie w Internecie kazało mi zmniejszyć liczbę pól

Więcej pól oznacza mniej konwersji, prawda? Być może spotkałeś się z badaniem „zmniejszyliśmy nasz formularz subskrypcji z 11 do 4 pól, co zwiększyło konwersje o 160%”. To klasyk. A jeśli spojrzysz na ich formularz kontaktowy, to ma sens. Dlaczego użytkownicy mieliby wypełniać 11 pól tylko po to, aby skontaktować się z firmą? Nie możesz prosić o tak duże zaangażowanie ludzi, którzy ledwo Cię znają, prawda?

Zacznij od pytania tylko o przydatne informacje. Dlaczego potrzebujesz płci osoby, aby utworzyć dla niej konto? Dlaczego masz dwa wiersze na adres, jeśli formularz subskrypcji dotyczy usługi online?

Pytaj tylko o potrzebne informacje. A następnie poproś o informacje w kontekście. Jeśli masz witrynę e-commerce, użytkownicy mogą być bardziej skłonni do podania swojego adresu w sekcji wysyłki w procesie realizacji transakcji niż podczas rejestracji. Dzięki temu formularz rejestracyjny e-commerce będzie o wiele łatwiejszy do wypełnienia na telefonie komórkowym!

Nie ufaj ślepo każdej statystyce i badaniu, które znajdziesz w Internecie. Pamiętasz badanie z 11 pól na 4? Cóż, inne, nowsze badanie wykazało, że zmniejszenie liczby pól z 9 do 6 spowodowało spadek konwersji o 14%. Szokujące, prawda? Czemu? Cóż, usunęli najbardziej angażujące pola. Krótko mówiąc, wrócili do 9 pól, umieścili najważniejsze na górze i voila, konwersje wzrosły o 19,21%.

Najważniejsze jest to, że chociaż te badania są interesujące, te witryny nie są Twoją witryną. Nie ufaj ślepo pierwszemu badaniu, jakie znajdziesz w Internecie.

Więc co możesz zrobić? Test. Test. I testuj!

• Przeprowadź testy użytkowników, aby sprawdzić czas do wypełnienia formularza mobilnego.
• Zmierz wypadanie.
• Mierz problemy z określonymi polami.
• Zmierz frustrację związaną z niektórymi polami. Jak bardzo użytkownicy są skłonni podać te informacje? Jak osobiste są te informacje?

Optymalizacja interakcji dotykowych

Sterowanie przyjazne dla dotyku

Jeśli Twoje pola są zbyt małe lub trudno dostępne, użytkownicy będą popełniać błędy i będą potrzebować dodatkowych interakcji, aby osiągnąć swoje cele. Pamiętasz prawo Fitta? Możesz to zastosować również do projektowania na urządzeniach mobilnych: Zwiększ rozmiar celu dotykowego , aby etykiety, pola i elementy sterujące formularzy były łatwe do dotknięcia. W przypadku etykiet w Internecie nieco większe wypełnienie może zwiększyć obszar dotykowy. Czasami trzeba będzie również dodać marginesy między elementami, aby uniknąć pominiętych stuknięć.

Nie zapomnij również połączyć etykiet z ich składnikami poprzez parowanie for i ID. W ten sposób, jeśli użytkownik nie dotknie etykiety, odpowiednie pole będzie nadal aktywne.

Steven Hoober przeprowadził badania użytkowników dotyczące obszarów dotykowych. Podsumowanie znajdziesz w „Designing for Touch”. W oparciu o to, co odkrył, zbudował małe narzędzie z plastikową linijką: mobilny szablon dotykowy. Narzędzie może pomóc w upewnieniu się, że obszary dotykowe są wystarczająco duże dla formularzy mobilnych i ogólnie do projektowania mobilnego.

Aby dowiedzieć się więcej o projektowaniu pod kątem dotyku, przeczytaj:

• „Projekt przyjazny dla palców: idealne rozmiary docelowe dla mobilnego ekranu dotykowego”
• „Strefa kciuka: projektowanie dla użytkowników mobilnych”

Dostarczanie opinii

Użytkownicy mobilni nie mają myszy (nie żartuję), więc nie otrzymują informacji zwrotnej o „kliknięciu”, którą otrzymują użytkownicy komputerów stacjonarnych po naciśnięciu przycisku. Użytkownicy formularzy mobilnych potrzebują jasnych informacji zwrotnych podczas interakcji z elementami:

• Podaj stan skupienia dla pola formularza, z którym użytkownik wchodzi w interakcję.
• Przekaż wizualną informację zwrotną, gdy użytkownik wejdzie w interakcję z przyciskiem .

Nie jestem wielkim fanem efektu falowania na guzikach Material Design. Muszę jednak przyznać, że animacje na Androidzie dają wyraźną informację zwrotną, gdy użytkownik wchodzi w interakcję z przyciskiem.

Uhonoruj ​​następną i poprzednią kolejność przycisków

Wreszcie, szanuj następne i poprzednie przyciski na klawiaturach mobilnych. Użytkownicy mogą ich używać do szybkiego poruszania się po polach. Kolejność tabindex powinna odpowiadać wizualnej kolejności pól i komponentów.

Jeśli to możliwe, unikaj rozwijanych funkcji na urządzeniach mobilnych

Listy rozwijane (element wyboru HTML) w sieci wymagają wielu kart i interakcji. Dlatego, jak powiedział Łukasz Wróblewski, powinny one być UI ostatniej szansy. Wiele innych składników interfejsu użytkownika działa lepiej niż listy rozwijane w wielu sytuacjach.

Kontrolki segmentów i przyciski opcji są dobrą alternatywą dla list rozwijanych, jeśli masz od dwóch do czterech opcji. Po co ukrywać opcje pod listą rozwijaną, skoro można je wszystkie wyświetlić bezpośrednio na jednym ekranie? Zauważ, że podobnie jak przyciski radiowe, kontrolki segmentów wzajemnie się wykluczają.

Lista krajów jest dobrym kandydatem na komponent. Lista ponad stu krajów to koszmar interakcji na urządzeniach mobilnych. Jeśli szukasz Afganistanu (na początku listy) lub Zimbabwe (koniec listy), nie ma problemu. Jeśli szukasz Luksemburga, skończysz w grze w przewijanie, aby dotrzeć do środka listy, posuwając się za daleko do litery M, próbując wrócić do L i tak dalej.

Długie listy rozwijane można zastąpić predykcyjnymi polami wprowadzania tekstu . Gdy użytkownik zacznie wpisywać L, interfejs zaproponuje dziewięć krajów. Jeśli dodają U — voila! — Tak jest w Luksemburgu. Cztery interakcje zamiast dwóch, w porównaniu z aż sześcioma lub siedmioma interakcjami przewijania z menu rozwijanym.

Jeśli potrzebujesz, aby użytkownicy wybrali datę, zapomnij o dzieleniu jej na rozwijane menu dnia, miesiąca i roku, jak to robią ludzie na papierowych formularzach. Zastąp wiele list dat selektorem dat . W większości przypadków działa type=date . Ale możesz mieć pewne specjalne potrzeby i skończyć zbudowaniem własnego selektora dat w JavaScript, zwłaszcza jeśli zajmujesz się rezerwacją (hotele, samochody, loty).

W swoim artykule „Mobile DropDowns Revisited” Klaus Schaefers wyjaśnia, w jaki sposób używanie selektora dat do dat przyjazdu i wyjazdu przyspiesza interakcje o 60%.

Pozostańmy przy biznesie rezerwacyjnym. Załóżmy, że użytkownik musi dodać do swojego planu podróży wielu podróżnych. Możesz **zamienić menu rozwijane * na * krokowy**, aby wybrać liczbę pasażerów. Stepper to element sterujący, który pozwala użytkownikowi zwiększać i zmniejszać wartości, po prostu dotykając przycisków + i - . To wydaje się być szybsze, gdy trzeba dodać mniej niż sześć osób. Jest też bardziej intuicyjny. Poniżej znajduje się przykład steppera używanego w natywnej dla systemu Android aplikacji Airbnb do wybierania gości oraz na zoptymalizowanej pod kątem urządzeń mobilnych witrynie Kayak do dodawania pasażerów.

Ostatnią alternatywą dla list rozwijanych jest widok listy. Opcje byłyby wymienione w określonym podwidoku, na przykład jako przyciski radiowe . Tak działają głównie ustawienia Androida.

Sprytne autouzupełnianie

Jeśli chcesz zmniejszyć koszt interakcji swojego formularza, bądź mądry. Nie pytaj o informacje, które możesz automatycznie wykryć lub odgadnąć na podstawie innych informacji podanych przez użytkowników. Autouzupełniaj i wstępnie wypełniaj tyle, ile możesz.

Miejsca i adresy

Jeśli użytkownik szuka miejsca lub musi wpisać adres, możesz zaoferować mu automatyczne uzupełnianie. Gdy wpisują, API wypełni dla nich resztę adresu. Zmniejsza to również błędy.

Możesz użyć:

• Interfejs API Miejsc Google
• Algolia Places, która jest oparta na OpenStreetMap

We Francji i wielu innych krajach miasto można odgadnąć na podstawie numeru kierunkowego. Tak więc, jeśli francuski użytkownik wprowadzi numer kierunkowy, możesz automatycznie uzupełnić lub przynajmniej zaproponować miasto. Mój kraj, Luksemburg, jest mały (nie śmiej się ze mnie). Mój numer kierunkowy jest powiązany z moją ulicą. Tak więc, jeśli wprowadzę swój numer kierunkowy, formularz powinien nawet zasugerować moją ulicę.

Karty kredytowe

Innym obszarem, w którym automatyczne wykrywanie jest łatwe, są karty kredytowe. Nie musisz pytać użytkownika, jaki typ karty kredytowej ma. Możesz to automatycznie wykryć na podstawie wprowadzonych przez nich początkowych liczb. Jest nawet biblioteka, która może wykonać tę pracę za Ciebie.

Korzystanie z autouzupełniania HTML5 (autouzupełnianie)

Atrybut autouzupełniania HTML może wstępnie wypełniać pola na podstawie wcześniejszych danych wprowadzonych przez użytkownika. Ten atrybut ma stan włączenia i wyłączenia. Niektórzy sprytni ludzie zaczęli pracować nad specyfikacją, aby uczynić to bardziej zaawansowanym i rozszerzyć atrybut autouzupełniania dla pól formularzy. WHATWG ma również ciekawą listę.

Chrome i inne przeglądarki mobilne obsługują już niektóre rozszerzone wartości dla kart kredytowych i nazw. Oznacza to, że użytkownicy mogą wstępnie wypełniać formularze swoim imieniem i danymi karty kredytowej, których używają na innych stronach internetowych.

Krótko mówiąc, kiedy musisz wybierać między różnymi systemami, policz liczbę interakcji, które każdy będzie wymagał.

Błędy się zdarzają: obsługa błędów w formularzach mobilnych

Ostatnim krokiem na naszej drodze do lepszych formularzy mobilnych jest obsługa błędów i pomyłek. Możemy spróbować zmniejszyć liczbę błędów, aby zmniejszyć obciążenie poznawcze użytkownika. Możemy również pomóc im odzyskać sprawność po błędach, ponieważ bez względu na to, jak świetny jest projekt formularza, zdarzają się błędy.

Unikanie błędów podczas wypełniania formularzy

„Lepiej zapobiegać niż leczyć” – mawiała moja mama. Dotyczy to również projektowania formularzy: zapobieganie błędom poprawi wygodę korzystania z formularza mobilnego.

Wyraźne ograniczenie formatu

„Bądź konserwatywny w tym, co robisz. Bądź liberalny w tym, co akceptujesz od innych”. Tę zasadę odporności można zastosować również do pól formularzy. Jeśli to możliwe, pozwól użytkownikowi wprowadzić dane w dowolnym formacie.

Jeśli uważasz, że musisz ograniczyć to, co użytkownik może wprowadzić w polu, zacznij od pytania „dlaczego”. W dziedzinie doświadczenia użytkownika mamy technikę o nazwie „trzy dlaczego”. Jeśli odpowiedź brzmi „bo bla bla bla” to może czas coś zmienić. Na przykład, dlaczego odrzucasz znaki specjalne, takie jak e, ai o w polu nazwy użytkownika? Napisałem artykuł wyjaśniający, jak niegrzeczne są dla mnie formularze, gdy próbuję wpisać „Stephanie” jako nazwę użytkownika. Nadal staram się znaleźć dobry powód (poza względami bazy danych).

Jeśli masz dobry powód, aby wymagać od użytkowników określonego formatu, poinformuj o tym z góry . Możesz użyć symboli zastępczych HTML5, aby dać użytkownikom wskazówkę, jak powinny wyglądać dane, ale znowu bądź ostrożny. Możesz również skorzystać ze wszystkich technik opisu pól wyjaśnionych na początku tego artykułu. Wreszcie maski wprowadzania mogą prowadzić użytkowników do właściwego formatu.

Zaznaczanie pól obowiązkowych (i opcjonalnych)

Nie czekaj, aż użytkownicy prześlą w połowie wypełniony formularz, aby poinformować ich o wymaganych polach. Jeśli pole jest obowiązkowe, użytkownicy powinni o tym wiedzieć . Oznaczanie pól obowiązkowych gwiazdką ( * ) i legendą stało się standardowym wzorem formularzy. Dobrą stroną jest to, że nie zajmuje dużo miejsca. Problem polega na tym, że nie ma to wartości semantycznej, więc może powodować problemy z dostępnością, jeśli jest źle zakodowane i jeśli polegasz na nawykach ludzi z interakcją z formularzem.

Zamiast tego można wyraźnie zaznaczyć zarówno pola obowiązkowe, jak i opcjonalne słowami „wymagane” (lub „obowiązkowe”) i „opcjonalne”. Zgadzają się z tym zarówno Baymard Institute, jak i Łukasz Wróblewski. Pozwala to uniknąć niejednoznaczności z długimi formularzami na telefonie komórkowym, na przykład podczas używania scrolla, przechodzenia do czegoś innego, a następnie wracania i nie pamiętania, czy pola obowiązkowe zostały oznaczone gwiazdką, czy czymś innym.

Ostatecznie decyzja o sposobie oznaczenia tych pól będzie zależeć od projektu i długości pola oraz od kontekstu. Najlepszym sposobem sprawdzenia, czy podjąłeś właściwą decyzję, jest ponowne przetestowanie formularza.

Rozsądne wartości domyślne

Uważaj na domyślnie wybrane opcje w formularzach . Kiedy starałem się o moją poprzednią pracę, był formularz informacyjny. Stan cywilny był opcjonalny. Uczynili pierwszy element listy rozwijanej „rozwiedziony”, pole domyślne. Mogłem więc albo nie odpowiedzieć (ponieważ było to pole opcjonalne) i pozwolić systemowi uwierzyć, że jestem rozwiedziony, albo poprawić to i ujawnić mój aktualny stan cywilny, nawet jeśli nie chciałem.

Uważaj też na płeć. Ponownie, miej opcję dla osób, które nie chcą tego ujawniać; wyjaśnij, dlaczego pytasz o ich płeć; jeszcze lepiej, poproś o zaimki lub nie pytaj, jeśli naprawdę nie musisz. 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.

• Po zalogowaniu
  W formularzu logowania opcja maskowania/odkrywania hasła znacznie poprawiłaby komfort użytkowania.
  Amazon ma ciekawą historię iteracji haseł w formularzu logowania. Kiedyś miał wersję, w której nie można było zobaczyć hasła. Kolejna iteracja pozwoliła użytkownikom to ujawnić. Wtedy hasło było domyślnie ujawniane i można je było ukryć. Tak wyglądało w 2015 roku:

  

  Amazon przetestował ostatnią wersję, a 60% osób nabrało podejrzeń. Dlatego zastąpili niezaznaczone pole wyboru „ukryj hasło” polem wyboru „pokaż hasło”. Spowoduje to wyświetlenie hasła mniejszymi znakami pod polem, podczas gdy użytkownik wpisałby. Tak to wygląda w momencie pisania tego artykułu:

  

  Jak widać, zawsze jest miejsce na ulepszenia.

Walidacja inline

Jeśli znasz zasady użyteczności, być może znasz prawo bliskości Gestalt. Na urządzeniach mobilnych unikaj podsumowywania błędów u góry strony, bez informacji kontekstowych, po kliknięciu przez użytkownika przycisku przesyłania.

Zamiast tego komunikaty o błędach powinny znajdować się blisko samych błędów .

Walidacja w czasie rzeczywistym

Nie musisz też czekać, aż użytkownicy klikną przycisk przesyłania. Możesz sprawdzać pola i wyświetlać opinie, gdy użytkownik je wypełnia .

Kilka wskazówek:

• Jak wspomniano wcześniej, pola haseł zyskałyby dzięki walidacji w czasie rzeczywistym i informacji zwrotnej na temat każdego naciśnięcia klawisza.
• Możesz także chcieć sprawdzać nazwy użytkowników w czasie rzeczywistym podczas tworzenia kont, aby upewnić się, że są one dostępne. Twitter wykonuje dobrą robotę.
• Nie sprawdzaj każdego naciśnięcia klawisza. Poczekaj, aż użytkownik zakończy pisanie. (Użyj blur JavaScript dla formularzy internetowych lub poczekaj kilka sekund, aby wykryć brak aktywności).

Uwaga : *Mihael Konjevic napisał fajny artykuł na temat „Inline Validation in Forms: Designing the Experience”. Wyjaśnia pojęcie „ nagradzaj wcześnie, karaj późno ”.*

„Jeśli użytkownik wprowadza dane w polu, które były w prawidłowym stanie, po wprowadzeniu danych przeprowadź walidację”.

„Jeśli użytkownik wprowadza dane w polu, które było w nieprawidłowym stanie, przeprowadź walidację podczas wprowadzania danych”.

Kolor ma znaczenie

Nie mówię, że kolor ma znaczenie tylko ze względu na mój obecny rudy, różowy i fioletowy kolor włosów. Kolor naprawdę ma znaczenie w projektowaniu formularzy.

W sieci istnieją pewne konwencje, których nie chcesz łamać. Użytkownicy nierozróżniający kolorów wiedzą, że czerwony oznacza błędy, żółty ostrzeżenia, a zielony prawie zawsze oznacza potwierdzenie lub sukces. Najlepiej trzymać się tych trzech kolorów. Jednak czerwony może wywołać u ludzi niepokój. Użytkownik może pomyśleć, że popełnił naprawdę poważny błąd. Używanie pomarańczowego lub żółtego do komunikatów o błędach może spowodować mniejszą panikę. Problem z żółtym i pomarańczowym polega na tym, że trudno znaleźć ich odcienie przyjazne dla daltonistów.

Mówiąc o daltonizmie: kolor nie powinien być jedynym sposobem na przekazanie komunikatu o błędzie . To jest kryterium dostępności.

W poniższym przykładzie po lewej stronie pole z błędem ma kolor pomarańczowy, a pole, które zostało poprawione, zmieniło kolor na zielony. Użyłem narzędzia do testowania daltonistów, aby zrobić zrzut ekranu w środku: nie można już odróżnić domyślnej szarej ramki od zielonej. Dodanie kilku ikon na ostatnim zrzucie ekranu zapewnia, że ​​komunikaty o błędach są przekazywane osobom z daltonizmem.

Odzyskiwanie błędów: pisanie przyjaznych dla użytkownika komunikatów o błędach

W tym momencie zrobiliśmy wszystko, co w naszej mocy, aby pomóc użytkownikom wypełnić nasze formularze i uniknąć błędów. Ale czasami, pomimo naszych najlepszych starań, zdarzają się błędy. Czas dowiedzieć się, jak pomóc użytkownikom naprawić te błędy.

Po pierwsze, pamiętaj: nie przejmuj kontroli nad systemem. Jeśli problem nie jest krytyczny, użytkownik powinien móc kontynuować interakcję z jak największą częścią interfejsu. Unikaj tych komunikatów o błędach JavaScript i modalnych, które blokują użytkowników, gdy tylko jest to możliwe. Ponadto, jeśli Twój formularz wymaga uprawnień, poproś o nie w trakcie użytkowania. Jeśli pozwolenie nie zostanie udzielone, nie uważaj tego za błąd, ponieważ tak nie jest. Uważaj na kopię, której tutaj używasz.

Nie jesteś robotem, podobnie jak Twoi użytkownicy

Wiem, że roboty są fajne. Ale nie jesteś robotem, podobnie jak Twoi użytkownicy. Jednak tak wiele komunikatów o błędach jest nadal tak źle napisanych. Oto kilka wskazówek dotyczących komunikatów o błędach przyjaznych dla człowieka:

• Nigdy nie pokazuj nieprzetworzonego komunikatu o błędzie, takiego jak „Wystąpił błąd typu 2393. Serwer nie mógł zakończyć operacji.” Zamiast tego wyjaśnij, co się wydarzyło w ludzkim języku i dlaczego to się stało .
• Nigdy nie pokazuj ślepego komunikatu o błędzie, takiego jak „Wystąpił błąd”. Zamiast tego zasugeruj sposoby naprawienia błędu . Napisz praktyczną kopię.
• Nigdy nie pokazuj niejasnego komunikatu o błędzie, takiego jak „Nie można znaleźć serwera o określonej nazwie hosta”, z przyciskiem „Spróbuj ponownie”. Zamiast tego postaraj się, aby komunikaty o błędach zawierały informacje i były spójne . Proszę, nie mów jak robot.
• Nie zakładaj, że ludzie znają kontekst wiadomości. Twoi użytkownicy nie są maniakami technicznymi. Zamiast tego wyjaśnij im prostym językiem, bez technicznego żargonu, jak naprawić ten błąd .

Uważaj na język, którego używasz w wiadomościach

Cokolwiek piszesz, unikaj sprawiania, by ludzie czuli się głupio z powodu błędu. Jeśli to możliwe, pomiń negatywne słowa ; mają tendencję do straszenia ludzi i sprawiają, że są jeszcze bardziej niespokojni. Zamiast tego użyj uprzejmego, pozytywnego, afirmującego tonu.

Nie obwiniaj użytkowników za błędy ; zamiast tego winić system. System nie będzie chował urazy, obiecuję. Przenieś uwagę użytkownika na to, jak system nie mógł przetworzyć akcji i wyjaśnij mu, jak znaleźć rozwiązanie .

Mała sztuczka polega na przeczytaniu na głos własnej wiadomości. Pomoże Ci usłyszeć, czy to działa, czy jest zbyt surowe, czy zbyt zwyczajne itp.

Możesz także wykazać się kreatywnością w komunikatach o błędach i dołączyć obrazy i humor , aby były mniej groźne. Będzie to jednak naprawdę zależeć od tożsamości i tonu Twojej marki.

Aby pomóc Ci napisać lepszy komunikat o błędzie, proponuję przeczytać następujące informacje:

• „6-punktowa lista kontrolna mikrokopii dla zespołów produktowych bez pisarzy UX”
• „Sztuka komunikatu o błędzie: pisanie przejrzystej, pomocnej kopii, gdy coś pójdzie nie tak”

Czas na przesłanie formularza

Użytkownik wypełnił formularz, nie ma już błędów i wszystko wygląda dobrze. Wreszcie nadszedł czas na przesłanie formularza!

Pierwsza zasada to nie maskuj przycisku przesyłania . Na serio! Zastanawiam się, jaki pokręcony umysł wpadł na ten pomysł, ale widziałem to w różnych formach. Przycisk przesyłania byłby wyświetlany tylko wtedy, gdy wszystkie wymagane pola zostały wypełnione bez żadnych błędów. Niepokojące dla użytkownika jest zastanawianie się, czy coś jest nie tak, czy przycisk formularza nie został załadowany, czy witryna jest uszkodzona i tak dalej.

Jeśli nie chcesz, aby użytkownicy mogli kliknąć przycisk przesyłania w przypadku braku obowiązkowych pól lub błędów walidacji, użyj disabled atrybutu HTML w danych wejściowych submit . Będziesz musiał ponownie włączyć przycisk za pomocą JavaScript, gdy formularz będzie prawidłowy i gotowy do przesłania.

Jeśli masz główne i dodatkowe wezwanie do działania, użyj koloru, rozmiaru i stylu, aby pokazać hierarchię .

Jeśli zastanawiasz się, czy przycisk potwierdzenia powinien pojawić się przed, czy za przyciskiem anulowania, ja też (i wiele innych osób). Jeśli tworzysz aplikację natywną, trzymaj się wytycznych systemu operacyjnego. Stało się to szczególnie zabawne, odkąd Android zmienił pozycje przycisków w swojej czwartej wersji. W sieci jest to bardziej skomplikowane, ponieważ nie ma prawdziwych wytycznych. Niezależnie od systemu operacyjnego, oto kilka ogólnych wskazówek dotyczących przycisków przesyłania zoptymalizowanych pod kątem urządzeń mobilnych:

• Daj wezwanie do działania opisowe, czasowniki dające się zastosować.
• Przekaż wizualną informację zwrotną, gdy użytkownik ją kliknie.
• Jeśli masz dwa przyciski, wyróżnij główną akcję .
• O ile nie pracujesz nad bardzo konkretnym formularzem korporacyjnym zaplecza (w takim przypadku będziesz mieć wiele wyzwań związanych z optymalizacją pod kątem urządzeń mobilnych), unikaj przycisku resetowania . Użytkownicy mogą pomylić go z przyciskiem przesyłania i przez przypadek stracą wszystkie swoje dane.

Wniosek

W tej pierwszej części omówiłem wiele technik, które pozwalają przenieść formularz na wyższy poziom i pomóc użytkownikom go wypełnić. Niektóre z tych ogólnych wskazówek i najlepszych praktyk dotyczących urządzeń mobilnych mogą nie działać w 100% przypadków — oto haczyk z najlepszymi praktykami. Dlatego zawsze testuj swoje formularze na rzeczywistych użytkownikach i rzeczywistych urządzeniach oraz dostosuj wytyczne do konkretnych potrzeb i doświadczenia użytkowników.

Zrób też regresję i automatyczne testy funkcjonalne — znowu na prawdziwych urządzeniach. Mobilny emulator Chrome nie wystarczy do testowania formularzy zoptymalizowanych pod kątem dotyku. Mówię to, ponieważ uruchomiłem witrynę e-commerce z formularzem wyszukiwania, który nie działał na urządzeniach mobilnych. Zautomatyzowaliśmy testowanie tylko za pomocą emulatora. Oto, co się stało. Formularz wyszukiwania został ukryty pod ikoną wyszukiwania. Możesz dotknąć przycisku, który otworzył pole z polem wyszukiwania. Działało poprzez emulację najechania myszą jako zdarzenia dotykowego. Przetestowaliśmy stukanie w przycisk i otworzyliśmy pudełko. Nikt nie próbował rozpocząć wyszukiwania. Tak więc nikt (nawet klient) nie zauważył, że pole wyszukiwania znikało, gdy tylko użytkownicy próbowali z nim wejść w interakcję. Co się stało? Gdy element wejściowy był aktywny, przycisk tracił stan najechania, więc zamykał pole z polem. Automatyczne testowanie nie było w stanie tego wychwycić, ponieważ dane wejściowe nie traciły ostrości. Uruchomiliśmy więc witrynę e-commerce bez funkcji wyszukiwania na urządzeniach mobilnych. Nie super doświadczenie.

W drugiej części tej serii przyjrzymy się bardziej zaawansowanym technikom mobilnym. Zobaczymy, jak używać fajnych funkcji HTML5 do formatowania pól i jak korzystać z funkcji mobilnych, aby przenieść wrażenia użytkownika mobilnego na wyższy poziom.