cnbloggercon, Web, WebDev @ 16 November 2007, “1 Comment”

在Firefox上安装了支持微格式(Microformats)的扩展(Operator, Tail Export等)的,也许会注意到年会注册程序的页面上已经提供了hCalendar的支持。以下是在这些页面上使用几个扩展的截图。

下面是Tail Export在边栏里列出的年会议程页面页面上所有hCalender微格式,用户可以点击export图标把感兴趣的活动/议题加入到本地的程序比如Outlook, Mozilla Calendar项目的软件比如Thunderbird Lightning等。

cbc-uf-tail-export-uf-list

导入到Outlook里后:

outlook-2a

我个人更喜欢Operator这个扩展,因为它还能把微格式导入到在线的日历服务比如Google Calendar和Yahoo! Calendar,而且似乎对unicode支持比较好。以下是截图:

cbc-uf-operator-menu-options

导入到GCal里:

cbc-uf-operator-export-to-gcal

链接:更多关于微格式的截图

从这些页面和本地程序的数据交互,以及网页和网页之间的程序调用和数据交互,展示了语义网(Semantic Web),最基础的技术支持(HTML, MIME, HTTP)就能提供很好的在线和本地(尤其是移动终端, iphone, mobile firefox? mobile xulrunner?)集成以及更好的用户体验。

另:年会注册程序里除了hCalendar,年会页面当然也能提供hCard(个人信息)的微格式,但是在没有更好的隐私保护措施和共识之前,对hCard的支持目前还是没有开放出来。其它的格式比如FOAF,hReview,rel-tag, rel-license等的支持,会在将来陆续提供。

P.S. 有点遗憾,因为临时有事,没能来得及在年会开始之前做这个介绍。

Reading, WebDesign @ 23 September 2007, “3 Comments”

从卓越上订购的Prioritizing Web Usability的中文版到手两周,周末翻了一遍,非常失望。

这是本翻译过的书,所以要评价的话,得把原书内容和翻译编辑排版部分分开来说。

先说原书内容部分吧,

首先,大部分内容是非常基本的应该是大多数设计者甚至是程序员所了解的常识,比如字体颜色和背景的搭配要有一定的反差,不要有弹出窗口等。大部分在网络上已经有很多类似的可用性注意点的列表以及详细的讨论 - 它们是免费的。

其次,书里列出的网站的例子,说少也不少(有必要把这些网站的首页截图都打印在书上么?),但是绝对不能说是多,因为它们之中典型的类型并不多,大部分是商业机构厂家,web2.0以来在网页设计和使用上很有影响力的网站几乎看不到一个(注:这本书可是06年才再版的)。

自然,原书作者根本没有介绍或者讨论最近(宽恕我,我知道的,2005年在互联网上已经算不上“最近”了)的以AJAX为主的新的用户界面元素所带来的在可用性方面的影响(再注:这本书可是06年才再版的)。

再说说原书犯的错误和缺陷:

P162, 第六章,6.10,“从主页直接访问”一节关于Mozilla网站首页上的下载区域的评论: “…显然,该区域主要服务于那些想要适用于Windows英文版的人。…”,显然,作者没有明白该网站是根据用户浏览器发送的HTTP请求里的UserAgent以及Accept-Language头信息判断用户的操作系统以及语言设置来生成相应的页面,而想当然地认为是因为“主要服务于Windows英文版的人”(其实是因为作者用的是英文Windows而已)。

关于复杂的URL,“尽管复杂的URL对可用性和搜索引擎优化都有危害…”,很遗憾,没看到作者对于复杂的URL对可用性的危害的解释(至少连粘贴到email里的URL会被email软件断行导致收件人点击无效链接的问题都没提到)。相反,作者推荐了TinyURL这样的服务,却没有提到TinyURL对可用性的影响(比如用户无法从URL看到链接实际指向的地址)。

在关于选择字体的部分,没有提到可以使用CSS和Javascript让用户自己选择字体(至少是Serif还是Sans Serif)和大小,这在今天这样的技术已经很成熟的时候,居然丝毫不提,更不要说提及sIFR这样的手段了。

如果要放截图,没必要整个页面的截图都放进来,只要把相关的,说明问题的页面部分就可以了。一个例子:P72的占了半个页面的截图,说明相关问题的仅仅是右下角的“skip intro”的几个按钮,更不要说这张图片明显要比实际的原图大(图片边缘的锯齿)。

关于上面讲的P162的Mozilla的界面用了前后比对的两个页面,也是只需要把页面的相关部分抠下来,并排摆放,这样用户比较起来更明显更容易,可是,居然用了整页的截图,而且放在不同页面!又是一个毫无必要的浪费,以及其所导致的在可用性上的失败。

书里常常提及用户的“挫折感”,可是,没有看到有关于用户为什么会产生挫折感的深入和系统的讨论,关于这方面,还是推荐《Dont’ Make Me Think》这本经典。

再说说这本中文版:

原书名是Prioritizing Web Usability,中文名称:网站优化。关于这点,请编辑和译者自己读读第三章的3.1.7“浮夸的内容以及空洞的夸大宣传”以及第八章的8.3.2的标题:减轻夸大的宣传。

一本关于可用性的书最难的在于能在各方面要能“可用”,至少不与自己所“推销”的可用性原则产生矛盾。可是我却能在这本书里找到许多反例:

这本中文版没有索引!这是不是指望读者从头到尾就看一遍,还是希望读者将来为了找某个要点得再从头翻一遍?

书里有很多在正文外的文字框,这些文字框的标题栏背景有橘黄色,绿色,深蓝色,而文字背景有白色,绿色,和橘黄色,不同颜色代表什么意思呢,我以为在前言或者介绍部分应该有“如何阅读本书”的部分做对应的介绍,遗憾的是,没找到。仔细看看发现每个章节的小结标题都有不同的背景颜色,比如第一章的是浅蓝色,第二章是浅橘黄色,第三章是浅绿色……有必么?这不仅让读者阅读的时候产生混淆,也让书的成本增加,这都是毫无必要的。

页面排版,每页竖的两栏,跟报纸似的,这跟我们平时看书的习惯不一样(请编辑和译者自己再阅读一下第8章的“为什么用户会进行扫描式阅读”),而且往往中间插入一段横跨一页的说明文字,打破两栏文字的文字框,整个阅读过程必须不断避开跳过这些隔断正文的文字框,跟玩贪吃蛇一样。

总结我的意见:

  1. 如果用《连线》杂志常用的评价来描述原书给我的印象,那就是:TIRED and EXPIRED。
  2. 从其内容和内容质量来看,这标价89元的书太贵了,毫无必要的贵,不值得买。

如果你从来没有接触过关于网页/网站可用性的介绍和讨论,那么建议你去借一本来看,要是借不到,就在书店里花一两个小时先看看,实在觉得对自己有用那么再买。如果已经对可用性有一定了解,那么没必要看这本书了。

最后,我斗胆在这里做些建议:

  1. 《Don’t Make Me Think》
  2. 学习和掌握网页标准(Web Standards),近期一些关于CSS和Javascript的书里有很多对可用性的讨论;
  3. 网络资源:有很多网站提供可用性研究和讨论;
  4. 参与在线讨论(比如DeDream’的Google Group);
  5. 最重要的,多看看一些好的网站,多用些common sense;
WebDev @ 29 August 2007, “6 Comments”

减少DNS查找能够缩短页面反应时间,但是所有网站资源都只用一个域名,从而把DNS查找减少到一个,也不是最好的办法。不仅仅因为减少的平行下载的可能,更因为Web Cache对带与不带cookie的请求和返回的处理不同。

我的网站域名是www.yining.org,有个页面(比如就这篇blog entry)带有一张图片,其src为:/img/camel.gif,那么它的URL就是:”http://www.yining.org/img/camel.gif”。如果这个页面设置了cookie(比如为了记录留言者的ID和网站地址等),cookie的作用域名自动为www.yining.org,那么每次访问该页的时候,因为URL的域名部是www.yining.org,那么浏览器都会带着cookie对该图片发起请求,即使一路上的web cache有www.yining.org/img/camel.gif的记录,也依然要到我的服务器(the origin server),而不是从中间的web cache返回 – 因为带cookie的请求都可能根据不同cookie的值而返回不同的response。

但是这对许多静态资源(图片, css, 和javascript)来说不是最理想的,因为不论cookie是什么,它们的response里都是同样的内容,对它们的请求没有必要每次都回到origin server。其次,因为不同web cache对带cookie的请求支持不同,即使有的cache能够缓存带cookie的response,但是1)不是大多数的cache都能做到这点,2)大多数的cache都缺省缓存不带cookie的response。因此最好的办法就是使用不同的域名把静态资源隔离开。虽然cookie的path属性也能做到这点,但是毕竟限制太多,不如使用专门的域名灵活。

所以应该尽量把所有静态的对象和动态页面的域名分开,更严谨地说,是把不需要读写客户端cookie的服务器资源与需要读写cookie的程序分开到不同的域名。比如我可以设置另一个域名static.yining.org,在引用该图片的<img>里的src属性改为”http://static.yining.org/img/camel.gif”,那么当访问首页的时候,浏览器就不会带着cookie(因为作用的域名现在不一样了),这样就能更好地利用web cache缓存和服务器的性能。我请教过一位曾经在NetAppliance(最大的web cache厂商)工作的同学,据他说根据经验,带和不带cookie之间的差别有可能是20%甚至更大。

WebDev @ 01 August 2007, “1 Comment”

雅虎的YSlow插件的规则之一:Rule 9 – Reduce DNS Lookups提到:

Reducing the number of unique hostnames has the potential to reduce the amount of parallel downloading that takes place in the page. Avoiding DNS lookups cuts response times, but reducing parallel downloads may increase response times. My guideline is to split these components across at least two but no more than four hostnames. This results in a good compromise between reducing DNS lookups and allowing a high degree of parallel downloads.

说说自己的理解:

首先,一个页面所需要访问的域名数量为n,那么就需要n次DNS查找,而DNS查找通常是blocking call,就是说在得到结果之后才能继续,所以越多的DNS查找,反应速度就越慢;

其次,并行下载(parallel downloading)由两个因素决定:到服务器的连接数量,以及每个连接内部的流水线请求数量。

一个页面里到服务器的连接数量由两个因素决定:

  1. 页面所需访问的域名数量,和
  2. 浏览器所允许的最多连接数

后者在Mozilla/Firefox中还由浏览器所允许最多连接数(network.http.max-connections,缺省为24),和每个服务器所允许的最大连接数(network.http.max-connections-per-server,缺省为8)决定。如果max-connection-per-server是m,那么一个需要访问n个不同域名的主机的页面,最多可以有n*m个连接 - 前提是n*m小于max-connections的值;

每个连接内部的流水线请求(pipelined requests)的数量也是浏览器的参数(Firefox上由network.http.pipelining来设置,缺省为4),前提是服务器支持persistent connection(比如在Apache设置KeepAlive为On)。之前的例子就不需要那么多的连接了(对服务器和浏览器来说,一个连接里多个流水线请求能够比多个并行连接更好些),假设pipelining的值为p,那么就可以只使用n*m/p个连接了。(BTW,对Firefox做优化的一些插件其实就是对上面的几个设置做调整)

所以减少页面内不同hostname的数量不一定会减少并行下载的数量,也要看所需要的请求(css, javascript, 图片等)的数量,因此YSlow的解释说是potentially。

Remy Sharp wrote a web service to look up HTML Entity Character. The service “allows you to quickly find the entity based on how it looks”. There is also an OpenSearch plugin and MacOS Dashboard widget. Kudos to Remy!

I figured a Firefox extension clone would be handy, and it wouldn’t be too difficult to make one, thus:

This extenion is simple: a GUI wraps and calls the Javascript code Remy wrote (with a little modifiication, basically renaming global variables to make them unique) and then displays the result. The code is licensed under Creative Commons by-sa 2.5, same as Remy’s code.

It should work on Firefox from version 1.5 and above (have tested on 3.0aPre7 too), also on Netscape Navigator and Flock, let me know if you have any problem using it.

To try out, go to the extension’s home page and click install (it’s currently hosted on my server, so you have to let Firefox allow download and install extension from my server).

I could have made the extension remotely invoke Remy’s web service, parse the return html and present the result, but it might not be a good option, because:

  1. I need it work while off-line (too much distraction online);
  2. HTML entities character set doesn’t change that often, what’s the last addition? € maybe?
  3. Overhead from network traffic and CPU cycles parsing html;
  4. Not really a reason though: I could later make use of the new Online and Offline Events and provide user the options;

Update (09/09/2008):
You should be able to have it run on Firefox 3.0.1 and above.

WebDev @ 26 July 2007, “2 Comments”

雅虎今天推出了YSlow插件(这名字不错:Why Slow? ),需要先装Firebug,YSlow其实是它的“插件”。YSlow从Firebug收集当前网页和该网页的访问信息后进行分析,如有必要则给出如何提高页面加载速度的建议,比如减少DNS查询,使用外部并压缩Javascript等。这些建议是根据13个提高网页速度的指导原则,其内容已经在Yahoo Developer Blog上系列连载了一段时间,最近更新速度快了很多几乎每天一篇(是为了配合YSlow的推出?)。除此外还有专门一本书:《High Performance Web Sites》,内容就是这个系列(多了一个关于Ajax的专题),应该有更深入的分析和解释(这本书是Rough Cut,所以有O’Reilly Safari帐号的可以先睹为快了)。

这个High Performance系列说明网站开发者(包括我自己)非常需要深入了解HTTP和HTML。对Java尤其尤其是J2EE程序员来说,不要只是build around the web, 而是build for the web。很多程序员(尤其是刚毕业的大学生)不在意HTTP的细节,从所谓的“企业级开发”的角度把HTTP请求仅仅当作作一种函数调用,导致能提高性能的所有HTTP的特性都被“抽象”掉了,也就不了解或者利用这些属性。比如,我常在面试的时候问:HTTP GET和POST的区别在哪里?大部分的回答只有参数大小和位置的不同。

YSlow上的指导原则里的内容还有些可以补充的(很多东西应该都放到那本书里去了吧),比如在High Performance Web Sites: Rule 13 – Configure ETags里,作者建议在Apache上把ETag关掉,实际上只需要告诉Apache不要用Inode信息生成ETag就可以。还有其他一些,回头写上来。这里这里,和这里也有很多非常好的建议。

另外要注意的是,网页速度跟网站性能是不同的概念,网页在浏览器上加载得快,并不能保证网站的性能就好,虽然二者之间有密切的关联。

P.S. 关于网站的延展性(scalability)和速度(performance),O’Reilly已经出了两本,另一本是《Building Scalable Web Sites》,都是雅虎员工写的,在这要赞一下雅虎对Web开发社区的贡献。

昨晚下载了Apple最新的浏览器Safari的Windows版,试了一下,可能是习惯了Firefox,感觉一般,而且中文显示还有问题(也许是我没设置好)。但用是肯定会用的,因为现在不用专门找台Mac或者跑虚拟机来测试网页在Safari上的显示效果了,这算最大最直接的好处了,赞一下。

又搜索了解了一下,发现Safari:

  1. 像Firefox有扩展一样,有自己的plugin平台,PimpMySafar是专门收集和推广Safari plugins的网站;
  2. 像Firefox基于Gecko一样,基于开源的引擎Webkit,btw, Windows上也有个基于Webkit的开源的浏览器Swift(在中文显示上似乎比这Windows版的Safari还糟糕);

但是Safari有Firefox完全没有的优势:iPhone。据说iPhone上的开发将是Web application,而不是提供运行iPhone的MacOS的本地的SDK/API,如果真是这样(也许Jobs过几个月又会改主意),那么Apple的用意也很明白了:利用iPhone的Cool Factor(就像MacBook一样),吸引更多的开发者开发基于iPhone的Safari的plugin,让Safari成为一个平台(嘿,关于这方面针对Firefox我曾经写过类似的)。而这些plugins也会在MacOS和Windows上运行,从而建立起Mac之外Apple的更大的开发者社区和Safari生态圈,像曾经的微软一样,Embrace and Extend。

接下来会怎么样?

Safari的Plugin会像Firefox扩展一样甚至更容易开发么?会不会有软件能移植或者部分转换扩展到Plugin?Firefox的扩展界面是XUL,也就是XML,XML是可以(即使不容易)转换(通过XSLT)的……

业界的开放标准会因此得到推动么?iPhone肯定要存储地址簿和日历的,那么读取和存储页面上的Microformats比如hCard和hCalendar的plugin肯定会有的(如果不是已经集成在Safari之内)……

出版商如O’Reilly会出版Safari Hacks,Safari Cookbook,Safari For Firefox Developer,Manning出版Safari In Action?Apress出版Beginner/Professional Safari?;-)

当然,就算这个策略不成功,Apple也还有像微软提供Windows CEMobile的SDK一样提供iPhone SDK的选择。

如果不能在iPhone上开发,那花那么多钱买iPhone,跟作Apple的凯子有啥区别?:-P

UPDATE: 在O’Reilly Radar上看到这篇XULRunner for the iPhone,Marc Hedlund说:

I suspect that the real and right desire is to connect all of the capabilities of the iPhone to the Internet.

仅仅是Web页面是不能充分做到这点的,只有能够跟iPhone本地结合,才能做到这点,增加更多iPhone的价值,激发更多的想象力,这在Firefox上已经被扩展机制证明了。