如何设计响应式表格

响应式表格设计要做的，是在可用宽度发生变化时，保留表格中有用的信息关系。让所有列都放得下，只是其中一种可能的解决办法。对于比较任务，一张易读的可滚动表格，可能比一组整齐堆叠的卡片更合适，因为卡片可能把用户需要比较的值分隔开来。

先从任务出发。用户需要比较多条记录、查找某一条记录、查看它的详情，还是对一组记录执行操作？答案决定了哪些信息必须放在一起，哪些信息可以通过控件进一步查看。如果不先回答这个问题，响应式设计就容易变成一连串被动调整：字体越来越小，列被隐藏，按钮也越来越拥挤。

下文使用一个虚构的评审队列作为示例，包含项目名称、负责人、状态、截止日期和未解决评论数。

找出必须保留的信息关系

表格之所以有用，是因为位置本身传达了含义。你可以沿着一列向下扫读，比较各个值；也可以沿着一行横向阅读，把某条记录与它的属性联系起来。响应式变化可能保留其中一种关系，却削弱另一种。

在项目评审示例中，经理可能需要找出仍有未解决评论、且最早到期的项目。截止日期和评论数必须同时可见，而且要能辨认它们属于哪个项目。仅仅因为评论数碰巧是最后一列，就把它隐藏起来，会破坏这项任务，即使画面因此看起来更干净。

而一位准备打开自己负责项目的评审者，需求又不同。他可能首先关心项目名称、状态和一个明确的操作入口，其他详情之后再看即可。紧凑的摘要加上展开功能，可能就很好用。底层数据没有变化，但完成不同任务所需的初始视图并不相同。

接着，标记完成每项任务需要哪些信息。每项任务都用到的列，应该放进核心视图。只有在选中某条记录之后才用得上的字段，可以考虑通过展开等方式再显示。这是在围绕用户的工作决定信息如何呈现，并不是要求删除较不重要的数据。

把表格宽度与页面宽度分开处理

一张宽表不必让整张页面都左右滚动。在 CSS 中，为表格添加设置了 overflow-x: auto 的包裹容器，就可以让响应式表格拥有自己的滚动区域，同时让标题、说明、筛选器和周围文字适应视口。包裹容器本身也必须能够在页面布局中收缩；如果网格列的尺寸固定，即使子元素设为占满宽度，也仍可能把整个页面撑宽。这样处理，才能把需要二维空间的区域限制在真正需要它的内容附近。

W3C 对内容重排（Reflow）准则的解释，允许那些必须依靠二维结构才能保持含义或用途的内容作为例外，数据表格就在其中。不过，它也区分了表格整体与单个单元格中的内容：后者仍然需要适当重排。这项例外并不是让所有标签和周围段落都溢出的理由。参见 W3C 对内容重排的说明。

在实际设计中，可以让较长的项目名称在合理的单元格宽度内换行。不要仅仅因为桌面设计原来用了很宽的列，就保留大片空白。表格可能需要横向移动来维持列之间的关系，但同时仍然可以通过合理设置单元格尺寸改善使用体验。

容器需要有能被识别的边界。如果最后一列可见内容恰好在屏幕边缘结束，又没有任何提示说明后面还有内容，用户可能会误以为表格已经显示完整。露出下一列的一部分、在环境支持时显示滚动条，或提供简短提示，都能更清楚地表明还有后续内容。不要只靠装饰性的渐隐效果来解释。

尽可能把表格标题和任务背景放在滚动区域之外。像“待评审项目”这样的标题，可以说明这些记录有什么共同点。简短备注可以解释初始排序方式或相关时区。这些内容帮助用户理解当前视图，不应变成额外的列，与数据争夺空间。

USWDS 展示了两种不同的响应式模式

美国网页设计系统的表格组件提供了可滚动和堆叠两种版本。滚动示例保留了矩阵结构；堆叠示例则在窄屏下，把每条记录显示为一组带标签的值。它的可操作示例让两者的区别一目了然。

这种差别比组件的名称更重要。矩阵通过位置，让人看出两列之间的关系；堆叠记录则重复显示标签，让用户可以独立阅读每一项。数据可以完全一样，但完成比较所需的工作量，可能大不相同。

在评审队列里试试这个任务：在评论数超过五条的项目中，找出最晚的截止日期。在表格中，你可以同时扫读评论数和日期两列；在卡片中，你可能必须逐条查看，并记住此前找到的候选项。现在把任务换成“查看 Cedar Lodge 的负责人和截止时间”。堆叠版本可能会很好读，因为这时比较已不再是核心任务。

根据读者需要付出的代价选择转换方式

交接实施时，明确几项必须保持不变的条件：用户始终能识别每一行，单位始终与对应数值相连，当前排序依据仍能被理解，调整窗口大小之后选择范围的含义保持一致。相比要求每个桌面列都塞进手机，这些约定更经得起布局变化。它们让实施者可以改变呈现，而不会在无声无息中改变用户的任务。

测试这套模式最难处理的情况。给行标签放入较长文字，再一直滚动到最右侧；展开相邻两条、且内容长度不同的记录；选中一个项目，改变视口，再继续同一个操作。干净的默认截图无法暴露这些问题：选中数量没有及时更新、吸附列挡住数值，或详情面板错误地关联到了另一条记录。

四种响应式模式及其取舍

1. 保留表格，并允许横向滚动

如果首要任务是比较对齐的数据，而且每一列都有意义，横向滚动就是很值得考虑的方式。它保留矩阵，而不是把数据改造成另一种信息结构。但它确实要求用户在横向空间中移动，因此需要有意识地设计这种浏览方式。

对于评审表格，把项目名称放在靠前的位置；如果实现能够可靠地支持吸附列，就让名称始终可见。否则，用户滚动到截止日期时，可能已经不知道当前这一行属于哪个项目。吸附名称列也应该足够窄，为其余数据留出实际可用的空间。

不要把半张表格都固定住。 在窄屏上，两三列固定列可能就占据了几乎整个视口，只给能滚动的内容留下一条窄缝。先用能保留上下文的最小标识。如果项目名称较长，可以允许换行，或谨慎使用辅助标识，不要把一个过大的区域固定在那里。

吸附区域的交叉处，需要仔细处理视觉层级。左上角单元格可能同时位于吸附表头行和吸附首列的上方。如果没有明确的层叠顺序和不透明背景，其他值可能会透出来，或发生重叠。这正是一种静态画面看起来没问题、滚动时却会出错的细节。

除了触摸手势，也要检查其他操作方式。必要时，键盘用户必须能到达并操作这个区域，交互内容周围的焦点也应保持可见。要在相关浏览器和辅助技术中验证实际行为；在设计稿上加一条轮廓，并不能证明键盘访问已经成立。

2. 显示优先列，其余内容按需展开

如果多数日常决定只依赖少量字段，优先列模式就可能适用。保留这些字段，再提供清楚的途径查看其他数据。只要优先级判断正确，就能在减少宽度的同时保留主要任务；判断不正确，则无法做到。

对于评审者，项目名称、状态和截止日期，可能组成一个实用的紧凑视图，负责人和评论数则可以放在展开行里。但对于需要找出“已逾期且还有未解决评论的工作”的经理，隐藏评论数就不合适。脱离用户任务，并不存在一套放之四海而皆准的“移动端列”。

使用能清楚表达展开状态的控件。展开内容在视觉上应明显属于正确的记录，相邻行看起来相似时尤其如此。如果详情面板的位置可能让归属不明确，就在面板内部重复项目名称。不要使用模糊标签，让人猜测这个控件究竟会打开详情、菜单，还是新页面。

几乎每条记录都要执行的操作，不应该必须展开后才能找到。 如果表格是评审队列，“打开评审”可能值得拥有一个直接可见的入口。把它和很少使用的元数据一起藏起来，虽然节省了宽度，却增加了反复操作的工作量。评估时要看哪些交互经常发生，而不只是哪些字段占空间。

明确说明被省略的列在哪里。如果桌面用户预期会看到负责人字段，到了窄屏它却消失了，界面就应提供一条容易理解的获取路径。无障碍详情视图、列选择器，或展开后的摘要，都可以承担这个作用。无声地移除字段，会改变用户能获得的信息。

3. 把每条记录变成带标签的卡片

当用户一次阅读一条记录时，堆叠记录很有用。每个值都有可见标签，一行数据变成一个小型竖向摘要。对于订单详情列表或预约列表，如果跨记录比较只是次要任务，这种方式就可能合适。

在虚构的项目表格中，一张卡片可以用 Cedar Lodge 作为标题，下面依次显示状态、截止日期、负责人和未解决评论。作为单条记录，它很容易阅读。但如果要比较十个项目的评论数，用户现在必须在一张长得多的页面里，反复寻找同一个标签。

选择这种模式之前，请一位用户比较多条记录的同一个属性。如果他必须来回滚动，才能记住各个值，说明卡片把横向移动换成了更大的竖向浏览和记忆负担。这种取舍也许可以接受，但应该是经过考虑的选择。

各张卡片的标签与数值顺序应保持一致。不要因为某个值缺失，就让一张卡片的状态出现在顶部，另一张却放在负责人之后。用有实际含义的文字表示缺失状态，让结构仍然可以预测。

不要只通过装饰性的生成内容插入标签，却不检查无障碍结果。视觉上看得到“截止日期”标签，与程序能够识别它和数据之间的关系，是两回事。最终标记必须让不看视觉卡片的人，也能连贯地理解数据。

如果桌面版本是语义化表格，窄屏只是改变视觉呈现，就要检查表格关系是否仍按预期保留。如果页面中存在两套不同呈现，也要确保隐藏内容不会产生重复控件或重复朗读。这种转换需要实施层面的审查，不能只调整响应式样式。

4. 让用户自己选择比较内容

有些表格的很多列确实都有存在的必要，但用户很少需要同时查看全部列。列选择器可以帮助用户建立有用的视图。专门的比较模式，则可以让他们选出少量记录，把相关属性放在一起查看。

这些控件也会带来额外工作。新用户可能不知道哪些列重要，也可能以为默认视图已经完整。应提供合理的初始视图，并明确提示有列被隐藏了。自定义应当帮助熟悉业务的用户，而不应让基本理解也依赖先完成配置。

对于评审表格，默认可以显示项目、状态、截止日期和评论。协调者可以添加负责人，个人评审者则可以移除这一列。项目标识应始终保留，避免记录变成一行行失去归属的数字。

比较模式更适合从少量备选项中做选择，而不是处理很长的队列。选择三个产品来比较，可能是合理的；但为了找出哪些项目逾期，就必须把所有项目都选一遍，是不必要的绕路。不要只因表格很宽，就添加比较控件。

如果用户可以保存视图，就要定义保存的具体内容。列是否可见、列顺序、排序方式和筛选条件，是不同的偏好。保存列布局，不应该意外地连旧筛选条件也保留下来，导致新记录被隐藏。在视觉原型中，把这些行为记录为需求，不要因为画了一个保存按钮，就暗示持久保存能力已经存在。

保留标签、数字和空单元格的含义

响应式变化经常会暴露原有内容规范不够清楚的问题。像“04/05”这样的日期，即使在大屏上也有歧义；没有空间容纳周围说明时，问题就更加明显。选择适合目标用户的日期格式，如果时区或相对日期背景会影响任务，也要提供这些信息。

数字列应使用一致的单位。除非表头和格式已经说明差别，否则不要把评论数量和文字状态混在同一个字段中。可以比较的数字应保持一致的对齐方式，方便辨认差异。不要只在窄屏上降低精度或删掉单位，却不考虑这些值是否还表达原来的意思。

决定空数据该如何表示。“未分配”“没有评论”和“不可用”表达的是不同状态，空白单元格却无法说明这些区别。在评审示例中，尚未分配负责人，不应该看起来与字段加载失败一样。

如果换行能够保留含义，就允许长标签换行。提示框可以提供补充背景，但如果用户必须反复去发现一个必要标签，它就不能很好地替代直接可见的文字。如果一个列标题长到在哪种布局都不好用，可以先考虑让措辞更准确，而不是马上将其截断。

W3C 的表格教程解释了，表头和数据单元格需要结构化标记，以及恰当的关联。这样用户即使不依赖视觉对齐来浏览，也能保留上下文。实施选定模式时应参考这些指导，尤其是行表头和列表头都参与表达含义的情况。参见 W3C 无障碍表格教程。

让控件的作用范围保持清楚

排序影响整个集合；打开详情影响一条记录；批量操作影响所选记录。布局变窄时，这些作用范围也应保持清楚。把所有控件都塞进同一个菜单，可能让用户不知道一个操作究竟会改变什么。

在视觉上，让行操作与对应记录保持关联。宽表最右侧的菜单，可能在横向滚动时移出视野。如果主要任务是打开项目，可以让项目名称带链接，提供稳定入口，再把较少使用的操作放进菜单。如何安排最合适，取决于哪项操作需要立即可用。

选择功能需要格外小心。在吸附首列放复选框可能很方便，但不能因此挤掉行标识。选中多条记录后，要显示数量，并说明选择范围是当前页，还是筛选结果中的全部记录。响应式版本不能悄悄改变这一含义。

排序控件应说明当前排序方向，而不是完全依赖一枚很小的箭头。如果排序列被隐藏，仍要检查用户是否能理解当前按什么排序。有时，把排序选项移到表格上方、带明确标签的控件中，会比把它留在看不见的表头上更清楚。

也要在窄屏下检查筛选和分页。表格本身可能易读，但筛选工具栏却伸出了页面，或者分页控件过于拥挤。虽然它们位于数据网格之外，却属于同一个任务。应测试从找到记录到执行操作的完整路径。

用难排内容和真实任务进行评审

使用能检验布局承受能力的内容：较长的项目名称、尚未分配的负责人、较大的评论数、缺失的日期，以及会换行的状态标签。还要加入足够多的行，让测试者必须沿着该模式所支持的方向移动浏览。三条完全整齐一致的记录，几乎说明不了响应式表格的实际表现。

对于滚动版本，请评审者横向移动后，把一个较晚的截止日期与对应项目名称联系起来。对于展开版本，请他找到一项详情，再返回并继续查看下一条记录。对于堆叠卡片，请他比较多个项目中的同一个值。这些任务可以揭示，设计保留的信息关系，是否正是用户实际需要的关系。

除了设备窄屏宽度，也要测试浏览器缩放。桌面用户放大内容时，虽然原因不同，也可能遇到同样受限的布局。检查文字是否仍然易读、控件是否仍能到达，以及吸附区域是否遮住了大部分可用空间。

在 OpenDesign 中，你可以用不同视口预设预览 HTML 表格布局，在过于拥挤的区域添加评论，再修改文字或样式。把示例记录和选定的任务保留在设计上下文中。语义化标记、键盘滚动、排序和保存状态，则要在实际实现的表格中测试。