编写用户手册的人不一定是程序员,他们需要一个可视化编辑器。一个主要问题是创作工具的内部格式;它应该是可读的文本/html,因此很容易比较签入版本控制的各个页面的版本。
11 回答
文档书
(来源:docbook.org)
Microsoft HTML Help Workshop 可用于创建高质量的专业 CHM 帮助文件。您所需要的只是一堆 HTML 文件。该工具将所有这些“编译”并捆绑到一个帮助文件中。可以使用 Microsoft Word/Frontpage 甚至 Dreamweaver 生成 HTML 文件。您可能需要考虑对这些 HTML 文件进行源代码控制。
在我以前的工作中,他们使用了 madcap 软件的一个工具,叫做flare。
它似乎工作得很好。
还有其他允许编写帮助文件的专业产品,它们支持“上下文 ID”,这使得上下文敏感的帮助成为可能。Doc To Help和RoboHelp就是这些类型的产品。
一个值得考虑的好组合是 Subversion、DocBook 和 Publican。
目前,这是全球最大的开源解决方案供应商使用的工具链之一,也是全球企业市场上大量使用基于 Linux 的操作系统的名称。大多数(几乎所有)Red Hat 的官方文档都是以这种方式创建的。Fedora 也是如此。
这里的主要“优点”是这些是免费提供的工具,在技术作家市场上有很强的重叠。所有这些都能够(但可能不想)用 XML 编写,并且拿起 DocBook 就像在 90 年代拿起 HTML。Subversion 是一个非常常见的版本控制工具,它和 DocBook 一样是比较容易实现和使用的。Publican 是一个很棒的发布工具,可以获取 DocBook XML,并将其发布为 PDF、HTML、HTML-single 等。显然,您的作者可以使用像 Serna 这样的 WYSIWYG,但我在 Geany(在 Fedora 上)或 TextMate(在OS X)个人。
主要的“缺点”是对技术性的看法。您的作者可能想要 WYSIWYG(并且可以拥有它),并且根据您的文档需求,这可能是您最终使用的。如您所知,专门修复 Microsoft Word 样式(和标记)的“技术作家”有一个市场,因此将“创作”与“发布”区分开来的论点基于经过验证但不同的组织用例要求文档保持与工程/编程/源生产的相同标准。
您将获得的一些极端建议来自那些已经接触过 XML 文档价值的人和公司,尤其是那些在 DITA 领域的人,在这些领域中,某些跨国公司因受格式和影响的收购而享有盛誉。产品知识的可用性。还有人认为将文档锁定为“粘性”或封闭格式无助于未来的维护需求。这就是开源选项在企业层面获得支持的地方。另外,显然,它是免费的。
您可以使用 Subversion 和 MGTEK Help Producer。Help Producer 从 Word 文档制作帮助文件。TortoiseSVN 带有脚本来比较 Word 文档的不同版本,在 Word 本身(Word 有一个版本比较工具)。
您的用户会想要一个与他们正在编辑的工具相似的视觉差异工具。如果他们只是稍微没有技术含量,DocBook 或 Latex 将无法工作(我已经尝试为我的用户提供这两种工具,我什至尝试将 Epic Editor 作为 DocBook 编辑器,它非常昂贵,但毕竟效果不佳)。坚持他们知道的东西(Word)可以避免很多麻烦。
一开始我也非常不愿意走这条路,因为我想要一个“技术上更完美”的解决方案,但随着时间的推移,我意识到拥有快乐和高效的用户更为重要。只是说我知道您来自哪里,但请尝试 Word 路线 - 它在实践中比所有“纯”基于文本的解决方案效果更好。普通用户不喜欢基于标记的编辑。
我创建了一个名为Mandown的文档系统(Markdown/Html/Javascript/基于文件的相对链接文档以实现可移植性),它可以很容易地受到版本控制。您必须单独弄清楚可视化编辑器部分 - 我有时使用至少具有预览功能的HTML-Kit 。
这是另一个检查工具:Xilize
如果您使用的是 Visual Studio,请查看 SandCastle - http://www.codeplex.com/Sandcastle。
还有一些工具可以帮助您构建沙堡文件,尝试在 codeplex 上搜索“sandcastle”。其中之一是 SandCastle Help File Builder ( http://www.codeplex.com/SHFB ),但我从未使用过它,所以我不知道非技术用户是否会对此感到满意。
Mapcap Flare 是最好的商业工具。由 Robodoc 的前开发人员撰写
我们正在使用APT。它与 CI(标准构建工件)很好地集成,并且比 word 文档更活跃。还可以在需要时生成 PDF 和其他格式。