Halo! Czy ktoś wie jak tworzyć dokumentację maszynową?
Ostatnio dużo pisaliśmy o tworzeniu dokumentacji API, wiec teraz dla odmiany napiszemy trochę o tym jak sobie pomóc w tworzeniu dokumentacji maszynowej.
Ostatnio dużo pisaliśmy o tworzeniu dokumentacji API, wiec teraz dla odmiany napiszemy trochę o tym jak sobie pomóc w tworzeniu dokumentacji maszynowej.
Brakuje Wam sprytnego narzędzia do korekty? Spellcheck w przeglądarce zawodzi? Ten w Wordzie daje niemądre sugestie? Dodaliście coś do jednego słownika, ale teraz używacie drugiego? Być może rozwiązaniem tych wszystkich problemów jest Grammarly? A być może Grammarly to wielka klapa?
Czy do Was też przychodzą programiści z pytaniami co napisać w wyskakującym okienku, które i tak nigdy się przecież nie pokaże? Jeśli tak, to dzisiejszy wpis może Was zainteresować. Niedawno trafiliśmy na artykuł poruszający właśnie to zagadnienie. Pisanie krótkich komunikatów to tak naprawdę rodzaj sztuki - w małym okienku musimy zawrzeć wszystkie niezbędne informacje zachowując przy tym poprawność językową i jasność przekazu. Zasada jest prosta - im mniej mamy miejsca, tym więcej czasu spędzimy pisząc komunikat. Warto jednak poświęcić czas na stworzenie komunikatów dobrej jakości, ponieważ są one istotnym elementem każdego systemu. Pełnią one rolę pierwszej linii wsparcia, dlatego jeśli są słabej jakości, negatywnie wpływają na jakość produktu oraz powodują frustrację użytkowników, co z kolei przekłada się bezpośrednio na koszty wsparcia technicznego. Jak powszechnie wiadomo, każda terapia zaczyna się od przyznania, że mamy problem. Tak samo jest w przypadku oprogramowania. Każdy system ma swoje problemy, dlatego dopiero kiedy to zaakceptujemy, możemy zabrać się do tworzenia komunikatów o błędach z odpowiednim nastawieniem. Naszym celem jest przede wszystkim pomoc użytkownikom. Poniżej garść wytycznych jak tworzyć dobre komunikaty o błędach (bynajmniej nie takie, jak komunikat w grafice do tego wpisu). Są one skierowane zarówno do dokumentalistów jak i programistów.
Drugi dzień konferencji soap! przyniósł jeszcze więcej prezentacji, które podzielone zostały na dwie ścieżki. Każdy mógł wybierać i przebierać w tematach. Niestety nie byliśmy w stanie uczestniczyć we wszystkich prezentacjach, dlatego przedstawiamy skrótowo tylko niektóre z nich.
Podejście minimalistyczne w pisaniu dokumentacji jest jak najbardziej wskazane, o czym wspominaliśmy w jednym z postów jakiś czas temu. Długie, skomplikowane i przeładowane informacjami instrukcje to samo zło, którego należy unikać.