C3.17.3Danger of full-swipe-to-perform设计研究
全滑到底直接执行的危险性
别名: 滑到底执行 · swipe to commit · 全滑提交
概念解释
侧滑有一档是“拖过整行，松手就执行默认露出项”，不再停在按钮上点一下。这档叫全滑执行。它省掉一次点按，也撤掉一次确认。惯性、邻行误滑、想露出按钮却滑过了头，都会在抬起时直接提交。危险来自提交绑在行程而不是绑在明确的点击。
机制
露出按钮是两段式：滑开（选择要看哪些命令）再点（提交某一个）。全滑把两段合成一段弹道，抬起即默认项。列表又常带惯性，一次略快的横滑会越过停靠点。行与行间距小，斜向滑会在邻行上完成全滑。因为没有第二段点击，系统也无法在提交前要求“你点的是这个标签”。撤销条可以补救，但它出现在提交之后，而且会被下一条操作清掉。全滑的速度优势，是拿确认台阶换的。
怎么研究
比较“只能滑开再点”与“允许全滑执行”。任务混合：故意归档、故意只想看按钮、快速浏览中的误横滑。因变量为意外提交率、事后撤销使用率、完成有意归档的时间。把惯性开/关作为自变量。邻行条件（密列表 vs 大卡片）要分开，密列表的全滑误伤更高。
边界
可逆且低风险的操作（标已读、钉住）全滑的危险低。离线队列里的全滑若尚未同步，仍有时间撤回，危险被推迟。没有撤销通道的全滑，危险在抬起那一瞬就闭合。游戏或演示里的全滑是表演，不在列表生产力语境。
怎么落地
- 默认不要开全滑执行；需要加速时只给低风险命令开，并保证过线时有强烈的跟手预览。
- 提供提交后的短暂撤销，且下一条手势不要立刻清掉它。
- 请人“只想看看这行有什么按钮”和“在快速过列表时不小心横滑”。前者不应提交；后者在密列表里若经常改了数据，全滑就太危险。