Ile informacji o błędzie powinien zostać pokazany użytkownikowi?


38

Aplikacje zawsze mogą zgłaszać błędy. Jeśli wystąpi taki błąd, użytkownik powinien zostać powiadomiony, ponieważ to, o co poprosił aplikację, nie powiodło się.

Ile informacji powinien jednak podać użytkownik? Myślę, że większość z nas zgadza się nie pokazywać śladu stosu ( czy ślad stosu powinien znajdować się w komunikacie o błędzie przedstawionym użytkownikowi? ), Ale nie mogę znaleźć pytania na temat pozostałej zawartości błędu lub tego, co pokazać użytkownik.

Na przykład język obsługujący wyjątki (.net, java) ma typ wyjątku do współdzielenia, w którym wystąpił wyjątek, oraz nieco bardziej klarowny komunikat towarzyszący wyjątkowi. Czy to również powinno być ukryte przed użytkownikiem? Czy powinniśmy to mimo wszystko pokazać? A może powinniśmy pokazać ogólny komunikat? czy powinniśmy pokazywać jeden z wielu komunikatów w oparciu o to, co stanowi podstawowy wyjątek?

Odpowiedzi:


34

co pokazać użytkownikowi. Czy to również powinno być ukryte przed użytkownikiem?

Pokazujesz użytkownikowi, co jest dla niego możliwe.

Na przykład, jeśli masz błąd, który jest spowodowany wyjątkiem wskaźnika zerowego i bardziej błędem niż błędem użytkownika, nie potrzebujesz pełnego wyjaśnienia, ponieważ nie mogą zrobić nic innego.

Czy powinniśmy to mimo wszystko pokazać? A może powinniśmy pokazać ogólny komunikat?

Wyświetlanie wyjątku jako głównej treści komunikatu o błędzie jest bezcelowe dla większości użytkowników . Być może, jeśli twoja baza użytkowników docelowych jest programistami, możesz cały czas wyświetlać te informacje jako pełny błąd (być może masz wewnętrzną aplikację do automatycznego testowania). Ale generalnie użytkownicy nie mogą zrobić nic innego, nawet z tą wiedzą.

czy powinniśmy wyświetlać jeden z wielu komunikatów na podstawie tego, co stanowi podstawowy wyjątek?

Najlepszą strategią jest wykonanie następujących czynności:

  • Zinterpretuj błąd w tekście, który ma znaczenie dla użytkownika.
    • Częściowo to „co użytkownik może zrobić inaczej?”
    • Jeśli nie mogą zrobić nic innego, powiedz „wystąpił nieoczekiwany błąd”.
  • Dodaj „opcjonalny” szczegółowy opis błędu
  • Zezwalaj użytkownikom na przesyłanie raportu o błędzie (lub rób to automatycznie, w zależności od bazy użytkowników)

Przykład

wprowadź opis zdjęcia tutaj

  1. Pokazuje „oto co się stało” (nieoczekiwany błąd)
  2. Mówi użytkownikowi, co ma robić (ponownie otworzyć Mail, zawiera nawet skrót do zrobienia tego)
  3. Ma również „zobacz szczegóły”, jeśli ktoś jest ciekawy pełnego błędu technicznego
  4. Dostarcza powiadomienie o złożeniu raportu o błędzie (patrz poniżej)

Pamiętaj, że w niektórych przypadkach możesz chcieć ustawić raport błędu ręcznie lub automatycznie.


20
Nie zgadzam się. Nie ma nic bardziej tak irytującego niż aplikacja, która drukuje „wystąpił błąd”. do ekranu, a następnie wychodzi. Ilekroć tak się dzieje, zawsze zastanawiam się, dlaczego deweloper był tak leniwy, że wydrukował tak nieinformacyjną wiadomość. Wyjaśnij coś użytkownikowi, aby mógł zrozumieć, co poszło nie tak w ogólnym sensie, nawet jeśli nic nie może z tym zrobić. Najlepszy scenariusz, mogą Google wyświetlić komunikat o błędzie i być może znaleźć rozwiązanie opisane przez kogoś innego, co jest prawie niemożliwe, jeśli każdy inny błąd drukuje ten sam ogólny komunikat.
Jon Bentley,

3
@JonBentley Patrzysz na to jako na programistę, który chce to zrozumieć. Przeciętny użytkownik po prostu będzie się martwił, że powinien to zrozumieć, czego nie musi.
deworde

12
@deworde Przeciwnie, uważam to za użytkownika . Jako użytkownik nie chcę tego rozumieć pod względem technicznym, ale potrzebuję wystarczającej ilości informacji, aby nie uważać, że osoba, która napisała oprogramowanie, jest niekompetentna („wystąpił błąd” sprawia wrażenie, że programista „ wiem, co oni robili), a ja mogę szukać odpowiedzi. Jeśli każda awaria mówi „wystąpił błąd”, wyszukiwarka Google mi nie pomoże. Niepowtarzalna wiadomość dla każdej sytuacji znacznie bardziej prawdopodobne jest, że doprowadzę mnie do forum, na którym ktoś miał ten sam problem i być może go rozwiązał.
Jon Bentley,

3
@ JonBentley kilka punktów do rozważenia. Po pierwsze, głównym celem tej odpowiedzi jest podanie użytkownikowi możliwych do działania informacji. Jeśli jest to błąd, mogą to naprawić, podając informacje, aby go rozwiązać. To wpada w You show the user what is actionable for them. Jeśli znasz przyczynę problemu, pokaż to użytkownikowi w opisie. Ale ogólnie, jeśli znasz przyczynę błędu, poznasz rozwiązanie problemu, aby odpowiednio poinformować użytkownika.
enderland

2
Po drugie, rażąco przeceniasz średnią zdolność użytkownika do samodzielnego rozwiązywania problemów. Przytłaczająca większość populacji jest tym, co większość programistów / programistów / stosów stosów wymieniłaby jako komputer analfabetów. Większość tych osób szczerze mówiąc nie jest przygotowana do diagnozowania, rozwiązywania problemów i rozwiązywania problemów. Szczegóły mogą w rzeczywistości pogorszyć sytuację, ponieważ ludzie mogą źle interpretować rzeczy, które byłyby całkowicie sensowne dla programistów. Programiści i znający się na technologii ludzie prawie nie są docelowymi
grupami

12

To zależy od tego, kim jest użytkownik i co może zrobić z informacjami.

Zasadniczo staraj się pokazywać im tylko przydatne informacje o tym, co mogą rozwiązać samodzielnie. Śledzenie stosu 40 linii z błędem wyrażenia regularnego u góry nie jest bardzo przydatne. Znacznie lepszy byłby komunikat z informacją, że data musi być sformatowana jako „rrrr-mm-dd” . Wszystko inne, a użytkownik może nie wiedzieć, jak zareagować na błąd, a następnie może nie chcieć korzystać z aplikacji, ponieważ obawia się, że spowoduje to więcej tajemniczych i przerażających błędów (i tak, użytkownicy nietechniczni są czasami przerażeni stosem ślady). I to może być złe dla biznesu.

W przypadku aplikacji wewnętrznych używanych przez innych programistów, jestem nieco bardziej zrelaksowany w wyświetlaniu śladu stosu, oprócz czegoś bardziej przydatnego , ponieważ wiem, że użytkownik może poradzić sobie z wyświetlaniem śladu stosu i prawdopodobnie będzie wiedział, co z tym zrobić.

W przypadku użytkowników nietechnicznych jedyne, co myślę, że wskazanie im śledzenia stosu jest w stanie krytycznym błędu, w którym potrzebujesz go do rozwiązania problemu, a oni są proszeni o skopiowanie i wklejenie śledzenia stosu i wysłanie go tobie, chociaż naprawdę o wiele lepszym sposobem na to jest poproszenie ich o przesłanie pliku dziennika lub jeszcze lepiej, aby aplikacja wysłała plik dziennika do programisty, po zapytaniu użytkownika o zgodę na udostępnienie pliku.


5
Nie byłbym w porządku z aplikacją, która wysyła logi gdziekolwiek bez pytania mnie. Zamiast tego okno dialogowe komunikatu o błędzie powinno zawierać opcję zgłoszenia błędu. Użytkownik powinien mieć możliwość przejrzenia wszystkich informacji, w tym śladu stosu, przed wysłaniem raportu.
piedar

1
@piedar: To dobra uwaga.
FrustratedWithFormsDesigner

4
@piedar: Posiadanie przycisku „Zobacz więcej szczegółów” w oknie dialogowym błędu lub link do pliku dziennika aplikacji jest prawdopodobnie dobrym sposobem na zaprezentowanie wszystkich krwawych szczegółów użytkownikom zaawansowanym, którzy chcą tych informacji. Nawet pole wyboru „pokaż szczegóły domyślnie”, jeśli chcesz mieć problem z jego kodowaniem. Ale nie wszyscy użytkownicy będą chcieli to zobaczyć, a niektórzy użytkownicy zostaną przez to wyłączeni.
FrustratedWithFormsDesigner

2
@Paddy: Masz rację, ale: 1) To przykład. : P 2) Może naprawiłem i wyczyściłem taki kod, dlatego właśnie o tym myślę ...
FrustratedWithFormsDesigner

2
@NateKerkhofs „A jeśli jest programistą, może powtórzyć błąd” .. - och, gdyby tylko to było prawdą :(
Blorgbeard

1

Wiadomości do użytkowników należy traktować w taki sam sposób, jak tworzenie nowego wyjątku do rzucenia - podajesz informacje, których będą potrzebować, aby zdecydować, co robić.

Będzie to oczywiście zależeć od twojej aplikacji i bazy użytkowników, ale powinna to być twoja główna zasada - Twoim celem powinno być dostarczenie informacji potrzebnych „dzwoniącemu” w celu ustalenia, co, jeśli w ogóle, mogą zrobić, aby pomyślnie wykonać pożądane działanie . Jeśli jest to coś prostego, np. Błąd dostępu do pliku, podajesz ścieżkę do pliku i komunikat, że nie możesz uzyskać do niego dostępu. Jeśli jest to wyjątek wskaźnika zerowego, po prostu podaj ogólny komunikat o błędzie.

Oczywiście będzie więcej komunikatów „niemożność wykonania żądanej czynności” niż takich, które użytkownik może naprawić, ale to tylko życie - większość wyjątków wynika z tego, że popełniliśmy błąd, a nie dlatego, że użytkownik skonfigurował środowisko nieprawidłowo.


1

To jest wspólny motyw:

Jak możesz pomóc niedoinformowanym / analfabetyzmowi komputerowemu, jednocześnie pokazując informacje, z których mogą korzystać bardziej zaawansowani użytkownicy, tacy jak programiści, programiści, testerzy itp.

Myślę, że odpowiedź brzmi: obie te rzeczy!

Kolejność jest jednak ważna i polecam:

  • Co się stało.
  • Co zrobić teraz
  • Szczegóły techniczne

Szczegóły techniczne to część, która zawiera informacje dotyczące zamówień zaawansowanych lub zwykłych użytkowników zgłaszających problem


0

To, co chcesz pokazać, zależy od tego, jak wstydzisz się zepsucia.

Chodzi o to, aby uzyskać szczegółowe informacje na temat awarii wsparcia technicznego tak szybko i płynnie, jak to możliwe. Może to oznaczać, że automatycznie wyślesz plik dziennika zawierający ślad stosu błędu zakończenia do domu lub poprosisz użytkownika o kliknięcie przycisku, który zainicjuje transfer. Może przez pamięć USB, jeśli nie ma połączenia z Internetem.


0

Podoba mi się uzasadnienie przyjętej odpowiedzi, ale z szacunkiem muszę przynajmniej nie zgodzić się z moją interpretacją ograniczenia informacji do tego, co jest „możliwe do wykonania” . Chcę dowiedzieć się trochę więcej jako użytkownika niż „nieoczekiwany błąd” .

I wprawdzie jestem trochę obeznany z komputerem i mam takie nastawienie, ale nie sądzę, że jest to szczególnie stronniczy pogląd. Ponieważ mogę zrobić wszystko, co w mojej mocy, aby usunąć to uprzedzenie, stosując ten sposób myślenia w domenach, dla których mam niewielkie doświadczenie, takie jak lotnictwo.

Chociaż niewiele wiem o lotnictwie, powiedz, że mój lot jest opóźniony lub odwołany, a jedyne, co mówią mi pracownicy, to: „Wystąpił nieoczekiwany błąd. Poczekaj 3 godziny na kolejny lot”. W takich przypadkach znajdziesz mnie trochę bardziej niezadowolonego klienta, ponieważ chociaż tak naprawdę nie wpływa to na mój sposób działania, chcę tylko dowiedzieć się nieco więcej o tym, dlaczego jestem niewygodne w ten sposób jako płacący klient.

Jeśli powiedzieli tylko: „Mamy burzliwą pogodę” lub „Mieliśmy awarię medyczną podczas naszego poprzedniego lotu”, albo awarię sprzętu, czy coś w tym rodzaju, to wystarcza mi, by wyrazić więcej niż „nieoczekiwany błąd” i trochę więcej zadowolenia siedząc i czekając 3 godziny na następny lot. Właściwie może nawet wolę jakiś technobabble, który idzie mi ponad głowę, do „nieoczekiwanego błędu”, na przykład: „W porządku, słowa wydobywające się z twoich ust docierają do mojego ucha, ale nie docierają do centralnego procesora. Ale teraz rozumiem problemu i pójdę napić się kawy i usiąść tam! Mam nadzieję, że załatwicie ten problem z tą rzeczą! ”

I często pod względem obsługi wyjątków, myślę, że zwykle masz dość tego rodzaju podstawowych informacji o tym, co wydarzyło się na catchstronie, nawet jeśli chcesz ukryć bardziej techniczne szczegóły wyjątku, takie jak:

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

Nie wyświetla to nawet potencjalnie bardzo technicznych informacji dołączonych do wyjątku, ale przynajmniej mówi nam znacznie więcej niż „nieoczekiwany błąd”. Zapewnia przynajmniej kontekstowe „co / gdzie / kiedy”, nawet jeśli nie mówi „dlaczego / jak”. Myślę, że przynajmniej moja chęć korzystania z komputera nie jest szczególnie tendencyjna.

Reszta jest prawdopodobnie bardzo specyficzna dla Twoich klientów i konkretnych potrzeb. Ale mój apel dotyczy przynajmniej czegoś drobniejszego niż „nieoczekiwany błąd”.


Cóż, to jest stronniczy pogląd. Przeciętny użytkownik nie dba o to, dlaczego nie może robić tego, czego nie może zrobić. Dbają tylko o to, czy i jak mogą rozwiązać swój problem.
gnasher729

„Przeciętny użytkownik nie dba o to, dlaczego nie może robić tego, czego nie może. Dba tylko o to, czy i jak może rozwiązać swój problem”. Jeśli przeciętny użytkownik nawet nie rozumie, czym jest plik lub serwer, być może tak, ale może to wiązać się z tym, co jest „możliwe do wykonania”, ponieważ może być w stanie dotknąć cię ramieniem i powiedzieć: „Hej , ta aplikacja mówi, że nie może znaleźć wymaganego pliku konfiguracyjnego ”lub czegoś w tym celu, w którym możesz następnie wyszukać problem i szybko go naprawić, np.
Dragon Energy
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.