SPIN

Zapomniałem napisać, że dzisiaj o 18.00 na XXIX spotkaniu krakowskiego SPIN-u przedstawię prezentację dotyczącą ergonomii i użyteczności interfejsu użytkownika.
Spotkanie odbędzie się w głównym budynku ComArchu w sali "Widownia" (al. Jana Pawła II 39 a).

Zapraszam. Rejestracja nie jest wymagana.

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.

Przyzwyczajenie drugą naturą człowieka

Moja żona postanowiła ostatnio zmienić swój komunikator internetowy. Poleciłem jej to, czego używam sam - Pidgin. Szybko udało się skonfigurować i działa. Ale ja nie o tym.

Iza bardzo często korzysta z komputera używając tylko myszki. Woli zaznaczyć tekst w oknie komunikatora, kliknąć prawym przyciskiem, wybrać Kopiuj, przejść do przeglądarki, kliknąć prawym przyciskiem w polu tekstowym i wybrać Wklej. Ja wolę inaczej - ctrl-shift-w prawo, ctrl-c, alt-f4, tab, tab, tab, ctrl-v. Dlatego nie zwróciłem uwagi na to, że Pidgin konstruuje menu kontekstowe inaczej, niż wszystkie inne aplikacje.

Typowe menu kontekstowe (z Eksploratora Windows) wygląda tak:

Pidgin z kolei menu rysuje tak:

Różnice:

• zupełnie inaczej ułożone separatory,
• Pidgin dezaktywuje np. pozycję Wklej, Eksplorator ją usuwa,
• w Eksploratorze jedna pozycja nazywa się "Kopiuj", w Pidginie - "Skopiuj".

I chodzi właśnie o ten ostatni punkt - dlaczego ktoś zmienia standardowo przetłumaczony, obecny w większości polskich aplikacji tekst "Kopiuj"? Gdzieś kiedyś czytałem, że autorem tłumaczeń najbardziej podstawowych terminów informatycznych (takich jak "plik") jest poeta, bodajże Tadeusz Olszański. Świadczy to o tym, że tego typu tłumaczenia są potwornie trudne. I nie można się na nie porywać bez odpowiedniego przygotowania i respektu. I tego respektu zabrakło chyba tłumaczowi Pidgina.

Jeszcze jedna ciekawostka: bodajże Alan Cooper w About Face pisał o tym, że użytkownicy bardzo rzadko czytają etykiety w menu - częściej zapamiętują pozycję (drugi element od góry, pierwszy element nad ostatnim separatorem) niż chociażby skanują wzrokiem te napisy. A różnica pomiędzy "Skopiuj" a "Kopiuj" przy pobieżnym skanowaniu (różna pierwsza litera - w dodatku wielka!) może okazać się zbyt duża.

PS Ciekawe, w jakich jeszcze programach twórcy bądź tłumacze zdecydowali się na tego typu kreatywne tłumaczenia?

IT Academic Day na AGH

Dzisiaj miałem niepowtarzalną okazję, aby stanąć po drugiej stronie katedry w sali 224 w budynku C2 krakowskiej Akademii Górniczo-Hutniczej. W tej sali spędziłem niezliczone godziny słuchając mniej lub bardziej porywających wykładów z informatyki. Dzisiaj to ja prowadziłem prelekcję i to ja byłem oceniany.

W ramach IT Academic Day VSoft dostał 1,5 godziny dla siebie - moja była połowa tego czasu. Powiedziałem więc o User Experience - kilka podstawowych zasad, kilka ciekawych pomysłów - tak, aby naszkicować temat.

Mam nadzieję, że słuchaczom się podobało i nie był to mój ostatni publiczny występ.

Zainteresowanych zapraszam po slajdy z prezentacji.

Nowy blog - technologie osobno

Dzisiaj postanowiłem, że z mojego prywatnego bloga wykiełkuje odnoga - kwestie specjalistyczne, dotyczące informatyki, programowania, User Experience, Interaction Design i tym podobnych nudnych rzeczy publikowane będą na nowym blogu - właśnie tutaj. Nie zdecydowałem się jeszcze, czy artykuły będę przeklejać też do bloga prywatnego, czy pozostanie on wyłącznie na sprawy prywatne.

W każdym razie - zapraszam.

World Usability Day Tour de Pologne '09

Pod tą długą nazwę kryje się mini-konferencja, w której miałem okazję dzisiaj uczestniczyć. Na stronę wydarzenia trafiłem przypadkiem kilka dni temu, ale pomyślałem sobie, że, czemu nie, przejdę się i zobaczę.

Niestety, żałuję.

Dlaczego:

• Na stronie internetowej nie było napisane wprost, jaki będzie poziom wykładów. Napisanie, że impreza przeznaczona jest dla "osób zainteresowanych tą tematyką" mówi trochę za mało. Szkoda, że nie zostało napisane, że głównymi odbiorcami są studenci (znaczna większość obecnych na sali).
• Marne przygotowanie techniczne.
• Uczestnicy przerywali prelegentom w połowie zdania (sic!) i zwracali się do nich na "ty".
• Uczestnicy gustowali w zadawaniu pytań na zasadzie "ja bym to zrobił lepiej" - tak, tego typu pytania też były zadawane w pół zdania - przez co jeden z wykładów trwał o połowę dłużej, niż powinien.

Plusy:

• Jedna ciekawa prezentacja (szkoda, że była ostatnia).
• Spotkałem dwóch dawnych kolegów.

Kiedy zobaczyłem stronę o tym wydarzeniu, bardzo zapaliłem się do tego pomysłu. Pomyślałem wręcz, że może w przyszłym roku spróbowałbym się w to włączyć. Po dzisiejszym dniu odnoszę się do tego raczej z rezerwą.

Kasy automatyczne – PS

W nawiązanie do tego wpisu: wczoraj w tym samym Carrefourze postanowiłem jednak zapłacić gotówką. Niestety maszyna wydała mi za mało reszty (o 1,20 zł – ale zawsze to mniej). Na szczęście wezwana pani z obsługi spojrzawszy na rachunek (reszty do wydania 1,85 zł) i na moją dłoń (monety o całkowitej wartości 0,65 zł) bez dodatkowych pytań wydała mi tyle, ile trzeba.