I2.06.1long wait must be cancellable设计
长等待必须可取消
别名: 加载可取消 · 长等待出口 · cancellable load
概念解释
加载一旦拖过还能把思路维持在这件事上的窗口，人就开始需要一条合法的离开：取消。取消在这里是加载语义上的操作——停止这次取数或这次长任务，而不是系统超时策略里「有一个放弃出口」那么一层。系统层面的超时策略只要求放弃出口存在即可；这里的要求更硬：长等待的界面上，取消是一等控件，和进度一起出现，人不必去杀应用、关页、拔网。
机制
长等待把人的注意和时间押在一条自己不能推进的路上。押注可以自愿延长，但必须能撤。没有取消时，撤的手段会外溢到操作系统：手势返回、划掉任务、关标签。那些手段的粒度错了——可能拆掉整次会话，也可能根本没通知到正在跑的请求，于是出现「我以为停了、它还在写」。产品内取消把粒度收到这次加载：只结束这一笔，上下文还在。
长的判据是任务，不是动画。导出、同步、大文件、跨海查询，即使用了确定进度，也必须可取消，因为进度只回答「还要多久」，不回答「我还能不能反悔」。短到还在即时或连续思维窗口里的请求，取消按钮自己会成为闪烁；那不是反对取消，是反对给来不及看见的等待配一套取消皮。
边界
不可中断的短握手（支付向银行确认的那几秒）可以没有取消，但必须真短，并在进入前说明；拖长了就回到必须可取消。取消若会留下半写入的危险状态，不是因此省略按钮，而是取消之后必须说清半写入怎么处置：是回滚、保留草稿还是标记不完整。后台已经接受、即使取消界面也无法撤回的作业（已提交的打印队列），按钮应改成「停止显示进度并去任务列表」，不要标成能撤回的取消。模态把取消做成系统返回键的副作用，等于没有一等控件：不是人人都会用那条键，也不知道它取消的是加载还是整页。
怎么落地
- 凡预计会越过连续思维窗口、人还留在这个界面里盯着的加载，在进度或等待皮旁放可见的取消。
- 不要把取消只藏在系统手势里。手势可以是第二条路，不能是唯一的路。
- 短请求不要为了对称而闪一个取消；长请求不要因为「已经有进度条」就省略取消。
- 验证：开始一次至少十几秒的加载。不看文档，能否在等待界面上直接点停。只能关应用或等它自己完，就说明没做到。