Komunikaty o błędach w systemie Windows 7

Komunikaty o błędach w systemie Windows 7 ostrzegają użytkowników o problemach, które już wystąpiły. Z kolei komunikaty ostrzegawcze ostrzegają użytkowników o warunkach, które mogą powodować problemy w przyszłości. Komunikaty o błędach można prezentować przy użyciu modalnych okien dialogowych, komunikatów w miejscu, powiadomień lub dymków.

Typowy modalny komunikat o błędzie.

Skuteczne komunikaty o błędach informują użytkowników, że wystąpił problem, wyjaśnij, dlaczego wystąpił, i podaj rozwiązanie, aby użytkownicy mogli rozwiązać ten problem. Użytkownicy powinni wykonać akcję lub zmienić swoje zachowanie w wyniku komunikatu o błędzie.

Dobrze napisane, przydatne komunikaty o błędach mają kluczowe znaczenie dla jakości środowiska użytkownika. Źle napisane komunikaty o błędach powodują niskie zadowolenie z produktu i są główną przyczyną możliwych do uniknięcia kosztów pomocy technicznej. Niepotrzebne komunikaty o błędach przerywają przepływ użytkowników.

Nuta: Wytyczne związane z oknami dialogowymi, komunikatami ostrzegawczymi, potwierdzeniami, standardowymi ikonami, powiadomieniami i układem są prezentowane w oddzielnych artykułach.

Czy jest to właściwy interfejs użytkownika?

Aby zdecydować, rozważ następujące pytania:

• Czy interfejs użytkownika przedstawia problem, który już wystąpił? Jeśli nie, komunikat nie jest błędem. Jeśli użytkownik jest powiadamiany o warunku, który może spowodować problem w przyszłości, użyj komunikatu ostrzegawczego.
• Czy problem można zapobiec bez powodowania nieporozumień? Jeśli tak, zapobiegnie problemowi. Na przykład użyj kontrolek, które są ograniczone do prawidłowych wartości, zamiast używać nieprzyciągniętych kontrolek, które mogą wymagać komunikatów o błędach. Ponadto wyłączenie kontrolek po kliknięciu spowoduje błąd, o ile jest oczywiste, dlaczego kontrolka jest wyłączona.
• Czy problem można rozwiązać automatycznie? Jeśli tak, obsłuż problem i pomiń komunikat o błędzie.
• Czy użytkownicy mogą wykonać akcję lub zmienić swoje zachowanie w wyniku komunikatu? Jeśli tak nie jest, warunek nie uzasadnia przerwania użytkownika, więc lepiej jest pominąć błąd.
• Czy problem jest istotny, gdy użytkownicy aktywnie korzystają z innych programów? Jeśli tak, rozważ wyświetlenie problemu przy użyciu ikony obszaru powiadomień.
• Czy problem nie jest związany z bieżącym działaniem użytkownika, czy nie wymaga natychmiastowego działania użytkownika i czy użytkownicy mogą go swobodnie ignorować? Jeśli tak, użyj powiadomienia o niepowodzeniu akcji .
• Czy problem dotyczy stanu zadania w tle w oknie podstawowym? Jeśli tak, rozważ wyświetlenie problemu przy użyciu pasków stanu.
• Czy głównymi specjalistami IT są użytkownicy docelowi? Jeśli tak, rozważ użycie alternatywnego mechanizmu przesyłania opinii, takiego jak wpisy pliku dziennika lub alerty poczty e-mail. Specjaliści IT zdecydowanie preferują pliki dziennika dla informacji niekrytycznych.

Pojęcia dotyczące projektowania

Cechy słabych komunikatów o błędach

Nie powinno być zaskoczeniem, że istnieje wiele irytujących, nieprzydatnych i słabo napisanych komunikatów o błędach. Ponieważ komunikaty o błędach są często prezentowane przy użyciu modalnych okien dialogowych, przerywają bieżące działania użytkownika i wymagają potwierdzenia przed zezwoleniem użytkownikowi na kontynuowanie.

Częścią problemu jest to, że istnieje tak wiele sposobów, aby to zrobić źle. Rozważ następujące przykłady z sali komunikatów o błędach wstydu:

Niepotrzebne komunikaty o błędach

niepoprawne:

Ten przykład z systemu Windows XP może być najgorszym komunikatem o błędzie w historii. Wskazuje, że nie można uruchomić programu, ponieważ sam system Windows jest w trakcie zamykania. Nie ma nic, co użytkownik może zrobić w tym celu, a nawet chce to zrobić (użytkownik zdecydował się zamknąć system Windows, mimo wszystko). I wyświetlając ten komunikat o błędzie, system Windows uniemożliwia zamknięcie się!

Problem: Sam komunikat o błędzie jest problemem. Oprócz odrzucenia komunikatu o błędzie, nie ma nic do zrobienia dla użytkowników.

Główna przyczyna: Raportowanie wszystkich przypadków błędów, niezależnie od celów lub punktu widzenia użytkowników.

Zalecana alternatywa: Nie zgłaszaj błędów, o których użytkownicy nie dbają.

Komunikaty o błędach "Powodzenie"

niepoprawne:

Ten komunikat o błędzie wynikał z tego, że użytkownik nie uruchamiał systemu Windows natychmiast po usunięciu programu. Usunięcie programu zakończyło się pomyślnie z punktu widzenia użytkownika.

Problem: Nie ma błędu z punktu widzenia użytkownika. Oprócz odrzucenia komunikatu o błędzie, nie ma nic do zrobienia dla użytkowników.

Główna przyczyna: Zadanie zostało ukończone pomyślnie z punktu widzenia użytkownika, ale nie powiodło się z punktu widzenia programu dezinstalacji.

Zalecana alternatywa: Nie zgłaszaj błędów w przypadku warunków, które użytkownicy uważają za dopuszczalne.

Całkowicie bezużyteczne komunikaty o błędach

niepoprawne:

Użytkownicy dowiedzą się, że wystąpił błąd, ale nie mają pojęcia, co to było lub co z tym zrobić. I nie, to nie jest OK!

Problem: Komunikat o błędzie nie daje konkretnego problemu i nie ma nic, co użytkownicy mogą z tym zrobić.

Główna przyczyna: Najprawdopodobniej program ma słabą obsługę błędów.

Zalecana alternatywa: Projektowanie dobrej obsługi błędów w programie.

Niezrozumiałe komunikaty o błędach

niepoprawne:

W tym przykładzie instrukcja problemu jest jasna, ale dodatkowe wyjaśnienie jest całkowicie zaskakujące.

Problem: Instrukcja lub rozwiązanie problemu jest niezrozumiałe.

Główna przyczyna: Wyjaśnienie problemu z punktu widzenia kodu zamiast użytkownika.

Zalecana alternatywa: Napisz tekst komunikatu o błędzie, który użytkownicy docelowi mogą łatwo zrozumieć. Udostępniaj rozwiązania, które użytkownicy mogą faktycznie wykonywać. Projektowanie środowiska komunikatów o błędach programu nie ma programistów tworzących komunikaty o błędach na miejscu.

Komunikaty o błędach, które overcommunicate

niepoprawne:

W tym przykładzie komunikat o błędzie najwyraźniej próbuje wyjaśnić każdy krok rozwiązywania problemów.

Problem: Za dużo informacji.

Główna przyczyna: Podanie zbyt wielu szczegółów lub próba wyjaśnienia skomplikowanego procesu rozwiązywania problemów w komunikacie o błędzie.

Zalecana alternatywa: Unikaj niepotrzebnych szczegółów. Ponadto unikaj rozwiązywania problemów. Jeśli narzędzie do rozwiązywania problemów jest konieczne, skoncentruj się na najbardziej prawdopodobnych rozwiązaniach i wyjaśnij resztę, łącząc się z odpowiednim tematem w Pomocy.

Niepotrzebne trudne komunikaty o błędach

niepoprawne:

Niezdolność programu do znalezienia obiektu prawie nie brzmi katastrofalne. I zakładając, że jest katastrofalne, dlaczego jest OK odpowiedzi?

Problem: Ton programu jest niepotrzebnie ostry lub dramatyczny.

Główna przyczyna: Problem jest spowodowany usterką, która wydaje się katastrofalna z punktu widzenia programu.

Zalecana alternatywa: Starannie wybierz język w oparciu o punkt widzenia użytkownika.

Komunikaty o błędach, które obwiniają użytkowników

niepoprawne:

Dlaczego użytkownicy czują się jak przestępcy?

Problem: Komunikat o błędzie jest sformułowany w sposób, który oskarża użytkownika o błąd.

Główna przyczyna: Niewrażliwe frazy, które koncentrują się na zachowaniu użytkownika zamiast problemu.

Zalecana alternatywa: Skoncentruj się na problemie, a nie na akcji użytkownika, która doprowadziła do problemu, używając pasywnego głosu w razie potrzeby.

Głupie komunikaty o błędach

niepoprawne:

W tym przykładzie instrukcja problemu jest dość ironiczna i nie podano żadnych rozwiązań.

Problem: Instrukcje komunikatu o błędzie, które są głupie lub nie sequitors.

Główna przyczyna: Tworzenie komunikatów o błędach bez zwracania uwagi na ich kontekst.

Zalecana alternatywa: Czy komunikaty o błędach zostały spreparowane i przejrzyone przez moduł zapisywania. Podczas przeglądania błędów należy wziąć pod uwagę kontekst i stan umysłu użytkownika.

Komunikaty o błędach programisty

niepoprawne:

W tym przykładzie komunikat o błędzie wskazuje, że w programie występuje usterka. Ten komunikat o błędzie ma znaczenie tylko dla programisty.

Problem: Komunikaty mające na celu pomoc deweloperom programu w znalezieniu usterek pozostają w wersji programu. Te komunikaty o błędach nie mają znaczenia ani wartości dla użytkowników.

Główna przyczyna: Programiści używający normalnego interfejsu użytkownika do tworzenia komunikatów do siebie.

Zalecana alternatywa: Deweloperzy muszą warunkowo skompilować wszystkie takie komunikaty, aby były automatycznie usuwane z wersji produktu. Nie marnuj czasu, próbując popełnić błędy takie jak ten zrozumiały dla użytkowników, ponieważ ich jedynymi odbiorcami są programiści.

Źle prezentowane komunikaty o błędach

niepoprawne:

Ten przykład zawiera wiele typowych błędów prezentacji.

Problem: Pobieranie wszystkich szczegółów źle w prezentacji komunikatu o błędzie.

Główna przyczyna: Nie wiedząc i stosując wytyczne dotyczące komunikatu o błędzie. Nieużywaj składników zapisywania i edytorów do tworzenia i przeglądania komunikatów o błędach.

Charakter obsługi błędów jest taki, że wiele z tych błędów jest bardzo łatwych do wykonania. Niepokojące jest uświadomienie sobie, że większość komunikatów o błędach może być nominowanymi do Hall of Shame.

Cechy dobrych komunikatów o błędach

W przeciwieństwie do poprzednich złych przykładów dobre komunikaty o błędach mają następujące elementy:

• Problem. Stwierdza, że wystąpił problem.
• Przyczyna. Wyjaśnia, dlaczego wystąpił problem.
• Rozwiązanie. Udostępnia rozwiązanie umożliwiające użytkownikom rozwiązanie problemu.

Ponadto dobre komunikaty o błędach są prezentowane w sposób:

• Istotny. Komunikat przedstawia problem, który użytkownicy dbają.
• Zaskarżeniu. Użytkownicy powinni wykonać akcję lub zmienić ich zachowanie w wyniku komunikatu.
• Wyśrodkowany przez użytkownika. Komunikat opisuje problem pod względem docelowych akcji lub celów użytkownika, a nie pod względem tego, z czym kod jest niezadowolony.
• Krótki. Wiadomość jest tak krótka, jak to możliwe, ale nie krótsza.
• Jasny. Komunikat używa zwykłego języka, aby użytkownicy docelowi mogli łatwo zrozumieć problem i rozwiązanie.
• Specyficzny. Komunikat opisuje problem przy użyciu określonego języka, podając określone nazwy, lokalizacje i wartości zaangażowanych obiektów.
• Uprzejmy. Użytkownicy nie powinni być obwiniani ani nie czuli się głupi.
• Rzadki. Wyświetlane rzadko. Często wyświetlane komunikaty o błędach są oznaką złego projektu.

Projektując środowisko obsługi błędów, aby mieć te cechy, możesz zachować komunikaty o błędach programu poza Hall of Shame komunikatów o błędach.

Unikanie niepotrzebnych komunikatów o błędach

Często najlepszym komunikatem o błędzie nie jest komunikat o błędzie. Wiele błędów można uniknąć dzięki lepszemu projektowaniu i często są lepsze alternatywy dla komunikatów o błędach. Zazwyczaj lepiej jest zapobiec błędowi niż zgłosić go.

Najbardziej oczywiste komunikaty o błędach, których można uniknąć, to te, które nie są możliwe do działania. Jeśli użytkownicy prawdopodobnie odrzucą komunikat bez konieczności zmiany lub zmiany, pomiń komunikat o błędzie.

Niektóre komunikaty o błędach można wyeliminować, ponieważ nie są to problemy z punktu widzenia użytkownika. Załóżmy na przykład, że użytkownik próbował usunąć plik, który jest już w trakcie usuwania. Chociaż może to być nieoczekiwany przypadek z punktu widzenia kodu, użytkownicy nie uważają tego za błąd, ponieważ osiągany jest żądany wynik.

niepoprawne:

Ten komunikat o błędzie powinien zostać wyeliminowany, ponieważ akcja zakończyła się pomyślnie z punktu widzenia użytkownika.

W innym przykładzie załóżmy, że użytkownik jawnie anuluje zadanie. W przypadku punktu widzenia użytkownika następujący warunek nie jest błędem.

niepoprawne:

Ten komunikat o błędzie należy również wyeliminować, ponieważ akcja zakończyła się pomyślnie z punktu widzenia użytkownika.

Czasami komunikaty o błędach można wyeliminować, koncentrując się na celach użytkowników zamiast technologii. W ten sposób należy ponownie rozważyć, co naprawdę jest błędem. Czy problem dotyczy celów użytkownika, czy też zdolności programu do ich spełnienia? Jeśli działanie użytkownika ma sens w świecie rzeczywistym, powinno też mieć sens w oprogramowaniu.

Załóżmy na przykład, że w programie handlu elektronicznego użytkownik próbuje znaleźć produkt przy użyciu wyszukiwania, ale zapytanie wyszukiwania literału nie ma dopasowań, a żądany produkt jest niedostępny. Technicznie jest to błąd, ale zamiast podawać komunikat o błędzie, program może:

• Kontynuuj wyszukiwanie produktów, które najlepiej pasują do zapytania.
• Jeśli wyszukiwanie ma oczywiste błędy, automatycznie zalecamy skorygowane zapytanie.
• Automatycznie obsługuje typowe problemy, takie jak błędy pisowni, alternatywne pisownie i niezgodność liczby mnogiej i przypadków czasowników.
• Określ, kiedy produkt będzie w magazynie.

O ile żądanie użytkownika jest uzasadnione, dobrze zaprojektowany program handlu elektronicznego powinien zwracać rozsądne wyniki, a nie błędy.

Innym doskonałym sposobem uniknięcia komunikatów o błędach jest zapobieganie problemom w pierwszej kolejności. Możesz zapobiec błędom, wykonując następujące czynności:

• Używanie kontrolek ograniczonych. Użyj kontrolek, które są ograniczone do prawidłowych wartości. Kontrolki, takie jak listy, suwaki, pola wyboru, przyciski radiowe, selektory dat i godzin są ograniczone do prawidłowych wartości, natomiast pola tekstowe często nie i mogą wymagać komunikatów o błędach. Można jednak ograniczyć pola tekstowe tak, aby akceptowały tylko niektóre znaki i akceptowały maksymalną liczbę znaków.
• Korzystanie z ograniczonych interakcji. W przypadku operacji przeciągania umożliwia użytkownikom upuszczanie tylko prawidłowych elementów docelowych.
• Korzystanie z wyłączonych kontrolek i elementów menu. Wyłącz kontrolki i elementy menu, gdy użytkownicy mogą łatwo określić, dlaczego kontrolka lub element menu jest wyłączony.
• Podawanie dobrych wartości domyślnych. Użytkownicy są mniej skłonni do błędów wejściowych, jeśli mogą zaakceptować wartości domyślne. Nawet jeśli użytkownicy zdecydują się zmienić wartość, wartość domyślna informuje użytkowników o oczekiwanym formacie wejściowym.
• Tworzenie rzeczy po prostu działa. Użytkownicy są mniej skłonni popełniać błędy, jeśli zadania są niepotrzebne lub wykonywane automatycznie. Lub jeśli użytkownicy popełniają małe błędy, ale ich intencja jest jasna, problem zostanie rozwiązany automatycznie. Można na przykład automatycznie rozwiązać drobne problemy z formatowaniem.

Dostarczanie niezbędnych komunikatów o błędach

Czasami naprawdę trzeba podać komunikat o błędzie. Użytkownicy popełniają błędy, sieci i urządzenia przestają działać, nie można odnaleźć ani zmodyfikować obiektów, nie można ukończyć zadań, a programy mają błędy. W idealnym przypadku te problemy występują rzadziej, na przykład możemy zaprojektować nasze oprogramowanie, aby zapobiec wielu typom błędów użytkowników, ale nie jest realistyczne, aby zapobiec wszystkim tym problemom. A gdy wystąpi jeden z tych problemów, pomocny komunikat o błędzie szybko zwraca użytkowników na nogi.

Powszechne przekonanie polega na tym, że komunikaty o błędach są najgorszym środowiskiem użytkownika i powinny być unikane za wszelką cenę, ale bardziej dokładne jest stwierdzenie, że zamieszanie użytkowników jest najgorszym środowiskiem i należy unikać ich za wszelką cenę. Czasami ten koszt jest pomocnym komunikatem o błędzie.

Rozważ wyłączenie kontrolek. W większości przypadków oczywiste jest, że kontrolka jest wyłączona, dlatego wyłączenie kontrolki jest doskonałym sposobem uniknięcia komunikatu o błędzie. Co jednak zrobić, jeśli przyczyna wyłączenia kontrolki nie jest oczywista? Użytkownik nie może kontynuować i nie ma żadnych opinii w celu ustalenia problemu. Teraz użytkownik jest zablokowany i musi wyłudić problem lub uzyskać pomoc techniczną. W takich przypadkach znacznie lepiej pozostawić kontrolkę włączoną i zamiast tego dać pomocny komunikat o błędzie.

niepoprawne:

Dlaczego przycisk Dalej jest tutaj wyłączony? Lepiej pozostawić to włączone i uniknąć nieporozumień użytkownika, dając pomocny komunikat o błędzie.

Jeśli nie masz pewności, czy powinien zostać wyświetlony komunikat o błędzie, zacznij od utworzenia komunikatu o błędzie, który może zostać wyświetlony. Jeśli użytkownicy mogą wykonać akcję lub zmienić ich zachowanie w wyniku, podaj komunikat o błędzie. Natomiast jeśli użytkownicy mogą odrzucić komunikat bez konieczności zmiany lub zmiany, pomiń komunikat o błędzie.

Projektowanie pod kątem dobrej obsługi błędów

Podczas tworzenia dobrego tekstu komunikatu o błędzie może być trudne, czasami jest niemożliwe bez dobrej obsługi błędów obsługi z programu. Rozważmy następujący komunikat o błędzie:

niepoprawne:

Istnieje prawdopodobieństwo, że problem jest naprawdę nieznany, ponieważ brakuje obsługi błędów programu.

Chociaż jest to możliwe, że jest to bardzo słabo napisany komunikat o błędzie, najprawdopodobniej odzwierciedla brak dobrej obsługi błędów przez kod źródłowy nie ma konkretnych informacji o problemie.

Aby utworzyć określone, możliwe do działania, skoncentrowane na użytkowniku komunikaty o błędach, kod obsługi błędów programu musi podać określone, ogólne informacje o błędach:

• Każdy problem powinien mieć przypisany unikatowy kod błędu.
• Jeśli problem ma kilka przyczyn, program powinien określić określoną przyczynę, jeśli jest to możliwe.
• Jeśli problem ma parametry, należy zachować parametry.
• Problemy niskiego poziomu muszą być obsługiwane na wystarczająco wysokim poziomie, aby można było wyświetlić komunikat o błędzie z punktu widzenia użytkownika.

Dobre komunikaty o błędach nie są tylko problemem interfejsu użytkownika, są one problemem projektowym oprogramowania. Dobre środowisko komunikatu o błędzie nie jest czymś, co można później spakować.

Rozwiązywanie problemów (i jak go uniknąć)

Rozwiązywanie problemów, gdy problem z kilkoma różnymi przyczynami jest zgłaszany z pojedynczym komunikatem o błędzie.

niepoprawne:

poprawna:

Rozwiązywanie problemów w przypadku zgłaszania kilku problemów za pomocą jednego komunikatu o błędzie.

W poniższym przykładzie nie można przenieść elementu, ponieważ został on już przeniesiony lub usunięty albo nastąpiła odmowa dostępu. Jeśli program może łatwo określić przyczynę, dlaczego umieścić obciążenie dla użytkownika w celu ustalenia konkretnej przyczyny?

niepoprawne:

Cóż, co to jest? Teraz użytkownik musi rozwiązać problemy.

Program może określić, czy nastąpiła odmowa dostępu, dlatego ten problem powinien zostać zgłoszony z określonym komunikatem o błędzie.

poprawna:

W przypadku określonej przyczyny nie jest wymagane rozwiązywanie problemów.

Używaj komunikatów z wieloma przyczynami tylko wtedy, gdy nie można określić określonej przyczyny. W tym przykładzie trudno byłoby ustalić, czy element został przeniesiony lub usunięty, więc w tym miejscu może być używany pojedynczy komunikat o błędzie z wieloma przyczynami. Jest jednak mało prawdopodobne, że użytkownicy będą się przejmować, jeśli na przykład nie mogą przenieść usuniętego pliku. W przypadku tych przyczyn komunikat o błędzie nie jest nawet konieczny.

Obsługa nieznanych błędów

W niektórych przypadkach naprawdę nie znasz problemu, przyczyny ani rozwiązania. Jeśli byłoby nierozsądne, aby pominąć błąd, lepiej z góry być z góry o braku informacji niż prezentować problemy, przyczyny lub rozwiązania, które mogą nie być właściwe.

Jeśli na przykład program ma nieobsługiwany wyjątek, odpowiedni jest następujący komunikat o błędzie:

Jeśli nie możesz pominąć nieznanego błędu, lepiej być z góry na temat braku informacji.

Z drugiej strony podaj konkretne, możliwe do działania informacje, jeśli prawdopodobnie będą one pomocne przez większość czasu.

Ten komunikat o błędzie jest odpowiedni dla nieznanego błędu, jeśli połączenie sieciowe jest zwykle problemem.

Określanie odpowiedniego typu komunikatu

Niektóre problemy można przedstawić jako błąd, ostrzeżenie lub informacje, w zależności od nacisku i fraz. Załóżmy na przykład, że strona sieci Web nie może załadować niepodpisanej kontrolki ActiveX na podstawie bieżącej konfiguracji programu Windows Internet Explorer:

• Błąd. "Ta strona nie może załadować niepodpisanej kontrolki ActiveX". (Fraza jako istniejący problem).
• Ostrzeżenie. "Ta strona może nie zachowywać się zgodnie z oczekiwaniami, ponieważ program Windows Internet Explorer nie jest skonfigurowany do ładowania niepodpisanych kontrolek ActiveX" lub "Zezwól tej stronie na zainstalowanie niepodpisanej kontrolki ActiveX? W ten sposób z niezaufanych źródeł może zaszkodzić komputerowi". (Obie frazy jako warunki, które mogą powodować przyszłe problemy).
• Informacja. "Skonfigurowano program Windows Internet Explorer do blokowania niepodpisanych kontrolek ActiveX". (Fraza jako oświadczenie faktów).

Aby określić odpowiedni typ komunikatu, należy skoncentrować się na najważniejszym aspekcie problemu, na który użytkownicy muszą wiedzieć lub podejmować działania. Zazwyczaj jeśli problem uniemożliwia użytkownikowi kontynuowanie, należy go przedstawić jako błąd; jeśli użytkownik może kontynuować, przedstawić go jako ostrzeżenie. Utwórz instrukcję główną lub inny odpowiedni tekst na podstawie tego fokusu, a następnie wybierz ikonę (standardową lub w inny sposób), która pasuje do tekstu. Tekst i ikony instrukcji głównej powinny być zawsze zgodne.

Prezentacja komunikatu o błędzie

Większość komunikatów o błędach w programach systemu Windows jest prezentowana przy użyciu modalnych okien dialogowych (jak większość przykładów w tym artykule), ale istnieją inne opcje:

• W miejscu
• Balony
• Powiadomienia
• Ikony obszaru powiadomień
• Paski stanu
• Pliki dziennika (w przypadku błędów przeznaczonych dla specjalistów IT)

Umieszczenie komunikatów o błędach w modalnych oknach dialogowych ma korzyść z żądania natychmiastowej uwagi i potwierdzenia użytkownika. Jednak jest to również ich podstawowa wada, jeśli ta uwaga nie jest konieczna.

Czy naprawdę musisz przerwać użytkownikom, aby mogli kliknąć przycisk Zamknij? Jeśli nie, rozważ alternatywy dla korzystania z modalnego okna dialogowego.

Modalne okna dialogowe są doskonałym wyborem, gdy użytkownik musi potwierdzić problem bezpośrednio przed kontynuowaniem, ale często jest to słaby wybór. Ogólnie rzecz biorąc, należy użyć najlżejszej prezentacji wagi, która dobrze wykonuje zadanie.

Unikaj nadmiernego napolecenia

Ogólnie rzecz biorąc, użytkownicy nie czytają, skanują. Im więcej tekstu, tym trudniej jest skanować tekst, a im bardziej prawdopodobne, że użytkownicy w ogóle nie czytają tekstu. W związku z tym ważne jest, aby ograniczyć tekst do swoich podstawowych elementów i korzystać z postępowych informacji i linków Pomocy, jeśli jest to konieczne, aby podać dodatkowe informacje.

Istnieje wiele ekstremalnych przykładów, ale przyjrzyjmy się jeszcze jednej typowej. Poniższy przykład zawiera większość atrybutów dobrego komunikatu o błędzie, ale jego tekst nie jest zwięzły i wymaga motywacji do odczytania.

niepoprawne:

Ten przykład jest dobrym komunikatem o błędzie, ale on overcommunicates.

Co to jest cały ten tekst naprawdę mówi? Coś takiego:

poprawna:

Ten komunikat o błędzie zawiera zasadniczo te same informacje, ale jest znacznie bardziej zwięzły.

Korzystając z Pomocy w celu podania szczegółów, ten komunikat o błędzie ma odwrócony styl prezentacji ostrosłupowej .

Aby uzyskać więcej wytycznych i przykładów dotyczących overcommunicating, zobacz Tekst interfejsu użytkownika.

Jeśli robisz tylko osiem rzeczy

1. Zaprojektuj program pod kątem obsługi błędów.
2. Nie udostępniaj niepotrzebnych komunikatów o błędach.
3. Unikaj nieporozumień użytkowników, podając niezbędne komunikaty o błędach.
4. Upewnij się, że komunikat o błędzie zawiera problem, przyczynę i rozwiązanie.
5. Upewnij się, że komunikat o błędzie jest odpowiedni, możliwy do działania, krótki, jasny, konkretny, uprzejmy i rzadki.
6. Projektuj komunikaty o błędach z punktu widzenia użytkownika, a nie z punktu widzenia programu.
7. Unikaj angażowania użytkownika w rozwiązywanie problemów, użyj innego komunikatu o błędzie dla każdej wykrywalnej przyczyny.
8. Użyj najlżejszej metody prezentacji wagi, która dobrze wykonuje zadanie.

wzorce użycia

Komunikaty o błędach mają kilka wzorców użycia:

Etykieta	Wartość
Problemy systemowe System operacyjny, urządzenie sprzętowe, sieć lub program uległ awarii lub nie jest w stanie wymaganym do wykonania zadania.	Użytkownik może rozwiązać wiele problemów systemowych: Problemy z urządzeniami można rozwiązać, włączając urządzenie, ponownie podłączając urządzenie i wstawiając nośnik. Problemy z siecią można rozwiązać, sprawdzając połączenie z siecią fizyczną i uruchamiając polecenie Diagnozowanie i naprawianie sieci. Problemy z programem można rozwiązać, zmieniając opcje programu lub uruchamiając ponownie program. W tym przykładzie program nie może odnaleźć aparatu do wykonania zadania użytkownika. W tym przykładzie należy włączyć funkcję wymaganą do wykonania zadania.
Problemy z plikami Nie można odnaleźć pliku lub folderu wymaganego dla zadania zainicjowanego przez użytkownika, jest już używany lub nie ma oczekiwanego formatu.	W tym przykładzie nie można usunąć pliku lub folderu, ponieważ nie został znaleziony. W tym przykładzie program nie obsługuje danego formatu pliku.
Problemy z zabezpieczeniami Użytkownik nie ma uprawnień dostępu do zasobu ani wystarczających uprawnień do wykonania zadania zainicjowanego przez użytkownika.	W tym przykładzie użytkownik nie ma uprawnień dostępu do zasobu. W tym przykładzie użytkownik nie ma uprawnień do wykonywania zadania.
Problemy z zadaniami Wystąpił konkretny problem podczas wykonywania zadania zainicjowanego przez użytkownika (inny niż system, nie znaleziono pliku, format pliku lub problem z zabezpieczeniami).	W tym przykładzie nie można wkleić danych Schowka do programu Paint. W tym przykładzie użytkownik nie może zainstalować uaktualnienia oprogramowania.
Problemy z danymi wejściowymi użytkownika Użytkownik wprowadził wartość, która jest niepoprawna lub niespójna z innymi danymi wejściowymi użytkownika.	W tym przykładzie użytkownik wprowadził niepoprawną wartość czasu. W tym przykładzie dane wejściowe użytkownika nie mają poprawnego formatu.

Wytyczne

Prezentacja

• Używaj okien dialogowych zadań zawsze, gdy jest to odpowiednie , aby uzyskać spójny wygląd i układ. Okna dialogowe zadań wymagają systemu Windows Vista lub nowszego, więc nie są odpowiednie dla starszych wersji systemu Windows. Jeśli musisz użyć pola komunikatu, oddziel instrukcję główną od instrukcji uzupełniającej z dwoma podziałami wierszy.

Błędy danych wejściowych użytkownika

• Jeśli to możliwe, zapobiegaj lub zmniejszaj błędy danych wejściowych użytkownika przez:
  • Używanie kontrolek, które są ograniczone do prawidłowych wartości.
  • Wyłączenie kontrolek i elementów menu po kliknięciu spowoduje błąd, o ile jest oczywiste, dlaczego kontrolka lub element menu jest wyłączony.
  • Podawanie dobrych wartości domyślnych.

niepoprawne:

W tym przykładzie dla ograniczonych danych wejściowych jest używane nieprzeciętne pole tekstowe. Zamiast tego użyj suwaka.

• Użyj moderowej obsługi błędów (błędów w miejscu lub dymków) w celu uzyskania kontekstowych problemów z danymi wejściowymi użytkownika.
• Użyj dymków dla niekrytycznych, jednopunktowych problemów wejściowych użytkowników wykrytych w polu tekstowym lub natychmiast po utracie fokusu.Balony nie wymagają dostępnego miejsca na ekranie ani dynamicznego układu wymaganego do wyświetlania komunikatów w miejscu. Wyświetlać tylko jeden dymek naraz. Ponieważ problem nie jest krytyczny, ikona błędu nie jest konieczna. Balony odchodzą po kliknięciu, rozwiązaniu problemu lub po przekroczeniu limitu czasu.

W tym przykładzie balon wskazuje na problem wejściowy, który nadal występuje w kontrolce.

• Użyj błędów w miejscu w przypadku opóźnionego wykrywania błędów, zazwyczaj błędów znalezionych przez kliknięcie przycisku zatwierdzenia. (Nie używaj błędów w miejscu dla ustawień, które są natychmiast zatwierdzane). Jednocześnie może występować wiele błędów w miejscu. Użyj zwykłego tekstu i ikony błędu 16x16 pikseli, umieszczając je bezpośrednio obok problemu, gdy jest to możliwe. Błędy w miejscu nie odejdą, chyba że użytkownik zatwierdzi i nie znaleziono żadnych innych błędów.

W tym przykładzie dla błędu znalezionego w miejscu jest używany błąd, klikając przycisk zatwierdzania.

• Użyj obsługi błędów modalnych (okien dialogowych zadań lub okien komunikatów) dla wszystkich innych problemów, w tym błędów obejmujących wiele kontrolek lub niezwiązanych z kontekstem lub błędów niezwiązanych z danymi wejściowymi, klikając przycisk zatwierdzania.
• Gdy zgłaszany jest problem z danymi wejściowymi użytkownika, ustaw fokus danych wejściowych na pierwszą kontrolkę z nieprawidłowymi danymi. W razie potrzeby przewiń kontrolkę do widoku. Jeśli kontrolka jest polem tekstowym, zaznacz całą zawartość. Zawsze powinno być oczywiste, do czego odnosi się komunikat o błędzie.
• Nie usuwaj niepoprawnych danych wejściowych. Zamiast tego pozostaw to pole, aby użytkownik mógł zobaczyć i rozwiązać problem bez rozpoczynania pracy.
  • Wyjątek: Wyczyść niepoprawne pola tekstowe haseł i numeru PIN, ponieważ użytkownicy nie mogą skutecznie poprawiać zamaskowanych danych wejściowych.

Rozwiązywanie problemów

• Unikaj tworzenia problemów z rozwiązywaniem problemów. Nie polegaj na pojedynczym komunikacie o błędzie, aby zgłosić problem z kilkoma różnymi przyczynami wykrywalnymi.
• Użyj innego komunikatu o błędzie (zazwyczaj innej instrukcji uzupełniającej) dla każdej wykrywalnej przyczyny. Jeśli na przykład nie można otworzyć pliku z kilku powodów, podaj oddzielną instrukcję uzupełniającą z każdego powodu.
• Użyj komunikatu z wieloma przyczynami tylko wtedy, gdy nie można określić określonej przyczyny. W takim przypadku przedstawimy rozwiązania w kolejności prawdopodobieństwa rozwiązania problemu. Dzięki temu użytkownicy mogą wydajniej rozwiązywać ten problem.

Ikony

• Modalne okna dialogowe komunikatów o błędzie nie mają ikon paska tytułu. Ikony paska tytułu są używane jako wizualne rozróżnienie między oknami podstawowymi a oknami pomocniczymi.

• Użyj ikony błędu. Wyjątki:

  • Jeśli błąd jest problemem z danymi wejściowymi użytkownika wyświetlanymi przy użyciu modalnego okna dialogowego lub balonu, nie używaj ikony. Jest to sprzeczne z zachęcającym tonem systemu Windows. Jednak komunikaty o błędach w miejscu powinny używać małej ikony błędu (16x16 pikseli), aby wyraźnie zidentyfikować je jako komunikaty o błędach.

    

    

    W tych przykładach problemy z danymi wejściowymi użytkownika nie wymagają ikon błędów.

    

    W tym przykładzie komunikat o błędzie w miejscu wymaga małej ikony błędu, aby wyraźnie zidentyfikować go jako komunikat o błędzie.

• Jeśli problem dotyczy funkcji, która ma ikonę (a nie problem z wprowadzaniem danych przez użytkownika), możesz użyć ikony funkcji z nakładką błędu. Jeśli to zrobisz, użyj również nazwy funkcji jako tematu błędu.

  

  W tym przykładzie ikona funkcji ma nakładkę błędów, a funkcja jest przedmiotem błędu.

• Nie używaj ikon ostrzeżeń dla błędów. Jest to często wykonywane, aby prezentacja czuła się mniej ciężka. Błędy nie są ostrzeżeniami.

  niepoprawne:

  

  W tym przykładzie ikona ostrzeżenia jest niepoprawnie używana, aby błąd był mniej poważny.

Aby uzyskać więcej wytycznych i przykładów, zobacz Standardowe ikony.

Stopniowe ujawnianie

• Użyj przycisku Pokaż/Ukryj szczegóły, aby ukryć zaawansowane lub szczegółowe informacje w komunikacie o błędzie. Upraszcza to komunikat o błędzie dla typowego użycia. Nie ukrywaj potrzebnych informacji, ponieważ użytkownicy mogą go nie znaleźć.

W tym przykładzie przycisk progresywnego ujawniania pomaga użytkownikom przejść do szczegółów, jeśli tego chcą, lub uprościć interfejs użytkownika, jeśli nie.

• Nie używaj opcji Pokaż/Ukryj szczegóły, chyba że naprawdę jest więcej szczegółów. Nie tylko przetwórz istniejące informacje w bardziej pełnym formacie.
• Nie używaj opcji Pokaż/Ukryj szczegóły, aby wyświetlić informacje pomocy. Zamiast tego użyj linków Pomocy.

Aby uzyskać wskazówki dotyczące etykietowania, zobacz Progresywne mechanizmy kontroli ujawniania.

Nie pokazuj ponownie tej wiadomości

• Jeśli komunikat o błędzie wymaga tej opcji, ponownie rozważ błąd i jego częstotliwość. Jeśli ma on wszystkie cechy dobrego błędu (istotne, możliwe do działania i rzadko), nie powinno to mieć sensu dla użytkowników, aby go pominąć.

Aby uzyskać więcej wytycznych, zobacz okna dialogowe.

Wartości domyślne

• Wybierz najbezpieczniejszą, najmniej destrukcyjną lub najbezpieczniejszą odpowiedź na wartość domyślną. Jeśli bezpieczeństwo nie jest czynnikiem, wybierz najbardziej prawdopodobne lub wygodne polecenie.

Pomoc

• Projektuj komunikaty o błędach, aby uniknąć potrzeby pomocy. Zazwyczaj użytkownicy nie powinni czytać tekstu zewnętrznego, aby zrozumieć i rozwiązać problem, chyba że rozwiązanie wymaga kilku kroków.
• Upewnij się, że zawartość Pomocy jest odpowiednia i przydatna. Nie powinno to być pełne odtworzenie komunikatu o błędzie, ale powinno zawierać przydatne informacje wykraczające poza zakres komunikatu o błędzie, takie jak sposoby uniknięcia problemu w przyszłości. Nie udostępniaj linku Pomoc tylko dlatego, że możesz.
• Użyj konkretnych, zwięzłych, odpowiednich linków Pomocy, aby uzyskać dostęp do zawartości Pomocy. W tym celu nie używaj przycisków poleceń ani progresywnego ujawniania.
• W przypadku komunikatów o błędach, których nie można określić i wykonać akcji, rozważ udostępnienie linków do zawartości Pomocy online. Dzięki temu można udostępnić użytkownikom dodatkowe informacje, które można zaktualizować po wydaniu programu.

Aby uzyskać więcej wytycznych, zobacz Pomoc.

Kody błędów

• W przypadku komunikatów o błędach, które nie mogą być specyficzne i możliwe do wykonania akcji lub mogą korzystać z pomocy, rozważ również podanie kodów błędów. Użytkownicy często używają tych kodów błędów do wyszukiwania w Internecie dodatkowych informacji.
• Zawsze podaj opis tekstowy problemu i rozwiązania. Nie należy polegać tylko na kodzie błędu w tym celu.

niepoprawne:

W tym przykładzie kod błędu jest używany jako zamiennik tekstu rozwiązania.

• Przypisz unikatowy kod błędu dla każdej innej przyczyny. Pozwala to uniknąć rozwiązywania problemów.
• Wybierz kody błędów, które można łatwo przeszukiwać w Internecie. Jeśli używasz kodów 32-bitowych, użyj reprezentacji szesnastkowej z wiodącymi znakami "0x" i wielkimi literami.

poprawna:

1234

0xC0001234

niepoprawne:

-1

-67113524

• Użyj opcji Pokaż/Ukryj szczegóły, aby wyświetlić kody błędów. Fraza jako kod błędu: <error code>.

W tym przykładzie kod błędu jest używany do uzupełnienia komunikatu o błędzie, który może skorzystać z dalszych informacji.

Dźwięk

• Nie dołączaj komunikatów o błędach z efektem dźwiękowym ani sygnałem dźwiękowym. To jest jarring i niepotrzebne.
  • Wyjątek: Odtwórz efekt dźwięku Krytyczne zatrzymanie, jeśli problem ma kluczowe znaczenie dla działania komputera, a użytkownik musi podjąć natychmiastowe działania, aby zapobiec poważnym konsekwencjom.

Tekst

Ogólne

• Usuń nadmiarowy tekst. Poszukaj go w tytułach, instrukcjach głównych, instrukcjach uzupełniających, linkach poleceń i przyciskach zatwierdzania. Ogólnie rzecz biorąc, pozostaw pełny tekst w instrukcjach i kontrolkach interaktywnych i usuń wszelkie nadmiarowość z innych miejsc.
• Użyj wyśrodkowanych przez użytkownika wyjaśnień. Opisz problem pod względem akcji lub celów użytkownika, a nie pod względem tego, z czym oprogramowanie jest niezadowolone. Użyj języka, który użytkownicy docelowi rozumieją i używają. Unikaj żargonu technicznego.

niepoprawne:

poprawna:

W tych przykładach poprawna wersja mówi językiem użytkownika, podczas gdy niepoprawna wersja jest nadmiernie techniczna.

• Nie używaj następujących słów:
  • Błąd, błąd (zamiast tego użyj problemu)
  • Nie można (zamiast tego nie można użyć polecenia )
  • Niedozwolone, nieprawidłowe, nieprawidłowe (zamiast tego użyj nieprawidłowego)
  • Przerwanie, zabicie, zakończenie (zamiast tego użyj polecenia stop)
  • Katastrofalne, śmiertelne (zamiast tego należy używać poważnych)

Te terminy są niepotrzebne i sprzeczne z zachęcającym tonem systemu Windows. W przypadku poprawnego użycia ikona błędu wystarczająco komunikuje się, że występuje problem.

niepoprawne:

poprawna:

W niepoprawnym przykładzie terminy "katastrofalne" i "niepowodzenie" są niepotrzebne.

• Nie używaj fraz, które obwiniają użytkownika ani nie oznaczają błędu użytkownika. Unikaj używania ciebie i swojego w frazach. Chociaż aktywny głos jest ogólnie preferowany, należy użyć pasywnego głosu, gdy użytkownik jest tematem i może czuć się obwiniany za błąd, jeśli używany był aktywny głos.

niepoprawne:

poprawna:

Niepoprawny przykład obwinia użytkownika za pomocą aktywnego głosu.

• Podawaj konkretne informacje. Unikaj niejasnego sformułowania, takiego jak błąd składniowy i niedozwolona operacja. Podaj określone nazwy, lokalizacje i wartości obiektów.

niepoprawne:

Nie można odnaleźć pliku.

Dysk jest pełny.

Wartość poza zakresem.

Znak jest nieprawidłowy.

Urządzenie jest niedostępne.

Te problemy byłyby znacznie łatwiejsze do rozwiązania z określonymi nazwami, lokalizacjami i wartościami.

• Nie należy udzielać prawdopodobnie mało prawdopodobnych problemów, przyczyn ani rozwiązań w celu uzyskania konkretnych rozwiązań. Nie udostępniaj problemu, przyczyny ani rozwiązania, chyba że prawdopodobnie będzie to właściwe. Na przykład lepiej powiedzieć, że wystąpił nieznany błąd niż coś, co może być niedokładne.
• Unikaj słowa "proszę", z wyjątkiem sytuacji, w których użytkownik jest proszony o zrobienie czegoś niewygodnego (takiego jak oczekiwanie) lub oprogramowanie jest winne sytuacji.

poprawna:

Czekaj, aż system Windows kopiuje pliki na komputer.

• Użyj słowa "przepraszam" tylko w komunikatach o błędach, które powodują poważne problemy dla użytkownika (na przykład utrata danych lub brak możliwości korzystania z komputera). Nie przeprosij, jeśli problem wystąpił podczas normalnego działania programu (na przykład jeśli użytkownik musi poczekać na odnalezienie połączenia sieciowego).

poprawna:

Niestety, usługa Fabrikam Backup wykryła nieodwracalny problem i została zamknięta w celu ochrony plików na komputerze.

• Zapoznaj się z produktami, używając ich krótkich nazw. Nie używaj pełnych nazw produktów ani symboli znaków towarowych. Nie dołączaj nazwy firmy, chyba że użytkownicy skojarzą nazwę firmy z produktem. Nie dołączaj numerów wersji programu.

niepoprawne:

poprawna:

W niepoprawnym przykładzie używane są pełne nazwy produktów i symbole znaków towarowych.

• Użyj podwójnych cudzysłowów wokół nazw obiektów. Dzięki temu tekst jest łatwiejszy do przeanalizowania i pozwala uniknąć potencjalnie kłopotliwych stwierdzeń.
  • Wyjątek: W pełni kwalifikowane ścieżki plików, adresy URL i nazwy domen nie muszą zawierać podwójnych cudzysłowów.

poprawna:

W tym przykładzie komunikat o błędzie byłby mylący, gdyby nazwa obiektu nie znajdowała się w cudzysłowie.

• Unikaj rozpoczynania zdań z nazwami obiektów. Takie działanie jest często trudne do przeanalizowana.
• Nie używaj wykrzykników ani wyrazów ze wszystkimi wielkimi literami. Wykrzykniki i wielkie litery sprawiają, że czujesz się, jakbyś krzyczał na użytkownika.

Aby uzyskać więcej wytycznych i przykładów, zobacz Style and Tone (Styl i ton).

Tytuły

• Użyj tytułu, aby zidentyfikować polecenie lub funkcję, z której pochodzi błąd. Wyjątki:
  • Jeśli błąd jest wyświetlany przez wiele różnych poleceń, rozważ użycie nazwy programu.
  • Jeśli ten tytuł będzie nadmiarowy lub mylący z instrukcją główną, użyj nazwy programu.
• Nie używaj tytułu, aby wyjaśnić lub podsumować problem , który jest celem głównej instrukcji.

niepoprawne:

W tym przykładzie tytuł jest niepoprawnie używany do wyjaśnienia problemu.

• Użyj wielkich liter w stylu tytułu bez kończenia interpunkcji.

Główne instrukcje

• Użyj głównej instrukcji, aby opisać problem w jasnym, prostym, określonym języku.
• Używaj tylko jednego, kompletnego zdania. Przeanalizuj instrukcję główną w dół do podstawowych informacji. Możesz pozostawić temat niejawny, jeśli jest to twój program lub użytkownik. Uwzględnij przyczynę problemu, jeśli możesz to zrobić zwięźle. Jeśli musisz jeszcze coś wyjaśnić, użyj instrukcji uzupełniającej.

niepoprawne:

W tym przykładzie cały komunikat o błędzie jest umieszczany w głównej instrukcji, co utrudnia odczytywanie.

• Należy podać konkretne informacje, jeśli istnieją obiekty, nadaj im nazwy.
• Unikaj umieszczania pełnych ścieżek plików i adresów URL w instrukcji głównej. Zamiast tego należy użyć krótkiej nazwy (takiej jak nazwa pliku) i umieścić pełną nazwę (taką jak ścieżka pliku) w instrukcji uzupełniającej. Można jednak umieścić jedną pełną ścieżkę pliku lub adres URL w instrukcji głównej, jeśli komunikat o błędzie nie wymaga innej instrukcji uzupełniającej.

W tym przykładzie tylko nazwa pliku znajduje się w głównej instrukcji. Pełna ścieżka znajduje się w instrukcji uzupełniającej.

• Nie należy w ogóle podawać pełnej ścieżki i adresu URL pliku, jeśli jest to oczywiste z kontekstu.

W tym przykładzie użytkownik zmienia nazwę pliku z Eksploratora Windows. W takim przypadku pełna ścieżka pliku nie jest potrzebna, ponieważ jest oczywista z kontekstu.

• Zawsze, gdy jest to możliwe, użyj czasu obecnego.
• Użyj wielkich liter w stylu zdania.
• Nie dołączaj końcowych okresów, jeśli instrukcja jest instrukcją. Jeśli instrukcja jest pytaniem, dołącz końcowy znak zapytania.

Szablony instrukcji głównych

Chociaż nie ma rygorystycznych reguł fraz, spróbuj użyć następujących głównych szablonów instrukcji, jeśli to możliwe:

• [opcjonalna nazwa podmiotu] nie może [wykonać akcji]
• [opcjonalna nazwa podmiotu] nie może [wykonać akcji], ponieważ [reason]
• [opcjonalna nazwa podmiotu] nie może [wykonać akcji] do "[nazwa obiektu]"
• [opcjonalna nazwa podmiotu] nie może [wykonać akcji] do "[nazwa obiektu]", ponieważ [reason]
• Za mało [zasobu], aby [wykonać akcję]
• [Nazwa podmiotu] nie ma [nazwy obiektu] wymaganego dla [celu]
• [Urządzenie lub ustawienie] jest wyłączone, aby [niepożądane wyniki]
• [Urządzenie lub ustawienie] nie jest [dostępne | znaleziono | włączone | włączone]
• "[nazwa obiektu]" jest obecnie niedostępny
• Niepoprawna nazwa użytkownika lub hasło
• Nie masz uprawnień dostępu do "[nazwa obiektu]"
• Nie masz uprawnień do [wykonania akcji]
• [nazwa programu] wystąpił poważny problem i musi natychmiast zamknąć

Oczywiście wprowadź zmiany zgodnie z potrzebami, aby główne instrukcje były poprawne gramatyczne i zgodne z głównymi wytycznymi instrukcji.

Instrukcje uzupełniające

• Użyj instrukcji uzupełniającej, aby:
  • Podaj dodatkowe szczegóły dotyczące problemu.
  • Wyjaśnij przyczynę problemu.
  • Wyświetl listę kroków, które użytkownik może wykonać, aby rozwiązać problem.
  • Podaj miary, aby zapobiec ponownemu wystąpieniu problemu.
• Jeśli to możliwe, zaproponuj praktyczne, przydatne rozwiązanie, aby użytkownicy mogli rozwiązać problem. Upewnij się jednak, że proponowane rozwiązanie prawdopodobnie rozwiąże problem. Nie marnuj czasu użytkowników, sugerując możliwe, ale nieprawdopodobne rozwiązania.

niepoprawne:

W tym przykładzie, chociaż problem i jego zalecane rozwiązanie są możliwe, są one bardzo mało prawdopodobne.

• Jeśli problem jest nieprawidłową wartością wprowadzoną przez użytkownika, użyj instrukcji uzupełniającej, aby wyjaśnić prawidłowe wartości. Użytkownicy nie powinni określać tych informacji z innego źródła.
• Nie udostępniaj rozwiązania, jeśli można go trywialnie wywołać z instrukcji problemu.

W tym przykładzie nie jest wymagana żadna instrukcja uzupełniająca; rozwiązanie może być trywialnie wywołane z instrukcji problemu.

• Jeśli rozwiązanie ma wiele kroków, należy przedstawić kroki w kolejności, w której należy je wykonać. Należy jednak unikać rozwiązań wieloetapowych, ponieważ użytkownicy mają trudności z zapamiętywaniem więcej niż dwóch lub trzech prostych kroków. Jeśli wymagane są więcej kroków, zapoznaj się z odpowiednim tematem Pomocy.
• Zachowaj zwięzłe instrukcje uzupełniające. Podaj tylko to, co użytkownicy muszą wiedzieć. Pomiń niepotrzebne szczegóły. Celem jest maksymalnie trzy zdania o średniej długości.
• Aby uniknąć błędów podczas wykonywania instrukcji przez użytkowników, przed akcją umieść wyniki.

poprawna:

Aby ponownie uruchomić system Windows, kliknij przycisk OK.

niepoprawne:

Kliknij przycisk OK, aby ponownie uruchomić system Windows.

W niepoprawnym przykładzie użytkownicy będą bardziej skłonni kliknąć przycisk OK przypadkowo.

• Nie zaleca się skontaktowania się z administratorem, chyba że jest to jednym z najbardziej prawdopodobnych rozwiązań problemu. Zarezerwuj takie rozwiązania problemów, które naprawdę mogą być rozwiązywane tylko przez administratora.

niepoprawne:

W tym przykładzie najprawdopodobniej problem dotyczy połączenia sieciowego użytkownika, więc nie warto skontaktować się z administratorem.

• Nie zalecamy kontaktowania się z pomocą techniczną. Opcja kontaktu z pomocą techniczną w celu rozwiązania problemu jest zawsze dostępna i nie musi być promowana za pośrednictwem komunikatów o błędach. Zamiast tego skoncentruj się na pisaniu przydatnych komunikatów o błędach, aby użytkownicy mogli rozwiązywać problemy bez kontaktu z pomocą techniczną.

niepoprawne:

W tym przykładzie komunikat o błędzie niepoprawnie zaleca skontaktowanie się z pomocą techniczną.

• Używaj pełnych zdań, wielkich liter zdań i kończenia interpunkcji.

przycisków Zatwierdź

• Jeśli komunikat o błędzie zawiera przyciski poleceń lub linki poleceń, które rozwiązują problem, postępuj zgodnie z odpowiednimi wytycznymi w oknach dialogowych.
• Jeśli program musi zakończyć działanie w wyniku błędu, podaj przycisk Zakończ program. Aby uniknąć nieporozumień, nie używaj funkcji Zamknij w tym celu.
• W przeciwnym razie podaj przycisk Zamknij. Nie używaj przycisku OK dla komunikatów o błędach, ponieważ to sformułowanie oznacza, że problemy są ok.
  • Wyjątek: Użyj przycisku OK, jeśli mechanizm raportowania błędów ma stałe etykiety (tak jak w przypadku interfejsu API MessageBox).

Dokumentacja

Podczas odwoływania się do błędów:

• Zapoznaj się z błędami zgodnie z ich główną instrukcją. Jeśli główna instrukcja jest długa lub szczegółowa, podsumuj ją.
• W razie potrzeby możesz odwołać się do okna dialogowego komunikatu o błędzie jako komunikatu. Zapoznaj się z komunikatem o błędzie tylko w programowaniu i inną dokumentację techniczną.
• Jeśli to możliwe, sformatuj tekst przy użyciu pogrubienia. W przeciwnym razie umieść tekst w cudzysłowie tylko wtedy, gdy jest to wymagane, aby zapobiec nieporozumieniu.

Przykład: Jeśli w komunikacie stacji dysków nie ma dysku CD , włóż nowy dysk CD na dysku i spróbuj ponownie.