F2.09.2ragged masonry columns break reading order设计研究
列间高度不齐会破坏阅读顺序
别名: 瀑布流阅读顺序 · masonry scan path
概念解释
三列瀑布流没有「行」。下一眼该往右、还是顺着本列往下？源顺序里的第 1 项可能因为左列一张竖图，被挤到中列半腰。用户按报纸习惯横着扫，会漏掉竖图下面那张；按列扫，又会把源顺序第 2 项看成第 5 项。
高度不齐破坏的是第一次怎么读，不是「下次还能不能找到」（那是位置稳定性）。
机制
横向文字文化默认自上而下、从起始边横扫再换行。瀑布流取消了行，插入算法（最短列）又不保证空间邻接等于源邻接。于是存在至少两套互相矛盾的策略，混用就会漏项。
「头条」若只保证源顺序第一，视觉上完全可能落在第二列中部，注意力却先被左上角一张高图吸走。布局在这里改写了编辑顺序，而且没有给出替代的阅读路径（编号、流向箭头）。
怎么研究
眼动扫视路径是现成范式：给同一组图做瀑布流与有行网格两版，看扫描是列优先、行优先还是跳。自变量：列数、高度方差、是否在左上放一张特高图。因变量：项的首次注视顺序与源顺序的相关、漏看率、回忆「刚才第几张」的准确度。
实验室常规定「请按你自然的方式看」，得到的策略因人不同而不同，这正是产品里的问题，不是噪声。不要把平均扫视路径当成所有人的路径。
边界
用户来找一张特定的图（搜索、保存过），阅读顺序不重要，找得到才重要。一列时没有列间不齐。游戏化的拼贴本就不提供顺序。若每张卡有明确编号或时间戳，顺序可以从文字恢复，空间乱序的伤害会小一些。
怎么落地
- 若任务含「按相关度或时间读下去」，不要用瀑布流；用有行的网格，裁切或信箱交给媒体策略去单独处理。
- 非用不可时，把最重要的一项做成通栏或固定占左上整块，不要交给最短列算法。
- 验证：在截图上按源顺序编号 1、2、3…，用笔连阅读路径。路径在列之间之字形、或 1 不在人们第一眼的位置，就记下被跳过的编号。把同一批图改成有行网格再连一次，比较漏掉的编号数。漏得少的那版才是阅读顺序还在的布局。