leechael.orgHome

印象中国内并没有多少人会提及 Unobtrusive JavaScript(低调的 JavaScript/不乱入的 JavaScript, 前者是在国内一 blog 看见的翻译，后者是对岸的一位设计师 Othree 的翻译)。本来这也不是很大的问题，倡导 CSS/JavaScript/HTML 代码分离是很多设计师们倡导的事情。有一篇 The seven rules of Unobtrusive JavaScript 说了七点 Unobtrusive JavaScript 要注意到的事情：

• 不作任何假定。
• 找到你的 JavaScript 在 HTML 代码中的接入点及与其的关系
• 将遍历 (Traversing) 留给专家(利用 CSS 来找寻你需要的元素)
• 了解浏览器和用户
• 了解事件(Events)
• 不与其他代码冲突
• 为下一个开发者工作

在看到最后一点后，一些东西就不再奇怪了。Unobtrusive JavaScript 倡导了一种良好的编码习惯，而实际上，或者说一句不中听的，这是给代码工人的规则。

Plaxo 的 Joseph Smarr 有一个很棒的、关于提高 JavaScript 的 slides: High Performance JavaScript。其中说到: Directly attach onclick, etc. handlers instead using event listeners where appropriate(尽可能地直接使用 onclick 等控制事件而不是事件冒泡).原因很简单，因为 Finding by class/attaching event handlers is slow.例如我需要那些 class 为 pop 的链接在点击后自动打开新窗口，当然我们可以通过编写一个额外的脚本来监控这些链接的点击，但在这些链接中使用 onclick 会让脚本运行得更快，但维护起来也会很麻烦。

而事实上，我们是否需要这般完整的分离代码呢？很大的可能是看这个站点对 JavaScript 的依赖程度。如果是轻度使用 JavaScript 来增强用户体验，Unobtrusive JavaScript 是很好的习惯；如果是那些 Web Application，例如，由于需要更多地考虑 JavaScript 的执行效率，就不必碍于 Unobtrusive JavaScript 的规则，适当地在 HTML 代码中插入 JavaScript 代码也未尝不可。

深究起来，其实这和编程中常见的、关于程序的 scalability 和 performance 的衡量，没有什么区别。

这几天评价豆瓣改版的人不少，长篇大论的赞扬和批评我不说太多，那些不是我该干的事情。要看这些东西，可以看执着于社区的麦田的豆瓣改版引发热议的冷思考, 可以看鲁公子的 社区化工具到工具化社区：豆瓣的乾坤大挪移, Charlee 这位非重度豆瓣使用者也说了数句。当然，按照预期，我这篇东西是写给 brant 看的，尽管我们互不认识，而他也就有不到 50% 的机会通过 blogsearch 定义的 keyword 搜索到这里。

废话不说了，上面变链接堆了。豆瓣这一次的改版，从某个角度来说忽略了老用户使用习惯上的过度，然后有一堆人在小组上面吵吵闹闹，好不热闹。我不算是一个可以分析的典型用户，我更多是把豆瓣当作一个工具而不是社区——对于不善于社交的人来说，社区是莫名其妙的存在。

首先是我的豆瓣这个页面。跟在我读后面的变成一个链接：173本在读、想读、读过的书籍——由原来的在读、想读、读过三个链接合并为一个链接。点击后，如果这是自己的个人页面，会跳转到想读的页面；而好友，或者说，他人的个人页面，点击该链接后进入他人的类似一个汇总列表的页面。我认为，这还是分为三个链接吧：想看、在看、看过。至于那个类似汇总的页面，很有累赘的感觉。如果从 SEO 的角度来说，该是避免无用的入口，减少分类页到最终目的页面之间需要跳转的页数，那么这个页面更需要取消。

我很可能对社交有些绝缘——好吧好吧，对于我那为数不多的好友，我关注他们在读在听在看的情况，那么，我进入“我的友邻”这个页面后，我期待看到的是他们通过豆瓣告知我和其它朋友这个方面的消息。我承认豆瓣的广播在这个方面有不错的效果，不过在我看来，这是一个阅读效率很低的列表。两个条目之间的留白太多了。头像或许可以考虑生成数个不同大小的，对于这般的一句话广播来说，30px 的长与宽或许已经足够了。然后，我认为“读”、“听”、“看”这几个字，不妨加上 <strong> 这个标签，或者用稍微不同的颜色标记，我想知道他们是在读九州志，而不是听或者看。

然后是读书、电影、音乐这三个频道。首先映入眼帘的是“友邻最近关注的xx”，接着在下面的是“你可能关心的评论”。豆瓣不要太自信自己的算法，在数据不足的情况下，这种推测有点无意义的味道。另一个方面，或许我有一点想找到最近的潮流：最热门和最新的，评论最多的。

豆瓣或许在排版上使用的列表方法上进行改进，也不要吝啬于生成各种不同规格的缩略图。

搜索框——那个利用 AJAX 做的下拉框，的确很 cool，不过给这个加上 outline:none，显示效果或许更佳？——另及，导航栏上使用这个 CSS Rule 作为对外观的小改进或者不错。

导航栏。一级菜单每一个链接旁边或许可以加上一个小小的 AJAX 按钮，或者套用这个 AJAX 效果：点击后仅是改变二级菜单里的显示，在点击刷新页面后，才看到二级菜单里的不同，这般或许就是在使用 AJAX 把操作化繁为简中被忽略的一点。AJAX 不是看起来很 cool，我们需要更实用的。

九点。本来想过单独说说九点这个产物，不过仔细想想，想说的其实也不多：

1. 我不希望九点在新窗口中打开。
2. 九点是阅读器还是一个 blog 推荐平台？——从 brant 的 blog 中看到，brant 自己是把九点当作阅读器，而可能在更多人的眼中，九点是后者。作为阅读器，九点并不高效，200+ 的更新在 GR 中我并不需要花费很多时间，在鲜果上有点费劲，在九点上更是有点 mission impossible 的味道；作为推荐平台，九点则是缺乏 API 收集评价数据。试想在 blog 中增加了一个按钮，“推荐到豆瓣九点”，类似“Post to Del.icio.us”。

我不知道是说多了还是说得一塌糊涂，这次为了省事也没有截图。当然，brant 或者其他豆瓣开发者看到这东西机会甚微，而考虑或者采纳机会更微，在这里我仅作为一个豆瓣的重度使用者和开发者的角度来说点什么，而不是评论家或其他。

可以先看看这一张截图：

按钮太多了。或许功能很完整，这是一个全能的阅读器，但是常用功能有多少呢？而无形之中，用户的学习成本提高了。或者用户不怕高昂的学习成本，但界面上太多干扰因素了，敢说你能从这样的界面上获得比 Google Reader 更高的阅读效率？

Getting Real 中有两点很合适的应用在设计上：更少的功能；更少的选择项和首选项。留给用户可以看见的选择越多，看见可以实现的功能越多，需要花费的学习成本越大。在界面上给用户最少的暗示，引导用户以最低的学习成本，在最短时间内熟悉你的界面，知道点击哪里会有什么行为。

vim 虽然是仅是一个编辑器，但却是一个很成功的产品。它的学习成本不高: esc, :, a, i, w, q, 基本上知道这六个按键的作用就能正常使用。当然这一切不仅是这般简单，它还有更多的快捷键，通过配置 .vimrc 以及插件，可以从一门轻机枪迅速转为重型大炮。

或许有另一个较好的类比；看过武侠小说的朋友，定对以下的场景感到熟悉：一个很普通的书房，通过某个特点的开关，暗门会打开（很多时候都是书柜），然后会发现另一个新天地。现在通过 JavaScript，可以留下更多“暗门”，那么为什么不留下“暗门”，而把默认界面设计为一个普通的书房，这般用户就能在最短时间内熟悉你的站点。

References

• Getting Real 中译版(非完整中译版)
• 白鸦 - 只把20%拿出来

或者我们可以先看一些例子:

Del.icio.us

雅虎中国

(被注册了？想一个更好的？更好的该是....)

V2EX

新浪

(我错在哪里了？根据红字所说的更改？....该是不会再弹出一个窗口的了吧？)

蚂蚁社区

结论

• Del.icio.us 和 V2EX 在错误信息的措词造句上，感觉是较为正式(formal)，这也是保险妥当的做法。
• Yahoo 中国的那句: “很遗憾，这个邮箱已经被注册了，再选个更好的吧。”在我看来是较为贴心的。
• 新浪和蚂蚁社区的错误信息中都用了感叹号; 新浪甚至用了弹出窗口。
• V2EX 的验证码说明文字中有一句“专为人类设计”——这一句小幽默，也不仅是 Livid 自信的表现，我想，看到这句话的用户也会被逗乐了。多语言版本中这句话也保留了，例如英文版本的“Only for human”

对于相当一部分用户，这些小细节是无关痛痒的: 国内论坛众多，而在搜索过程中，在某个没有注册的论坛找到需要的资源（例如下载链接），获得资源的前提条件是注册——因此注册了一堆帐号的用户，我猜想是不少的。他们在某个程度上，已经对任何提示语接近麻木的程度，这时候，错误信息中的句子是怎般的对他们的心理影响也不大。当然，他们只会是让站点看起来的注册人数不错的一个数字，从某个意义上说，留住这些用户的心也不仅是错误信息的遣词造句的问题，在这里暂不讨论。

这些遣词造句真正针对的用户，是潜在的活跃用户和新注册的用户。让我印象深刻的一次是，我妈在使用某个网络服务时输入了错误的密码，她嘟噜了一句“咦？怎么错了，我记得是xxxx……”这些错误的反馈信息正是针对这一部分的用户。对于初级用户，他们抱有有些谨慎的态度，例如新浪和蚂蚁社区的错误信息，都用了感叹号——这般或许会让初级用户不由得感到有些紧张和疑惑: 我哪里错了?他们不是不知道错误的所在，错误信息有告诉他们哪里错了；但是他们不知道为什么导致了这般的小错误，而且这个错误被提高至这般的一个高度。

所谓的 Accessibility，亲和力，不仅是版面设计的事情，也是遣词造句的事情。我的建议是，

1. 尽可能不使用叹号，而用句号，或者问号: “或者你可以试试 xx？”
2. 弹出窗口是恶魔，该尽可能不去使用。
3. 较为正式的语句虽然没有很好的亲和力，从另一方面来说，也并不会带给用户挫折情绪的影响。
4. 错误信息中带有一些建议性的语言，引导用户正确地输入，是一个很不错的做法。
5. 适当加入一些幽默的语句。

网页亲和力(accessibility), 并不仅是设计师的事情。