格式指南

标题和子标题

读者会略微多关注标题、项目符号列表和链接,因此确保这些项目的前两到三个词尽可能地“前置加载”信息非常重要。

最佳实践

  • 标题和子标题应让读者知道他们将在页面上找到什么内容。
  • 它们应简洁准确地描述内容主题。
  • 标题应简短(不超过八个词)、切中要点,并使用平实、主动的语言。
  • 避免使用双关语、悬念和文化典故。
  • 省略开头的冠词(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