D5.06.5Interruptive versus queued arbitration设计研究

中断式仲裁打断当前反馈,排队式仲裁延后播放

别名: interruptive · queued · preemption

概念解释

中断式仲裁立即打断当前反馈并改为播放新事件,排队式仲裁把新事件放到后面。两种策略对不同紧迫程度的场景适用:需要立即响应的情形适合中断,可以稍后处理的情形适合排队。

机制

两种策略的成本不同。中断保证了紧迫事件的即时性,但会破坏正在进行的反馈的完整性,用户可能因此失去上下文;排队保证了既有反馈的完整,但会让紧迫事件延迟到当前反馈结束。选择依据因此是两项代价的相对大小:若延迟带来的损失大于打断带来的损失,应选择中断;反之选择排队。这两种代价都随事件的重要性变化,所以策略应当按事件等级而非全局设定。

怎么研究

可比较两种策略在不同事件组合下的表现:构造低优先级反馈进行中、高优先级事件到达的场景,分别采用中断与排队,测量高优先级事件的响应延迟、被打断内容的恢复情况与用户的困惑程度。变量包括事件等级差、当前反馈时长与恢复机制的可用性。

边界

当被打断的反馈可以被完整恢复时,中断的代价明显降低,中断策略的适用范围扩大。当高优先级事件并不真正紧迫(只是比另一事件等级高)时,中断会造成不必要的打断,此时排队更合适。若用户无法区分被打断的内容是否还会继续,任何策略都需要配套的状态提示。

怎么落地

  • 按事件等级决定使用中断还是排队,而不是全局设定单一策略。
  • 采用中断时提供被打断内容的恢复路径,减少上下文损失。
  • 采用排队时给出队列状态,使用户知道还有事件等待。
  • 验证方式:在高低优先级混合的场景中测量高优先级事件的响应延迟与用户困惑程度,确认所选策略的代价可接受。

延伸

  • 同组D5.06.4 仲裁需要处理同一时刻多个事件的排队与丢弃规则 · D5.06.7 用户应能在特定场景下临时改写默认的仲裁结果
  • 相邻D2.10.2 高优先级警报应能打断正在播放的低优先级警报 · D5.06.3 优先级应按后果等级而非按通道能力
  • 站内检索interruptive arbitration · queued playback · preemption cost

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/D5.06.5