UI结构标准 是做什么的？
界面难用，往往是因为结构问题，而非规模。一个拥有300项设置的应用可以轻松导航，而一个只有30项设置的应用却可能让人如坠迷宫。原因总是那几个：同一个控件出现在多个地方、菜单结构与代码或团队组织方式一一对应、操作与偏好设置混在一起、无标签的图标、不可见的范围，以及从未清理的冗余项。
解决方案是遵循主流平台已经采用的做法，并在每个应用中以相同的方式实现，让用户能够使用他们已经掌握的知识：
- 一个熟悉的布局。 左侧是可搜索的分类列表，右侧是打开的页面，行内标签在左，控件在右。
- 一套统一的分类名称。 账户、通知、隐私与安全、辅助功能、外观、语言与区域、数据与存储，然后是产品自身的主题。通过七个问题，任何设置都只能归入一个分类。
- 更少的控件。 最佳设置是那个永远不必发布的设置，因为更好的默认值已经使其变得多余。
- 每个保留的控件只有一个归宿。 每一项设置、目标和命令都是注册表中的一条记录，每条记录只有一个归宿，界面根据这些记录绘制。当没有人手动放置控件时，结构就不会漂移。
选择任务
在以下表格中找到请求，并只阅读该部分及其所引用的文件。
| 请求 | 章节 | 另请参阅 |
|---|---|---|
| "添加一个设置/菜单项/按钮" | 添加一个控件 | 通常不需要其他内容 |
| "这个UI一团糟", "审查这个", "用户找不到东西" | 审计现有界面 | references/audit.md, references/rules.md |
| "构建/设计/重新设计设置界面、侧边栏或工具栏"，或需要转化为一个界面的功能列表 | 构建新的界面 | references/categories.md, references/visual-design.md, references/record-schema.md |
| "组织我们的设置", "我们应该有哪些分类" | 标准分类 | references/categories.md |
| "为我们的项目设置这个" | 采用注册表 | references/record-schema.md |
无论任务是什么，都要尊重你所在的项目。如果代码库已经有一个设置注册表、一个组件库或它自己的标记规则，请扩展这些内容；不要引入一个并行的系统。该标准描述的是结构，而非技术。
evals/ 文件夹包含此技能的测试用例。它不是参考材料；在执行任务时不要阅读它。
添加一个控件
依次询问以下五个问题，并在第一个答案为“是”时停止。告诉用户这个决定及其原因；不要带他们走过那些不再适用的问题。
- 更好的默认值是否会让它变得多余？ 如果可以通过更改默认值、检测情况或简单地移除人们不喜欢的行为（一个没人需要的确认、一个自动保存的东西的提示）来满足所有人的需求，那就这样做。没有设置项。
- 系统或管理员是否已经决定了它？ 主题、文本大小、通知权限等属于下一层。遵循它。如果产品有充分的理由提供自己的选择，那么该选择应包括“使用系统设置”，并且这是默认值；它绝不是一个简单的开/关开关。
- 它是一次性操作，而非持久的选择吗？ 那么它是一个操作：一个按钮，与开关分开存放，放在上下文中或放在其页面底部一个带标签的组中。
- 它是否每周或更频繁地被更改？ 那么控件存在于上下文中，在它所更改的功能旁边，并带有一个指向其主页面的链接。主页面仍然列出它。
- 是否只有不到大约二十分之一的人会更改它？ 那么它的层级是高级。一个页面如果有三个或更多高级项，则在一个“高级”折叠区中显示它们；如果少于三个，则将它们作为普通行放在最后。
否则，它将是其主题页面上的一个标准行。
如果问题1或2的答案是肯定的，请直说并提出更改建议，而不是设置项。每个设置都会产生测试、支持和他人查找东西的成本，所以用户应该先听到更便宜的选择。他们可能仍然需要设置项；这是他们的决定。用几行代码将其作为后备方案提供。
选择归宿。 使用标准分类下的七个问题，映射到已存在的页面上。如果控件不匹配任何一项，那就证明缺少一个主题：说出来并提议一个。不要创建名为“常规”、“其他”、“杂项”或“高级”的页面。当现有界面已经有这样一个页面时，将新控件放在命名最佳的具体页面上，并在一行中提及这个杂项页面，作为以后值得修复的东西。一个添加控件的请求并不等同于审计请求。
提出问题的控件。 带有“不再询问”的确认是一个用于设置（问题4）的上下文控件：复选框和设置行是同一个记录，因此选择可以在以后找到并撤销。永远不要提供“不再询问”而没有某处可以撤销它的行。
向用户展示多少内容。 如果项目有注册表，请编写完整的记录（下面的字段），并检查它所落到的页面是否仍在限制范围内。如果没有，或者用户只要求建议，请用通俗的语言回答：添加什么、在哪里、叫什么、默认值是什么以及为什么、以及它是应用于此设备还是整个账户。诸如 id、tier、owner 和 reviewed 之类的字段是簿记字段；在对话式回答中省略它们。当你不知道记录所需的内容时（例如设置是否在设备之间同步、存在哪些页面），请在一句话中说明你的假设，然后继续。
审计现有界面
目标是生成一个具体的、可修复的发现列表，并关联到规则编号，以及一个提议的结构。首先阅读 references/rules.md，以便发现可以引用规则，并使用 references/audit.md 中的报告模板。
一次审计可以涵盖设置、导航、工具栏，或全部三者。审计用户询问的内容以及你能看到的内容。如果界面上没有设置，请跳过模板中关于设置的部分；不要强行填充。
- 清点。 列出一个人可以更改或触发某事的所有地方：设置界面、账户菜单、上下文菜单、每个项目的对话框、导航列表、工具栏、图标条、命令行标志、配置文件。在大型代码库中，委派扫描或搜索模式（标签、开关、菜单构建器）；不要整体阅读巨大的文件。对于每个控件，记录其显示的标签、种类、所在位置以及如何访问。当一个控件根本没有标签时，说出来，通过位置描述它，并将任何关于其功能的猜测标记为猜测。
- 测量。 计算规则限制的内容：更改某事的场所数量、顶级导航条目数量、每页设置项数量、深度、每个工具栏的按钮数量、仅图标控件、没有可访问名称的控件、搜索框，以及同一类型对象显示的不同命令集数量。
- 查找症状。
- 同一个设置或命令可以在多个地方访问，或两个控件叠加或冲突
- 一个主题分散在多个页面中
- 同一个东西有多个名称；一个链接的标签与其目标标题不同；并排的近乎重复的名称
- 名为“其他”、“高级”、“常规”的页面
- 操作（导出、删除、退出登录）位于偏好设置或目标之间
- 范围只在提示文本中解释，或根本没有解释
- 标签中使用构建者的词汇
- 只有一个项目的组和超过其限制的列表
- 没有可见文字的图标；一个图标用于两种含义
- 工具栏超过五个按钮；同一类型的对象之间命令集不同
- 没有当前位置标记
- 一个界面上有多个搜索框
- 提供显示、隐藏或重新排序控件作为解决杂乱的方案
- 提议。 对于设置：适用的标准分类加上最多两个产品主题，总共最多九个，每个控件只映射到一个。对于导航：最多九个顶级条目，其余放在带标签的组下。对于工具栏：每个对象类型一个命令集，栏上五个，其余放在“更多”下。列出完全离开当前界面的内容及其去向。说明这些分组是提议，需要通过卡片分类和树形测试进行确认（5个人可以找到主要问题；目标为80%的任务成功率），因为分组的匹配方式必须符合用户的思考方式，而这无法从代码中读取。
- 排列更改顺序，以便那些无需任何人重新学习的更改排在前面：图标上的文字和当前位置标记，然后是合并重复项和统一名称，接着是一致的工具栏，最后是重新分组。移动东西放在后面，因为它会对现有用户造成成本。如果采用注册表是合理的，把它放在最后并提出，而不是强推；用户问的是界面上要更改什么。
按发现对新用户造成的伤害程度排序。肯定已经有效的功能：现有的注册表、搜索、重置或地址机制是构建修复的基础，说出来可以防止没人需要的重写。
构建新的界面
- 首先对每个项目运行五个问题。 产品愿望清单中总包含一些应该是更好的默认值、属于系统、或者是操作而非偏好设置的东西。将裁剪掉的项从注册表中删除，并在你的摘要中列出原因，以便用户可以否决你。
- 在编写任何标记之前，先编写记录，遵循
references/record-schema.md。如果存在注册表，则添加进去。 - 使用七个问题归档每条记录（下一节）。省略那些会是空的分类。当一个分类只有一两个设置时，如果人们会按名称查找它（例如通知），则可以保留；否则将其合并到相邻分类。关于某个主题的状态信息留在该主题的页面上；只有应用范围内的信息才放在“关于”下面。
- 检查限制（下文），手动或使用检查器。
- 根据记录绘制标准布局，遵循
references/visual-design.md中的排列、大小、控件和状态，以及references/patterns.md中的行为。简而言之：宽屏上分类列表在页面旁边，窄屏上在页面之前；单列宽度限制在约1100像素；标签在左，控件或当前值在右；相关行放在包含组中；开关用于开和关，单选按钮用于两到五个选项，没有保存按钮；目标至少24像素，触控目标为44到48像素；文本对比度4.5:1；不能仅靠颜色显示信息。每一行显示其范围，并且当它与默认值不同时，显示一个已更改标记和重置按钮。搜索位于顶部。每条记录都有一个稳定的地址。操作与偏好设置分开存放，破坏性操作再分开存放。 - 说明你的假设：你不得不猜测的默认值、范围和所有者由用户确认。对于未知所有者，使用
unassigned；不要编造团队名称。
标准分类
依次询问以下问题，在第一个答案为“是”时停止。顺序是打破平局的因素。
| # | 问题 | 分类 |
|---|---|---|
| 1 | 它是关于你是谁、你如何进入、或你支付什么的吗？ | 账户 |
| 2 | 它决定产品何时或如何打扰你吗？ | 通知 |
| 3 | 它控制其他人、其他应用或服务可以看到、保留或做什么吗？ | 隐私与安全 |
| 4 | 它存在是为了让有特定需求的人能够看到、听到或操作产品吗？ | 辅助功能 |
| 5 | 它只改变事物的外观吗？ | 外观 |
| 6 | 它是关于语言、时间或格式的吗？ | 语言与区域 |
| 7 | 它是关于数据存储在哪里、存储多少、或通过哪个网络的吗？ | 数据与存储 |
| 否则：它改变哪个功能？ | 最多两个产品主题中的一个（消息、编辑器、播放） |
“关于”（版本、帮助、法律）是底部的一个链接，不计算在内。管理员为每个人所做的设置是一个单独的界面。一个设置项少于约15个的小型应用，可以使用一个页面，并将这些名称作为组标题。
所以，通话铃声是通知，而不是通话；“减少运动”是辅助功能，而不是外观。当一个设置可以归入两个分类时，根据第一个“是”来归档，并将另一个分类的关键词放入其搜索词中。references/categories.md 涵盖了大型产品、套件、命名和推理。
这些名称是操作系统已经使用的名称。从它们开始，只有当产品自身的用户（在卡片分类中）以不同方式分组事物时才更改它们。
记录
| 字段 | 它回答的问题 | 允许的值 |
|---|---|---|
id | 它的永久名称是什么？ | 一个点号路径，例如 chat.notifications.sound。永不重用或重命名。 |
kind | 它是什么类型的？ | preference, action, status, list, destination, command |
subject | 它是关于哪个名词的？ | 恰好一个主题。这是它的归宿。 |
scope | 它改变谁或什么？ | item, device, account, organization |
tier | 多少人需要它？ | everyday, standard, advanced |
label, summary | 它叫什么，它做什么？ | 一个简单的标签；一个关于结果的句子 |
search | 人们会输入什么来找到它？ | 同义词、旧名称、专业术语 |
value | 它持有哪种类型的值？ | 一个类型，带有选项或范围 |
default, default_reason | 如果没人动它会发生什么？ | 大多数人会选择的值，以及原因 |
risk | 更改它会破坏什么？ | safe, care（可恢复）, destructive（永久丢失） |
owner, reviewed | 当它应该消失时谁决定？ | 所有者和它上次被证明合理的日期 |
目标和命令使用较少的字段集。完整模式在 references/record-schema.md 中，assets/registry.example.json 是一个工作示例。
限制
| 限制 | 值 | 来源 |
|---|
…
[为翻译截断]