poniedziałek, 8 lutego 2010

Wybór wartości z listy

Chcemy zrobić prostą, wydawałoby się, rzecz - wybrać kilka wartości z listy. Dla utrudnienia dodajmy tylko tyle, że wartości na liście jest dużo (na pewno nie będą widoczne w liście bez przewijania). Dla przykładu: mamy listę zdefiniowanych ról w aplikacji i dla danego elementu menu wybieramy, które z nich będą miały do niego dostęp; albo mamy listę wszystkich możliwych tapicerek do foteli i w naszym CMS-ie mamy wybrać, które są dostępne dla konkretnego modelu krzesła.

Rozwiązanie zazwyczaj wychodzi nam z grubsza podobne do tego:

Coś takiego widzieliśmy wszyscy i wiemy, jak tego używać. Jeżeli i jedna, i druga lista są dobrze posortowane, to nie ma najmniejszego problemu. Jeżeli jeszcze możemy używać techniki przeciągnij i upuść - tym lepiej.

Problem pojawia się jednak, gdy elementy, na których operujemy, mają więcej niż jedną wartość ją opisującą. Jeżeli chcemy wyświetlać wartości w gridzie (a właściwie w dwóch gridach), to na pewno nie zmieszczą się one w układzie takim, jak powyższy - gridy zazwyczaj posiadają kilka kolumn, a szerokość strony internetowej czy okna, w którym nasza kontrolka ma się wyświetlić - jest ograniczona. Naturalnym kierunkiem rozwoju takiej kontrolki jest więc ułożenie dwóch gridów jeden pod drugim. Na przykład tak:
Załóżmy od razu, że gridy te (a przynajmniej pierwszy z nich) są stronicowane i posiadają przyciski do zmiany stron. Od razu widać, że tak zbudowana kontrolka jest znacznie cięższa - chociażby przez to, że stara się przekazać znacznie więcej informacji. Zaawansowanym użytkownikom pozwala jednak na realizowanie wymyślniejszych żądań - zazwyczaj możemy posortować dane po każdej kolumnie, więc wybór wszystkich modeli Volkswagena Passata z ręczną skrzynią biegów z silnikiem benzynowym będzie łatwy.

Zaprezentowana powyżej propozycja jest przez użytkowników nawet dobrze rozumiana - widzą, że najpierw jest lista dostępnych modeli, mogą więc na niej coś zaznaczyć. Później (niżej) znajduje się przycisk "Dodaj", po którego kliknięciu wybrana wartość pojawi się w tabelce jeszcze niżej (dalej). Warto zaznaczyć, że dezorientujące będzie dla użytkownika, jeżeli to przypisanie nie zostanie zrealizowane asynchronicznie i po kliknięciu "Dodaj" strona zostanie przeładowana.

Jednak jakiś czas temu spotkałem się jednak z podejściem zgoła odwrotnym, czyli czymś wyglądającym tak:


Miałem przyjemność na tej aplikacji przeprowadzać testy użyteczności, tak więc uwagi do takiego projektu nie są wymyślone przeze mnie, ale zaobserwowane na użytkownikach z krwi i kości. Co więc można o takim projekcie - koniec końców bardzo podobnym do tego wcześniejszego - powiedzieć?

Jest niejasny. Użytkownicy mają standardowy schemat skanowania strony i poznawania jej elementów, a taki projekt do tego schematu nie pasuje. Użytkownik widzi najpierw pustą tabelkę, później przyciski "Dodaj" i "Usuń". Zdarzyło mi się zaobserwować, że użytkownik po wejściu na tak zbudowaną stronę wciskał od razu przycisk "Dodaj", licząc na to, że zostanie wyświetlona lista elementów możliwych do wyboru. Listę tę użytkownik miał zaraz poniżej, ale najpierw zauważył przycisk i od razu postanowił go kliknąć. Jego prawo.

Jeżeli użytkownik dostrzegł już, że lista elementów do wyboru znajduje się poniżej, to od zwycięstwa dzieliło go jeszcze kilka kroków. Zasadniczo - musiał znaleźć przycisk, którym doda zaznaczony element do zbioru wybranych elementów. Wydaje się to absurdalne, bo przecież przycisk "Dodaj" użytkownik zauważył kilka sekund wcześniej. Nic z tego. Użytkownik uważa (poniekąd słusznie), że taki przycisk znajdzie się na dalszej drodze analizowania strony, czyli poniżej drugiej tabelki. Tam go jednak nie ma. Nie od razu każdy przypomni sobie, że przycisk "Dodaj" widział już wcześniej.

Wnioski. W sytuacji, gdy elementy możemy opisać krótkimi etykietami, zdecydowania polecam używanie znanego schematu przypisywania z lewej do prawej. Jeżeli musimy skorzystać z gridów, to w żadnym wypadku nie powinniśmy używać schematu z dołu do góry. Model z góry na dół jest znacznie bardziej zrozumiały.

Ale czy w ogóle musimy używać kontrolek zbudowanych z dwóch gridów? Oczywiście - to zależy. Ale jeżeli musimy wybrać jedną, dwie, może trzy wartości z długiej listy złożonych elementów, to może drugi grid - tak samo rozbudowany jak pierwszy - jest zbędny? Może wystarczy wybrane elementy wypisać gdzieś obok w uproszczonej postaci? Albo przechowywać je na początku jedynej tabelki? W ten sposób zrealizowany jest na przykład wybór wielu kontaktów z listy osób w Nokiach z Symbianem S60 w wersji 3.

Wniosek podstawowy - nie zaburzać użytkownikowi jego drogi czytania strony.

Brak komentarzy:

Prześlij komentarz