极窄与极宽窗口都需要处理
别名: 极窄窗口 · 超宽窗口 · snapped window · ultrawide
概念解释
中间宽度上的连续重排还不够。窗口会被贴到屏幕一半、四分之一，或拉满一块超宽屏，极窄与极宽是两条不同的失败，不能用同一套补救对付。窄端的问题是放不下：多栏变成争抢，工具溢出，一行表格只剩半个单元格。宽端的问题是太空：一行字拉成地平线、主操作漂到视野外、空白被当成「还可以再塞一列」。
两端都要有明确策略。只保证「拖动过程中别崩」并不自动修好贴边后的四分之一屏，也不自动修好 32:9 上的一行正文。
机制
窄窗来自分屏、侧边对照、竖屏显示器、把参考材料钉在一旁。此时客户区接近一条手机那么宽，却仍按桌面信息架构来：双栏、固定宽工具条、横向标签。空间不够时，人不是「再挤一挤」，而是进入另一种任务形态——一次只盯一个对象。若布局仍坚持并排，控件开始互相覆盖，或出现只能靠横向滚动完成的主路径。
宽窗来自超宽显示器、窗口被拉到跨屏之前的最大矩形、把两个文档并排后各自仍然很宽。行长一旦超出舒适的阅读测度，扫视回行会丢行；把按钮按左对齐钉在窗口最左侧，右手边的内容区会变成一块没有锚点的空地。两端的物理原因相反，所以补救也相反：窄端要做降级（单栏、叠放、把次要面板收成可唤出），宽端要做约束（最大内容宽度、分栏封顶、把主操作留在视线中心附近）。
怎么研究
把窗口锁在极端宽高比上做任务，而不是只测「常见尺寸」。窄端用贴边或四分之一屏；宽端用超宽显示器或人为拉宽的窗口。阅读类任务要另测行长：同一段落在 40、80、120 字符宽度上的阅读速度和回行错误（Dyson 等人的测度研究是这一支）。
自变量：宽高比、列数策略、是否设最大内容宽度、窄端是否改为单栏。 因变量：完成率、横向滚动次数、回行找错行的次数、主操作落在视野外的次数。
不要把「最大化窗口」当成宽端的代表——最大化在 16:9 上往往仍是中间态。真正的宽端要专门造出来。
边界
固定画幅的图像或视频视口，宽了只是加黑边，不需要把内容拉长。数据表格和时间线以横向空间为资源，极宽是收益不是事故，但表头和行操作仍需在窄端可及。IDE、邮件三栏这类本身就靠宽度工作的界面，窄端的合理策略可能是「拒绝再窄并提示去用别的视图」，而不是硬折成单栏把结构拆毁。全屏放映没有「窄窗」。
怎么落地
- 为窄端准备降级：低于某一宽度改为单栏或可切换面板，主操作进入仍可见的底栏或折叠菜单，禁止用唯一的横向滚动去完成提交。
- 为宽端加约束：正文设最大测度，多栏封顶，不要让主按钮跟着窗口左缘一路漂到视野外。
- 验证：把窗口贴成屏幕的四分之一，做完一条主任务；再拉到超宽屏全宽，读完一段正文并点一次主操作。窄端若必须水平滑才能提交，宽端若一行超过约 90–100 字符还在拉长，两端都没处理完。