Ostatnim bastionem, który broni się przed ofensywą WYSIWYG, są profesjonalne narzędzia - np. edytory LaTeX. Świetnie! “Użytecznie” nie znaczy zawsze “najłatwiej”. W przypadku narzędzia pracy programisty może znaczyć “najefektywniej” albo “najszybciej”.

Dzisiaj - 35 lat od premiery Bravo - WYSIWYG jest jednak jedną z fundamentalnych zasad projektowania interfejsów użytkownika. Tak mocno zakorzenioną jak okna czy ikony. Tak oczywistą jak prąd w naszych mieszkaniach, że dopiero, kiedy coś przestaje działać - myślimy o tym.

Trzeba oczywiście rozróżnić dwa zupełnie różne problemy z WYSIWYG:

1. aby uzyskać jakiś efekt (np. pogrubienie) muszę znać odpowiednie znaczniki (np. “**”)
2. oprogramowanie zachowuje się w sposób nieprzewidywalny - łamię zasadę WYSIWYG

Pierwszy przypadek to świadomy wybór projektowy. Użytkownik musi wiedzieć jak uzyskać efekt. Drugi przypadek to łamanie reguły najmniejszego zaskoczenia. Dobrym przykładem może być system wiadomości w Basecampie (zarządzanie projektami online).

Zrzut ekranu powyżej przedstawia okno edycji nowej wiadomości. Wpisując treść można spodziewać się, że zostanie ona przetworzona na listę wypunktowaną, lub w najgorszym wypadku zostaną zachowane oryginalne myślniki na początku linii.  Rezultat jest co najmniej zaskakujący.

Lista została zwinięta do jednego wiersza. To zdecydowanie nie jest efekt, którego można się spodziewać.  Aby uzyskać listę (jak poniżej), należy użyć znaku “*” zamiast myślnika (”-”).

Brak odpowiednich znaczników nie usprawiedliwia jednak zachowania programu, które po prostu nie jest uprzejme. Brak odpowiednich znaków może usprawiedliwiać to, że Basecamp nie generuje wypunktowanej listy z wcięciem, ale nie może usprawiedliwiać zignorowania podziału na wiersze.

Podobny problem dotyczy MediaWiki (silnika Wikipedii).

Wprowadzony powyżej tekst, po zapisaniu, będzie wyświetlony tak: 
Zobacz:

• hasło WYSIWYG w angielskiej Wikipedii
• artykuł o edytorze tekstowym Bravo w angielskiej Wikipedii
• Basecamp - oprogramowanie do zarządzania projektami firmy 37signals
• MediaWiki - silnik Wikipedii

Historia zwykle wygląda podobnie: wchodzę na stronę restauracji, po dłuższej chwili znajduję menu, wybieram co chcę zamówić, chwytam za telefon i… teraz muszę znaleźć stronę z numerem telefonu. Znajduję ją jednak po dłuższej lub krótszej chwili, dzwonię, podaję numer telefonu, adres, przechodzę do momentu w którym składam właściwe zamówienie i… zapomniałem co chciałem zamówić - muszę znowu szukać strony z menu.

Tego typu historia przytrafia mi się nagminnie. Strona internetowa restauracji (zwłaszcza restauracji typu fast-food) mogłaby w większości przypadków przypominać ulotki pizzerii - powinna dawać łatwy dostęp do menu, adresu, godzin otwarcia i telefonu. A w przypadku stron restauracji umożliwiających zamówienie jedzenia na telefon - numer telefonu powinien być dostępny tuż obok menu. Tymczasem menu i numer telefonu często ukryte są gdzieś w hierarchii witryny.

Tak na prawdę problem dotyczy nie tylko KFC.pl, dotyczy on stron większości restauracji oferujących możliwość zamówienia jedzenia z dostawą do domu, z jakich miałem okazję korzystać.

Problemy te biorą się z braku wsparcia (albo zrozumienia) dla celów i potrzeb docelowych użytkowników. Na stronie KFC prawdopodobnie nie określono po co przychodzi na nią użytkownik i co jest dla niego najważniejsze. Jednym z najczęstszych powodów odwiedzin tej strony jest z pewnością chęć złożenia zamówienia przez telefon. Tymczasem strona internetowa bardzo słabo ten cel wspiera. Można było tego uniknąć przez zaprojektowanie interakcji w serwisie np. przy pomocy  scenariuszy użycia.

Scenariusze użycia to jedno z podstawowych narzędzi projektanta interakcji. Rozpisanie zadań, które użytkownik ma realizować w serwisie pozwala zapewnić, że w każdej chwili będzie miał dostęp do aktualnie potrzebnych informacji oraz że będzie wiedział, co powinien zrobić w danej chwili.

Zobacz:

• strona internetowa KFC
• strona internetowa pizzerii Da Grasso
• strona internetowa pizzerii Dominium
• strona internetowa Pizzy Hut

Teoretycznie wydaje się, że to dobry pomysł, może dzięki temu będziemy mogli w różny sposób śledzić  działalność znajomych w serwisie w zależności od tego jak dobrze ich znamy. Może i tak, ale:

• Biznes.net w żaden sposób nie tłumaczy po co to podajemy
• Nie zauważyłem, żeby te informacje były w jakikolwiek sposób wykorzystywane
• Nie można tego kroku pominąć

Niezależnie od tego, czy to faktycznie jest przydatne, czy nie - czy faktycznie możemy ocenić na ile kogoś znamy? I jaka jest różnica pomiędzy znajomością ‘bardzo słabą (20%)’, a ‘na razie słabą (30%)’? Znajomości mają to do siebie, że ewoluują w czasie.  Dodatkowo stopień znajomości ‘w realu’ często nie odpowiada znajomościom w sieci. Osoby, które znam tylko przez internet w moim odczuciu znam relatywnie słabo - natomiast z punktu widzenia sieci społecznej właśnie te znajomości są dla mnie wartościowe -  z tymi osobami najczęściej chcę być w kontakcie, chcę wiedzieć co się u nich dzieje, jakich mają znajomych.

A jakie Wy znacie sposoby oceniania stopnia znajomości w sieciach społecznych? Może jakiś inny serwis robi to lepiej?

Zobacz:

• Biznes.net

W czym więc problem?
Intuicyjne jest to co widzieliśmy wcześniej. Strony dyskusji do artykułów w żaden sposób nie przypominają komentarzy w innych serwisach internetowych i blogach. Wprowadzenie innej formy to złamanie reguły najmniejszego zaskoczenia.

Dodatkowym problemem jest konieczność znajomości składni, aby korzystać ze stron dyskusji. Ile dwukropków należy postawić przed swoją wypowiedzą?

Który przycisk nad polem edycji służy do wstawiania swojego podpisu? Który do dołączania pliku?

Każde rozwiązanie ma swoje dobre i złe strone.  W tym przypadku zaletami są  elastyczność i większe możliwości prowadzenia dyskusji. Ceną natomiast jest większa bariera wejścia.

Powstaje pytanie: ile osób z merytoryczną wiedzą i czasem Wikipedia “traci” przez wysoką barierę wejścia?

Czym jest bariera wejścia?
Tworząc trudny i nieintuicyjny interfejs zwiększamy barierę wejścia - czyli niezbędną wiedzę, którą musi posiadać użytkownik, aby korzystać z serwisu.
W optymalnym przypadku bariera wejścia nie powinna być wyższa niż podstawowa umiejętność obsługi przeglądarki.

Zobacz:

• Polska Wikipedia
• Strona dyskusji dla hasła “Polska”

Terminologia branży lub firmowy żargon są zrozumiałe dla pracowników. Dla klientów nie stanowią żadnego ułatwienia - wręcz przeciwnie sprawiają, że zrozumienie oferty jest trudniejsze. Trzeba mówić w taki sposób, żeby mógł nas zrozumieć.  Czy jednak klienci indywidualni banku znają różnicę między kontem lokacyjnym a lokatą terminową albo potrafią zdefiniować swoją potrzebę jako “konto a’vista”?

Dobrze zaprojektowana komunikacja to po prostu mniej kłopotów dla klienta. Udostępnienie wielu widoków, trybów przeglądania informacji i “przechowalni” na artykuły można uznać za dodatkową funkcjonalność (czy faktycznie w tym wypadku pomocną?). Z pewnością nie jest to rozwiązywanie faktycznych problemów klientów.

Zobacz:

• serwis Raiffeisen Bank Polska S.A.
• artykuł How Little Do Users Read?

Pewnego dnia pewien S. zakupił bilet lotniczy na stronie linii lotniczych SWISS. Proces rezerwacji poszedł sprawnie, i niebawem w skrzynce S. pojawił się e-mail z potwierdzeniem zakupu:

W wigilię wylotu S. otrzymał e-mail zapraszający go do internetowej rejestracji pasażerów. W tym celu S. potrzebował numer swojego biletu elektronicznego, który odnalazł w mig (w e-mailu, który widzieliśmy wyżej). S. otworzył e-mail i skopiował numer biletu:

Następnie S. przełączył się do okna ze stroną webcheck-inu i wkleił numer biletu w odpowiednie miejsce:

Po wypełnieniu pozostałych pól, S. chciał zakończyć ten etap rejestracji klikając “Dalej”. Strona mu jednak na to nie pozwoliła:

Zgodnie z poleceniem S. kliknął ikonę znaku zapytania i dowiedział się, że cyfry w numerze biletu muszą być wpisane jednym ciągiem, bez spacji.

— No tak —pomyślał S. — faktycznie w numerze biletu, który wkleiłem, spacje były. Bo przecież takim go dostałem od SWISS. A mechanizm na stronie webcheck-inu obciął aż 3 ostatnie cyfry, bo sztywno nałożony limit znaków w tym polu policzył spacje jako cyfry. Dlaczego ta sama firma raz wysyła mi numer biletu ze spacjami, a innym razem każe podawać go bez spacji? Dlaczego — S. zachodził w głowę — nie można było tego ujednolicić i spojrzeć na proces rejestracji on-line nieco bardziej globalnie? Dostrzec, że klient może skopiować numer biletu z e-maila, bo to jeden z najwygodniejszych sposobów?

S. znalazł szybko rozwiązanie problemu, choć nie był zadowolony, że musiał w ogóle szukać. Jako leniwy typ, nie usunął ręcznie spacji i nie dopisał ręcznie 3 ostatnich cyfr. Skopiował numer w postaci bezspacjowej z nazwy załącznika (potwierdzenie zakupu w pliku PDF):

I tym razem się udało:

S. zarejestrował się na ten lot i doleciał szczęśliwie, a nawet wrócił później do Polski. Ale pozostała pewna niechęć do firmy, która nie zadała sobie trudu, by ujednolicić interfejs, z którym spotyka się użytkownik i by zaprojektować proces rejestracji globalnie, a nie tylko od pewnego momentu, z pominięciem jego początku, kiedy użytkownik w jakiś sposób zdobywa numer swojego biletu.

Zobacz:

• swiss.com
• swiss.com/webcheckin

Kiedy twórcy Basecampa chcą przekazać jakieś informacje swoim klientom, w centralnym miejscu aplikacji pojawia się ogłoszenie. Zawsze zwięzłe, zawsze pisane uprzejmym językiem, zawsze utrzymane w podobnym tonie:

Dziękujemy za Twoje wsparcie, wiemy, że Basecamp jest dla Ciebie ważnym narzędziem i jako taki, nie powinien być zawodny.

Często zawierają odnośnik do pełnej treści ogłoszenia, gdzie można znaleźć więcej informacji.

Ogłoszenia pojawiają się często i jest to ich główna zaleta. Dodatkowo, w przypadku problemów z wydajnością lub działaniem serwisu, informacje o problemach pojawiają się bardzo szybko, zanim problemy te zostaną rozwiązane, dzięki czemu klienci są stale na bieżąco. Komunikacja wychodząca od twórców Basecampa jest szybka, szczera i skuteczna.

Usprawnieniem, które można by zaproponować, byłoby rozróżnianie różnych typów ogłoszeń, np. kolorami lub wg klucza ikonograficznego. Obecnie wszystkie powiadomienia wyglądają tak samo, i zwykłe powiadomienie o nowej funkcji w pierwszej chwili wygląda dokładnie tak samo, jak przeprosiny za niewydolność serwerów.

Poniżej przedstawiamy kilka przykładowych informacji:

• ogłoszenie o nowej funkcji

•  informacja o 4. urodzinach Basecampa

•  informacja o doświadczanych problemach wydajnościowych (podana zanim problem został rozwiązany)

Na szczególną uwagę zasługuje ostatnie powiadomienie. Wczesne informowanie o problemach (także jeśli wystąpiły z naszej winy) jest dla klientów zapewnieniem o dobrych chęciach i o dbaniu o nich. Nie należy się  tego wstydzić czy bać!

Zobacz:

• http://www.basecamphq.com/tour

Gdy na stronie ztm.warszawa.pl wejdziemy w zakładkę “rozkłady jazdy”, naszym oczom ukazuje się taki ekran:

W który link powinniśmy kliknąć jeśli chcemy sprawdzić rozkład jakiegoś autobusu? Już sam fakt zgrupowania w jedną listę różnych rozkładów, zmian w rozkładach i oznaczeń w nich stosowanych, bez żadnego rozgraniczenia, jest wystarczającym utrudnieniem dla osoby która styka się z tą stroną pierwszy raz. Ale nawet ktoś, kto korzysta z tej strony codziennie, musi się chwilę zastanowić.

ZTM prezentuje zarówno aktualny rozkład jazdy, jak również rozkład który dopiero co wygasł oraz rozkład który niebawem wejdzie w życie.  Przy czym nie jest to ścisłą regułą - czasem jednego z dwóch ostatnich rozkładów nie ma. Dodatkowym problemem jest to, że aktualny rozkład nie jest w żaden sposób wyróżniony - rozkłady są oznaczone wyłącznie datą ich obowiązywania. Chociaż prawdopodobnie umieszczenie tych trzech różnych rozkładów ma sens, to jestem pewien, że absolutna większość odwiedzających tę stronę osób chce się zapoznać po prostu z aktualnym rozkładem i nigdy nie potrzebowały sprawdzić rozkładu  wczorajszego, czy tego, który będzie obowiązywał za 3 dni.

Problemów z architekturą informacji w rozkładach ZTM jest więcej. Uciążliwe jest np. to, że z poziomu rozkładu jazdy danej linii nie możemy obejrzeć bezpośrednio rozkładu jazdy danego przystanku. Nie możemy wobec tego łatwo sprawdzić przesiadek czy innych możliwości dojazdu

Osobnym problemem jest wyszukiwarka połączeń, która jest… zbyt precyzyjna. Praktycznie na każde zapytanie podaje długą listę możliwych dojazdów z różnymi możliwościami przesiadek. W trakcie precyzowania zapytania mamy do wyboru tryby: normalny i stary. Nie jest opisane czym to się różni i co zmienia. Przy prezentacji wyników system informuje, że są one posortowane według “praktycznej jakości połączenia”, ale co to jest praktyczna jakość?

Sprawdzenie rozkładu jazdy autobusu czy tramwaju to codzienny rytuał wielu warszawiaków. Przypadek ten został nam zresztą zgłoszony przez sfrustrowanego czytelnia. :) Z pewnością opracowanie od nowa i przygotowanie porządnej architektury informacji na stronie pozytywnie wpłynęłoby na jej wizerunek. I chociaż przy takiej ilości informacji nie byłoby to proste, to jednak patrząc na to jako na inwestycję długoterminową - z pewnością byłoby opłacalne.

Zobacz:

• Rozkłady jazdy ZTM wg. linii

Strona oferująca pliki do pobrania gry FreeCol próbuje pomóc użytkownikowi proponując odpowiednią dla jego systemu operacyjnego wersję gry. W zamierzeniu twórców strony ma to prawdopodobnie ułatwić podjęcie decyzji o pobraniu gry.

Istnieje jednak ryzyko, że tak przedstawiona podpowiedź zostanie zignorowana przez odwiedzającego stronę czytelnika, który wiele razy widział już podobnych rozmiarów i podobnie wyśrodkowane banery na innych stronach. Użytkownik zacznie więc szukać wersji dla swojego systemu poniżej podpowiedzi, na liście pozostałych plików, gdzie oczywiście jej nie znajdzie, skoro strona wykryła typ jego systemu i spróbowała ułatwić mu zadanie.

Przewrotne, złośliwe, ale jednak prawdziwe niebezpieczeństwo wiąże się z próbami wyróżniania niektórych informacji pośród innych. Dobrą praktyką jest zatem zawsze sprawdzać, czy wyróżnienie nie przynosi przypadkiem efektu odwrotnego do zamierzonego.

Zobacz:

• Strona pobierania FreeCol
• Wikipedia: ślepota bannerowa

Czytelniczka pisze:

Chcę znaleźć pociąg z Brwinowa do Warszawy Śródmieście. Wypełniam formularz, wysyłam, i dostaję odpowiedź: “Wprowadzenie nie jest jednoznaczne. Proszę wybrać z listy powyżej.”Lista wygląda następująco:

- Warszawa Śródmieście //dokładnie tak jak wpisałam!
- Warszawa Śródmieście WKD // słodkie, ale WKD nie jeździ z Brwinowa
- Chrzanów Śródmieście //Hę?

No i muszę wysłać formularz ponownie, co trwa.

Słuszne jest rozgoryczenie naszej czytelniczki, chociaż system działa poprawnie - dla wpisanej stacji docelowej dopasował w bazie danych kilka możliwych opcji i pozwala użytkownikowi doprecyzować zapytanie. Z punktu widzenia użytkownika jest to zbędny krok - system w końcu sam się domyślił o którą stację chodzi (pierwsza opcja to właściwy wybór) i czeka żeby mu jeszcze raz powiedzieć, że faktycznie ma szukać połączenia pomiędzy tymi dwiema stacjami.

Ten dodatkowy krok jest jeszcze bardziej uciążliwy, gdy nie wiemy, do której ze stacji chcemy jechać. Po wybraniu jednej z możliwości, musimy cofnąć się do ekranu z wyborem, zmienić opcję, potwierdzić wybór, cofnąć się do ekranu z wyborem itd.

Okazuje się, że ten krok można było pominąć - wystarczyłoby na przykład, żeby w przypadku konieczności wyboru jednej z kilku stacji system wyświetlał połączenia z/do aktualnie wybranej stacji, pozostawiając możliwość wyboru. Dzięki temu nasza czytelniczka od razu dostałaby rozkład, który ją interesuje, a osoby chcące sprawdzić różne możliwości miałyby mniej klikania.

Takie usprawnienie spodobałoby się zwłaszcza osobom sprawdzającym połączenia w biegu za pomocą przeglądarki w telefonie komórkowym. W tym przypadku wyjątkowo sprawdza się znane powiedzenie - że czas (i ilość przesłanych danych) to pieniądz.

Zobacz:

• rozklad.pkp.pl