U6.10.5Bookmarks need human-readable names to be findable again设计

书签需要人可读的命名才能被再次找到

别名: 书签命名 · 可检索书签

概念解释

书签的生命周期里,"存下来"只是第一步,"找回来"才是价值兑现——而起名决定了找得回找不回。默认名(时间戳串或页面标题复制)在两周后的书签列表里毫无辨识度;一个人可读的名字("华东线上渠道增速异常排查")让书签在搜索、浏览、引用三种场景里都能被认领。

机制

命名的本质是把书签从"状态快照"升级为"知识条目":名字承载的是"这个状态回答了什么问题",而这正是未来检索的索引——用户找旧书签时凭的是任务记忆("上次查增速那次"),不是时间戳。命名还承担团队协作中的引用职能:会议里"看一下那个华东增速的书签"要求名字在口语中可指认。设计上要通过机制保证命名质量而非依赖用户自觉:默认名自动生成有语义的候选(基于当前筛选与视图的关键字段拼接),鼓励或要求改名,书签列表支持按名字与状态内容双索引搜索。

边界

命名不能替代状态预览:名字是索引,但确认"是不是那个"仍需状态摘要(筛选条件、数据时点的自动摘要随书签显示),两者配合才能在长列表里快速认领。命名规范也无需过度设计——不强制统一句式,能区分即可;要避免的是让命名成为保存的门槛(弹窗强制填写长表单会让用户放弃保存)。共享书签的命名还要经得起他人视角测试:自己懂的黑话在团队书签库里等于没有名字。

怎么落地

  • 保存书签时预填语义化默认名(由筛选与视图关键字段生成),一键可改。
  • 书签列表与搜索覆盖名字与状态内容两个索引。
  • 验证:让用户在三十条书签里找回一个月前的某个分析;凭名字能定位即合格,需要逐个打开试错即命名机制失效。

延伸

  • 同组U6.10.1 分析状态需可被编码为可复现的链接或快照 · U6.10.2 底层数据更新后旧书签指向的结论可能不再成立 · U6.10.3 书签需记录筛选与视图配置,而不只是页面位置 · U6.10.4 分享链接的接收者可能因权限不足而看到不同的数据
  • 相邻U6.11.3 探索路径本身是分析产物 · U6.10.3 书签需记录筛选与视图配置,而不只是页面位置
  • 站内检索bookmark naming · saved view search · findability

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/U6.10.5