心弦

如果你没读过我之前的那篇“有感于与三通的对话”的话，我强烈建议你先花几分钟时间去看看，因为本文将在这篇文章的基础上展开进一步的讨论。

我上次提到了“规范”的重要性，其实“规范”这个词本身具有相当大的歧义，因为往小了说，它可能就体现为一些文档什么的；往大了说，什么东西都可以装在“规范”这个篮子里。为了避免让人联想起“规范文档专员”或是《1984》中“老大哥”（Big Brother）那样的形象，我借用了“架构”这个词，来形容此类工作，考虑这些事情的人，自然冠以“用户体验架构师”最为合适（我猜白鸦就是在做类似的工作，虽然他自己可能不这么叫）。

用户体验架构师是什么？估计100个人有至少100种说法。我觉得老冒提的“统筹和管理设计”这个概念很有意思，有效地引领、统筹、管理和规范设计应该是用户体验架构师最重要的工作职责之一，但我现在还不确定可不可以把这个“之一”拿掉。我非常希望白鸦能分享一下这块的经验，在我的概念中，他所提供的咨询服务就是为了解决设计部门（可能还包括产品部门）大方向和规范的问题。

那么用户体验架构师做哪些事情呢？至少应该包括以下一些：

确定界面设计的哲学

这个“哲学”包括：1）你这个产品或设计总体上想给人什么感觉？是Apple的灵活和酷，还是IBM的刻板和严谨？是KFC的明亮洁净，还是PizzaHut的温暖舒适？这个问题很重要，是指导设计师工作的基础。当遇到设计规范文档中没有描述的情况时，这个“总体感觉”就是发散和延伸的基础了。但是，这个恐怕也是最难总结和归纳的，Apple也是历经了几起几落后才确立了“酷”的风格（参见《苹果电脑案例》）；2）设计遵循“广且浅”还是“窄且深”的信息架构？Apple的设计非常明显带有“窄且深”的特点，一般来说它只会将最最常用的少数几个按钮放在面板上，其余的功能则逐级放在菜单或辅助面板上（其实也不是特别深），比如iWork中的幻灯片制作软件Keynote（如下图），实际上，它大部分软件都是如此，我已经养成了非常统一的操作习惯，我也很乐意养成这样的习惯，因为预期和结果具有高度一致性。反观MS的Word/Excel，我相信没人不记得上面那数十个按钮吧！MS给我的感觉是尽可能的把功能暴露在外面，它所采用的信息架构和Apple的就有明显区别。

未完待续……

2008年1月3日凌晨更新，推荐继续阅读我后来的几篇文章：

• 初探用户体验架构 2

从今天起本博推出一个新的栏目：“心弦设计沙龙”。通过这一栏目征集广大设计师对特定设计主题（或需求）的作品，旨在开拓视野、发散思路，吸收别人之所长，最终提高自己的设计能力。

第一期的设计主题是“为下拉菜单添加一个新增菜单项目的功能”。这一主题直接来源于我的日常工作，并且也是非常常见的设计需求。实际上，能够从实践中搜集问题，通过本栏目以集思广益的方式得到良好答案，并最终解决实际问题，这正是本栏目的出发点。具体的需求如下：

我们要给用户设计一个网上书架，用户可以把自己喜欢的图书添加到书架里，并展示给他的朋友们。考虑到有一些用户的收藏量比较大，我们对书架提供了分类功能：用户可以把不同种类的书放在不同的书架里，并且能在不同的书架间自由切换。由于某种原因，切换必须通过下拉菜单完成，即用户在下拉菜单中选择不同的种类，则菜单下方展示对应的书架（如下图所示）。现在我们需要添加一个功能，使用户能够方便添加类别。

这一产品的用户群比较广泛且分散，其中占比最大的用户群具有的特点包括：25岁左右，大学本科毕业后，在IT类公司工作了2年（职业未知）。平时喜欢一个人看书和听音乐，上网占了大部分业余时间。由于用户调研成本有限，我们对用户只了解这么多。

请根据上述用户特征描述和设计需求，设计你心目中此功能所应具有的交互界面及流程，设计好后请将demo通过邮件发给我（felixding[a]21cn.com，其中的[a]请自行换成@），demo的精度无所谓，能把界面及流程表述清楚就行了。如果觉得邮件不方便，也可以把demo的地址直接回复在留言里。

这是第一次搞这样的活动，到底效果如何我也不知道，所以不设立截止日期，以收到10个反馈为结束。结束时我会把所有的设计结果公布出来，届时大家可以揣摩学习。

晚上去参加“D2前端技术论坛”，结束出来时遇到了淘宝UED的视觉主管三通，便和他探讨起UED部门角色分工、流程和设计质量管理的问题。没想到在这样的问题上我们居然心有戚戚焉，有些相关的想法不吐不快，遂第一时间记录在这里。

我们开始此番讨论，源于我的一个关于淘宝UED角色分工的问题：在淘宝UED部门中，是采用单兵作战，即每个设计师独立承担项目中的所有角色，再辅以各领域专家（如研究、视觉和代码）的方式，还是按照设计师的专业方向，为其划分明确的职能范围？三通的答案很有意思，他说他觉得应该分一阵合一阵，因为淘宝两种方式都尝试过，总的感觉下来各有利弊。但有一点我们达成了绝对一致的意见，就是应该有一个起到架构和引领作用的小组，由它来制定整个网站的设计规范、标准和哲学，掌控每个产品及网站整体的设计质量，提升部门的设计水平，并提供基础性的工具支持。这个小组虚拟或实体都无所谓，关键在于必须有资源保证上述工作得以进行。在十几分钟的简短对话中，我们不约而同的对规范的价值一再肯定。

规范是我一直都非常非常重视的部分，它不仅仅包括对设计要求的界定，还包括了流程、方法和产出物本身。你可以把规范实现的最高境界看成：随便拉两个设计师出来，他们都可以遵循一直的设计哲学，用相同的流程和方法，产出质量相等的东西。此时人已经不是影响团队设计质量的重要因素了，团队也不会因为某个设计师的突然缺失而受到重大损失。当达到或接近这种程度时，真正重要的，就是规范本身。下午我和同事（iefen）谈话时，说了这样一句话：“人们制定规范，人们遵守规范，人们更新规范。规范进步，人也随之进步”。

这当然是一种非常理想的境界，但我坚信其方向是正确的，现实当中的例证也比比皆是。 比如，我们在学校所学到的知识，其实它们不都是完全正确的，但教育普及的结果就是低成本的提升了全民素质，降低了人与人之间的沟通成本。当科学家们把知识的内容更新后，更广大的人民受益，整个社会也随之进步。

再比如，程序开发中所使用到的各种框架，可以显著提升程序员的工作效率，保证开发质量。完全不用担心框架会限制人们的水平，因为自然有高水平的程序员会做升级框架的工作。

这样的例子举一天也举不完，但有人不同意。就像iefen说的那样：制定规范并确保它的执行，这只是一个过程，或者说做法，我们不能为了制定规范而制定规范，因为高管们并不关心规范本身，他们要的是结果。我的回答是：为什么不可以为了制定规范而制定规范？如果是制定规范这是一个过程而非目标的话，那么提升和保证设计质量也同样是个过程而非目标，因为提升和保证设计质量是为了提高可用性和用户体验，提高可用性和用户体验是为了用户更愿意使用我们的产品……按照如此逻辑推论下去，任何事情都只是过程而非目标。既然我们已经知道了其中的因果关系，不注重因，又何谈果！

所谓知易行难。三通用了一个非常恰当的词，来形容部门内基础和规范的建设，就是“公共福利”。我觉得这个词用得真tm绝了！实际上我一直在做提高“公共福利”的事情，无论是去年的“支付宝设计指南”、“代码助手”、“支付宝UI库”（类似YUI的东西），还是今年的“支付宝UI设计规范”、“支付宝模板和代码片段库”、“卡片分类测试助手”和“变形金刚”（具体用途自己猜）等等一系列的规范和工具，过程辛苦异常（其中的经历我都可以出本书了），结果不够理想，因为这是“公共福利”，因为不是今天打下去桩明天就能盖栋楼的。

说了半天规范的重要性，再花点时间来谈谈方法论的问题。作规范，说白了就三件事儿：制定规范、确保它的有效执行、建立规范更新机制。我想特别说说第二件。

确保规范的有效执行，其实是上述三件事儿中最难办到的。我最初的做法是提供文档，但我很快就发现这行不通，因为不是所有人都像我一样喜欢阅读文档，即使这个文档的内容来源于设计师自己；于是我尝试提供一些工具来辅助设计，比如前文提到的“代码助手”和“支付宝UI库”，这一方法确实有用，但效果远不如预期，根本原因在于这些工具的作用只是辅助设计，而不在设计师工作中的必经之路；于是痛定思痛之下，借鉴团队软件开发模式，我联合两位同事推出了“支付宝模板和代码片段库”（你现在在支付宝网站上看到的页面布局样式，就是其中的一部分产物），直接把符合设计规范的模板和代码片段集成到每个人所使用的Dreamweaver中，并专门设立一台服务器来提供最新的模板和代码片段源，从结果来看，这一方法的效果非常理想，可以说我现在至少能从源头上进行质量控制了。

在我的设想中，应用此方法从源头把握设计质量，后期通过架构小组审核并结合可用性测试来掌控最终设计交付物的质量（当然会有相应的审核流程和标准，时间关系不在这里展开讲了）。可惜由于种种原因，这种“中央集权式”的做法最终没能实现。我觉得除非你的团队能够一直保持高质量的设计，否则设计质量控制就是一个重要又紧急的问题，听说承志最近也在考虑类似的问题，我比较期待他的解决方案。

时间太晚了（现在是凌晨1点15分），先写到这儿吧。

2008年1月3日凌晨更新，推荐继续阅读我后来的几篇文章：

• 初探用户体验架构（“有感于与三通的对话”续篇）
• 初探用户体验架构 2

永久链接的英文原文是“Permanent link”或“Clean URL”，指的是一个链接具有静态且绝对的地址。永久链接最初主要是为了做搜索引擎优化（SEO），因为Google的机器人对静态的URL有偏好，所以对于动态生成的页面，人们想出了这么个办法来使其假扮成一个静态的页面，以便让Google更好的索引网站内容；另外一个初衷是增加URL地址的可读性（前些年的URL常常非常复杂，尤其是一些门户网站）。这两年随着重写技术（Rewrite）的广泛应用和REST的兴起，永久链接变成了一件相当时髦的事情，你现在看到的我的Blog，就采用了永久链接。

但人们似乎忽视了永久链接的一些可用性问题。

首先，从理论上来讲当一个页面拥有了永久链接后，无论在何时何地访问这个链接地址，用户都应该得到同一个页面－否则还叫什么“永久链接”呢！但事实却并不总是这样，因此它的第一个可用性问题就是：永久链接并不真的永久！

这个问题常见于网站列表页上必不可少的翻页导航。我的Blog也有（如下图），为了达到上述两个目的，翻页导航中的链接全部是永久链接，仔细观察其URL，不难看出其中的“page:（数字）”表示页码。但因为我会不断地更新Blog的内容，某一页面内的内容就会发生变化，这样就会造成这个月看到的第三页的内容和下个月看到的可能就会不一样，此时永久链接也就不再永久了。产生这一问题的根源在于，为了让用户首先看到最新的内容，网站设计者把通常意义上的“最后一页”（或者说最新一页）变成了第一页，造成索引完全失效了。这就好像你在读一本书的同时，作者不断从开头增加内容，结果你发现当你第二次拿起这本书的时候，无论如何也不能根据记忆中的页码来找东西了。

那么怎么解决这一问题呢？我觉得至少可以从以下两方面入手：

按照现实中的习惯来为网站内容索引

就是依照时间顺序来自然的增大页码，这是一种根除问题的办法。但缺点在于它会挑战用户习惯，由经验我们知道，这是很可怕的 :P

给页码链接增加时间戳

给每一个动态生成的页码链接加上一个时间戳，比如“page:3/date:20071216”，以此来表示此页码的有效时间范围。但这显然会增加程序设计的难度，并且从它的隐喻来讲比较奇怪，“2007年12月16号的第三页”？这听起来令人匪夷所思，虽然这一方法确实能解决上述问题。

前几天曾经写（主要是翻译）过一篇“未来的UI设计 1”，在那篇文章的结尾，我提到说打算写一篇关于“直接操纵”（direct manipulation）的文章，那么你现在看到的文字，就是我这两日酝酿的部分结果。

顾名思义，直接操纵就是你按照真实世界中的做法，对物体进行操纵。比如你想看看手机是不是放在抽屉里了，只要打开抽屉就知道了。这听起来好像有点奇怪，因为这不是再正常不过的事情了吗？可是你想想在电脑里，就拿AVG或RPG游戏来说，你扮演的角色要喝水的时候是不是要先用鼠标点杯子，然后在弹出的菜单中选择“喝水”？这就不是直接操纵，并且在GUI中，非直接操纵的交互太普遍了，以致大家都见怪不怪了。

直接操纵的好处很多。最大的好处就是没有或几乎没有学习成本，现实当中的做法和计算机中的没有区别，预期和结果相符；其次就是出错的可能性会大幅度降低，操作时间也会下降，因为所有的结果都是可预期的；最后，直接操纵所带来的乐趣比较大，比如玩游戏的时候。写到这儿突然想起一个绝妙的例子：Westwood的经典名作“C&C”和尚洋工作室的“血狮”。这两款游戏我就不介绍了，老玩家应该都记得，不知道的可以自己Google，我要说的是它们虽然同为战争类的RTS游戏，但操作方式却大相径庭。C&C是对直接操纵的典型应用（虽然很多方面还不是）：选中一个物体－比如一辆坦克－然后点击目的地，坦克就会自动开过去；可到了血狮那里，好不容易选中了一辆坦克后（血狮程序有Bug，选东西经常选不中），你还需要在菜单中选择让它干吗－是移动还是攻击？让人哭笑不得，期待了那么久的国产游戏，拿到手后却被拙劣的操作方式搞的兴趣索然（我知道尚洋也是有原因的，作为国产游戏早期的从业者，他们的开拓精神值得尊敬，这里的讨论只是就事论事）。

有人可能会问，直接操纵是不是等于所见即所得（WYSIWYG）？我觉得直接操纵肯定是所见即所得的，但反过来则不一定。比如在Photoshop里调整一个对象大小的操作就是所见即所得的，如果你通过鼠标拉动来调整，这就是直接操纵；如果在工具面板中直接输入对象大小的数值，虽然你也能即时看到结果，但这就不是直接操纵，按照我最最崇拜的HCI专家Shneiderman （1997）和Preece（1994）两口子的观点，这叫做“form fillin”。

直接操纵当然也有很多缺点。对于UI设计师和程序员来说，最大的问题就是对技术要求太高，相比非直接操纵的程序，开发人员需要付出更多努力，这一点极大地阻碍了这一交互方式的普遍应用。幸运的是，Apple公司Core Animation的出现，可能会在整个IT行业加速推动直接操纵的应用。对于普通用户来说，并不是所有操作需要直接操纵。比如按照“文件XX”的形式给一个目录下100个文件改名（其中的XX代表数字编号），直接操纵显然不如命令行来得快。

在应用方面，我接下来会特别谈谈Core Animation，因为它可能会带来一场UI设计上的革命！还是那句话：敬请期待 ：）

LonelyThinker(LT)就是你现在看到的这个blog程序，目前的版本是0.3.2007112801。因为我很可能会把这个程序开源（我知道WP、MT等程序很棒，可总有人需要点不同的东西，对吧），所以特别在此记录下来它一路的发展轨迹。在0.4版中，我计划有如下变动：

确定每个版本升级所遵循的原则，以及版本号的规则

从0.4版开始，每次升级都会至少增添一个重要的功能、或是对已有功能进行大幅度更新。当我确定下一版本的升级目标后，会立即一步步修改线上的程序，并同时更新修订版本号，直到我觉得这个目标已经达成，此时就会更新主版本号。至于版本号的规则，则从现有的“主版本号.日期+当日修订版本号”变为“主版本号.修订版本号.日期”。

比如，我决定在LT 0.4中增加一个名为“iconment”的功能，并以此作为升级目标。那么我会在接下来的一段时间里不断的升级程序，版本号也会由现在的0.3.2007112801变为0.3.2.20071128、0.3.3.xxxxxxxx、0.3.4.xxxxxxxx……，直到我认为这个功能完成了，才会正式发布0.4版的LT，届时版本号会是0.4.0.xxxxxxxx这样的格式。

iconment

这个词是“icon”和“comment”的合写，意思是带有图标的评论。这里的“图标”一方面指的是评论内容中的表情图标，更重要的，则指评论者的头像图标。

表情图标实现起来比较简单，无非就是利用正则表达式替换字符串；但头像图标的实现则要花点心思。我计划使用Gravatar的服务结合自己编写的程序，来实现评论者头像图标的管理和显示。用OmniGraffle画了个流程图草稿，如下所示：

此外，iconment还将包含以下改进：1）评论订阅。评论者可以订阅他所评论文章的最新评论，这样他就不用总跑到那篇文章下面看看有没有人回复他的评论了；2）待定 ：）

Spam防火墙

因为没有做统计功能，我不清楚现在blog上几乎看不到Spam的原因是什么，是因为机器人不认识评论表单的代码（以前用WP时每天Spam多得要命），还是现在的防Spam机制真的管用？无论怎样，我仍然看到有漏网的Spam。在LT 0.4中，我会大幅度完善Spam处理机制，同时力争做到像现在一样不影响用户体验－你仍然不需要输入一个莫名其妙的单词、或是回答一个数学题什么的。

图片来源于鸟山明的《七龙珠》。

Smashing Magazine网站发表了一篇题为“Monday Inspiration: User Experience Of The Future”的文章，介绍了未来数年内可能采用的UI设计。

Cheoptics360™

这东西真是酷毙了！能够在空气中生成栩栩如生的三维影像！

reactable

reactable是一个建立在桌面之上、使用多点触摸界面（mutil-touch interface）技术的可协作的电子乐器。通过移动和旋转桌面上的物体，不同的演奏者可以同时控制这一乐器。这里有一个演示。

Multi-Touch

经过苹果这两年的宣传，尤其是iPhone的流行，mutil-touch早已不是什么新鲜技术了。但iPhone中的应用不过是冰山一角而已。下图中展示的mutil-touch具有抓取（grabing）、拉伸（stretching）、旋转（swiveling）和滑动（sliding）等功能，甚至同时捕捉和响应你不同手指的运动（演示1和演示2）。怎么样，是不是听起来像是科幻电影一样！

Microsoft Surface

我是今年春天的时候听说了Microsoft Surface，观看演示的视频后对其赞叹不已。Surface充分使用了mutil-touch技术，大大的触摸屏可以响应很多种手势。此外，当你把电子设备放在它的触摸屏上时，Surface电脑马上会“看到”你的设备（通过隐藏的多个摄像头），并即时在屏幕上展现出各种可能的操作。比如你放个数码相机上去，它就会问你是否要查看照片等等。我看的时候就觉得，只有如此简单的操作才能真正将电脑普及到千家万户。

Photosynth

Photosynth的算法相当先进，它可以根据一系列照片生成一个多维的空间（顶多4维吧，多了人也感受不到）。Photosynth的架构师Blaise Aguera y Arcas提供了一个备受赞誉的演示。

BumpTop

Bumptop是一种全新的用户界面，它把常见的桌面（就是Windows/Mac OS X等操作系统的桌面）的隐喻，发展成炫目的3D版本。

这篇博客主要对未来的交互方式做了简单的介绍，我计划在“未来的UI设计 2”中详细介绍现在就能用的上的交互方式：“直接操纵”（direct manipulation），敬请期待 ：）

老实说，给这篇博客起这么个名字就是为了骗点击量的，因为我真正要说的是阿北和他的豆瓣。

崇拜了那么久，这是我第一次亲眼见到阿北。他给我的感觉是，不仅程序和设计做得好，人也实在。他一上台就问了句“有人不知道豆瓣吗”，在我们都窃以为他在耍大牌之时，他忽然说：“那我就不需要浪费大家时间过多介绍豆瓣了”，台下不禁释然一笑。

来听阿北布道的同行

豆瓣的设计早都被众多高手评判过了，那么阿北自己是如何诠释豆瓣的设计呢？在幻灯片里，他给出了一个“Web 2.0原则”：

• 从最简单版本开始
• 持续叠代（alwasy beta）
• Eat your own dog food

对于Web 2.0公司而言，这些都是不错的点子。我个人认为很多非Web 2.0的互联网公司常常以这些原则为借口，来为自己低水平的设计开脱。常见的说法是：只有国外的互联网环境才适于在产品发布前对其进行精雕细琢，在国内，我们需要最快速度把产品发布掉，然后再想办法完善。这种说法的错误之处在于，它混淆了产品的功能和设计。我同意最快速度把功能展现给用户的做法，但这些功能本身、以及功能的界面设计必须达到一定的水平，用俗话说，就是作一样东西像一样东西。

当然，不同的公司有不同的风格和做法，高质量的设计和高水平的技术并非是商业成功的充分条件。

阿北认为，上述原则的实现是有前提条件的，它们包括：

• 最简设计
• 敏捷开发过程和支持快速修改的技术架构
• 设计者是真正用户
• 即时的用户反馈通道

其中最吸引我的是第二条，因为身在支付宝这样的公司，页面上的调整－哪怕是修改几个字－都做不到像Web 2.0公司那样“敏捷”。豆瓣曾经一天内修改过3次设计，但我常常遇到项目开始时设计的Demo到了项目临近发布时发现不是很合适的尴尬情况（因为业务的发展）。传统的互联网公司如何借鉴这样的经验、尽可能地为设计创造敏捷的环境，这是一个深入考虑的问题。

阿北还提出了关于用户调研的一些经验，包括：

• 用户要的不是用户需要的
• 用户要的只是他自己要的
• 用户不知道他应该需要的

还有：

• 1%用户发出80%的声音
• 1%用户推动新需求的满足
• 1%用户不是典型用户

这些其实是非常普遍的情况，在用户调研时，如何确定典型用户、以及如何分辨用户真正的需求确实是比较令人头疼的。就拿我最近在做的一个项目来说，根据业务部门的需求，我们经过讨论后对我们认为的典型用户做了调研，在访谈中，我们尽可能根据用户的习惯，来挖掘他们的原始需求，结果发现他们对业务部门构想的产品没有兴趣。但这一结果和方法本身均遭到了业务部门的质疑甚至反对，他们认为应该找此类产品的直接使用者（已有其它公司提供了类似的产品），并直接提出诸如“你需要什么样的功能”这样的问题。在经过一番激烈的辩论后，双方各退一步，决定在极小的范围内推出此产品，并以此试探用户的反应。虽然我对这样的结果多少有些无可奈何，但在用户研究方面确实经验不足，不知道如何是好。

很遗憾的是，听到一半我的相机没电了，后来的幻灯片都没能拍下来。剩下的内容等我拿到阿北的PPT再写吧。

另外，再次向阿北呼吁尽快开放API，嘿嘿～

周四在公司加班到近凌晨1点，期间在和开发部门的同事焦头烂额的编写js代码时，深深被jQuery强大的选择器所折服。

1、选择不存在的HTML对象时，jQuery不会报错

这点我早就深有体会。在此前使用的Prototype中，选择HTML对象前必须要保证这个对象的合法性，如果这个对象不存在，Prototype就会报错。这听起来很正常，但在jQuery中这种检查完全没必要，因为当一个对象不存在时，它会自动跳过那段代码！这样用起来非常方便。

2、parents()、children()和find()

利用parents()和children()可以很快捷地找到一个对象的父对象和子对象，但在实际使用时，常常遇到使用这两个函数编写好的js代码无法重用的问题，这是因为js代码是按照现有HTML的层级关系编写的，一旦HTML中的层级关系发生变化，js就失效了。幸好有find()这个函数，它可以让你完全不顾上下文的关系，而选择你想要选择的对象。

比如我想在用户点链接的时候，把如下代码中span的内容打印出来：

如果用parents()和children()：

如果用find()：

这看起来好像没什么区别？别急，find()还可以这样用：

这一点当时就把我们给震了！虽然实际编写的代码比这个要复杂的多，但我们怎么也没想到前面为空时find()依然有效！我估计此时find('span')就相当于$('span')。

最后就是，有谁知道到底用什么工具可以给jQuery代码生成注释文档？之前提的JSDoc不行。