太阳3娱乐什么才是好的移动交互设计?顶级新闻
发布时间:2020-04-09 17:55

  如何利用数据可视化帮助改善移动端的交互体验?来自华尔街日报、Bloomberg 等顶级新闻工作室的新媒体从业者们是这样思考的。

  如何利用数据可视化帮助改善移动端的交互体验?来自华尔街日报、Bloomberg 等顶级新闻工作室的新媒体从业者们是这样思考的。

  本文的原 po 给几乎每个案例、工具都做了超链。如果你对手机可视化的课题感兴趣,可点进原文做进一步学习。

  如何将台式机上优美的交互体验搬到手机上?在我肤浅的认知里,数据是很重要的一环。但目前的问题是,数据太多,甚至没有足够的位置去展现。

  手机有大量不同的功能,用户随功能产生不同的行为,开发者和设计师必须考虑这一点,不能想当然地认为移动端是桌面端的简化版。

  「移动设备若具备了能够感知倾斜和移动的陀螺仪、优秀的定位功能和内置摄像头,它将大有可为,」华尔街日报全球视觉负责人Jessica Yu 说,「所有终端都有它独一无二的特点」。Yu 告诉我,期待在 2050 年的新闻交互世界中,人们倾斜手机,就可以看见透镜状的图像,获得为读者准备的彩蛋。那时,台式机交互会变得不那么重要。

  有时候,「移动端」优先的思考决定了「桌面端以何种方式组织图片与交互行为」,甚至决定了内容团队组织信息的方式。

  「我们正在努力摆脱『大屏设计』的习惯,所有人的思考全部向『移动化』转变。」NPR 视觉负责人Brian Boyer 强调道,「如果这个设计在移动端行不通,它就不是好设计。我们已经基本放弃那种华丽的、大型图表设计了。」

  当我要求开发者和设计师详细解释一下他们如何在交互中融入「移动端」的考虑,所有人都觉得,智能手机提供了更多创造性的方式呈现内容。但同时也在一些方面表达了相同的挫折感:

  时间的紧迫度决定了我们使用哪种交互方式,同时,你一定得明确数据对用户具体的意义。比如,在「洛杉矶老化水管」的案例中,我们认为读者最想知道离他们最近的水管泄露点在什么位置,所以我们使用「地理位置」服务,让读者在手机上能查到离他们最近的泄露点。

  某些交互方式在手机上行不通,所以我们有时干脆在移动端禁用这些功能。如果移动端的阅读体验太差,我们会将地图的内容推倒重来。

  如果信息图必须呈现为「纵向」,而且数据很繁杂,那么它在移动端往往就行不通。当你缩放它,它在小屏幕的终端就无法正常阅读了。我们应该做的是——在更大的框架中收集并简化信息碎片,以便读者把握数据,并看到数据的趋势。否则就只能变换图像的方向了——当然,太阳3官网让读者翻转他们的手机体验不太好。

  要优化移动端的阅读体验,就要放弃复杂的数据和结构。我们很爱用D3.js,但很可能 HTML 就够用了,要从追求「高科技」的状态中走出来,为页面减负。

  在移动端加载视频确实是个头疼的问题(尤其是 iPhone 不允许视频自动播放),但我们不是没有解决方法。比如在「迦迪纳的警方监控录像」这个案例中,你可以选择不同的 camera,倒放或者略过,在移动端我们则简单做成了小的 GIF,放入 HTML canvas 元素中。

  在柏林墙崩塌 25 周年之际,我们打算调查柏林这几年的城市变化,并向城市数据库申请了解所有「柏林居住者」实际的出生地,但数据并不详细。但当一年后再度申请,我们拿到了一张巨型 Excel 表。

  当时我们脑子里有两件事。第一,这些数据的新闻性在哪儿?答案是,在柏林,你很少能遇上一个在柏林出生的人。第二,我们怎么吸引读者?交互有个规则:远处和近处的信息交互,太阳3娱乐必须都能行得通。且读者看到第一个画面时就要感觉有意思:啊,这是「与我有关」的新闻。

  对于 Zugezogenen Atlas 互动工具所显示的「柏林人」的实际出生地,详细信息(即近处信息)的展示非常重要,因为人们很可能需要在地图上放大他们的家乡,观察周边设施。

  我们把交互地图的中心展现为整个德国,如果你想要更大的图景,缩放即可。你能在地图上找到具体的乡址和相关数字,并将它们分享出去——它在脸书上有上万次分享,对于我们这样的地方报纸来说真的挺多了。

  后来我们又加上了「出生地最多的 100 个城市」,和关于「柏林的外来人居住在此的理由」的视频内容。

  在手机上操控地图并不容易。在台式机桌面上,你可以用鼠标「悬停」,但在手机上你必须「点击」,结果就没有太多容纳提示信息的空间了。但我们找到了解决方案——至少现在没人抱怨过这个方案——那就是当你输入地址,地图就将它即刻放大。这样用户只要集中精力把地址输对就行了,不用漫无目的地平移和缩放。

  桌面端和移动端需要同时考虑。当我们有了一个基础的想法后,就用文字或一些其他元素把它展现出来,交给设计师。设计师会为桌面端和移动端设计两套模型,接着开发人员去建模。

  我们并没有特别严格的工作流程,只是通 Slack 和 Trello 交流模型的好坏,并保持产品迭代。

  视频是个烦。苹果公司不允许 iOS 设备自动播放视频,你必须首先点击「开始播放」,然后视频变成全屏(所以你就从主页面跳出了)。我们这个产品中,「不断变化的天际线」的交互非常复杂,当你滑动阅读到特定文字的时候,地图也会显示到相应的位置。这套方案必须也能在移动端跑通。最后我们使用了我一个在纽约时报工作的大学同学所写的一个叫 canvid 的开源 hack,先抽取出视频的不同框架,生成图像,然后合并为一个镜头。这样你就能在 iPhone 上看到柏林「变幻的天际线」了。

  我很高兴能听到来自读者的称赞——而非数据分析师或技术人员的。因为我们真的为之付出了巨大心血。

  交互图的设计重点并不在于设计,而在于怎样通过个性化的设计让数据与读者的位置、家乡、职业(或某些他们已知的东西)相关。简而言之,就是让读者在乎数据。然后才到设计环节。你需要找到一个吸引人的数据呈现方式,同时它兼容不同设备。

  桌面和移动端需要两种完全不同的设计,并不是随意平衡一下屏幕大小就算完了,小屏的交互只能吸引有限的注意力。为移动端做交互设计,你就是在设计内容本身。

  台式机上「点击」的动作在手机上很好实现,问题在于你不可能做到「悬停然后释放出更多信息」,用户不会喜欢这样的功能。

  如果手机上也要实现悬停数据交互的话,就必须分步实现,不然用户会很迷惑究竟是该「点击」还是该「滑动」。从数据图中就要得到你的目标信息,这才是移动端好的交互设计。

  手机地图是个大工程,尤其是当它需要横向全屏的时候。有时候,你提取出一些有趣的数据制成信息图,那就足够了。在移动端可以少提供一些数据选择,用户不可能去点击每个细节。

  当展现时间序列数据时,在台式机上可以做小模块。在手机上也有很多方法可以让读者一眼就看懂数据,比如做一个 GIF,或者另外一些直观的方式。

  一个叫做 Modernizr 的 Javascript 库是个非常有用的工具,它可以帮助探测屏幕是否是触摸屏,以及屏幕尺寸大小——主要是探测读者使用移动端读数据的概率。移动数据可视化的工具不多,所以每个项目的工具都得看情况去找。

  在移动流量占据 50% 的今天,移动设计绝不再是什么次要的东西了。最初的设计方案需要具有流动性和平台未知性。

  首先,我们确定下需要展现的内容;其次,钻研如何实现——一个游戏、一系列信息图表、动画、时间线或是视频,我们在头脑风暴中所想的创意,或多或少可以在某些型号的设备上实现。

  桌面和移动的 UI 设计有根本区别。桌面设计允许鼠标悬停和点击交互,而手机允许滑动、倾斜或更为随意的物理摇晃。在手机上,你要设计一种靠滑动展现信息逻辑的路径。比如「From Pluto to the Sun」呈现给玩家的是整个「宇宙」,桌面用户可以在屏幕上随意点击任意星球。但在手机有限的视野中你不能呈现这种效果。所以我们设计了一种垂直滑动的交互方式,默认展现打开的信息图(在桌面上你需要点击进入)。

  我们利用所有可利用的工具为产品建模,不管是代码、Illustrator、Sketch,还是传统的纸笔,这都影响了我们最初的断点设置。我们的模版预先确定好了手机、平板和桌面视口的网格断点,这有助于对模块化的思考。同时,也要为这些项目的社交推广做考虑。

  为了容纳这样的交互设计,我们创建了一种基于用户引导的 HTML 模块,关联到我们的网格断点和样式表上,以此容纳基本反馈和类型层级。客制工作不可避免地要置于最高层级。考虑到我们的交互器模块,我们创建了一整套内置的内容响应工具容纳新闻编辑室的需求。移动体验是输出的一部分,不需要编辑进行额外的客制工作。

  固定地点的覆盖在移动端的精度要求很高且操作复杂,可尝试使用「折叠式」设计或干脆链接到一个新页面。如果你必须使用固定元素,确保即使延展开来,也不会超过屏幕的 30%。

  最适合桌面的图表样式通常在手机上水土不服,别觉得换成柱状图就一定 LOW。动画也是相同的道理。越简单可靠越好,比如只是一个简单的渐变或是直线运动。

  如果你使用单柱式设计,拒绝把一切藏在下拉框中的需求,因为交互体验太差。用户更习惯简单的滑动和有限的按钮。

  我们最大的成绩是创建了开源系统Daily Graphics,一款让懂代码的人更易创建图表的工具,它不支持点击指向和所见即所得,也跟chartmaker from Quartz 那样的工具有所不同,使用它首先要对Javascript、CSS 等语言很熟练。

  它就像一套我们使用的初始模板。从柱状图开始,慢慢变成一个常用图表样式库,你可以直接复制并加工。NPR 的图表在视觉表现上并不突出,那是因为人们通常拿它和印刷的杂志页做比较。我们 Elections 的网页是以移动端优先考虑的,你浏览下网页版就知道了,它是我们移动版的延伸。

  Elections 的图表被置于一个标准框架中,没有给本身体量很大的州太多位置。我们曾想尽力展现州的力量,但最后出来的样子像俄罗斯方块。

  所以我们给各州做了垂直频道,每个州有多少选票都被分开展现。选票会一夜之间填满,当票数达到某个临界值,那位竞选人就赢了。对我们来说,这样的页面就已经足够优美,它在手机上行得通。

  做地图很难。我们不太做国家地图,除非地理位置真的非常重要——比如河流走向、山峦范围、鸟类迁移等。我们做的是主题地图,最近大家喜欢去做各州的比较统计地图,每个州都是一个正方形,但我们觉得六边形才更接近地反应了实际地理状况。

  我们反对过多的交互。别让我必须交互才能读到些什么!许多像悬停交互一类的东西,移动端根本走不通。我们最近做的交互都是步进式的:点击、加载进程,然后你看到一些变化。

  最近我很满意的一组可视化成果,是关于沃尔玛城市分布点变迁的一组图。在桌面上它们一排三张,但在手机上它是一个 GIF。

  还有别的妙招。我们设计了一个叫MapTurner 的工具——基于代码线性控制,生成基于定位的矢量地图,虽然我们同样会使用扇形工具。MapBox 已经不再用了,虽然惊艳但在手机上行不通。

  我们还在日常图表系统中植入了一个响应式框架库 Pym.js。使用 Pym,图形会告诉页面需要多少容量,图形尺寸也同时支持纵横变化。

  研究了文本后,我可能会先开始在Illustrator 中建模,然后别人开始在 HTML 页面中建模,我们使用大量 D3。我知道别的组也会使用像Highcharts 这类工具,虽然简单但非常受限。

  但最终还是内容决定了设计和交互展现的形式,有些可以做成巨大的桌面工程,有些只能在小小的移动端展现。

  从网页开发者的角度看,我们更推崇自适应设计。我们需要考虑能适应所有界面的所有可能的版本,然后再去决定哪个最好。

  有时一个动画会拖累网速,但我们又想留下它,所以只好妥协把它做成静态的形式,但同时读者可以在小的移动设备上看懂它是什么意思。

  不管怎样,你最终的目的都是要让读者能非常容易地得出结论。要让读者在各自的平台上读懂图表,每个平台所需要的交互形式都可能是不同的。

  「budget quiz」这个案例非常合适我们。我们一直在想的是如何只通过一系列的点击让产品完型,减少用户在获取重要信息过程中不必要的「摩擦」。

  与之相对,「二氧化碳时钟」这个案例耗时数月。我们创建了室内模型预测大气中二氧化碳的含量,验证模型的精确性耗费了我们大量精力,但图表的效果是干净简单的。因为「二氧化碳时钟」是个常青项目,所以耗费那些精力也是值得的。但有时你一周做的东西也能常青,很难说。

  我们被赋予很大权限去追求不同的展现形式。我们基本上是一直在考虑怎么把想法真的做出来。一年光景,情况就会截然不同,有些旧的数据可视化形式会显得很过时。但其实不是这样,我们还是会在工作中提取旧的图表,然后不断优化旧图表,跟它们死磕。

  公司地址:北京市朝阳区酒仙桥路4号751 D·Park正东集团院内 C8座105室 极客公园

购买咨询电话
4008-974021
sitemap sitemap