Spróbujmy w tej części naszego cyklu uzasadnić potrzebę weryfikacji dwóch elementów oprogramowania: interface'u użytkownika i dokumentacji eksploatacyjnej.

Podobnie jak w innej dziedzinie - motoryzacji, silnik w samochodzie ma wprawdzie istotne znaczenie dla osiąganych przezeń szybkości, ale z punktu widzenia bezpieczeństwa użytkowania ważniejsza jest sprawność układu kierowniczego i hamulcowego oraz znajomość przez kierowcę kodeksu drogowego, którego lepiej nie uczyć się z bryków. Podobnie jest w informatyce. Straty w systemach powstałe w wyniku błędów sterowania można pod względem kosztów spokojnie porównać co najmniej z kosztami poważniejszych kolizji samochodowych. Tak więc interfejs i dokumentacja, jako podstawowe narzędzia sterowania oprogramowaniem, wymagają równie pieczołowitej oceny jak pozostałe jego elementy.

Krytyczne "międzymordzie"

Spójrzmy teraz na system informatyczny kompleksowo, tzn. włączmy do niego także użytkownika i spróbujmy odpowiedzieć na pytanie: jaka część systemu informatycznego jest w istocie najpowolniejsza i - co ważniejsze - nie można jej działania przyspieszyć prostymi środkami technicznymi. Doświadczenie wskazuje, że najwolniej przebiega wprowadzanie przez użytkownika informacji do systemu. Niedostateczna jego przyjazność sprawia, że w wielu przypadkach użytkownik nie wie, jak zachować się w konkretnej sytuacji. Co gorsza często nie znajdzie recepty w niekompletnej lub napisanej po bałaganiarsku dokumentacji.

Interface graficzny miał bez wątpienia przełomowe znaczenie w sposobie komunikowania się człowieka z komputerem. Pamiętajmy jednak, że okna i ikony mogą albo niezwykle ułatwić posługiwanie się programem, ale też, gdy są przygotowane niewłaściwie, zdecydowanie je utrudnić. Aby zrozumieć jak ważne są zasady ich konstrukcji, barwy, animacji a także wspomagającego je dźwięku, nie powinniśmy opierać się na wrażeniu, które pozostawia krótki kontakt w czasie demonstracji programu. Musimy brać pod uwagę fakt, że chodzi w istocie o jednostajną, wykonywaną dzień po dniu, wielogodzinną pracę, z oczami utkwionymi w ekranie. Po pewnym czasie użytkownikowi zaczyna się śnić matryca ekranu. Kombinacje figur i ich ruchu, kolorów czy dźwięków, potrafią wywoływać niepokój czy wręcz agresję. Na potwierdzenie tej tezy nie trzeba wielkich badań. Spróbujmy zamknąć oczy po długim seansie TV.

Niestety niektórzy producenci oprogramowania za "standard" uznają monotonię, a wyrazistość ikon utożsamiają z ich jaskrawością i agresywnością. Niejeden programista większą wagę przywiązuje do "atakującego" odbiorcę wyglądu interfejsu, a dokumentację zamienia w rodzaj komiksu. Stąd też w przypadku oceny oprogramowania, do zbadania jego właściwości dialogowych należy kierować zarówno informatyków, jak i specjalistów z dziedziny zarządzania, której ten system dotyczy. W systemach o szczególnej wadze, wśród weryfikatorów, powinni znaleźć się też: psycholog, plastyk, architekt, inżynier ergonomii.

Dla każdego coś innego

Nie jest to bynajmniej przesada. Weźmy np. system kontroli ruchu lotniczego, gdzie wszystko jest dokładnie rozpracowane, wytrenowane, sprawdzone i powtarzane setki lub tysiące razy. Aby "normalny, zdrowy" człowiek mógł w sposób koncentrować się przez kilka godzin na obrazkach, interface winien spełniać szczególne wymogi. Rozwiązania dialogowe muszą w tym przypadku pobudzać operatora, zawierać sprawdziany jego sprawności psychofizycznej, skuteczne, lecz nie doprowadzające do furii. Jednocześnie gama bodźców powinna być eskalowana w taki sposób, aby w sytuacji awaryjnej, wywoływały one jedynie stres, pobudzający do maksymalnego wysiłku psychicznego i intelektualnego, nie prowokując paniki.

Przykład jest oczywiście z gatunku ekstremalnych. Nie można jednak wykluczyć przypadku z innej łączki. Zdarzyć się może bowiem snadnie, że skutek słabej widoczności komunikatu o błędzie, księgowa dostaje zawału serca, widząc ostateczny wynik obliczeń, który prowadzi ją wprost do gabinetu prokuratora.

Jak z tego widać, interface graficzny również musi uwzględniać w znaczącym stopniu specyficzne cechy potencjalnych użytkowników programów.

Jakie elementy i dlaczego weryfikować?

Nie liczmy jednak, że znajdziemy łatwo gotowe, uniwersalne przepisy na weryfikację wyżej wymienionych właściwości oprogramowania. Sprawdza się tu stara anegdota:

Co zrobić, żeby wyszkolić wyżła na kuropatwy?

Nic.

Wystarczy, aby zaaportował 1000 kuropatw". Odpowiedzmy więc na pytanie: co sprawdzać, w nadziei, że uczynią to wspólnie znawcy tej dziedziny zarządzania, którą system ma wspomagać i informatycy. Będą to:

INTERFACE:

1. Konstrukcja obrazów, ich odnawianie i animacja;

przykładowe błędy: słabe wydzielenie obszarów, a szczególnie pól zawierających dane informacyjne i dane do wprowadzenia, rozmieszczanie w różnych ekranach tych samych pól w innych miejscach, nieczytelne "przelatujące" na szybszym sprzęcie komunikaty, nadużywanie stałych migających podkreśleń, czy napisów

2. Dobór kolorów;

przykładowe błędy: nieuzasadniona zbyt duża kontrastowość całych ekranów lub ich elementów, utrudniająca wielogodzinną pracę. Niewłaściwa jest jednak też przesada "w drugą stronę", czyli stosowanie np. koloru czerwonego, gdy treść komunikatu nie ma charakteru ostrzegawczego.

3. Poprawność i komunikatywność słownictwa;

przykładowe błędy: nadużywanie slangu informatycznego np. "Z08" zamiast "Zamówienia w sierpniu", bezsensowne zakładanie, że jeżeli ktoś użytkuje komputer to zna angielski, a także ortodoksyjne stosowanie normatywnych określeń również w przypadkach, gdy są one zastępowalne pojęciami z języka potocznego.

4. Skuteczność "helpów" w sensie ich kontekstowości i wielopoziomowości informacji; przykładowe błędy: help sztywny, tzn. nie zakładający, iż użytkownik z czasem uczy się i zaczynający zawsze wyjaśnienia "od Adama i Ewy" oraz taki, który nie podaje informacji bezpośrednio dotyczącej wykonywanej operacji

"natrętny help" wyświetlający się przy każdej pomyłce, również wtedy gdy nie żądamy wyjaśnienia.

5. Ergonomia systemowych klawiszy funkcyjnych;

przykładowe błędy: niektórzy projektanci zapominają o numerycznym obszarze klawiatury. Dla osób przyzwyczajonych do korzystania z niej w praktyce (lub często wyłącznie z niej) oznacza to zdecydowany spadek wydajności pracy. Dla profesjonalistki (start w finale mistrzostw świata w maszynopisaniu) zmiana standardu klawiatury oznaczała 2 lata forsownych ćwiczeń, aby dojśc do poprzedniej biegłości.

DOKUMENTACJA

1. Zgodność opisu dokumentacyjnego z ekranem.

2. Poprawność układu, umożliwiająca szybkie wyszukanie informacji i uwzględniająca proces edukacji użytkownika; przykładowe błędy: rozwiązania są złe jeżeli nie uwzględniają użytkownika zupełnie nieprzygotowanego, a równocześnie nie pozwalają łatwo wybrać z całości dokumentacji elementów dostosowanych do poziomu wiedzy osób o większym doświadczeniu.

3. kompletność i wszechstronność (wielostronność): czyli stopień uwzględniania wszystkich możliwych sytuacji, jakie mogą zaistnieć w trakcie posługiwania się software'm.

Na zakończenie jedno zdanie na temat psychologicznych aspektów interface'ów i dokumentacji. Interfejs nie może poganiać użytkownika i uświadamiać mu jego niekompetencji. Powinien natomiast w miarę często informować go o prawidłowości przebiegu operacji.