K2.06.5hover dwell delay设计研究

悬停触发的时间阈值需要过滤路过式的鼠标移动

别名: 悬停停留 · 路过过滤 · hover intent · dwell

概念解释

桌面一旦把预览、次要动作、提示铺在许多对象上,指针去往真正目标时会穿过一串别的对象。停留阈值要求进入之后再等一拍,路过的轨迹来不及点亮这些对象,只有停住的那一个才触发。没有这拍等待,悬停带来的设计自由会变成一路弹窗。

它过滤的是路过,不是在微调「多少毫秒才算快」。菜单和气泡要不要两套数字,是输入原语里的事。

机制

桌面窗口大,悬停敏感的对象可以铺得很密:工具栏图标、表格每一行、导航每一项。指针却是一条连续轨迹,去右上角的关闭按钮也会扫过半个工具栏。若触发条件是「进入」,轨迹上的每一个对象都会开火,预览互相覆盖,次要动作闪成噪声,人还没到目的地已经被一路内容打断。停留把证据从「经过」改成「还在」:路过产生进入和离开,几乎不产生停留;有意预览产生停留。桌面越敢把设计押在悬停上,这道门槛越不可省——自由的规模就是路过的规模。

阈值是闸门,不是内容。闸门太短,路过仍能挤进去;闸门太长,有意的一瞥也要排队,人会觉得界面呆。桌面的自由能成立,靠的是这道闸刚好挡住轨迹、放行停住。

怎么研究

在铺满悬停对象的桌面窗口里做「去点远端目标」和「停下来看某一项」两种任务。自变量:停留时长、沿途悬停对象密度(这正是设计自由用得有多狠)。因变量:沿途误触发次数、到达真正目标的时间、有意预览被闸门挡掉的次数。

不要只测单个按钮上的延迟。密度才是桌面这笔自由的变量:同一阈值在疏的窗口上无感,在密的窗口上决定能不能用。

边界

有意的快速扫读(沿一列缩略图掠过看哪张是要的)会被停留闸门压住,这类任务需要更短的闸或按压修饰键暂时取消过滤。键盘焦点移动不是路过,焦点上的提示不应套用鼠标轨迹的停留。拖动过程中指针穿过的对象更不能当悬停触发,否则拖放通道被一路弹层打断。触屏没有路过式鼠标移动,这道闸不存在。

怎么落地

  • 凡是会弹出预览、次要动作条或气泡的进入事件,先加一道停留闸;指针在触发前离开就取消,不要排队。
  • 对象越密、弹出越打扰,闸越要挡得住路过;对象疏、弹出只是高亮,闸可以更短。不要用同一道闸对待整扇窗口里所有东西。
  • 验证:把指针从窗口一端划到另一端的一个按钮,沿途不应逐一弹出。再把指针停在某一项上,预览应在停住之后出现。若划过时已经一路弹,或停住后仍要等得像无响应,闸没设在路过和停住之间。

延伸

  • 同组K2.06.1 悬停允许无承诺的预览与提示 · K2.06.2 依赖悬停的设计无法迁移到触屏 · K2.06.3 同一产品跨形态时需准备两套方案 · K2.06.4 悬停可用于渐进呈现次要信息,避免界面一开始就显得拥挤 · K2.06.6 纯悬停触发的功能天然不可被键盘或屏幕阅读器发现 · K2.06.7 悬停态提供的信息若不可或缺,说明界面本身缺少必要的常驻线索
  • 相邻C1.20 悬停延迟与误触发 · C1.06 悬停状态及其在触屏上的缺失
  • 站内检索hover dwell · pass-through · hover intent

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/K2.06.5