notifications-and-recovery

通知与恢复

当发生变化时——成功、失败或介于两者之间的任何情况——用户都必须知晓。出现问题时，用户也必须始终有路可走。没有恢复操作的通知，只是一句道歉。

---

模式选择

模式	使用时机	消失方式
Toast	用户操作的短暂结果（已保存、已发送、已删除）	4–6 秒后自动消失，可手动关闭
内联错误	字段级验证、表单错误	更正后消失
警示横幅	影响当前上下文的持续性问题	手动关闭或问题解决后消失
模态框 / 对话框	继续操作前需要用户做出决定的阻断性错误	需要用户操作
空状态	暂无数据——引导用户执行第一个操作	首个条目出现后替换
骨架屏 / 加载状态	异步内容尚未就绪	内容就绪后替换
就地确认	内联编辑已保存、行已更新、条目已切换	2–3 秒后自动消失

---

Toast 通知

Toast 用于确认后台操作已完成。它们会出现，但不会打断用户的操作流程。

**位置：**底部居中或右下角。绝不要放在顶部居中——这会与页面内容和导航争夺注意力。

**持续时间：**提示信息显示 4–6 秒。错误应持续显示，直到用户将其关闭——用户需要时间阅读并采取行动。

组成：

[Icon] Message text                    [Action] [×]

• 图标：按颜色区分（绿色 ✓ 成功、红色 ✗ 错误、橙色 ⚠ 警告、蓝色 ℹ 信息）
• 消息：用浅显的语言写成一句话
• 操作（可选）：“撤销”“重试”“查看”——最多提供一个操作
• 关闭按钮：错误通知始终显示；成功通知可选

✓ "Changes saved."
✓ "Message sent.  [Undo]"
✗ "Could not save. Check your connection.  [Retry]"  ← persists until dismissed

**切勿：**同时显示多个 Toast。将它们排队，一次只显示一个。

---

内联错误

内联错误显示在导致错误的元素旁边。它是上下文关联最紧密、最便于采取行动的错误反馈形式。

表单验证：

• 在字段失焦时验证，而不是在每次按键时验证——按键时验证会产生过多干扰
• 提交时验证完整表单
• 在字段正下方以红色显示错误消息，并附带图标
• 字段边框变为 --color-error
• 通过 aria-describedby 关联错误消息，供屏幕阅读器读取

<label for="email">Email</label>
<input id="email" aria-describedby="email-error" aria-invalid="true">
<p id="email-error" role="alert">Enter a valid email address.</p>

就地编辑：

• 内联编辑字段（表格单元格、卡片标题）时，在字段旁边显示保存/取消控件
• 保存后：显示简短的成功指示（“✓ 已保存”），2 秒后淡出——不要跳转离开
• 出错时：在字段下方显示内联错误消息，并提供重试选项
• 取消时：立即恢复原值

---

警示横幅

横幅会持续显示，直到问题解决或用户将其关闭。

适用场景：

• 服务降级（“部分功能暂时不可用”）
• 需要用户采取行动的账户问题（“您的订阅将在 3 天后到期。[续订]”）
• 持续的同步错误（“更改未保存。[重试]”）
• 与当前页面相关的重要公告

**位置：**受影响区域的顶部；除非问题确实影响全局，否则不要放在整个页面的顶部。

组成：

[Icon] [Message — describes the issue and its scope] [Action] [×]

• 每个区域一次只显示一个横幅——同时显示多个横幅会造成警报疲劳
• 除非问题具有阻断性，否则应允许用户关闭
• 颜色遵循状态颜色惯例：红色（错误）、橙色（警告）、蓝色（信息）、绿色（成功/已解决）

---

恢复模式

每种错误状态都必须提供继续操作的途径。设计错误消息时，也要同时设计恢复操作。

重试

适用于暂时性故障（网络、超时、速率限制）：

"Could not load results."
[Try again]

• 重试按钮会再次触发相同操作
• 重试失败 3 次后，升级处理方式：“仍然遇到问题？[联系支持团队]”
• 重试期间显示加载动画——不要让用户多次点击

撤销

对于具有破坏性或不可逆的操作（删除、归档、发送）：

"Message sent.  [Undo]  ×"

• 撤销窗口：5–10 秒。Toast 在此期间持续显示。
• 窗口关闭后，操作即不可撤销
• 对于影响较小的操作，撤销优于确认对话框——速度更快，干扰更少

自动保存和草稿恢复

对于长篇输入内容（表单、文档、编辑器）：

• 每隔 30–60 秒静默自动保存
• 保存失败时：“自动保存失败——您的更改已在本地保存。[重试保存]”
• 崩溃或关闭后返回时：“您有 [time] 时未保存的更改。[恢复] [放弃]”

优雅降级

当某项功能发生故障，但产品其余部分仍能正常使用时：

• 仅为发生故障的部分显示错误状态——不要清空整个页面
• 提供备用选项：“无法加载推荐内容。[浏览所有产品 →]”
• 静默记录错误；只向用户显示他们需要了解的信息

---

加载和骨架屏状态

加载不是错误，但也是一种需要设计的状态。

• 内容丰富的页面使用 骨架屏——在数据加载时展示布局轮廓
• 针对特定异步操作使用 旋转指示器（按钮加载、行内刷新）
• 对于时长已知的长时间操作（文件上传、多步处理），使用 进度条
• 加载时绝不要显示空白屏幕——始终显示一些内容

与旋转指示器相比，骨架屏能缩短用户感知到的等待时间。骨架屏的形状应与实际内容布局相匹配。

---

通知中心

Toast 和横幅都是临时的；通知中心则是用户查看并控制通知的持久入口。做好这项设计有两个关键。

入口易找，控制易用。 用户几乎不需要费力查找就能进入通知偏好设置（铃铛图标 → 通知中心 → 设置）。控制模式应保持简洁——最多 1 到 3 个类别，每个类别都设有简单的级别：

• Off (0) — 不接收此类别的通知
• Minimal — 只接收重要通知
• All / granular — 接收所有通知

不要为每种事件都设置一系列开关。用户的实际需求主要有两种：全部静音，或保留一两个类别。围绕这两种需求直接设计——提供醒目的“全部静音”/“全部标为已读”选项，以及 1–3 个类别开关。

尽量减少阅读。 用户会扫视通知中心，而不是逐条阅读。按类别分组，每条通知都以易于识别的图标和实体/操作开头（而不是一段文字），清楚显示未读状态，并允许用户一键清空整个列表。阅读需要时间（参见 [[ui-density]]）——如果通知中心要求用户仔细阅读，就失去了其存在的意义。

通知无障碍设计

• 错误使用 role="alert"——屏幕阅读器会立即播报
• 状态更新使用 role="status"——屏幕阅读器会礼貌地在当前语音播报后播报
• Toast 必须可通过键盘访问——关闭按钮不要使用 pointer-events: none
• 自动消失的 Toast 必须显示足够长的时间（使用 prefers-reduced-motion 的用户可能需要更多阅读时间）

<div role="alert">Could not save. Check your connection.</div>


<div role="status" aria-live="polite">Changes saved.</div>

---

审查清单

• 每个错误是否都有恢复操作（重试、撤销、联系支持）？
• 成功提示的 Toast 是否会自动消失，而错误提示是否会持续显示？
• 是否始终最多只显示一个 Toast？
• 行内错误是否放在对应字段旁，而不是表单顶部？
• 表单错误是否通过 aria-describedby 与对应输入项关联？
• 提醒横幅是否显示在受影响部分的顶部，而不是总是占满整个页面？
• 长篇输入内容是否支持自动保存或草稿恢复？
• 加载状态是否对内容使用骨架屏、对特定操作使用旋转指示器？
• 错误是否通过 role="alert" 播报，状态更新是否通过 role="status" 播报？