TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: What is not mandated is forbidden From:Steven Jong <stevefjong -at- comcast -dot- net> To:TECHWR-L Digest <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Sat, 21 Jun 2014 12:39:17 -0400
I think the original question touches on the premises of minimalism. As such, it’s interesting to discuss.
Imagine a product with event logging. You can set the logging level to five values, from terse (fatal errors only) to chatty (debug messages for every event). Minimally, you can document that there is logging, there are five levels, here they are, here’s the default, and here’s how to set them.
By the principals of minimalism, that’s all you need to say. (Maybe even that is too much. Here’s how to set log levels. Go explore! Customers will see the default at once, and they can determine for themselves what works for them.)
But it may be that setting the logging level to “terse” results in important errors, such as the system hanging, going unrecorded. It might also be that setting the logging to “chatty” floods the log, fills the disk, and ruins performance. It may be that customers call Support all the time with both these problems. (And it may be that I’m not making this up, but rather describing real situations 8^)
Perhaps I misinterpret minimalism. But I’m not misinterpreting the product line manager who would say not to include such a statement: he’s wrong. Good advice is valuable; I care to minimize support costs; I care to maximize doc value; I care to improve the user experience; I care to just plain do my job. From any of those perspectives, I would include the information, both my example and yours.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Doc-To-Help 2014 v1 now available. SharePoint 2013 support, NetHelp enhancements, and more. Read all about it.
