Błędy
Gdy użytkownik końcowy siądzie przed naszym programem, może mu się przytrafić niemiła sytuacja - wystąpił błąd. I należy pokazać wtedy komunikat błędu. I dochodzimy do sprzecznych wymagań niestety. Musi być on na tyle przyjazny, zeby się użytkownik nie przestraszył, ale jednocześnie tak dokładnie opisujący problem, aby zaawansowany użytwkonik, bądź sam twórca, mógł wyśledzić, gdzie kryje się problem.
W Windows widać często niestety tylko pierwszy człon porządnego komunikatu o błedach. “Program wykonał nieprawidłową operację. Czy wysłać raport do firmy Microsoft?”. Prawie żadnych szczegółowych i (co ważne dla Power Userów) czytelnych informacji o źródle problemu. My, twórcy produktu, możemy sobie pooznaczać błedy kolejnymi numerkami, potem zaglądamy do kodu i widzimy, gdzie taki numer jest. Ale zaawansowany użytkownik, tóry sam chciałby naprawić problem?
A wróćmy do tego zwykłego. Do przysłowiowej “Pani Zosi”. Siadła ona przed naszym, dajmy na to hiper-programem księgowym, a jej wyskoczyło “Wystąpił błąd 0×0524, E_DEVICE_READ_FAIL. Wymień dysk i naciśnij dowolny klawisz.”. Czy o wiele przyjaźniejsze nie byłoby “Nie mogę odczytać z dyskietki. Sprawdź, czy dyskietka jest włożona, jeśli nie, to włóż ją i naciśnij jakikolwiek klawisz.”? Z drugiej strony, gdy przyjdzie Pan Staś, administrator sieci, to zobaczy w podręczniku, że błąd 0×0524 oznacza, zę dyskietka jest zabezpieczona przed zapisem. Jak pogodzić przyjemne komunikaty o błedach z szczegółowymi informacjami o nich?
Dobrą metodą jest przycisk opisany na przykład “Więcej informacji”, który pokazuje te szczegółowe informacje techniczne. Czy też zapisywanie błędów, wraz ze szczegółowymi informacjami, w jakimś pliku logu. O lokalizacji oczywiście znanej i opisanej w dokumentacji programu. O, właśnie. Przydałoby się wszystkie informacje o błędach dobrze dokumentować. Tak, aby każdy (no, w miarę obeznany) mógł zrozumieć, co nalezy postąpić w takiej to, a takiej sprawie. I abyśmy my się też nie głowili i nie szukali po kodzie programu w jakiej sytuacji występuje dany błąd.
Rozsądne, przyjazne, ale i dobrze opisujące problem, komunikaty o błdach, są bardzo ważne. Mogą uczynić program przyjaznym (lub nie) i łatwym do naprawy (lub nie). Bo sytuacja, w której reinstalacja programu jest lekarstwem na błędy jest niedopuszczalna.
1 komentarz
»Wątek RSS dla komentarzy tego wpisu · Adres trackback
grudzień 19, 2005 godzina 15:18
Problem błędów i komunikatów o błędach całkiem dobrze opisał Ian Sommervile w swojej książce o inżynierii oprogramowania. Niestety nie mam książki przed sobą, aby przytoczyć co ciekawsze fragmenty, ale pocelam każdemu przeczytać to chociaż raz.
Przykłady:
- komunikat powinien dać się łatwo zauważyć
- komunikat nie powinien sugerować, że to użytkownik popełnił błąd
- komunikat powinien w sposób jasny i precyzyjny wskazywać miejsce powstania błędów.
itd ….