技术文档不必枯燥

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

Opensource.com

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

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

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

但是,就像生活中的大多数事情一样,也有例外。枯燥乏味对于参考资料来说很棒: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 许可本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.