E1.14.4button group overflow to another control设计研究
按钮组内选项过多时应改用其他控件而非持续横向扩展
别名: 按钮组过长 · 不要无限分段 · too many segments
概念解释
按钮组靠一排同时可见的键工作。选项一多，这一排要么挤瘦每个键，要么横向滚出视野。两种都不再是按钮组。过多时应换成选择菜单、列表或溢出「更多」，而不是把组无限接长。组的能力是「一眼比较这几个」，不是「当一条可滚动工具带」。
机制
同时可见是组的知觉前提。超出工作记忆和视宽之后，人要滚动才能看见全部，互斥关系不再能一眼成立，漏选和重复选都会出现。每个键变瘦，文字截断，命中区下降，邻项误触上升。希克选择也在变贵：组把 N 个选项都当成同等候选铺出来，N 到 7、8 以上，搜索加决策的时间不如一个可筛选的菜单。横向滚动还与页面纵向滚动抢手势。产品常因为「这些都是对等动作」而舍不得收进菜单，结果对等变成谁都看不清。
怎么研究
同一组动作做成 3、5、8、12 项的按钮组，对照 5 项组 + 菜单收其余。任务是找到中间那个不常见项并执行。
自变量：可见项数、是否允许横向滚、项标签长度。 因变量：找到目标的时间、截断造成的混淆、横向滚动与误触。
实验室宽屏会低估。要在目标手机宽度上测，8 项组往往已经破相。
边界
专业调色或时间线工具可以用可滚动的分段条，那是专家工作区，用户预期在带上巡航。图标极高共识且无文字的视图切换（列表/网格/看板）可以略多几枚。动态数量（每加一个账户多一枚）几乎一定该改用列表，不要让组跟着数据长。
怎么落地
- 把一组里同时铺开的项限制在一眼能比较的数量（通常四五个以内），其余进菜单或独立页。
- 不要给按钮组加横向滚动当「还是组」；出现滚动就换控件。
- 项数随数据增长的，一开始就用列表或选择器。
- 验证：在目标窄宽上，组内每一项的文字完整可见且可点。出现省略号、左右箭头或必须横滑，就是该换控件了。