跳至主要内容

为 GitHub Docs 创建图表

本指南解释了何时以及如何为 GitHub Docs 创建图表。

关于 GitHub 文档中的图表

图表使用形状、线条和标签以直观的方式解释概念。我们在 GitHub 文档中使用图表来支持文本信息。

图表并不会降低信息的复杂性,但它们提供了一种不同的方式来接收和处理信息。有些人希望以展示的方式获取信息,而不是阅读。有些人无法理解可视化图表,需要以文本形式呈现信息。

图表有许多用途。图表可以提供概念的高级概述,这些概念需要用段落或整篇文章来撰写。某人可以查看图表,然后决定是否要阅读更多内容以获取其他信息。图表还可以用于系统级决策制定,通过一次查看整个流程或微观级理解工作流中的特定步骤。图表是内容,与所有内容一样,需要仔细考虑用户的需求,以确定如何最好地使用它们。

图表具有创造性。如果你有一个图表创意可以帮助人们,无论它使用什么形状,它都可能非常适合 GitHub 文档。以下要求和建议将帮助你创建可以包含在 GitHub 文档中的图表。

图表清单

要包含在 GitHub 文档中,图表必须满足以下条件。

  • 尽可能多的用户都可以访问图表。
    • 图表有清晰的起点且易于理解。
    • 图表在出现的文章中之前或之后有完整的文本描述,没有完全以可视化形式传达的信息。
    • 图表具有适当的对比度。
    • 图表具有适当的备用文本。
    • 图表清晰明了,元素尽可能清晰易读。
  • 图表有验收标准并符合这些标准。
    • 图表有受众。
    • 图表的信息量和密度适中。
  • 图表在视觉上是合理的。
    • 图表遵循此内容模型中规定的样式。
    • 图表有足够的信息,易于理解和浏览,但不会过度装饰或不必要地复杂。

维护图表

图表创建者负责维护图表。如果图表已过时,GitHub 文档团队有权删除、更新或替换图表。

不使用图表的情况

图表不能替代文本。它们是对文章中书面信息的补充。不要添加图表来尝试简化或修复令人困惑的文章。考虑重写文章文本,如果它支持重写的文本,则可能添加图表。

使用图表的情况

图表可以在 GitHub 文档中使用,当它们对人们有帮助,而不仅仅是视觉装饰时。要确定图表是否有用,它需要包含以下内容的验收标准

  • 图表的目标受众是谁?
  • 图表的作用域是什么?
  • 图表如何补充随附的文本?
  • 你将如何评估图表的效果?

图表必须始终附带完全传达相同信息的文本。

图表验收标准

要为图表创建验收标准,请回答以下问题。

图表的目标受众是谁?

图表与文章一样,可以有广泛或特定的受众。例如,图表受众可能是考虑为其组织购买 GitHub 高级安全性的用户,或者正在学习 GitHub 教育申请流程的学生。

图表的作用域是什么?

图表中的信息越多,创建和理解起来就越困难。所有图表都需要一个既定的范围来指导其创建和评估其有效性。例如,解释 GitHub 是什么的图表具有非常大的范围。如果它详细介绍每个 GitHub 产品和功能,可能会令人困惑,因此我们希望此范围的图表提供广泛的概述。相比之下,帮助某人评估 GitHub 托管的 runner 还是自托管的 runner 更适合其用途的图表可能会包含更具体和细微的信息,因为它具有更窄的范围。

图表如何补充随附的文本?

图表可以根据其附近的文本提供不同的目的。在系统文本描述之后描绘复杂系统的图表可以提供系统的可视化解释,这将帮助一些人理解整个概念。在说明某人即将执行的任务的程序步骤之前的图表可以帮助一些人做好成功完成任务的准备。图表需要一个它与文本一起完成的目的,并且图表永远不能成为文章中传达信息的唯一方式。

你将如何评估图表的效果?

考虑到受众和范围,你应该能够确定图表需要解释什么才能有效。在将图表包含在 GitHub 文档中之前,请让其他人查看并确定它是否向指定受众解释了预期信息,并具有与范围相适应的详细信息。

选择使用何种类型的图表

不同的人会发现不同的图表有价值,并且创建好的图表既有科学性,也有艺术性。以下一般准则可以帮助你选择使用何种类型的图表,但你也可以拥有一个独特的图表,它更适合你的具体验收标准。

解释时间的图表

如果你要创建一个图表来解释某事何时或如何发生,请考虑以下这些图表类型。

  • 流程图:流程图对于显示流程中的步骤很有用。在此示例中,矩形表示流程中的步骤,菱形表示图表分叉成两个可能端点的决策点。

    An example flowchart that uses rectangles to represent steps in a process and a diamond to represent a decision point where the chart branches into two possible endpoints.

  • 甘特图:甘特图对于显示任务需要多长时间以及它们何时重叠很有用。在此示例中,水平轴标记为“时间”,蓝色矩形表示三个离散任务。任务 1 和任务 2 重叠,这意味着至少部分任务同时发生。任务 3 与其他任务不重叠,这意味着它在前两个任务完成后发生。

    An example Gantt chart that has three tasks arranged on a horizontal axis labeled "Time".

  • 旅程图:旅程图对于显示某事随时间变化的状态很有用。在此示例中,水平轴标记为“时间”,垂直轴标记为“观察或测量到的某事”。蓝色圆点标记特定时间点的测量值,并用线连接起来以说明随时间的趋势。

    An example journey map that has a line on two axes tracking events over time that we want to observe or measure something about.

解释排列的图表

如果你要创建一个图表来解释事物是什么或在哪里,请考虑以下这些图表类型。

  • 框图:框图对于通过将项目放在其他项目中来显示事物的组织方式很有用。此示例显示了内容如何在 GitHub 文档中组织,其中最大的矩形标记为“类别”,该矩形内的一个矩形标记为“映射主题”,该矩形内的一个矩形标记为“文章”。

    A block diagram of the GitHub Docs content model with overlapping squares showing articles within map topics within categories.

  • 概念图:概念图对于显示事物之间的关系很有用。带有或不带有标签的不同线条显示事物如何连接或相互影响。在此示例中,四个蓝色矩形表示概念,它们之间的线条显示它们之间的不同关系。

    An example concept map that shows relationships between four blue rectangles labeled A, B, C, and D.

  • 层次结构:层次结构对于显示类别和子类别之间的关系很有用。在此示例中,三个级别的层次结构垂直组织。

    An example hierarchy that shows two levels of subcategories beneath a main category.

解释上下文的图表

如果你要创建一个图表来解释某事为何如此,请考虑以下这些图表类型。

  • 连续统一体图表:连续统一体图表对于显示事物在线性频谱上的位置很有用。在此示例中,蓝色矩形显示感兴趣的项目在连续统一体上更接近选项 2 而不是选项 1。

    An example continuum with a horizontal axis representing the continuum between two options and the position of an item on the continuum.

  • 象限图:象限图可用于解释两个轴之间的关系以及事物在两个轴上的位置。在此示例中,水平轴左侧标记为“纯粹装饰性”,右侧标记为“满足特定验收标准”。垂直轴顶部标记为“补充书面文本”,底部标记为“信息呈现的唯一方式”。标记为“GitHub 文档中的图表”的蓝色正方形位于“补充书面文本”和“满足特定验收标准”重叠形成的右上角象限中,这意味着它具有这两个属性。

    An example quadrant diagram with four quadrants created by two axes and a blue rectangle in the upper right quadrant.

  • 韦恩图:韦恩图可用于显示共享特征或思想重叠。圆圈表示概念或事物,圆圈重叠的区域表示事物之间的共享特征。在此示例中,标记为“章鱼”的圆圈和标记为“猫”的圆圈之间的重叠部分标记为“Octocat”,它是章鱼和猫的组合。

    An example Venn diagram that shows two circles overlapping. One circle is labelled "Octopus" and the other is labelled "Cat". The overlapping section of the circles is labelled "Octocat".

样式指南

遵循这些规则来创建符合 GitHub 文档样式的图表。

形状

形状表示图表中的对象或概念。

如果相关且清晰,你可以使用 GitHub UI 中的元素(例如八爪鱼图标、菜单或按钮)来创建图表。

对于自定义图表形状,请使用这些形状表示其关联的含义。

  • 矩形:事物、对象、想法。
  • 矩形堆栈:类似事物的倍数。
  • 菱形:在遵循图表流程时某人做出的决策。
  • 圆形、星形或其他形状:需要与矩形表示的任何事物不同的独特事物。

形状的排列可以传达含义。

  • 形状在另一个形状内:这是其中的一部分。
  • 指向另一个形状的箭头形状:这导致了这一点。
  • 缩进在形状下方的形状:这是那种类型。
  • 带有到另一个形状的线的形状:这与那相关。线的粗细可以传达进一步的含义,粗线表示强连接,虚线表示弱连接。
  • 与另一个形状重叠的形状:这与那相同。

线条

线条表示图表中形状之间的关系。

使用不同类型的线条来传达关系的附加含义。

  • 非定向线:关联 两个蓝色矩形由非定向线连接。
  • 以箭头结尾的单向线:显示序列或指向对象。 两个蓝色矩形由一条线连接,该线在右侧末端有一个箭头。
  • 两侧都有箭头的双向线:表示互惠。 两个蓝色矩形由一条线连接,该线两端都有箭头。
  • 括号:建立层次结构。通常,垂直组织括号,以便在网页上更易于导航。缩进每个层次结构级别。 两个蓝色矩形由括号连接的示例。一个有三个矩形垂直排列在一个括号中,两个矩形缩进并通过线连接到顶部的矩形。另一个有两个矩形水平排列,通过线连接到上面的矩形。

标签

标签是视觉和语言标记。标签应少于 25 个字符。要增加标签的对比度,请将文本放入矩形中。在创建图表结束时标记事物通常更容易。

图例

图例通过解释图表中不同元素的内容或明确阐明关系来帮助理解。并非每个图表都需要图例。

图例不能引入图表中原本没有的新信息。图例不能修复过于复杂的图表。图例不应定义标记不当的对象或关系。

图例应用于解释形状、颜色或其他视觉元素。图例还可以包括引用或对比例和操作的解释。图例可以包括一些说明,例如从流程图中的何处开始,但大多数说明应在介绍图表的文本中。

颜色

如果图表需要颜色,请使用 Primer 设计系统 中定义的颜色。为了使更多人能够访问图表,颜色不能成为传达信息的唯一方式。例如,如果你使用颜色来表示关系,则还必须使用线条或其他视觉元素来传达相同的信息。

GitHub 文档中图表的首选颜色是

颜色十六进制代码
黑色#24292f
蓝色#0969DA
灰色#57606a
绿色#1a7f37
紫色#8250df
红色#cf222e

技术规范

  • PNG 文件格式
  • 仅限静态图像(无 GIF)
  • 文件大小为 250 KB 或更小
  • 描述性文件名,例如 merge-conflict-diagram.png,而不是 diagram-02.png

如果你需要创建在低分辨率下难以查看的图表,请在相关存储库或其他适当位置中包含指向图表较大版本的链接。请参阅“关于 Actions Runner Controller”以获取示例。

创建图表工具

建议使用 Figma 工具创建图表,以便访问 Primer 颜色和其他资源。但是,如果您愿意,可以使用其他程序。遵循上述样式指南中的形状约定,并使用 Primer 设计系统 中定义的颜色。

辅助功能

图表必须具有适当的对比度和替代文本。

如果您使用 Primer 设计系统中定义的颜色,则图表应具有适当的对比度。若要检查其他背景颜色的对比度,请使用 颜色对比度分析器

为图表编写替代文本,描述图表的显示方式以及将其包含在文章中的原因。不要尝试在替代文本中解释图表传达的所有内容,因为它可能会变得太长而无法使用。有关编写替代文本的更多信息,请参阅“样式指南”。

图表中的所有信息还必须在图表随附的文本中传达。

版本控制

某些图表适用于所有 GitHub 计划(GitHub Free、GitHub Pro、GitHub Team、GitHub Enterprise Cloud 和 GitHub Enterprise Server)。在这种情况下,不需要版本控制。

当图表仅与某些计划或 GitHub Enterprise Server 版本相关时,必须使用 Liquid 条件语句对图表进行版本控制。您可能需要在最初创建内容时添加此版本控制,或者您可能需要在为功能更新或 GitHub Enterprise Server 版本更新内容时添加此版本控制。

如果图表仅与某些版本相关并且很快就会过时,请考虑是否有一种更容易维护的选项来传达必要的信息。

源代码管理

图表存储在 docs 存储库中 assets/images/help/ 目录中的相关目录中。如果您要创建新图表,请将其添加到适当的文件夹。如果您要更新现有图表,请用更新的版本替换现有图表。

当您创建新图表时,请将其添加到 Docs Figma 团队中的图表项目,或向 Docs 团队成员提供 Figma 文件的副本。如果您在其他程序中创建图表,如果它满足本指南中的要求和建议,则可以将其包含在 GitHub 文档中,但如果它过时,则更有可能被删除而不是更新。

示例

来自“GitHub Codespaces 概述”的此图表有效地使用其他矩形内的矩形来直观地解释哪些代码空间部分包含在云中,并且使用箭头来显示云中托管的代码空间与本地编辑器之间的关系。

Diagram showing the relationship between a code editor and a codespace running on an Azure virtual machine.