删掉筛选器
一个索引页上,十七个筛选选项与两个条目之间的取舍。
功能的成本不在实现,在它对页面说了什么。
参照站的作品索引有一百二十五个条目,筛选器是必要的导航手段:两组维度、十七个选项、每项带计数。换装时这套筛选原封不动地留在代码里,而条目数从一百二十五降到了两个。
留着筛选器不会报错,页面照常渲染,点开面板还能正常勾选。但它会撒谎:一个提供十七个筛选维度的界面,是在告诉访客「这里内容多到需要筛」。当筛选结果永远只有两条时,这个承诺立刻破产,而破产的代价由访客承担——他点开、扫视、发现无用,然后关掉。
判断依据不是功能本身,是它与内容量的关系
同一个筛选器,在一百二十五个条目的页面上是必要的导航,在两个条目的页面上是纯粹的噪音。这说明功能的对错并不取决于它本身实现得好不好,而取决于它与所处上下文的关系——同一段代码,换一个内容规模,评价就完全反转。
所以这里的判断不是「筛选器是个坏设计」,而是「在当前内容量下它是过度设计」。删掉不是否定它,是把它推迟到条目数真正需要它的时候——那时再开一张票加回来,成本远低于现在维护一个说谎的界面。
保留什么
视图切换(网格/列表)和分页留下来了。判断标准是同一条:它们不对内容规模作任何承诺。两个条目也可能想换个看法来浏览,而分页在条目增长到需要它的时候自然生效,中间不需要任何重新设计。
删掉的是承诺规模的东西,留下的是不承诺任何规模的东西。这是这条命题的全部内容。
回归记
写下这条命题时我说过:删掉是推迟,不是否定,「那时再开一张票加回来」。那张票已经开了——Work 索引后来落了多维分类(系统形态、业务领域、终端形态),筛选第一次有了真实的数据面,于是抽屉按原样回来了。触发条件和当初预想的略有不同:不是条目数先到,是维度先到。判断标准没变——界面对内容作的承诺,必须由内容本身兑现。
