移动大潮席卷了你我。
如何利用数据可视化帮助改善移动端的交互体验？来自华尔街日报、Bloomberg 等顶级新闻工作室的新媒体从业者们是这样思考的。
本文的原 po 给几乎每个案例、工具都做了超链。如果你对手机可视化的课题感兴趣，可点进原文做进一步学习。
本文编译自 niemanlab，原标题 Small screens, full art, can’t lose: Despite their size, phones open up new opportunities for interactives。
如何将台式机上优美的交互体验搬到手机上？在我肤浅的认知里，数据是很重要的一环。但目前的问题是，数据太多，甚至没有足够的位置去展现。
手机有大量不同的功能，用户随功能产生不同的行为，开发者和设计师必须考虑这一点，不能想当然地认为移动端是桌面端的简化版。
「移动设备若具备了能够感知倾斜和移动的陀螺仪、优秀的定位功能和内置摄像头，它将大有可为，」华尔街日报全球视觉负责人 Jessica Yu 说，「所有终端都有它独一无二的特点」。Yu 告诉我，期待在 2050 年的新闻交互世界中，人们倾斜手机，就可以看见透镜状的图像，获得为读者准备的彩蛋。那时，台式机交互会变得不那么重要。
有时候，「移动端」优先的思考决定了「桌面端以何种方式组织图片与交互行为」，甚至决定了内容团队组织信息的方式。
「我们正在努力摆脱『大屏设计』的习惯，所有人的思考全部向『移动化』转变。」NPR 视觉负责人 Brian Boyer 强调道，「如果这个设计在移动端行不通，它就不是好设计。我们已经基本放弃那种华丽的、大型图表设计了。」
当我要求开发者和设计师详细解释一下他们如何在交互中融入「移动端」的考虑，所有人都觉得，智能手机提供了更多创造性的方式呈现内容。但同时也在一些方面表达了相同的挫折感：
全屏地图、iOS 禁止自动播放视频、数据过载、同时适配平行和垂直界面。
下面是这些从业者的声音。
洛杉矶时报：好的交互需要大胆取舍数据
Len DeGroo，数据可视化总监
时间的紧迫度决定了我们使用哪种交互方式，同时，你一定得明确数据对用户具体的意义。比如，在「洛杉矶老化水管」的案例中，我们认为读者最想知道离他们最近的水管泄露点在什么位置，所以我们使用「地理位置」服务，让读者在手机上能查到离他们最近的泄露点。
某些交互方式在手机上行不通，所以我们有时干脆在移动端禁用这些功能。如果移动端的阅读体验太差，我们会将地图的内容推倒重来。
如果信息图必须呈现为「纵向」，而且数据很繁杂，那么它在移动端往往就行不通。当你缩放它，它在小屏幕的终端就无法正常阅读了。我们应该做的是——在更大的框架中收集并简化信息碎片，以便读者把握数据，并看到数据的趋势。否则就只能变换图像的方向了——当然，让读者翻转他们的手机体验不太好。
要优化移动端的阅读体验，就要放弃复杂的数据和结构。我们很爱用 D3.js，但很可能 HTML 就够用了，要从追求「高科技」的状态中走出来，为页面减负。
但我们会一直为复杂数据在移动端的呈现思考好的交互方式。
在移动端加载视频确实是个头疼的问题（尤其是 iPhone 不允许视频自动播放），但我们不是没有解决方法。比如在「迦迪纳的警方监控录像」这个案例中，你可以选择不同的 camera，倒放或者略过，在移动端我们则简单做成了小的 GIF，放入 HTML canvas 元素中。
柏林晨邮报：远近交互都要行得通
Julius Tröger, 交互负责人
在柏林墙崩塌 25 周年之际，我们打算调查柏林这几年的城市变化，并向城市数据库申请了解所有「柏林居住者」实际的出生地，但数据并不详细。但当一年后再度申请，我们拿到了一张巨型 Excel 表。
当时我们脑子里有两件事。第一，这些数据的新闻性在哪儿？答案是，在柏林，你很少能遇上一个在柏林出生的人。第二，我们怎么吸引读者？交互有个规则：远处和近处的信息交互，必须都能行得通。且读者看到第一个画面时就要感觉有意思：啊，这是「与我有关」的新闻。
对于 Zugezogenen Atlas 互动工具所显示的「柏林人」的实际出生地，详细信息（即近处信息）的展示非常重要，因为人们很可能需要在地图上放大他们的家乡，观察周边设施。
我们把交互地图的中心展现为整个德国，如果你想要更大的图景，缩放即可。你能在地图上找到具体的乡址和相关数字，并将它们分享出去——它在脸书上有上万次分享，对于我们这样的地方报纸来说真的挺多了。
后来我们又加上了「出生地最多的 100 个城市」，和关于「柏林的外来人居住在此的理由」的视频内容。
在手机上操控地图并不容易。在台式机桌面上，你可以用鼠标「悬停」，但在手机上你必须「点击」，结果就没有太多容纳提示信息的空间了。但我们找到了解决方案——至少现在没人抱怨过这个方案——那就是当你输入地址，地图就将它即刻放大。这样用户只要集中精力把地址输对就行了，不用漫无目的地平移和缩放。
桌面端和移动端需要同时考虑。当我们有了一个基础的想法后，就用文字或一些其他元素把它展现出来，交给设计师。设计师会为桌面端和移动端设计两套模型，接着开发人员去建模。
我们并没有特别严格的工作流程，只是通 Slack 和 Trello 交流模型的好坏，并保持产品迭代。
视频是个大麻烦。苹果公司不允许 iOS 设备自动播放视频，你必须首先点击「开始播放」，然后视频变成全屏（所以你就从主页面跳出了）。我们这个产品中，「不断变化的天际线」的交互非常复杂，当你滑动阅读到特定文字的时候，地图也会显示到相应的位置。这套方案必须也能在移动端跑通。最后我们使用了我一个在纽约时报工作的大学同学所写的一个叫 canvid 的开源 hack，先抽取出视频的不同框架，生成图像，然后合并为一个镜头。这样你就能在 iPhone 上看到柏林「变幻的天际线」了。
我很高兴能听到来自读者的称赞——而非数据分析师或技术人员的。因为我们真的为之付出了巨大心血。
公共廉政中心：为移动端做交互设计，你就是在设计内容本身
Yue Qiu, 新闻 app 开发者
交互图的设计重点并不在于设计，而在于怎样通过个性化的设计让数据与读者的位置、家乡、职业（或某些他们已知的东西）相关。简而言之，就是让读者在乎数据。然后才到设计环节。你需要找到一个吸引人的数据呈现方式，同时它兼容不同设备。
桌面和移动端需要两种完全不同的设计，并不是随意平衡一下屏幕大小就算完了，小屏的交互只能吸引有限的注意力。为移动端做交互设计，你就是在设计内容本身。
台式机上「点击」的动作在手机上很好实现，问题在于你不可能做到「悬停然后释放出更多信息」，用户不会喜欢这样的功能。
如果手机上也要实现悬停数据交互的话，就必须分步实现，不然用户会很迷惑究竟是该「点击」还是该「滑动」。从数据图中就要得到你的目标信息，这才是移动端好的交互设计。
手机地图是个大工程，尤其是当它需要横向全屏的时候。有时候，你提取出一些有趣的数据制成信息图，那就足够了。在移动端可以少提供一些数据选择，用户不可能去点击每个细节。
当展现时间序列数据时，在台式机上可以做小模块。在手机上也有很多方法可以让读者一眼就看懂数据，比如做一个 GIF，或者另外一些直观的方式。
一个叫做 Modernizr 的 Javascript 库是个非常有用的工具，它可以帮助探测屏幕是否是触摸屏，以及屏幕尺寸大小——主要是探测读者使用移动端读数据的概率。移动数据可视化的工具不多，所以每个项目的工具都得看情况去找。
华尔街日报：越简单可靠越好
Jessica Yu, 全球视觉负责人
在移动流量占据 50% 的今天，移动设计绝不再是什么次要的东西了。最初的设计方案需要具有流动性和平台未知性。
首先，我们确定下需要展现的内容；其次，钻研如何实现——一个游戏、一系列信息图表、动画、时间线或是视频，我们在头脑风暴中所想的创意，或多或少可以在某些型号的设备上实现。
桌面和移动的 UI 设计有根本区别。桌面设计允许鼠标悬停和点击交互，而手机允许滑动、倾斜或更为随意的物理摇晃。在手机上，你要设计一种靠滑动展现信息逻辑的路径。比如「From Pluto to the Sun」呈现给玩家的是整个「宇宙」，桌面用户可以在屏幕上随意点击任意星球。但在手机有限的视野中你不能呈现这种效果。所以我们设计了一种垂直滑动的交互方式，默认展现打开的信息图（在桌面上你需要点击进入）。
我们利用所有可利用的工具为产品建模，不管是代码、Illustrator、Sketch，还是传统的纸笔，这都影响了我们最初的断点设置。我们的模版预先确定好了手机、平板和桌面视口的网格断点，这有助于对模块化的思考。同时，也要为这些项目的社交推广做考虑。
为了容纳这样的交互设计，我们创建了一种基于用户引导的 HTML 模块，关联到我们的网格断点和样式表上，以此容纳基本反馈和类型层级。客制工作不可避免地要置于最高层级。考虑到我们的交互器模块，我们创建了一整套内置的内容响应工具容纳新闻编辑室的需求。移动体验是输出的一部分，不需要编辑进行额外的客制工作。
一些建议：
- 尽量减少不必要的交互。这通常意味着禁用图表提示和地图缩放。
- 固定地点的覆盖在移动端的精度要求很高且操作复杂，可尝试使用「折叠式」设计或干脆链接到一个新页面。如果你必须使用固定元素，确保即使延展开来，也不会超过屏幕的 30%。
- 最适合桌面的图表样式通常在手机上水土不服，别觉得换成柱状图就一定 LOW。动画也是相同的道理。越简单可靠越好，比如只是一个简单的渐变或是直线运动。
- 如果你使用单柱式设计，拒绝把一切藏在下拉框中的需求，因为交互体验太差。用户更习惯简单的滑动和有限的按钮。
- 对于时间相关的图表，要尽量展现更近的数据。
美国国家公共电台：别让我必须交互才能读到些什么！
Brian Boyer，NPR 视觉组负责人
我们最大的成绩是创建了开源系统 Daily Graphics，一款让懂代码的人更易创建图表的工具，它不支持点击指向和所见即所得，也跟 chartmaker from Quartz 那样的工具有所不同，使用它首先要对 Javascript、CSS 等语言很熟练。
它就像一套我们使用的初始模板。从柱状图开始，慢慢变成一个常用图表样式库，你可以直接复制并加工。NPR 的图表在视觉表现上并不突出，那是因为人们通常拿它和印刷的杂志页做比较。我们 Elections 的网页是以移动端优先考虑的，你浏览下网页版就知道了，它是我们移动版的延伸。
Elections 的图表被置于一个标准框架中，没有给本身体量很大的州太多位置。我们曾想尽力展现州的力量，但最后出来的样子像俄罗斯方块。
所以我们给各州做了垂直频道，每个州有多少选票都被分开展现。选票会一夜之间填满，当票数达到某个临界值，那位竞选人就赢了。对我们来说，这样的页面就已经足够优美，它在手机上行得通。
做地图很难。我们不太做国家地图，除非地理位置真的非常重要——比如河流走向、山峦范围、鸟类迁移等。我们做的是主题地图，最近大家喜欢去做各州的比较统计地图，每个州都是一个正方形，但我们觉得六边形才更接近地反应了实际地理状况。
我们反对过多的交互。别让我必须交互才能读到些什么！许多像悬停交互一类的东西，移动端根本走不通。我们最近做的交互都是步进式的：点击、加载进程，然后你看到一些变化。
最近我很满意的一组可视化成果，是关于沃尔玛城市分布点变迁的一组图。在桌面上它们一排三张，但在手机上它是一个 GIF。
还有别的妙招。我们设计了一个叫 MapTurner 的工具——基于代码线性控制，生成基于定位的矢量地图，虽然我们同样会使用扇形工具。MapBox 已经不再用了，虽然惊艳但在手机上行不通。
我们还在日常图表系统中植入了一个响应式框架库 Pym.js。使用 Pym，图形会告诉页面需要多少容量，图形尺寸也同时支持纵横变化。
彭博商业评论：减少用户在获取重要信息过程中不必要的「摩擦」
Blacki Migliozzi, Mira Rojanasakul, Alex Tribou, Bloomberg 图像组
Rojanasakul：
研究了文本后，我可能会先开始在 Illustrator 中建模，然后别人开始在 HTML 页面中建模，我们使用大量 D3。我知道别的组也会使用像Highcharts 这类工具，虽然简单但非常受限。
但最终还是内容决定了设计和交互展现的形式，有些可以做成巨大的桌面工程，有些只能在小小的移动端展现。
Migliozzi：
从网页开发者的角度看，我们更推崇自适应设计。我们需要考虑能适应所有界面的所有可能的版本，然后再去决定哪个最好。
有时一个动画会拖累网速，但我们又想留下它，所以只好妥协把它做成静态的形式，但同时读者可以在小的移动设备上看懂它是什么意思。
Tribou：
不管怎样，你最终的目的都是要让读者能非常容易地得出结论。要让读者在各自的平台上读懂图表，每个平台所需要的交互形式都可能是不同的。
Rojanasakul：
「budget quiz」这个案例非常合适我们。我们一直在想的是如何只通过一系列的点击让产品完型，减少用户在获取重要信息过程中不必要的「摩擦」。
我们曾建了一系列步进式图表，但后来放弃了，因为「滑动」的体验似乎更好。
Tribou：
我们用滑动取代点击式体验。因为对用户来说，不用再次进入某个页面，获取信息会更容易。
Migliozzi：
「是什么让地球变暖」是我们一个简单却非常棒的案例。没花多少时间，没有太多信息，但它非常棒。
与之相对，「二氧化碳时钟」这个案例耗时数月。我们创建了室内模型预测大气中二氧化碳的含量，验证模型的精确性耗费了我们大量精力，但图表的效果是干净简单的。因为「二氧化碳时钟」是个常青项目，所以耗费那些精力也是值得的。但有时你一周做的东西也能常青，很难说。
我们被赋予很大权限去追求不同的展现形式。我们基本上是一直在考虑怎么把想法真的做出来。一年光景，情况就会截然不同，有些旧的数据可视化形式会显得很过时。但其实不是这样，我们还是会在工作中提取旧的图表，然后不断优化旧图表，跟它们死磕。
图片来自 niemanlab
iOS下载