格式指南
标题和子标题
读者会略微多关注标题、项目符号列表和链接,因此确保这些项目的前两到三个词尽可能地“前置加载”信息非常重要。
最佳实践
- 标题和子标题应让读者知道他们将在页面上找到什么内容。
- 它们应简洁准确地描述内容主题。
- 标题应简短(不超过八个词)、切中要点,并使用平实、主动的语言。
- 避免使用双关语、悬念和文化典故。
- 省略开头的冠词(a、the 等)。
页面标题
页面标题应以行动为导向。例如:
- 启用 SCIM
- 安装 Docker Desktop
最佳实践
- 确保页面标题与目录(TOC)条目匹配。
- 如果要在目录文件(_toc.yaml)中的页面标题中使用‘:’,必须将整个标题用“”括起来,以避免破坏构建。
- 如果向 TOC 文件添加新条目,请确保它以斜杠 (/) 结尾。如果不这样做,页面将不会显示侧边导航。
图像
图像,包括屏幕截图,可以帮助读者更好地理解概念。然而,应谨慎使用它们,因为它们容易过时。
最佳实践
- 当您截取屏幕截图时:
- 不要使用占位文本(lorem ipsum)。尝试模拟某人在真实场景中使用该功能的方式,并使用真实的文本。
- 仅捕获相关的 UI。不要包含不必要的空白或无助于说明要点的 UI 区域。
- 保持小巧。如果不需要显示屏幕的全宽,就不要显示。
- 检查图像在页面上的渲染效果。确保图像不模糊或过大。
- 保持一致性。与文档页面上已有的其他屏幕截图协调,以提供一致的阅读体验。
- 为保持 Git 仓库轻量,请(无损地)压缩图像。在将图像添加到仓库之前,请务必压缩它们。在将图像添加到仓库后再压缩实际上会加剧对 Git 仓库的影响(尽管它仍然可以优化浏览时的带宽)。
- 不要忘记从仓库中删除不再使用的图像。
有关如何将图像添加到内容的信息,请参阅有用的组件和格式示例。
链接
注意不要创建太多链接,尤其是在正文文本中。过多的链接会分散注意力,或将读者从当前页面引开。
当人们点击链接时,他们通常会忘记自己的思路,并且尽管没有吸收页面上的所有信息,也可能无法返回原始页面。
最好的链接为读者提供了另一种扫描信息的方式。
最佳实践
- 使用不会误导或承诺过多的平实语言。
- 简短且具有描述性(最好在五个词左右)。
- 让人们能够(以相当高的置信度)预测选择链接后会得到什么。尽可能在链接中镜像目标页面的标题文本。
- 将面向用户和行动的术语放在链接的开头(例如,下载我们的应用)。
- 避免通用的行动号召(例如,点击这里、了解更多)。
- 链接文本时不要包含任何结束标点符号(例如,句点、问号或感叹号)。
- 不要将链接文本设为斜体或粗体,除非它在正常正文中就是如此。
有关如何向内容添加链接的信息,请参阅有用的组件和格式示例。
代码和代码示例
将以下内容格式化为代码:Docker 命令、指令和文件名(包名)。
要应用内联代码样式,请将文本用单个反引号 (`) 括起来。
有关如何向内容添加代码块的信息,请参阅有用的组件和格式示例。
命令的最佳实践
- 命令提示符和 shell:
- 对于非特权 shell,在代码块中的命令前加上 $ 提示符。
- 对于特权 shell,在代码块中的命令前加上 # 提示符。
- 对于远程 shell,添加远程计算机的上下文并排除路径。例如,
user@host $。 - 添加任何特定于 Windows 的命令时,请指定 Windows shell(命令提示符、PowerShell 或 Git Bash)。无需为每个 Windows shell 都包含命令。
- 当您为多个操作系统或 shell 添加命令时,请使用选项卡。有关如何向内容添加选项卡的信息,请参阅选项卡。
- 用户将复制并运行的命令:
- 如果命令产生输出或需要用户验证结果,请为每个命令添加一个代码块。
- 将命令输出与命令分开添加到单独的代码块中。
- 用户不会复制和运行的命令:
- 使用 POSIX 兼容语法。无需包含 Windows 语法。
- 将可选参数用方括号 ( [ ] ) 括起来。
- 在互斥参数之间使用管道 ( | )。
- 在重复参数后使用三个点 ( ... )。
代码的最佳实践
- 当您在列表项下嵌套代码块时,将代码块缩进 3 个空格。
- 省略代码时使用三个点 ( ... )。
提示框
使用提示框来强调页面上的选定信息。
最佳实践
- 将单词 Warning(警告)、Important(重要)或 Note(注意)加粗。不要加粗提示框内的内容。
- 最好避免在一个页面上放置大量文本提示框。如果使用过多,它们会产生杂乱的外观,并且会削弱其影响力。
| 文本提示框 | 使用场景 | 颜色或提示框类型 |
|---|---|---|
| Warning | 使用 Warning 标签向读者发出警告,指出某些操作可能导致硬件损坏或数据丢失。 | 红色 |
✅ 示例:Warning: 当您使用 docker login 命令时,您的凭据会存储在您主目录的 .docker/config.json 文件中。密码在该文件中以 base64 编码。 |
||
| Important | 使用 Important 标签向读者指出某些操作可能导致较低严重性的问题。 | 黄色 |
| ✅ 示例:更新 Docker Desktop 条款 | ||
| Note | 使用 Note 标签提供可能不适用于所有读者的信息,或与主题相关性不大的信息。 | 蓝色 |
| ✅ 示例:删除仓库会删除其包含的所有镜像及其构建设置。此操作无法撤销。 |
有关如何向内容添加提示框的信息,请参阅有用的组件和格式示例。
导航
当记录如何在 Docker Desktop 或 Docker Hub UI 中导航时:
- 始终先使用位置,然后是操作。例如: 从 可见性 下拉列表(位置)中,选择 Public(操作)。
- 简洁且具体。例如: 正确做法:选择 保存。 错误做法:选择 保存 以使更改生效。
- 如果某个步骤必须包含原因,请以该原因开始步骤。这有助于用户更快地浏览。 正确做法:要查看更改,请在合并请求中选择链接。 错误做法:在合并请求中选择链接以查看更改。
可选步骤
如果某个步骤是可选的,请以单词 Optional 开头,后跟句点。
例如:
1. Optional. 输入作业的描述。
占位符文本
您可能想要提供使用特定值的命令或配置。
在这种情况下,请使用 < 和 > 来指出读者必须用自己的值替换文本的位置。例如:
docker extension install <name-of-your-extension>
表格
使用表格以直接的方式描述复杂信息。
请注意,在许多情况下,无序列表足以描述具有单个简单描述的项目列表。但是,如果您有数据最适合通过矩阵来描述,那么表格是最佳选择。
最佳实践
- 表格标题使用句子大小写(Sentence case)。
- 为保持表格的可访问性和可扫描性,表格不应有任何空单元格。如果某个单元格没有其他有意义的值,请考虑输入 N/A(表示不适用)或 None。
有关如何向内容添加表格的信息,请参阅有用的组件和格式示例。
引用文件类型
当讨论文件类型时,请使用该类型的正式名称。不要使用文件扩展名来泛指文件类型。
| 正确 | 错误 |
|---|---|
| a PNG file | a .png file |
| a Bash file | an .sh file |
引用单位
当引用计量单位时,请使用全大写的缩写形式,并在数值和单位之间留一个空格。例如:
| 正确 | 错误 |
|---|---|
| 10 GB | 10GB |
| 10 GB | 10 gb |
| 10 GB | 10 gigabytes |