2010年1月31日星期日

程序员的品味

上个月跟刘江以及一些《程序员》的热心作者读者吃了一顿饭,刘江让大家谈谈《程序员》的内容以及未来的方向。在激烈的讨论之后,我觉得我应该把自己的想法写下来,但那篇文章在我的草稿箱里躺了一个月了,就是无法结尾。

那篇文章想要表达的意思很简单,我认为《程序员》应该提供一流的阅读体验。至于作者和编辑手上的内容,就如同程序员手上的代码一样,都只是为了实现特定体验的手段而已。就拿《Avatar》来做例子吧,它的内容值多少钱?先别说它内容做得怎么样,就算做得再好,在中国消费者眼里也就值一张盗版光盘的价格。但是大家都原意花钱去电影院看《Avatar》,而且非 IMAX 不看,这说明大家花钱买的是体验,而非内容。

文章写到最后,我认为《程序员》的阅读体验相对于一般 IT 杂志而言,就应该如同 IMAX 跟家里电视机的区别一样大。价格不是问题,大家天天都在家里看电视也不是问题,只要体验是值回票价的,大家就原意排队买票看 IMAX 。然而为什么《程序员》应该去扮演 IT 杂志中 IMAX 的角色,为什么《程序员》就不能老老实实地做电视机,这个问题我无法解答,因此那篇文章也无法发布。

最近我重看了一次 Paul Graham 那篇《创造者的品味》,并且花了些时间去看原版。然后周末在 Open Party 上有和 Tin 聊了一下如何培养程序员的品味,我想我已经知道如何回答上面那个问题了。

什么构成品质

对于博客园这样的草根媒体来说,有高品质的博客,也有低品质的博客,这是可以容忍的。高品质的博客,说的不仅仅是文章内容质量好。就拿 Jeff 的博客来说,模板源自一个漂亮的 WordPress 模板,然后 Jeff 根据他的需求对细节作出了调整。 Jeff 还选择了一个视觉效果比较贴近 Visual Studio 的代码着色器,这使得代码块的整体视觉效果不会太糟糕。而且 Jeff 自己写的代码通常都很简介很清晰,这保证了他在文章中嵌入一些代码块后,可读性还是十分高的。此外,清晰的逻辑结构和小节的划分,使得读者能够快速跳扫描一遍文章,然后认真阅读自己想要深入理解的段落。

至于《程序员》,你随便找一本翻开,和屏幕上 Jeff 的博客对比一下,你可能会觉的 Jeff 的博客才是专业媒体。就拿版式来说,《程序员》和同等价位的时尚、美食、旅游杂志实在没得比。文章中内嵌大量的代码块,而且为了不破坏分栏结构,大多数原本一行的代码必须分作两行写,第二行还不能有缩进,因为缩进了可能就要分作三行写。至于插入 UML ,往往就意味着破坏分栏结构了,最终导致文字环绕的出现。我想任何一个看过《写给大家看的设计书》的人,都能指出这些版式设计的错误。

我知道作为一本程序员的杂志,插入代码和图表是必须的,就如同时尚杂志必须出现服饰、美食杂志必须出现食物、旅游杂志必须出现景点一样。区别在于,凡是出现在杂志上的服饰、食物、景点,展示的都是事物最美好最让人向往的一面,然而《程序员》杂志上的代码和图表并非如此,你看到这些代码后只会感到厌恶,并且心里想着,「我用 TextMate 随便打开一份我写下的代码都比你这要好看」。

说到品质,有一个对比效果非常强烈的例子,那就是2009年10月《时尚先生》上的 IT 企业家李开复,和2009年12月《程序员》上的 IT 民工李开复。我真的很想知道,如果把这两张照片剪下来,然后拿去小学做访谈,问小学生想要长大后成为这两个人当中的哪一个,最终的统计结果会是怎样的。这个统计的结果,或许可以通过类比猜出来。在《程序员》中找到《架构师接龙》这篇文章,把你大脑里对架构师的认识先抹掉,看着文章开头两位架构师的照片问自己一个问题,「我想要成为架构师吗?我想要成为这两个人当中的任何一个吗?」

选择符合自己审美观的事物,是人的天性。这种选择,同时也就是对品质的选择。这种审美观,源自长期的积累,就如同熟练的程序员能够无意识地一下子嗅出代码中坏味道,而无需刻意去思考「这段代码违反 DRY 原则了吗?」

品质影响品味

有人说,「北京有西直门换乘,就不可能有一流的设计师」。因为如果一位设计师每天都要经过西直门换乘,他就必须学会容忍别人的恶心设计,久而久之,他也就学会了忍自己的恶心设计。同样地,如果你每天看在线版的 MSDN ,你就会习惯了里面一些反模式的示例代码,习惯了这种满眼内容但就是找不到你所需信息的文档,习惯了 MSDN 网站打开的龟速。接下来,你就会觉得自己的代码偶尔反模式不是什么问题,自己的文档没人能读懂也不是什么问题,自己的 ASP.NET 网站比 MSDN 网站还慢更不是什么问题。

因此,品味是可以被引导的。你每天使用 Visual Studio 的体验(打开速度、键入代码便捷程度),查阅 MSDN 的体验(搜索多少次才能找到你要的信息),浏览技术博客的体验(文字是否容易理解、代码排版与着色是否易读)……这一切都会影响你的品味。在你写程序写文章时,你的大脑里会呈现出「一个优美的程序应该是这样子的」,或者是「一篇优美的文章应该是这样子的」。这个具体的想象,源自于你平时阅读到的程序和文章。正所谓「 Garbage in. Garbage out. 」,输入的品质决定了输出的品质。

程序员每天都要接触大量的信息源。聪明的程序员会选择那些高品质的信息源,同时避免在低品质的信息源上浪费时间。如果我从博客园首页打开一篇文章,然后看到作者在模板上乱改,例如插入拍得不怎么样的个人照片、消耗我 CPU 的 Flash 时钟等等影响视觉效果的东西,又或者是把 CSS 改得完全没有美感连裸奔都不如,我都不会再去看文章的具体内容,直接把窗口关掉。至于 CSDN 的博客,看到链接我就绕开了,因为我知道那个链接背后的页面有多恶心,右下角还一定会弹一个小窗口出来。这样做的原因很简单,如果你不在乎博客给人的第一印象如何,我不相信你对文章质量能有多在乎。

有品味才有品质

为什么有些杂志能够有如此高的品质,来迎合读者对品味的追求?我觉得这是因为那些杂志的背后有一群有品味的作者、摄影师、编辑……最最重要的是,有一位有品味的 CEO 。尽管我对杂志行业了解不多,但这个道理在软硬件行业是普遍存在的。

Jonathan Ive , Apple 负责工业设计的高级副总裁,在 Steve Jobs 回归 Apple 之后带领着设计团队创造了一系列突破性的产品,包括拯救了 Apple 的 iMac 、美国人手一部的 iPod 以及最近发布的 iPad 。那么在他加入 Apple 之后到 Steve Jobs 回归之前的这段时间里,他又做了什么呢?在这段时间里, Apple 一直在下滑, CEO 换了两任, Jonathan Ive 没能造出任何能拯救 Apple 的产品来。 Steve Jobs 和 Jonathan Ive ,谁的品味更重要一些?

有品质自然会有面包

我一直不明白,为什么博客园要把资源浪费在小组、问答、招聘这类项目上。在我看来,博客园有比这重要得多的问题有待解决。举个例子,文章编辑器和评论编辑器。尽管有不少人用 Windows Live Writer 之类的客户端,但编辑器依然显著地影响着作者和评论者的写作体验,而这个体验决定了最终的文章质量、评论质量。

为什么 Mac 软件的界面设计往往比 Windows 的要好?仅仅是因为 Apple 有 HIG (人机交互指引)吗?这是因为 Interface Builder 会引导你把控件放到符合 HIG 的位置上去。如果你把一个 Label 和一个 TextFiled 放到一行, Interface Builder 会提示你按照文本的基线对齐,而非按照控件边框对齐。回头看看 Visual Studio ,我相信不少人遇到过 LabelTextBox 难以对齐的问题,调来调去都不好看,最后索性就不调了。

写文章的人其实也会遇到同样的问题。谁不希望自己随手写出来的文章就很美观呢?但能够花时间去折腾模板和对每一篇文章进行细节调整的毕竟是少数人。这时候,编辑器能够达到什么样的品质,往往也就决定了文章和评论能够达到什么样的品质。

或许有人会说,问答很重要,因为工作上的问题解决不了我就会被炒掉。类似地,应该也有人会说,招聘很重要,如果连工作都找不到我哪里有闲情来写博客。这样的想法太过短视了。如果你有一个高品质的博客,你不可能没有好工作。不相信的话,你可以看看那些业界大牛的网站,有哪一个品质不高的?对自己的代码有什么样的品质要求,对自己的网站也就有什么样的品质要求。反过来,企业通过看网站的品质,也就能看出你的品质。

我知道,并不是每一个程序员都懂前端开发,也不是每一个程序员都懂视觉设计,但你必须意识到一点──那些大牛也不是天生下来就懂这些的,他们也必须经历学习的过程,只是他们为了把自己的网站做到符合自己的品味,不得不学习更多的知识而已。 Jeff 在做模板的时候,也问过我一些前端开发的问题,因此我觉得关键不在于你是否懂前端开发,而在于你是否真的想要把事情做好。(当然,你心目中「好」的定义由你的品味决定。)

对于网站和杂志来说,同样的道理是成立的。有些时候,不是覆盖越广的人群和满足越多的需求,就是越好的商业策划。如果能力有限,就用心做好一件事情。做到品质完全超越所有同行,钱自然会找上门来。

我最近读了一篇对 P1.cn 创始人王宇的采访。 P1.cn 是一个面向高消费人群的 SNS 。王宇说, P1.cn 用户的家庭月均收入为 ¥8000 ,开心的这数字是 ¥3000 ,人人的则是 ¥2000 , QQ 就更低了。尽管这是未经第三方证实的数据,但至少 P1.cn 上的广告能够说明问题──我想你不可能在 P1.cn 以外的 SNS 见到这些广告:轩尼诗的酒、佳能的数码单反、宾利的汽车……道理很简单,你去开心投放这类广告,回报率不可能高。

最后,用 Steve Jobs 的一句名言来结束这篇文章。在《 Macworld 》的 Mac 20周年采访中,记者问到了关于 Mac 市场份额的问题, Steve Jobs 的回答是:
Apple 的市场份额比宝马、奔驰或者保时捷在汽车市场中所占的份额都要大。成为数字领域的宝马或奔驰有什么不好的吗?

2010年1月30日星期六

能承载移动 Web 应用的唯一浏览器: Mobile Safari

最近拿 iPhone 、 Android 、 Windows Mobile 这三个平台上的内置浏览器来做了一番对比,结果是只有 iPhone 的 Mobile Safari 能够承载现代化的移动 Web 应用,其他移动浏览器的设计思路还停留在上个世纪──能看网页就行,不存在移动应用一说。

我用来做对比的平台是 iPhone 2.0 、 Android 2.0 、 Windows Mobile 6.5 。 iPhone 之所以选择 2.0 ,是因为 3.0 的浏览器跟 2.0 是一样的,尽管我的测试是在 3.0 上做的,但对 2.0 来说也是适用的。 Windows Mobile 6.5 则是在 Windows Mobile 系列中的唯一选择,因为只有它的浏览器是 IE6 内核的,再往前的 Windows Mobile 6.1 都是 IE4 内核的。

拖放

iPhone 对拖放的支持是完美的,使用 touch 系列事件监控触击及拖动,然后使用 preventDefault 禁用浏览器的默认行为(也就是拖动页面显示区域),这就搞掂了。

Android 也支持拖放,具体方案我没有研究过,估计是改用 mouse 系列事件监控触击及拖动,然后使用 preventDefault 禁用浏览器的默认行为。

Windows Mobile 让人很绝望,连拖放也不支持。估计因为这是一个对 IE6 的封装,封装的时候就把浏览器默认行为写死了,所以你不能够通过 mouse 事件监控到任何东西,也无法禁用浏览器默认行为。

手势

最简单的手势,就是通过两个手指靠进和远离来实现放大和缩小,如果这个手势都实现不了,别的手势也就不用测试了。

iPhone 对手势的支持也是完美的,你可以直接使用 gesture 系列事件监控手势操作,也可以用 touch 系列事件监控手势中每一个触点的活动。 preventDefault 同样可以禁用浏览器默认行为(也就是缩放页面显示区域)。

Android 的浏览器不支持多点触击,尽管 Android 的另一些内置应用是支持的,这估计是因为 Google 和 Apple 纠缠不清的多点触击专利官司。因此,如果你要在 Web 应用上支持缩放,就只能在界面上放两个按钮来实现了。

Window Mobile 就不用说了,你不能期望一个缩小版的 IE6 能做什么针对移动 Web 应用的优化。

定位

iPhone 可以使用 W3C 的 Geolocation API 进行定位,而且可以跟踪定位(也就是定位变化时通过事件调用你的函数)。

Android 内置的地图可以定位,但是浏览器就是不提供这个接口,这只能说 Android 就设计为不考虑移动 Web 应用。

Windows Mobile 在安装 Google Gears 后,理论上可以支持定位。这个 ActiveX 嘛,能让你扩展浏览器,实现任何其他浏览器上难以实现的东西。唯一的问题是,这会让人产生疑问──我到底是在 Web 应用开发还是在做客户端应用开发? Microsoft 背负了太多的历史包袱,使得开发者要从客户端应用开发转向 Web 应用开发也不容易。

绘图

iPhone 同时支持 SVG 和 Canvas 。如果你需要面向对象的图形组合方式,你可以选择 SVG 。如果你需要命令式(类似 GDI )的绘图接口,你可以选择 Canvas 。

Android 只支持 Canvas ,这能够满足大多数绘图需求,唯一的问题是你不能把已经绘制的形状如同对象般删除,需要的话只能全部重绘,这就是 Canvas 跟 SVG 在使用上的主要区别。

至于 Windows Mobile ,不仅仅 SVG 和 Canvas 这样的公开标准不支持,连 VML 这样的私有标准也不支持,基本上也就无法绘图了。

样式

iPhone 支持大部分的 CSS3 特性。这是因为 iPhone 1.0 并不支持客户端应用, Apple 为了让开发者能在 Web 上实现跟客户端应用一样的视觉效果, Mobile Safari 必须做到跟 Safari 一样,支持大多数的 CSS3 特性。

Android 支持的 CSS3 特性要少一些。尽管它的浏览器用的也是 Webkit 内核,但 Webkit 管的是布局而不是渲染,在样式渲染方面 Google 的实现总是比 Apple 要慢一步。

Windows Mobile 的话……跟一个 IE6 核心的浏览器讨论 CSS3 ,这不是纯粹浪费口水吗?

体验

上面列举了一大堆的功能,但这一切只是为了实现特定的体验,所以我们真正应该关注的是一款移动浏览器设计为满足怎样的体验目标。

iPhone 上的 Mobile Safari 拥有最高的体验目标设定。在 iPhone 1.0 的时候, Apple 禁止开发人员开发本地应用,只允许开发 Web 应用,因此 Apple 必须为开发人员提供最好的 Web 应用开发平台。

此外, Apple 拥有业界最好的 HIG (人机交互指引),对比之下 Microsoft 的 UX Guide 连 Windows Mobile 都覆盖不到,而 Android 的 UI Guildlines 则显得十分山寨。由于 Apple 鼓励开发者按照 HIG 进行 iPhone 应用程序的交互设计,所以 Mobile Safari 当初就设计为帮助开发者实践 HIG 。至于其他移动浏览器,它们的设计目标则简单得多──只要用户能够在上面流畅使用面向桌面设计的网站就可以了。

正是由于设计目标的差异,使得最终产出的产品存在着巨大的差异。只有 Mobile Safari 能够承载移动 Web 应用,其他移动浏览器只是桌面浏览器在移动设备上的延伸。