信息架构、内容架构与界面系统
为什么用户找不到你的内容，以及如何构建知识图谱而不是仅仅设计网页。
目录
技术文档网站上大多数的可用性失败并不是 UI 错误。它们是结构性的失败。
用户带着特定的问题到来，搜索一个术语，登录到一个页面，然后立刻失去了方向感。他们无法分辨自己正在阅读的文档是高层次的概述、深入的教程，还是 API 参考。他们无法预测相关信息存在于何处。网站看起来很漂亮，但知识在结构上是不连贯的。
当一个团队在设计信息架构 (IA) 和内容架构之前就设计界面时，就会发生这种情况。
将知识凝聚在一起的系统
为了构建一个真正能够教导他人的出版物，你必须将知识的结构与知识的呈现分离开来。
- 信息架构（IA）： 内容如何被分类、标记和映射，以便用户能够找到它。它是空间的心智模型。
- 内容架构： 内容在系统中（模式、字段、关系）如何被建模，以便可以对其进行可预测的管理和检索。
- 界面系统： 将结构化内容呈现给用户的布局、排版和交互式组件。
当这三个层次被混淆时，出版物就会退化为无法导航的粘液。
核心区别：分类法 vs. 导航
技术出版中最常见的失败模式是将分类法与导航混淆。
分类法 是你所有知识在后台的分类。它是详尽的。它定义了概念如何相互关联（例如，“React”是“前端框架”的子主题）。
导航 是用户在网站上移动的面向用户的界面。它是经过精心策划的。它根据用户实际需要做的事情，暴露了穿过分类法的特定路径。
如果你让你的导航成为分类法的 1:1 精确复制品，你就迫使用户仅仅为了点击一个链接就必须理解你的整个组织模型。
graph LR
subgraph 弱结构：导航 = 分类法
N1[菜单: 前端] --> N2[菜单: 框架]
N2 --> N3[菜单: React]
N3 --> N4[菜单: Hooks]
end
subgraph 强结构：解耦
T1[分类法数据库] -->|查询| H1(主题中心: React)
T1 -->|查询| S1(搜索索引)
Nav[全局导航] -->|精选链接| H1
Nav -->|精选链接| G1(指南)
end主导模型：内容图谱
现代技术出版物不是文件夹的层级结构。它是一个关系的图谱。
在 Interface Atlas 中，我们通过四个截然不同的原语来建模知识。通过将它们分离，我们允许它们链接在一起形成一个语义网络。
- 指南： 长篇的教学层。它们带有论点，并解释如何和为什么。
- 主题中心： 综合层。它们不仅仅是链接列表；它们精选指南并为广泛的主题提供景观。
- 术语表： 定义层。对特定术语简短、精确的解释，允许指南链接出去，而不是增加它们自己的字数。
- 博客： 按时间排序的层。更新、新闻和不属于持久规范的及时想法。
一个实际的例子
想象一个试图理解“水合（Hydration）”的读者。
在弱（扁平）结构中： 他们找到一个叫做“React 性能”的 5000 字长页面。页面的二分之一是 API 参考，四分之一是教程，而水合的定义被埋在第 14 段。如果他们搜索“水合”，他们只是被扔在这个巨大页面的顶部。
在强（图谱）结构中：
- 他们搜索“Hydration”并直接登陆到
术语表：Hydration条目。 - 术语表条目给他们一个 100 字的定义，并且在“相关指南”下，链接到
指南：作为架构的 Web 性能。 - 他们阅读了指南。该指南链接到
主题中心：性能以供进一步阅读。 - 他们探索主题中心以发现相关的概念，如可恢复性（Resumability）。
内容模型强制执行了学习路径。
要避免的失败模式
- 组织结构图的 IA： 根据编写文档的内部团队来构建文档，而不是根据用户试图完成的任务。
- 扁平内容，没有模型： 将所有内容转储到一个具有单一 WYSIWYG 正文字段的通用“页面”CMS 类型中。这会阻止您以编程方式将指南与术语表术语相关联。
- 界面优先思考： 在决定实际需要导航哪些内容类型之前，先设计一个漂亮的侧边栏。
将此应用于 Interface Atlas
我们通过仓库结构来强制执行此架构：
- 显式模式（Schemas）： 我们的内容集合规定了指南必须包含
topicKeys和glossaryKeys。 - 编辑中心： 我们不会将主题页面自动生成为简单的标签列表。主题是作者编写的文件，用于综合它们下面的指南。
- 无处不在的链接： 没有链接到术语表或主题中心的指南是一个孤立的节点。只有当作者显式连接边缘时，网络才起作用。
相关指南和术语
继续你的探索：
- MDX、内容集合与作为架构的内容 — 我们如何在 Astro 中实现这种结构。
- 前端架构到底是什么 — IA 如何适应前端系统。
- 优秀技术指南的剖析 — 内部指南结构如何反映更大的内容架构。