Aplikacje sieciowe rządzą się swoimi prawami, jednym z nich jest niemożliwość uniknięcia formularzy. Te ostatnie można zaprojektować lepiej lub gorzej, zastanówmy się więc, co zrobić, aby były chociaż ciut wygodniejsze w użyciu.

Przede wszystkim należy się wystrzegać układu wielokolumnowego. Schemat najwygodniejszy dla oka to dwie kolumny, gdzie jedna zawiera opisy pól, zaś druga to kontrolki niezbędne do wprowadzania danych. Kolumnę z nagłówkami można wyrównać - wedle uznania - do lewej lub prawej, jednak jej centrowanie jest raczej kiepskim pomysłem - zabija to ideę układu dwukolumnowego, gdzie wszystkie dane wyrównane są do jednej (w przypadku wyrównania nagłówków do prawej) lub dwóch (w przypadku wyrównania do lewej) osi. Może się wydawać, że zysk na czytelności jest niewielki, jednak badania prowadzone z udziałem ludzi po czterdziestym roku życia pokazują, że dla nich różnica jest znaczna.

Należy grupować logicznie powiązane ze sobą dane w nazwane zestawy pól. Służy do tego element <fieldset/> w połączeniu z obowiązkowym elementem <legend/>. Zwiększa to czytelność formularza, usuwa wrażenie bezładu i uzasadnia taką a nie inną kolejność pól.

Powinno się unikać nadmiarowych pól. Jeśli aplikacja nie wymaga poszczególnych składowych adresu (jak np. numer domu), to znacznie ułatwimy życie swoim gościom, jeśli skleimy pola typu ulica, nr domu, nr lokalu, kod pocztowy i miasto w jedno większe pole zatytułowane adres, podając pod spodem oczekiwany format adresu. Powód jest prosty - większość użytkowników do przełączania się pomiędzy polami formularza używa myszy, więc konieczność wypełnienia kilku pól więcej jest bardzo uciążliwa.

Staraj się, aby wszystkie pola były podobnej długości, nie wprowadzaj więcej niż dwie - trzy różne długości pól, w ten sposób łatwiej podążać wzrokiem za nagłówkami, nie skupiając się na samych polach.

Do reprezentacji alternatywy wybieraj odpowiednie kontrolki. Jeśli opcje są dwie, to odpowiedni będzie checkbox (dla odpowiedzi tak/nie) lub 2 radiobuttony (w pozostałych przypadkach), niedopuszczalne jest np. użycie checkboksa do wyboru pomiędzy dwoma kolorami (zaznacz, jeśli produkt ma być czerwony, w przeciwnym wypadku będzie żółty). Radiobuttony są najlepszym wyjściem, kiedy opcji jest więcej niż dwie - zapewniają największą czytelność, bo wszystkie opcje widoczne są jednocześnie. Mają jednak jedną wadę - zajmują dużo miejsca, co bardzo przeszkadza, kiedy opcji jest więcej. Wtedy lepiej użyć rozwijalnej listy, jednak powinna to być ostateczność, bo jej użycie wymaga dodatkowego kliknięcia, zanim pojawią się dostępne opcje. Wystrzegać za to należy się listy (selectbox z liczbą wierszy większą niż jeden) - internauci nie są przyzwyczajeni do tej kontrolki i często nie wiedzą, jak z niej korzystać.

Do wyboru kilku spośród równorzędnych opcji zawsze najlepsza jest seria checkboksów. Niech nikomu nawet przez myśl nie przejdzie implementacja takiego wyboru za pomocą listy z włączoną opcją kilku wyborów. Lista jest przede wszystkim niewygodna - wymaga przewijania w celu dostania się do potrzebnych nam opcji. Jest też nieintuicyjna - wybranie kilku opcji wymaga przytrzymania klawisza Control (lub innego w przypadku architektur różnych od PC), z czego niewiele osób zdaje sobie sprawę. Ewentualne zaoszczędzone względem checkboksów miejsce trzebaby poświęcić na instrukcję obsługi korzystania z kontrolki listy.

Nie ma nic bardziej denerwującego niż klikanie na wielki napis tak, zgadzam się tylko po to, żeby dowiedzieć się, że nie jest on klikalny i musimy celować w niewielkich rozmiarów biały kwadracik checkboksa znajdującego się obok. Należy korzystać z elementu <label/>, pozwala on na uzyskanie fokusa przez kontrolkę po kliknięciu na jej opis i jest szalenie wygodne w przypadku każdego typu pól. Wystarczy atrybut for elementu <label/> ustawić na taką samą wartość, jak atrybutowi id odpowiedniej kontrolki.

Osoby starsze bardzo pozytywnie reagują na mały zabieg, polegający na wyróżnieniu aktywnego pola za pomocą niewielkiej zmiany kolorów. Można to uzyskać przez odpowiednie reguły CSS, jednak efekt ten nie zadziała w IE. Niestety, ta przeglądarka wymaga dodatkowych skryptów JS.

Na koniec najprostszy zabieg - zatrudnienie do pracy JavaScriptu. Pozwala to na przetworzenie i zweryfikowanie formularza jeszcze przed wysłaniem go na serwer. Jak często zdarzyło się wam klikać wyślij dziesiąty raz z rzędu, aby po minucie ładowania otrzymać kolejny komunikat o niewypełnionym polu? Jeśli przeglądarka wspiera JS, to można przygotować nieinwazyjny skrypt, który sam po cichu podłączy się do formularzy na stronie i przed ich wysłaniem upewni się, że wszystko wpisaliśmy zgodnie z intencjami autora serwisu. Tutaj uwaga - wyświetlenie komunikatu nie wypełniłeś wymaganych pól nie mówi użytkownikowi wiele. Należy przy okazji wskazać mu pola, o których zapomniał.

Przykład zastosowania JavaScriptu do wstępnej walidacji formularza można znaleźć na mojej stronie demonstracyjnej.

Można tam też zobaczyć niewielki gadżet - pasek postępu wysyłania formularza, który daje użytkownikowi poczucie, że coś się dzieje, co jest szczególnie ważne w przypadku uploadu dużych plików za pomocą formularza na stronie.

Na drugiej stronie demonstracyjnej można zobaczyć przykład innego skryptu - wyświetlania podpowiedzi wewnątrz pól edycyjnych, co przydaje się szczególnie, jeśli na stronie nie ma miejsca na opis dla danego pola (np. mini-wyszukiwarki umieszczane w nagłówkach stron).

Oczywiście, nie wyczerpałem tutaj tematu i nawet nie miałem takiego zamiaru - jest to tylko garść (mam nadzieję, że przydatnych) porad.

Ta notka została wysłana 13 lipca 2005 o 22:30:57.
Możesz przejść na koniec i zostawić komentarz.