2009年4月11日星期六

豆瓣的『请勿联系我们』页面

如果说Don't Make Me Think的基本思想是让用户凭直觉都能找到他们需要的东西,那么豆瓣的联系我们页面就做了一个绝佳的例子,或者说是绝佳的反例,这视乎你怎么看这个问题。

联系豆瓣 - Mozilla Firefox (Build 2009032608)

联系我们

还是用Don't Make Me Think里面的比喻,在网站上寻找内容就如同在商店里寻找商品,最理想的情况自然是一抬头就看到导向牌说你想要的商品在哪一行的哪一个货架上。在这方面,豆瓣的联系我们页面是做得非常好的,通过清晰的分类说明了不同情况应该联系不同的邮件地址。就如同清晰的导向牌一样,你能够径直走到摆满你想要的商品的货架前。

接着搞笑的事情发生了,你发现这个货架其实是个锁上了的玻璃橱窗,上面有一个牌子写着『如需取商品,请找售货员』。这时候你会想,这不是一家便利店吗?还是有什么我理解错了?这就是豆瓣的联系我们页面给我的感觉,因为那些邮件地址不仅仅不可以点击,还刻意设计为图片使得不能够复制。

如果你跟我一样,习惯有什么想法直接点击网站的联系我们链接,你应该明白常见的联系我们页面是怎样的。网站往往为了保护邮件地址免受垃圾邮件骚扰而不会直接公开邮件地址,为此他们会设计一个专门的表单让你提交反馈信息并留下你的联系方式。随后如果你提交的信息确实有价值,网站会主动联系你,之后的通信就都可以在邮件里进行了。

这是用户对联系我们页面的印象,就如同对便利店的印象一样——自由地在货架前选取商品然后再去埋单。然而豆瓣选择了在便利店里放置锁上了的玻璃橱窗,这就会导致用户迷失方向,他们会想『这是一家便利店吗?还是说我走进了一家「珠宝便利店」?那算了,我就不买了,或者到附近的便利店买吧。』

帮助中心

这个联系我们页面上面,只有一个链接可点击(除去全局链接外),那就是帮助中心链接了。用户找不到熟悉的反馈表单,自然会凭直觉沿着链接点击下去,而这个链接是唯一的选择。进去之后仍然是一个清晰分类的页面,不过就是没有用户需要的反馈表单。或许用户会浏览一下分类列表,然后发现他要反馈的问题不能算是严格属于某个特定分类。这时候就如同顾客根据导向牌走进了唯一一行他认为正确的货架,但是货架上的分类标识他想要的东西不属于这里的任何一个货架。

这又是一个让用户感受挫折的地方,然而这还不是最后一个。如果用户坚信反馈表单存在,就如同顾客坚信这是每一家便利店都卖的东西一样,那么他们自然会继续找下去。在点击进入任何一个分类链接后,用户会看到又一个清晰的Q&A列表,然后他必须再一次经历同样的挫折,最后才在一个不显眼的地方找到他想要的东西,一个写着『没搞定?给管理员捎个话』的链接。

为什么说这个链接不显眼?因为特殊链接往往会放在页头、页脚或侧栏这类视觉上与内容分离开来的区域,而这个链接放在问题列表和解答列表之间的狭缝。这处的留白本应只用于表示两个列表互相对立的关系,在两个块区元素之间插入一个行内元素只会让人以为那也是分隔符的一部分而已。

小结

这就是为什么我说豆瓣的『联系我们』页面应该叫做『请勿联系我们』页面。它在向用户传达一种意思,那就是『我们豆瓣是刻意增加你联系我们的成本的,因为我们就是不欢迎你联系我们。』这就好比说,我们都知道每一家7-11都会在cashier前有一个放满了condom的架子,而豆瓣是一家和特别的7-11,它在那里放了一个牌子然后写上『我们就是不卖condom,你就不要找了,也不要问我们的售货员』。

2009年3月29日星期日

Microsoft MVP Global Summit 2009 (Part 2 - Sessions)

这次去参加MVP Summit,我计划主要是听ASP.NET 4.0及Silverlight 3有关的session,结果在Microsoft Campus的两天也就泡在MSCC,也就是往返于Hood和Rainier这两个room。这些内容之前一直都不能说,现在MIX09开完之后,大部分的内容我们都可以自由讨论了。

ASP.NET 4.0

ASP.NET 4.0方面,我最关注的是ASP.NET AJAX 4.0,不过Preview 4和Preview 3比起来没多少新增功能,我只能希望在Preview 3中存在的bug在Preview 4都修复了。在demo方面,DataView控件加上Live Binding确实非常cool,可以一个DataView做master另一个做details,在其中任何一处作出的修改立即同步到所有地方,包括对ADO.NET Data Service作出更新请求。不过demo始终就只是demo,现实中的场景总有一些更复杂更需要创意的地方。

此外,ASP.NET 4.0还包括ASP.NET MVC和Dynamic Data,前者终于发布了1.0,后者比最初我看到的第一个Preview已经要强大很多了,当然也换上了Entity Model这样的数据访问层组件。

Silverlight 3

我对Silverlight 3的关注原本只是很表面的,但却发现Silverlight 3的新增功能比ASP.NET 4.0要多得多,这意味着Microsoft对Silverlight的投入巨大吧,因此我也觉得有必要去好好研究Silverlight 3了。

Silverlight 3的突破是巨大的,假如我们都承认原来的Silverlight 2其实很弱的话。在工具方面,现在终于可以在Visual Studio 2010里面拖放编辑XAML了,而Expression Blend也支持C#编辑了,不再像过去的版本那样,Visual Studio和Blend各自只能完成一半的工作,必须在两个工具之间切换来切换去。

视频播放一直都是Silverlight非常重视的功能之一,Silverlight 3将会支持H.264,并把H.264/AAC/MP4作为标准的视频封装格式。如今有越来越多的设备支持H.264的硬件解码,而且Adobe与Apple的软件也广泛采用H.264作为高清视频的编码格式,所以将来我们无需再为编码格式的区别而烦恼了。

另外,Silverlight 3还引入了GPU硬件加速的支持,用于UIElement的合成与拉伸,同时支持浏览器内嵌模式与全屏模式。不过,如果你要让你的Silverlight 3应用支持GPU加速,还必须在浏览器插件及UIElement两个层面声明启用GPU加速,以保证其他内容不受此新功能引入的影响。

GPU硬件加速带来的是什么?当然是视觉上的新功能啦。过去Silverlight 2无法做梯形变换,所以也就做不了真正的Coverflow。现在Silverlight 3可以做Perspective 3D了,Coverflow也就能实现了。另外WPF拥有的Effects在Silverlight 3中也能用了,虽然Silverlight 3现在的Preview仅仅自带了两个Effects,但WPF自带的Effects甚至是第三方的Effects都可以导入到Silverlight 3中使用,因为它们都是用HLSL写的Pixel Shaders。

如果你对这些新功能感兴趣,我建议你去看看MIX 09的视频,里面涵盖了我所说到的所有内容。我准备接下来用Silverlight 3做一个Coverflow,如果你有兴趣了解这是怎么做的,欢迎订阅Cat in Chinese

2009年3月22日星期日

Microsoft MVP Global Summit 2009 (Part 1 - Trip & Food)

虽然MVP Summit发生在3月初,但由于我一直都很懒,所以现在才来写写文章。而且,很多MVP Summit上讨论的受NDA保护的内容,过了MIX09也就成为公开内容了,我也就可以在这里说说了。

今年买票的时候,竟然找不到第二个人跟我同行。上海的一群MVP,都为了省钱买了海航的机票,从上海飞到北京再直飞西雅图。我还是更愿意飞NWA,因为里程可以积累到我的南航帐号上,所以虽然票价贵一些,我还是选择了一个人飞NWA。直到起飞前两天,才确定上海的包包跑来北京了,因为面签时被check了拖到最后一刻才买票,结果就和我同机了。

飞到东京之后,有趣的事情发生了,我们见到了一群穿着校服的日本女生走进来候机室,登机之后其中一位就坐在我旁边。我在吃完机上第一餐之后,无所事事就开始找她聊天,问问她有没有用过Baidu.jp,然后说说去美国做什么,她说她其实是去Vancouver参加交流活动。因为飞机引擎噪声很大,我们又都不太懂对方的口音,所以我拿了一个小本子出来把英语写下来让她看。在她有不懂表达的意思时,她拿了一个电子词典出来用日文查对应的英文,不过有时候我看看其中的日文解释,上面的汉字也足够我理解了。这样的沟通挺有趣的。

到了Seattle之后,打车去Sheraton Seattle Hotel,然后还是和去年一样带着今年第一次来的MVP去海边走走,去Crab Pot吃蟹。我们要了便宜的snow crab和dungeon crab,没有选最贵的king crab,吃起来感觉还不错,不过snow crab实在是太小了。最后一天晚上也是在Crab Pot吃,就是吃king crab,但这其实不是我们吃过最好的king crab。

说到这里,就不得不重点推荐一下我们在Oceanaire Seafood Room吃的那一餐Alaska red king crab了。虽然这里的king crab要$45/pound,而Crab Pot的只要$22/pound,但是这里的king crab确实比较大,而且非常甜!如果你想要尝一尝king crab是有多么的好吃,那就一定要去Oceanaire Seafood Room点Alaska red king crab。一般来说,一个人吃1~2 pounds是没问题的,如果你不再点其他东西的话。面包是送的,但既然是专门来吃king crab的,当然就不再点其他东西了,甚至连面包都不吃。

Alaska Red king crab

美国人吃法比较奇怪的地方在于,他们用石头那么硬的面包来搭配甜美的king crab。不仅仅这样,他们还会上热好了的黄油,让你点king crab来吃。我试了一下,发现这一点都不好吃,原本爽口的蟹肉变得油油的,感觉很奇怪。

今年MVP Summit的开场中说到去年MVP Summit抱怨最厉害的事情,那就是salmon吃得太多了,每餐都有salmon,所以今年的口号是No Salmon。我自然很失望啦,Seattle作为一个salmon产量如此多的地方,我过来自然要吃salmon啊,怎么可以没salmon呢?结果后来几天真的很多人在Twitter上抱怨No Salmon,于是乎今年最大的抱怨也就正好与去年相反了。看来做如此大的一场活动,关于吃什么的问题真是众口难调哦。

有关MVP Summit旅行与饮食的话题就说到这里吧,如果你有兴趣了解我接下来要说的技术内容,欢迎订阅Cat in Chinese

2009年3月13日星期五

ASP.NET AJAX 4.0 Preview 3 (Part 2 - ASP.NET AJAX Template)

在上一篇文章里,我们说到了如何使用ADO.NET Data Service Client Library能够轻松访问到存在服务器端的数据,然而将数据展现出来仍需要人手拼接HTML这点就实在是让人难以接受,所以我们现在就来看看如何利用 ASP.NET AJAX Template解决这个问题。文章中所用到的示例代码,可以在这里下载:ASP.NET AJAX 4.0 Preview 3 Demo,然后参考里面的AspNetAjaxTemplateDemo.aspx。

Sys.UI.DataView

为了解决展示数据的问题,我们需要用到一个全新的客户端控件,那就是Sys.UI.DataView 了,简称DataView。我们会用DataView替换掉上一篇文章中所说到的人手拼接HTML的部分,用于迭代生成一个ul中的li元素,因此看起来是把DataView当作Repeater来用。实际上,DataView的功能类似于ListView加上DetailsView

如果你把一个Array绑定到DataView上,它会显示为一个ListView。与ListViewLayoutTemplate相类似的是,它也能够定义控件展示的整体布局,并且仅仅是迭代输出其中的一小部分。例如说,编写一个有thead的table,并且仅仅是迭代输出thead之后的tr。在这方面,是DataViewListView完全一致的。唯一不同的是,客户端暂时还没有DataPager这样的控件,所以DataView必须一次性的完整显示整个Array的数据。

如果你把单个Object绑定到DataView上,它就会显示为一个DetailsView。这使得你可以使用两个DetailsView就做出经典的Master-Details展示模式,和在服务器端分别用ListViewDetailsView做出来的一样。当然,你不能指望DataView能够好像DetailsView那样,自动帮你分析每一个数据项并映射出对应的HTML模板,因此HTML 模板还是要你自己手写的,但至少那是在HTML中编写模板,编写时能够享受IDE带来的各种好处,维护时也更容易看懂自己(或别人)原来写下的 HTML。

JavaScript语法

接下来,我们就要把DataView投入到实际应用中去了。首先,我们说一下如何用JavaScript来实例化一个DataView。有编写ASP.NET AJAX客户端代码经验的人对$create应该不会觉得陌生,因为DataView继承自Sys.UI.Control,我们仍然可以用$create来实例化它。不过,在此之前,我们先要把对应的 HTML编写好:

<ul id="itemTemplate" class="sysTemplate">
  <li>
    <span class="award">{{ Award }}</span>
    <span class="winner">{{ Winner }}</span>
    <span class="film">{{ Film }}</span>
  </li>
</ul>


然后我们就可以基于itemTemplate这个HTML元素创建控件了:

$create(Sys.UI.DataView, {
    dataSource: new Sys.Data.AdoDataSource(),
    serviceUri: "WebDataService.svc",
    query: "OscarWinners"
  }, {}, {}, $get("itemTemplate"));


现在,页面显示出来的结果和之前我们人手拼接HTML的版本完全一致,不过我们已经不在需要维护嵌入在JavaScript中的HTML代码了。

声明性语法

如果你觉得上面的做法还不够好,要在pageLoad()里面写一个$create,那么声明性语法可能正是你需要的。大家应该记得很久很久之前,在ASP.NET AJAX还叫做Atlas的时候,就已经有过声明性语法的设计,那就是xml-script。不知为何,后来Microsoft放弃了这一设计,现在声明性语法又回来了,而且设计得比以前的xml-script还要更好。假如不用$create的话,通过声明性语法实例化一个DataView仅需要这样做:

<body
  xmlns:sys="javascript:Sys"
  xmlns:dataView="javascript:Sys.UI.DataView"
  sys:activate="*">
  <ul id="itemTemplate" class="sysTemplate"
    sys:attach="dataView"
    dataView:datasource="{{ new Sys.Data.AdoNetDataSource() }}"
    dataView:serviceuri="WebDataService.svc"
    dataView:query="OscarWinners">
    <li>
      <span class="award">{{ Award }}</span>
      <span class="winner">{{ Winner }}</span>
      <span class="film">{{ Film }}</span>
    </li>
  </ul>
</body>


我们所需要更改的代码包括:
  1. 在body元素上声明有关的xmlns,将JavaScript中的名字空间映射到HTML上,或者你可以理解为映射到XML/XHTML上。
  2. 通过sys:activate="*"这个声明,让ASP.NET AJAX知道它需要去解释页面上所有的声明性语法,并激活对应的组件。
  3. 将原本使用$create初始化时传递给实例的属性、事件、引用改为用声明性语法,直接写在HTML元素的定义上。


经过这三步,我们就可以将原来使用$create创建的组件改为使用声明性语法创建了。

小结

DataView 使得我们能够使用HTML模板,来避免手工拼接HTML带来的种种问题,同时声明性语法让我们能够如同声明服务器端控件一样声明客户端组件。虽然在 ASP.NET AJAX 4.0 Preview 3中这些功能仍有小bug,例如我想用声明性语法创建我自己编写的InPlaceEditoBehavior,这在初始化阶段毫无问题,但却会在页面卸载销毁对象之时抛出脚本错误。

由于我觉得ASP.NET AJAX 4.0 Preview 4很快就要出来了,所以我也就不准备去深入研究Preview 3了,等Preview 4出来了再去好好看看源代码。如果你有兴趣关注这方面的技术文章,欢迎订阅我的博客,点击侧栏上的订阅链接就可以了。

ASP.NET AJAX 4.0 Preview 3 (Part 1 - ADO.NET Data Service Client Library)

自从Microsoft与jQuery合作以来,ASP.NET AJAX与jQuery就被定位为两个互补的AJAX库。既然jQuery已经实现了如此多轻量级的AJAX特性,自然ASP.NET AJAX会继续专注于富客户端所需的一些重量级特性。

在ASP.NET AJAX 4.0 Preview 3里面,开发人员能够接触到的两个重要的新特性就是ADO.NET Data Service Client Library以及ASP.NET AJAX Template。对于熟悉ASP.NET服务器端开发但不熟悉客户端开发的人来说,你可以简单地把这两个特性理解为存在于客户端的DataSource 以及ListView,只要把数据通过ADO.NET Data Service输出到前端,你就可以如同使用DataSource和ListView的组合一样在客户端开发数据驱动的应用程序了。

在这篇文章里,我们将来看看如何使用ADO.NET Data Service Client Library,将ADO.NET Data Service暴露的REST数据接口直接拿到客户端JavaScript代码中去调用。文章中所用到的示例代码,可以在这里下载:ASP.NET AJAX 4.0 Preview 3 Demo,然后参考里面的AdoNetDataServiceDemo.aspx。

服务器端准备工作

在我们接下来要讲到的示例当中,我们会用到一个SQL Server 2005 Express Edition的数据库,里面有一张名为OscarWinners的表,记录的是本年度奥斯卡获奖名单,字段包括AwardID、Award、 Winner、Film。然后我们为这张表创建ADO.NET Entity Model,接着再为它生成的实体类创建ADO.NET Data Service。这些都是在Visual Studio 2008中点几下鼠标就能完成的操作,就不再详细解释了。在ADO.NET Data Service的InitializeService()方法内,我们仅仅给它提供一个最宽松的规则:

config.SetEntitySetAccessRule("*", EntitySetRights.All);

到这里,我们就把服务器端的要做的工作都准备好了。打开你创建的ADO.NET Data Service地址,看看是否输出了正确的Atom格式数据。如果没有,请检查一下你机器上的WCF是否已经正确安装和配置好了。确保服务器端的准备工作都做好了,然后再进入客户端的开发工作。

连接Data Service

在客户端使用ADO.NET Data Service,我们需要接触到的类只有一个,那就是Sys.Data.AdoNetServiceProxy。首先,我们要连接到ADO.NET Data Service,也就是使用ADO.NET Data Service的URL来实例化此类:

var dataService = new Sys.Data.AdoNetServiceProxy("WebDataService.svc");

然后,我们就可以利用dataService来调用ADO.NET Data Service进行CRUD操作了。

CRUD操作

所有的CRUD操作都在Sys.Data.AdoNetServiceProxy对象上执行,方法分别名为query()insert()update()remove()。在我们的示例当中,会用到query()update()方法,另外两个方法是用起来和update()很类似,就不再详细说明了。
查询操作
dataService.query("OscarWinners", function(result, context, operation) {
  /* display result */
}, errorHandler);


使用上述语句,我们查询出了OscarWinners表中的所有数据。随后的第一个回调函数会在查询成功时被调用,因此我们可以在其中编写拼接HTML以显示结果的逻辑,具体的代码请参考下载中的AdoNetDataServiceDemo.aspx。第二个回调函数会在查询失败时被调用,我们可以编写一个统一的错误处理函数,名为errorHandler,然后将它传递给此参数。

如果需要传递复杂的查询参数,使用ADO.NET Data Service的格式就可以了,这可以在MSDN上查到。例如说查询Slumdog Millionaire这部电影夺取了多少个奥斯卡奖项,然后把奖项按照名称排序输出,可以这样子写:

dataService.query("OscarWinners?$filter=Film eq 'Slumdog Millionaire'&$orderby=Award", function(result, context, operation) {
  /* display result */
}, errorHandler);
更新操作
dataService.update(item, function(result, context, operation) { }, errorHandler);

尽管将查询结果保存下来成为items集合,并且根据用户在界面上执行的操作修改item上的属性,这些逻辑都需要我们手动维护,然而最后将item更新到服务器上则只需要如此简单的一句调用。

在我给出的示例代码中,我自己写了一个InPlaceEditBehavior,也就是所谓的“就地编辑器”,能够让用户点击显示文本后把显示文本变成输入框。然后我把这个InPlaceEditBehavior绑定到每一条记录显示的Winner字段和Film字段的span上,使得这些span都能接收用户输入。最后,我为InPlaceEditBehavior添加了一个onchanged事件,并在该事件的处理函数中完成更新item以及调用update()的操作。

小结

在这篇文章里,我简单地介绍了ADO.NET Data Service Client Library的易用性,并且通过一个具体的示例说明了如何用它来节省大量的数据交互代码。

如果你曾经写过AJAX-Enabled WCF Service,你应该知道把实体类暴露为WCF Service接口是多么麻烦的事情,就算每个实体类就简单地支持CRUD方法,你也必须手动编写这4个方法。ADO.NET Data Service相当于帮你把这一切都做好了,只要给它实体类和规则,它就帮你生成一个Data Service。另外,通过AJAX-Enabled WCF Service所包括的数据接口,会自动生成一大堆客户端代理类,而ADO.NET Data Service Client Library则只有一个固定的代理类,客户端代码体积不会随着接口复杂度的增加而增加。

说了 ADO.NET Data Service Client Library的那么多好处,那么这个示例中又有什么做得不够好的地方呢?我觉得最难维护的地方就是获取到数据后拼接HTML的代码了,人手写的HTML 拼接代码难免容易出错,而且日后更新起来也很麻烦,出错了调试时也不容易定位问题。ASP.NET AJAX Template能够帮助我们解决这个问题,这就是下一篇文章中将会讲到的内容。

如果你不想错过接下来的文章,欢迎订阅我的博客,点击侧栏上的订阅链接就可以了。

如何购买 Amazon Kindle 书籍

在美国旅行时,无聊地在iPhone上装了Kindle for iPhone,然后挑了几本技术书的sample来看看,发现在iPhone上这样看电子书还是挺方便的,就是有些代码块不能自动放大到正常显示字体看起来有点辛苦。我觉得Amazon的sample还是做得挺大方的,每本书都开放了整个chapter 1,技术书的话基本上看chapter 1就能看出作者讨论问题的深度。

我利用旅行的时间,看完了LINQ UnleashedPro LINQ的sample,然后决定买一本来学习一下LINQ。我个人更倾向于买Pro LINQ,因为它在chapter 1就提到了deferred query这样的概念,应该是一个本深入讨论LINQ内部技术的书籍。不过我还是看了一下Amazon上的评分,发现两本都是5星的,但Pro LINQ有32个review,而Linq Unleashed只有4个,于是决定就买Pro LINQ。

开头以为买本Kindle书就是直接刷卡那么简单的事情,结果发现Kindle书是有区域限制的,只能发送到美国。但是我上次买LEGO Mindstorm NXT也是这样买啊,中国的信用卡加美国的送货地址就可以了,不允许送到美国之外的东西就让别人在美国待我签收。神奇的是,Kindle书是只能1-Click购买的,不能在购买时填写送货地址,那Amazon凭什么说我就是在美国之外呢?虽然我禁用了1-Click购买,但保留在1-Click购买的默认地址是美国地址,真是想不明白。

在网上看了很多资料,别人都是可以在美国境外购买Kindle书的,我想来想去也不明白Amazon凭什么判定不能把Kindle书卖给我。本来我不想把帐号上记录了的信用卡信息和地址信息删除的,这样将来要用时又要重新输入,最后实在想不到办法了,决定把这些信息都删掉!接着点1-Click购买,Amazon重新问我要了一个地址,我填了一个美国地址,就购买成功了。

另外,大家都说只能用中国的信用卡购买Amazon Gift Card,再用Gift Card买Kindle书,我也不知道是不是这样,反正我是这样买的。一开始Amazon提示区域限制时,我就怀疑是信用卡的区域问题,所以就去买了Gift Card。能否不用Gift Card直接购买我还不知道,下次可以这样试试。

最后,Amazon是有iPhone版页面的,但它默认打开的购买Kindle书页面缺不是iPhone版的。如果在iPhone版页面上搜索Kindle书,结果能显示出来,然而旁边会写着『This item is currently unavailable』,并且点击进去就会说找不到。只能说,Kindle for iPhone确实还没完全准备好,配套的购买功能都还做好针对iPhone的优化。

2009年2月22日星期日

Beijing Open Party

这是我第一次参加Beijing Open Party,主要是为了了解unconference的具体组织形式,其次是想谈谈GMP Party与Beijing Open Party合作的事情。

下午1:00,我们到达了东直门的ThoughtWorks办公室,门口的签到挺方便的——假如曾经在网上报名或者参与过过往活动,输入名字后其他信息就会自动显示出来。然后进入了ThoughtWorks的办公区域——一个无阻隔的大hall,四周除了窗户就是涂鸦墙,水房仅仅用吧台分隔开来,只有娱乐室是用墙壁分隔的。这样的办公区域感觉挺好的,特别是用来做各种创意活动的话,但是如果想要专心coding,不知道会不会很容易受周围讨论的影响。无论如何,这样的地方用来举办Open Party倒是不错的。



1:30开场之后,先有30分钟的『调侃5分钟』活动,任何人都能够上去做个简单的分享或者广告,每个人的时间限制在5分钟之内。有些人上去介绍了一下自己的网站或者开源项目,也有些人上去分享了一些想法和工作成果。这种形式的分享在同一专业人群内总是很有效率的,不需要演讲者有非常优秀的演讲技能把专业内容转化为适合大众口味的内容或调动听众情绪,只要能把专业内容正确表达出来,听众们一定能听懂,并且也知道哪些内容是更能体现演讲者的技术深度。



在『调侃5分钟』结束后,正式开始对话题的投票,虽然不限制每个人的投票次数,不过还是鼓励大家只投真正想听的话题,以便把话题分散开来,人人都能听到自己想听的,而对能拿到奖品的top 3话题评价也更准确一些。投票完毕,根据4 tracks * 3 periods选出了12个话题,然后就正式进入话题演讲阶段了,其中每个period为一个小时。

我一直留在大厅听较为大众化的话题,偶尔去各个会议室看看其他小众话题是如何进行的。由于这次是Mozilla赞助的活动,所以有3个Mozilla相关的话题,其中第一个是在大厅的Seth演讲,讲的是Mozilla Community Localization。

随后还有图灵的书友会以及CC商业模式介绍的话题,讲得都不错。比较可惜的是,到后期饮料都被拿光了,剩下很多曲奇却没有人吃。

总的来说,Beijing Open Party确实挺geeky的,不过放在大厅的话题还算是大众化,而且演讲的质量也挺高的,所以即使没有哪个小众话题吸引你,也可以在大厅听听,或者走到旁边跟其他人聊聊天。

2009年2月14日星期六

Facebook News Feed 上的内容强调与弱化

我之前曾经思考过Facebook News Feed的价值,觉得News Feed中良好的信息筛选与排序算法是我喜欢使用Facebook的原因之一。当时我只想到了News Feed显示的是一种trend,以及这种trend能够带来的经济利益,不过貌似至今Facebook也没有开发这方面潜在赢利点的倾向。

最近我又对比了一下Facebook和众多国内SNS网站的首页输出,发现Facebook的News Feed其实很侧重于用户交互,并且这个侧重点不仅仅与信息输出的条数有关,还与版面设计有关。

如果你把Facebook的News Feed当作报纸来看,那么哪些是能够第一时间成功吸引你注意力的“头条”?我想应该是用户上传或分享的视频、图片,以及有评论的信息。首先,这些信息占的版面大;其次,视频与图片的丰富色彩及评论区域的背景颜色明显地和颜色单调的描述性文字区分开来。我们来看一个具体的例子:

Facebook | Home

我想你肯定能够轻易地看得出中间照片集一段的强调作用——占用空间更大、粗体的标题、字号更大的评论链接。这说明了,Facebook是刻意设计为强调这一条信息的,而非仅仅因为照片占用更多空间而“意外”造成的效果。

那么有评论的信息呢?评论区域淡淡的背景色,也成功地将它从其他同等级别的信息中凸显出来:

Facebook | Home

大量弱化的信息,往往会被淹没在News Feed中,然而只要有评论,你就一定不会错过。评论区域的背景色一定会捕捉到你的注意力,甚至你会因为评论数量之多,而好奇到底是什么事情吸引了那么多人的注意力。

校内在一定程度上抄袭了Facebook的这些设计,所以首页看起来还是挺顺眼的,虽然我实在搞不懂校内是如何选择强调哪些信息的,而且在中文字体上用粗体能得到的强调效果我觉得并不明显,此外弱化信息的弱化做得也不够明显。

海内在这方面显得有点点“自作聪明”了,结果得到的效果更糟糕。例如用户改变状态(或曰“签名”、“迷你博客”……),这类信息数量之大,显然应该弱化之,最多仅仅强调有评论的几条。海内则是反过来做:

首页_海内

这种对好友意义不大的信息(相对发照片或写博客来说),竟然要暂用三行的空间。而且,海内还默认把评论隐藏起来了,在一堆同类信息当中,你实在看不出哪一条是因为能够得到别人注意而拥有评论的,于是扫一眼就全部跳过去了。此外,海内的评论(或曰“回复”)也不突出,即使默认展开了强调效果也不明显。

最后总结一下,SNS的首页信息必须做到两点
  1. 能够有所侧重地选择推送给用户的内容
  2. 在版面设计上把重点强调出来
至于哪些是应该重点推送的信息,我想除了可以通过复杂的算法计算之外,有些简单的规则是普遍适用的。例如说评论,能够引起部分人注意的信息,至少比没人会留意到的信息更值得我关注。又例如说照片,别人原意花时间上传的照片,至少比无意修改的状态更值得我关注。

2008年12月29日星期一

GMP Party EP2

Geeky meets Pretty的第2场大party终于来了(平时的小聚会不计算场次)。自从我在网志年会上见识到了Punch Party后,我就一直想在GMP内搞这样一个活动,在小组内进行过若干讨论后我们最终决定要搞一个2008年年度“大”party,形式当然就是Punch Party了。

这次party,要感谢Chloe和Piggest帮忙组织,是她们帮忙确定了整个活动的rundown和预订到了场地(奇遇花园)。然后要感谢所有的speakers,是他们带来了如此丰富的speech:

Jinghua和Chloe的session做成了series,让大家非常期待下一个episode。其中Jinghua说到清华校园不适合搭讪美女时,方军立即表示反对并解释了清华哪里适合寻找美女。Leo因为是在看过广州Punch Party的视频后做的准备,所以他的session风格也更接近之前广州Punch Party的,据说他之前按照7分钟的时间安排排练了好几次哦。龚纹的星座解释好复杂哦,听着听着就让我感觉在上高中的政治课,可惜现场没有人主动出来让龚纹做一下分析,否则会好玩很多。

作为一个party,少不了的当然是回答问题抢奖品的环节,我的geeky问题加上Chloe的fashion问题还有龚纹的星座问题,确保了大家不仅仅要有实力还要有运气才能拿到奖品。对我来说,最好玩的就是问Office 2007下一版本号的问题了,竟然那么多人不知道Office 13这个版本号被跳过了。

这次的party虽然并没有Carol组织的Punch Party那么紧凑和快节奏,不过我觉得作为第一次已经做得不错了,相对来说不够2.0(主要是单向交流,听众互动少),而且也没有sponsor。方军建议我们可以和Beijing Open Party合作,做成他们的一个track,因为我们在某些方面正好和他们互补哦——他们缺少美女,而我们性别比例极力保持在1:1;他们缺乏非技术话题因而显得范围比较窄,而我们追求多样性有各式各样的话题;我们没有sponsor所以要收场地费用,而他们拥有不少的sponsor;我们还没有固定的流程,而他们已经有相当的活动经验。

anyway,接下来我们GMP也要建立一个对外发布信息及接受投票和留言的blog,然后逐步把GMP Party的筹办过程流程化,让GMP Party成为一个相对稳定的活动。

2008年12月11日星期四

假如你愿意以原版或影印版价格购买翻译书籍的话

这篇文章是接着Tony Qu的《批“觉得有必要记一下的东西——关于翻译”一文》写的,就讨论一个问题——你原意以原版或影印版的价格购买翻译书籍吗?

为什么问这个问题?这源自Tony Qu批判的原文中的一句话:
很多国内程序员看书就只看英文原版,开发就只用原版VS,就是这个原因。


我承认,在英语能力相当的程序员当中,这句话说的是事实。能够看原版书的尽量看原版书,不仅仅因为看起来舒服,更因为容易在P2P网络上找到OCR后完美排版的PDF(甚至是官方PDF)。但这部分人当中,又有多少是真真正正是去买原版书的(原价格按汇率算),或者至少去买影印版的(价格是翻译版的一倍以上,原版的一半以下)?我想就很少了,我仅仅知道Jeffrey Zhao会从国外买二手原版书。很老实说,假如读者原意为翻译版支付引进版的价格,那么翻译版能够做得比现在的要好得多。但有多少人是连翻译版的价格也不愿意支付的,宁愿上网找极度难看的未OCR扫描版?此时,结论已经很明确,翻译版质量差不完全是出版社或者译者的问题,是经济利益驱使,这有电影工业与唱片工业在大陆的做法为证!

虽然现在DVD的分区对购买者来说已经毫无意义,但当初就把大陆分作一个6区是有理由的。话说刚刚有DVD的时候,大陆的DVD市场跟国际市场同一个运作方法,电影上映后至少3个月才发行DVD,以免影响票房。但DVD就是卖不出去,不仅仅是因为太贵,还因为国内的购买者不愿意等那3个月,当然也不愿意买票进电影院看。他们买什么?买盗版DVD。因为DVD必须有正版片源出来后,才可能有正版片源的盗版DVD,所以3个月未到,所有的盗版都只可能是枪版DVD。然而大陆消费者就是不在乎画质和音质,他们就是想以最低的价格抢先看到电影,看完就算。当这种需求被中国电影工业从业人员知道以后,一种新的商业模式发展出来了,以满足这部分消费者的需求——大陆的引进版DVD的发行和电影的上映几乎同步进行,价格仅仅比盗版略高,并且最重要的是,人为地把画质和音质降低到枪版的水平。就这样,电影工业能够在大陆盗版市场上分到一杯羹,我的意思是他们算是卖官方枪版的了,同时也不影响他们的国际市场价格——即使存在购买渠道,港台消费者也不会接受这样廉价的劣质DVD,仍然会等上映3个月后买原版DVD。

唱片工业做的事情是类似的,大陆所谓的引进版虽然价格更容易被消费者接受,但音质是经过人为降低的。这就是价格歧视,因为大陆消费者只愿意支付一个更低的价格,也只需要购买质量更低的商品,所以供应商就可以把这划分为一个独立的价格歧视区域市场。我不知道图书行业是否存在这样人为控制的“阴谋”,但只要大陆消费者的需求还是这样的“另类”,价格歧视原则就会一直适用,这样的事情就会无意识的继续存在,以远低于影印版价格售卖的翻译版质量就肯定还是那么低。对了,顺带说一句,港台翻译版的价格是和大陆影印版差不多的。

总结一下,我也是译者,翻译工作低廉的价格以及编辑工作的效率低下Tony Qu说过我就不再说了。如果大陆翻译版最终按照港台翻译版的价格去销售也能获得同样的销量的话,我相信译者可能愿意为这份价钱做全职的翻译工作,我相信出版社愿意聘请更多专业编辑并且合理安排他们的工作量。

P.S.如果要认真学习和研究中国的传统语言文化,我个人还是建议去台湾。

2008年12月6日星期六

SD2C 2008

这几天参加了SD2C,也就是“软件开发2.0技术大会”。规矩当然是照旧的,social第一,session第二。

Day 1

第一天想着12:00开始签到,于是慢吞吞地准备出发,去到九华山庄已经是11:00。这是我第一次在没有车接送的前提下一个人跑来九华山庄,路上浪费了不少时间。签到后开始乱逛,然后陆续找到了公司不同部门来的同事,发现大家都没吃午餐。虽然我自己从McDonald's带了一个汉堡来,不过还是跟大家一起打车到小汤山街口的镇上吃饭。吃完饭就13:00了,应该开场了,可是打车回九华山庄实在太难,最后无奈打了黑车回去。我个人认为,把开场放在13:00但又不提供午餐是十分不体贴的。在市区的话也就算了,在九华山庄这样一个三流装一流的地方,选择不多又不怎么好吃的自助餐竟然要¥68一位,方便面也要¥20一盒,不提供午餐这样的做法实在是不人道。

下午的议程看起来全是keynote级别,听过后才发现那完全是赞助商专场——逐个赞助商轮流上去宣传自己的技术或者观点,而且还不提供任何课程反馈的机会,它讲得再烂我也不能表达一下我的不满。赞助商专场分为上下两个半场,上半场的人都是来吹水的,就吹嘘自己公司的东西,泛泛而谈,听了也没什么收获;下半场讲的东西稍微实在一些,雷军和戴志康上来讲的话都很真诚,也很有感染力。总之,要是早知道第一天下午是赞助商专场的话,我就去WinHEC玩到15:00再过来好了,然后18:00吃饭,接着参加晚上的活动。这只能怪我参加会议的经验还是太少了,没有把这么明显的安排给看出来。

下午听了那么多个小时,最让我感到震撼观点来自于雷军。他在说他投资的UCWeb时提到了这样一个观点:我们曾经都是互联网用户中的领头羊,有什么新鲜的东西出来我们都先去尝试,然后慢慢普及到大众用户。但在移动互联网就不是这样,移动互联网的主要用户是那些比较少机会通过计算机接入互联网的人,例如学生、民工和军人。也就是说,我们这些每天使用计算机连接着互联网做开发的人,其实是不可能知道移动互联网的真实需求的,我们无法体会使用不到计算机接入互联网会使怎样的。过往我一直认为移动互联网用户就是高端移动用户和高端互联网用户的交集,现在我终于明白到不是这么一回事了。

晚上去各个沙龙看了一下,没有什么印象特别深刻的。只记得在“职业规划与成长论坛”上听到这样一句搞笑的话——“我们的HR自裁了,也就没有HR了”。晚会后有班车把我们送回到地铁站,然后回到家也就是23:00了。

Day 2

第二天早上9:00出发,去到就是11:00了。我觉得把第一个session放在9:00开始是很不合理的,九华山庄这么偏僻的地方外加不包住宿,谁原意那么早起床赶7:00从市区开出的班车啊,结果当然是大家都很晚才到啊。对于speaker来说,如果自己的session被放在早上,可能也会觉得大会不重视他的session,因为早上能赶来参加session的人就是少一些,这个大家都明白的。我去到时已经是11:00,然后去听了一下郭安定的课,中午和郭安定、老孟、莫依等MVP一起吃饭,还是挺好玩的。

从郭安定讲的内容来看,他很注重企业生态圈。也就是说,只要你能够帮助别人解决实际问题,赚钱的机会总是有的,但也没必要自己把什么都做了,也要留机会让别人帮你,赚你的钱。把这个道理传播出去,让更多人赚得到钱,让更多人受惠。这种思想我是十分认同的,如果帮助别人的同时又帮助了你自己,这有什么不好呢?

下午我去听了一下周爱民的JavaScript+Delphi+ErLang,语言层面的东西不用怎么在乎,他也没做很应用性的展示,我觉得最重要的一个思想还是分层——只要实现了分层,层与层之间是针对接口设计的,那么随时换掉一个层都是可以的,只要接口保持不便,什么语言并不重要,不同层的需求不同实现语言自然也可以不同。另外还听了李建忠的.NET设计模式,讲的是一些老生常谈的内容,没什么非常特别的。其实讲什么技术并不重要,最重要是把那种思想说清楚,让听众都能领悟到,那就算是成功了。

晚上是CSDN专家沙龙,本来说是让各位专家说说对CSDN服务的不满与建议的,结果大家的自我介绍都拖得很长,介绍完也就完了,赠送给各位专家一人一本绝影签名的《疯狂的程序员》,然后就赶班车去了。其中最有趣的一幕,就是莫依问老孟说,“是什么让你多年坚持在论坛上帮助别人解答问题”,旁边的郭安定小小声说了两个字,“伟哥”。

Day 3

最后一天,依旧是9:00出发11:00到。原本计划去听听iPhone开发的,发现基础部分都讲完了,开始讲OpenGL的使用,我又完全听不懂,听了三分钟就睡着了。

下午听的是使用YSlow2.0优化网络性能,主要是了解一下YSlow2.0的新特性,也就是如何自己设计符合自身网络特性的网络性能评分规则。接着去听了Amazon运计算服务的架构分析介绍,确实比较介绍性,让你知道就是有那么多的服务在运行着,并且能为企业省钱,就这么简单。最后听的一个session是面向对象的JavaScript,这是作为当今JavaScript开发人员必须知道的基础知识啦,听他说一遍只是为了好玩。

SD2C结束后,马宁准备把我和莫依还是陈敏送到地铁站,最后大发慈悲把我们都送回家了,超级好人,在这里需要感谢一下。建议明年真的不要选择九华山庄这样的地方了,交通实在是不方便。

P.S.发现自己最近参加的会议不少啊,整个blog塞满了关于各个会议的文章,如China MVP Open Day 2008、TechED 2008 China、Chinese Blogger Conference 2008WinHEC 2008 China

大陆技术书越来越台湾化了

这次SD2C我总共搬了4本书回家,2本买的2本送的。我发现现在大陆出版的技术书越来越台湾化了,也就是“更多搞笑,更少大道理”,而这正好符合我近期的读书倾向。

在CSDN专家沙龙上,每位专家都拿到了一本绝影的《疯狂的程序员》,听说是绝影自己经历的写照。虽然我还没仔细看,不过相信这本书会是本十分轻松的小说,这正是我喜欢的。之前看《梦断代码》也是足够轻松的,不过轻松背后也发人深思,让你不得不去思考很多软件工程和组织架构的问题。

在SD2C的签售会上,我还买了一本《悟透JavaScript》。我已经不需要看任何对JavaScript泛泛而谈的书,但我仍然买了这本书,就是想看看其娱乐性的一面,如果确实写得好,包括插图画得好,那也是十分值得我学习得。什么时候我也要在我的blog上加上专业插图,否则就太没有竞争力了。

另外我最近还买了一本《大话设计模式》,同样也是因为它搞笑的一面。虽然读起来会觉得某些剧情比较牵强,但至少这是一种写作风格,可能在大陆还不成熟,不过将来会被越来越多的作者采纳,自然会成熟起来。

总的来说,我现在也看纯技术书看得有点累了,况且很多东西看了不用等于没看,过一段时间还真变成没用的了。轻松娱乐的东西,至少保证了阅读的过程是愉快的,即使将来用不着,用得着也就算是赚了。

2008年12月3日星期三

WinHEC 2008 China

今天是WinHEC第一天。WinHEC就是Windows Hardware Engineering Conference,中文名是做Windows硬件工程大会。昨晚紫柔告诉我9:00到场签到就可以了,因为9:30正式开始,但我早上还是忍不住多睡了一会儿,所以10:00才到场。当时还是张亚勤的演讲,我进入主会场后迅速找到剩余的几个空位坐下来了。

张亚勤的演讲当然紧接着若干个demo,其中Surface的demo在MVP Open Day已经看过了,这次还是同一个人来做。还有那个health care的video,也是MVP Open Day上面放过的,看来这两个月没什么变化嘛。整体而言,张亚勤演讲后的中文demo都是做一些我们已经知道的东西,没什么值得看的。

原本张亚勤的演讲只有1个小时,结果延长了很多,然后Dennis Flanagan才上来讲Windows 7。Windows 7的demo就非常有冲击力了,特别是device stage这样的特性。

在Windows 7里面,每个外设(包括网络外设)都有自己的图标,厂商可以设计一个和外设外观一样的图标,使得用户更容易在Windows 7中识别这一设备。例如你有黑白两个USB drive,都插入到电脑后,你会发现不知道哪个盘符是哪个USB drive的,要看看里面的内容才知道。在Windows 7里面,只要厂商制作了对应的图标,用户就能在图形界面上看到有区别的两个图片,也就可以在不了解何谓盘符的前提下正确操作这两个USB drive了。

此外,每一个外设都可以有自己的device stage,例如连接一部Zune后可以显示容量、电量,还可以显示为你推荐的MP3销售信息;又例如连接一部Nokia手机后可以显示有关的内部信息,以及Nokia网站上为这部手机推荐的新游戏。简单来说,硬件设备销售后不再是与硬件厂商脱离关系了,只要它连接到安装了Windows 7的PC,并且这台PC还连接着网络,硬件厂商就能得知这台设备的使用情况,并且为你推介更多的商品和服务,当然也可能包括免费的服务与技术支持。肯定有人会说这会导致隐私问题之类之类的,我相信最终Windows 7和硬件厂商会引入访问控制机制,让用户选择一台设备连接到Windows 7后是否允许相关信息通过网络传输,这个大家不用担心。

两个keynote结束后,就是抽奖环节。早上每一个人进来时都拍了一张照片用于抽奖,然后用这些照片拼成了一个巨大的奥运五环徽标,最终用Silverlight Deep Zoom来随机zoom in到某一个人的照片之上。这样的抽奖形式还是挺有创意的,不过有些照片实在太不清晰了,最后拿到了大奖的人到底是不是照片上的人,我们都不知道。

午餐是跟紫柔以及其它MVP一起吃的,紫柔带来了一个90后的实习生,是一个拿了国家奖学金去新加坡读高中的女生。她应该是紫柔的助手吧,不过我们说的东西她都听不懂,应该会觉得十分无聊。

随后,让我最不满的事情就发生了!今年的WinHEC和TechED一样,通过盖章来增加互动,总共有1200份Windows 7光盘和1000只2G USB drive可以通过盖全10个章后获得,并且日程表写着下午2:00开始换领的。但我们2:00回到会场发现今天的400只2G USB drive已经换领完毕了,虽然Windows 7光盘还是有的,但因为必须同时换领,所以也就相当于不能换领。既然日程表写着下午2:00开始就应该下午2:00开始啊,怎么能够提前开始发呢?!

下午的课程我们都没有去听,一群MVP聚在一起聊天。最有趣的一幕就是,竟然有人来主动搭讪那位90后女生。是不是非80后的人就分不清什么人是90后的呢?又或者是IT人士太闭塞了?反正我觉得90后的化妆和穿衣风格挺容易辨别的。我们分散地坐在媒体展示区的长沙发上,那个人直接无视我们问她还有没有盖章的那张纸。她说没有,那个人就问她是哪里的以及有没有名片。这时候作为大版主的紫柔自然冲出来说——我们都是微软中文技术论坛的!我相信那个人已经很无语了,但又不知道我们是干什么的,还是问我们有没有名片。紫柔就告诉他,你上微软中文论坛技术就知道啦。他估计还是不知道微软中文技术论坛是什么,不过很无奈地走了。真是难得见到有人如此直接搭讪的,而且还是在硬件工程大会上哦!

最后一个session解释时,会根据收回的反馈表抽奖,于是我们就找了一个讲用VHD(虚拟硬盘)引导启动的session去听听。最后提问阶段,有人问了能否引导启动一个装有Linux的VHD,speaker说VHD的技术都是开放的,虽然Microsoft没有实现的意向,但开源社区可以去做这样的事情。其实我有个问题,不过一直懒得问,那就是Microsoft能否和Apple合作,做一个Mac上从VHD引导启动的东东,那么将来我就可以在MacBook装Windows 7并且仅仅装到VHD里。

会议结束后,MVP在讨论是否组织一起吃饭,因为我约了人,要去拿张CF卡,所以就先走了。明天我要去参加SD2C,也就无法参加WinHEC了。

P.S.这篇文章不是因为MVP换取赠票而必须写的,而是因为换领礼品这件事实在搞得太不合理了,当时我就决定要写WinHEC的负面。

2008年11月23日星期日

Chinese Blogger Conference 2008

上个周末请了两天年假,回广州参加网志年会顺便回家。

第一天去到会场,就见到了LEMONedhidecloud,然后拿到了我的fail whale tee。接下来的session……其实我不知道session讲什么,我想大多数人都跟我一样不关心session讲什么,大家只是找个机会来聚会而已。中午跟Elliot Ng一起吃了午餐,并且拿了一件CNReviews的tee。下午的session也是不知道讲了什么,然后就是自助晚餐了和Punch Party了。

自助晚餐吃的是点心,虾饺和牛肉丸都不错,但是鸡翅就很难吃。接着Punch Party正是开始,第一位上台的是Carol,介绍什么是Punch Party。所谓的Punch Party,就是每位speaker有7分钟的时间,大概就是20个slide每个slide讲20秒的时间再多一点。当晚的Punch Party做得非常perfect,每一个人讲的话题都十分之吸引人,做到了Punch Party所强调的punch效果——让人感觉耳目一新。Carol作为第一个speaker,把全场的气氛都调动起来了。中间有介绍大陆吃喝玩乐之行有多艰险的工头坚,还有介绍胖卡如何把宅男配送到乡下的。最后一位导演先生,表演了7分钟的无声演讲——开头只说了一句,“由于接下来的内容都很晦涩,所以自动进行静音处理”,接着做了7分钟演讲的动作与口型,幻灯片翻了几页,但是没说过一个字。对于所有参加Punch Party的人来说,这样的结尾实在是太impressive了!

Punch Party的好处显而易见,能够在最短的时间内让你了解到一些你可能永远都接触不到的知识,同时给你无限的震撼感。不过我觉得Punch Party对speaker的要求也挺高,否则也不容易做好。而且作为organizer,一场Punch Party必须组合不同类型的speaker。

第二天的session稍微有趣一些,不过依然没怎么听,莫非年会的习俗就是把重点放在晚上?下午年会结束后大家就跟着Issac Mao到“友鸡会”吃了火锅,然后到北风的凸凹酒吧去聊天。我也不知道最后大家是什么时候才回家的,我快到凌晨时已经想睡觉了,于是就回家了。

2008年11月13日星期四

Live Mesh vs MobileMe

最近在用Live Mesh在多台计算机上同步文件,而之前一直用MobileMe同步联系人、日程等信息外加系统备份,真希望把这两个服务的好处叠加起来。

Live Mesh的好处是可以指定任何一个目录进行同步,而非指定一个同步目录然后要同步的东西必须放在里面,这方面就比MobileMe要好。而且Live Mesh的自动同步客户端同时兼容Windows和Mac,而MobileMe仅仅支持Mac同步。Live Mesh唯一不足就是没有版本控制,不过我想要是有版本控制占用的网络空间和流量开销就成倍增加了。

MobileMe给我印象最深刻的是,我重装了我的MacBook后一登录MobileMe帐号就帮我把整个System Preferences给恢复了。当然,联系人和日程信息也都恢复了,这是现在Live Mesh完全没覆盖到的功能。另外对iPhone的push服务也做得很好,更新什么信息都在Mac上进行就可以了,根本不用管它什么时候同步到iPhone上。

我觉得最好就是把这两种服务结合到一起,一个帐号一个服务就把这些都覆盖了,当然我不介意付费。在TechED MVP Dinner上,我和一位做Azure的Microsoft员工聊了一下,说最好Windows上的程序都遵守Vista的规范,把代码和数据分开存放,也就是数据都放到C:\ProgramData下面,这样Windows也就如同Linux一样能够轻松备份纯数据了。接着只要把数据同步到cloud上面,例如说是Azure上层的Live Mesh,重装机器后就能够把数据重新同步回来了,只要再装上应用程序就一切恢复原装了。

2008年11月9日星期日

开始翻译 Adobe AIR in Action

Prototype and Scriptaculous的翻译已经是一年前的事情了,翻译了半年,休息了大半年,现在继续接受翻译的工作。仍然是图灵引进的书,仍然是Manning的In Action系列,这次的是Adobe AIR in Action

其实AIR出来之前我就想去学习,很多很多技术都如此,不过翻译算是一个很好的学习过程,因为它逼着你认认真真把一本书读懂。这次着手翻译Adobe AIR in Action,我想半年后我也会熟悉AIR相关的技术。虽然我一直以来都对Flash和Flex没什么深入了解,但我希望这些知识反过来也能用到Silverlight开发上,结合两派的模式从而进化出一种更好的实践方法。

另外我还介绍了身边的朋友去翻译Practical Prototype and Script.aculolus。Manning即将发布Silverlight 2 in Action,如果图灵引进这本书的话,我也去看看是否能够参与翻译。

2008年11月4日星期二

以服务器端为中心的 ASP.NET AJAX 模式 (Part 2 - Control)

在上一篇文章当中,也就是《以服务器端为中心的 ASP.NET AJAX 模式 (Part 1 - Behavior)》,我们探讨了较为易用的Behavior模式。之所以说它较为易用,是因为它不涉及和原有Page处理流程的交互,即使访问网络也是访问独立的Web Service(包括Page上的[WebMethod]),因此和Page处理流程的设计绝对是正交的。但有时候我们需要的就是与Page处理流程的交互,这时我们不得不使用与服务器端逻辑紧耦合的Control了,这正是本次文章要讨论的内容。

在基本的 ASP.NET AJAX框架下,我们有三种方法来做基于Control的Ajax操作,它们分别是UpdatePanel、ICallbackEventHandler 和IScriptControl,下面我们就分别看看它们的特点和使用场景。

UpdatePanel

UpdatePanel 是与服务器端逻辑进行交互的多种方案中最易用的一个,甚至就不能称之为交互——你根本就不需要触及任何客户端逻辑。一个服务器端操作,经过 UpdatePanel的“劫持”,变成了一个客户端操作,而这个客户端操作又直接调用对应的服务器端操作,就这么简单。

如果用UpdatePanel来做一个带分支的选择对话框,那应该如何设计?思路可别跑到客户端的confirm方法上去,那可太绕了,或者说太不 ASP.NET AJAX了。用UpdatePanel,就应该坚持它的理念,一切客户端操作都是幻象,所有操作其实都是在服务器端进行的,包括选择对话框。要按 ASP.NET的思路来做,我会做一个选择对话框控件,它的实质可能是一个浮动层模拟的对话框,这属于实现细节,我们不用太关注。重点是,这个选择对话框的分支逻辑是完全在服务器端进行的,Async PostBack之后服务器端根据提交回来的数据决定如何触发事件。这样做整个分支选择的逻辑就是内嵌在Page处理流程当中的,不需要通过 Cookies或者Session来做数据的中转媒介,避免了Page处理流程与更大作用域中的数据的紧耦合。

UpdatePanel 适用于逻辑完全在服务器端的开发,并且我建议使用UpdatePanel时也就把所有逻辑放在服务器端,不要去写一些混合服务器端逻辑与客户端逻辑的代码。有人会说,你看老赵就很喜欢去动那个 Sys.Net.WebRequestExecutor来改变UpdatePanel的行为啊,但其实这属于分层设计思想中的一部分,他去动那个东西改变的也就是一个分层内的逻辑,只要层与层之间的接口不变,具体实现是可以按需设计的。但如果你用了UpdatePanel,同时又用Cookies或者 Session来传值,这就跨越了n个层,增加了不少耦合度。

ICallbackEventHandler

关于ICallbackEventHandler,我已经说过无数次了,重点还是你必须用Page处理流程来思考,只要你理解了Page处理流程,你就明白为什么ICallbackEventHandler在.NET Framework 2.0 Beta2中只有一个方法,而到了RTM要分拆成两个方法。具体可以参考《ASP.NET 2.0 ClientScript Callback》,我就不再重复了。

如果用 ICallbackEventHandler实现一个带分支的选择对话框,又如何做?和使用UpdatePanel的做法类似,我还是会做一个选择对话框控件,并且这个控件继承自ICallbackEventHandler。为这个控件编写JavaScript并实现 ICallbackEventHandler接口时,我会确保JavaScript对Callback给出正确的调用参数,并在接口方法的实现中接收这些参数然后触发正确的事件,就这么简单。和UpdatePanel一样,不要偏离了ICallbackEventHandler的设计思想,它的处理流程必须是合并到Page处理流程中的,你的控件也就必须这样设计。

至于在什么情况下选择 ICallbackEventHandler?如果你有一个轻量级的Ajax操作,但使用UpdatePanel更新整个区域的HTML开销很大的话,那么你可以考虑使用ICallbackEventHandler。当然,前提是你懂得控件开发和JavaScript。

IScriptControl

这是最复杂的解决方案了,你需要实现一个Control的两个副本——一个服务器端的,一个客户端的。有一部分逻辑,是要在客户端和服务器端重复实现两次的,而另外一部分逻辑,只需要在客户端或服务器端之中的一个实现一次。IScriptControl的经典例子,当然是ASP.NET AJAX自带的Timer控件。它的计时器是纯粹的客户端逻辑,然而Tick事件却在服务器端触发,Async PostBack成为了两者之间的桥梁。当然,就Control本身而言,它并不在乎PostBack是不是异步的,Tick事件只因PostBack而触发。

如果用IScriptControl来实现带分支的选择对话框,那将会和 ICallbackEventHandler的版本十分相似,唯一不同的地方就是它在客户端的逻辑会被封装为一个Sys.UI.Control的派生类,而ICallbackEventHandler的客户端逻辑往往是不封装的。这样的好处显而易见,那就是代码更容易维护了,并且客户端的Control可以同样可以加入事件支持,并提供和服务器端一样的代码分支事件。要知道在CTP阶段的Timer控件,其客户端版本Sys.Timer(而非RTM的 Sys.UI._Timer)是拥有tick事件的,和服务器端的Tick事件对应,只不过RTM取消了此项功能,因为ASP.NET AJAX 1.0的侧重点完全就是服务器端功能,客户端功能都被砍掉了。

什么情况下选用IScriptControl?如果你认为你的客户端逻辑应该封装为Sys.UI.Control的派生类,那就选择IScriptControl吧。

小结

我们分别讨论了三种通过Control实现Ajax调用的方案,并且一再强调了设计必须基于Page处理流程,不要在此流程之外增加不必要的复杂度和耦合度。值得一提的是,有很多人质疑为什么要在Web上提供这样一个支持分支的选择对话框功能,我的看法是这样的:既然客户端软件的流程会有此功能,那么 Web应用也有此功能就实在是太正常了,你删除blog post的时候问你一下是否确认删除,难道会有人觉得这个功能是设计错误?可能不同的只是表现形式而已,到底是confirm还是弹出层,甚至是一个专用的过渡页面。然而从用户体验的角度来说,这其实并不是最优的方案,多数时候用户删除就是确认删除,并不需要再问一次是否确认之类的愚蠢问题,但开发人员觉得用户错手删除的后果应当由用户自己承担,所以就做了这样一个对话框来推卸责任。真正好的用户体验是不需要确认的删除,但用户一定能够恢复,最好是按一下 Ctrl+Z就可以了,然而对于开发人员来说还是有很多操作是无法做到可恢复的,这时候除了显示对话框也没有更好的解决方案了。

最后,如果你喜欢我的文章,可以通过订阅feed来及时获得更新:

2008年11月3日星期一

软件安装时到底是否应该让用户选择路径

周末和Google UX Team的Junyu聊天,说到Google现在统一使用Google Installer安装软件了,点一下Web上面的链接就自动开始下载安装并运行,开头我还以为是Microsoft的ClickOnce呢。由于安装过程是全自动的,就如同Microsoft的ClickOnce和Adobe的AIR一样,所以是不允许用户选择安装路径的。

到底不让用户选择安装目标好不好?我们认为用户分为三个层次:
  1. 入门用户 - 购买的是品牌机,可能就一个C:和一个用于一键恢复的D:。这时候有什么好选择的呢?当然是不选择最好了。
  2. 熟练用户 - 经受过文件难以搜索或者忘记及时备份误删文件的种种磨难,学会了分门别类存放文件,自己有计划地把硬盘分成C:, D:, E:, F:四个盘。这时候你不满足他分类存放文件的习惯,他就会觉得很不爽了。
  3. 高级用户 - 经过无数次备份与重装后又在返璞归真,只用一个C:,安装时多数选项都直接next,不选择安装路径。
当然,这个分类主要是针对Windows用户,因为Windows的成长过程就是典型的“问题少年”——不停地向用户抛出各种问题,这个你选什么啊,那个你选什么啊。对于Linux和Mac用户来说,大家早已习惯了安装时一路next到底。Linux命令行安装甚至不用next,只是本地编译的话有时候需要yes一下。

事实上,我认为给用户那么多选择是没必要的,文件的搜索与备份应该通过其它手段来改进,而不是让用户手动归档。要求用户理解文件系统,就如同要求调用者理解API实现方式一样,其实是很不合理的。

对于现在的品牌机而言,只有一个C:,培养Windows用户好像Mac用户那样,什么都装到一个盘里面,这才是正确的发展道路。Mac有Spotlight,Windows Vista现在也有不错的磁盘索引与搜索系统,将来实现了WinFS或许能做得更好。

现在Windows缺的是一套好用的备份与迁移方案,问题来源于Windows软件都没有规范地把可执行代码与数据分离存放,所以没有一种统一的模式来备份软件数据。如果Windows上面的软件能够按照Vista的指引,把数据都存储到C:\ProgramData,那么接下来的事情就容易多了。况且我之前也说过了,这也是UAC的意义所在,有助于提高Windows的安全性。

2008年10月27日星期一

以服务器端为中心的 ASP.NET AJAX 模式 (Part 1 - Behavior)

早在ASP.NET AJAX从CTP转向Beta再转向RTM时,看着客户端的Control被逐步放弃,与此同时ASP.NET AJAX Control Toolkit越来越多地使用Behavior,我就想深入说说ASP.NET AJAX的模式。不过由于我比较懒,所以这个话题只在《理想的 ASP.NET AJAX (Part 2 - Server Centric)》中一笔带过,没有深入讨论。今天看到volnet的《我们究竟是否有在“Asp.net中模仿Winform的MessageBox ”的必要?》,决定写一个文章系列来说说ASP.NET AJAX的模式。

什么是Behavior?

什么是Behavior?Behavior与Control有什么不同?这是首先需要回答的问题。

在Windows开发当中,Behavior的概念是不存在的,有的只是Control。ASP开发连Control都没有的,到了ASP.NET才引入了Control的概念。为什么Ajax开发要引入Behavior这样的概念呢?因为Behavior意味着不需要改变原有的组件逻辑,而改变原有组件的逻辑在客户端往往是不可行的,至少是难以实现的。

举个最简单的例子,一个<input type=”text” />就是一个浏览器内部的对象,你无法扩展这个对象的类型,也无法为它加上新的属性与方法,至少并非所有浏览器都允许你在JavaScript中这样做。然而如果你想要让它加上auto-complete(或曰suggest)的功能,这是可以做到的,并且很多人都做过了,例如ASP.NET AJAX Control Toolkit的AutoComplete,或者是script.aculo.us的autocompleter。这些实现都基于同一种方式,就是尝试基于input已有的接口在它之外添加新功能,而非尝试继承input并在它之内添加功能。

类似的做法在Ajax开发中普遍存在。例如说拖放吧,现在离HTML5拖放的全面普及不知道还有多远,所以大家都只能基于现有的鼠标事件来开发拖放功能。又或者说带有验证功能的输入框,无论是input还是select,无论是客户端验证还是服务器端验证,也都是基于现有HTML元素的事件来完成的。这一切都是Behavior。

什么情况下使用Behavior?

简单归纳,就两个条件:

  1. 需要基于特定的一个组建进行扩展
  2. 组建本身所处的环境缺乏可扩展性

单看第1个条件,我们有丰富的选择。很多人的第一反应就是继承自该组件,把扩展功能做到子类里面。熟悉设计模式的话,可能还会想到decorator pattern。然而在浏览器的环境当中,受到第2个条件的限制,继承或者decorator pattern都是不可行的。这时候,我们就需要使用Behavior了。

在一定程度上,我们可以把Behavior看作一种折衷了的decorator pattern。在decorator pattern中,decorator也继承自组件,因此当一个组件使用decorator pattern后,我们就把decorator放在原组件所处的位置上,而原组件就成了decorator的一个子节点(基于树的角度来看的话)。如果再加一个decorator,原decorator就会如同一个普通组件那样再被封装一次。在多个decorator的情况下,decorator之间是串联的关系。Behavior本身不是一个浏览器内部的组件,它无法继承自input的基类,因此Behavior也不能串联。Behavior本身本也不会取代input在树中的位置,这使得Behavior可以并联起来——一个input可以有多个Behavior,例如一个是自动完成,另外一个是输入验证。

总之,如果你原来的工作就是和UI打交道,并且熟练使用decorator pattern,那么在进行Ajax开发时把decorator pattern换成Behavior就可以了。

小结

回过头来看文章开头所说的MessageBox(或曰confirm)的问题,如果这个功能不需要对服务器端进行反馈,完全可以使用Behavior实现。ASP.NET AJAX Control Toolkit就有ConfirmButton这样一个东西,在客户端叫Behavior,在服务器端叫Extender,其实Extender就是对Behavior在服务器端做一下封装而已。当然,ConfirmButton不能完全实现MessageBox的功能,它只能在用户选择“取消”时取消整个提交操作,但不能够执行另外一个服务器端的代码分支。这算是Behavior的一个限制,就是它只能在客户端添加额外的功能,但是它不能影响到与服务器端的交互。但很多时候,正是这种限制确保了我们开发的组件是与服务器端解耦的。

如果我真的需要一个与服务器端交互的客户端组件,例如支持调用服务器端代码分支的confirm,怎么办?这时候你就真的需要一个与服务器端Control对应的客户端Control了。请关注本系列的下一篇文章,《以服务器端为中心的 ASP.NET AJAX 模式 (Part 2 – Control)》。通过订阅feed,你可以及时获得文章更新:

P.S.既然提到了Behavior和Extender的一一对应关系,就不得不说一下,服务器端的Extender就是真正的decorator pattern。

2008年10月26日星期日

远离国内的 SNS

最近我一直在想是否要把海内的帐号终止掉,原因只有一个——我很久不上海内了。既然我不用它,我就没必要把我的个人信息放在上面,让更多不认识的人有机会获取到这些信息。

如果要详细解释这件事,就要从很久很久以前说起,就是海内刚刚开放注册的时候。在改为邀请注册之前,海内曾经开放注册过几天,让及时获得消息的geek们第一时间获得了帐号,那时候我还没有多少好友在上面,已有的好友没有多少活动,news feed自然不值得一看。

后来,海内上的好友逐渐多起来了,大家也更活跃了,这是我认为海内最好的一段时候了。虽然,这时候的news feed算法也不怎么样,例如不会把同类项合并了,也不会对信息按照重要程度进行过滤。我之前也说过,Facebook的真正价值就在于它的news feed,news feed的算法不行也就以为着海内能为用户带来的价值优先。

随后,海内开始把重心转移到游戏开发上来。买卖好友可以说是为了刺激用户数量的扩张,但越来越多的游戏上线让我觉得整个海内都变得以娱乐白领为首要目标了。我的个人观点是跟BeanAwflasher差不多,虽然中国人口众多必然导致劳动力过剩,但让每个人都把自己过剩的劳动时间投入到游戏当中并不是好事情。当海内的news feed充斥着各类游戏相关的信息时,我就不再去看海内了。

说完了海内,国内的其他SNS我想也没必要一一列举了。海内曾经是国内最用心用力想称为白领SNS的一个了,国内其他成功SNS的目标从一开始就定为娱乐性SNS,短期内不可能得到比海内更有价值的结果。在这里我所说的价值不是指SNS本身的商业价值,而是指推动国内SNS用户素质提升的价值,是指创造SNS之外的商业价值的可能性。