以内容优先的理念设计移动产品

2019-04-03    来源:Web App Trend

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

知名Web设计师Andy Clarke最近发布了320 and up,开源快速开发模板Mobile Boilerplate的分支。这恰好和他之前媒体查询的样板(media queries)相反,新的样板从较大宽度样式下的小屏幕样式和图层集合开始开发,而不是开始于为小屏幕裁剪大宽度的样式。

这绝对是利用特定宽度样式的最好方法,在结合媒体查询或者JavaScript 之后。但当我看到对应特定设备宽度的像素值时,我有些紧张:320*480,等等。相比之依靠一个假想的宽度,比如960个像素,这当然是一个进步。但我担心的是,这依然只是为了匹配现在流行的显示窗口,而简单地堆砌显示内容。这也是Mark所说的,“被版面局限”了的设计方法( the “canvas in” approach ):

“我相信,为了迎合网页本地布局设计的需要(不考虑设备),我们不得不从版面布局出发,再考虑我们的内容创意。而我们需要的其实是反过来,内容优先来设计布局。”

如今,可能的情况是你的内容就是基于像素的(图像或者视频),而且它们的尺寸恰好适合特定设备显示窗口的大小。但根据我的经验,待处理的大多数内容仍然属于文字类。但像素却不是处理文字的最好单元。这也是我倾向采用基于字体大小(em-based)的媒体查询的原因之一。

我的基本观点是,媒体查询应该服务于内容。某些站点可能适合把直线型布局应用于小屏幕,而柱状布局应用于更大设备(比如平板电脑)的屏幕。对其他站点,即使平板电脑尺寸的屏幕,直线型布局却更适合。这都取决于内容。

我最喜欢的关于内容优先的一个例子,是Dan 的文章type-inspired interfaces。我认为网页设计者的一个共识是,设计都应该内容优先,但我们现在却过于依赖类似画布的工具,比如某些预先确定的网格类工具(predefined grids)。类似地,在框架和信息构架领域,当我们需要专注于内容时,我们经常不自觉地去首先设计菜单和导航界面。

这是最近《移动优先》作者Luke对Jared说的一段话,其中提到了他的设计原则“内容优先,之后才是导航”(“content first, navigation second”)。

Luke曾经广为人知地对互联网开发者宣传移动为先( mobile first )的方法。这种方法用于发现推送给用户的重要内容,的确非常适用。但不要太绝对,有时候这种方法也等同于“打印样式表优先”(print-stylesheet first),或者某种“非桌面环境优先”(non-desktop environment first)策略。正确应用的关键,还是在于你是否把内容优先放在第一位(you’re thinking about the content first and foremost):

“屏幕空间被无端占用80%时,你才被迫注意到留在屏幕上的,应该是对于你的用户或者业务最重要的特点集合。而不是一堆界面的碎片,或者可要可不要的内容。你应该明确什么是最重要的。”

但这不是说你不能把某些不太相关却很不错的内容放到屏幕上。但这应该添加到可能需要某种条件来延缓加载的部分,而不是一股脑地把厨房水池一类的信息放到开始界面上。

移动页面设计上,已经出现了一系列非常不错的典范设计。然而,传统桌面网页设计却成为了死气沉沉和自鸣得意的代名词。这导致的是一堆充斥着陈旧无聊内容的网站,就像 Merlin 的Flickr相册Noise to Noise Ratio 列举的:
“当然,这之中还是有一些非常不错的原创性内容,虽然隐藏在一堆广告、自助链接和附加新闻中。”

对,在图中接着找。负责地说,里面“的确”存在有用的内容,不是吗?

还有一点共识,就是移动用户是不能糊弄的。应该尽快给这些总是匆匆忙忙的用户所需要的内容。但它的推论不一定成立。为什么我们认为桌面用户就更能够忍受如此多不需要的内容呢?

不需要的页面冗余一般看做对页面的破坏,用户可以利用Readability,Safari’s Reader和Instapaper等工具绕开它们。这些工具的存在,一方面是为了从多个内容来源为读者聚合信息(free up content from having a single endpoint),另一方面也将有用内容从被滥用得令人窒息的页面容器中解放出来。这不是新的现象,当然,在RSS出现之前我们就在浏览信息。但这些阅读辅助工具也应该当做对我们的警告,或者挑战。我们怎么能用这样一个用户讨厌的方式来承载内容,以致于用户不得不求助Readability或者Instapaper。

一些臃肿页面(常常是支离破碎的设计)的设计者,在设计站点时(通常是新的站点),都有一个另外的移动版本,通常是“m.子域名”的命名方式。这个版本中,内容并不是用桌面版本中呆板、冗余、分页的方式被呈现。我注意到用户在用Twitter或者email等工具分享链接时,分享的通常是这个简洁的m.版本。这些站点影响的广泛扩大,简单地说就是因为它们更加易读,在任何平台都是如此。

我们以前读到过,就像我在点评(the comment)Paul对移动开发者的误导(Paul’s misguided post on mobile design)时说的:

“在过去的坏日子里,为习惯屏幕阅读的用户设计独立而平等的只提供文本阅读的站点的确是常事。这样的确细分了用户,但显然,这只是取巧的方法。现在,我们知道习惯屏幕阅读的用户也应该享受和其他一样的内容服务,前提是站点应该用正确的方式构建(有趣的是,一些站点注意到“传统的”非屏幕阅读用户也倾向于更快更简洁的站点版本,这应该能给那些仍然认为桌面和移动站点完全不同的设计者好好上一课)。”

毫无疑问,我完全不同意Jakob Nielsen的说法(the proclamation from Jakob Nielsen):

“桌面的电脑和移动设备是完全不同的。唯一能带给用户良好体验的,就是为一个产品设计两个独立的版本,当然,一般来说移动版本会少一些功能。”

我很困惑,不知道为什么网站既然饱受简洁可用性方面的质疑,设计者还要另外设计一个版本,而让不用这个版本的每个人几乎无法忍受另一版本的臃肿混乱。要注意,我不是暗示每个用户都得到一样的体验,事实上远非如此。不过多亏渐进式增强设计(按照正确方法的响应式设计正是渐进式增强的一个完美应用),我们能提供用户需要的内容,并在任何设备上用最好的效果显示。
所以,这才是显出不同的关键:内容优先,而不是设备。

这是一个对网页设计来说激动人心的年代。种类不断增长的设备,直接揭示了我们以前传统、固定大小、内容臃肿的桌面中心设计方案有多么自以为是和南辕北辙。就像面对任何变动一样,总会有些紧张和神经质。开发者正慌不择路地发掘移动设备带给我们的变革和好处:

“我应该学习Objective-C吗?”

“我应该掌握HTML5吗?”

“我应该学习移动App构架吗?”

你也许正做着这样的事。不过,千万要记住内容策略(content strategy)的应用。

原作者: Jeremy Keith 。作者是知名web开发者,作者,工作生活于英国布莱顿。 文章写于2011年4月27日,源文链接。

文章来源:webapptrend.com

标签: 理念 移动 内容 

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:鲜果联播-Flipboard新版对比评测

下一篇:任务转场