Prezentuję tutaj esencjonalną teorię odnośnie komunikowania zachowań oprogramowania i komunikatów błędów. Zastosowanie wypisanych tutaj rad i sugestii może przyczynić się do lepszego User eXperience, a tym samym wpłynie na jakość naszego oprogramowania.
Problemy z komunikatami błędów takie jak niejasna ich treść bądź niewłaściwe kodowanie znaków diakrytycznych (np. polskich ąęźżćńół) przeważnie posiadają priorytet niski, z uwagi na ich wizualny charakter a nie funkcjonalne defekty (mówiąc prosto: niejasny komunikat nie psuje aplikacji). Oczywiście priorytetyzacja takowych komunikatów w głównej mierze zależy od kontekstu, dla przykładu: brak komunikatu o usunięciu elementu z listy kilkuset pozycji (jeśli nie jest założeniem specyfikacji) będzie defektem o średnim priorytecie lub czasami nawet wysokim gdyż może powodować dezorientację użytkownika, dla kontrastu, komunikat po kliknięciu w Zapisz, nie będzie już tak odbierany, gdyż jest to akcja spodziewana, której efekt najczęściej widać błyskawicznie.
Według mnie najlepszą metodą na dobre komunikaty w programach jest postawienie się w roli użytkownika owego programu, swego rodzaju empatia – nie jest to jednak proste dla kogoś kto zna prawie na pamięć aplikację gdyż ją tworzy jak np. developer lub tester, który „przeklikał” już jej wszystkie widoki setki razy :)
- powiadomienie o wystąpieniu problemu stosujemy tylko jeśli ma to kluczowe znaczenie dla użytkownika lub systemu
- komunikat wyjaśnia dlaczego pojawił się problem, co go spowodowało, językiem przystępnym dla użytkownika, należy unikać sloganów technicznych jeśli to nie jest konieczne, dostosować język do operatora – tj. np. dla podstawowego usera komunikat ma być prosty i sugerujący rozwiązanie, dla administratora może zawierać szczegóły techniczne
- informuje co użytkownik może zrobić, aby poprawić błąd
- sugestie w komunikatach powinny występować w czynnej formie, a nie biernej np. zamiast „aby wprowadzono” – „wprowadź”
- inaczej sprawa wygląda z błędami, nie powinny bezpośrednio obarczać winą użytkownika, a także nie wyrażać opinii o nim, np. zamiast „Źle wprowadziłeś dane” wyświetl „Wprowadzono nieprawidłowe dane, nie używaj znaków specjalnych typu: #,$,?”
- należy zadbać o przyjazność i użyteczność komunikatów, można wprowadzić element humoru „Dane logowania nieprawidłowe, nie martw się, masz jeszcze 3 próby”
- komunikat może zawierać przykład np. „Wprowadź datę w formacie ROK-MC-DZIEN np. 2018-08-11
- komunikaty błędów powinny dać się skopiować, zwłaszcza gdy są długie
- komunikaty powinny być wyświetlane z odpowiednim kontrastem w stosunku do aplikacji, aby wyodrębniać się z tła
- podsumowując komunikaty powinny być krótkie, konkretne, zrozumiałe i naprowadzać na rozwiązanie
Typy komunikatów:
- komunikaty w osobnym oknie, modal box (wyświetlają komunikat dopóki użytkownik nie zareaguje, najczęściej komunikaty błędów, których użytkownik nie powinien pominąć, a czasem nawet potwierdzić, że się z nimi zapoznał)
- komunikaty kontekstowe w chmurkach, między elementami aplikacji, podpowiedzi
- strony błędów (w przypadku błędów wyjątkowych aplikacji webowych – powinno się przekierowywać na spersonalizowaną stronę błędu, np. własną 404 lub informującą o przerwie technicznej)
[artykuł rozwojowy, v.2, zachęcam do komentowania]