Information architecture 信息架构
页面该长成什么形状。这件事要在挑颜色、定间距之前决定。
这一节的其他几页回答的是零件的问题。本页回答的是排在它们前面的那个问题：这块屏幕要装的东西这么多，用户到底是来做什么的，什么样的排布能让他做成。
适用场景：要做一块同时装着多个对象、多种状态以及它们之间关系的屏幕，比如控制台、仪表盘、后台、工作台、监控页。落地页和单一转化的表单不算，那类页面的成败取决于说服力，而不是用户能不能在密集信息里判断准确。
数据齐了不等于页面设计好了。接口返回的字段一个不落，筛选、状态标签、批量操作也都在，用户照样不知道该先看哪儿。缺的不是信息，是顺序。
动组件之前先回答三个问题
- 用户打开页面，最该先看到的是哪一件事？ 这是页面的主信息。
- 为了看懂它，还必须同时看到什么？ 关联资源、关联模型、上下文。
- 看完之后他要做什么？ 作判断、执行操作，或者接着往下想。
这三个问题要在打开组件清单之前答完。三个答案清楚的页面很少选错形状；跳过它们的页面，最后都是照着接口返回的结构长出来的。
一个页面只有一个主模型。 辅助模型可以帮着理解和操作主模型，但不能来抢首屏。
形状由任务决定，不由返回值决定
大部分形状不对的页面，都出自这两个顺手的选择：
- 接口返回了数组，于是做成表格。
- 路由里带了一个 ID，于是做成详情页。
这两件事都不构成理由。同一个对象在不同任务下是不同的形状：查找时 issue 是一个集合，处理时是一条状态流，协作时是一条讨论线索，审计时是一串事件序列。记录里有日期，只能说明数据里有日期，不能说明这一页就该是日历。
怎么选表达骨架
选那个能让用户最少转几道弯就回答出主问题的排布。
| 用户眼前要回答的问题 | 必须放在一起的信息 | 表达骨架 |
|---|---|---|
| 这些之间差在哪儿？ | 参与比较的字段，列的位置固定 | 二维对照表 |
| 是哪一个，我要点进去 | 名称、标识、状态 | 列表 / 资源目录 |
| 是哪一个，看图就认得出来 | 图放在最显眼处，名称和字段围着它排 | 卡片网格 |
| 这个对象是什么，现在什么状态？ | 身份、状态、主操作，然后才是属性 | 分区详情 |
| 它属于哪里？ | 路径、父级、同级 | 层级树 |
| 谁依赖它，改了会影响到谁？ | 上下游、影响范围 | 关系列表 |
| 我走到第几步了，接下来是什么？ | 阶段、当前输入、后面的步骤 | 分步向导 |
| 每一条在哪个阶段，推动它就是干活 | 列代表阶段，卡片带身份和阻塞点 | 看板 |
| 为什么卡住了？ | 阶段概要，再到单步结果，再到原始日志 | 追踪下钻 |
| 现在健康吗，影响面有多大？ | 对象名、状态，以及把状态改掉的那个事件 | 状态墙 |
| 发生了什么，先后顺序，谁干的？ | 时间、操作者、事件类型 | 事件时间线 |
| 谁提了什么，别人怎么回的？ | 作者、发言、回复结构 | 讨论线程 |
| 改之前和改之后差在哪儿？ | 两个版本并排 | 并排比较 |
| 趋势怎么样，异常在哪儿？ | 指标、它的比较基准、进明细的入口 | 仪表盘 |
| 这段时间被谁占着，会不会撞车？ | 开始、结束、时长放在同一根轴上 | 日历排期 |
| 我接下来该处理哪一条？ | 一侧是队列，另一侧是这一条的详情 | 主从工作台 |
| 哪些规则生效，会影响到什么？ | 配置项、生效范围、造成的后果 | 配置表单 |
| 这段正文说了什么？ | 正文按顺序读，旁边给一份大纲 | 连续文档 |
| 它在哪儿？ | 位置、边界、分布 | 地图与画布 |
最容易选反的几对
- 时间线还是分步向导。 时间线讲已经发生过什么，按先后排；分步向导讲你现在在哪一步、下一步是什么。两者长得像，指向的时间方向却相反。
- 看板还是筛选。 只有当拖动卡片本身就是那个操作时，看板才成立。列如果只是几组存下来的筛选条件，那就是做了个要拖一下才能用的筛选器。
- 日历还是时间线。 日历回答的是占用和冲突，时间线回答的是先后。记录里的日期不负责在这两者之间做选择，问题才负责。
- 卡片网格还是表格。 图要么是识别的锚点，要么不是。如果选择是靠比数字做出来的，把预览缩成第一列的小图，反而压掉了真正决定结果的字段。
- 关系图还是关系列表。 只有当路径本身或影响怎么扩散就是判断依据时，才值得画图。否则一份分好组的上下游列表读起来更快。
- 正文还是字段格子。 需要顺着读下来的文字就让它保持文字。把每一段都切成卡片或者键值对，正好毁掉了它原本好读的地方。
不要因为做得出来就把三种视图都做一遍。每多一种视图，就多一套筛选、多一份状态映射、多一组要同步维护的操作。等到第二种用法确实高频了再加，而不是为了以防万一先加上。
每一类信息该放在哪里
| 信息 | 回答的问题 | 该放在 | 不该落到 |
|---|---|---|---|
| 身份 | 这是什么？ | 标题、对象概要 | 表格最后一列，或者某个标签页后面 |
| 状态 | 现在怎么样？ | 标题区或概要区 | 只能在详情字段里翻到 |
| 属性 | 它是什么样的？ | 详情正文，按人理解的方式分组 | 照着接口字段顺序摊平 |
| 关联 | 它和谁有关系？ | 自己的区块或标签页，归属、依赖、引用分开表达 | 混进属性表里 |
| 变更 | 和之前差在哪儿？ | 差异区块、时间线 | 只显示改完之后的值 |
| 证据 | 凭什么这么判断？ | 紧挨着这个判断，可以展开 | 另开一个日志页 |
| 操作 | 现在我能做什么？ | 主操作在标题区，其余的挨着各自作用的对象 | 塞进「更多」里 |
| 反馈 | 刚才那下做成了吗？ | 紧挨着操作，保住任务上下文 | 一个和上下文断开的全局提示 |
每条信息只有一个权威位置。 别处只放摘要或入口，并且指回那个权威位置。
阅读顺序
页面身份
→ 当前状态或异常
→ 主任务和主操作
→ 判断所需的信息
→ 关联、变更、证据
→ 次要信息和低频操作- 一页只有一个视觉上的主标题。 分节标题靠语义推进，不要用字号假装层级。
- 一个任务区里最多一个主操作。 主按钮代表最可能、价值最高的下一步，不是最危险的那一步。危险操作用危险语义表达，不该长期占着最重的视觉分量。
- 警告色和危险色留给真正需要用户注意的状态。整页都是绿的，信号就已经花掉了。
- 徽标、标签、横幅共用同一份注意力预算。只强调那些会改变判断和动作的信息。
信息密度
密度不是单位面积里塞了多少控件，而是用户一眼能拿走多少可用来判断的信息。把间距收紧只提高了视觉密度，有效密度原地不动；删掉不相关的字段、把需要对比的东西摆到一起，才是真的提高。
| 档位 | 适用场景 | 换来什么 |
|---|---|---|
| 宽松 | 首次使用、低频配置、高风险确认 | 解释的空间、更大的分组间距、看得见的影响预览 |
| 标准 | 大多数列表、详情和表单 | 可扫读性和每屏信息量之间的默认平衡 |
| 紧凑 | 高频专家工作台：监控、运维、审计 | 稳定的列宽、短文案、键盘效率、可保存的视图 |
- 一个页面里最多用相邻的两档。标准页面里嵌一张紧凑的表格没问题，每个区块各发明一套标尺不行。
- 紧凑不等于「字号和点击区域一起缩小」。容器留白和行高可以收紧，正文的可读性、看得见的焦点圈和指针目标尺寸不能。
- 对专家用户来说，列管理、保存视图、批量操作和快捷键，都比一次显示更多内容更有用。
怎么维持任务上下文
骨架定下来之后，再决定辅助内容放在哪儿：
| 用户正在… | 就给他 |
|---|---|
| 在对象或证据之间反复切换 | 主从分栏：一侧队列，一侧当前这条 |
| 瞥一眼很轻、看完就走的内容 | 可展开行（r-disclosure-row）或气泡卡（r-popover） |
| 处理可以分享出去、或者需要宽度的内容 | 一条独立路由 |
| 做一次确认，或者填一个字段 | 弹窗（r-modal） |
弹窗不是一层导航。 只要需要可复制的链接、浏览历史、并排比较，或者刷新之后工作还得在，就给它一条路由。
这一层 ranui 能给你什么
ranui 在页面形状上是刻意不表态的：它提供基础件和令牌，不提供页面模板。这一层它能给的是：
r-section划出骨架的各个内容带，r-card承载真正独立的重复条目。卡片里不要再套卡片；表单字段用小标题或分隔线分组就够了。r-tabs表达同一个对象的平级视图（它的讨论、它的检查、它的差异），不要拿来放互不相干的模块，那是导航的事。r-disclosure-row做渐进展开，r-popover和r-dropdown承载临时上下文，r-modal只做上面那张表允许它做的事。r-state-dot表达状态，并且永远带上文字标签：不能只靠颜色。- 首屏加载时用
r-skeleton，长到会让人犯嘀咕的操作配r-progress，结果用r-message告诉他。
ranui 没有表格、树、日历、看板和时间线。自己实现时，用令牌和 设计规范去搭，不要另起一套视觉体系：间距取自标尺，字体按角色定，颜色来自语义令牌，每一个可达状态都要设计到。
典型做坏的方式
- 接口返回的每个字段都变成一行详情，身份、状态、关联和证据以同样的分量一起涌出来。
- 用卡片、颜色和装饰性间距堆出层次感，却没说清该先看哪儿、要据此作出什么判断。
- 几个操作同时用主按钮样式，或者把一个低频操作摆进标题区。
- 状态、属性、关联和变更混进同一张表，结果哪儿都比不出来。
- 用户只是想查个名字和状态，却给了他一张关系图。
- 用弹窗装一条长流程、一次比较，或者别人一定会想发链接出去的内容。
- 同一句话在标题、概要、标签页和表格里各出现一遍，哪一次都没带来新信息。
页面上线前的检查清单
- 主信息、关联信息、用户的下一步动作，三样都写下来了。
- 表达骨架是从问题选出来的，不是从返回值的形状推出来的。
- 页面只有一个主模型，辅助视图服务于它而不是和它抢。
- 不看需求文档，五秒内能说出这一页的对象、当前状态和主操作。
- 比较发生在同一个地方，不需要跨标签页或跨页面记住某个值。
- 每条信息只有一个权威位置，别处都指回去。
- 密度与使用频次匹配，且没有出现超过相邻两档的情况。
- 长文本、大数字和窄屏都不会把信息顺序打乱。
- 对判断没有帮助的区块、字段、标签和按钮，都删掉了。