双栏保持列表上下文与详情同时可见
别名: 大屏双栏 · 列表详情同时可见 · split view · list-detail
概念解释
平板和展开的折叠屏有一块够宽的工作面，双栏（two-pane / split view）把集合放在一栏、当前对象放在另一栏，让列表上下文和详情同时落在视野里。价值不在多开一列装饰，而在换条时不必先卸掉集合：邻条的名字、标记、排序位置仍在余光中，点下一条是改选中，不是一次进出。手机上的「点进去再返回」是用时间换宽度；大屏若仍只给全屏详情，等于把这块多出来的物理宽度浪费掉。栏怎么随窗口伸缩、窄到什么程度该收成单栏，不是这条要处理的问题。
机制
巡检是在集合里移动。详情占用工作记忆去理解这一条，列表则把「我在哪一段、旁边还有谁」外化成看得见的坐标。两栏同时可读时，换条成本接近一次点击；列表一旦离开屏幕，坐标只能靠记忆或再导航重建。平板的物理宽度让两栏都能维持可读字号和可点目标，这是同时可见能成立的前提——并排本身不够，每一栏都得达到各自任务的最低宽度。大屏上坚持单栏栈，人会反复进出，空间记忆用不上，大屏相对手机的优势就只剩字更大。列表栏若瘦到只剩图标或被详情盖住，表面上还是双栏，上下文已经不在。
怎么研究
用同一批邮件、文件或记录，在平板横屏上比较「列表与详情同时可见」和「全屏详情加返回」。任务分成两类：巡检（逐条处理并对照邻条状态）和单条深读。
自变量：详情打开时列表是否仍在视野、列表栏是否显示识别字段、换条是点邻条还是返回再进。 因变量：换条时间、邻条状态误判、返回后的位置迷失、主观工作量。
巡检应在双栏上更快；深读不一定，因为深读不需要邻条。不要用桌面窗口的数据直接代替平板——平板是触控选中，没有悬停预览，换条的动作和桌面点击不是同一套。实验室里若强制「必须看完所有条」，会低估真实使用中因上下文丢失而放弃对照的情况。
边界
集合只有一条、或任务几乎从不换条时，常驻列表栏是噪音，单栏详情更干净。只读短预览可以并排；详情若是很长的编辑表，列表会被挤成细条，编辑过程应让详情暂时占满。竖持、分屏、折成外屏之后，物理宽度可能不够两栏同时可读，这时硬留双栏会两边都不可用。键盘外接、指针可用时，换条还可以靠方向键，双栏的「点邻条」优势会变小，但列表作为外部记忆的作用仍在。
怎么落地
- 邮件、文件、会话、设置分组这类「集合里逐条处理」的平板界面，默认用双栏，不要把手机栈直接放大。
- 列表栏至少要放下识别字段和选中态；详情里改了标题或状态，对应行要同步，否则余光里的上下文是过期的。
- 用改选中换条，而不是每次把详情推成新的全屏页。地址栏或导航栈若把列表卸掉了，就不再是双栏。
- 验证：处理十条里的三条，问邻条此刻的状态。必须先返回列表才能回答，说明同时可见没有成立。