可用性有如此重要?October 8, 2010

请原谅我取了个如此有争议的标题,原文的标题是《浏览器不是什么》。我个人觉得作者有点脱离题目,但这并不影响其想要陈述的观点。

可用性 一直是我们前端争论的焦点之一。但仔细想想,我们是否值得为那些连见都没见到过的盲人阅读器或者那些自行禁用 JavaScript 的用户投入额外的、大量的开发成本去「满足」他们?

-- Split --

原文地址: http://blog.istvan-antal.ro/2010/10/what-is-not-a-browser/ 发声 。而后过了段时期,出现了能够同时使用扬声器和声卡的应用程序。

话说回来,现在是否还有人关心自己的机子上有无声卡吗?我想恐怕已经没有。甚至我觉得人们已经遗忘了机箱中的扬声器了。

例如,我从来没有见过某款游戏因为机子上没有声卡而自动关闭其声音--当然,如果我耳朵听不到那是另外回事情(老外的这个说法比较冷)。

说了那么多,上述故事和浏览器以及 JavaScript 的故事非常的相似。不同的是现在的开发人员,在开发应用的时候,仍然在考虑如果没有脚本支持的这一情况。

其实和当年的声卡普及情况差不多,JavaScript 发明于 1995 年(已经是 15 年前了)。当时其在浏览器中的份额不到 1%,而且当时的用户(甚至开发者)都认为这玩意是可有可无的。

我的观点是,每个 Web 应用程序应该能够尽可能的运行在不同环境中,但它并不说明无条件的迁就于某一情况,在任何情况下都表现一致。

例如,在浏览器没有 JavaScript 支持的情况下,新闻类站点仍然可以显示其主要内容(新闻),同时不保证那些依赖 JavaScript 的相册脚本,仍然还能正常工作。

我们现在称之为「浏览器」的应用程序必须为:它能理解 HTML、能使用 CSS 渲染页面、同时能驱动 JavaScript 脚本。某个应用程序只能够完成上述一项或者其中两项功能,那么这压根就无法称之为「浏览器」。

例如,搜索引擎理解 HTML(以及部分 CSS 防止作弊),我们只需要提供内容让其收录 -- 同时它不需要过多的了解 GUI 相关的设计。

从内容方面考虑,其实我只关心两件事物:搜索引擎和浏览器。首先,我第一步需要做的就是创建具有语义的 HTML(这对于 HTML 来说并不容易),然后再使用 CSS 排版并且使其支持现代浏览器,然后再使用 JavaScript 增加针对 IE 的 CSS 规则(很明显原作者非常讨厌 IE)。

我的上述工作流程有时候会收到指责,因为这样必须让老旧的浏览器具备 JavaScript 支持才能引入针对其自身的 CSS 规则。同时情况可能变得模棱两可,我真的不认为我们称之为「浏览器」的玩意竟然不支持 JavaScript,哪怕是那些可以称之为古董的玩意(暗指 IE 吗?)。

总而言之,我们的思路应该为未来而开发,而非迁就过去(We should develop for the future not for the past.)。

我们应该为大多数(用户)而非少数服务。如果我们的用户中有 0.1% 禁用了 JavaScript,那么在我看来,我们可能不值得去耗费大量的开发时间去争取那些 0.1% 的用户。

同时另一个事实是,如果我们让用户觉得在没有使用 JavaScript 的情况下也能使用我们的应用,那么他们会毫不犹豫的禁用它(类似 noscript 插件 )。那么这样,我们推进 Web 的前进几乎是不可能的,我们和用户都会认为 JavaScript 是额外的附属品。

最后,其实我想说明的是:在着手实际开发之前,我们首先规划那些有限的资源(例如时间、人力等)-- 它们的计划投入和实际产出是否能符合我们的预期。

-- EOF --

§ 28 条评论

  1. 走自己的路,让别人无路可走~

  2. noscript用的比较爽

  3. evan evan

    想想当年用 lynx links w3m 的日子吧

    1. 在我精简得连X都没有的移动硬盘的Arch Linux下,我只能用 w3m....

      什么时候,w3m 能支持 CSS 和 javascript?

  4. 那我们是否应该开始放弃迁就IE6了呢,针对国内目前的IE6占有率来说?我真的很想知道,这个垃圾玩意什么时候能消失。

  5. 当IE6的占有率小于1%时,可以不用考虑IE6了。

  6. 关于这个,Joel Spolsky的《软件随想录》就有精辟的论述。见第21章:关于战略问题的通信之六。

  7. >>我真的很想知道,这个垃圾玩意什么时候能消失。
    当你觉得用IE的用户都是垃圾用户的时候,这个玩意就能消失。

    如果你很看重使用IE的垃圾用户的话,这个玩意永远不会消失----除非有一天ms没了或intel不再生产x86系列cpu了。

    1. ware ware

      除非xp消失

      1. 其实也简单,MS一个升级补丁搞定;
        但也比较难,什么世界之窗、360还固守IE的内核

  8. 千吨泥 千吨泥

    "浏览器不是什么" 这句话有歧义,也有“浏览器不值得重视”的意思。

    应该翻译成—— 这货不是浏览器

  9. Lz 你写滴才是原文,感觉那E文是翻译你滴
    PS:可用性很重要^_^

  10. soda soda

    “我们的思路应该为未来而开发,而非迁就过去。”
    ”我们应该为大多数(用户)而非少数服务。“
    断章取义下,这两句话看起来本来就是难自圆其说的事情,况且问题重点不应该放在是否禁用javascript的讨论上。

  11. 其实可用性 还是挺重要的

  12. swingguy swingguy

    只能说我们的产品开发还没有达到更高的现代程度(如开发的产品真正关心残疾人、关心环保等)。我们要让优秀的现代浏览器具有卓越的体验,也要让落后的设备和终端有基本体验(能满足使用,而不会无法运行)。如果只考虑一种情况,未免过于简单。为少数人服务,是一种先进的表现,哪怕只有0.1%,你想想如果这0.1%是特殊人群,意义会有多大?技术上不难,关键是思路。思维决定了高度。不得不承认商业化利益让这种思路有点急功近利,该多考虑考虑社会效益,为更多大众服务。

  13. [...]来源:http://www.gracecode.com/archives/3035/[...]

  14. 看了多少谈可用性有多么多么重要的书,但实际项目中真的没有以此来实行。国内总能找到搪塞的理由,却不能真正地说出个严谨的观点。多一种观点总是好的。

    个人觉得可用性有那么重要,但不必为所有人群都提供十全十美的解决方案。网站支持落后的浏览器能让访问者走到最后,但路上的风景不必如现代浏览器那般精彩。

    有人测试国内的电子商务网站禁掉JS后没有一个能买到东西,而亚马逊却可以。需求总认为一个能把所有浏览器兼容,能把设计师出的页面在所有浏览器中都写的一模一样的技术最牛;其实能表现出差异性的才是真的牛。

    PS 上面是我的Trackbacks。

  15. “我们的思路应该为未来而开发,而非迁就过去。”这话太对了。。。

  16. 不要迁就过去。。。,不过保留似乎也没什么不可以啊,有电梯的年代,也要有个楼梯为好。

  17. lucifer lucifer

    国外对可用性是立法的

    在天朝,你的boss不在乎,你公司股东不在乎,everything is ok

    但是,我始终觉得实现可用性的过程,就是一个你思维的过程。
    从单纯的html表达语义(内容),到添加css实现布局和效果,到最后的js实现动态效果。一直是个progress enhancement的过程。
    这是国外前台的一个基本思路。

    国内,我看到很多公司都是做个prototype,让美工去设计下,然后按照设计开始搞代码。虽然最后长得界面还可以,但是代码质量,没法看。

    可用性其实不仅仅是客户对你的产品的可用性,也包括后续维护人员对你代码的可用性。

  18. 我的上述工作流程有时候会收到指责,因为这样必须让老旧的浏览器具备 javascript 支持才能引入针对其自身的 CSS 规则。同时情况可能变得模棱两可,我真的不认为我们称之为“浏览器”的玩意竟然不支持 javascript,哪怕是那些可以称之为古董的玩意(暗指 IE 吗?)

  19. [...]来源:http://www.gracecode.com/archives/3035/[...]

  20. [...]来源:http://www.gracecode.com/archives/3035/[...]

  21. [...]来源:http://www.gracecode.com/archives/3035/[...]

  22. [...]来源:http://www.gracecode.com/archives/3035/[...]

  23. [...]来源:http://www.gracecode.com/archives/3035/[...]

  24. [...]来源:http://www.gracecode.com/archives/3035/[...]

  25. [...]来源:http://www.gracecode.com/archives/3035/[...]

添加评论




* Required (but your email address will never be published)

Yahoo 统计