Ile waży ten interfejs? Rozważania o HCI, Szuku i kognitywistyce
Przeglądając ostatnio Reddita trafiłem na dwa bardzo ciekawe artykuły na temat interfejsu użytkownika. Starają się one powiązać ciężar poznawczy interfejsu użytkownika z jego używalnością (usability) i proponują zgrubne metody jego mierzenia. Ciężar poznawczy (tak tłumaczę cognitive load, nie wiem, jakie jest zwyczajowe tłumaczenie) jest terminem pochodzącym z kognitywistyki który oznacza, mówiąc z grubsza, jak dużo ludzkiej „pamięci operacyjnej” musi zostać zaangażowane do wykonania jakiegoś zadania. Być może zetknęliście się z teorią 7±2: opiera się ona na bardzo podobnych pomysłach.
(Oba artykuły są mocno nieformalne: starają się przekazać pewną ideę, a nie pełną teorię, i w podobnyn tonie będą też moje rozważania... Prawda jest taka, że po pewnym czasie zajmowania się filozofią nauki traci się wrodzony szacunek wobec nadmiernie formalnych i silących się na ścisłość rozważań. Ale to temat na inną, dużo nudniejszą notkę. ;-)
Pierwszy artykuł wprowadza 3 hipotezy:
Ciężar poznawczy interfejsu rośnie proporcjonalnie do ilości kliknięć, uderzeń w klawisze klawiatury, gestów, itp. niezbędnych do jego obsłużenia.
Ciężar poznawczy intefejsu rośnie proporcjonalnie do czasu oczekiwania (latency) na odpowiedź interfejsu.
Używalność interfejsu (którą można rozumieć jako jak bardzo ludzie będą chcieli z niego korzystać) jest odwrotnie proporcjonalna do jego ciężaru poznawczego.
Drugi artykuł wprowadza poprawkę do hipotezy pierwszej. Zamiast liczyć kliknięcia itp. proponuje raczej mierzyć, z iloma obiektami musimy sobie poradzić aby osiągnąć upragniony cel. Wydaje się to słuszne: jeżeli już zacząłem pisać, napisanie kolejnych dwóch zdań nie wymaga ode mne prawie żadnego wysiłku. Z kolei sięgnięcie po myszkę aby zmienić czcionkę będzie już dla mnie dość nużące.
Zanalizujmy za pomocą tej metody dwa przykłady: wysłanie mejla i wiadomości jabberowej/gadu-gadu. Aby wysłać mejla muszę:
- Przejść do okienka przeglądarki/programu pocztowego.
- Kliknąć "Compose mail".
- Wprowadzić adres mejlowy adresata.
- Wymyślić temat, wprowadzić go.
- Wprowadzić treść mejla.
- Kliknąć wyślij.
Z kolei aby wysłać wiadomość za pomocą Jabbera lub Gadu-gadu:
- Przejść do odpowiedniego okienka.
- Wybrać znajomego.
- Wprowadzić wiadomość, nacisnąć Enter.
Z tej krótkiej analizy wynika, że mejl jest mniej używalny niż gadu, ponieważ (1) wymaga poradzenia sobie z większą ilością obiektów, (2) ma dłuższy czas oczekiwania na odpowiedź (w Jabberze już po kilku sekundach wiemy, czy nasz rozmówca zaczął odpowiadać). To co widzimy dookoła nas wydaje się potwierdzać tę hipotezę. Od wielu lat już słyszę, jak to mejle są wypierane przez instant messaging, sam obserwuje podobne zjawisko w swoim życiu. W podobny sposób można tłumaczyć wzrost popularności Twittera (lub Blipa) w stosunku do blogów, przewagi iPhone'a nad G-Phonem, od pewnego poziomu skomplikowania: linii komend nad graficznym menedżerem plików, etc.
Przykładów, kiedy prezentowana teoria działa, jest całkiem sporo; nie przychodzi mi też do głowy żaden przykład, który mógłby ją radykalnie sfalsyfikować. W związku z tym możemy ją chyba uznać za całkiem niezłą metodologię do rozważań na temat interfejsów użytkownika. Przyszedł mi więc do głowy nieco masochistyczny pomysł: zanalizować za jej pomocą moje (ale nie tylko moje) niedawne dzieło, czyli nowy interfejs szuku.pl.
Aby wyszukać jakąś osobę na Szuku należy:
- Wprowadzić jej imię i nazwisko, nacisnąć Enter.
- Kliknąć na interesującą zakładkę.
- Kliknąć interesujący nas tag.
- Przelecieć przez listę grup, zaznaczając te które dotyczą osoby której szukamy, odrzucając te które nie dotyczą.
- Wcisnąć guzik „Ulepsz wyniki”.
- Być może powtórzyć kroki 2 i 3.
Użytkownik musi zatem poradzić sobie z następującymi obiektami:
- Formularz wyszukiwania
- Zakładki
- Tagi
- Lista grup wyników
- Przycisk „Ulepsz wyniki”.
Dwa momenty kiedy użytkownik czeka to między potwierdzeniem nazwiska a pojawieniem się pierwszych wyników (co może trwać dość długo jeżeli wyszukiwanego nazwiska nie ma w indeksie) i po kliknięciu „Ulepsz wyniki” (co już trwa krótko).
Ci którzy pamiętają stary interfejs Szuku są raczej zgodni, że nowy jest dużo prostszy i bardziej przejrzysty. Tam każda grupa wyników była obiektem, z którym należało sobie poradzić, ponieważ akceptacja bądź odrzucenie powodowało pojawienie się nowych grup (a bez tego pojawiało się stosunkowo niewiele wyników). Ponadto interfejs co ileśtam sekund doładowywał nowe dane, co zmieniało kolejność wyników na liście, dezorientując użytkownika. Zamiast liczby obiektów z którymi użytkownika musiał sobie poradzić lepiej byłoby chyba podać ograniczenie dolne ;-)
Niestety, w porównaniu z Google (a to z nimi jesteśmy najczęściej porównywani) nawet nowy interfejs wciąż wypada bardzo słabo. Szukając w Google musimy sobie poradzić tylko z dwoma obiektami: formularzem wyszukiwania i paginacją wyników. Opóźnień nie stwierdzono.
Jak zatem sprawić, aby Szuku było lepsze, bardziej używalne? Jeśli chodzi o opóźnienia, to w tej chwili trwają bardzo intensywne prace nad tym, aby je zminimalizować. Jednym z pomysłów jest prefetching, czyli wprowadzanie do indeksu nazwisk automatycznie, na podstawie jakiejś listy. Prócz tego rzecz jasna nieustannie pracujemy nad optymalizacją silnika. Wreszcie, możemy dać Szuku więcej mocy obliczeniowej (życie w epoce Amazon Web Services ma sporo zalet). Nie martwię się opóźnieniami. Jestem przekonany, że ich wyeliminowanie jest tylko kwestią czasu.
Gorzej jest niestety z ciężarem poznawczym wynikającym z pierwszej hipotezy (z iloma obiektami użytkownik musi sobie poradzić). Przy wyszukiwaniu ludzi praktycznie zawsze mamy do czynienia z kilkoma imiennikami. Szuku nie ma jak samo dowiedzieć się o kogo konkretnie chodzi: musi zapytać użytkownika, który musi przyjrzeć się grupom aby odpowiedzieć. Tak samo, nie da się porównać pod względem trafności dwóch wyników dotyczących różnych osób, więc paginacja raczej nie będzie dobrym rozwiązaniem. Musimy stosować inne metody porządkowania wyników, jak tagi i zakładki.
Myślę o tym, jak uprościć Szuku dniami i nocami. Póki o niestety nie udało mi się wymyślić niczego rewolucyjnego. Pozostaje mi jedynie wierzyć, że któregoś dnia spadnie mi na głowę to jabłko (pies w czapce Sherlocka Holmesa?) i doznam olśnienia. Które zaskutkuje powstaniem Perfekcyjnego Interfejsu Wyszukiwarki Ludzi.
A Wy? Macie jakiś pomysł, jak zmniejszyć ciężar poznawczy Szuku?
-
24-03-09, 21:06
linki powiązanych osób - trzeba klikać na strzałkę - zapewne bug
-
24-03-09, 21:28
@ms: nie do końca to a propos cognitive load :) ale: strzałka to link do wyszukania, a kliknięcie w nazwisko filtruje wyniki do tych, z którymi jest ono powiązane.
-
26-03-09, 14:10
Uch - ile to my tygodni spędziliśmy projektując interfejs... uhaha... Chyba z tuzin profesjonalistów nam doradzał (ludzie od usability, twórca lastfm i inni...).
Ja do tego "cognitive load" dodałbym jeszcze wyróżnienie - funkcje podstawowe od zaawansowanych.
Użytkownik wchodzi na serwis, bo chce wykonać konkretną akcję - np. wyszukać informacje o osobie. To powinno być możliwie proste.
Z drugiej strony - niektórzy użytkownicy oczekują zaawansowanych funkcjonalności, np. możliwości doprecyzowania o kogo chodzi, albo wyświetlenia zaawansowanych informacji w serwisie. Te zaawansowane funkcjonalności nie muszą być aż tak proste w obsłudze, *o ile nie przeszkadzają podstawowym użytkownikom.*
Przykład w produkcie Apple'a: podepnijcie iPhona / iPoda do komputera, włączcie iTunes. Kliknijcie na zakładkę, aby wyświetlić informacje o swojej maszynie.
Pojawiają się Name, Capacity, Soft. ver., Serial number, Phone number.
Zagadka za 10 punktów - jak odczytać numer IMEI, albo build number?
Apple mogłoby umieścić obok przycisk: "Advanced information", ale to zwiększyłoby cognitive load.
Teoretycznie mogłoby to być w menu, ale zaawansowany użytkownik musiałby się dokopać tam, co by irytowało coniektórych (odpowiednik potrzeby instalowania specjalnego skryptu Greasemonkey aby otrzymać dostęp do ukrytych funkcji wyszukiwarki).
Zamiast tego... trzeba kliknąć jeden z labeli. Klikając "Phone number" label zmieni się na "IMEI" i mamy numerek IMEI. Kliknijcie "Software Version", aby zobaczyć numer builda.
To tyle, jeśli chodzi o ukryte przyciski. Zgaduję, że gdyby niektórzy z naszych pracowali w Apple'u, nigdy nie pozwoliliby Jobsowi wprowadzić czegoś takiego :D
-
26-03-09, 14:24
Merlin: Hm, a czy w iPhonie działa wpisanie *#06#, aby zobaczyć IMEI?
-
26-03-09, 15:33
Działa. iPhone rządzi.
Kolejny przykład ukrytej funkcjonalności - numer imei w zwykłych telefonach :)
-
26-03-09, 23:59
Rychu, nie za bardzo rozumiem ideę porównywania usability emaila z usability czata. To przecież zabawki z trochę innej bajki. Sensowniej porównywać usability gmaila z usabiliy jakiegoś-innego-webmaila albo usability jabberowego klienta x vs jabberowego klienta y.
Pozdro
Michał -
27-03-09, 15:07
@Przadka - idea porównywania IM z mailem polega na tym, że oba narzędzia służą do tego samego, a IM i livestreamingi zdają się wypierać obecnymi czasy e-mail. Z jakiegoś powodu ludzie wolą napisać mi, gdzie jest w Wawie dobra wołowina na Blipie, niż wysłac mi mejla z tą informacją. Z jakiegoś powodu komentarze do bloga przychodzą Gtalkiem, a nie formularzem komentowania... Z jakiegoś powodu całkiem sporo młodych ludzi nie ma adresów e-mail (studenci I roku...), bo przecież mają numer gadugadu.
Tymi powodami jest właśnie różnica w wymaganiach poznawczych, jakie stawiają narzędzia komunikacji - ludzie wybierają te, które mniej od nich wymagają.
-
27-03-09, 19:11
mysle, ze wyciagacie zbyt pochopne wnioski. wiadomo ze jak mam wybór:
a. zagadac w jakiejś sprawie na czacie widząc że jesteś online
vs
b. napisać maila
to wybiorę pierwsze, bo jest szybciej, łatwiej etc. no ale to jest konkretny use-case. wystarczy ze nie będziesz na czacie i będę wolał pisać maila. podobnie w sytuacji gdybym chciał pisać do wielu osób jednocześnie np żeby sie umówić na piwo - robienie tego przez gg czy gczata to imo dziwny pomysł.
-
28-03-09, 00:21
@przadka:
Zwróć uwagę, że kiedy chcesz się umówić na piwo z kilkoma osobami, to wysłanie mejla wygra z IM jeśli chodzi o ilość obiektów, z którymi musisz sobie poradzić. Usability zawsze będzie zależeć od zadania, które użytkownik stara się wykonać.
-
29-03-09, 00:50
Zgoda. Właśnie to miałem na myśli w pierwszym poście. Czat i email służą do innych celów/zadań moim zdaniem.
