E5.13.2long-press context menu设计研究
触屏上依赖长按，与其他手势竞争
别名: 长按菜单 · touch and hold · 手势冲突
概念解释
桌面用右键唤出上下文菜单，触屏没有第二键，多数产品改用长按（long-press / touch and hold）。长按不是一条空闲的通道：同一接触点上还住着滚动、轻点、拖拽、文本选择和系统级的长按菜单。上下文菜单在触屏上首先是手势争用问题，其次才是菜单里有什么。
机制
一次接触在抬手之前都是未完成的手势。系统用时间阈值和位移阈值来分类：位移大了是滚或拖，时间到了还几乎没动是长按，很快抬手是轻点。上下文菜单要抢「时间到了且没怎么动」这一格。可是人在准备滚动时经常先按住再决定方向，按住的时间一靠近阈值，菜单就会在滚动开始前冒出来，挡住列表。文本上的长按已被系统征用为选词；再叠一套对象菜单，两套会抢同一格，或轮流误触发。拖拽排序的列表里，长按还是「拿起这项」的起手，对象菜单几乎没有自己的时间片。
阈值调高，真正想要菜单的等待变长，人会以为没有菜单；阈值调低，路过的按住全变成菜单。没有第二键，这条通道天然拥挤，不能靠「再加一种长按」解决，只能决定哪一种手势在这一种对象上享有优先。
怎么研究
在列表、文本和可拖拽项上分别布置「打开上下文菜单」「滚动」「拖动排序」「选中文字」任务，记录手势被判成哪一类。自变量是长按时间、允许的位移、以及是否同时启用拖拽。因变量是目标手势成功率、菜单误开率、滚动被菜单打断的次数。
手指大小和年龄会移动阈值，实验室年轻被试的「刚好」对别的人群可能太短。
边界
有触控笔或键盘的设备可以回到第二键或修饰键，争用下降。系统已经提供标准的对象菜单 API 时，应让系统仲裁，而不是再叠一层应用长按。明确的对象内按钮（「更多」）不走长按通道，适合手势已经很挤的表面。桌面指针没有这个问题。
怎么落地
- 在已经要拖拽或选文本的表面，不要再用长按作为对象菜单的唯一入口；给可见的更多按钮。
- 长按与滚动共享的列表，把位移阈值写清楚：一开始动就交给滚动，不要在滚动中途弹出菜单。
- 与系统长按菜单冲突时，跟系统走或明确禁用其一，不要两个菜单先后弹出。
- 验证：在目标表面上连续做滚动、拖拽、选词和唤出菜单。任何「本想滚却出了菜单」或「本想出菜单却拖起来了」都是争用。再把长按时间调到用户感到「按住等了一下」，仍应能稳定唤出，而路过的按住不应出菜单。