EasyFlow/docs/design/interaction-motion-guidelines.md

EasyFlow 交互与动效规范 v1

1. 文档目标

本规范用于统一 EasyFlow 的操作反馈、异步流程、状态恢复、键盘可达性与动效系统，确保界面既现代流畅，又稳定可信。

2. 交互哲学

EasyFlow 的交互原则是：

• 顺手
• 可预期
• 低打扰
• 可恢复
• 有活力

界面应始终让用户知道：

• 我现在在哪
• 当前发生了什么
• 下一步可以做什么
• 出错了如何恢复

补充：

• Apple HIG 所强调的直接、顺滑、层级清晰的控制感，应成为 EasyFlow 的默认交互目标。
• toB 系统不应因为强调稳定，就牺牲流动感、反馈质量和控件手感。

3. 交互优先级规则

3.1 主操作稳定

• 同类页面主操作位置尽量固定
• 主操作数量尽量少，避免多个并列主按钮

3.2 次级操作退后

• 搜索、筛选、帮助、导出等默认低于主任务
• 危险操作不与主操作并列抢权重

3.3 反馈先于装饰

• 任何视觉变化都应优先承担反馈职责
• 不为“好看”增加没有业务意义的动画
• 但也不应因为“稳”而做成死板、僵硬、毫无气息的后台交互

4. 表单交互规范

4.1 基本要求

• 字段标签清晰
• 帮助信息紧邻字段
• 错误提示就近展示
• 提交后有明确状态反馈

4.2 校验策略

• 优先在字段级提示错误
• 文案要能指导修改，而不是只提示“输入有误”
• 对高风险或高成本字段，必要时增加确认步骤

4.3 提交流程

表单提交必须覆盖：

• 提交中 loading
• 防重复点击
• 成功提示
• 失败原因
• 保留或恢复用户已填内容

5. 列表与批量操作规范

5.1 列表交互

• 排序、筛选、分页、搜索需保持稳定顺序
• 列表刷新不应导致明显跳闪
• 行 hover 反馈应轻量但可感知

5.2 批量操作

• 进入批量态后，当前选中数量要清楚
• 高风险批量操作必须确认
• 批量完成后需反馈结果摘要

6. 状态反馈规范

6.1 Loading

• 短操作可用按钮 loading 或局部 skeleton
• 中长操作应提供区域级反馈
• 不要让全页面频繁闪动式 loading 干扰操作

6.2 Success

• 成功反馈应简洁明确
• 成功后如果有下一步建议，可轻量提示

6.3 Error

• 错误要说明原因，至少说明失败发生在哪
• 可恢复错误必须给出重试路径
• 不可恢复错误也应给出返回或联系支持路径

6.4 Empty

• 解释为什么为空
• 提供推荐操作
• 保持视觉克制，不用过重插画制造噪音

7. 危险操作规范

以下场景默认视为危险操作：

• 删除
• 清空
• 停用
• 覆盖
• 批量不可逆处理

要求：

• 二次确认
• 文案明确说明影响范围
• 按钮层级清晰，不允许误触
• 完成后提供结果反馈

8. 键盘与可访问性

8.1 键盘可达性

• Tab 顺序合理
• 对话框支持 Esc 关闭
• 主操作支持 Enter 快捷确认时，要避免误触发

8.2 焦点样式

• 必须清晰可见
• 不依赖微弱颜色变化
• 不得被自定义样式覆盖消失

8.3 语义结构

• 表单、表格、弹窗、导航使用语义化结构
• 图标按钮必须有可访问名称

9. 动效总原则

EasyFlow 的动效关键词固定为：

• 细腻
• 短促
• 稳定
• 不变形

动效作用：

• 帮助理解层级变化
• 帮助理解状态切换
• 帮助降低跳变感
• 帮助界面保持现代、轻盈和有生命力

10. 动效时长与缓动

10.1 推荐时长

• 微交互：120ms - 160ms
• 常规切换：180ms - 240ms
• 弹窗 / 抽屉：220ms - 280ms

10.2 推荐缓动

• 常规：cubic-bezier(0.2, 0, 0, 1)
• 进入：cubic-bezier(0.16, 1, 0.3, 1)
• 离开：cubic-bezier(0.3, 0, 1, 1)

10.3 禁止事项

• 弹跳
• 果冻式形变
• 过长动画
• 多段花哨运动
• 与业务无关的常驻装饰动画

11. 推荐动效模式

11.1 Hover

• 颜色轻微变化
• 背景轻微提亮
• 轻微阴影或轻微上浮
• 导航骨架中的 hover 可以有更明显一点的材质变化，但不应造成大幅跳动

11.2 Focus

• 清晰焦点环
• 轻量边框强化

11.3 面板出现

• 淡入 + 轻微位移
• 避免大幅滑入造成压迫感
• 顶栏、侧栏、轻浮层可结合轻度模糊和透明度变化，形成更现代的进入感

11.4 弹窗 / 抽屉

• 淡入 + 轻微缩放或轻微滑入
• 遮罩过渡应与内容同步，不可明显割裂

11.5 列表更新

• 避免整表闪烁刷新
• 局部更新优先于全局重新挂载

12. 页面级体验规范

12.1 页面切换

• 保持节奏轻，优先稳定而不是显著
• 页面标题、工具栏、内容区切换不应各自动太多

12.2 骨架屏与占位

• 骨架屏结构应接近真实布局
• 不要用与实际结构完全不一致的占位图形

12.3 响应式行为

• 优先保持信息层级和操作顺序
• 不要简单缩小所有控件到影响手感
• 小屏下优先重排而不是一味压缩

12.4 现代工作台感

• 页面切换、导航激活、工具区状态变化应体现“流动感”，而不是生硬闪现。
• 动效应让界面更像一个现代系统工作台，而不是一组静态表单页面之间的硬切换。
• 动效与反馈应帮助用户感知“控制层浮于内容之上”的空间关系，而不是通过硬分隔线提醒区域切换。

13. AI 模块交互建议

13.1 生成中

• 应让用户知道系统正在做什么
• 若耗时较长，可显示阶段性状态或进度提示

13.2 工具调用 / 工作流执行

• 优先呈现当前步骤、结果和异常信息
• 不要让执行过程完全黑盒化

13.3 失败恢复

• 失败后提供重试、编辑输入、查看错误原因等恢复路径
• 对话和流程记录尽量保留，避免用户重新来过

14. 与当前代码的演进建议

当前设计层已有：

• transition.css
• ui.css
• 若干组件内联 transition-* 规则

建议后续演进：

1. 先统一动效时长和缓动命名
2. 再逐步收敛组件内散落的 transition 写法
3. 最终沉淀为基础动效 token 和少量标准过渡模式

15. 交付时必须说明

如果任务涉及交互、状态、表单、浮层或动效改动，交付说明必须补充：

• 交互变化服务了什么任务目标
• 是否补齐了 loading、失败恢复与空状态
• 动效是否符合“细腻、短促、稳定、不变形”
• 是否影响键盘可达性、焦点样式或响应式表现