技术文档不必枯燥

2 位读者喜欢这篇文章。
Technical documentation doesn't have to be dull

Opensource.com

今年早些时候,我描述了优秀文档的三个重要特征:简洁、一致和简单。 我写道,好的措辞对于理解和翻译非常重要。 但这并不意味着它必须枯燥乏味。

想知道一个秘密吗? 我最喜欢的科技书籍是 For Dummies 系列。 和你们许多人一样,我的书架上也有不少 O'Reilly 的书,它们都很棒。 我从我拥有的严肃科技书籍中学到了很多东西,但是当我要坐下来学习一个不熟悉的科目时,幽默的书籍最能吸引我的注意力。 如果你想让我关注你的文档,保持我兴趣的最佳方法是大量使用“空前绝后满天飞!”的梗。 看来我选错了星期来戒掉 [装订] 胶水。

让你项目的个性融入文档是可以的,甚至是有益的,但有一些注意事项。 要注意在另一种语言,甚至同一种语言的不同方言中没有意义的口语表达。 要知道你诙谐的流行文化典故可能会被错过,或者不被认为有趣(是的,甚至有人不喜欢“空前绝后满天飞!”)。 目标不是试图变得有趣,而是允许你自己的风格。 正如 Bob Reselman 在 关于他在 SCaLE 14x 演讲的采访 中告诉 Rikki Endsley 的那样:“枯燥乏味真糟糕。”

但与生活中的大多数事情一样,也有例外。 枯燥乏味对于参考资料来说很棒:API 文档(尽管可以在示例中随意展示个性)、词汇表和发行说明。

想想你喜欢阅读哪种文档,然后就写那种文档。 如果人们不喜欢它,你可以肯定他们会让你知道。

标签
User profile image.
Ben Cotton 是一名受过气象学训练的气象学家,但天气是一个很棒的爱好。 Ben 在红帽公司担任 Fedora 项目经理。 他是《开源项目项目管理》一书的作者。 在 Twitter (@FunnelFiasco) 或 FunnelFiasco.com 上找到他。

7 条评论

我同意。 幽默也是吸引我注意力的关键。

我同意,但是在翻译开源项目手册时,我了解到:我们不要忘记幽默非常难以翻译,甚至不可能翻译,因为语言始终具有特定的地理、社会或其他背景......

回复 ,作者:Don Watkins

Jan,这是一个很好的观点。 幽默在很大程度上是文化性的,因此很难翻译。 如果您对如何在保持这种平衡以及翻译人员如何在本地化笑话时尝试保留语气方面有任何建议,我认为这将是一篇很棒的 Doc Dish 文章。

回复 ,作者:janniggemann

退一步说,人们应该以更对话的语气编写文档。 不是漫无边际,而是简洁友好。 这对于保持读者兴趣大有帮助。 多年来,我在各种技术写作工作中都尝试过这样做,但结果好坏参半。 我感觉让开源项目的成员接受这一点比试图说服保守的商业人士接受其好处更容易......

与几乎所有事物一样,人们可以说有好的《For Dummies》系列书籍,也有不太好甚至令人恼火的《For Dummies》系列书籍。 在其中一些书中,特立独行的幽默尝试逐渐变得令人恼火。
在帮助为 Scribus 编写 400 多页的手册后,我知道这方面非常具有挑战性。 为此,我们尽力在可能的情况下使其轻松一些,有时这可能来自您在插图中选择的照片,但我们也努力保持一致的写作风格。

在商业技术写作中,任何不追求极度枯燥的尝试几乎肯定会被驳回为“不专业”。 开源不应感到同样的约束。

有用的真实示例总是好的。 我遇到过的一些最好的文档是 Borland 的 Turbo C++ 的文档。 很多示例代码可以直接拿来使用。

© . All rights reserved.