技术文档不必枯燥

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

Opensource.com

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

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

让你的项目的个性融入文档是可以的,甚至是有益的,但有一些注意事项。要注意在另一种语言中,甚至在同一种语言的不同方言中,都无法理解的口语表达。要知道你诙谐的流行文化引用可能会被错过,或者不被认为是好笑的(是的,甚至有人不喜欢“空前绝后满天飞!”)。目标不是试图变得滑稽,而是允许你自己的风格。正如 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++。很多示例代码都可以直接拿来使用。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.