团队越来越习惯在晨会、会议间隙或差旅途中查看经营数据，但许多仪表板仍按桌面屏幕设计。用户打开手机后，只能反复缩放、横向拖动，再小心点击筛选控件。Amazon Quick 仪表板引入 Mobile Layout，针对的正是这种高频却低效的使用场景：让移动端不再只是桌面页面的缩小版。
移动布局解决的不只是屏幕宽度
桌面仪表板通常依赖多列网格、大尺寸图表和横向排列的筛选器。把这样的页面等比压缩到手机上，会同时产生几个问题：
- KPI 数字和图例变得难以辨认；
- 控件点击区域过小，容易误操作；
- 用户必须横向滚动才能比较数据；
- 最重要的指标可能被次要内容挤到首屏之外。
因此，移动布局的关键并非简单调整 CSS 宽度，而是重新定义小屏上的信息顺序。查看收入、销售管道或运行状态时，用户往往只需要快速回答几个问题：当前数值是多少、与目标相差多少、是否出现异常、接下来应查看哪个维度。
这意味着仪表板作者需要把移动端视为独立的决策界面。桌面端适合探索和横向比较，手机端则更强调扫描速度、触控操作和异常确认。
内容排序比图表缩放更重要
设计移动布局时，可以按以下顺序整理内容：
- 把收入、转化率、告警数量等核心 KPI 放在最前面。
- 将趋势图安排在 KPI 之后，帮助用户判断变化方向。
- 把筛选条件压缩到少量高频选项，例如日期、区域和业务线。
- 将明细表、长文本和低频分析放到页面后部。
- 检查每个控件是否能用手指准确操作，而不依赖悬停行为。
移动端也不适合机械复制所有桌面内容。一张包含十几个系列的折线图，即使能够塞进屏幕，也很难支持快速判断。更实用的做法是减少同时展示的系列，突出当前值、目标值和异常区间。
来源摘要没有给出 Mobile Layout 的具体编辑器步骤、接口或配置格式，因此不应假设它提供某个可编程 API。实际启用方式和发布流程应以当前 Amazon Quick 控制台及官方文档为准。
可以这样实践：自动检查移动端可用性
移动布局发布前，可以使用 Playwright 对仪表板页面执行基础验收。下面的示例不是 Amazon Quick 官方 API，而是一种可改造的浏览器测试方案。它会以手机尺寸打开页面，检查是否出现横向溢出，并保存截图。
先创建项目并安装依赖：
mkdir quick-mobile-check
cd quick-mobile-check
npm init -y
npm install --save-dev @playwright/test
npx playwright install chromium
新建 mobile-dashboard.spec.js，将 DASHBOARD_URL 指向测试环境中的仪表板地址。若页面需要登录，可以进一步使用 Playwright 的 storageState 保存测试账号会话。
const { test, expect, devices } = require('@playwright/test');
test.use({
...devices['iPhone 13'],
});
test('dashboard fits a mobile viewport', async ({ page }) => {
const dashboardUrl = process.env.DASHBOARD_URL;
if (!dashboardUrl) {
throw new Error('Set DASHBOARD_URL before running the test');
}
await page.goto(dashboardUrl, { waitUntil: 'networkidle' });
const dimensions = await page.evaluate(() => ({
viewportWidth: document.documentElement.clientWidth,
contentWidth: document.documentElement.scrollWidth,
}));
expect(dimensions.contentWidth).toBeLessThanOrEqual(
dimensions.viewportWidth + 1
);
await page.screenshot({
path: 'artifacts/dashboard-mobile.png',
fullPage: true,
});
});
运行测试：
mkdir -p artifacts
DASHBOARD_URL='https://your-dashboard.example.com' \
npx playwright test mobile-dashboard.spec.js
这项检查只能发现页面级横向溢出，不能判断图表内容是否清晰，也不能替代人工验收。建议再选择一台窄屏手机和一台大屏手机，检查以下项目：
- 首屏是否出现最重要的 KPI；
- 筛选器是否容易点击和清除；
- 图例、轴标签和数值是否可读；
- 加载状态或错误提示是否挤压布局；
- 从竖屏切换到横屏后是否出现内容遮挡；
- 身份验证和嵌入容器是否会额外占用可视空间。
上线时保留桌面端与移动端的职责边界
采用 Mobile Layout 时，不必追求两个端完全一致。真正需要一致的是指标定义、筛选语义和数据更新时间，而不是每张图表的位置与尺寸。
上线前可以建立一份简短清单：确认核心指标位于首屏，删除移动端低价值内容，在真实设备上验证触控区域，并为关键视口保留截图回归测试。同时记录桌面布局与移动布局的维护责任，避免后续新增图表时只更新其中一端。
移动布局带来的价值，最终要通过任务完成速度来衡量。用户能否在晨会开始前迅速确认收入，在会议间隙判断销售管道变化，或在旅途中发现运行异常，比“页面能在手机上打开”更能说明改造是否成功。