2006年05月04日

Technorati终于被关在门外了。如月光所说,www.technorati.com这个关键字已经被完全屏蔽。关键字屏蔽意味着不仅不能登陆这个网址,就连在google上搜索这个url都不可以。试了google和icerocket,搜索的结果都是“无法显示网页”而且在一段时间内无法再次访问www.google.com和blogs.icerocket.com。

转到正题,technorati的倒下必然给其他同类搜索引擎带来机遇,比如icerocket。这和当年Google与Baidu的情形有点像。所谓“山中无老虎,猴子来称王”,现在正是搞Blog垂直搜索的大好时机。下一个被人们接受的Blog search engine不知会是哪一个,icerocket?还是另有其人?

2006年05月03日

Google与微软的战争终于要全面展开了。早上读了keso《东拉西扯:默认的力量》,颇有些感触。

 

首先,我已经见过太多文章对用户或者大众进行含蓄的贬低了,keso文中所引用的那句“伟大的无知者”可算是比较温和的一句了。大众作为参与者,在有些时候确实无法发挥个人的那种理性思维,而且力量其又远远大于个人,所以那些有大众参与的活动,常常会出现不理智且波澜壮阔的一边倒现象,最明显莫过于股市。但是在选择服务,选择产品这个问题上,如果厂商仅仅把大众看成一个“无知”的群体,那他们的覆灭也就为期不远了。在选择服务的时候,大众作为一个群体反而能摒弃个人所拥有的好恶、崇拜、鄙视等等感情,大众需要的只是一个便捷、实惠的服务或者产品。在Google VS 微软这场斗争里,如果Google和MSN search之间没有明显的、质的差别,那么谁能把自己的服务送到用户的门前,谁就更有希望赢。在这种情况下,大众不会再关心这个公司的文化、理念甚至产品质量,他们所关心的只是鼠标指针要滑多远才能滑到这个商品上。大众是最现实的。

 

其次,总是拿微软的垄断来做文章也没什么意思。Google联手Firefox,与微软把MSN search集成进IE 7在本质上是一样的,都是要把自己的产品送到客户端。所不同的就是IE的市场份额比FF大的多,其影响自然也大的多。而且微软也表明了有权更换默认搜索的。虽然Keso指出了用户可能根本不会行使这个权利,但我认为这恰恰说明了客户需要的并不一定是某一个搜索引擎,他们需要的是一个能在客户端使用的便捷的搜索服务,而集成的MSN search足以满足他们。

 

Google现在占据着IT世界中最肥沃的一片土地,而微软则掌握着通向这片土地的道路,两强相争,必定精彩。

2006年04月29日

前一阵子一直在研究Ajax和Prototype库,有点感触,正好又看到国外的一篇blog(2005年的……),就翻了一下,希望对那些正在用或者考虑使用Ajax的同仁们有点帮助,少走一些弯路。

    这篇文章写的是Ajax设计中的10个常见错误。

 

 

1.  在点击部件后不即时提供视觉线索

如果我点击的某个部件会引发Ajax行为,那你最好给我一点视觉线索让我知道有些工作正在进行中。一个例子就是Gmail右上角的loading button:当我在Gmail里做了什么之后,右上方的红色小方块就会显示网页正在读取,以此来补足在网页读取时Ajax不会引发正常的网页UI变化(注:应该是只诸如ie右上角飘动的旗子那类UI部件)

 

 

2.  破坏了“后退”按钮

在标准网站用户界面中(注:应该值的还是浏览器),“后退”按钮是一个很有用的功能。不幸的是,后退按钮和Javascript不能很好的配合。保持“后退”按钮的功能正是不采用纯Javascript网络应用程序的一个主要理由。

 

 

3.  用链接来改变状态(Get请求)

正如我在以前的帖子里提到的,Ajax应用程序为那些认为GET操作不改变状态(注:服务器状态)的用户带来了很多问题。改变状态的链接不仅仅给(注:搜索引擎)的机器人带来了许多问题,还使那些习惯于链接驱动的浏览的用户在面对改变状态的链接时变得困惑。

 

 

4.  出乎意料的闪烁或改动网页的某些部分

Ajax中的第一个A代表了Asynchronous-不同步。不同步信息的问题是当它们出乎用户意料地弹出时,这些信息将使用户非常困惑。网页的不同步改变应该只限于有限的被定义区域,而且应该被明智地使用;那些在我并不想注意的地方出现的闪动的信息使我回想起那段使用HTML blink tag的日子。

 

 

5.  不使用能被我发送给朋友或是加紧书签的链接

网站的另一个很好的功能就是我可以把URL发送给别人,使他们可以看到我正在看的东西。我还可以把网站首页加进我的标签,以后再回来浏览。Javascript,或者进一步Ajax应用程序,可能会给这种使用方式带来很多问题。由于是Javascript在动态生成网页而不是服务器,URL就被从这个过程中剥离了,也不能再用来作为浏览的索引了。失去这个功能是很不幸的,这也正是很多Ajax网站中特别设立永久链接的原因。

 

 

6.  过多的程序代码造成浏览器变慢

Ajax带来了一种制造更加有趣的javascipt应用程序的方法,但不幸的是,有趣通常意味着更多的程序代码正在运行。更多的代码运行给浏览器带来了更多的工作,这意味着对于一些大量使用javascript的网站,特别是程序编的不太好的那些,你需要一个强大的CPU来保证功能可以迅速地运行。事实上,CPU的问题以前确实是javascript功能的一个限制,仅仅因为现在的电脑快了很多并不表示这个问题已经不存在了。

 

 

7.  发明新的用户界面惯例

使用Ajax常犯的一个重大错误是:“点击这个不明显的东西来获得另一个不明显的结果”。当然,用户在使用一个网站一段时间以后可能会意识到如果在这个div上点击并且拖拽的话,他们可以把它移到另外一个位置,但是由于这不是一个常规的用户体验,你还是增加了学习你的网页所需的时间和难度,这对任何一个应用程序来说都是负面的。

 

 

8.  局部的改变不能影响网页的其它部分

由于Ajax/Javascript给了你对网页内容的特殊控制,你会很容易变得对某个部分过度专注以至于丧失了大局观。这方面的一个例子就是Backpackit的标题。如果你改变了一个Backpackit的网页标题,他们会立刻替换掉旧标题,并且会记住改变右边的标题,但是他们确不该变HTML Head中的标题(注:这段翻译的有点模糊,有兴趣的可以参考一下那个网站)。在使用Ajax时,你需要估计到全局即使改变只是局部的。

 

 

9.  不同步地进行批处理

有了Ajax你可以使很多对表单输入的改变立刻生效,但那可能会造成很多麻烦。比如当我勾选了很多会异步发送信息到服务器的check box时,我将会丧失对checkbox整体状态改变的明晰,而且那些涌现出来的checkbox改变提示也会很讨厌并且分散注意力。

 

 

10. 页面滚到造成难以定位

在一个网页中弹出文本会造成的另一个问题是这些文本可能导致页面滚动。我可能正在开心地读着某篇文章或者在一个超常的列表中查找信息,而这时异步javascript请求决定把一个位置位于远远高于我的阅读位置的段落删掉,因此打断了我的阅读。这绝对是令人反感的,而且还会我还要浪费时间来重新定位。

 

 

 

 

对原文有兴趣的朋友可以看这里。还有另外一个关于Ajax应用误区的网站,也值得Ajax开发人员关注一下。

2006年04月14日

昨天网上最热的新闻:Google成了“谷歌”。据我观察,大部分人对此名称持不屑态度,小部分持不置可否态度。赞赏的,基本没有。不过,keso提到了在发布会上众人对此名号还是“赞不绝口”的,虽然有些人把门口的IE首页设成了百度……

 

 

 

    谷歌这个名字据说是“山谷之歌”的意思。很空灵的一个名字。如果是一位民族歌手的艺名,那么他/她可能已经铺垫好了家喻户晓的基础。但是这个名字用在Google身上,只“空”不“灵”。

 

 

 

    就像我置疑百度时会用Google来支持自己一样,这次数落“谷歌”也不能不拿百度来说说事。Google在中国与百度的竞争中略负一酬的原因是众所周知的,除了那些不便言传的,最大的原因可能就是对于中文的“理解”问题。百度来源于“众里寻她千百度”,这个“寻”正好呼应百度的搜索业务(当然, “百度”某种程度上也暗示了“找一百次也不一定找得着”,还是需要“蓦然回首”的)。反过来再看“谷歌”,实在看不出和搜索有甚关系。在名字的选择上,Google又败了一酬。

 

 

 

    当然了,这Google本就是个舶来品,取个名字不一定要多有意义,只要读音上接近就好了。但就算这样,“谷歌”实在也算不上是一个“称职”的音译。那么Google为什么要选如此一个中文名呢?在我看来原因如下:

1.  Keso说28%的人曾经叫Google“狗狗”。可惜,这名字现在已经名花有主了。

2.  其次,还有13%的人称“Google”为“古狗”。这名子现在也不好用了,因为已经有了“搜狗”了。而且“搜狗”还真的去搜索狗来做代言了。要是Google真叫了古狗,难道要去找一只老狗来代言?

3.  其他的音译。Google乍一听像是“股沟”。这个更没法用,谁知到是腹股沟还是p股沟……

 

 

 

所以我觉得Google不是不想取个响亮的名字,而是受其英文名所累而选不到好的名字。

 

 

 

写到最后忽然对Google的中文名有了点想法。Google本身就是个数学家自创的词,代表了1后边跟100个0这个数,基本上就是非常大的数,那么它的中文名为什么不再从这个意思上入手呢?叫个“无穷”之类的不是更好。要不从音译入手,“顾”这个字是个不错的选择,至少有“看”的意思,引申一下也能有点“寻找”的以为。最不济就估个“估够”,取其意于“不管你搜什么,第一页的结果估计就够你用的了!”

2006年04月13日

应朋友要求做个简短的调查,各位看客要是有空就回一句“yes”或“no”。谢谢了!

------------------------------------------------

在您的经济条件允许的情况下,你是否愿意通过中介的服务去国外的医院进行疑难杂症的治疗?如果您愿意,您希望为此付出的费用是多少?

2006年04月08日

    故事发生在不远的未来……

    有人的地方就有网络,网络之上,则有江湖。

    自从CERN的Tim Berners-Lee在一九八九年编出网络江湖英雄录-World Wide Web,这世间便再无宁日。经过十几年的风雨,十几年的纷争,江湖中终于呈现出三家鼎立的局面,这就是人们口中的“江湖三世家”:

    -人称Microsoft的微家。这微家乃是江湖第一世家,家主姓比名尔门,本是专门给人纳鞋底的一名鞋匠。人在江湖漂,哪能不穿鞋?这微软家就靠着纳鞋底(也叫操作系统,operating system)敛得无数财宝,更在机缘巧合下练成绝食兵器-视窗(江湖人口中的windows)。自此,微软家便拥有了两大绝世神功:纳鞋底,打补丁(patch)。

    -人称Amazon的亚家。亚家乃是江湖中最为诡异的一批人。其家人多以卖书为生,但是暗中却掌握着令江湖中人闻风丧胆的“个人化自动推荐系统”(automated personalize recommendations)。寻常人等只要中了此系统,三炷香之内必定在亚马逊家的书店狂买打折书以至囊空兜破,钱尽人亡。

    -人称Google的古家。三大家中,古家的历史最短,但其却拥有天下最毒之虫-spider和人间至快之剑-pagerank。靠着这一虫一剑,古家一跃成为江湖第一名捕。但因其行事刚正不阿,江湖中人竟纷纷以被古家逮捕为荣。甚至有未被捕者大白天杀人越货只为求古家一捕(SEO)。

   

    话说两千零四年,曾经的江湖第一美女-信息的妹妹-定制信息,初入江湖。此女一入江湖便受到江湖中一种年青侠客的追捧,其间引发了无数刀光剑影、腥风血雨。三大家族的族长更是当仁不让,纷纷祭出杀手锏。古家最先发难,其家族子弟TiVo、Blogger、GMail、GoogleNews等于两千零六年练成当时江湖中最强的the Google Grid阵,并以此阵败敌无数。微家不甘示弱,于两千零七年铸成神兵-Newsbogster,以此应对古家的绝食奇阵。

    经过一年的僵持,古家暗使合纵连横之计,与三大家族中的亚家结成同盟,以the Google Grid阵搭配“个人化自动推荐系统”,奇阵奇功合而为一,人称Googlezon!

    微家此时已呈败像。终于两零一零年被Googlezon击败,从此与武林美女无缘……

    再说这Googlezon,在微家之后便已成为天下单磕无敌手,但其丝毫不为俗名所累,终于在两零一四年练成惊天地泣鬼神的EPIC-Evolving Personalized Information Construct,江湖中人皆俯首称臣。

    江湖自此一统。

 

―――――――――――――――――――――――――――――――――――――――

    以上内容系本人午夜梦呓。人称物称,如有雷同,纯属巧合。

    内容改编自媒体历史博物馆所出的短片《EPIC》 。英文对白见此

2006年03月28日
最近看donews IT业界的头版几乎每天都会有一篇关于Feed意义的讨论,可见诸君对Feed的狂热。忍不住,只好再说点自己的想法。
先列一下最近关于Feed的文章(按时间顺序排列):
1. Sayonly: feed意义大于blog
2. Keso: 东拉西扯:feed的意义大于网页
3. 熊川: FEED的意义没有那么大
4. 我自己的: 我看《feed的意义大于网页》
5. 陈体滇的: 网页和Feed的重要性可比吗
5. Sayonly: 如何避免feed的厄运降临
6. 旧烟斗的: blog的意义不小于feed,blog的意义大于网页
7. vazi: 中国互联网业界对Feed的理解
其中Vazi提到了Niall Kennedy的《Feeds as a platform》,不错的文章。
所有这些文章里都提到了Feed与网页的比较(严紧地说是和HTML比较)。Feed和HTML同样作为信息的载体、格式,其重要性自然而然地由其可承载的信息的多样性、交互性、广泛性。HTML经过N年的发展,现在可说是“百足之虫,死而不僵”,Feed作为新兴的事物,其所能表现的资源目前主要还是集中在文字和图片,其交互性可说是完全没有,故现阶段仍不及HTML。
不过长远来看,Feed所基于的XML比HTML具有先天的优点,比如更加系统、严谨、数据表现分离等。而在这个强壮的基础上,实现HTML目前独有的功能只是时间问题。根据一月二十四号发布的Atom Syndication Format Link Extensions所公布的内容,Atom将利用Link Extension(标签的le属性)来支持对MD5验证、实体标签、实体最后修改时间、文件采样范围、媒介、链接组及镜像连接等等功能,从而大大丰富了Atom可以链接的资源并且增加了Atom大规模发布的可行性,比如:利用le:follow来决定那些实体文件是需要自动下载而哪些是不需要的,从而缓解了Feed信息发布者,特别是多媒体发布者如Podcaster,在拥有众多订阅者时所面临的带宽瓶颈问题。
此外,Microsoft、Google和Newsgator也将陆续推出Feed platform,这将使Feed的重要性和受众范围得到一个跳跃。不得不说的一句话就是:什么东西有微软一搅和,成功的机会都会大一些。
虽然Feed具有很多优点并且拥有不断丰富的功能,其缺点也是显而易见的,如:
1. 缺乏交互性:我的文章里提到过这个问题。Feed现在保持单向的传播方式,这种方式比较像传统的电视,但这语互联网所崇拜的互动是背道而驰的。相信随着Feed科技和标准的不断完善,这个问题将会得到解决。
2. 带宽瓶颈:声音、图片、影像作为Feed内容的一部分,其受欢迎程度的提升大大造成了信息发布者的带宽瓶颈问题。由RSS/Feed阅读器发起的自动更新和下载为那些提供富媒体资源的发布人带来沉重的带宽压力。
3. 缺乏过滤机制:对于大多数博客,可能一天只会更新一篇文章,而那些博客订阅者每次阅览Feed时却要同时浏览以前的旧信息。缺乏一种机制来过滤Feed内容并提供有条件下载,造成了极大的眼球资源浪费。
4. 缺少统一标准:这个也是一个我在以前文章里提到的问题。缺乏统一标准为解析器带来不必要的压力和浪费。
Feed并不完美,HTML也不是全无可取之处,两者孰优孰劣恐怕还要经过很长一段时间才能见分晓,但可以肯定的是,用户的体验将在这个过程中得到显著提升。这终归是件好事。
补充资料:
1. Windows RSS Platform
2. Google Reader Platform
3. NewGator API
特别感谢Vazi,从她/他(?)的blog里找到了很多好的资源。
2006年03月24日

Keso在东拉西扯里提到了feed相对网页以和blog的意义问题。起因是因为sayonly的那篇《feed意义大于blog》里提出了一个同名的命题。

 

依我来看,这个命题中所比较的对象不具有明显的可比性,至少在现阶段是这样。打个比方,feed好ADSL的Modem,而blog则好比我笔记本上的键盘+显示器。如果我使用电脑的目的是上网浏览的话,那么两者缺一不可,重要性不分轻重。Feed和blog的关系也如此。一个没有RSS Feed的Blog和一个纯静态HTML编成的个人主页有什么区别?而如果没有Blog,人们看见的只是一堆一堆基于XML的描绘性数据,即使你能用XSL生成显示,那么千篇一律的东西你不觉得厌烦吗?更加重要的是,RSS Feed现在只能提供单向的信息传输,即从信息发布者到信息订阅者。缺少订阅者的反馈功能造成的结果就是独立的RSS Feed只适用于那些单向传播方式,如新闻等。Blog在信息反馈和信息个性化显示上弥补了Feed的不足。

 

再说Feed和网页之间的关系。我赞同Keso所说的“将来的情况可能是,RSS Feed的意义大于网页”。这是因为Feed基于的XML比现有网页基于的HTML更加利于传播。XML利用严谨的书写格式、外连的显示方案完美地把数据和表示剥离开来,而HTML不可避免地将两者揉杂在一起。随着网站间数据交流地愈加频繁,XML相对于HTML的优势也就越明显。如果XML能够实现HTML中诸如表单的那些交互功能,那么XML+XSL这种组合取代HTML只是时间问题。

 

最后说说我对于扩充Feed意义的一些想法。首先,RSS Feed的标准必须统一,不能你搞你的RSS2.0,我搞我的Atom,即使能编出高度适应的解析程序,也不能否认这是一种浪费。其次,RSS Feed将变成双向交流标准。信息的发布可能会是RSS:Post,反馈则可能是RSS:Feedback,这在技术上是完全可行的,所需要的只是一个标准。

 

IT这个产业是建立在林林总总无数个标准和协议上的,其结果是标准的统一带来的影响很可能比技术上的突破更加有力度。RSS Feed现在需要的是一个至高无上的Authority。

2006年03月23日

前些日子申请了Google Page Creator,今天早晨终于被批准了,于是赶紧试用了一下。(这有一些Google Page Creator的介绍

登陆界面还是一贯的Google风光-清新爽洁不紧绷!

左边的框里写着:“我们今天不开门了”-典型的拒客户于门外嘛!不过没关系,email里写着“We haven’t opened up Google Page Creator to everybody yet, so you’ll see a message on our home page saying that accounts are unavailable — you can just ignore that.”,于是装作没看见直接登陆:

登陆进去就是Page Manager,最上边的是你的网页的地址,好像默认是以gmail的帐号作为地址前缀,没注意能不能改(我还把我的邮箱遮住了,结果被这个出卖了……)。中间是管理区,可以在这进行网页管理、创建、发布等等功能。右边的是用来上传文件的部件。

编辑一下我的主页看看:

左边是工具条,功能比较有限。上边也是工具条,还有个redo|undo功能,比较有意思,看来是要挑战桌面系统了。右上方可以选择网站的外观和布局。正中就是编辑区域,根据你选择的布局会出现几个红色虚线包围的框,基本上分成:主标题、复标题、左边导航栏、右边内容区。点击需要编辑的区域然后填入内容就成了。

来看看Google给提供的外观:

一共41种外观。第二行第三个就是我选择的。

再来是布局:

四种可选择的布局,感觉和msn space的有点像。我选了个最常见的(左边第二)。

发布后的网站大家可以参照http://crane.z.googlepages.com/ 。

总体试用感觉:简单易用,很适合初学者或者不想投太多精力到个人网站上的用户。不过简单也是一个缺点:生成的网站千篇一律。好像不能使用CSS,我找了半天也没找着,限制了网页的个性化。此外就是觉得-慢!输入文字、界面间切换都比较慢,不知道是我自己的电脑和网络有毛病还是怎么着。

对技术比较着迷的朋友们不妨申请一个试用一下;搞网页美工的就算了吧,比较受限制。希望以后能改的更Advanced-user friendly。

2006年03月22日

刚才看了安德的《一种“自然部落”的形成 //是不是也很SNS 》,脑子里突然有了个比较“诡异”的想法:安德在文章里所说的会员入会方式乍一看有点像Gmail的病毒式传播或者是一个典型的传销团伙的关系图,但是其中暗含的Network正符合自然界一切有生命的物质的繁衍方法:父生子,子生孙,孙又生子;子子孙孙,无穷馈也。

SNS(Social Network Software)是归根在人们的社会网络上一种软件或者应用。软件设计层的社会网络的概念和性质决定了软件的服务方向和功能。现阶段SNS大都是建立在“朋友”这个社交圈上的(比如Friendster),或者其他社会生活所产生的关系圈,比如工作(Linkist),但是从来没有一个SNS涉足人类社会最基础的Network-血缘氏族。

血缘氏族如果要抽象地表示起来,其实应该是安德所说的“自然部落”头上脚下时的情况,其形态将呈现树状结构。让我们先抛开技术问题来看这样的SNS:假如有一个网站,在这里你可以输入自己的信息,然后再输入自己的老婆(或老公)、父亲、母亲、爷爷、奶奶、外公、外婆、叔叔、阿姨、姑姑、舅舅等等等等你能想起来的亲属的名称,这样你等于把自己的家谱搬到了网上。现在,暂时称“你”为A;用户B,也可以用同样的方法把自己的族谱搬到这个网站。这时就会产生一种情况,就是A的家族树和B的家族树会有交点,也就是说A和B有可能是俗话中“八竿子打不着的亲戚”。通过这样的家族树交汇,A和B之间就建立了基于血亲的Social Network(或许交Blood Network更合适)。这样的交汇,将会随着用户的增多和用户所提供的家族树的高度、宽度的增加而呈现明显的上升。这个网站的终极形态则是-人类的家谱。

当然,上述情况是基于几个假设的:

1. 记忆力假设:假设用户提供的信息足够详细而且精确,足以建立家族树。

2. 全民参与假设:假设所有人都为用户,使家族树与家族树之间不会出现gap。

3. 区分人名假设:这是一个技术上的假设。假设网站能在技术上识别每一个家族树上的成员并使其保持唯一。这个技术首要解决的问题就是“重名问题”-很多人之间拥有过多的相同属性,比如名字、生日、籍贯等等。当然,这些属性的集合可以更好的区分个体,但是如果要精确区分每一个个体,需要多大的属性集合、包含哪些属性才能最有效,这是一个大问题。

上述假设中,如果假设3能被妥善解决,那么已经足以构建一个相当广大而且精确的Social Network。

关于这种Network的实际用途、价值等等我还在思考,但是隐患我倒是听说了一个:女朋友听了后问我,万一到时发现咱俩是亲戚怎么办……

(似乎现在最有可能从技术上实现这种network的就是Google,以后会不会出现一个Google Human Being?这个已经超出我目前的思考范围了,我目前还是在犹豫一个大问题:该不该把“情妇”或者“情人”这个身份作为家族树的一点呐? :D