Jakiś czas temu przekonywaliśmy Was, jak użyteczna dla dokumentalisty może być dobrze prowadzona Wiki. Dzisiaj chcielibyśmy przedstawić Wam wikidPada, czyli narzędzie, za pomocą którego możecie tę tezę łatwo zweryfikować.
Jak w każdym zawodzie, tak i w technical writingu, bycie cenionym specjalistą to wynik ciągłej pracy nad warsztatem, nabywanie różnorodnych doświadczeń, a także nieustanne poszukiwanie nowych ścieżek rozwoju. Proponujemy dzisiaj coś, co być może zachęci Was do podjęcia nowego wyzwania. Coś, co naszym zdaniem, będzie świetną okazją do nauki zawodu, zdobycia nowych doświadczeń, ale także zdobycia, często intratnych, kontaktów.
Praca z tekstem nie jest tak prosta jak mogłoby się wydawać. Ciągle nowe wyzwania, terminy na wczoraj, klient sam nie wie czego chce. Nigdy nie jest tak, że po prostu się siada i tworzy.
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.
Nasz ulubiony temat - jak przekazać więcej pisząc mniej - powraca. I będzie powracać, bo na tym właściwie polega cała sztuka przekazywania wiedzy.