TheTarPit

Ten Most Wanted Design Bugs

Dzięki genialnym wynalazkom, jakimi są RSS i Bloglines, oraz spostrzegawczym ludziom, do jakich należy Simon Willison, napotkałem w sieci listę Ten Most Wanted Design Bugs.

Mimo, że umieszczone na tej liście błędy są przeważnie związane komputerami Apple, czy przynajmniej opisane w ich kontekście, to dotyczą w równym stopniu wszelkich innych systemów i programów. Wiele z nich jest zakorzenionych bardzo głęboko w istniejących rozwiązaniach technologicznych i jedyne, co można o nich powiedzieć, to „faktycznie, kiepskie.. ale ja tu i teraz nic nie umiem na to poradzić”. Jednak istnieją na tej liście błędy, których można stosunkowo łatwo uniknąć — np. pozycja numer trzy (poniżej wycinek):

Bug Name: Mysteriously dimmed menu items

Duration: 25 years

Supplier: Apple, Microsoft, Sun, Linux, et. al.

Product: All GUIs

Bug: Designers offer no way for users to discover why a given menu or option has been dimmed (grayed out), nor how to turn it back on.

Class of error: Users are teased with options that they cannot access without guessing what was in the designer's mind

Principle: Interfaces should be fully explorable. Users should never have to guess at what unusual confluence of factors will enable them to take advantage of a given capability of a website, application, or system.

Proposed Fix: Make grayed-out objects clickable, revealing what has caused the object to be dimmed and what the user can do about it.

O tym, że w dowolnej rozbudowanej aplikacji niektóre pozycje menu są czasowo niedostępne wie chyba każdy użytkownik. Fakt, że nieaktywne opcje pozostają w menu i tak jest dla użytkownika znacznie lepszy niż gdyby pozycje menu miały się pojawiać i znikać w trakcie działania aplikacji. Mimo wszystko pozostawienie opcji wyłączonej bez słowa wyjaśnienia jest błędem, chociaż rzadko kiedy jest to w ten sposób traktowane. Powiedzmy jednak, że jest to błąd, do którego przyzwyczaili się już wszyscy i wszyscy, łacznie z użytkownikami, nauczyli się go ignorować.

Natomiast „ciekawsze” wydaje mi się niekonsekwentne zachowanie wielu poważnych programów. Na przykład popatrzmy na menu w OpenOffice.org — jeżeli w edytorze nie jest zaznaczony żaden tekst, to pozycje typu „Cut” czy „Copy” są wyłączone. Niby wszystko jasne — są to potencjalnie możliwe działania, aktualnie niedostępne z powodów merytorycznych. Jednak powyżej widzimy „Can't Undo” i „Can't Restore”... „Can't” bo co? Czym w tym momencie różni się brak możliwości cofnięcia operacji (jak się domyślam dlatego, że żadna jeszcze nie została wykonana) od braku możliwości skopiowania tekstu (jak się domyślam z powodu braku zaznaczenia)? Obie te sytuacje są chwilowe i wynikają z aktualnego działania użytkownika. Jednak Ktoś Kiedyś Uznał, że tekst w pozycji dotyczącej cofania operacji będzie „user friendly” i będzie się zmieniał np. na „Undo: Insert”, „Undo: Apply Attributes” itp. A skoro ten tekst się zmienia to potrzebny był tekst dla stanu wyłączonego, a więc... „Can't Undo”. Tymczasem o „Can't Copy” jakoś nikt nie pomyślał. A wyjaśnienie powodu dlaczego właściwie „Can't” to już w ogóle mżonka. I oczywiście sytuacja ta nie jest charakterystyczna dla OOo — identycznie zachowuje się menu np. w Microsoft Office, co tylko potwierdza, że (przynajmniej dla „pakietów biurowych”) jest to zachowanie standardowe.

Powyższe to tylko jeden z tysięcy przykładów, zaledwie mały pretekst, dla którego na pierwszym miejscu listy postawiłbym uniwersalny, drażniący, bezczelny, występujący wszędzie i od zawsze, kompletnie niezniszczalny super hero wśród błędów projektowych aplikacji wszelakich — Jej Wysokość Niekonsekwencję.

Komentarze