G2.04.2scannable breadth limit设计研究
广度受可扫描数量限制
别名: 可扫描宽度 · menu visual search · 一屏选项上限
概念解释
一层里能合法放多少项，不取决于分类还能不能再切，而取决于人在那一块导航里扫得完、分得清。广度受可扫描数量限制：超出这个数量，多出来的项不是被「多一次决策」吃掉，而是根本没进视野，或进了视野却来不及完成一次辨别。这是视知觉和短时搜索的上限，不是类目在语义上是否互斥。
横条、竖列、巨型菜单的多列，上限不同。同一个「8 个」在底部标签栏里可能已经溢出，在侧栏长列表里却仍扫得动。
机制
扫视导航是视觉搜索，不是把选项装进 7±2 的短时记忆再回忆。眼睛沿一条可预期的方向跳（横条从左到右，列表从上到下），每跳一次读一个标签，直到命中或放弃。项数增加，跳的次数增加；项一旦落到折行、溢出菜单、「更多」后面，搜索空间被切开，后面那截默认不被扫。字号、间距、是否对齐成整齐的一列，会改变一次注视能覆盖几个标签，所以上限是布局参数，不是一个通用整数。
移动视口把可扫描数量压得更低：横条很快变成要横滑的一条，横滑出去的项等于不存在。桌面巨型菜单用多列把一次搜索拆成「先选列、再选行」，有效广度是列数与列内项数的乘积，但人必须先学会列的分组标题，否则多列只是把扫视路径折成锯齿。E5 里讨论的是控件能摆几个；这里的上限约束的是深度/广度权衡里「往宽里走」能走多远。
怎么研究
固定深度，只改一层里的项数和布局，用视觉搜索指标而不是满意度。
- 范式：菜单视觉搜索任务（目标项位置随机）；眼动记扫描路径是否覆盖全部项；首次点击测试看目标在溢出区时的命中。
- 自变量：项数、排列方向（横/竖/多列）、是否需要滚动或溢出、字号与间距。
- 因变量：搜索时、漏扫率（目标在屏上却未被注视）、溢出后再打开的比例。
- 方法论注意点：目标总在前几个槽位的测试会高估可扫描数量。必须把目标均匀铺在整条导航上，包括「更多」之后。7±2 不能当自变量的合法上限来用，它测的不是扫视。
边界
图标加短标签的底部栏，可扫描项更少，因为每个槽更宽、标签还要争宽度。专家知道目标在第几个，搜索时接近零，上限约束的是生手和偶尔任务。语音、命令面板、搜索建议走的是查询匹配，不受这一条视知觉上限约束。阅读方向与横条方向不一致的语言里，扫视路径要按书写方向重测，不能搬拉丁界面的个数。
怎么落地
- 在目标设备和真实字号下截导航，数「不滚动、不打开溢出就能完整读到的项」。这才是这一层的可扫描广度。
- 超出去的项不要假装还在这一层：要么换布局（横改竖、加列），要么承认它们在下一层，不要藏在「更多」里还按全宽来宣传。
- 多列必须先有可扫的列标题，否则先别加列。
- 验证：把目标项轮流放在每一个槽位（含溢出后）做首次点击。命中率在某一序号之后塌陷，那个序号就是当前布局的可扫描上限——权衡里的广度不能越过它。