HTML5技术

HTML5设计原理_HTML教程(9)

字号+ 作者:H5之家 来源:H5之家 2015-09-17 16:26 我要评论( )

上面的代码中包含了4个不同的层次。 1、如果浏览器支持video元素,也支持H264,没什么好说的,用第一个视频。 2、如果浏览器支持video元素,支持Ogg,那么用第二个视频。 3、如果浏览器不支持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)。

 

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

相关文章
网友点评