Zobacz mnie na GoldenLine
ThinkLab: moja firma

MOJE KSIĄŻKI - AUTOR

Użyteczność w praktyceM. Kasperski, A. Boguska-Torbicz Projektowanie stron WWW. Użyteczność w praktyce, Helion 2008.

Moja książkaM. Kasperski, Sztuczna Inteligencja, Helion 2003.

REDAKTOR MERYTORYCZNY

UmysłD. Casacuberta, Umysł. Czym jest i jak działa, Świat Książki 2007.

100 sposobów...T. Stafford, M. Webb, 100 sposobów na zgłębienie tajemnic umysłu, Onepress 2006.

Istota inteligencjiJ. Hawkins, S. Blakeslee, Istota inteligencji, Onepress 2005.

Blog > Komentarze do wpisu

Defensive design: obsługa błędów

Sześć lat temu udało mi się na Allegro zakupić pamiętny (bo wyróżniający się pod względem designu) model laptopa iBook Clamshell (Blueberry), który wszedł do historii ze względu na zgoła inną rzecz, natomiast że był pierwszym notebookiem wykorzystującym technologię WiFi (a to był rok 1999). Pamiętam do dziś jak z pełną ekscytacją badałem każdy element nieznanego wówczas dla mnie interfejsu.

Pewnego dnia chcąc sporządzić szybką notatkę włączyłem maszynę, poczekałem chwilę na pojawienie się ekranu logowania do systemu, wybrałem portret swojej tożsamości i wpisałem w okienko hasło, po czym... oniemiałem! Okienko wzdrygnęło (dosłownie i w przenośni) się na moje wpisane hasło i potrząsnęło znacząco na NIE. Hasło, które wpisałem nie było poprawne. Tamten dzień był dla mnie znaczący.

 

Mac OS X: logowanie.

Rysunek 1. Panel logowania do systemu Mac OS X.

 

Obsługa błędów to jeden z poważniejszych problemów w projektowaniu interfejsów, a wciąż - niestety - bagatelizowany. Co prawda coraz mniej widuję na ekranach kultowych już komunikatów: "Błąd 404 - Nie odnaleziono pliku" (ten akurat ze strony Wprost), "Błąd 404. Strona o podanym adresie nie istnieje" (a ten z GUS), czy też "Wystąpił Błąd! Brak dokumentu (nr błędu 404)" i to w formacie obrazka .gif (ze strony sejmu), ale ekrany błędów wciąż nie są wystarczająco dobrze projektowane. Na domiar złego, niektórzy z projektantów poczyniają się do obowiązku, by przy okazji tworzenia strony komunikatu z błędem, napisać cały poemat nt. ew. powodów błędu (przykład poniżej).

 

Błąd nr 404 ze strony Wprost.

Rysunek 2. Zrzut strony z błędem 404 ze strony "Wprost".

 

Z pomocą przychodzą dwie szkoły: jedna ta wywodząca się z Apple, opisana m.in. w książce A Smile in the Mind, Beryla McAlhone'a (recenzja na stronie uzytecznosc.pl) i druga, wywodząca się z grupy 37 Signals, znana szerzej pod nazwą projektowania dyfensywnego (defensive design), a opisana w Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points (polskie tłumaczenie wyszło nakładem Helion). W skrócie: obie zmierzają do tego, by 1) komunikaty o błędach uczynić bardziej ludzkimi (wyrzucamy z komunikatu całą terminologię techniczną - kogo obchodzi na który numer błędu natrafłem?), a może nawet i zabawnymi, oraz 2) wspomagać wyjście z sytuacji, np. podsuwając linki, któe pozwolą mi wyjść z opresji (do strony głównej, do systemu pomocy, FAQ, wyszukiwarki, etc.).

W Polsce dobrymi przykładami świeci serwis społecznościowy Golden Line (brawo dla konkurencji! :)), gdzie komunikaty o błędach brzmią po prostu po ludzku.

 

Komunikaty o błędach z GoldenLine.

Rysunek 3. Komunikaty błędów ze strony serwisu społecznościowego GoldenLine.

 

Przykładem zaś wdrożenia metodyki Smile Mind jest chociażby komunikat z Cars.com.

Dla mnie prawdziwym majstersztykiem w ostatnim czasie była strona CrazyEgg. Wchodząc na jej domenę, pewnego razu stwierdziłem, że zamiast znanej mi strony widnieje komunikat mówiący, że właśnie odbywa się konserwacja serwera i przez pewien czas strona będzie wyłączona. Natomiast jeśli tylko chcę mogę... pograć sobie w grę (wykonaną w technologii flash), która widniała tuż poniżej. Nim się obejrzałem okazało się, że na stronie - której przecież de facto nie było - spędziłem ok. 20 minut, grając w najlepsze w rzucanie jajkami w przechodzących ludzi. :)

Nice!

sobota, 30 czerwca 2007, marekkasperski

Polecane wpisy

  • Definicja UX: Przez wskazanie... Feature na rynku nieruchomości

    Wstęp [można pominąć] 0.1. User Experience to nie jest ' wziu-wziu ' w HTML5. To nawet nie jest front-end. Sorry , nie przekonacie mnie w licznych rozmowach;

  • Z półki projektanta: Koszyk

    Krótki komiks o projektowaniu. *** To jest koszyk na zakupy. To jest ładny koszyk na zakupy, jednak pełni taką samą rolę jak zwyczajny koszyk. Dla sklepu (a

  • Polski Internet śpi

    Nie wiem, czy to za sprawą globalnych dużych graczy, którzy (pod względem zasięgu) przejęli polskich użytkowników, a z nimi polskie budżety marketingowe, ale wy

TrackBack
TrackBack w tym blogu jest moderowany. TrackBack URL do wpisu:
jak wykorzystać przerwy techniczne? z Dominik Koza słowem o słowie
Nie piszę już nawet w liczbie pojedynczej, bo na moje używanie języka wpływa nadmiar informacji o problemach naszej klasy. Przerwa techniczna w liczbie pojedynczej byłaby na dziś dzień odrealnieniem. Robert Drózd we wpisie 8220 jak informowa... »
Wysłany 2008/01/12 17:15:49
Komentarze
2007/07/01 15:45:35
no ten pomysł z gierką we flashu jest rewelacyjny. bo poza tym to nawet gdyby informacja o tym, że nie można wyświetlić strony albo czegoś uruchomić była nie wiem jak słodka, to po pewnym czasie na jej widok dostawałabym mdłości
-
2007/07/03 16:02:48
Obejrzyj komunikaty błędu serwisu last.fm --- boskie ;)
A z innej strony sprawa wygląda tak, że komunikat błędu powinien być dostosowany do natury usługi/serwisu w którym występuje. I tutaj często np. numer błędu jest niezbędny dla poprawnej diagnozy problemu z jakim użytkownik przychodzi do BOKu/helpdesku etc.
Przykład z życia poczty elektronicznej. Użytkownik zgłasza się, bo nie może wysłać poczty i podaje cytat komunikatu błędu: u mnie różnica między błędem 4.0.1 a (np.) 4.0.5 może być kluczowa dla szybkości diagnozy.
Dlatego jeśli mam wybierać jakąś z 'szkół' wskazanych w twojej notce, to skłaniam się do komunikatu NIE stroniącego od technicznej terminologii i - wręcz - zmuszającej użytkownika do samodzielnego poszukiwania rozwiązania. To jest jak z analogią: dajesz wędkę, a nie rybę....
-
2007/07/04 10:25:16
Re: FUNDAMENTALISTA

Co do kwestii, że "komunikat błędu powinien być dostosowany do natury usługi/serwisu w którym występuje" - tak, to prawda, przeoczyłem ten fakt we wpisie. Trudno sobie wyobrazić podobnie brzmiący lakonicznie komunikat co w GoldenLine, ale np. na stronie któregoś z hospicjum. W tej sprawie pełna zgoda.

Co do drugiej kwestii, że jednak przy komunikatach błędu potrzebny jest zapis techniczny, gdyż przydaje się dla BOK. Polemizowałbym. Albo - inaczej: komunikat n. błędu powinien jednak być dla użytkownika, nie dla BOK. Dla BOK, w ramach strony z błędem, umieściłbym button z napisem "Wyślij info. o błędzie". Użytkownik, który by skorzystał z tej funkji, wysyłałby jednocześnie na adres BOK nr. błędu, który szedł by z automatu, adres url strony, na której otrzymał błąd oraz mógłby - jeśli by chciał odpowiedź - podać swój adres e-mail, w celu umożliwienia skontaktowania się z nim kogoś z BOK.

Wydaje mi się to optymalnym rozwiązaniem, bo godzi kilka scenariuszy użytkowania.