Which made for bloated release notes that were required to navigate the documentation: A user would need to cross-check the manuals with the release notes to discover the truth about the product.
So everything that happened after code freeze, including new features and lots of fixes, were dumped into the release notes. We knew full well that features would be slipped in after code freeze, but we were already giving the translators the absolute minimum amount of time needed to translate those manuals into ten, twenty, or more languages. Which has always been an idealistic goal and milestone. As I remember, we would shut down the docs sometime around code freeze. When our docs had to be translated, we had to finish the documentation well before the product was complete. After having written manuals for years, I was more than happy to focus on online documentation and leave that messy publication workflow behind.īecause it was messy, and we (the writers) knew that it forced the documentation to be less than it could be. Any mistakes and incomplete information are locked in forever, and those docs will never know about new features or workarounds. Once you move the documentation offline, it’s as good as set in stone. Ok, that might be overstating it a little. But I have to admit that there are still some use cases for it, even if the letters P, D, and F make me shudder in fear. What I need, or might need, is a way to provide that content to users who aren’t online.Īfter setting up and writing content for wikis and other online-only systems for years, the concept of “offline documentation” seems obsolete, even primitive.
To be less vague: I have an online knowledge base/help center. I’m evaluating what I have, and what more I need. I’ve been thinking about documentation tools and publishing platforms.
0 kommentar(er)
