技术文档不必枯燥

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

Opensource.com

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

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

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

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

想想你喜欢阅读哪种文档,然后就那样写。如果人们不喜欢,你肯定会知道的。

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

7 条评论

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

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

回复 ,作者 janniggemann

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

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

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

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

© . All rights reserved.