Podczas szkolenia ITCQF (relacja) spotkaliśmy Adriana, który pracuje z narzędziem Documentor. Po krótkich namowach zgodził się opisać dla Was narzędzie do intuicyjnego i przejrzystego tworzenia dokumentacji z wykorzystaniem WordPress'a - dziękujemy!
Jak już zapewne zdążyliście zauważyć, bardzo lubimy darmowe narzędzia. Dzisiaj mamy dla Was trzy małe, ale za to pomocne aplikacje, z których sami korzystamy i uważamy, że są godne polecenia. Nie są one ściśle związane z pracą Tech Writera, jednak zdecydowanie mogą Wam ułatwić codzienne zadania.
Jeśli spotkaliście się kiedyś z takim błędem podczas generowania dokumentów przy użyciu RoboHelpa 11, to bardzo możliwe, że poziom Waszej frustracji osiągnął absolutne maksimum. Dlatego tym bardziej mamy nadzieję, że opis problemu z jakim sami borykaliśmy się oraz rozwiązanie jakie udało nam się opracować pozwolą na ocalenie chociaż kilku dobrych ludzi przed utratą zmysłów 😉
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ć.
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.