Zespół narzędzi…
Najprawdopodobniej odpowiedź na powyższe pytanie brzmi tak: interfejs tego przykładowego programu był źle zaprojektowany. Jak to możliwe, że rzecz z pozoru tak błaha, jak zewnętrzna forma, tak bardzo wpływała na komfort pracy? Otóż wcale nie jest to czynnik mało istotny. Interfejs użytkownika to nie tylko kolorki przycisków czy kształt ikon – jak mówi naukowa definicja, to cały “zespół narzędzi programowych, które umożliwiają komunikację między człowiekiem i systemem informatycznym” (I. Dubielewicz, materiały wykładowe Politechniki Wr.). W procesie konstruowania interfejsu ważne jest nie tylko dostosowanie go do specyfiki wykonywanych zadań, ale również do użytkownika. Ściślej rzecz ujmując, do modelu użytkownika. Co to znaczy, o tym za chwilę, teraz wytłumaczę jeszcze, co wiedza o projektowaniu interfejsów może dać szerokiemu gronu użytkowników popularnych programów.
Otóż będziemy mogli dzięki temu ocenić, czy aplikacja, z którą się właśnie zetknęliśmy, została opracowana z myślą o naszej wygodzie. Wobec mnogości dostępnych powszechnie popularnych programów będziemy w stanie odrzucić software zaprojektowany niedbale i odszukać taki, którego użytkowanie nas nie męczy. Oczywisty jest także inny pożytek – grono przyszłych i obecnych programistów może się dzięki temu dowiedzieć, jak napisać aplikację, która cieszyć się będzie dużą popularnością. Naturalnie dotknę tu tylko niektórych aspektów projektowania GUI (Graphical User Interface), nie mając nawet nadziei na zbliżenie się do kompletności i pomijając zupełnie kwestie związane z interfejsem tekstowym (CLI – Command Line Interface).
Modelki i modele
“Interfejs użytkownika jest dobrze zaprojektowany wtedy, gdy program zachowuje się dokładnie tak, jak oczekuje tego użytkownik”. Koniec, kropka – w zasadzie na tej podstawowej prawdzie można by zakończyć wykład o projektowaniu interfejsów graficznych, jako że wszystkie następne zasady wywodzą się z tej pierwszej. Ponieważ jednak nawet najbardziej oczywiste wnioski nie muszą być wcale proste do wysnucia, opiszemy jeszcze kilka wskazówek dotyczących projektowania dobrych interfejsów.
O co chodzi w tej podstawowej zasadzie? Otóż każdy, nawet początkujący użytkownik programu ma jakieś oczekiwania i wyobrażenia, jak powinien on działać. To właśnie nazywane jest modelem użytkownika. Przykład: osoba po raz pierwszy siedząca przed edytorem tekstu może go traktować jak niezapisaną kartkę. Ma zatem pełne prawo oczekiwać, że – podobnie jak w życiu – po umieszczeniu na niej słów nie trzeba wykonywać jakichkolwiek dodatkowych czynności w celu zachowania treści. Sęk w tym, że programista (lub zespół twórców aplikacji) ma odmienny model działania programu (w naszym przykładzie: konieczne jest zapisanie pliku). Ich zadaniem jest wobec tego maksymalne zbliżenie modelu programu do modelu użytkownika. Można próbować zmienić model użytkownika, jest to jednak zadanie bardzo trudne i w większości przypadków kończące się niepowodzeniem.
Skąd wiadomo, jak wygląda model użytkownika? O to trzeba zapytać… ich samych. Kolejną zatem zasadą jest testowanie programu na użytkownikach. Nie są do tego celu koniecznie potrzebne potężne laboratoria – wystarczy dosłownie kilku “userów”. Zgromadzone do tej pory doświadczenia dowodzą dodatkowo, że jeśli model programu nie jest prosty, to najprawdopodobniej różni się on od modelu użytkownika. Wykorzystują oni bowiem zawsze najprostszy możliwy model.
Chwila poezji
Jeśli programiści nie znają modelu użytkownika lub koniecznie chcą przekazać mu własny model programu, posługują się w tym celu metaforą. Najbardziej znaną jest metafora biurka, z którą mamy do czynienia podczas pracy w systemach Windows czy Mac OS. Ich pulpity przypominają biurko np. z drukarką czy koszem i innymi elementami, którymi można manipulować. Jest to metafora czytelna. Niestety, zdarzają się złe metafory – takich lepiej nie stosować w ogóle. Część z nas pamięta zapewne tzw. Aktówkę (Briefcase) z systemów Windows 9x/Me. Czy ktoś tego narzędzia kiedykolwiek używał? Większość pytanych przeze mnie osób twierdziła, że choć znała teoretycznie ideę jego działania, nigdy nie była jej na tyle pewna, by zastosować Aktówkę do praktycznych zadań.
Wszyscy znamy okno opcji z kartami ułożonymi w dwóch rzędach (np. opcje Worda). Ta dość czytelna metafora ma jednak wadę – w pewnych sytuacjach zachowuje się niezgodnie z prawami fizyki. Otóż chodzi o moment, gdy klikamy kartę położoną w tylnym rzędzie. Nie wiedząc dlaczego, zmienia się kolejność ułożenia kart – zamieniają się one miejscami: tylne stają się przednimi i na odwrót. Czasami spotkać można nie do końca doskonałe rozwiązanie tego problemu – przy dużej liczbie kart część jest zakryta i trzeba je odsłaniać, przewijając je dodatkowym przyciskiem.
