状态先于动效
真实音乐存在时才进入音乐活动；标题、歌手、时长与封面必须作为完整快照发布，不拼接新旧歌曲数据。
Back to selected work
TopIslet
Product study / 02 macOS native app
TopIslet
顶屿
一个安静地待在屏幕顶部的活动承载区。真正要解决的，不是把窗口做得像 Dynamic Island，而是让每一次状态、动效和控制都值得信任。
01 / The question
顶部的一小块空间，
需要一整套判断。
灵动岛式的视觉很容易被做成一张漂亮的黑色胶囊。难点在于：汽水音乐的真实状态会变化，权限会失效，媒体来源会抢占会话，控制命令也可能“成功派发”却作用在错误的播放器上。
所以我把 TopIslet 当成一个产品系统来推进：先定义可信状态和活动生命周期，再决定动效如何出现，最后用自动化和真实设备门禁验证它。
02 / Product decisions
三态，一条音乐活动
折叠、紧凑和展开是同一条真实音乐状态的不同密度；用户展开、拖动或控制时，自动事件不打断当前操作。
控制必须指向唯一目标
不依赖全局媒体键去“猜”当前播放器。控制路径保留进程、权限、窗口归属和唯一语义控件校验，失败就安全拒绝。
03 / Interaction model
同一首音乐，
三种阅读距离。
状态机让音乐信息服务于注意力：无需操作时隐去，需要确认时紧凑显示，需要控制时再展开。
01
Fold / 折叠
quiet无需持续阅读时只保留音乐状态信号，不遮挡当前窗口。
02
Compact / 紧凑
signal显示真实歌曲、艺人和进度摘要，让当前播放仍然可识别。
03
Expanded / 展开
control展示真实封面、时间轴、播放/暂停与上下一首定向控制。
04 / Original UI experience
原本的顶屿，
直接搬到网页。
把音乐状态留在屏幕顶部，只在需要时展开。
Midnight Circuit1000 Handz
音乐展开态，已暂停
05 / A failure worth keepingREAL DEVICE REGRESSION
“派发成功”，
不代表控制正确。
一次真实设备回归里，MediaRemote 命令返回了成功，但实际暂停了当前视频。这个结果直接否定了“只要系统接受命令就算完成”的假设。
我停用了这条路径，把产品控制改成目标应用内唯一、已验证的语义控件。这样做牺牲了一点通用性，却把误控其他播放器的风险关在产品边界之外。
The correction was product work, not just a code patch.
06 / Evidence
用门禁回答
“它真的工作吗？”
这些数字来自项目内的自动化、真实安装版和长稳验收记录。它们只说明已经验证过的范围。
v0.1.3 build 36 通过 swift test --quiet。
build 29 主动汽水下一首门禁中，控制请求全部被接受。
P50 / 12ms P95dispatch latency
控制派发延迟已从基线的 487ms / 569ms 降下来。
两小时长稳观察，资源和窗口门禁没有违规。
Still open
P0 / tracking完整曲目文本与封面的收敛 P95 仍约为 649ms，500ms 目标尚未关闭。产品继续保持原子发布，不用新歌名拼接旧封面。
07 / My angle
我更关心
下一次判断。
在这个项目里，我把产品需求、MVP 验收标准、状态模型、发布清单和回归证据放在同一条工作线上。每一次体验问题都要回到一个可复现的条件，再决定是改动效、改状态，还是收紧能力边界。
下一步不是继续堆更多入口，而是收集日常日志里的过渡证据，找到更早且可验证的完整状态来源，让“看起来快”变成“确实可信”。
Discuss this case ↗