多设备内容
作者:Sam Dutton
人们在网络上如何阅读
美国政府写作指南总结了人们对网页写作的需求:
进行网页写作时,使用通俗易懂的语言有利于用户找到他们需要的内容、理解他们找到的内容,然后利用这些内容来满足自己的需求。>> 网页写作应可操作、可查找并且可分享。
研究显示,人们不会阅读网页,他们只是浏览一下。一般来说,人们只阅读网页内容的 20–28%。从屏幕上阅读的速度比从纸上阅读的速度要慢。除非信息易于获取和理解,否则人们会放弃阅读并退出您的网站。
如何为移动设备撰写内容
关注手头的主题,表述应简明扼要。为撰写可在各种设备和视口上运行的内容,一开始就必须阐明重点:通常,理想的情况是前四段大约 70 个字。
问问您自己人们想从您的网站获得什么。他们是否在尝试找到一些信息?如果人们访问您的网站是为了查找信息,请确保您的所有文本都旨在帮助他们实现其目标。写作时使用主动语态,提供操作和解决方案。
只发布访问者需要的内容,仅此而已。
英国政府调查还表明:
80% 的人偏好使用浅显英语书写的句子,并且问题越复杂,这种偏好就越明显(例如,97% 的人在“among > other things”与拉丁文“inter alia”之间更偏好前者)。>> 人们的受教育程度越高,他们的知识就越专业,也 > 越倾向于使用简明的英文。
换句话说:应使用通俗易懂的语言、较短的词语和简单的句子结构,即使是针对有文化懂技术的受众。始终使用交谈式语气,除非有非常好的理由不这么做。新闻业的一个老规则是以像是在与一个聪明的 11 岁孩子交流的方式进行写作。
下一批十亿用户
这种最简明的写作方法对移动设备上的读者尤为重要,在针对具有小视口的低成本手机(需要更多滚动、显示屏质量较差且屏幕响应不太灵敏)创建内容时,采用这种方法尤为重要。
在将使用网络的下一批十亿用户中,大多数用户会使用廉价的设备。他们不想将自己的数据预算花在导航冗长的并且可能无法以其第一语言阅读的内容上。调整您的文本:使用较短的句子、最大程度减少标点的使用、每段不超过五行,且具有单行标题。考虑自适应文本(例如,针对较小的视口使用较短的标题)但也要注意这样做的弊端。
使用极简的文字也让您的内容更易于本地化和国际化,并且您的内容被社交媒体用户引用的可能性更大。
最低要求:
- 保持内容简单
- 减少杂乱无章
- 直接切入重点
消除不必要的内容
就字节大小而言,网页很大并且越来越大。
利用自适应设计技巧,可以为多个较小视口提供不同的内容,但先精简文本、图像和其他内容始终是明智之举。
网络用户通常以行动为导向,在寻找他们当前问题的答案时“身体向前倾”而不是向后倾,以消化一本好书。>> —Jakob Nielsen
问问您自己:用户在访问我的网站时尝试获得什么?
每个页面组件是否可帮助用户实现他们的目标?
移除多余的页面元素
根据HTTP Archive,对于普通的网页,HTML 文件构成近 70k 大小和九次以上的请求。
许多受欢迎的网站每个页面使用几千个 HTML 元素和几千行代码,即使在移动设备上也是如此。HTML 文件过大可能不会减慢页面加载速度,但 HTML 负载沉重可能表示内容臃肿:.html 文件越大,意味着元素越多和/或文本内容越多。
降低 HTML 复杂性也将减少页面重量,帮助实现本地化和国际化,并使响应式设计更容易计划和调试。有关编写更多有效 HTML 的信息,请参阅高性能 HTML。
在用户通过您的应用获得价值之前,让用户执行的每一个步骤都会让您失去 20% 的用户 >>—Gabor Cselle,来自 Twitter
这同样适用于内容:尽快帮助用户获得他们需要的内容。
不要只是向移动用户隐藏内容。以内容对等为目标,因为对某人来说,猜测移动用户不会错过哪些功能注定会失败。如果您有资源,可针对不同的视口大小创建相同内容的备用版本,即使是仅针对高优先级页面元素。
考虑内容管理和工作流:旧版系统是否会导致内容老旧?
精简文本
随着网络走向移动化,您需要改变您撰写内容的方式。保持内容简单,减少杂乱无章并直接切入重点。
移除冗余图像
根据
,网页平均发送 54 次图像请求。
图像很美观、有趣并且可以提供丰富的信息,但是它们也在使用页面空间,增加页面重量,并增加文件请求的数量。当连接性变得糟糕时,延迟也变得更严重,这意味着随着网络走向移动化,过多的图片文件请求成为日益严重的问题。
图像构成页面重量的 60% 以上。
图像也会耗电。继屏幕之后,无线电成为第二大耗电项目。图像请求越多,无线电使用就越多,需要的电量也就越多。即使只呈现图像也会耗电,且与大小和数量成比例。请参阅 Stanford 报告谁谋杀了我的电池?(Who Killed My Battery?)
如果可以,请去除图像!
下面是一些建议:
- 考虑避免带图像的设计,或谨慎使用图像。仅文本也可以很美观!问问您自己,“访问我的网站的用户尝试获得什么?图像对此过程有帮助吗?"
- 在过去,将标题和其他文本另存为图形的做法很普遍。该方法不能很好地响应视口大小变化,并且会增加页面重量和延迟时间。以图形方式使用文本还意味着文本不能被搜索引擎找到,且无法通过屏幕阅读器和其他辅助性技术访问。尽可能使用“真实”文本,网络字体和 CSS 可实现美观的字体。
- 使用 CSS 而非图像来设置渐变色、阴影、圆角和背景纹理,所有现代浏览器均支持这些功能。但是,请谨记,CSS 可能是比图像更好,但仍存在处理和渲染不利因素,特别是在移动设备上。
- 背景图片很少能够在移动设备上流畅运行。您可以使用媒体查询 来避免在小视口上使用背景图片。
- 避免启动画面图像。
- 使用 CSS 设置 UI 动画。
- 了解您的字形;使用Unicode 符号和图标替代图像,如有需要,可使用网络字体。
- 考虑图标字体;它们是可以无限缩放的矢量图形,可将整个图像集以一种字体进行下载。(但请注意这些问题。)
- 在 JavaScript 中,可使用
<canvas>
元素通过行、曲线、文本和其他图像来构建图像。 - 内联 SVG 或数据 URI 图像不会减少页面重量,但它们可以通过减少资源请求的数量缩短延迟时间。内联 SVG在移动设备和桌面设备浏览器上能够得到很好的支持,优化工具可以大大减少 SVG 尺寸。同样,数据 URI也得到了很好的支持。这两者都可以内联到 CSS 中。
- 考虑使用
<video>
代替 GIF 动画。移动设备上的所有浏览器均支持 video 元素(除 Opera Mini 以外)。
可以在不同视口尺寸上良好显示的设计内容
“创造适用于小屏幕的产品,而不是针对小屏幕重新设想一个。出色的移动 > 产品是创造出来的,而绝不是移植出来的。
—移动设计与开发,Brian Fling
"伟大的设计者不会“专门为移动设备进行优化”,而是考虑以自适应方式构建可在各种设备上使用的网站。文本结构和其他页面内容对于成功构建跨设备网站非常重要。
在将使用网络的下一批十亿用户中,有许多用户使用具有小视口的低成本设备。在低分辨率的 3.5 英寸或 4 英寸屏幕上阅读可能很困难。
下面是两个屏幕截图放在一起的照片:
在较大的屏幕上,文本小但可以阅读。
在较小的屏幕上,浏览器可以正确渲染布局,但是文本难以阅读,即使放大后也很难阅读。显示屏很模糊,并且存在“色偏”,同时白色也不是很白,使得内容难以辨认。
为移动设备设计内容
在针对各种视口进行构建时,要考虑内容以及布局和图形设计,使用真实文本和图像进行设计,而不是使用虚拟内容。
“内容比设计重要。缺乏内容的设计不能叫设计,只能叫装饰。”
— Jeffrey Zeldman
- 将最重要的内容置于顶部,因为用户往往以 F 形模式阅读网页。
- 用户访问您的网站以实现一个目标。问问您自己,为实现该目标他们需要什么,并去除其他内容。果断去除视觉和文本装饰、老旧的内容、过多的链接和其他杂乱无章的内容。
- 慎用社交分享图标;它们会让布局变得杂乱,其代码会拖慢页面加载速度。
- 针对内容(而不是固定设备尺寸)设计自适应布局。
测试内容
成功:不管做什么,一定要测试!
- 使用 Chrome DevTools 和其他模拟工具检查较小视口的可读性。
- 在低带宽和长延迟时间下测试您的内容;在各种连接场景中试用内容。
- 尝试在低成本手机上阅读内容并与内容进行交互。
- 请朋友和同事试用您的应用或网站。
- 构建简单的设备测试实验室。面向 Google 迷你移动设备实验室的GitHub 存储区提供了有关如何构建您自己的实验室的说明。OpenSTF是一个用于在多个 Android 设备上测试网站的简单网络应用。
下面是 OpenSTF 实例:
人们越来越多地使用移动设备吸收内容和获取信息,移动设备不再只是用于通讯、游戏和媒体的设备。
这使得在考虑跨设备布局、界面和交互设计时,计划可在各种视口上顺畅运行的内容并确定内容的优先级变得越来越重要。
了解数据成本
网页变得越来越大。
根据HTTP Archive,前一百万网站的平均页面重量现已超过 2MB。
用户会避免访问他们认为较慢或非常消耗流量的网站或应用,因此,了解加载页面和应用组件的成本至关重要。
减少页面重量还可以提高盈利。来自 YouTube 的 Chris Zacharias发现,当他们将观看页面大小从 1.2MB 减少到 250KB 时可以提高盈利:
以前无法使用 YouTube 的大量用户突然能够使用了。
换句话说,减少页面重量可以开辟全新的市场。
计算页面重量
计算页面重量的工具有很多。Chrome DevTools Network 面板显示所有资源的总字节大小,可用于确定具体资产类型的重量。您还可以从浏览器缓存查看已检索到哪些项目。
Firefox 和其他浏览器提供相似的工具。
WebPagetest可用于测试第一个页面加载和后续页面加载。您可以使用脚本(例如,登录到某个网站)或通过使用其RESTful API实现自动化测试。以下示例(加载developers.google.com/web)显示缓存已成功,后续页面加载不需要额外的资源。
WebPagetest 还可以按 MIME 类型提供大小和请求的详细分析。
计算页面成本
对许多用户而言,数据不只消耗字节和性能,还很费钱。
网站What Does My Site Cost?让您可以预估加载您的网站的实际财务成本。下面的直方图展示加载 [amazon.com] 所需的成本(使用预付数据计划)(https://www.amazon.com/\)。
请记住,这没有考虑相对于收入的支付能力。来自blog.jana.com的数据展示了数据的成本。
500MB 数据计划 成本(美元) | 每小时最低 工资(美元) | 为支付 500MB 数据计划需要工作的小时数 | |
---|---|---|---|
印度 | 3.38 美元 | 0.20 美元 | 17 小时 |
印度尼西亚 | 2.39 美元 | 0.43 美元 | 6 小时 |
巴西 | 13.77 美元 | 1.04 美元 | 13 小时 |
页面重量不只是新兴市场的问题。在许多国家/地区,人们使用数据有限的移动计划,如果他们认为您的网站或应用很重并且非常耗费流量,则会避免使用它们。即使“无限”蜂窝网络和 WiFi 数据计划也通常会有数据限制,超出这个限制就会被阻止或被节流。
根本问题:页面重量会影响性能并且费钱。优化内容效率介绍了如何降低该成本。