H5.11.1dismissed notifications remain in history设计研究
已消失的通知需要在历史列表中可重新查看
别名: 通知历史 · 划掉再看 · notification replay
概念解释
通知栏是短暂表面：划掉、超时、被新到达挤走，卡片就没了。历史列表让这些已经从栏里消失的条目还能被打开再看——不是把它们永远钉在栏里，而是给一个可检索的回放。划掉常常是「现在没空」，不是「这条作废」。没有回放，暂时的清除变成永久丢失。
这条管消失之后还能不能找回。它不是免打扰当时挡下的契约（模式结束要有落点），也不是栏内把同类收成摘要。
机制
通知到达与人能处理的窗口经常错开：开车、开会、口袋误划。栏的设计是为了当下扫视，容量小、生命周期短。历史把「当下」和「稍后」拆开：栏负责打断与短期待办，历史负责记忆。没有这层记忆，人只能希望自己当时看清了，或打开每一个可能的应用去翻——后者把找回变成猜应用。
回放要保留对象链接，而不只是当时那一行文案。文案会过期（「你的车已到达」），点进去应落到当时的对象，即使对象状态已经变了，也要能看出「曾经是这条通知」。
怎么研究
让人在忙碌任务中划掉若干通知，过一段时间再找回。比较有系统级历史、仅应用内收件箱、与两处都无。
自变量：历史入口位置、保留时长、是否可搜、对象链接是否仍有效。 因变量：找回率、找回耗时、找错应用的次数、因找不到而反复打开应用的次数。
实验室里「请记住这些」会高估无历史时的回忆。应插入无关任务再找。不要用「划掉率」当清理成功——划掉可能是推迟。
边界
验证码、阅后即焚、加密会话可能不允许把正文写入持久历史；至少留下来源、时间和「曾有一条，需打开应用」。法律或企业策略可能要求更长或更短的保留，历史不是产品可以随便做永久日志的借口。公共设备上历史本身是泄密面，应随锁屏或退出清理。
怎么落地
- 提供系统或应用内的通知历史，划掉、超时、被挤走的条目默认进入，保留至少若干天。
- 每条可点回原对象；对象已不在时标明失效，而不是死链。
- 入口放在人找「刚才那条」会去的地方：通知栏底、系统设置、应用收件箱，而不是埋进关于页。
- 验证：让人划掉三条不同应用的通知，做十分钟别的事，再找回。找不到或要猜应用，历史就没有承担回放。