G1.05.1metadata enables filter sort relate设计研究
元数据支撑筛选、排序与关联
别名: 元数据 · descriptive metadata · 筛选排序关联
概念解释
元数据（metadata）是关于内容的结构化描述：类型、作者、日期、状态、受众、主题词。筛选靠字段值收窄集合，排序靠字段值排次序，关联靠共享字段把对象拉到一起。没有这些字段，界面上的筛选器、排序控件和「相关」模块没有可计算的输入，只能假装存在。元数据不是页面上的装饰标签，是让同一批内容按不同任务被切开、排开、连上的数据层。
标题和正文可以被人读，但不能被筛选器可靠地运算。能运算的是字段。
机制
浏览树一次只提供一条路径。元数据把对象从「住在某个文件夹」变成「携带一组可查询属性」，同一对象可以按日期被排、按类型被滤、按主题被连，而不必搬动它的主位置。筛选是在属性空间做交集，排序是在某一维上做全序，关联是在共享值上做邻接。三种操作消费的是同一份字段，字段的语义一旦含糊（「日期」是创建、发布还是修订），三种操作会一起说瞎话。
人能完成这三种操作，前提是字段名和取值的含义稳定，并且界面上的控件绑的就是这些字段，而不是另一套临时规则。
怎么研究
把界面控件和底层字段做成可核对的对应，而不是只测「筛选好不好用」。
- 范式：任务需要筛选、排序或找相关时，记录用户期望的切法；再对照对象实际拥有的字段。字段删除实验：拿掉某一字段，看哪类任务先崩。
- 自变量：可用字段集合、字段语义是否公开、关联是按共享字段还是按推荐模型。
- 因变量：任务能否在不回到整树浏览的情况下完成、排序是否符合用户对「最近 / 相关」的理解、相关模块的命中是否能被字段解释。
- 方法论注意点：日志里的筛选使用率低，可能是字段根本不支持用户的切法，不一定是用户「不爱筛选」。相关推荐若不能指出共享了哪一字段，就无法与「按元数据关联」混为一谈。
边界
纯线性阅读（一篇长文、一次结账）不需要这三种操作，硬加筛选会制造空控件。实时对象（正在进行的通话、传感器流）的字段在不断变，排序和关联的「当前值」会抖动，需要时间窗口，不能当静态目录用。机器学习相似度可以补字段稀疏，但它不是元数据：不可解释、不可手动修正，失败模式也不同。
怎么落地
- 为每类对象列出筛选、排序、关联各自要消费的字段，缺字段就不要画对应控件。
- 每个字段写一句对用户可说的定义（「日期 = 发布时间」），筛选、排序、相关共用这个定义。
- 关联模块展示共享了什么（同一作者、同一主题），不要只给「你可能还想看」。
- 验证：关掉正文搜索，只靠筛选、排序和相关，能否完成三类典型任务。哪一类完成不了，就是那一类还没有元数据，不是控件没设计好看。