Web 平台 API / ✦ UX 交互模式 · 那些有名字的交互细节 待审核 7 页

✦ UX 交互模式 · 那些有名字的交互细节

一个界面好不好用,常常不取决于功能列表,而取决于一批被反复打磨、各自有名字的交互细节: 点击后界面是立刻响应还是转圈等待;一处数据被改动后用户能否一眼找到; 误删之后能不能反悔;鼠标斜着滑向子菜单时菜单会不会半路消失。 这些模式大多诞生于具体产品的实战(Gmail 的撤销发送、37signals 的 Yellow Fade、Amazon 的 Mega Menu), 后来沉淀为通用词汇。本系列把其中 7 个挑出来,每个都做成可交互触发、并排对照「有 / 没有」的 demo。 正文中文,交互模式 / API 关键词保持英文。

一条主线: 这些模式服务于同一个目标——缩短「操作」与「反馈」之间用户能感知的间隙。 有的是提前给反馈(Optimistic UI),有的是事后留后路(Snackbar Undo), 有的是读懂指针的意图(Safe Triangle / Hover Intent / Fitts's Law), 有的是用连续的运动替代生硬的跳变(View Transitions)。 即时反馈:让等待「不被感知」 optimistic · 乐观更新

Optimistic UI:先更新界面,再等服务器

点击瞬间就把 UI 更新到成功后的样子,请求放到后台,失败再回滚。代价是偶发的「跳一下」。

yellow-fade · 黄色淡出

Yellow Fade Technique:让刚刚变化的地方自己跳出来

把刚改动的那一行瞬间染成黄色再缓缓淡回,用一次短暂的高亮牵引视线。关键在染色瞬间、淡出缓慢这条不对称缓动。

snackbar · 撤销优先

Snackbar & Undo:用「可以反悔」替代「确定吗」

与其每次删除前弹一个 confirm,不如直接执行、再给一条带撤销的 Snackbar。确认成本从每次操作前挪到极少数想反悔时。

读懂指针:在用户开口前理解意图 safe-triangle · 安全三角形

Safe Triangle:斜着滑向子菜单,不要半路关掉它

鼠标斜向移往子菜单时会扫过其他父项。以光标与子菜单靠父列表那条边的两角连成三角容差区,指针还朝三角内去就暂缓切换。

hover-intent · 悬停意图

Hover Intent:区分「路过」与「真的想看」

给「打开」加一道判定:指针停留超过阈值才触发,离开带一点关闭延迟。本质是对 enter 事件去抖。

hit-target · 点击热区

Fitts's Law:目标越大越近,越快越准

费茨定律把指向一个目标的难度量化为 log2(D/W+1)\log_2(D/W+1)。两个推论:热区可以比视觉大,屏幕四角是无限大的目标。

连续性:用运动替代跳变 view-transition · 共享元素转场

View Transitions:让同一个元素在两个状态间「长」过去

给前后两个状态里的同一元素标上 view-transition-name,浏览器自动补出位移与缩放的中间帧。同文档版靠 startViewTransition(),跨文档版只需两页同源各写一条 at-rule。

为什么这些细节值得单独命名? 因为它们解决的都不是「功能缺失」,而是感知问题: 同样的请求延迟,Optimistic UI 让它感觉是零;同样的一次删除,Snackbar 让它不再可怕; 同样一条 DOM 更新,Yellow Fade 让它被看见。把它们抽象成有名字的模式, 团队才能在 code review 里说「这里该上 optimistic / 加个 hover-intent」,而不必每次从头解释。

🔗 相关链接

📐 规范 / 文档

📎 模式出处 / 背景