心弦

Aero Taskforce网站的目的是“Find, publish and rate user experience quirks in Windows Vista”。网站上线后，创建者根据用户反馈，迅速推出了针对Mac OS X的AQUA的版本－Aqua Taskforce。

这两个网站都把所有的问题划分为Aesthetics、Annoyance、Bug、Icons、Legacy和Usability等类目。而问题的状态，则包括Not fixed、Under review、Will fix、rejected和Fixed。如果你想一下这个网站所在的立场和角度，会觉得这些状态很有趣，希望终有一天，一向自闭的Apple可以接纳这一网站所做的努力，并做出反馈。

因为明早要去金陵东路的达民琴行，可又不熟悉那边的地形，于是想着先在Google Map上搜索一下，看看这个琴行在地图上的具体位置，然后再用Treo 650手机上的Busline或者口碑什么的，查查有什么公交车可以到。

输入了“金陵东路318号”后，Google帮我准确地找到了位置（天知道它是怎么知道每一个门牌号的）。按照以往的习惯我该换工具了。此时忽然想起来Google好像刚推出了公交搜索，索性试试看。

点了地图上的“前往此处”后，我面对输入框，正经犹豫了一下：我是该输入小区名称呢，还是道路名称加门牌号呢？实际上，我只知道前者。抱着试试看的心理，我输入了我所在的小区名称。结果让我小惊喜了一下－Google知道我在哪儿。

明确了出发地点后，Google Map的界面让我有点搞不明白了：我想要的是公交线路，可它好像显示的是自驾车线路（虽然这看起来像GPS导航一样酷）。公交线路在哪里？

仔细看了几秒钟，发现了那个“公共交通路线”的链接。老实说，这里的设计可不怎么样，那两个链接实际上是标签的意思，可从视觉表现上完全看不出来。

点了“公共交通路线”以后，我的乖乖！新版的Google Map完全超出了我的期望！它不仅告诉我乘车的班次和路线，还把方向和里程显示出来，更夸张的是，它居然知道“浙江中路”站下车后要步行多少米到达目的地！

查找公交线路从来没有如此方便省心过，真的是太爽了。

不过在UI设计上，可能我还是不太习惯Google的设计理念，总感觉它的操作方式自成一体，却又不太容易理解。当然瑕不掩瑜，这已经是一款让人感到惊喜的产品了！

看看这位老兄是怎么拆开新买的三星手机的包装的：

早上在地铁站，居然遇到了杭州天籁琴行的李乐老师。李老师琴艺精湛，在杭州乃至全国都小有名气。不过人很随和、朴实。

我也算是他徒弟的徒弟了－在杭州时和他爱人学过不到一年的琴，可惜我比较笨，水平还是停留在初学中的初学，呵呵。

我一直比较在意页面的性能和编码质量，有时候会通过HTML代码的质量来判断一个网站的技术水平。

易趣、eBay和淘宝在网页性能和前端编码质量上的简单对比

昨天下午闲来无事，去久违的易趣转了转，发现他们的浏览器兼容性还是一如既往地好。可看看“我的易趣”页面的源代码，就觉得有点头大－不仅HTML/CSS/JS全部都混杂在一起，而且代码显得非常凌乱，还大量使用了表格来定位。当我把CSS禁用掉，再把浏览器窗口调到320像素这么宽后，网页已经基本无法阅读了。

下图是其YSlow得分，老实说，37分并不是个理想的成绩。对于这样大规模的网站来说，如何通过规范来保证多人协作编码时的质量，以提升工作效率、减少沟通成本，并且给网站提速减负，是个重要且紧急的问题。

易趣的表现让我对eBay很好奇－看看高手云集的eBay情况如何。

结果令人惊讶（如下图），“My eBay”的YSlow得分居然高达97！只有一项因为没有加Expires header而得了B，此外全部是A。这恐怕是我见过的最高的YSlow得分了。

但是这个页面的编码质量并不如想象中的好，问题和“我的易趣”页面如出一辙。强调可访问性（accessibility）的508法案似乎被eBay完全忽视掉了。

不过值得一提的是，eBay的js写得非常强悍，单从函数的命名就可见一斑了。

接下来我又测试了一下“我的淘宝”，淘宝的代码明显漂亮了很多。它的YSlow得分为39（如下图），

从上图来看，淘宝丢分主要在1）过多的引入外部资源，比如18个js和16次DNS查询；2）Apache和CDN的设置（其实根源在各种广告提供商，10个没有经gzip压缩的js里面有9个都是广告相关的）。

替前端鸣冤

有很多人不理解为什么在拥有众多高手的大型互联网站，页面的代码还能如此之乱。难道这些前端开发不知道W3C，不知道js要做到无侵入（unintrusive）么？

当然不是，其实这里面的原因挺多的，也不是一两句话能讲的清楚。在所有的原因中，以下两条可能是最关键的：

1. 缺乏规范，或者具备规范，但缺少强有力的执行机制。在前端打交道最多的三种语言中，只有Javascript算是程序语言，HTML和CSS根本就是描述性的语言。最让人头疼的是，它们远不象具有很多相同特点的XML那么严谨，自身的描述能力又不强，所以几乎不可能写出类似Java那样规范的代码来。程序语言中常用的框架，到了HTML和CSS这里也起不到作用，甚至它们两个根本就产生不了框架（那些所谓的CSS框架，在能力上和真正的程序框架差的太远了，我觉得顶多算是CSS模式[Pattern]）。要部分解决这个问题，我提倡用真正的程序语言，比如Velocity/PHP/Ruby等对HTML进行二次封装，实际上本站上面的很多东西就是靠helper（助手，MVC中View的一个组成部分，可以理解成帮助页面显示的一些程序）渲染出来的；
2. 系统逻辑太复杂，以至于顺利完成工作都变成了一个不小的挑战，更别说还管什么性能和质量了。写到这里想起曾经写过的一个control（控件，MVC中View的一个组成部分，可以理解成页面上的一个复用的元素），在当时紧张的时间里，control里面的代码质量已经算是不错的了（跟我搭档的几个Java程序员这么认为，其实我觉得一般，不过确实没时间写得更好了），可仍没办法做到把HTML、Javascript和Velocity代码完全分开，因为判断的逻辑太多太复杂。以至于在浏览器中看到的东西，比如一个小小的下拉菜单，它背后所隐藏的东西可能超乎想象。