六个非常规写作思想
除此之外，还有常规的文档页面-示例，教程，说明控件支持的数据源，如何对控件数据进行过滤和分组的文章等。小时的问题是这些文章是否应提及所有这些内容。我之前提到的2000多种属性，方法和事件。 这个问题的一个答案是“是”，因为“如果您不全部提及它们，那么用户还将如何了解它们？”从这一观点出发，您正在将文档转变为仅显示一部分API和留给读者去寻找剩余的东西。 我不同意。 鉴于文档中已经包含“ API参考”部分，读者可以自由浏览这堆内容，并为每个可用的公共项目找到描述。 单独的帮助文章则是完全不同的实体。 作为作者，您不应以提及现有API的每一点为目标。 技术作家的工作比遍历Visual Studio的“属性网格”中的属性A到Z更重要。 这让我想起了一个原始人，他使用mo吟声，吟声和壁画在一个部落面前分享他最近的发现-火热，石头折断，猛stick象很强。 相反，有一个故事。 您的工作是引导人们开发复杂的产品-为他们画一条学习曲线。 您的目标不是要提及每个现有成员，而是要说明某个功能的主要用例是什么，可以直接使用哪些功能。 然后添加更多特定的案例，将最高级的特定场景留在边缘，然后将其转移到专用示例和操作方法上。 一言以蔽之，过滤信息并将其分解成几部分，然后根据这些内容构建叙述。 结构 忘记什么是“功能” 多年来，我们一直在编写基于功能的文档。…
