K2.05.3drag-and-drop failure feedback设计
拖放失败需给出原因
别名: 拖放失败 · 静默拒绝 · drop rejected
概念解释
对象跟着指针走了很长一段，松手后弹回原处、或落下去却毫无下文。失败要给出原因：类型不匹配、目标只读、权限不够、目标已满、应用正忙、这一块根本不是投放区。跨应用时源应用不知道目标为什么拒，目标若不说，整条通道看起来像坏了。
失败原因是松手之后的那一句话，不是拖动过程中的「不可放下」光标。光标避免误松手；原因解释已经发生的拒绝。
机制
跨应用拖放的两端不共享内部状态。源只看见自己交出了数据，目标只看见自己收下或拒收。操作系统可以把「没有类型匹配」表达成光标，却不能替目标说出「这个项目被锁定了」「附件超过上限」「正在同步不能写入」。人把一次拖放理解成单一动作，失败若没有下文，会被归因到整条桌面通道：以后再也不拖，改走导出。
弹回本身是空间上的「没过去」，但它是歧义信号——类型不对、权限不够、松手位置偏了三像素，看起来一样。原因必须落到目标窗口里，用一句能行动的话：换一种格式、先解锁、换一个文件夹。源窗口弹一句「对方拒绝了」没有用，因为下一步发生在目标那边。短暂提示即可，拖放已经占用了足够的注意，失败说明不要再开一扇模态把人锁住。
边界
拖动中途按 Escape 取消，不是失败，不应报错，对象安静回原位即可。类型不匹配在进入时就已经用「不可放下」光标说过了，松手若发生在非目标上，不必再弹一层；若发生在声明了接收、却在松手那一瞬才发现权限不够的目标上，必须说。批量拖入二十个文件、只有三个类型不对，要汇总，不要连弹二十次。沙盒拒收是系统级失败，应用仍应把系统返回的原因翻译成人能懂的句子，不要只留一条错误码。
怎么落地
- 在投放成功的区域，若松手后仍不能写入，在该区域旁给出原因和下一步（解锁、换格式、缩小体积），不要只把对象弹回源窗口。
- 区分取消和失败：Escape 或拖回源窗口是取消；松手在目标上被拒是失败。
- 验证：向只读目标、类型不支持的目标、已达上限的目标各拖一次。每一次都要在目标一侧看到原因。拖到窗口空白处再松开，应安静取消，不报错。连拖多个文件时，失败应汇总成一条。