HTML5设计原理(下)

平稳退化

下一条原理大家应该都很熟悉了,那就是平稳退化。毕竟,我们已经遵守这条规则好多年了。渐进增强的另一面就是平稳退化。

有关HTML5遵循这条原理的例子,就是使用type属性增强表单。下面列出了可以为type属性指定的新值,有number、search、range,等等。

input type="number"

input type="search"

input type="range"

input type="email"

input type="date"

input type="url"

最关键的问题在于浏览器在看到这些新type值时会如何处理。现有的浏览器,不是将来的浏览器,现有的浏览器是无法理解这些新type值的。但在它们看到自己不理解的type值时,会将type的值解释为text。

无论你写的是input type=”foo”还是input type=”bar”,现有的任何浏览器都会说:“嗯,也许作者的意思是text。”因而,你从现在开始就可以使用这些新值,而且你也可以放心,那些不理解它们的浏览器会把新值看成type=”text”,而这真是一个浏览器实践平稳退化原理的好例子。

比如说,你现在输入了type=”number”。假设你需要一个输入数值的文本框。那么你可以把这个input的type属性设置为number,然后理解它的浏览器就会呈现一个可爱的小控件,像带小箭头图标的微调控件之类的。对吧?而在不理解它的浏览器中,你会看到一个文本框,一个你再熟悉不过的文本框。既然如此,为什么不能说输入type=”number”就会得到一个带小箭头图标的微调控件呢?

当然,你还可以设置最小和最大值属性,它们同样可以平稳退化。这是问题的关键。

再看input type=”search”。你也可以考虑一下这种输入框,因为这种输入框在Safari中会被呈现为一个系统级的搜索控件,右边还有一个点击即可清除搜索关键词的X。而在其他浏览器中,你得到的则是一个文本框,就像你写的是input type=”text”一样,也就是你已经非常熟悉的文本框。那为什么还不使用input type=”search”呢?它不会有什么副作用,没有,对不对?

HTML5还为输入元素增加了新的属性,比如placeholder(占位符)。有人不知道这个属性的用处吗,没有吧?没错,就是用于在文本框中预先放一些文本。不对,不是标签(label)——占位符和标签完全不是一回事。占位符就是文本框可以接受的示例内容,一般颜色是灰色的。只要你一点击文本框,它就消失了。如果你把已经输入的内容全部删除,然后单击了文本框外部,它又会出现。

使用JavaScript编写一些代码当然也可以实现这个功能,但HTML5只用一个placeholder属性就帮我们解决了问题。

当然,对于不支持这个属性的浏览器,你还是可以使用JavaScript来实现占位符功能。通过JavaScript来测试浏览器支不支持该属性也非常简单。如果支持,后退一步,把路让开,乐享其成即可。如果不支持,可以再让你的JavaScript来模拟这个功能。

现在,我不得不提到另一个话题了:HTML5对Flash。也许你早听说过了,或者在哪里看到了这方面的讨论。说实话,我一点也不明白。我搞不懂人们怎么会仅仅凭自己的推测来展开争论。

首先,他们所说的HTML5对Flash,并不是指的HTML5,也不是指的Flash。而是指HTML5的一个子集和Flash的一个子集。具体来说,他们指的是视频。因此,不管你在哪里听到别人说“HTML5对Flash”,那很可能说的只是HTML5视频对Flash视频。

其次,一说HTML5对Flash,就好像你必须得作出选择一样:你站在哪一边?实际上不是这样的。HTML5规范的设计能够让你做到鱼和熊掌兼得。

好,下面就来看看这个新的video元素;真是非常贴心的一个元素,而且设计又简单,又实用。一个开始的video元素,加一个结束的video元素,中间可以放后备内容。注意,是后备内容,不是保证可访问性的内容,是后备内容。下面就是针对不支持video元素的浏览器写的代码:

<video src="movie.mp4">

<!-- 后备内容 -->

</video>

那么,在后备内容里面放些什么东西呢?好,你可以放Flash影片。这样,HTML5的视频与Flash的视频就可以协同起来了。你不用作出选择。

<video src="movie.mp4">

<object data="movie.swf">

<!-- 后备内容 -->

</object>

</video>

当然,你的代码实际上并没有这么简单。因为这里我使用了H264,部分浏览器支持这种视频格式。但有的浏览器不支持。

对不起,请不要跟我谈视频格式,我一听就心烦。不是因为技术。技术倒无所谓,关键是会牵扯到一大堆专利还有律师、知识产权等等,这些都是Web的天敌,对我建网站一点好处都没有。

可你实际上要做的,仅仅就是把后备内容放在那而已,后备内容可以包含多种视频格式。如果愿意怕话,可以使用source元素而非src属性来指定不同的视频格式。

<video>

<source src="movie.mp4">

<source src="movie.ogv">

<object data="movie.swf">

<a href="movie.mp4">download</a>

</object>

</video>

上面的代码中包含了4个不同的层次。

1、如果浏览器支持video元素,也支持H264,没什么好说的,用第一个视频。

2、如果浏览器支持video元素,支持Ogg,那么用第二个视频。

3、如果浏览器不支持video元素,那么就要试试Flash影片了。

4、如果浏览器不支持video元素,也不支持Flash,我还给出了下载链接。

不错,一开始就能考虑这么周到很难得啊。有了这几个层次,已经够完善了。

总之,我是建议你各种技术要兼顾,无论是HTML5,还是Flash,一个也不能少。如果只使用video元素提供视频,难免搬起石头砸自己的脚,我个人认为。而如果只提供Flash影片,情况也好不到哪去,性质是一样的。所以还是应该两者兼顾。

为什么要兼顾这两种技术呢?假设你需要面向某些不支持Flash的手持设备——只是举个例子——提供视频,你当然希望手持设备的用户能够看到视频了,不是吗?

至于为什么要使用不同的格式,为什么Flash视频和音频如此成功,我想可以归结为另一个设计原理,即梅特卡夫定律(Metcalfe’s Law):

网络价值同网络用户数量的平方成正比。

梅特卡夫的这个定律虽然是针对电话网提出来的,但在很多领域里也是适用的。使用网络的用户越多,网络的价值也就越大。人人都上Facebook,还不是因为人人都上Facebook嘛。虽然Facebook真正的价值不在于此,但只有人人都上才会让它的变得如此有价值。

梅特卡夫定律也适用于传真机。如果只有一个人购买了传真机,当然没有什么用处。但如果其他人也陆续购买了传真机,那么他的投资会就得到回报。

当然,面对竞争性的视频格式和不同的编码方式,你感觉不到梅特卡夫定律的作用,我也很讨厌以不同的方式来编码视频,但只向浏览器发送用一种方式编码的视频是行不通的。而这也正是Flash在视频/音频领域如此成功的原因。你只要把Flash影片发送给浏览器就好了,然后安装了插件的浏览器都能正常播放。本质上讲,Flash利用了梅特卡夫定律。

最终用户优先

今天我要讲的最后一个设计原理,也是我个人最推崇的一个,但没有要展示的代码示例。这个原理更有哲学的味道,即最终用户优先。

这个设计原理本质上是一种解决冲突的机制。换句话说,当你面临一个要解决的问题时,如果W3C给出了一种解决方案,而WHATWG给出了另一种解决方案,一个人这么想,另一个人那么想……这时候,有人站出来说:“对这个问题我们这样来解决。”

一旦遇到冲突,最终用户优先,其次是作者,其次是实现者,其次标准制定者,最后才是理论上的完满。

理论上的完满,大致是指尽可能创建出最完美的格式。标准制定者,指的是工作组、W3C,等等。实现者,指的是浏览器厂商。作者,就是我们这些开发人员,对吧?看看我们在这个链条里面的位置多靠上啊!我们的地位仅次于最终用户——事情本来就该这个样子。用户是第一位的。而我们的声音在标准制定过程中也同样非常非常重要。

Hixie(即Ian Hickson, Acid2、Acid3的作者及维护者,HTML5、CSS 2.1规范的制定者)经常说,在有人建议了某个特性,而HTML5工作组为此争论不下时,如果有浏览器厂商说“我们不会支持这个特性,不会在我们的浏览器中实现这个特性”,那么这个特性就不会写进规范。因为即使是把特性写进规范,如果没有厂商实现,规范不过是一纸空文,对不对?实现者可以拒绝实现规范。

而根据最终用户优先的原理,我们在链条中的位置高于实现者,假如我们发现了规范中的某些地方有问题,我们想“这样规定我们不能同意,我们不支持实现这个特性”,那么就等于把相应的特性给否定了,规范里就得删除,因为我们的声音具有更高的权重。我觉得这样挺好!本质上是我们拥有了更大的发言权,对吧?我认为开发人员就应该拥有更多的发言权。

我觉得这应该是最重要的一条设计原理了,因为它承认了你的权利,无论是设计一种格式,还是设计软件,这条原理保证了你的发言权。而这条原理也正道出了事物运行的本质。难道还不够明显吗?用户的权利大于作者,作者的权利大于实现者,实现者的权利大于标准制定者。然而,反观其他规范,比如XHTML2,你就会发现完全相反的做法。把追求理论的完满放在第一位,而把用户——需要忍受严格错误处理带来的各种麻烦的用户——放在了链条的最底端。我并没有说这种做法就是错误的,但我认为这是一种完全不同的思维方式。

因此,我认为无论你做什么,不管是构建像HTML5这样的格式,还是构建一个网站,亦或一个内容管理系统,明确你的设计原理都至关重要。

软件,就像所有技术一样,具有天然的政治性。代码必然会反映作者的选择、偏见和期望。

下面我们讲一个例子。Drupal社区曾联系马克·博尔顿(Mark Boulton)和丽莎·雷贺特(Leisa Reichilt)设计Drupal的界面。他们计划遵循一些设计原理。为此,他们并没有纸上谈兵,而是经过了一段时间的思考和酝酿,提出指导将来工作的4个设计原理:

简化最常见的任务,让不常见的任务不至于太麻烦。

只为80%设计。

给内容创建者最大的权利。

默认设置智能化。

实际上,我在跟马克谈到这个问题时,马克说主要还是那两个,即“只为80%设计。给内容创建者最大的权利。”这就很不错了,至少它表明了立场,“我们认为内容创建者比这个项目中的任何人都重要。”在制定设计原理时,很多人花了很多时间都抓不住重点,因为他们想取悦所有人。关键在于我们不是要取悦所有人,而是要明确哪些人最重要。他们认为内容创建者是最重要的。

另一条设计原理,只为80%设计,其实是一条常见的设计原理,也是一种通用模式,即帕累托原理(Pareto principle)。

帕累托是意大利经济学家,他提出这个比例,80/20,说的是世界上20%的人口拥有80%的财富。这个比例又暗合了自然界各个领域的幂律分布现象。总之,无论你是编写软件,还是制造什么东西,都是一样的,即20%的努力可以触及80%的用例。最后20%的用例则需要付出80%甚至更多的努力。因此,有时候据此确定只为80%设计是很合理的,因为我们知道为此只要付出20%的努力即可。

再比如,微格式同样也利用了帕累托原理,只处理常见用例,而没有考虑少数情形。他们知道自己不会让所有人都满意;而他们的目标也不是让所有人都满意。他们遵循的设计原理很多,也都非常有价值,但最吸引人的莫过于下面这条了:

首先为人类设计,其次为机器设计。

同样,你我都会觉得这是一条再明显不过的道理,但现实中仍然有不少例子违反了这条原理:容易让机器理解(解析)比容易让用户理解更重要。

所以,我认为平常多看一看别人推崇的设计原理,有助于做好自己手头的工作。你可以把自己认为有道理的设计原理贴在墙上。当然,你可以维护一个URL,把自己认为有价值的设计原理分享出来,就像Mozilla基金会那样,对不对,以下是Mozilla的设计原理:

Internet作为一种公共资源,其运作效率取决于互通性(协议、数据格式、内容)、变革及全球范围内的协作。

基于透明社区的流程有助于增进协作、义务和信任。

我觉得像这样的设计原理都非常好。而有了设计原理,我认为才更有希望设计出真正有价值的产品。设计原理是Web发展背后的驱动力,也是通过HTML5反映出来的某种思维方式。我想,下面这条原理你绝对不会陌生:

大多数人的意见和运行的代码。

对不对?这句话经常在我脑际回响,它囊括了Web的真谛,触及了HTML5的灵魂。

也许我该把这条原理打印出来贴到办公室的墙上,让它时刻提醒我,这就是Web的设计原理:大多数人的意见和运行的代码。

我想,今天的演讲就到这里了。如果大家有什么想法可以在twitter上通过@adactio找到我。有时候我也会在自己的博客,adactio.com上写写有关这个主题的文章。最后,可能还要顺便给我自己做个广告,我刚出了一本书,希望大家关注。

非常感谢大家。

原文链接:http://www.cn-cuckoo.com/2010/10/21/the-design-of-html5-2151.html

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏進无尽的文章

如何利用动画效果来提升用户体验

动画效果会讲故事。但不是冗长和完整的故事,而是简单的故事,比如“嗨,你现在该看这里了”或者“哇,你的操作完全正确。”然而,动效的目的不是为了愉悦用户,而是为了帮...

894
来自专栏企鹅号快讯

详解百度echarts如何自定义地图板块,实现鼠标交互效果

声明:理工科的同志,语言组织能力差,轻喷 先吐槽一下,自从大数据流行起来过后,做开发的很多朋友都遇到了一个调侃的问题:为什么你们都那么喜欢研究地球。我只能说,没...

3558
来自专栏phodal

Mifa Design:一个服务于 Markdown 的设计体系

嗯,UI 框架,这已经不是一个很好的时代了。可对于 Design Systems 来说,这还是个不错的开始。 Material Design 是 Google ...

2096
来自专栏区块链技术开发与技术解决方案

区块链公司谈的硬分叉和软分叉是什么

编程术语中的“fork”是一个开源代码修改。通常,分叉代码与原始代码相似,但有重要的修改,并且两个“叉”舒适地共存。有时使用分支来测试流程,但使用加密货币时,它...

1082
来自专栏钱塘大数据

【数说】用python爬下6万共享单车数据,谈谈单车热潮中的城市

共享经济的浪潮席卷着各行各业,而出行行业是这股大潮中的主要分支。如今,在城市中随处可见共享单车的身影,给人们的生活出行带来了便利。相信大家总会遇到这样的窘境,在...

3285
来自专栏灯塔大数据

干货|用python抓取摩拜单车API数据并做可视化分析(源码)

在APP中能看到很多单车,但走到那里的时候,才发现车并不在那里。有些车不知道藏到了哪里;有些车或许是在高楼的后面,由于有GPS的误差而找不到了;有些车被放到了...

6027
来自专栏数据派THU

我是怎样爬下6万共享单车数据并进行分析的(附代码)

来源:钱塘大数据 本文长度为3297字,建议阅读7分钟 本文为你解答用Pyhon获取、分析单车数据的过程,并为你分析得出的结论。 共享经济的浪潮席卷着各行各业,...

46610
来自专栏大数据挖掘DT机器学习

用python抓取摩拜单车API数据并做可视化分析(源码)

警告:此篇文章仅作为学习研究参考用途,请不要用于非法目的。 摩拜是最早进入成都的共享单车,每天我从地铁站下来的时候,在APP中能看到很多单车,但走到那里的时候...

2255
来自专栏互联网数据官iCDO

袭击GA数据的新型引荐垃圾

余霞,iCDO翻译志愿者 若你看到你的数据里有很多引荐流量,别惊讶,你只是其中的一个。本文的作者Jonathan Hochman将给我们解释那些引荐垃圾是怎么发...

2577
来自专栏腾讯Bugly的专栏

Android 手表应用开发设计规范 【译】

阅读提示:全文较长,预计阅读时间20分钟 image.png Android 手表设计规范 为可以穿戴的 Android 手表设计应用与为手机和平...

4637

扫码关注云+社区